[PATCH v3 06/13] clk: qcom: Add HFPLL driver

[Stephen Boyd]

On some devices (MSM8974 for example), the HFPLLs are
instantiated within the Krait processor subsystem as separate
register regions. Add a driver for these PLLs so that we can
provide HFPLL clocks for use by the system.

Cc: 
Signed-off-by: Stephen Boyd 
---
 .../devicetree/bindings/clock/qcom,hfpll.txt   |  40 
 drivers/clk/qcom/Kconfig   |   8 ++
 drivers/clk/qcom/Makefile  |   1 +
 drivers/clk/qcom/hfpll.c   | 109 +
 4 files changed, 158 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,hfpll.txt
 create mode 100644 drivers/clk/qcom/hfpll.c

diff --git a/Documentation/devicetree/bindings/clock/qcom,hfpll.txt 
b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt
new file mode 100644
index ..fee92bb30344
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt
@@ -0,0 +1,40 @@
+High-Frequency PLL (HFPLL)
+
+PROPERTIES
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be "qcom,hfpll"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: address and size of HPLL registers. An optional second
+   element specifies the address and size of the alias
+   register region.
+
+- clock-output-names:
+   Usage: required
+   Value type: 
+   Definition: Name of the PLL. Typically hfpllX where X is a CPU number
+   starting at 0. Otherwise hfpll_Y where Y is more specific
+   such as "l2".
+
+Example:
+
+1) An HFPLL for the L2 cache.
+
+   clock-controller@f9016000 {
+   compatible = "qcom,hfpll";
+   reg = <0xf9016000 0x30>;
+   clock-output-names = "hfpll_l2";
+   };
+
+2) An HFPLL for CPU0. This HFPLL has the alias register region.
+
+   clock-controller@f908a000 {
+   compatible = "qcom,hfpll";
+   reg = <0xf908a000 0x30>, <0xf900a000 0x30>;
+   clock-output-names = "hfpll0";
+   };
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 0d7ab52b7ab0..d421fd195114 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -88,3 +88,11 @@ config MSM_MMCC_8974
  Support for the multimedia clock controller on msm8974 devices.
  Say Y if you want to support multimedia devices such as display,
  graphics, video encode/decode, camera, etc.
+
+config QCOM_HFPLL
+   tristate "High-Frequency PLL (HFPLL) Clock Controller"
+   depends on COMMON_CLK_QCOM
+   help
+ Support for the high-frequency PLLs present on Qualcomm devices.
+ Say Y if you want to support CPU frequency scaling on devices
+ such as MSM8974, APQ8084, etc.
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 953f792d2133..b1076179fb17 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_MSM_LCC_8960) += lcc-msm8960.o
 obj-$(CONFIG_MSM_GCC_8974) += gcc-msm8974.o
 obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
 obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
+obj-$(CONFIG_QCOM_HFPLL) += hfpll.o
diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom/hfpll.c
new file mode 100644
index ..0092017b257d
--- /dev/null
+++ b/drivers/clk/qcom/hfpll.c
@@ -0,0 +1,109 @@
+/*
+ * Copyright (c) 2013-2014, 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 "clk-regmap.h"
+#include "clk-hfpll.h"
+
+static const struct hfpll_data hdata = {
+   .mode_reg = 0x00,
+   .l_reg = 0x04,
+   .m_reg = 0x08,
+   .n_reg = 0x0c,
+   .user_reg = 0x10,
+   .config_reg = 0x14,
+   .config_val = 0x430405d,
+   .status_reg = 0x1c,
+   .lock_bit = 16,
+
+   .user_val = 0x8,
+   .user_vco_mask = 0x10,
+   .low_vco_max_rate = 124800,
+   .min_rate = 53760UL,
+   .max_rate = 29UL,
+};
+
+static const struct of_device_id qcom_hfpll_match_table[] = {
+   { .compatible = "qcom,hfpll" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, qcom_hfpll_match_table);
+
+static const struct regmap_config hfpll_regmap_config = {
+   .reg_bits   = 32,
+   .reg_stride = 4,
+   .val_bits   = 32,
+   .max_register   = 0x30,
+   .fast_io= true,
+};
+
+static int qcom_hfpll_probe(struct platform_device *

[PATCH v3 10/13] clk: qcom: Add KPSS ACC/GCC driver

[Stephen Boyd]

The ACC and GCC regions present in KPSSv1 contain registers to
control clocks and power to each Krait CPU and L2. For CPUfreq
purposes probe these devices and expose a mux clock that chooses
between PXO and PLL8.

Cc: 
Signed-off-by: Stephen Boyd 
---
 .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt  |  7 ++
 .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt  | 28 +++
 drivers/clk/qcom/Kconfig   |  8 ++
 drivers/clk/qcom/Makefile  |  1 +
 drivers/clk/qcom/kpss-xcc.c| 95 ++
 5 files changed, 139 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
 create mode 100644 drivers/clk/qcom/kpss-xcc.c

diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt 
b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
index 1333db9acfee..382a574a5c55 100644
--- a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
@@ -21,10 +21,17 @@ PROPERTIES
the register region. An optional second element specifies
the base address and size of the alias register region.
 
+- clock-output-names:
+   Usage: optional
+   Value type: 
+   Definition: Name of the output clock. Typically acpuX_aux where X is a
+   CPU number starting at 0.
+
 Example:
 
clock-controller@2088000 {
compatible = "qcom,kpss-acc-v2";
reg = <0x02088000 0x1000>,
  <0x02008000 0x1000>;
+   clock-output-names = "acpu0_aux";
};
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt 
b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
new file mode 100644
index ..d1e12f16a28c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
@@ -0,0 +1,28 @@
+Krait Processor Sub-system (KPSS) Global Clock Controller (GCC)
+
+PROPERTIES
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: should be one of:
+   "qcom,kpss-gcc"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: base address and size of the register region
+
+- clock-output-names:
+   Usage: required
+   Value type: 
+   Definition: Name of the output clock. Typically acpu_l2_aux indicating
+   an L2 cache auxiliary clock.
+
+Example:
+
+   l2cc: clock-controller@2011000 {
+   compatible = "qcom,kpss-gcc";
+   reg = <0x2011000 0x1000>;
+   clock-output-names = "acpu_l2_aux";
+   };
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 7b82b3c4e259..92eb883533d5 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -97,6 +97,14 @@ config QCOM_HFPLL
  Say Y if you want to support CPU frequency scaling on devices
  such as MSM8974, APQ8084, etc.
 
+config KPSS_XCC
+   tristate "KPSS Clock Controller"
+   depends on COMMON_CLK_QCOM
+   help
+ Support for the Krait ACC and GCC clock controllers. Say Y
+ if you want to support CPU frequency scaling on devices such
+ as MSM8960, APQ8064, etc.
+
 config KRAIT_CLOCKS
bool
select KRAIT_L2_ACCESSORS
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index f8d7cfaee4a2..6327dd623773 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -22,4 +22,5 @@ obj-$(CONFIG_MSM_LCC_8960) += lcc-msm8960.o
 obj-$(CONFIG_MSM_GCC_8974) += gcc-msm8974.o
 obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
 obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
+obj-$(CONFIG_KPSS_XCC) += kpss-xcc.o
 obj-$(CONFIG_QCOM_HFPLL) += hfpll.o
diff --git a/drivers/clk/qcom/kpss-xcc.c b/drivers/clk/qcom/kpss-xcc.c
new file mode 100644
index ..abf6bfd053c1
--- /dev/null
+++ b/drivers/clk/qcom/kpss-xcc.c
@@ -0,0 +1,95 @@
+/* Copyright (c) 2014-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 
+
+static const char *aux_parents[] = {
+   "pll8_vote",
+   "pxo",
+};
+
+static unsigned int aux_parent_map[] = {
+   3,
+   0,
+};
+
+static const struct of_device_id kpss_xcc_match_table[] = {
+   { .compatible = "qcom,kpss-acc-v1", .data = (void *)1UL },
+   { .compatible = "qcom,kpss-gcc" },
+   

[PATCH v3 12/13] cpufreq: Add module to register cpufreq on Krait CPUs

[Stephen Boyd]

Register a cpufreq-generic device whenever we detect that a
"qcom,krait" compatible CPU is present in DT.

Cc: 
Signed-off-by: Stephen Boyd 
---
 .../devicetree/bindings/arm/msm/qcom,pvs.txt   |  38 
 drivers/cpufreq/Kconfig.arm|   9 +
 drivers/cpufreq/Makefile   |   1 +
 drivers/cpufreq/qcom-cpufreq.c | 204 +
 4 files changed, 252 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,pvs.txt
 create mode 100644 drivers/cpufreq/qcom-cpufreq.c

diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,pvs.txt 
b/Documentation/devicetree/bindings/arm/msm/qcom,pvs.txt
new file mode 100644
index ..e7cb10426a3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,pvs.txt
@@ -0,0 +1,38 @@
+Qualcomm Process Voltage Scaling Tables
+
+The node name is required to be "qcom,pvs". There shall only be one
+such node present in the root of the tree.
+
+PROPERTIES
+
+- qcom,pvs-format-a or qcom,pvs-format-b:
+   Usage: required
+   Value type: 
+   Definition: Indicates the format of qcom,speedX-pvsY-bin-vZ properties.
+   If qcom,pvs-format-a is used the table is two columns
+   (frequency and voltage in that order). If qcom,pvs-format-b 
is used the table is three columns (frequency, voltage,
+   and current in that order).
+
+- qcom,speedX-pvsY-bin-vZ:
+   Usage: required
+   Value type: 
+   Definition: The PVS table corresponding to the speed bin X, pvs bin Y,
+   and version Z.
+Example:
+
+   qcom,pvs {
+   qcom,pvs-format-a;
+   qcom,speed0-pvs0-bin-v0 =
+   <  38400  95 >,
+   <  48600  975000 >,
+   <  59400 100 >,
+   <  70200 1025000 >,
+   <  81000 1075000 >,
+   <  91800 110 >,
+   < 102600 1125000 >,
+   < 113400 1175000 >,
+   < 124200 120 >,
+   < 135000 1225000 >,
+   < 145800 1237500 >,
+   < 151200 125 >;
+   };
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 1b06fc4640e2..3829d5521dfc 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -137,6 +137,15 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
 
+config ARM_QCOM_CPUFREQ
+   tristate "Qualcomm based"
+   depends on ARCH_QCOM
+   select PM_OPP
+   help
+ This adds the CPUFreq driver for Qualcomm SoC based boards.
+
+ If in doubt, say N.
+
 config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 82a1821471fd..be95ed8d6873 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ)+= kirkwood-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
 obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)   += pxa2xx-cpufreq.o
 obj-$(CONFIG_PXA3xx)   += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ) += qcom-cpufreq.o
 obj-$(CONFIG_ARM_S3C24XX_CPUFREQ)  += s3c24xx-cpufreq.o
 obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o
 obj-$(CONFIG_ARM_S3C2410_CPUFREQ)  += s3c2410-cpufreq.o
diff --git a/drivers/cpufreq/qcom-cpufreq.c b/drivers/cpufreq/qcom-cpufreq.c
new file mode 100644
index ..c9f86a062cdd
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq.c
@@ -0,0 +1,204 @@
+/* Copyright (c) 2014, 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 
+
+static void __init get_krait_bin_format_a(int *speed, int *pvs, int *pvs_ver)
+{
+   void __iomem *base;
+   u32 pte_efuse;
+
+   *speed = *pvs = *pvs_ver = 0;
+
+   base = ioremap(0x007000c0, 4);
+   if (!base) {
+   pr_warn("Unable to read efuse data. Defaulting to 0!\n");
+   return;
+   }
+
+   pte_efuse = readl_relaxed(base);
+   iounmap(base);
+
+   *speed = pte_efuse & 0xf;
+   if (*speed == 0xf)
+   *speed = (pte_efuse >> 4) & 0xf;
+
+   if (*speed

[PATCH v3 00/13] Krait clocks + Krait CPUfreq

[Stephen Boyd]

These patches provide cpufreq scaling on devices with Krait CPUs.
In Krait CPU designs there's one PLL and two muxes per CPU, allowing
us to switch CPU frequencies independently.

 secondary
 +-++
 | QSB |---+|\
 +-+   || |-+
   |+---|/  |
   ||   +   |
 +-+   ||   |
 | PLL |+---+   |   primary
 +-+|  || +
|  |+-|\   +--+
 +---+  |  |  | \  |  |
 | HFPLL |--+-|  |-| CPU0 |
 +---+  |  || |  | |  |
|  || +-+ | /  +--+
|  |+-| / 2 |-|/
|  |  +-+ +
|  | secondary
|  |+
|  +|\
|   | |-+
+---|/  |   primary
+   | +
+-|\   +--+
 +---+| \  |  |
 | HFPLL ||  |-| CPU1 |
 +---+  | |  | |  |
| +-+ | /  +--+
+-| / 2 |-|/
  +-+ +

To support this in the common clock framework we model the muxes,
dividers, and PLLs as different clocks. CPUfreq only interacts
with the primary mux (farthest right in the diagram). When CPUfreq
sets a rate, the mux code finds the best parent that can provide the rate.
Due to the design, QSB and the top PLL are always a fixed rate and thus
only support one frequency each. These sources provide the lowest
frequencies for the CPUs. The HFPLLs are where we can make the CPU go
faster (GHz range). Sometimes we need to run the HFPLL twice as
fast and divide it by two to get a particular frequency.

When switching rates we can't leave the CPU clocked by the HFPLL because
we need to turn off the output of the PLL when changing its frequency.
This means we have to switch over to the secondary mux and use one of the
fixed sources. This is why we need something like the safe parent patch.

I plan to submit the DTS changes through arm-soc, but I've included everything
here to make it easier to pick things up for testing, etc. If anything can be
picked up right now it would be better to reduce the churn over time as
other pieces settle. Some things are not done, but I'm posting this now
to get it out there and because the clock framework patches needed some rework
due to recent changes.

Changes since v2:
 * Switched to cpufreq-dt
 * Ported over PVS binding
 * Stripped out cpu logical map to make modules work
 * Dropped patches that merged upstream

Changes since v1:
 * Added IPQ and APQ8064 support
 * Switched to cpufreq-generic
 * Added OPP parsing from DT (need to write binding though)
 * New patches to make clk-generic.c go away
  * Made mux and divider reusable for non-MMIO devices
  * Added a mux_determine_rate_closest (not sure if this is really needed)
  * Added unregistration of muxes
 * New patch to avoid sending high frequencies down to devices using clocks

TODO:
 * Add Krait regulator voltage scaling (not strictly necessary)
 * Add some thermal awareness
 * Use efuse/eeprom API instead of hardcoding the location in the driver
 * Figure out how to express number of CPUs without relying on linux's
   concept of number of CPUs and logical CPU mapping
 * Trim down the probe code for krait-cc so that we just register clocks
   and don't enable or set rates

Stephen Boyd (13):
  ARM: Add Krait L2 register accessor functions
  clk: mux: Split out register accessors for reuse
  clk: Avoid sending high rates to downstream clocks during set_rate
  clk: Add safe switch hook
  clk: qcom: Add support for High-Frequency PLLs (HFPLLs)
  clk: qcom: Add HFPLL driver
  clk: qcom: Add MSM8960/APQ8064's HFPLLs
  clk: qcom: Add IPQ806X's HFPLLs
  clk: qcom: Add support for Krait clocks
  clk: qcom: Add KPSS ACC/GCC driver
  clk: qcom: Add Krait clock controller driver
  cpufreq: Add module to register cpufreq on Krait CPUs
  ARM: dts: qcom: Add necessary DT data for Krait cpufreq

 .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt  |   7 +
 .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt  |  28 ++
 .../devicetree/bindings/arm/msm/qcom,pvs.txt   |  38 +++
 .../devicetree/bindings/clock/qcom,hfpll.txt   |  40 +++
 .../devicetree/bindings/clock/qcom,krait-cc.txt|  22 ++
 arch/arm/boot/dts/qcom-apq8064.dtsi| 230 ++
 arch/arm/boot/dts/qcom-msm8960.dtsi 

[PATCH v3 11/13] clk: qcom: Add Krait clock controller driver

[Stephen Boyd]

The Krait CPU clocks are made up of a primary mux and secondary
mux for each CPU and the L2, controlled via cp15 accessors. For
Kraits within KPSSv1 each secondary mux accepts a different aux
source, but on KPSSv2 each secondary mux accepts the same aux
source.

Cc: 
Signed-off-by: Stephen Boyd 
---
 .../devicetree/bindings/clock/qcom,krait-cc.txt|  22 ++
 drivers/clk/qcom/Kconfig   |   8 +
 drivers/clk/qcom/Makefile  |   1 +
 drivers/clk/qcom/krait-cc.c| 352 +
 4 files changed, 383 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
 create mode 100644 drivers/clk/qcom/krait-cc.c

diff --git a/Documentation/devicetree/bindings/clock/qcom,krait-cc.txt 
b/Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
new file mode 100644
index ..874138f88ec6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
@@ -0,0 +1,22 @@
+Krait Clock Controller
+
+PROPERTIES
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,krait-cc-v1"
+   "qcom,krait-cc-v2"
+
+- #clock-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 1
+
+Example:
+
+   kraitcc: clock-controller {
+   compatible = "qcom,krait-cc-v1";
+   #clock-cells = <1>;
+   };
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 92eb883533d5..6de898c366ff 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -105,6 +105,14 @@ config KPSS_XCC
  if you want to support CPU frequency scaling on devices such
  as MSM8960, APQ8064, etc.
 
+config KRAITCC
+   tristate "Krait Clock Controller"
+   depends on COMMON_CLK_QCOM && ARM
+   select KRAIT_CLOCKS
+   help
+ Support for the Krait CPU clocks on Qualcomm devices.
+ Say Y if you want to support CPU frequency scaling.
+
 config KRAIT_CLOCKS
bool
select KRAIT_L2_ACCESSORS
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 6327dd623773..2477ce687208 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -24,3 +24,4 @@ obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
 obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
 obj-$(CONFIG_KPSS_XCC) += kpss-xcc.o
 obj-$(CONFIG_QCOM_HFPLL) += hfpll.o
+obj-$(CONFIG_KRAITCC) += krait-cc.o
diff --git a/drivers/clk/qcom/krait-cc.c b/drivers/clk/qcom/krait-cc.c
new file mode 100644
index ..f55b5ecd0df8
--- /dev/null
+++ b/drivers/clk/qcom/krait-cc.c
@@ -0,0 +1,352 @@
+/* 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 "clk-krait.h"
+
+static unsigned int sec_mux_map[] = {
+   2,
+   0,
+};
+
+static unsigned int pri_mux_map[] = {
+   1,
+   2,
+   0,
+};
+
+static int
+krait_add_div(struct device *dev, int id, const char *s, unsigned offset)
+{
+   struct krait_div2_clk *div;
+   struct clk_init_data init = {
+   .num_parents = 1,
+   .ops = &krait_div2_clk_ops,
+   .flags = CLK_SET_RATE_PARENT,
+   };
+   const char *p_names[1];
+   struct clk *clk;
+
+   div = devm_kzalloc(dev, sizeof(*div), GFP_KERNEL);
+   if (!div)
+   return -ENOMEM;
+
+   div->width = 2;
+   div->shift = 6;
+   div->lpl = id >= 0;
+   div->offset = offset;
+   div->hw.init = &init;
+
+   init.name = kasprintf(GFP_KERNEL, "hfpll%s_div", s);
+   if (!init.name)
+   return -ENOMEM;
+
+   init.parent_names = p_names;
+   p_names[0] = kasprintf(GFP_KERNEL, "hfpll%s", s);
+   if (!p_names[0]) {
+   kfree(init.name);
+   return -ENOMEM;
+   }
+
+   clk = devm_clk_register(dev, &div->hw);
+   kfree(p_names[0]);
+   kfree(init.name);
+
+   return PTR_ERR_OR_ZERO(clk);
+}
+
+static int
+krait_add_sec_mux(struct device *dev, int id, const char *s, unsigned offset,
+ bool unique_aux)
+{
+   struct krait_mux_clk *mux;
+   static const char *sec_mux_list[] = {
+   "acpu_aux",
+   "qsb",
+   };
+   struct clk_init_data init = {
+   .parent_names = sec_mux_list,
+   .num_parents 

[PATCH v5 2/3] I2C: mediatek: Add driver for MediaTek I2C controller

[Eddie Huang]

From: Xudong Chen 

The mediatek SoCs have I2C controller that handle I2C transfer.
This patch include common I2C bus driver.
This driver is compatible with I2C controller on mt65xx/mt81xx.

Signed-off-by: Xudong Chen 
Signed-off-by: Liguo Zhang 
Signed-off-by: Eddie Huang 
---
 drivers/i2c/busses/Kconfig  |   9 +
 drivers/i2c/busses/Makefile |   1 +
 drivers/i2c/busses/i2c-mt65xx.c | 705 
 3 files changed, 715 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-mt65xx.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 22da9c2..243c4ec 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -602,6 +602,15 @@ config I2C_MPC
  This driver can also be built as a module.  If so, the module
  will be called i2c-mpc.
 
+config I2C_MT65XX
+   tristate "MediaTek I2C adapter"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   help
+ This selects the MediaTek(R) Integrated Inter Circuit bus driver
+ for MT65xx and MT81xx.
+ If you want to use MediaTek(R) I2C interface, say Y or M here.
+ If unsure, say N.
+
 config I2C_MV64XXX
tristate "Marvell mv64xxx I2C Controller"
depends on MV64X60 || PLAT_ORION || ARCH_SUNXI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 3638feb..372a711 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_I2C_IOP3XX)  += i2c-iop3xx.o
 obj-$(CONFIG_I2C_KEMPLD)   += i2c-kempld.o
 obj-$(CONFIG_I2C_MESON)+= i2c-meson.o
 obj-$(CONFIG_I2C_MPC)  += i2c-mpc.o
+obj-$(CONFIG_I2C_MT65XX)   += i2c-mt65xx.o
 obj-$(CONFIG_I2C_MV64XXX)  += i2c-mv64xxx.o
 obj-$(CONFIG_I2C_MXS)  += i2c-mxs.o
 obj-$(CONFIG_I2C_NOMADIK)  += i2c-nomadik.o
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
new file mode 100644
index 000..3940112
--- /dev/null
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -0,0 +1,705 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Xudong.chen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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 
+#include 
+#include 
+
+#define I2C_HS_NACKERR (1 << 2)
+#define I2C_ACKERR (1 << 1)
+#define I2C_TRANSAC_COMP   (1 << 0)
+#define I2C_TRANSAC_START  (1 << 0)
+#define I2C_TIMING_STEP_DIV_MASK   (0x3f << 0)
+#define I2C_TIMING_SAMPLE_COUNT_MASK   (0x7 << 0)
+#define I2C_TIMING_SAMPLE_DIV_MASK (0x7 << 8)
+#define I2C_TIMING_DATA_READ_MASK  (0x7 << 12)
+#define I2C_DCM_DISABLE0x
+#define I2C_IO_CONFIG_OPEN_DRAIN   0x0003
+#define I2C_IO_CONFIG_PUSH_PULL0x
+#define I2C_SOFT_RST   0x0001
+#define I2C_FIFO_ADDR_CLR  0x0001
+#define I2C_DELAY_LEN  0x0002
+#define I2C_ST_START_CON   0x8001
+#define I2C_FS_START_CON   0x1800
+#define I2C_TIME_CLR_VALUE 0x
+#define I2C_TIME_DEFAULT_VALUE 0x0003
+#define I2C_FS_TIME_INIT_VALUE 0x1303
+#define I2C_WRRD_TRANAC_VALUE  0x0002
+#define I2C_RD_TRANAC_VALUE0x0001
+
+#define I2C_DMA_CON_TX 0x
+#define I2C_DMA_CON_RX 0x0001
+#define I2C_DMA_START_EN   0x0001
+#define I2C_DMA_INT_FLAG_NONE  0x
+#define I2C_DMA_CLR_FLAG   0x
+
+#define I2C_DEFAUT_SPEED   10  /* hz */
+#define MAX_FS_MODE_SPEED  40
+#define MAX_HS_MODE_SPEED  340
+#define MAX_MSG_NUM_MT6577 1
+#define MAX_DMA_TRANS_SIZE_MT6577  255
+#define MAX_WRRD_TRANS_SIZE_MT6577 31
+#define MAX_SAMPLE_CNT_DIV 8
+#define MAX_STEP_CNT_DIV   64
+#define MAX_HS_STEP_CNT_DIV8
+
+#define I2C_CONTROL_RS  (0x1 << 1)
+#define I2C_CONTROL_DMA_EN  (0x1 << 2)
+#define I2C_CONTROL_CLK_EXT_EN  (0x1 << 3)
+#define I2C_CONTROL_DIR_CHANGE  (0x1 << 4)
+#define I2C_CONTROL_ACKERR_DET_EN   (0x1 << 5)
+#define I2C_CONTROL_TRANSFER_LEN_CHANGE (0x1 << 6)
+#define I2C_CONTROL_WRAPPER (0x1 << 0)
+
+#define COMPAT_MT6577  (0x1 << 0)
+#define COMPAT_MT6589  (0x1 << 1)
+
+#define I2C_DRV_NAME   "mt-i2c"
+
+enu

[PATCH v5 3/3] I2C: mediatek: Add driver for MediaTek MT8173 I2C controller

[Eddie Huang]

Add mediatek MT8173 I2C controller driver. Compare to I2C controller
of earlier mediatek SoC, MT8173 fix write-then-read limitation, and
also increase message size to 64kb.

Signed-off-by: Xudong Chen 
Signed-off-by: Liguo Zhang 
Signed-off-by: Eddie Huang 
---
 drivers/i2c/busses/i2c-mt65xx.c | 107 
 1 file changed, 75 insertions(+), 32 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 3940112..17607c8 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -33,10 +33,13 @@
 #include 
 #include 
 
+#define I2C_RS_TRANSFER(1 << 4)
 #define I2C_HS_NACKERR (1 << 2)
 #define I2C_ACKERR (1 << 1)
 #define I2C_TRANSAC_COMP   (1 << 0)
 #define I2C_TRANSAC_START  (1 << 0)
+#define I2C_RS_MUL_CNFG(1 << 15)
+#define I2C_RS_MUL_TRIG(1 << 14)
 #define I2C_TIMING_STEP_DIV_MASK   (0x3f << 0)
 #define I2C_TIMING_SAMPLE_COUNT_MASK   (0x7 << 0)
 #define I2C_TIMING_SAMPLE_DIV_MASK (0x7 << 8)
@@ -67,6 +70,9 @@
 #define MAX_MSG_NUM_MT6577 1
 #define MAX_DMA_TRANS_SIZE_MT6577  255
 #define MAX_WRRD_TRANS_SIZE_MT6577 31
+#define MAX_MSG_NUM_MT8173 65535
+#define MAX_DMA_TRANS_SIZE_MT8173  65535
+#define MAX_WRRD_TRANS_SIZE_MT8173 65535
 #define MAX_SAMPLE_CNT_DIV 8
 #define MAX_STEP_CNT_DIV   64
 #define MAX_HS_STEP_CNT_DIV8
@@ -81,6 +87,7 @@
 
 #define COMPAT_MT6577  (0x1 << 0)
 #define COMPAT_MT6589  (0x1 << 1)
+#define COMPAT_MT8173  (0x1 << 2)
 
 #define I2C_DRV_NAME   "mt-i2c"
 
@@ -172,6 +179,7 @@ struct mtk_i2c {
 static const struct of_device_id mtk_i2c_of_match[] = {
{ .compatible = "mediatek,mt6577-i2c", .data = (void *)COMPAT_MT6577 },
{ .compatible = "mediatek,mt6589-i2c", .data = (void *)COMPAT_MT6589 },
+   { .compatible = "mediatek,mt8173-i2c", .data = (void *)COMPAT_MT8173 },
{}
 };
 MODULE_DEVICE_TABLE(of, mtk_i2c_match);
@@ -236,7 +244,7 @@ static inline void mtk_i2c_init_hw(struct mtk_i2c *i2c)
else
mtk_i2c_writew(I2C_IO_CONFIG_OPEN_DRAIN, i2c, OFFSET_IO_CONFIG);
 
-   if (i2c->platform_compat & COMPAT_MT6577)
+   if (i2c->platform_compat & (COMPAT_MT6577 | COMPAT_MT8173))
mtk_i2c_writew(I2C_DCM_DISABLE, i2c, OFFSET_DCM_EN);
 
mtk_i2c_writew(i2c->timing_reg, i2c, OFFSET_TIMING);
@@ -320,10 +328,12 @@ static int i2c_set_speed(struct mtk_i2c *i2c, unsigned 
int clk_src_in_hz)
return 0;
 }
 
-static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs)
+static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
+   int num, int left_num)
 {
u16 addr_reg;
u16 control_reg;
+   u16 start_reg = 0;
u16 irqstat;
dma_addr_t rpaddr = 0;
dma_addr_t wpaddr = 0;
@@ -344,6 +354,8 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs)
control_reg |= I2C_CONTROL_RS;
if (i2c->op == I2C_MASTER_WRRD)
control_reg |= I2C_CONTROL_DIR_CHANGE | I2C_CONTROL_RS;
+   if (left_num >= 1)
+   control_reg |= I2C_CONTROL_RS;
mtk_i2c_writew(control_reg, i2c, OFFSET_CONTROL);
 
/* set start condition */
@@ -361,13 +373,13 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, 
struct i2c_msg *msgs)
mtk_i2c_writew(addr_reg, i2c, OFFSET_SLAVE_ADDR);
 
/* Clear interrupt status */
-   mtk_i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP,
-   i2c, OFFSET_INTR_STAT);
+   mtk_i2c_writew(I2C_RS_TRANSFER | I2C_HS_NACKERR | I2C_ACKERR
+   | I2C_TRANSAC_COMP, i2c, OFFSET_INTR_STAT);
mtk_i2c_writew(I2C_FIFO_ADDR_CLR, i2c, OFFSET_FIFO_ADDR_CLR);
 
/* Enable interrupt */
-   mtk_i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP,
-   i2c, OFFSET_INTR_MASK);
+   mtk_i2c_writew(I2C_RS_TRANSFER | I2C_HS_NACKERR | I2C_ACKERR
+   | I2C_TRANSAC_COMP, i2c, OFFSET_INTR_MASK);
 
/* Set transfer and transaction len */
if (i2c->op == I2C_MASTER_WRRD) {
@@ -376,7 +388,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs)
mtk_i2c_writew(I2C_WRRD_TRANAC_VALUE, i2c, OFFSET_TRANSAC_LEN);
} else {
mtk_i2c_writew(msgs->len, i2c, OFFSET_TRANSFER_LEN);
-   mtk_i2c_writew(I2C_RD_TRANAC_VALUE, i2c, OFFSET_TRANSAC_LEN);
+   mtk_i2c_writew(num, i2c, OFFSET_TRANSAC_LEN);
}
 
/* Prepare buffer data to start transfer */
@@ -422,7 +434,17 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs)
/* flush before sending start */
mb

[PATCH v5 0/3] ARM: mediatek: Add driver for Mediatek I2C controller

[Eddie Huang]

This series is for Mediatek SoCs I2C controller common bus driver.

Earlier MTK SoC ((for example, MT6589, MT8135)) I2C HW has some limitationes.
New generation SoC like MT8173 fix these limitations.

1. Only support one i2c_msg number. One exception is WRRD (write then read)
mode. WRRD can have two i2c_msg numbers.

2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD
mode the Repeat Start will be issued between 2 messages.
In this driver if 2 messages is first write then read, the driver will
combine 2 messages using Write-Read mode so the RS will be issued between
the 2 messages.

3. The max transfer data length is 255 in one message. In WRRD mode, the
max data length of second msg is 31.

MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c
registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR
bit first, the operation on other registers are still the same.
For now MT6589/MT8135 support this, MT6577/MT6595/MT8127 do not support.
For example, If want to use I2C4/5/6 pins on MT8135 just need to enable
the pinmux, else if want to use I2C pins on PMIC(MT6397) need to add
"mediatek,have-pmic" property in the .dts file of each platform.

This driver is based on 4.0-rc1.

Change in v5:
Apply new i2c_adapter_quirks patch [2]. Change to use dam_map_single to map
dma buffer. Add spinlock to fix race condition. Check of_property_read_u32
return value. Remove I2C_FUNC_10BIT_ADDR capability due to driver not implement.
Add MT8173 I2C driver.

Change in v4:
Modify to support i2c_adapter_quirks base on Wolfram's patch [1].
Remove check transfer size and WRRD combine code. Instead, fill quirk
property and let i2c_check_for_quirks to do the filter.


[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/314804.html
[2] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325744.html

Eddie Huang (1):
  I2C: mediatek: Add driver for MediaTek MT8173 I2C controller

Xudong Chen (2):
  dt-bindings: Add I2C bindings for mt65xx/mt81xx.
  I2C: mediatek: Add driver for MediaTek I2C controller

 .../devicetree/bindings/i2c/i2c-mt6577.txt |  41 ++
 drivers/i2c/busses/Kconfig |   9 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-mt65xx.c| 748 +
 4 files changed, 799 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
 create mode 100644 drivers/i2c/busses/i2c-mt65xx.c

--
1.8.1.1.dirty


--
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 v5 1/3] dt-bindings: Add I2C bindings for mt65xx/mt81xx.

[Eddie Huang]

From: Xudong Chen 

Add devicetree bindings for Mediatek Soc I2C driver.

Signed-off-by: Xudong Chen 
Signed-off-by: Eddie Huang 
---
 .../devicetree/bindings/i2c/i2c-mt6577.txt | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
new file mode 100644
index 000..eff52c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
@@ -0,0 +1,41 @@
+* Mediatek's I2C controller
+
+The Mediatek's I2C controller is used to interface with I2C devices.
+
+Required properties:
+  - compatible: value should be either of the following.
+  (a) "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c.
+  (b) "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c.
+  (c) "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c.
+  (d) "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c.
+  (e) "mediatek,mt8173-i2c", for i2c compatible with mt8173 i2c.
+  - reg: physical base address of the controller and dma base, length of memory
+mapped region.
+  - interrupts: interrupt number to the cpu.
+  - clock-div: the fixed value for frequency divider of clock source in i2c
+module. Each IC may be different.
+  - clocks: clock name from clock manager
+  - clock-names: Must include "main" and "dma", if enable have-pmic need 
include
+"pmic" extra.
+
+Optional properties:
+  - clock-frequency: Frequency in Hz of the bus when transfer, the default 
value
+is 10.
+  - mediatek,have-pmic: platform can control i2c form special pmic side.
+Only mt6589 and mt8135 support this feature.
+  - mediatek,use-push-pull: IO config use push-pull mode.
+
+Example:
+
+   i2c0: i2c@1100d000 {
+   compatible = "mediatek,mt6577-i2c";
+   reg = <0x1100d000 0x70>,
+ <0x11000300 0x80>;
+   interrupts = ;
+   clock-frequency = <10>;
+   mediatek,have-pmic;
+   clock-div = <16>;
+   clocks = <&i2c0_ck>, <&ap_dma_ck>;
+   clock-names = "main", "dma";
+   };
+
-- 
1.8.1.1.dirty

--
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 06/13] musb: Add support for the Allwinner sunxi musb controller

[Chen-Yu Tsai]

Hi,

On Sat, Mar 21, 2015 at 3:11 AM, Hans de Goede  wrote:
> This is based on initial code to get the Allwinner sunxi musb controller
> supported by Chen-Yu Tsai and Roman Byshko.
>
> This adds support for the Allwinner sunxi musb controller in both host only
> and otg mode. Peripheral only mode is not supported, as no boards use that.
>
> This has been tested on a cubietruck (A20 SoC) and an UTOO P66 tablet
> (A13 SoC) with a variety of devices in host mode and with the g_serial gadget
> driver in peripheral mode, plugging otg / host cables in/out a lot of times
> in all possible imaginable plug orders.
>
> Signed-off-by: Hans de Goede 
> ---
>  .../bindings/usb/allwinner,sun4i-a10-musb.txt  |  25 +
>  drivers/usb/musb/Kconfig   |  12 +-
>  drivers/usb/musb/Makefile  |   1 +
>  drivers/usb/musb/musb_core.h   |   1 +
>  drivers/usb/musb/musb_gadget.c |   6 +
>  drivers/usb/musb/musb_virthub.c|   6 +
>  drivers/usb/musb/sunxi.c   | 671 
> +
>  7 files changed, 721 insertions(+), 1 deletion(-)
>  create mode 100644 
> Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
>  create mode 100644 drivers/usb/musb/sunxi.c
>
> diff --git 
> a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt 
> b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
> new file mode 100644
> index 000..21dfc7f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
> @@ -0,0 +1,25 @@
> +Allwinner sun4i A10 musb DRC/OTG controller
> +---
> +
> +Required properties:
> + - compatible  : "allwinner,sun4i-a10-musb"
> + - reg : mmio address range of the musb controller
> + - clocks  : clock specifier for the musb controller ahb gate clock
> + - interrupts  : interrupt to which the musb controller is connected
> + - interrupt-names : must be "mc"
> + - phys: phy specifier for the otg phy
> + - phy-names   : must be "usb"
> + - dr_mode : Dual-Role mode must be "host" or "otg"
> +
> +Example:
> +
> +   usb_otg: usb@01c13000 {
> +   compatible = "allwinner,sun4i-a10-musb";
> +   reg = <0x01c13000 0x0400>;
> +   clocks = <&ahb_gates 0>;
> +   interrupts = <38>;
> +   interrupt-names = "mc";
> +   phys = <&usbphy 0>;
> +   phy-names = "usb";
> +   status = "disabled";
> +   };
> diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
> index 14e1628..c83cad1 100644
> --- a/drivers/usb/musb/Kconfig
> +++ b/drivers/usb/musb/Kconfig
> @@ -5,7 +5,7 @@
>
>  # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller
>  config USB_MUSB_HDRC
> -   tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)'
> +   tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, AW, ...)'
> depends on (USB || USB_GADGET)
> help
>   Say Y here if your system has a dual role high speed USB
> @@ -20,6 +20,8 @@ config USB_MUSB_HDRC
>   Analog Devices parts using this IP include Blackfin BF54x,
>   BF525 and BF527.
>
> + Allwinner SoCs using this IP include A10, A13, A20, ...
> +
>   If you do not know what this is, please say N.
>
>   To compile this driver as a module, choose M here; the
> @@ -60,6 +62,14 @@ endchoice
>
>  comment "Platform Glue Layer"
>
> +config USB_MUSB_SUNXI
> +   tristate "Allwinner (sunxi)"
> +   depends on ARCH_SUNXI
> +   depends on NOP_USB_XCEIV
> +   select EXTCON
> +   select GENERIC_PHY
> +   select SUNXI_SRAM
> +
>  config USB_MUSB_DAVINCI
> tristate "DaVinci"
> depends on ARCH_DAVINCI_DMx
> diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
> index ba49501..f95befe 100644
> --- a/drivers/usb/musb/Makefile
> +++ b/drivers/usb/musb/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_USB_MUSB_DA8XX)  += da8xx.o
>  obj-$(CONFIG_USB_MUSB_BLACKFIN)+= blackfin.o
>  obj-$(CONFIG_USB_MUSB_UX500)   += ux500.o
>  obj-$(CONFIG_USB_MUSB_JZ4740)  += jz4740.o
> +obj-$(CONFIG_USB_MUSB_SUNXI)   += sunxi.o
>
>
>  obj-$(CONFIG_USB_MUSB_AM335X_CHILD)+= musb_am335x.o
> diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
> index ba8dd78..444b936 100644
> --- a/drivers/usb/musb/musb_core.h
> +++ b/drivers/usb/musb/musb_core.h
> @@ -166,6 +166,7 @@ struct musb_io;
>   */
>  struct musb_platform_ops {
>
> +#define MUSB_SUN4I BIT(7)
>  #define MUSB_DMA_UX500 BIT(6)
>  #define MUSB_DMA_CPPI41BIT(5)
>  #define MUSB_DMA_CPPI  BIT(4)
> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
> index b2d9040..7d13eb9 100644
> 

Re: [PATCH net-next 0/5] NetCP: Add support for version 1.5

[David Miller]

From: Murali Karicheri 
Date: Fri, 20 Mar 2015 16:11:20 -0400

> NetCP 1.5 is used in newer K2 SoCs from Texas Instruments
> such as K2E, K2L etc. This patch series add support for Ethss
> driver for this version of NetCP. While at it, fix couple of
> bugs in the original driver.
> 
> One of the earlier patch "net: netcp: select davinci_mdio driver
> by default" is folded onto this series.
> 
> Please review and let me know your comments.

Series applied to net-next, thanks.
--
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 v4] dt-bindings: brcm: rationalize Broadcom documentation naming

[Scott Branden]

This patchset attempts to standardize the naming of dt-bindings
documents based on the Broadcom vendor prefix of brcm.

Although there are no guidelines currently present for how to name
the dt-bindings document the "vendor,binding.txt" style is in use by
some of the other vendors.

Acked-by: Lee Jones 
Acked-by: Florian Fainelli 
Acked-by: Gregory Fong 
Acked-by: Stephen Warren 
Signed-off-by: Scott Branden 
---
 .../arm/bcm/{brcm,bcm11351-cpu-method => brcm,bcm11351-cpu-method.txt}| 0
 .../devicetree/bindings/arm/bcm/{bcm11351.txt => brcm,bcm11351.txt}   | 0
 .../devicetree/bindings/arm/bcm/{bcm21664.txt => brcm,bcm21664.txt}   | 0
 .../devicetree/bindings/arm/{bcm2835.txt => bcm/brcm,bcm2835.txt} | 0
 .../devicetree/bindings/arm/{bcm4708.txt => bcm/brcm,bcm4708.txt} | 0
 .../devicetree/bindings/arm/bcm/{bcm63138.txt => brcm,bcm63138.txt}   | 0
 .../devicetree/bindings/arm/{brcm-brcmstb.txt => bcm/brcm,brcmstb.txt}| 0
 Documentation/devicetree/bindings/arm/bcm/{cygnus.txt => brcm,cygnus.txt} | 0
 Documentation/devicetree/bindings/bus/{bcma.txt => brcm,bus-axi.txt}  | 0
 .../devicetree/bindings/clock/{bcm-kona-clock.txt => brcm,kona-ccu.txt}   | 0
 .../devicetree/bindings/dma/{bcm2835-dma.txt => brcm,bcm2835-dma.txt} | 0
 .../devicetree/bindings/gpio/{gpio-bcm-kona.txt => brcm,kona-gpio.txt}| 0
 .../devicetree/bindings/i2c/{i2c-bcm-kona.txt => brcm,kona-i2c.txt}   | 0
 Documentation/devicetree/bindings/mfd/{bcm590xx.txt => brcm,bcm59056.txt} | 0
 .../bindings/mips/brcm/{bcm3384-intc.txt => brcm,bcm3384-intc.txt}| 0
 Documentation/devicetree/bindings/mips/brcm/{bmips.txt => brcm,bmips.txt} | 0
 .../devicetree/bindings/mips/brcm/{cm-dsl.txt => brcm,cm-dsl.txt} | 0
 Documentation/devicetree/bindings/misc/{smc.txt => brcm,kona-smc.txt} | 0
 .../devicetree/bindings/mmc/{kona-sdhci.txt => brcm,kona-sdhci.txt}   | 0
 .../bindings/net/{broadcom-sf2.txt => brcm,bcm7445-switch-v4.0.txt}   | 0
 .../devicetree/bindings/net/{broadcom-bcmgenet.txt => brcm,bcmgenet.txt}  | 0
 .../bindings/net/{broadcom-systemport.txt => brcm,systemport.txt} | 0
 .../bindings/net/{broadcom-mdio-unimac.txt => brcm,unimac-mdio.txt}   | 0
 .../devicetree/bindings/phy/{bcm-phy.txt => brcm,kona-usb2-phy.txt}   | 0
 .../devicetree/bindings/pwm/{bcm-kona-pwm.txt => brcm,kona-pwm.txt}   | 0
 .../{arm/bcm/kona-resetmgr.txt => reset/brcm,bcm21664-resetmgr.txt}   | 0
 .../bindings/serial/{bcm63xx-uart.txt => brcm,bcm6345-uart.txt}   | 0
 .../devicetree/bindings/sound/{bcm2835-i2s.txt => brcm,bcm2835-i2s.txt}   | 0
 .../bindings/{arm/bcm/kona-timer.txt => timer/brcm,kona-timer.txt}| 0
 .../devicetree/bindings/{mips/brcm/usb.txt => usb/brcm,bcm3384-usb.txt}   | 0
 .../bindings/{arm/bcm/kona-wdt.txt => watchdog/brcm,kona-wdt.txt} | 0
 31 files changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/arm/bcm/{brcm,bcm11351-cpu-method => 
brcm,bcm11351-cpu-method.txt} (100%)
 rename Documentation/devicetree/bindings/arm/bcm/{bcm11351.txt => 
brcm,bcm11351.txt} (100%)
 rename Documentation/devicetree/bindings/arm/bcm/{bcm21664.txt => 
brcm,bcm21664.txt} (100%)
 rename Documentation/devicetree/bindings/arm/{bcm2835.txt => 
bcm/brcm,bcm2835.txt} (100%)
 rename Documentation/devicetree/bindings/arm/{bcm4708.txt => 
bcm/brcm,bcm4708.txt} (100%)
 rename Documentation/devicetree/bindings/arm/bcm/{bcm63138.txt => 
brcm,bcm63138.txt} (100%)
 rename Documentation/devicetree/bindings/arm/{brcm-brcmstb.txt => 
bcm/brcm,brcmstb.txt} (100%)
 rename Documentation/devicetree/bindings/arm/bcm/{cygnus.txt => 
brcm,cygnus.txt} (100%)
 rename Documentation/devicetree/bindings/bus/{bcma.txt => brcm,bus-axi.txt} 
(100%)
 rename Documentation/devicetree/bindings/clock/{bcm-kona-clock.txt => 
brcm,kona-ccu.txt} (100%)
 rename Documentation/devicetree/bindings/dma/{bcm2835-dma.txt => 
brcm,bcm2835-dma.txt} (100%)
 rename Documentation/devicetree/bindings/gpio/{gpio-bcm-kona.txt => 
brcm,kona-gpio.txt} (100%)
 rename Documentation/devicetree/bindings/i2c/{i2c-bcm-kona.txt => 
brcm,kona-i2c.txt} (100%)
 rename Documentation/devicetree/bindings/mfd/{bcm590xx.txt => 
brcm,bcm59056.txt} (100%)
 rename Documentation/devicetree/bindings/mips/brcm/{bcm3384-intc.txt => 
brcm,bcm3384-intc.txt} (100%)
 rename Documentation/devicetree/bindings/mips/brcm/{bmips.txt => 
brcm,bmips.txt} (100%)
 rename Documentation/devicetree/bindings/mips/brcm/{cm-dsl.txt => 
brcm,cm-dsl.txt} (100%)
 rename Documentation/devicetree/bindings/misc/{smc.txt => brcm,kona-smc.txt} 
(100%)
 rename Documentation/devicetree/bindings/mmc/{kona-sdhci.txt => 
brcm,kona-sdhci.txt} (100%)
 rename Documentation/devicetree/bindings/net/{broadcom-sf2.txt => 
brcm,bcm7445-switch-v4.0.txt} (100%)
 rename Documentation/devicetree/bindings/net/{broadcom-bcmgenet.txt => 
brcm,bcmgenet.txt} (100%)
 rename Documentation/devicetree/bindings/net/{broadcom-systemport.txt => 
brcm,sy

[PATCH v5 2/2] Input: touchscreen-iproc: add device tree bindings

[Jonathan Richardson]

Documents the touchscreen device tree binding for Broadcom iProc family
of SoCs.

Reviewed-by: Scott Branden 
Tested-by: Scott Branden 
Signed-off-by: Jonathan Richardson 
---
 .../input/touchscreen/brcm,iproc-touchscreen.txt   |   76 
 1 file changed, 76 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt

diff --git 
a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
 
b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
new file mode 100644
index 000..34e3382
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
@@ -0,0 +1,76 @@
+* Broadcom's IPROC Touchscreen Controller
+
+Required properties:
+- compatible: must be "brcm,iproc-touchscreen"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- clocks:  The clock provided by the SOC to driver the tsc
+- clock-name:  name for the clock
+- interrupts: The touchscreen controller's interrupt
+
+Optional properties:
+- scanning_period: Time between scans. Each step is 1024 us.  Valid 1-256.
+- debounce_timeout: Each step is 512 us.  Valid 0-255
+- settling_timeout: The settling duration (in ms) is the amount of time
+the tsc waits to allow the voltage to settle after
+turning on the drivers in detection mode.
+Valid values: 0-11
+0 =  0.008 ms
+1 =  0.01 ms
+2 =  0.02 ms
+3 =  0.04 ms
+4 =  0.08 ms
+5 =  0.16 ms
+6 =  0.32 ms
+7 =  0.64 ms
+8 =  1.28 ms
+9 =  2.56 ms
+   10 =  5.12 ms
+   11 = 10.24 ms
+- touch_timeout: The continuous number of scan periods in which touch is
+not detected before the controller returns to idle state.
+Valid values 0-255.
+- average_data: Number of data samples which are averaged before a final
+data point is placed into the FIFO
+Valid values 0-7
+0 =   1 sample
+1 =   2 samples
+2 =   4 samples
+3 =   8 samples
+4 =  16 samples
+5 =  32 samples
+6 =  64 samples
+7 = 128 samples
+- fifo_threshold: Interrupt is generated whenever the number of fifo
+entries exceeds this value
+Valid values 0-31
+- touchscreen-size-x: horizontal resolution of touchscreen (in pixels)
+- touchscreen-size-y: vertical resolution of touchscreen (in pixels)
+- touchscreen-fuzz-x: horizontal noise value of the absolute input
+  device (in pixels)
+- touchscreen-fuzz-y: vertical noise value of the absolute input
+  device (in pixels)
+- touchscreen-inverted-x: X axis is inverted (boolean)
+- touchscreen-inverted-y: Y axis is inverted (boolean)
+
+Example:
+
+   touchscreen: tsc@0x180A6000 {
+   compatible = "brcm,iproc-touchscreen";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x180A6000 0x40>;
+   clocks = <&adc_clk>;
+   clock-names = "tsc_clk";
+   interrupts = ;
+
+   scanning_period = <5>;
+   debounce_timeout = <40>;
+   settling_timeout = <7>;
+   touch_timeout = <10>;
+   average_data = <5>;
+   fifo_threshold = <1>;
+   /* Touchscreen is rotated 180 degrees. */
+   touchscreen-inverted-x;
+   touchscreen-inverted-y;
+   };
-- 
1.7.9.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 v5 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver

[Jonathan Richardson]

Add initial version of the Broadcom touchscreen driver.

Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Tested-by: Scott Branden 
Signed-off-by: Jonathan Richardson 
---
 drivers/input/touchscreen/Kconfig |   11 +
 drivers/input/touchscreen/Makefile|1 +
 drivers/input/touchscreen/bcm_iproc_tsc.c |  518 +
 3 files changed, 530 insertions(+)
 create mode 100644 drivers/input/touchscreen/bcm_iproc_tsc.c

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 6261fd6..4a8b0e5 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -323,6 +323,17 @@ config TOUCHSCREEN_ILI210X
  To compile this driver as a module, choose M here: the
  module will be called ili210x.
 
+config TOUCHSCREEN_IPROC
+   tristate "IPROC touch panel driver support"
+   help
+ Say Y here if you want to add support for the IPROC touch
+ controller to your system.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bcm_iproc_tsc.
+
 config TOUCHSCREEN_S3C2410
tristate "Samsung S3C2410/generic touchscreen input driver"
depends on ARCH_S3C24XX || SAMSUNG_DEV_TS
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 0242fea..68f69bc 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_TOUCHSCREEN_GOODIX)  += goodix.o
 obj-$(CONFIG_TOUCHSCREEN_ILI210X)  += ili210x.o
 obj-$(CONFIG_TOUCHSCREEN_INEXIO)   += inexio.o
 obj-$(CONFIG_TOUCHSCREEN_INTEL_MID)+= intel-mid-touch.o
+obj-$(CONFIG_TOUCHSCREEN_IPROC)+= bcm_iproc_tsc.o
 obj-$(CONFIG_TOUCHSCREEN_LPC32XX)  += lpc32xx_ts.o
 obj-$(CONFIG_TOUCHSCREEN_MAX11801) += max11801_ts.o
 obj-$(CONFIG_TOUCHSCREEN_MC13783)  += mc13783_ts.o
diff --git a/drivers/input/touchscreen/bcm_iproc_tsc.c 
b/drivers/input/touchscreen/bcm_iproc_tsc.c
new file mode 100644
index 000..c02a015
--- /dev/null
+++ b/drivers/input/touchscreen/bcm_iproc_tsc.c
@@ -0,0 +1,518 @@
+/*
+* Copyright (C) 2015 Broadcom Corporation
+*
+* 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 version 2.
+*
+* This program is distributed "as is" WITHOUT ANY WARRANTY of any
+* kind, whether express or implied; 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 
+
+#define IPROC_TS_NAME "iproc-ts"
+
+#define PEN_DOWN_STATUS 1
+#define PEN_UP_STATUS   0
+
+#define X_MIN   0
+#define Y_MIN   0
+#define X_MAX   0xFFF
+#define Y_MAX   0xFFF
+
+/* Value given by controller for invalid coordinate. */
+#define INVALID_COORD   0x
+
+/* Register offsets */
+#define REGCTL1 0x00
+#define REGCTL2 0x04
+#define INTERRUPT_THRES 0x08
+#define INTERRUPT_MASK  0x0c
+
+#define INTERRUPT_STATUS0x10
+#define CONTROLLER_STATUS   0x14
+#define FIFO_DATA   0x18
+#define FIFO_DATA_X_Y_MASK  0x
+#define ANALOG_CONTROL  0x1c
+
+#define AUX_DATA0x20
+#define DEBOUNCE_CNTR_STAT  0x24
+#define SCAN_CNTR_STAT  0x28
+#define REM_CNTR_STAT   0x2c
+
+#define SETTLING_TIMER_STAT 0x30
+#define SPARE_REG   0x34
+#define SOFT_BYPASS_CONTROL 0x38
+#define SOFT_BYPASS_DATA0x3c
+
+
+/* Bit values for INTERRUPT_MASK and INTERRUPT_STATUS regs */
+#define TS_PEN_INTR_MASKBIT(0)
+#define TS_FIFO_INTR_MASK   BIT(2)
+
+/* Bit values for CONTROLLER_STATUS reg1 */
+#define TS_PEN_DOWN BIT(0)
+
+/* Shift values for control reg1 */
+#define SCANNING_PERIOD_SHIFT   24
+#define DEBOUNCE_TIMEOUT_SHIFT  16
+#define SETTLING_TIMEOUT_SHIFT  8
+#define TOUCH_TIMEOUT_SHIFT 0
+
+/* Shift values for coordinates from fifo */
+#define X_COORD_SHIFT  0
+#define Y_COORD_SHIFT  16
+
+/* Bit values for REGCTL2 */
+#define TS_CONTROLLER_EN_BITBIT(16)
+#define TS_CONTROLLER_AVGDATA_SHIFT 8
+#define TS_CONTROLLER_AVGDATA_MASK (0x7 << TS_CONTROLLER_AVGDATA_SHIFT)
+#define TS_CONTROLLER_PWR_LDO   BIT(5)
+#define TS_CONTROLLER_PWR_ADC   BIT(4)
+#define TS_CONTROLLER_PWR_BGP   BIT(3)
+#define TS_CONTROLLER_PWR_TSBIT(2)
+#define TS_WIRE_MODE_BITBIT(1)
+
+#define dbg_reg(dev, priv, reg) \
+   dev_dbg(dev, "%20s= 0x%08x\n", #reg, readl((priv)->regs + reg))
+
+struct tsc_param {
+   /* Each step is 1024 us.  Valid 1-256 */
+   u32 scanning_period;
+
+   /*  Each step is 512 us.  Valid 0-255 */
+   u32 debounce_timeout;
+
+   /*
+* The settling 

[PATCH v5 0/2] Add support for Broadcom iProc touchscreen

[Jonathan Richardson]

This patchset contains initial support for the touchscreen on the Broadcom
iProc family of SoCs. This driver has been validated with Cygnus and is expected
to work on other iProc family of SoCs that use the same touchscreen controller.

Changes from v4:
- Debug code cleanup.
- pdev wasn't initialized prior to calling get_tsc_config() in probe resulting
  in null dev pointer being passed to the function.

Changes from v3:
- Fixed typo in Kconfig.

Changes from v2:
- Misc style changes.
- Removed assumptions about interrupts generated in ISR. It now emits all
  events and then syncs if necessary.
- Removed our rotation property and replaced with the latest
  touchscreen-inverted-x/y. Also added support for the standard optional
  properties touchscreen-size-x/y and touchscreen-fuzz-x/y. Did not add support
  for inverted-x/y at this time as our touchscreen is currently only oriented
  180 degres.

Changes from v1:
- Add missing newlines to debug messages
- Use BIT macro for defines
- Fix logic in get_tsc_config to improve readability
- Get rid of unnecessary remove() function

Jonathan Richardson (2):
  Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver
  Input: touchscreen-iproc: add device tree bindings

 .../input/touchscreen/brcm,iproc-touchscreen.txt   |   76 +++
 drivers/input/touchscreen/Kconfig  |   11 +
 drivers/input/touchscreen/Makefile |1 +
 drivers/input/touchscreen/bcm_iproc_tsc.c  |  518 
 4 files changed, 606 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
 create mode 100644 drivers/input/touchscreen/bcm_iproc_tsc.c

-- 
1.7.9.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 V3 3/7] of: Document {little,big,native}-endian bindings

[Grant Likely]

On Mon, 2 Mar 2015 10:57:41 -0800
, Kevin Cernekee 
 wrote:
> On Mon, Mar 2, 2015 at 9:45 AM, Peter Hurley  wrote:
> >> This doesn't change the behavior of pre-existing drivers that
> >> implement the *-endian properties in a different way.  There are not
> >> many of these drivers and they can be documented as special cases.
> >
> > Yeah, ok, as long as there's no expectation that existing drivers
> > meet this criteria when they add big-endian support.
> 
> The intention is to make it easy for existing drivers with LE register
> accesses (i.e. mostly drivers taken from an x86 + PCI environment) to
> work on systems with native to BE register accesses.  8250 and USB are
> the first two examples of this.

I think the right solution here is to drop any specified default in the
common properties binding and replace with something like, "If a binding
supports these properties, then that binding should also specify the
default if none of these properties are present. In such cases,
little-endian is the preferred default, but it is not a requirement"

g.
--
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: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[NeilBrown]

On Fri, 20 Mar 2015 10:34:18 +0100 "Dr. H. Nikolaus Schaller"
 wrote:

> 
> Am 20.03.2015 um 09:54 schrieb NeilBrown :

> > There needs to be one device-node for each device, and that device-node 
> > needs
> > to be a child of the device-node for the device which is the primary
> > connection to the child device.
> 
> Then please explain to me nodes like
> 
> / {
>   compatible = "ti,omap3-gta04", "ti,omap36xx", "ti,omap3";
> 
>   cpus {
>   cpu@0 {
>   cpu0-supply = <&vcc>;
>   };
>   };
> 
> According to the rule you apply here it should be something like
> 
>   cpu@0 {
>   regulator {
>   …
>   }
> 
> 

This exactly highlight one of the big problems with device tree as I see it.

Each device can potentially have relationships with a number of other
devices, for the supply of power, reset signalling, interrupt handled, data
transfer, command transfer etc etc etc.

devicetree provides two ways to indicated a relationship between devices.
One way is a parent/child arrangement.  The other way is ad-hoc
   attribute = <&devicename>
assignments.

Each device can only have one parent, but can have multiple arbitrary
assignments.

I would much rather that the parent/child relationship didn't exist at all.
Each device should stand alone, and list all relationships explicitly.  But
that is not the way devicetree works, and we need to live with that.

So we need a clear understanding of what the 'parent' of a given device
should be.
I don't know what the specifications say, if anything, but what I see is that
the parent is in practive a device which can 'address' the child.  i.e.
control signalling is the key parent->child relationship.
This is consistent with the fact that many device nodes have a 
reg=
attribute which gives the address of the node as seen by it's parent.

Given that understanding, a regulator must be a child of the device which can
control it - which can turn it on or off.  Not a child of the device which
receives power from it.

In the case of our GPS, it receives control over the serial connection from
the UART, also receives control via a GPIO to the on/off pin, and also needs
a regulator to power the antenna.

So should the parent be the uart, the on/off GPIO, or the regulator?

I would much rather there wasn't a parent, and that each of these were listed
as ad-hoc attribute assignments.  But device-tree says there must be a parent
(where possible), and the parent is the thing that is "primarily" in control.

I think the GPS is "primarily" a uart-attached device.
So I propose a device-node which describes the GPS, which is a child of the
UART, and explicitly identifies the GPIO it uses to power on/off, the
regulator it uses to power the antenna, and how it receives "on or off"
status indications from the GPS.

It is arguable that the "antenna" should be treated as a separate device - a
child of the GPS - which controls the regulator and also provides a 'extcon'
which reports whether an external GPS antenna is attached, or whether the
internal on is in use.  I haven't made the time to properly explore that
issue yet.

> >> 
> >> All the following is very special logic for the w2sg0004 chip which should 
> >> be
> >> divided out into a separate driver.
> >> 
> >> Marek and me already had proposed such a chip specific driver (to be 
> >> located
> >> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
> >> specific and present itself as a regulator (because that is its main 
> >> purpose:
> >> control the LDO regulator inside the w2sg0004 chip).
> > 
> > Presenting itself as a regulator would be wrong because it isn’t a 
> > regulator.
> 
> It has a regulator that can be controlled by a gpio…

Does it?  I guess may it does.
Maybe it also has an ARM core and some memory and assorted other bits and
pieces.  But we don't really need to describe them to device tree.

The w2sg0004 is primarily a GPS device, so that needs to be stated in the
devices tree description.  If there are subcomponents that can usefully be
described as well then there could be a place to describe those subcomponents.
I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
1V8 source based on its 3V3 input.  If a board made use of that, it could be
useful to describe the regulator inside the GPS so it could be declare that
some other device which needed 1V8 made use of that regulator

> 
> Another example to think about: the twl4030 is also not a regulator.
> Nevertheless they present some regulator nodes.

The TWL4030 is a multifunction device which contains regulators and GPIOs and
audio codec and  USB PHY etc etc etc.

So in device-tree there is a device-node for the TWL4030, and it has
child-nodes for each sub-device.   They in turn can provide services to other
devices on the board.
These sub-devices are much more independent of the whole than the regulat

Re: [PATCH 4/5] phy: add Broadcom SATA3 PHY driver for Broadcom STB SoCs

[Florian Fainelli]

On 18/03/15 18:23, Brian Norris wrote:
> Supports up to two ports which can each be powered on/off and configured
> independently.
> 
> Signed-off-by: Brian Norris 
> ---

[snip]

> +
> +static const struct of_device_id brcmstb_sata_phy_of_match[] = {
> + { .compatible   = "brcm,bcm7445-sata-phy" },

The binding document specifies "brcm,phy-sata3" as a fallback compatible
string, so we want to match it here.

[snip]

> +
> + dev_info(dev, "registered %d ports\n", count);

"registered %d port(s)" ;)
-- 
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 3/5] ata: add Broadcom AHCI SATA3 driver for STB chips

[Florian Fainelli]

On 18/03/15 18:23, Brian Norris wrote:
> Pretty straightforward driver, using the nice library-ization of the
> generic ahci_platform driver.
> 
> Signed-off-by: Brian Norris 
> ---
>  drivers/ata/Kconfig|   9 +++
>  drivers/ata/Makefile   |   1 +
>  drivers/ata/sata_brcmstb.c | 148 
> +
>  3 files changed, 158 insertions(+)
>  create mode 100644 drivers/ata/sata_brcmstb.c
> 
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index 5f601553b9b0..33d4b3031705 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -98,6 +98,15 @@ config SATA_AHCI_PLATFORM
>  
> If unsure, say N.
>  
> +config SATA_BRCMSTB
> + tristate "Broadcom STB AHCI SATA support"
> + depends on ARCH_BRCMSTB

We would probably want a select PHY_BRCMSTB_SATA here?

[snip]

> +
> +static void brcm_sata3_init_config(struct brcm_ahci_priv *priv)
> +{
> + /* Configure endianness */
> + writel((DATA_ENDIAN << 4) | (DATA_ENDIAN << 2) | (MMIO_ENDIAN << 0),
> + priv->top_ctrl + SATA_TOP_CTRL_BUS_CTRL);

AFAIR, this portion of the initialization must be done in the host-CPU
native endianness, so __raw_writel() would be more appropriate, or we
could use Kevin's conditional I/O accessors and do either ioread32() or
ioread32be() based on the absence/presence of the "big-endian" property?


[snip]

> +
> +static const struct of_device_id ahci_of_match[] = {
> + {.compatible = "brcm,sata3-ahci"},

The binding specifies brcm,bcm7445-ahci as a valid compatible string,
such that we would probably want to match it here for consistency.
-- 
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 1/3] ARM: dts: OMAP5+: separate the cpu thermal zone definition from omap4

[Eduardo Valentin]

On Fri, Mar 20, 2015 at 02:47:39PM -0500, Nishanth Menon wrote:
> From: Tero Kristo 
> 
> OMAP4 has a finer counter granularity, which allows for a delay of 1000ms
> in the thermal zone polling intervals. OMAP5/DRA7 have different counter
> mechanism, which allows at maximum a 500ms timer. Adjust the cpu thermal
> zone accordingly for OMAP5/DRA7.
> 
> Signed-off-by: Tero Kristo 
> Signed-off-by: Nishanth Menon 


> ---
>  arch/arm/boot/dts/omap5-cpu-thermal.dtsi |   41 
> ++
>  arch/arm/boot/dts/omap5.dtsi |2 +-
>  2 files changed, 42 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/omap5-cpu-thermal.dtsi
> 
> diff --git a/arch/arm/boot/dts/omap5-cpu-thermal.dtsi 
> b/arch/arm/boot/dts/omap5-cpu-thermal.dtsi
> new file mode 100644
> index ..4a6427c1e47e
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap5-cpu-thermal.dtsi
> @@ -0,0 +1,41 @@
> +/*
> + * Device Tree Source for OMAP4/5 SoC CPU thermal
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> + * Contact: Tero Kristo 
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include 
> +
> +cpu_thermal: cpu_thermal {
> + polling-delay-passive = <250>; /* milliseconds */
> + polling-delay = <500>; /* milliseconds */
> +
> + /* sensor   ID */
> + thermal-sensors = <&bandgap 0>;
> +
> + cpu_trips: trips {
> + cpu_alert0: cpu_alert {
> + temperature = <10>; /* millicelsius */
> + hysteresis = <2000>; /* millicelsius */
> + type = "passive";
> + };
> + cpu_crit: cpu_crit {
> + temperature = <125000>; /* millicelsius */
> + hysteresis = <2000>; /* millicelsius */
> + type = "critical";
> + };
> + };
> +
> + cpu_cooling_maps: cooling-maps {
> + map0 {
> + trip = <&cpu_alert0>;
> + cooling-device =
> + <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index ddff674bd05e..e650d4eb59dd 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -67,7 +67,7 @@
>   };
>  
>   thermal-zones {
> - #include "omap4-cpu-thermal.dtsi"
> + #include "omap5-cpu-thermal.dtsi"

Can't we simple change the polling value for the omap5 case and reuse
the omap4 file?

>   #include "omap5-gpu-thermal.dtsi"
>   #include "omap5-core-thermal.dtsi"
>   };
> -- 
> 1.7.9.5
> 


signature.asc
Description: Digital signature

Re: [PATCH 2/3] ARM: dts: DRA7: Add bandgap and related thermal nodes

[Eduardo Valentin]

On Fri, Mar 20, 2015 at 02:47:40PM -0500, Nishanth Menon wrote:
> From: Keerthy 
> 
> Add bandgap and related thermal nodes. The patch adds 5 thermal
> sensors. Only one cooling device for mpu as of now. The sensors are
> the exact same on both dra72 and dra7.
> 
> Signed-off-by: Keerthy 
> Signed-off-by: Nishanth Menon 

Acked-by: Eduardo Valentin 

> ---
>  arch/arm/boot/dts/dra7.dtsi   |   12 
>  arch/arm/boot/dts/dra72x.dtsi |9 +
>  arch/arm/boot/dts/dra74x.dtsi |9 +
>  3 files changed, 30 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index eea4a54d6cb3..4b975cc377fd 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -177,6 +177,18 @@
>   };
>   };
>  
> + bandgap: bandgap@4a0021e0 {
> + reg = <0x4a0021e0 0xc
> + 0x4a00232c 0xc
> + 0x4a002380 0x2c
> + 0x4a0023C0 0x3c
> + 0x4a002564 0x8
> + 0x4a002574 0x50>;
> + compatible = "ti,dra752-bandgap";
> + interrupts = ;
> + #thermal-sensor-cells = <1>;
> + };
> +
>   cm_core_aon: cm_core_aon@4a005000 {
>   compatible = "ti,dra7-cm-core-aon";
>   reg = <0x4a005000 0x2000>;
> diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
> index e5a3d23a3df1..43bd0709bde9 100644
> --- a/arch/arm/boot/dts/dra72x.dtsi
> +++ b/arch/arm/boot/dts/dra72x.dtsi
> @@ -20,6 +20,11 @@
>   device_type = "cpu";
>   compatible = "arm,cortex-a15";
>   reg = <0>;
> +
> + /* cooling options */
> + cooling-min-level = <0>;
> + cooling-max-level = <2>;
> + #cooling-cells = <2>; /* min followed by max */
>   };
>   };
>  
> @@ -27,4 +32,8 @@
>   compatible = "arm,cortex-a15-pmu";
>   interrupts = ;
>   };
> +
> + thermal_zones: thermal-zones {
> + #include "omap5-cpu-thermal.dtsi"
> + };
>  };
> diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
> index 10173fab1a15..4f2c870836fe 100644
> --- a/arch/arm/boot/dts/dra74x.dtsi
> +++ b/arch/arm/boot/dts/dra74x.dtsi
> @@ -31,6 +31,11 @@
>   clock-names = "cpu";
>  
>   clock-latency = <30>; /* From omap-cpufreq driver */
> +
> + /* cooling options */
> + cooling-min-level = <0>;
> + cooling-max-level = <2>;
> + #cooling-cells = <2>; /* min followed by max */
>   };
>   cpu@1 {
>   device_type = "cpu";
> @@ -45,6 +50,10 @@
>;
>   };
>  
> + thermal_zones: thermal-zones {
> + #include "omap5-cpu-thermal.dtsi"
> + };
> +
>   ocp {
>   omap_dwc3_4: omap_dwc3_4@4894 {
>   compatible = "ti,dwc3";
> -- 
> 1.7.9.5
> 


signature.asc
Description: Digital signature

Re: [PATCH 3/3] ARM: dts: am57xx-beagle-x15: Add thermal map

[Eduardo Valentin]

On Fri, Mar 20, 2015 at 02:47:41PM -0500, Nishanth Menon wrote:
> BeagleBoard-X15 has capability for a fan and has an onboard TMP102
> temperature sensor as well. This allows us to create a new thermal
> zone (called, un-imaginatively "board"), and allows us to use some
> active cooling as temperatures start edge upward in the system by
> creating a new alert temperature (emperically 50C) for cpu.
> 
> NOTE: Fan is NOT mounted by default on the platform, in such a case,
> all we end up doing is switch on a regulator and leak very minimal
> current.
> 
> Signed-off-by: Nishanth Menon 

Acked-by: Eduardo Valentin 

> ---
>  arch/arm/boot/dts/am57xx-beagle-x15.dts |   49 
> +++
>  1 file changed, 49 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> index 41642fe770a1..6a3621c23017 100644
> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> @@ -86,6 +86,7 @@
>   gpios =  <&tps659038_gpio 1 GPIO_ACTIVE_HIGH>;
>   gpio-fan,speed-map = <0 0>,
><13000 1>;
> + #cooling-cells = <2>;
>   };
>  
>   extcon_usb1: extcon_usb1 {
> @@ -441,6 +442,7 @@
>   pinctrl-0 = <&tmp102_pins_default>;
>   interrupt-parent = <&gpio7>;
>   interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
> + #thermal-sensor-cells = <1>;
>   };
>  };
>  
> @@ -559,3 +561,50 @@
>  &usb2 {
>   dr_mode = "peripheral";
>  };
> +
> +&cpu_trips {
> + cpu_alert1: cpu_alert1 {
> + temperature = <5>; /* millicelsius */
> + hysteresis = <2000>; /* millicelsius */
> + type = "active";
> + };
> +};
> +
> +&cpu_cooling_maps {
> + map1 {
> + trip = <&cpu_alert1>;
> + cooling-device = <&gpio_fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> +};
> +
> +&thermal_zones {
> + board_thermal: board_thermal {
> + polling-delay-passive = <1250>; /* milliseconds */
> + polling-delay = <1500>; /* milliseconds */
> +
> + /* sensor   ID */
> + thermal-sensors = <&tmp102 0>;
> +
> + board_trips: trips {
> + board_alert0: board_alert {
> + temperature = <4>; /* millicelsius */
> + hysteresis = <2000>; /* millicelsius */
> + type = "active";
> + };
> +
> + board_crit: board_crit {
> + temperature = <105000>; /* millicelsius */
> + hysteresis = <0>; /* millicelsius */
> + type = "critical";
> + };
> + };
> +
> + board_cooling_maps: cooling-maps {
> + map0 {
> + trip = <&board_alert0>;
> + cooling-device =
> +   <&gpio_fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> +   };
> +};
> -- 
> 1.7.9.5
> 


signature.asc
Description: Digital signature

[GIT PULL] DeviceTree fixes for 4.0

[Rob Herring]

Hi Linus,

Please pull some more DT fixes for 4.0.

Rob

The following changes since commit 06e5801b8cb3fc057d88cb4dc03c0b64b2744cda:

  Linux 4.0-rc4 (2015-03-15 17:38:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
tags/devicetree-fixes-for-4.0-part2

for you to fetch changes up to f64255b5072d9c46cef8655d51cf7e10285abed7:

  Revert "of: Fix premature bootconsole disable with 'stdout-path'"
(2015-03-19 08:46:54 -0500)


More DeviceTree fixes for 4.0:

- Revert setting stdout-path as preferred console. This caused
regressions in PowerMACs and other systems.

- Yet another fix for stdout-path option parsing.

- Fix error path handling in of_irq_parse_one


Brian Norris (2):
  of: unittest: Add option string test case with longer path
  of: handle both '/' and ':' in path strings

Laurent Pinchart (1):
  of/irq: Fix of_irq_parse_one() returned error codes

Peter Hurley (1):
  Revert "of: Fix premature bootconsole disable with 'stdout-path'"

 drivers/of/base.c | 11 ++-
 drivers/of/irq.c  | 10 +++---
 drivers/of/unittest.c |  5 +
 3 files changed, 14 insertions(+), 12 deletions(-)
--
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 v7 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Andy Gross]

On Fri, Mar 20, 2015 at 01:49:12PM -0700, Bjorn Andersson wrote:
> On Fri 20 Mar 13:29 PDT 2015, Andy Gross wrote:
> 
> > On Thu, Mar 19, 2015 at 06:48:10PM -0700, Bjorn Andersson wrote:
> > 
> > 
> > 
> > > +Example:
> > > +
> > > + tcsr: syscon@1a40 {
> > 
> > typo here, syscon@fd484000.  And this syscon is specifically for the tcsr 
> > mutex
> > reg area.
> > 
> 
> You're right, I didn't read the documentation good enough; let's name it
> tcsr-mutex and as this is not the main tcsr region we should fall back
> to just having syscon as compatible.

Agreed.  A generic syscon will work until we need to support the other registers
in that block.

> But there's still a bunch of other registers in the tcsr-mutex range -
> that probably will be consumed by various drivers, so it still makes
> sense to have a syscon there.

Agreed.

-- 
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

[PATCH] ASoC:pcm512x: Make PLL lock output selectable via device tree.

[Howard Mitchell]

Currently the PLL Lock output signal is hardcoded to GPIO4. This
makes it seletable in the same way as pll-in and pll-out.

Signed-off-by: Howard Mitchell 
---
 .../devicetree/bindings/sound/pcm512x.txt  |3 ++
 sound/soc/codecs/pcm512x.c |   47 +---
 2 files changed, 33 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/pcm512x.txt 
b/Documentation/devicetree/bindings/sound/pcm512x.txt
index 3aae3b4..432f186 100644
--- a/Documentation/devicetree/bindings/sound/pcm512x.txt
+++ b/Documentation/devicetree/bindings/sound/pcm512x.txt
@@ -26,6 +26,8 @@ Optional properties:
 given pll-in pin and PLL output on the given pll-out pin.  An
 external connection from the pll-out pin to the SCLK pin is assumed.
 
+  - pll-lock : gpio pin used to output the PLL lock flag.
+
 Examples:
 
pcm5122: pcm5122@4c {
@@ -49,4 +51,5 @@ Examples:
clocks = <&sck>;
pll-in = <3>;
pll-out = <6>;
+   pll-lock = <4>;
};
diff --git a/sound/soc/codecs/pcm512x.c b/sound/soc/codecs/pcm512x.c
index 8472099..a4217d7 100644
--- a/sound/soc/codecs/pcm512x.c
+++ b/sound/soc/codecs/pcm512x.c
@@ -49,6 +49,7 @@ struct pcm512x_priv {
int fmt;
int pll_in;
int pll_out;
+   int pll_lock;
int pll_r;
int pll_j;
int pll_d;
@@ -1296,24 +1297,26 @@ static int pcm512x_hw_params(struct snd_pcm_substream 
*substream,
ret, pcm512x->pll_out);
return ret;
}
+   }
 
-   gpio = PCM512x_G1OE << (4 - 1);
-   ret = regmap_update_bits(pcm512x->regmap, PCM512x_GPIO_EN,
-gpio, gpio);
-   if (ret != 0) {
-   dev_err(codec->dev, "Failed to enable gpio %d: %d\n",
-   4, ret);
-   return ret;
-   }
-
-   gpio = PCM512x_GPIO_OUTPUT_1 + 4 - 1;
-   ret = regmap_update_bits(pcm512x->regmap, gpio,
-PCM512x_GxSL, PCM512x_GxSL_PLLLK);
-   if (ret != 0) {
-   dev_err(codec->dev,
-   "Failed to output pll lock on %d: %d\n",
-   ret, 4);
-   return ret;
+   if (pcm512x->pll_lock) {
+gpio = PCM512x_G1OE << (pcm512x->pll_lock - 1);
+ret = regmap_update_bits(pcm512x->regmap, PCM512x_GPIO_EN,
+ gpio, gpio);
+if (ret != 0) {
+dev_err(codec->dev, "Failed to enable gpio %d: %d\n",
+pcm512x->pll_lock, ret);
+return ret;
+}
+
+gpio = PCM512x_GPIO_OUTPUT_1 + pcm512x->pll_lock - 1;
+ret = regmap_update_bits(pcm512x->regmap, gpio,
+ PCM512x_GxSL, PCM512x_GxSL_PLLLK);
+if (ret != 0) {
+dev_err(codec->dev,
+"Failed to output pll lock on %d: %d\n",
+ret, pcm512x->pll_lock);
+return ret;
}
}
 
@@ -1518,6 +1521,16 @@ int pcm512x_probe(struct device *dev, struct regmap 
*regmap)
ret = -EINVAL;
goto err_clk;
}
+
+if (of_property_read_u32(np, "pll-lock", &val) >= 0) {
+if (val > 6) {
+dev_err(dev, "Invalid pll-lock\n");
+ret = -EINVAL;
+goto err_clk;
+}
+pcm512x->pll_lock = val;
+}
+
}
 #endif
 
-- 
1.7.9.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 v1 1/3] phy: phy-core: allow specifying supply at port level

[Dmitry Torokhov]

Hi Arun,

On Fri, Mar 20, 2015 at 02:25:25PM -0700, Arun Ramamurthy wrote:
> Multi-port phy's may have per-port power supplies. Let's change phy core
> to first attempt to look up the supply at the port level, and then, if
> not found, check parent device.
> 
> Reviewed-by: Ray Jui 
> Reviewed-by: Scott Branden 
> Signed-off-by: Dmitry Torokhov 
> Signed-off-by: Arun Ramamurthy 
>

This should have had:

From: Dmitry Torokhov 

as first line of the body of e-mail as the patch was authored by me.

Thanks.

 ---
>  drivers/phy/phy-core.c | 30 --
>  1 file changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index a12d353..b43bb6b 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -650,16 +650,6 @@ struct phy *phy_create(struct device *dev, struct 
> device_node *node,
>   goto free_phy;
>   }
>  
> - /* phy-supply */
> - phy->pwr = regulator_get_optional(dev, "phy");
> - if (IS_ERR(phy->pwr)) {
> - if (PTR_ERR(phy->pwr) == -EPROBE_DEFER) {
> - ret = -EPROBE_DEFER;
> - goto free_ida;
> - }
> - phy->pwr = NULL;
> - }
> -
>   device_initialize(&phy->dev);
>   mutex_init(&phy->mutex);
>  
> @@ -673,6 +663,26 @@ struct phy *phy_create(struct device *dev, struct 
> device_node *node,
>   if (ret)
>   goto put_dev;
>  
> + /*
> +  * Locate phy-supply. We first try individual port and then,
> +  * if supply is not found, try parent device.
> +  */
> + phy->pwr = regulator_get_optional(&phy->dev, "phy");
> + if (IS_ERR(phy->pwr)) {
> + ret = PTR_ERR(phy->pwr);
> + if (ret == -EPROBE_DEFER)
> + goto free_ida;
> +
> + phy->pwr = regulator_get_optional(phy->dev.parent, "phy");
> + if (IS_ERR(phy->pwr)) {
> + ret = PTR_ERR(phy->pwr);
> + if (ret == -EPROBE_DEFER)
> + goto free_ida;
> +
> + phy->pwr = NULL;
> + }
> + }
> +
>   ret = device_add(&phy->dev);
>   if (ret)
>   goto put_dev;
> -- 
> 2.3.2
> 

-- 
Dmitry
--
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 v1 2/3] Phy: DT binding documentation for Broadcom Cygnus USB PHY driver

[Arun Ramamurthy]

Broadcom's Cygnus chip has a USB 2.0 host controller connected to
three separate phys. One of the phs (port 2) is also connectd to
a usb 2.0 device controller

Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Signed-off-by: Arun Ramamurthy 

---
 .../bindings/phy/brcm,cygnus-usb-phy.txt   | 65 ++
 1 file changed, 65 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt 
b/Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt
new file mode 100644
index 000..002bd59
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt
@@ -0,0 +1,65 @@
+BROADCOM CYGNUS USB PHY
+
+Required Properties:
+   - compatible:  brcm,cygnus-usb-phy
+   - reg : usbphy_regs - Base address of phy registers
+   usb2h_idm_regs - Base address of host idm registers
+   usb2d_idm_regs - Base address of device idm registers
+The node that uses the phy must provide one integers, 0 for device and 1 for 
host
+
+NOTE: port 0 and port 1 are host only and port 2 can be configured for host or 
device.
+
+Example of phy :
+   usbphy0: usbphy@0x0301c000 {
+   compatible = "brcm,cygnus-usb-phy";
+   reg = <0x0301c000 0x2000>,
+ <0x18115000 0x1000>,
+ <0x18111000 0x1000>;
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   usbphy0_0: usbphy0@0 {
+   #phy-cells = <1>;
+   reg = <0>;
+   status = "okay";
+   phy-supply = <&vbus_p0>;
+   };
+
+   usbphy0_1: usbphy0@1 {
+   #phy-cells = <1>;
+   reg = <1>;
+   status = "okay";
+   };
+
+   usbphy0_2: usbphy0@2 {
+   #phy-cells = <1>;
+   reg = <2>;
+   status = "okay";
+   phy-supply = <&vbus_p2>;
+   };
+   };
+
+Example of node using the phy:
+
+   /* This nodes declares all three ports as host */
+   
+   ehci0: usb@0x18048000 {
+   compatible = "generic-ehci";
+   reg = <0x18048000 0x100>;
+   interrupts = ;
+   phys = <&usbphy0_0 1 &usbphy0_1 1 &usbphy0_2 1>;
+   phy-names = "usb","usb","usb";
+   status = "okay";
+   };
+
+   /* This node declares port 2 phy
+   and configures it for device */
+
+   usbd_udc_dwc1: usbd_udc_dwc@0x1804c000 {
+   compatible = "iproc-udc";
+   reg = <0x1804c000 0x2000>;
+   interrupts = ;
+   phys = <&usbphy0_2 0>;
+   phy-names = "usb";
+   };
-- 
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

[PATCH v1 1/3] phy: phy-core: allow specifying supply at port level

[Arun Ramamurthy]

Multi-port phy's may have per-port power supplies. Let's change phy core
to first attempt to look up the supply at the port level, and then, if
not found, check parent device.

Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Arun Ramamurthy 
---
 drivers/phy/phy-core.c | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index a12d353..b43bb6b 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -650,16 +650,6 @@ struct phy *phy_create(struct device *dev, struct 
device_node *node,
goto free_phy;
}
 
-   /* phy-supply */
-   phy->pwr = regulator_get_optional(dev, "phy");
-   if (IS_ERR(phy->pwr)) {
-   if (PTR_ERR(phy->pwr) == -EPROBE_DEFER) {
-   ret = -EPROBE_DEFER;
-   goto free_ida;
-   }
-   phy->pwr = NULL;
-   }
-
device_initialize(&phy->dev);
mutex_init(&phy->mutex);
 
@@ -673,6 +663,26 @@ struct phy *phy_create(struct device *dev, struct 
device_node *node,
if (ret)
goto put_dev;
 
+   /*
+* Locate phy-supply. We first try individual port and then,
+* if supply is not found, try parent device.
+*/
+   phy->pwr = regulator_get_optional(&phy->dev, "phy");
+   if (IS_ERR(phy->pwr)) {
+   ret = PTR_ERR(phy->pwr);
+   if (ret == -EPROBE_DEFER)
+   goto free_ida;
+
+   phy->pwr = regulator_get_optional(phy->dev.parent, "phy");
+   if (IS_ERR(phy->pwr)) {
+   ret = PTR_ERR(phy->pwr);
+   if (ret == -EPROBE_DEFER)
+   goto free_ida;
+
+   phy->pwr = NULL;
+   }
+   }
+
ret = device_add(&phy->dev);
if (ret)
goto put_dev;
-- 
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

[PATCH v1 3/3] phy: cygnus-usbphy: Add Broadcom Cygnus USB phy driver

[Arun Ramamurthy]

This driver adds support for USB 2.0 host and device phy for
Broadcom's Cygnus chipset. The host controller is connected to
three separate phys and one of the phys (port 2) is connected to
the device controller


Signed-off-by: Dmitry Torokhov 
Signed-off-by: Arun Ramamurthy 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/phy/Kconfig  |  12 +
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-bcm-cygnus-usb.c | 499 +++
 3 files changed, 512 insertions(+)
 create mode 100644 drivers/phy/phy-bcm-cygnus-usb.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2962de2..0aa62dc 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -291,4 +291,16 @@ config PHY_QCOM_UFS
help
  Support for UFS PHY on QCOM chipsets.
 
+config PHY_BCM_CYGNUS_USB
+   tristate "Broadcom Cygnus USB PHY support"
+   depends on OF
+   depends on ARCH_BCM_CYGNUS || COMPILE_TEST
+   select GENERIC_PHY
+   default ARCH_BCM_CYGNUS
+   help
+ Enable this to support the USB PHY in Broadcom's Cygnus chip.
+ The phys are capable of supporting host mode for all ports
+ and device mode for port 2. The host or device configuration is
+ read from the device tree.
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f080e1b..47a37fa 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_GENERIC_PHY)   += phy-core.o
 obj-$(CONFIG_PHY_BERLIN_USB)   += phy-berlin-usb.o
 obj-$(CONFIG_PHY_BERLIN_SATA)  += phy-berlin-sata.o
 obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
+obj-$(CONFIG_PHY_BCM_CYGNUS_USB)   += phy-bcm-cygnus-usb.o
 obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
 obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)  += phy-exynos-dp-video.o
 obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
diff --git a/drivers/phy/phy-bcm-cygnus-usb.c b/drivers/phy/phy-bcm-cygnus-usb.c
new file mode 100644
index 000..c12918e
--- /dev/null
+++ b/drivers/phy/phy-bcm-cygnus-usb.c
@@ -0,0 +1,499 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; 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 
+
+#define CDRU_USBPHY_CLK_RST_SEL_OFFSET 0x11b4
+#define CDRU_USBPHY2_HOST_DEV_SEL_OFFSET   0x11b8
+#define CDRU_SPARE_REG_0_OFFSET0x1238
+#define CRMU_USB_PHY_AON_CTRL_OFFSET   0x00028
+#define CDRU_USB_DEV_SUSPEND_RESUME_CTRL_OFFSET0x1210
+#define CDRU_USBPHY_P0_STATUS_OFFSET   0x11D0
+#define CDRU_USBPHY_P1_STATUS_OFFSET   0x11E8
+#define CDRU_USBPHY_P2_STATUS_OFFSET   0x1200
+#define CDRU_USBPHY_USBPHY_ILDO_ON_FLAG1
+#define CDRU_USBPHY_USBPHY_PLL_LOCK0
+#define CDRU_USB_DEV_SUSPEND_RESUME_CTRL_DISABLE   0
+#define PHY2_DEV_HOST_CTRL_SEL_HOST1
+
+#define CRMU_USBPHY_P0_AFE_CORERDY_VDDC1
+#define CRMU_USBPHY_P0_RESETB  2
+#define CRMU_USBPHY_P1_AFE_CORERDY_VDDC9
+#define CRMU_USBPHY_P1_RESETB  10
+#define CRMU_USBPHY_P2_AFE_CORERDY_VDDC17
+#define CRMU_USBPHY_P2_RESETB  18
+
+#define USB2_IDM_IDM_IO_CONTROL_DIRECT_OFFSET  0x0408
+#define USB2_IDM_IDM_IO_CONTROL_DIRECT__clk_enable 0
+#define USB2_IDM_IDM_RESET_CONTROL_OFFSET  0x0800
+#define USB2_IDM_IDM_RESET_CONTROL__RESET  0
+
+#define PLL_LOCK_RETRY_COUNT   1000
+#define MAX_PHY_PORTS  3
+
+static int power_bit[] = {CRMU_USBPHY_P0_AFE_CORERDY_VDDC,
+   CRMU_USBPHY_P1_AFE_CORERDY_VDDC,
+   CRMU_USBPHY_P2_AFE_CORERDY_VDDC};
+static int reset_bit[] = {CRMU_USBPHY_P0_RESETB,
+   CRMU_USBPHY_P1_RESETB,
+   CRMU_USBPHY_P2_RESETB};
+static int status_reg[] = {CDRU_USBPHY_P0_STATUS_OFFSET,
+   CDRU_USBPHY_P1_STATUS_OFFSET,
+   CDRU_USBPHY_P2_STATUS_OFFSET};
+
+struct bcm_phy_instance;
+
+struct bcm_phy_driver {
+   void __iomem *usbphy_regs;
+   void __iomem *usb2h_idm_regs;
+   void __iomem *usb2d_idm_regs;
+   struct bcm_phy_instance *ports[MAX_PHY_PORTS];
+   spinlock_t lock;

[PATCH v1 0/3] USB PHY driver for Broadcom's Cygnus chipse

[Arun Ramamurthy]

This patchset adds the USB phy driver and documentation 
for Broadom's Cygnus chipset. The phy is configurable from device tree
and is capable of both device and host functions. It also provides
a clock and reset to the host controller

History:
v1:
- Included Dmitry Torokhov's patch that addresed Kishon Vijay Abraham's 
comments on multiple phy model
- Inlucded Dmitry Torokhov's patch to use phy regulator
- Addressed Arnd Bergmann's comments on usage of this phy driver by
ehci-platform and ohci-platform driver in a separate patchset. 

Arun Ramamurthy (3):
  phy: phy-core: allow specifying supply at port level
  Phy: DT binding documentation for Broadcom Cygnus USB PHY driver
  phy: cygnus-usbphy: Add Broadcom Cygnus USB phy driver

 .../bindings/phy/brcm,cygnus-usb-phy.txt   |  65 +++
 drivers/phy/Kconfig|  12 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-bcm-cygnus-usb.c   | 499 +
 drivers/phy/phy-core.c |  30 +-
 5 files changed, 597 insertions(+), 10 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt
 create mode 100644 drivers/phy/phy-bcm-cygnus-usb.c

-- 
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

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

[Lad Prabhakar]

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 v10:
 Fixed review comments pointed by Hans.

 v9: https://patchwork.kernel.org/patch/6056111/
 v8: https://patchwork.kernel.org/patch/6055981/
 v7: https://patchwork.kernel.org/patch/6034651/
 v6: https://patchwork.kernel.org/patch/6012751/
 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 | 1509 
 include/media/ov2659.h |   34 +
 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/Documentation/devicetree/bindings/media/i2c/ov2659.txt 
b/Documentation/devicetree/bindings/media/i2c/ov2659.txt
new file mode 100644
index 000..cabc7d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2659.txt
@@ -0,0 +1,38 @@
+* OV2659 1/5-Inch 2Mp SOC Camera
+
+The Omnivision OV2659 is a 1/5-inch SOC camera, with an active array size of
+1632H x 1212V. It is programmable through a SCCB. The OV2659 sensor supports
+multiple resolutions output, such as UXGA, SVGA, 720p. It also can support
+YUV422, RGB565/555 or raw RGB output formats.
+
+Required Properties:
+- compatible: Must be "ovti,ov2659"
+- reg: I2C slave address
+- clocks: reference to the xvclk input clock.
+- clock-names: should be "xvclk".
+- link-frequencies: target pixel clock frequency.
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+   i2c0@1c22000 {
+   ...
+   ...
+ov2659@30 {
+   compatible = "ovti,ov2659";
+   reg = <0x30>;
+
+   clocks = <&clk_ov2659 0>;
+   clock-names = "xvclk";
+
+   port {
+   ov2659_0: endpoint {
+   remote-endpoint = <&vpfe_ep>;
+   link-frequencies = /bits/ 64 <7000>;
+   };
+   };
+   };
+   ...
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..4006cc8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8910,6 +8910,16 @@ T:   git 
git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
 S: Maintained
 F: drivers/media/platform/am437x/
 
+OV2659 OMNIVISION SENSOR DRIVER
+M: Lad, Prabhakar 
+L: linux-me...@vger.kernel.org
+W: http://linuxtv.org/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
+S: Maintained
+F: drivers/media/i2c/ov2659.c
+F: include/media/ov2659.h
+
 SIS 190 ETHERNET DRIVER
 M: Francois Romieu 
 L: net...@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index da58c9b..6f30ea7 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -466,6 +466,17 @@ config VIDEO_APTINA_PLL
 config VIDEO_SMIAPP_PLL
tristate
 
+config VIDEO_OV2659
+   tristate "OmniVision OV2659 sensor support"
+   depends on VIDEO_V4L2 && I2C
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV2659 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2659.
+
 config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 98589001..f165fae 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_VIDEO_SMIAPP_PLL)+= smiapp-pll.o
 obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
 obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
 obj-$(CONFIG_VIDEO_ML86V7667)  += ml86v7667.o
+obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
new file mode 100644
index 000..edebd11
--- /dev/null
+++ b/drivers/media/i2c/ov2659.c
@@ -0,0 +1,1509 @@
+/*
+ * Omnivision OV2659 CMOS Image Sensor driver
+ *
+ * Copyright (C) 201

Re: [PATCH 2/2] add newhaven lcd tty driver on i2c

[atull]

On Tue, 17 Mar 2015, Greg Kroah-Hartman wrote:

> On Tue, Mar 17, 2015 at 03:36:47PM -0500, Alan Tull wrote:
> > Supports the Newhaven NHD‐0216K3Z‐NSW‐BBW 2x16 LCD module as i2c slave.
> > Devices will show up as /dev/ttyLCD0, etc.
> > 
> >  * Backspace is supported to the beginning of the current line.
> > * i.e. printf '\b' > /dev/ttyLCD0
> > 
> >  * ESC [ 2 J
> > * erase whole display and reset cursor to home.
> > * i.e. printf '\e[2J' > /dev/ttyLCD0
> > 
> >  * ESC [ 2 K
> > * erase current line and set cursor to beginning of line.
> > * i.e. printf '\e[2K' > /dev/ttyLCD0
> > 
> >  * CR and LF are supported.
> > 
> >  * Vertical scroll when cursor is on bottom line and receive end of line.
> > 
> > Default brightness can be set from the device tree/plat data.
> > 
> > Brightness can be set from a sysfs file, for example:
> >  * echo 6 > /sys/devices/soc.0/ffc04000.i2c/i2c-0/0-0028/brightness
> > 
> > Signed-off-by: Alan Tull 
> 
> This should use the new fb_tft api instead of trying to look like a tty
> device.  That framework is merged in the staging-next branch of the
> staging.git kernel tree and will show up in 4.1-rc1.  Please port this
> driver to that api and submit a patch for me to take for the staging
> tree so that we don't have one-off devices like this.
> 

Hi Greg,

This isn't framebuffer type of device.  It's two rows of 16 characters
and you can write ascii characters to it.  If there's another framework
more suited to this, that would be great.

Alan

> thanks,
> 
> greg k-h
> --
> 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/
> 

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

[Bjorn Andersson]

On Fri 20 Mar 13:29 PDT 2015, Andy Gross wrote:

> On Thu, Mar 19, 2015 at 06:48:10PM -0700, Bjorn Andersson wrote:
> 
> 
> 
> > +Example:
> > +
> > +   tcsr: syscon@1a40 {
> 
> typo here, syscon@fd484000.  And this syscon is specifically for the tcsr 
> mutex
> reg area.
> 

You're right, I didn't read the documentation good enough; let's name it
tcsr-mutex and as this is not the main tcsr region we should fall back
to just having syscon as compatible.

But there's still a bunch of other registers in the tcsr-mutex range -
that probably will be consumed by various drivers, so it still makes
sense to have a syscon there.

Sorry about the address, will update that as well.

> > +   compatible = "qcom,tcsr-msm8974", "syscon";
> > +   reg = <0xfd484000 0x2000>;
> 

Regards,
Bjorn
--
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 v7 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Andy Gross]

On Thu, Mar 19, 2015 at 06:48:10PM -0700, Bjorn Andersson wrote:



> +Example:
> +
> + tcsr: syscon@1a40 {

typo here, syscon@fd484000.  And this syscon is specifically for the tcsr mutex
reg area.

> + compatible = "qcom,tcsr-msm8974", "syscon";
> + reg = <0xfd484000 0x2000>;



-- 
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

[PATCH v17 01/10] ARM: qcom: Add Subsystem Power Manager (SPM) driver

[Lina Iyer]

SPM is a hardware block that controls the peripheral logic surrounding
the application cores (cpu/l$). When the core executes WFI instruction,
the SPM takes over the putting the core in low power state as
configured. The wake up for the SPM is an interrupt at the GIC, which
then completes the rest of low power mode sequence and brings the core
out of low power mode.

The SPM has a set of control registers that configure the SPMs
individually based on the type of the core and the runtime conditions.
SPM is a finite state machine block to which a sequence is provided and
it interprets the bytes and executes them in sequence. Each low power
mode that the core can enter into is provided to the SPM as a sequence.

Configure the SPM to set the core (cpu or L2) into its low power mode,
the index of the first command in the sequence is set in the SPM_CTL
register. When the core executes ARM wfi instruction, it triggers the
SPM state machine to start executing from that index. The SPM state
machine waits until the interrupt occurs and starts executing the rest
of the sequence until it hits the end of the sequence. The end of the
sequence jumps the core out of its low power mode.

Add support for an idle driver to set up the SPM to place the core in
Standby or Standalone power collapse mode when the core is idle.

Based on work by: Mahesh Sivasubramanian ,
Ai Li , Praveen Chidambaram 
Original tree available at -
git://codeaurora.org/quic/la/kernel/msm-3.10.git

Cc: Stephen Boyd 
Cc: Arnd Bergmann 
Cc: Kevin Hilman 
Cc: Daniel Lezcano 
Signed-off-by: Lina Iyer 
---
 .../devicetree/bindings/arm/msm/qcom,saw2.txt  |  29 +-
 drivers/soc/qcom/Kconfig   |   7 +
 drivers/soc/qcom/Makefile  |   1 +
 drivers/soc/qcom/spm.c | 405 +
 4 files changed, 436 insertions(+), 6 deletions(-)
 create mode 100644 drivers/soc/qcom/spm.c

diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt 
b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
index 1505fb8..664aa91 100644
--- a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
@@ -2,11 +2,20 @@ SPM AVS Wrapper 2 (SAW2)
 
 The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
 Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable
-micro-controller that transitions a piece of hardware (like a processor or
+power-controller that transitions a piece of hardware (like a processor or
 subsystem) into and out of low power modes via a direct connection to
 the PMIC. It can also be wired up to interact with other processors in the
 system, notifying them when a low power state is entered or exited.
 
+Multiple revisions of the SAW hardware are supported using these Device Nodes.
+SAW2 revisions differ in the register offset and configuration data. Also, the
+same revision of the SAW in different SoCs may have different configuration
+data due the the differences in hardware capabilities. Hence the SoC name, the
+version of the SAW hardware in that SoC and the distinction between cpu (big
+or Little) or cache, may be needed to uniquely identify the SAW register
+configuration and initialization data. The compatible string is used to
+indicate this parameter.
+
 PROPERTIES
 
 - compatible:
@@ -14,10 +23,11 @@ PROPERTIES
Value type: 
Definition: shall contain "qcom,saw2". A more specific value should be
one of:
-"qcom,saw2-v1"
-"qcom,saw2-v1.1"
-"qcom,saw2-v2"
-"qcom,saw2-v2.1"
+   "qcom,saw2-v2"
+   "qcom,saw2-v2.1"
+   "qcom,apq8064-saw2-v1.1-cpu"
+   "qcom,msm8974-saw2-v2.1-cpu"
+   "qcom,apq8084-saw2-v2.1-cpu"
 
 - reg:
Usage: required
@@ -26,10 +36,17 @@ PROPERTIES
the register region. An optional second element specifies
the base address and size of the alias register region.
 
+- regulator:
+   Usage: optional
+   Value type: boolean
+   Definition: Indicates that this SPM device acts as a regulator device
+   device for the core (CPU or Cache) the SPM is attached
+   to.
 
 Example:
 
-   regulator@2099000 {
+   power-controller@2099000 {
compatible = "qcom,saw2";
reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
+   regulator;
};
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 7bd2c94..628bcba 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -9,3 +9,10 @@ config QCOM_GSBI
   functions for connecting the underlying serial UART, SPI, and I2C
   devices to the output pins.
 
+config QCOM_PM
+   bool "Qualcomm Power Management"
+  

[PATCH] ARM: Exynos5420: dt: Fixed the checkpatch.pl WARNING misspelled

[Anand Moon]

Changes fixes the misspelled of #interrups-cell.

arch/arm/boot/dts/exynos5420.dtsi:224: WARNING: 'interrups'
 may be misspelled - perhaps 'interrupts'?

Tested on OdroidXU3 board.

Signed-off-by: Anand Moon 
---
 arch/arm/boot/dts/exynos5420.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index c0e98cf..a78ac1f 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -221,7 +221,7 @@
compatible = "samsung,exynos4210-mct";
reg = <0x101C 0x800>;
interrupt-controller;
-   #interrups-cells = <1>;
+   #interrupt-cells = <1>;
interrupt-parent = <&mct_map>;
interrupts = <0>, <1>, <2>, <3>, <4>, <5>, <6>, <7>,
<8>, <9>, <10>, <11>;
-- 
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

[PATCH v17 07/10] ARM: dts: qcom: Add idle states device nodes for 8974/8074

[Lina Iyer]

Add ARM common idle states device bindings for cpuidle support for APQ
8974/8074.

Support Standalone power collapse (SPC) idle state (power down that does
not affect any SoC idle states) for each cpu.

Cc: Kumar Gala 
Signed-off-by: Lina Iyer 
---
 arch/arm/boot/dts/qcom-msm8974.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 5a41f44..1c28f0f 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -22,6 +22,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc0>;
qcom,saw = <&saw0>;
+   cpu-idle-states = <&CPU_SPC>;
};
 
cpu@1 {
@@ -32,6 +33,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc1>;
qcom,saw = <&saw1>;
+   cpu-idle-states = <&CPU_SPC>;
};
 
cpu@2 {
@@ -42,6 +44,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc2>;
qcom,saw = <&saw2>;
+   cpu-idle-states = <&CPU_SPC>;
};
 
cpu@3 {
@@ -52,6 +55,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc3>;
qcom,saw = <&saw3>;
+   cpu-idle-states = <&CPU_SPC>;
};
 
L2: l2-cache {
@@ -59,6 +63,16 @@
cache-level = <2>;
qcom,saw = <&saw_l2>;
};
+
+   idle-states {
+   CPU_SPC: spc {
+   compatible = "qcom,idle-state-spc",
+   "arm,idle-state";
+   entry-latency-us = <150>;
+   exit-latency-us = <200>;
+   min-residency-us = <2000>;
+   };
+   };
};
 
cpu-pmu {
-- 
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 v1] of/pci : fix of_pci_dma_configure parent ptr NULL

[Murali Karicheri]

On 03/19/2015 11:01 AM, Bjorn Helgaas wrote:

On Wed, Mar 11, 2015 at 12:40:03PM -0400, Murali Karicheri wrote:

On some platforms such as that based on x86, ia64 etc, root bus is
created with parent node passed in as NULL to pci_create_root_bus().
On these platforms, the patch series "PCI: get DMA configuration from
parent device" when applied causes kernel crash. So add a check for this
in of_pci_dma_configure()

Signed-off-by: Murali Karicheri
Acked-by: Rob Herring


Since I hadn't merged the original patch yet, I just folded this fix into
it.  The series is on pci/iommu, and I merged it for "next".  Thanks for
your patience.

Bjorn


Thanks!

Murali



---
  drivers/of/of_pci.c |4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 86d3c38..a8e485c 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -129,6 +129,10 @@ void of_pci_dma_configure(struct pci_dev *pci_dev)
struct device *dev =&pci_dev->dev;
struct device *bridge = pci_get_host_bridge_device(pci_dev);

+   /* Some platforms can have bridge->parent set to NULL */
+   if (!bridge->parent)
+   return;
+
of_dma_configure(dev, bridge->parent->of_node);
pci_put_host_bridge_device(bridge);
  }
--
1.7.9.5




--
Murali Karicheri
Linux Kernel, Texas Instruments
--
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 v17 10/10] ARM: qcom: Update defconfig to enable cpuidle

[Lina Iyer]

Update defconfig to allow cpuidle for QCOM cpus.

* Enable QCOM_PM
* Enable ARM_QCOM_CPUIDLE

Cc: Kumar Gala 
Signed-off-by: Lina Iyer 
---
 arch/arm/configs/qcom_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 8c7da33..56bda6b 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -30,6 +30,7 @@ CONFIG_CLEANCACHE=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CPU_IDLE=y
+CONFIG_ARM_QCOM_CPUIDLE=y
 CONFIG_VFP=y
 CONFIG_NEON=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
@@ -135,6 +136,7 @@ CONFIG_DMADEVICES=y
 CONFIG_QCOM_BAM_DMA=y
 CONFIG_STAGING=y
 CONFIG_QCOM_GSBI=y
+CONFIG_QCOM_PM=y
 CONFIG_COMMON_CLK_QCOM=y
 CONFIG_APQ_MMCC_8084=y
 CONFIG_IPQ_GCC_806X=y
-- 
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

[PATCH v17 04/10] ARM: dts: qcom: Add power-controller device node for 8074 Krait CPUs

[Lina Iyer]

Each Krait CPU in the QCOM 8074/8974 SoC has an SAW power controller to
regulate the power to the cpu and aide the core in entering idle states.
Reference the SAW instance and associate the instance with the CPU core.

Cc: Kumar Gala 
Signed-off-by: Lina Iyer 
Reviewed-by: Stephen Boyd 
---
 arch/arm/boot/dts/qcom-msm8974.dtsi | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index e265ec1..5a41f44 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -21,6 +21,7 @@
reg = <0>;
next-level-cache = <&L2>;
qcom,acc = <&acc0>;
+   qcom,saw = <&saw0>;
};
 
cpu@1 {
@@ -30,6 +31,7 @@
reg = <1>;
next-level-cache = <&L2>;
qcom,acc = <&acc1>;
+   qcom,saw = <&saw1>;
};
 
cpu@2 {
@@ -39,6 +41,7 @@
reg = <2>;
next-level-cache = <&L2>;
qcom,acc = <&acc2>;
+   qcom,saw = <&saw2>;
};
 
cpu@3 {
@@ -48,6 +51,7 @@
reg = <3>;
next-level-cache = <&L2>;
qcom,acc = <&acc3>;
+   qcom,saw = <&saw3>;
};
 
L2: l2-cache {
@@ -144,7 +148,27 @@
};
};
 
-   saw_l2: regulator@f9012000 {
+   saw0: power-controller@f9089000 {
+   compatible = "qcom,msm8974-saw2-v2.1-cpu";
+   reg = <0xf9089000 0x1000>, <0xf9009000 0x1000>;
+   };
+
+   saw1: power-controller@f9099000 {
+   compatible = "qcom,msm8974-saw2-v2.1-cpu";
+   reg = <0xf9099000 0x1000>, <0xf9009000 0x1000>;
+   };
+
+   saw2: power-controller@f90a9000 {
+   compatible = "qcom,msm8974-saw2-v2.1-cpu";
+   reg = <0xf90a9000 0x1000>, <0xf9009000 0x1000>;
+   };
+
+   saw3: power-controller@f90b9000 {
+   compatible = "qcom,msm8974-saw2-v2.1-cpu";
+   reg = <0xf90b9000 0x1000>, <0xf9009000 0x1000>;
+   };
+
+   saw_l2: power-controller@f9012000 {
compatible = "qcom,saw2";
reg = <0xf9012000 0x1000>;
regulator;
-- 
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

[PATCH v17 05/10] ARM: dts: qcom: Add power-controller device node for 8084 Krait CPUs

[Lina Iyer]

Each Krait CPU in the QCOM 8084 SoC has an SAW power controller to
regulate the power to the cpu and aide the core in entering idle states.
Reference the SAW instance and associate the instance with the CPU core.

Cc: Kumar Gala 
Signed-off-by: Lina Iyer 
Reviewed-by: Stephen Boyd 
---
 arch/arm/boot/dts/qcom-apq8084.dtsi | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi 
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index 1f130bc..71182bf 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -21,6 +21,7 @@
enable-method = "qcom,kpss-acc-v2";
next-level-cache = <&L2>;
qcom,acc = <&acc0>;
+   qcom,saw = <&saw0>;
};
 
cpu@1 {
@@ -30,6 +31,7 @@
enable-method = "qcom,kpss-acc-v2";
next-level-cache = <&L2>;
qcom,acc = <&acc1>;
+   qcom,saw = <&saw1>;
};
 
cpu@2 {
@@ -39,6 +41,7 @@
enable-method = "qcom,kpss-acc-v2";
next-level-cache = <&L2>;
qcom,acc = <&acc2>;
+   qcom,saw = <&saw2>;
};
 
cpu@3 {
@@ -48,6 +51,7 @@
enable-method = "qcom,kpss-acc-v2";
next-level-cache = <&L2>;
qcom,acc = <&acc3>;
+   qcom,saw = <&saw3>;
};
 
L2: l2-cache {
@@ -144,7 +148,27 @@
};
};
 
-   saw_l2: regulator@f9012000 {
+   saw0: power-controller@f9089000 {
+   compatible = "qcom,apq8084-saw2-v2.1-cpu";
+   reg = <0xf9089000 0x1000>, <0xf9009000 0x1000>;
+   };
+
+   saw1: power-controller@f9099000 {
+   compatible = "qcom,apq8084-saw2-v2.1-cpu";
+   reg = <0xf9099000 0x1000>, <0xf9009000 0x1000>;
+   };
+
+   saw2: power-controller@f90a9000 {
+   compatible = "qcom,apq8084-saw2-v2.1-cpu";
+   reg = <0xf90a9000 0x1000>, <0xf9009000 0x1000>;
+   };
+
+   saw3: power-controller@f90b9000 {
+   compatible = "qcom,apq8084-saw2-v2.1-cpu";
+   reg = <0xf90b9000 0x1000>, <0xf9009000 0x1000>;
+   };
+
+   saw_l2: power-controller@f9012000 {
compatible = "qcom,saw2";
reg = <0xf9012000 0x1000>;
regulator;
-- 
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

[PATCH v17 09/10] ARM: dts: qcom: Add idle state device nodes for 8064

[Lina Iyer]

Add ARM common idle state device bindings for cpuidle support for APQ
8064.

Support Standalone power collapse (SPC) idle state (power down that does not
affect any SoC idle states) for each cpu.

Cc: Kumar Gala 
Signed-off-by: Lina Iyer 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 9fd24bc..592e985 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -23,6 +23,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc0>;
qcom,saw = <&saw0>;
+   cpu-idle-states = <&CPU_SPC>;
};
 
cpu@1 {
@@ -33,6 +34,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc1>;
qcom,saw = <&saw1>;
+   cpu-idle-states = <&CPU_SPC>;
};
 
cpu@2 {
@@ -43,6 +45,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc2>;
qcom,saw = <&saw2>;
+   cpu-idle-states = <&CPU_SPC>;
};
 
cpu@3 {
@@ -53,12 +56,23 @@
next-level-cache = <&L2>;
qcom,acc = <&acc3>;
qcom,saw = <&saw3>;
+   cpu-idle-states = <&CPU_SPC>;
};
 
L2: l2-cache {
compatible = "cache";
cache-level = <2>;
};
+
+   idle-states {
+   CPU_SPC: spc {
+   compatible = "qcom,idle-state-spc",
+   "arm,idle-state";
+   entry-latency-us = <400>;
+   exit-latency-us = <900>;
+   min-residency-us = <3000>;
+   };
+   };
};
 
cpu-pmu {
-- 
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

[PATCH v17 02/10] ARM: cpuidle: qcom: Add documentation for qcom cpuidle states

[Lina Iyer]

Add documentation for cpuidle states of QCOM cpus. In addition to
arm-idle-state compatible string, the ARM idle state definition must
define one of the following compatible strings -
"qcom,idle-state-ret",
"qcom,idle-state-spc",
"qcom,idle-state-pc",

The compatibles helps the SPM platform driver to use the correct idle
function when the index to the idle state is passed to the platform
driver.

Signed-off-by: Lina Iyer 
---
 .../bindings/arm/msm/qcom,idle-state.txt   | 84 ++
 1 file changed, 84 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt

diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt 
b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt
new file mode 100644
index 000..06df04c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt
@@ -0,0 +1,84 @@
+QCOM Idle States for cpuidle driver
+
+ARM provides idle-state node to define the cpuidle states, as defined in [1].
+cpuidle-qcom is the cpuidle driver for Qualcomm SoCs and uses these idle
+states. Idle states have different enter/exit latency and residency values.
+The idle states supported by the QCOM SoC are defined as -
+
+* Standby
+* Retention
+* Standalone Power Collapse (Standalone PC or SPC)
+* Power Collapse (PC)
+
+Standby: Standby does a little more in addition to architectural clock gating.
+When the WFI instruction is executed the ARM core would gate its internal
+clocks. In addition to gating the clocks, QCOM cpus use this instruction as a
+trigger to execute the SPM state machine. The SPM state machine waits for the
+interrupt to trigger the core back in to active. This triggers the cache
+hierarchy to enter standby states, when all cpus are idle. An interrupt brings
+the SPM state machine out of its wait, the next step is to ensure that the
+cache hierarchy is also out of standby, and then the cpu is allowed to resume
+execution. This state is defined as a generic ARM WFI state by the ARM cpuidle
+driver and is not defined in the DT. The SPM state machine should be
+configured to execute this state by default and after executing every other
+state below.
+
+Retention: Retention is a low power state where the core is clock gated and
+the memory and the registers associated with the core are retained. The
+voltage may be reduced to the minimum value needed to keep the processor
+registers active. The SPM should be configured to execute the retention
+sequence and would wait for interrupt, before restoring the cpu to execution
+state. Retention may have a slightly higher latency than Standby.
+
+Standalone PC: A cpu can power down and warmboot if there is a sufficient time
+between the time it enters idle and the next known wake up. SPC mode is used
+to indicate a core entering a power down state without consulting any other
+cpu or the system resources. This helps save power only on that core.  The SPM
+sequence for this idle state is programmed to power down the supply to the
+core, wait for the interrupt, restore power to the core, and ensure the
+system state including cache hierarchy is ready before allowing core to
+resume. Applying power and resetting the core causes the core to warmboot
+back into Elevation Level (EL) which trampolines the control back to the
+kernel. Entering a power down state for the cpu, needs to be done by trapping
+into a EL. Failing to do so, would result in a crash enforced by the warm boot
+code in the EL for the SoC. On SoCs with write-back L1 cache, the cache has to
+be flushed in s/w, before powering down the core.
+
+Power Collapse: This state is similar to the SPC mode, but distinguishes
+itself in that the cpu acknowledges and permits the SoC to enter deeper sleep
+modes. In a hierarchical power domain SoC, this means L2 and other caches can
+be flushed, system bus, clocks - lowered, and SoC main XO clock gated and
+voltages reduced, provided all cpus enter this state.  Since the span of low
+power modes possible at this state is vast, the exit latency and the residency
+of this low power mode would be considered high even though at a cpu level,
+this essentially is cpu power down. The SPM in this state also may handshake
+with the Resource power manager (RPM) processor in the SoC to indicate a
+complete application processor subsystem shut down.
+
+The idle-state for QCOM SoCs are distinguished by the compatible property of
+the idle-states device node.
+
+The devicetree representation of the idle state should be -
+
+Required properties:
+
+- compatible: Must be one of -
+   "qcom,idle-state-ret",
+   "qcom,idle-state-spc",
+   "qcom,idle-state-pc",
+   and "arm,idle-state".
+
+Other required and optional properties are specified in [1].
+
+Example:
+
+   idle-states {
+   CPU_SPC: spc {
+   compatible = "qcom

[PATCH v17 08/10] ARM: dts: qcom: Add idle states device nodes for 8084

[Lina Iyer]

Add ARM common idle states device bindings for cpuidle support for APQ
8084.

Support Standalone power collapse (SPC) idle state (power down that does not
affect any SoC idle states) for each cpu.

Cc: Kumar Gala 
Signed-off-by: Lina Iyer 
---
 arch/arm/boot/dts/qcom-apq8084.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi 
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index 71182bf..6126d47 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -22,6 +22,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc0>;
qcom,saw = <&saw0>;
+   cpu-idle-states = <&CPU_SPC>;
};
 
cpu@1 {
@@ -32,6 +33,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc1>;
qcom,saw = <&saw1>;
+   cpu-idle-states = <&CPU_SPC>;
};
 
cpu@2 {
@@ -42,6 +44,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc2>;
qcom,saw = <&saw2>;
+   cpu-idle-states = <&CPU_SPC>;
};
 
cpu@3 {
@@ -52,6 +55,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc3>;
qcom,saw = <&saw3>;
+   cpu-idle-states = <&CPU_SPC>;
};
 
L2: l2-cache {
@@ -59,6 +63,16 @@
cache-level = <2>;
qcom,saw = <&saw_l2>;
};
+
+   idle-states {
+   CPU_SPC: spc {
+   compatible = "qcom,idle-state-spc",
+   "arm,idle-state";
+   entry-latency-us = <150>;
+   exit-latency-us = <200>;
+   min-residency-us = <2000>;
+   };
+   };
};
 
cpu-pmu {
-- 
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

[PATCH v17 03/10] ARM: cpuidle: Add cpuidle support for QCOM cpus

[Lina Iyer]

Define ARM_QCOM_CPUIDLE config item to enable cpuidle support.

Cc: Stephen Boyd 
Cc: Arnd Bergmann 
Cc: Kevin Hilman 
Cc: Daniel Lezcano 
Signed-off-by: Lina Iyer 
---
 drivers/cpuidle/Kconfig.arm | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 1f067bd..644a647 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -74,3 +74,10 @@ config ARM_MVEBU_V7_CPUIDLE
depends on ARCH_MVEBU
help
  Select this to enable cpuidle on Armada 370, 38x and XP processors.
+
+config ARM_QCOM_CPUIDLE
+   bool "CPU Idle Driver for QCOM processors"
+   depends on ARCH_QCOM
+   select ARM_CPUIDLE
+   help
+ Select this to enable cpuidle on QCOM processors.
-- 
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

[PATCH v17 06/10] ARM: dts: qcom: Update power-controller device node for 8064 Krait CPUs

[Lina Iyer]

Update the SAW2 DT bindings to add qcom,apq8064-saw2-v1.1-cpu compatible
binding string to configure SPM registers and allow the SPM to put the
core in deeper idle states when the core is idle.

Cc: Kumar Gala 
Signed-off-by: Lina Iyer 
Reviewed-by: Stephen Boyd 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index b3154c0..9fd24bc 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -139,26 +139,26 @@
reg = <0x020b8000 0x1000>, <0x02008000 0x1000>;
};
 
-   saw0: regulator@2089000 {
-   compatible = "qcom,saw2";
+   saw0: power-controller@2089000 {
+   compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
reg = <0x02089000 0x1000>, <0x02009000 0x1000>;
regulator;
};
 
-   saw1: regulator@2099000 {
-   compatible = "qcom,saw2";
+   saw1: power-controller@2099000 {
+   compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
regulator;
};
 
-   saw2: regulator@20a9000 {
-   compatible = "qcom,saw2";
+   saw2: power-controller@20a9000 {
+   compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
reg = <0x020a9000 0x1000>, <0x02009000 0x1000>;
regulator;
};
 
-   saw3: regulator@20b9000 {
-   compatible = "qcom,saw2";
+   saw3: power-controller@20b9000 {
+   compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
reg = <0x020b9000 0x1000>, <0x02009000 0x1000>;
regulator;
};
-- 
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

[PATCH v17 00/11] ARM: qcom: cpuidle support for 8064, 8074, 8084

[Lina Iyer]

Hi,

This v17 revision of patch has minor changes since v16. Primarily rebased on
top of Daniels' changes [1].

Changes since v16:
- Dropped per-cpu cpuidle changes in the cpuidle-arm driver, Daniel submitted
  it as part of his series.
- Rebase on top of [1].
- Return -ENXIO when qcom_cpuidle_init() detects SPM device is not probed yet.
- Declare cpuidle_ops using CPUIDLE_METHOD_OF_DECLARE.

Changes since v15:
https://www.mail-archive.com/devicetree@vger.kernel.org/msg64700.html
- Clean up cpuidle-arm.c to use devm_kzalloc and print error codes.
- Remove qcom,idle-state-stby as a DT mode, instead use the ARM WFI defined in
  ARM cpuidle driver for clock gating/standby modes. The platform driver will
  default to standby for all cpus after executing any low power state. This 
allows
  us to be completely compatible with generic ARM cpuidle driver and not send 
out
  cpu_pm notifications that are sent out for all 'platform states'.
- Cleaned up comments around setting SPM states.
- Platform idle state (SPC) starts at index 1, previous patch was overwritting
  ARM WFI state, which is mandated to be default state at index 0. 
- Removed duplicate cpu_pm_enter() and cpu_pm_exit() callbacks.
- Re-introduce ARM_QCOM_CPUIDLE defconfig item to enable/disable QCOM cpuidle
  support.
- Update documentation on standby state to indicate that this state is no longer
  defined in the DT.
- Remove unused qcom,saw2-v1.* compatibles from documentation.
- Rebased on top of SCM changes that were pulled in Kumar's 'soc' branch [2].
- Removed Reviewed-by tags from DT patches due to change in idle states.

Changes since v14:
- Support for cpuidle_ops
- SPM probe changes to register cpuidle
- Rebase on top of 4.0-rc1
- Remove SCM patches from series. Rebased on top of Kumar's tree
- Removed cpuidle-qcom.c in favor of ARM generic cpuidle driver
- Included Daniel's change for supporting creating cpuidle devices by platform

Tested on: 8074, 8084.

Thanks,
Lina

[1]. https://lkml.org/lkml/2015/3/20/165


Lina Iyer (10):
  ARM: qcom: Add Subsystem Power Manager (SPM) driver
  ARM: cpuidle: qcom: Add documentation for qcom cpuidle states
  ARM: cpuidle: Add cpuidle support for QCOM cpus
  ARM: dts: qcom: Add power-controller device node for 8074 Krait CPUs
  ARM: dts: qcom: Add power-controller device node for 8084 Krait CPUs
  ARM: dts: qcom: Update power-controller device node for 8064 Krait
CPUs
  ARM: dts: qcom: Add idle states device nodes for 8974/8074
  ARM: dts: qcom: Add idle states device nodes for 8084
  ARM: dts: qcom: Add idle state device nodes for 8064
  ARM: qcom: Update defconfig to enable cpuidle

 .../bindings/arm/msm/qcom,idle-state.txt   |  84 +
 .../devicetree/bindings/arm/msm/qcom,saw2.txt  |  29 +-
 arch/arm/boot/dts/qcom-apq8064.dtsi|  30 +-
 arch/arm/boot/dts/qcom-apq8084.dtsi|  40 +-
 arch/arm/boot/dts/qcom-msm8974.dtsi|  40 +-
 arch/arm/configs/qcom_defconfig|   2 +
 drivers/cpuidle/Kconfig.arm|   7 +
 drivers/soc/qcom/Kconfig   |   7 +
 drivers/soc/qcom/Makefile  |   1 +
 drivers/soc/qcom/spm.c | 405 +
 10 files changed, 629 insertions(+), 16 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt
 create mode 100644 drivers/soc/qcom/spm.c

-- 
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

[PATCH net-next 1/5] net: netcp: fix forward port number usage for 10G ethss

[Murali Karicheri]

10G switch requires forward port number in the taginfo field,
where as it should be in packet_info field for necp 1.4 Ethss. So
fill this value correctly in the knav dma descriptor.

Also rename dma_psflags field in struct netcp_tx_pipe to switch_to_port
as it contain no flag, but the switch port number for forwarding the
packet. Add a flag to hold the new flag,  SWITCH_TO_PORT_IN_TAGINFO which
will be set for 10G. This can also used in the future for other flags for
the tx_pipe.

Signed-off-by: Murali Karicheri 
Signed-off-by: WingMan Kwok 
CC: "David S. Miller" 
CC: Mugunthan V N 
CC: "Lad, Prabhakar" 
CC: Grygorii Strashko 
CC: Christoph Jaeger 
CC: Lokesh Vutla 
CC: Markus Pargmann 
CC: Kumar Gala 
CC: Ian Campbell 
CC: Mark Rutland 
CC: Pawel Moll 
CC: Rob Herring 
---
 drivers/net/ethernet/ti/netcp.h   |5 -
 drivers/net/ethernet/ti/netcp_core.c  |   23 +++
 drivers/net/ethernet/ti/netcp_ethss.c |   14 ++
 3 files changed, 29 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/ti/netcp.h b/drivers/net/ethernet/ti/netcp.h
index 906e9bc..bbacf5c 100644
--- a/drivers/net/ethernet/ti/netcp.h
+++ b/drivers/net/ethernet/ti/netcp.h
@@ -41,7 +41,10 @@ struct netcp_tx_pipe {
struct netcp_device *netcp_device;
void*dma_queue;
unsigned intdma_queue_id;
-   u8  dma_psflags;
+   /* To port for packet forwarded to switch. Used only by ethss */
+   u8  switch_to_port;
+#defineSWITCH_TO_PORT_IN_TAGINFO   BIT(0)
+   u8  flags;
void*dma_channel;
const char  *dma_chan_name;
 };
diff --git a/drivers/net/ethernet/ti/netcp_core.c 
b/drivers/net/ethernet/ti/netcp_core.c
index a31a8c3..d867636 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -1098,9 +1098,9 @@ static int netcp_tx_submit_skb(struct netcp_intf *netcp,
struct netcp_tx_pipe *tx_pipe = NULL;
struct netcp_hook_list *tx_hook;
struct netcp_packet p_info;
-   u32 packet_info = 0;
unsigned int dma_sz;
dma_addr_t dma;
+   u32 tmp = 0;
int ret = 0;
 
p_info.netcp = netcp;
@@ -1140,20 +1140,27 @@ static int netcp_tx_submit_skb(struct netcp_intf *netcp,
memmove(p_info.psdata, p_info.psdata + p_info.psdata_len,
p_info.psdata_len);
set_words(psdata, p_info.psdata_len, psdata);
-   packet_info |=
-   (p_info.psdata_len & KNAV_DMA_DESC_PSLEN_MASK) <<
+   tmp |= (p_info.psdata_len & KNAV_DMA_DESC_PSLEN_MASK) <<
KNAV_DMA_DESC_PSLEN_SHIFT;
}
 
-   packet_info |= KNAV_DMA_DESC_HAS_EPIB |
+   tmp |= KNAV_DMA_DESC_HAS_EPIB |
((netcp->tx_compl_qid & KNAV_DMA_DESC_RETQ_MASK) <<
-   KNAV_DMA_DESC_RETQ_SHIFT) |
-   ((tx_pipe->dma_psflags & KNAV_DMA_DESC_PSFLAG_MASK) <<
-   KNAV_DMA_DESC_PSFLAG_SHIFT);
+   KNAV_DMA_DESC_RETQ_SHIFT);
 
-   set_words(&packet_info, 1, &desc->packet_info);
+   if (!(tx_pipe->flags & SWITCH_TO_PORT_IN_TAGINFO)) {
+   tmp |= ((tx_pipe->switch_to_port & KNAV_DMA_DESC_PSFLAG_MASK) <<
+   KNAV_DMA_DESC_PSFLAG_SHIFT);
+   }
+
+   set_words(&tmp, 1, &desc->packet_info);
set_words((u32 *)&skb, 1, &desc->pad[0]);
 
+   if (tx_pipe->flags & SWITCH_TO_PORT_IN_TAGINFO) {
+   tmp = tx_pipe->switch_to_port;
+   set_words((u32 *)&tmp, 1, &desc->tag_info);
+   }
+
/* submit packet descriptor */
ret = knav_pool_desc_map(netcp->tx_pool, desc, sizeof(*desc), &dma,
 &dma_sz);
diff --git a/drivers/net/ethernet/ti/netcp_ethss.c 
b/drivers/net/ethernet/ti/netcp_ethss.c
index 84f5ce5..2be90a5 100644
--- a/drivers/net/ethernet/ti/netcp_ethss.c
+++ b/drivers/net/ethernet/ti/netcp_ethss.c
@@ -1472,15 +1472,21 @@ static int gbe_open(void *intf_priv, struct net_device 
*ndev)
GBE_MAJOR_VERSION(reg), GBE_MINOR_VERSION(reg),
GBE_RTL_VERSION(reg), GBE_IDENT(reg));
 
+   /* For 10G use directed to port */
+   if (gbe_dev->ss_version == XGBE_SS_VERSION_10)
+   gbe_intf->tx_pipe.flags = SWITCH_TO_PORT_IN_TAGINFO;
+
if (gbe_dev->enable_ale)
-   gbe_intf->tx_pipe.dma_psflags = 0;
+   gbe_intf->tx_pipe.switch_to_port = 0;
else
-   gbe_intf->tx_pipe.dma_psflags = port_num;
+   gbe_intf->tx_pipe.switch_to_port = port_num;
 
-   dev_dbg(gbe_dev->dev, "opened TX channel %s: %p with psflags %d\n",
+   dev_dbg(gbe_dev->dev,
+   "opened TX channel %s: %p with to port %d, flags %d\n",
gbe_intf->tx_pipe.dma_chan_name,
gbe_intf->tx_pipe.dma_channel

[PATCH net-next 2/5] net: netcp: use separate reg region for individual ethss modules

[Murali Karicheri]

Ethss has multiple modules within the sub system
 - switch sub system
 - sgmii
 - mdio
 - switch module

NetCP driver re-uses existing davinci mdio driver. It requires to
have its own register region to map the reg space. So restructure
the code to use separate reg region for the individual modules it
manages. Use range property to define register space of NetCP and
use reg property to define individual reg spaces. So MDIO will have
its own reg space to map. This is a pre-requisite to enable MDIO
driver for NetCP.

Signed-off-by: Murali Karicheri 
Signed-off-by: WingMan Kwok 
CC: "David S. Miller" 
CC: Mugunthan V N 
CC: "Lad, Prabhakar" 
CC: Grygorii Strashko 
CC: Christoph Jaeger 
CC: Lokesh Vutla 
CC: Markus Pargmann 
CC: Kumar Gala 
CC: Ian Campbell 
CC: Mark Rutland 
CC: Pawel Moll 
CC: Rob Herring 
---
 .../devicetree/bindings/net/keystone-netcp.txt |   16 +--
 drivers/net/ethernet/ti/netcp_ethss.c  |  130 ++--
 2 files changed, 102 insertions(+), 44 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/keystone-netcp.txt 
b/Documentation/devicetree/bindings/net/keystone-netcp.txt
index f9c0771..8368abd 100644
--- a/Documentation/devicetree/bindings/net/keystone-netcp.txt
+++ b/Documentation/devicetree/bindings/net/keystone-netcp.txt
@@ -49,6 +49,7 @@ Required properties:
 - compatible:  Should be "ti,netcp-1.0"
 - clocks:  phandle to the reference clocks for the subsystem.
 - dma-id:  Navigator packet dma instance id.
+- ranges:  address range of NetCP (includes, Ethernet SS, PA and SA)
 
 Optional properties:
 - reg: register location and the size for the following register
@@ -66,8 +67,10 @@ Required properties:
 - label:   Must be "netcp-gbe" for 1Gb & "netcp-xgbe" for 10Gb.
 - reg: register location and the size for the following register
regions in the specified order.
-   - subsystem registers
-   - serdes registers
+   - switch subsystem registers
+   - sgmii port3/4 module registers (only for NetCP 1.4)
+   - switch module registers
+   - serdes registers (only for 10G)
 - tx-channel:  the navigator packet dma channel name for tx.
 - tx-queue:the navigator queue number associated with the tx dma channel.
 - interfaces:  specification for each of the switch port to be registered as a
@@ -120,14 +123,13 @@ Optional properties:
 
 Example binding:
 
-netcp: netcp@209 {
+netcp: netcp@200 {
reg = <0x2620110 0x8>;
reg-names = "efuse";
compatible = "ti,netcp-1.0";
#address-cells = <1>;
#size-cells = <1>;
-   ranges;
-
+   ranges  = <0 0x200 0xf>;
clocks = <&papllclk>, <&clkcpgmac>, <&chipclk12>;
dma-coherent;
/* big-endian; */
@@ -137,9 +139,9 @@ netcp: netcp@209 {
#address-cells = <1>;
#size-cells = <1>;
ranges;
-   gbe@0x209 {
+   gbe@9 {
label = "netcp-gbe";
-   reg = <0x209 0xf00>;
+   reg = <0x9 0x300>, <0x90400 0x400>, <0x90800 0x700>;
/* enable-ale; */
tx-queue = <648>;
tx-channel = <8>;
diff --git a/drivers/net/ethernet/ti/netcp_ethss.c 
b/drivers/net/ethernet/ti/netcp_ethss.c
index 2be90a5..42592b8 100644
--- a/drivers/net/ethernet/ti/netcp_ethss.c
+++ b/drivers/net/ethernet/ti/netcp_ethss.c
@@ -40,15 +40,18 @@
 #define GBE_MODULE_NAME"netcp-gbe"
 #define GBE_SS_VERSION_14  0x4ed21104
 
+#define GBE_SS_REG_INDEX   0
+#define GBE_SGMII34_REG_INDEX  1
+#define GBE_SM_REG_INDEX   2
+/* offset relative to base of GBE_SS_REG_INDEX */
 #define GBE13_SGMII_MODULE_OFFSET  0x100
-#define GBE13_SGMII34_MODULE_OFFSET0x400
-#define GBE13_SWITCH_MODULE_OFFSET 0x800
-#define GBE13_HOST_PORT_OFFSET 0x834
-#define GBE13_SLAVE_PORT_OFFSET0x860
-#define GBE13_EMAC_OFFSET  0x900
-#define GBE13_SLAVE_PORT2_OFFSET   0xa00
-#define GBE13_HW_STATS_OFFSET  0xb00
-#define GBE13_ALE_OFFSET   0xe00
+/* offset relative to base of GBE_SM_REG_INDEX */
+#define GBE13_HOST_PORT_OFFSET 0x34
+#define GBE13_SLAVE_PORT_OFFSET0x60
+#define GBE13_EMAC_OFFSET  0x100
+#define GBE13_SLAVE_PORT2_OFFSET   0x200
+#define GBE13_HW_STATS_OFFSET  0x300
+#define GBE13_ALE_OFFSET   0x600
 #define GBE13_HOST_PORT_NUM0
 #define GBE13_NUM_SLAVES   4
 #define GBE13_NUM_ALE_PORTS(GBE13_NUM_SLAVES + 1)
@@ -58,14 +61,18 @@
 #define XGBE_MODULE_NAME   "netcp-xgbe"
 #define XGBE_SS_VERSION_10 0x4ee42100
 
-#define XGBE_SERDES_REG_INDEX  1
+#define XGBE_SS_REG_INDEX  0
+#define XGBE_SM_REG_INDEX

[PATCH net-next 3/5] net: netcp: select davinci_mdio driver by default

[Murali Karicheri]

Keystone netcp driver re-uses davinci mdio driver. So enable it
by default for keystone netcp driver.

Signed-off-by: Murali Karicheri 
Signed-off-by: WingMan Kwok 
CC: "David S. Miller" 
CC: Mugunthan V N 
CC: "Lad, Prabhakar" 
CC: Grygorii Strashko 
CC: Christoph Jaeger 
CC: Lokesh Vutla 
CC: Markus Pargmann 
CC: Kumar Gala 
CC: Ian Campbell 
CC: Mark Rutland 
CC: Pawel Moll 
CC: Rob Herring 
---
 drivers/net/ethernet/ti/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index f6a7109..631e0af 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -88,6 +88,7 @@ config TI_CPTS
 config TI_KEYSTONE_NETCP
tristate "TI Keystone NETCP Core Support"
select TI_CPSW_ALE
+   select TI_DAVINCI_MDIO
depends on OF
depends on KEYSTONE_NAVIGATOR_DMA && KEYSTONE_NAVIGATOR_QMSS
---help---
-- 
1.7.9.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 net-next 4/5] net: netcp: enclose macros in parentheses

[Murali Karicheri]

Fix following checkpatch error. It seems to have passed checkpatch
last time when original code was introduced.

 ERROR: Macros with complex values should be enclosed in parentheses
 #172: FILE: drivers/net/ethernet/ti/netcp_ethss.c:869:

Signed-off-by: Murali Karicheri 
Signed-off-by: WingMan Kwok 
CC: "David S. Miller" 
CC: Mugunthan V N 
CC: "Lad, Prabhakar" 
CC: Grygorii Strashko 
CC: Christoph Jaeger 
CC: Lokesh Vutla 
CC: Markus Pargmann 
CC: Kumar Gala 
CC: Ian Campbell 
CC: Mark Rutland 
CC: Pawel Moll 
CC: Rob Herring 

---
 drivers/net/ethernet/ti/netcp_ethss.c |  523 +
 1 file changed, 272 insertions(+), 251 deletions(-)

diff --git a/drivers/net/ethernet/ti/netcp_ethss.c 
b/drivers/net/ethernet/ti/netcp_ethss.c
index 42592b8..f8f3be3 100644
--- a/drivers/net/ethernet/ti/netcp_ethss.c
+++ b/drivers/net/ethernet/ti/netcp_ethss.c
@@ -482,275 +482,296 @@ struct netcp_ethtool_stat {
int offset;
 };
 
-#define GBE_STATSA_INFO(field) "GBE_A:"#field, GBE_STATSA_MODULE,\
-   FIELD_SIZEOF(struct gbe_hw_stats, field), \
-   offsetof(struct gbe_hw_stats, field)
+#define GBE_STATSA_INFO(field) \
+{  \
+   "GBE_A:"#field, GBE_STATSA_MODULE,  \
+   FIELD_SIZEOF(struct gbe_hw_stats, field),   \
+   offsetof(struct gbe_hw_stats, field)\
+}
 
-#define GBE_STATSB_INFO(field) "GBE_B:"#field, GBE_STATSB_MODULE,\
-   FIELD_SIZEOF(struct gbe_hw_stats, field), \
-   offsetof(struct gbe_hw_stats, field)
+#define GBE_STATSB_INFO(field) \
+{  \
+   "GBE_B:"#field, GBE_STATSB_MODULE,  \
+   FIELD_SIZEOF(struct gbe_hw_stats, field),   \
+   offsetof(struct gbe_hw_stats, field)\
+}
 
-#define GBE_STATSC_INFO(field) "GBE_C:"#field, GBE_STATSC_MODULE,\
-   FIELD_SIZEOF(struct gbe_hw_stats, field), \
-   offsetof(struct gbe_hw_stats, field)
+#define GBE_STATSC_INFO(field) \
+{  \
+   "GBE_C:"#field, GBE_STATSC_MODULE,  \
+   FIELD_SIZEOF(struct gbe_hw_stats, field),   \
+   offsetof(struct gbe_hw_stats, field)\
+}
 
-#define GBE_STATSD_INFO(field) "GBE_D:"#field, GBE_STATSD_MODULE,\
-   FIELD_SIZEOF(struct gbe_hw_stats, field), \
-   offsetof(struct gbe_hw_stats, field)
+#define GBE_STATSD_INFO(field) \
+{  \
+   "GBE_D:"#field, GBE_STATSD_MODULE,  \
+   FIELD_SIZEOF(struct gbe_hw_stats, field),   \
+   offsetof(struct gbe_hw_stats, field)\
+}
 
 static const struct netcp_ethtool_stat gbe13_et_stats[] = {
/* GBE module A */
-   {GBE_STATSA_INFO(rx_good_frames)},
-   {GBE_STATSA_INFO(rx_broadcast_frames)},
-   {GBE_STATSA_INFO(rx_multicast_frames)},
-   {GBE_STATSA_INFO(rx_pause_frames)},
-   {GBE_STATSA_INFO(rx_crc_errors)},
-   {GBE_STATSA_INFO(rx_align_code_errors)},
-   {GBE_STATSA_INFO(rx_oversized_frames)},
-   {GBE_STATSA_INFO(rx_jabber_frames)},
-   {GBE_STATSA_INFO(rx_undersized_frames)},
-   {GBE_STATSA_INFO(rx_fragments)},
-   {GBE_STATSA_INFO(rx_bytes)},
-   {GBE_STATSA_INFO(tx_good_frames)},
-   {GBE_STATSA_INFO(tx_broadcast_frames)},
-   {GBE_STATSA_INFO(tx_multicast_frames)},
-   {GBE_STATSA_INFO(tx_pause_frames)},
-   {GBE_STATSA_INFO(tx_deferred_frames)},
-   {GBE_STATSA_INFO(tx_collision_frames)},
-   {GBE_STATSA_INFO(tx_single_coll_frames)},
-   {GBE_STATSA_INFO(tx_mult_coll_frames)},
-   {GBE_STATSA_INFO(tx_excessive_collisions)},
-   {GBE_STATSA_INFO(tx_late_collisions)},
-   {GBE_STATSA_INFO(tx_underrun)},
-   {GBE_STATSA_INFO(tx_carrier_sense_errors)},
-   {GBE_STATSA_INFO(tx_bytes)},
-   {GBE_STATSA_INFO(tx_64byte_frames)},
-   {GBE_STATSA_INFO(tx_65_to_127byte_frames)},
-   {GBE_STATSA_INFO(tx_128_to_255byte_frames)},
-   {GBE_STATSA_INFO(tx_256_to_511byte_frames)},
-   {GBE_STATSA_INFO(tx_512_to_1023byte_frames)},
-   {GBE_STATSA_INFO(tx_1024byte_frames)},
-   {GBE_STATSA_INFO(net_bytes)},
-   {GBE_STATSA_INFO(rx_sof_overruns)},
-   {GBE_STATSA_INFO(rx_mof_overruns)},
-   {GBE_STATSA_INFO(rx_dma_overru

[PATCH net-next 0/5] NetCP: Add support for version 1.5

[Murali Karicheri]

NetCP 1.5 is used in newer K2 SoCs from Texas Instruments
such as K2E, K2L etc. This patch series add support for Ethss
driver for this version of NetCP. While at it, fix couple of
bugs in the original driver.

One of the earlier patch "net: netcp: select davinci_mdio driver
by default" is folded onto this series.

Please review and let me know your comments.

Thanks 

CC: "David S. Miller" 
CC: Mugunthan V N 
CC: "Lad, Prabhakar" 
CC: Grygorii Strashko 
CC: Christoph Jaeger 
CC: Lokesh Vutla 
CC: Markus Pargmann 
CC: Kumar Gala 
CC: Ian Campbell 
CC: Mark Rutland 
CC: Pawel Moll 
CC: Rob Herring 

Murali Karicheri (4):
  net: netcp: fix forward port number usage for 10G ethss
  net: netcp: use separate reg region for individual ethss modules
  net: netcp: select davinci_mdio driver by default
  net: netcp: enclose macros in parentheses

WingMan Kwok (1):
  net: netcp: ethss: enhancement to support NetCP 1.5 ethss

 .../devicetree/bindings/net/keystone-netcp.txt |   34 +-
 drivers/net/ethernet/ti/Kconfig|1 +
 drivers/net/ethernet/ti/netcp.h|5 +-
 drivers/net/ethernet/ti/netcp_core.c   |   23 +-
 drivers/net/ethernet/ti/netcp_ethss.c  | 1581 
 5 files changed, 1303 insertions(+), 341 deletions(-)

-- 
1.7.9.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 net-next 5/5] net: netcp: ethss: enhancement to support NetCP 1.5 ethss

[Murali Karicheri]

From: WingMan Kwok 

NetCP 1.5 available on newer K2 SoCs such as K2E and K2L introduced 3
variants of the ethss subsystem, 9 port, 5 port and 2 port. These have
one host port towards the CPU and N external slave ports.

To customize the driver for these new ethss sub systems, multiple
compatibility strings are introduced. Currently some of parameters that
are different on different variants such as number of ALE ports, stats
modules and number of ports are defined through constants. These are now
changed to variables in gbe_priv data that get set based on the
compatibility string. This is required as there are no hardware
identification registers available to distinguish among the variants
of NetCP 1.5 ethss. However there is identification register available
to differentiate between NetCP 1.4 vs NetCP 1.5 and the same is made use
of in the code to differentiate them.

For more reading on the details of this peripheral, please refer to the
User Guide available at http://www.ti.com/lit/pdf/spruhz3

Signed-off-by: Murali Karicheri 
Signed-off-by: WingMan Kwok 
CC: "David S. Miller" 
CC: Mugunthan V N 
CC: "Lad, Prabhakar" 
CC: Grygorii Strashko 
CC: Christoph Jaeger 
CC: Lokesh Vutla 
CC: Markus Pargmann 
CC: Kumar Gala 
CC: Ian Campbell 
CC: Mark Rutland 
CC: Pawel Moll 
CC: Rob Herring 
---
 .../devicetree/bindings/net/keystone-netcp.txt |   18 +
 drivers/net/ethernet/ti/netcp_ethss.c  |  920 +++-
 2 files changed, 902 insertions(+), 36 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/keystone-netcp.txt 
b/Documentation/devicetree/bindings/net/keystone-netcp.txt
index 8368abd..d0e6fa3 100644
--- a/Documentation/devicetree/bindings/net/keystone-netcp.txt
+++ b/Documentation/devicetree/bindings/net/keystone-netcp.txt
@@ -65,12 +65,30 @@ NetCP device properties: Device specification for NetCP 
sub-modules.
 1Gb/10Gb (gbe/xgbe) ethernet switch sub-module specifications.
 Required properties:
 - label:   Must be "netcp-gbe" for 1Gb & "netcp-xgbe" for 10Gb.
+- compatible:  Must be one of below:-
+   "ti,netcp-gbe" for 1GbE on NetCP 1.4
+   "ti,netcp-gbe-5" for 1GbE N NetCP 1.5 (N=5)
+   "ti,netcp-gbe-9" for 1GbE N NetCP 1.5 (N=9)
+   "ti,netcp-gbe-2" for 1GbE N NetCP 1.5 (N=2)
+   "ti,netcp-xgbe" for 10 GbE
+
 - reg: register location and the size for the following register
regions in the specified order.
- switch subsystem registers
- sgmii port3/4 module registers (only for NetCP 1.4)
- switch module registers
- serdes registers (only for 10G)
+
+   NetCP 1.4 ethss, here is the order
+   index #0 - switch subsystem registers
+   index #1 - sgmii port3/4 module registers
+   index #2 - switch module registers
+
+   NetCP 1.5 ethss 9 port, 5 port and 2 port
+   index #0 - switch subsystem registers
+   index #1 - switch module registers
+   index #2 - serdes registers
+
 - tx-channel:  the navigator packet dma channel name for tx.
 - tx-queue:the navigator queue number associated with the tx dma channel.
 - interfaces:  specification for each of the switch port to be registered as a
diff --git a/drivers/net/ethernet/ti/netcp_ethss.c 
b/drivers/net/ethernet/ti/netcp_ethss.c
index f8f3be3..2bef655 100644
--- a/drivers/net/ethernet/ti/netcp_ethss.c
+++ b/drivers/net/ethernet/ti/netcp_ethss.c
@@ -53,10 +53,31 @@
 #define GBE13_HW_STATS_OFFSET  0x300
 #define GBE13_ALE_OFFSET   0x600
 #define GBE13_HOST_PORT_NUM0
-#define GBE13_NUM_SLAVES   4
-#define GBE13_NUM_ALE_PORTS(GBE13_NUM_SLAVES + 1)
 #define GBE13_NUM_ALE_ENTRIES  1024
 
+/* 1G Ethernet NU SS defines */
+#define GBENU_MODULE_NAME  "netcp-gbenu"
+#define GBE_SS_ID_NU   0x4ee6
+#define GBE_SS_ID_2U   0x4ee8
+
+#define IS_SS_ID_MU(d) \
+   ((GBE_IDENT((d)->ss_version) == GBE_SS_ID_NU) || \
+(GBE_IDENT((d)->ss_version) == GBE_SS_ID_2U))
+
+#define IS_SS_ID_NU(d) \
+   (GBE_IDENT((d)->ss_version) == GBE_SS_ID_NU)
+
+#define GBENU_SS_REG_INDEX 0
+#define GBENU_SM_REG_INDEX 1
+#define GBENU_SGMII_MODULE_OFFSET  0x100
+#define GBENU_HOST_PORT_OFFSET 0x1000
+#define GBENU_SLAVE_PORT_OFFSET0x2000
+#define GBENU_EMAC_OFFSET  0x2330
+#define GBENU_HW_STATS_OFFSET  0x1a000
+#define GBENU_ALE_OFFSET   0x1e000
+#define GBENU_HOST_PORT_NUM0
+#define GBENU_NUM_ALE_ENTRIES  1024
+
 /* 10G Ethernet SS defines */
 #define XGBE_MODULE_NAME   "netcp-xgbe"
 #define XGBE_SS_VERSION_10 0x4ee42100
@@ -74,8 +95,6 @@
 #define XGBE10_ALE_OFFSET  0x700
 #define XGBE10_HW_STATS_OFFSET  

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Pavel Machek]

Hi!

> >> 
> >> Wouldn’t it be easier to simply write
> >> 
> >> &uart1 {
> >>vdd-suppy = <&vaux4>;
> >> }
> > 
> > Easier to write: certainly.
> > Easier to justify? No.
> 
> I just justified.
> 
> > Easier to get merged upstream?  Definitely not.
> 
> Are you the maintainer?

And you? I believe Neil is right here, and this kind of shortcut can
not be taken.

> > After all, the uart itself doesn't require a power supply.
> > It is the device connected to the uart which requires the power supply.
> 
> Yes.

There's UART, long rs/232 cable, and a GPS.

UART needs some kind of power supply, to present voltages on the
rs/232 cable.

GPS needs some kind of power supply to work.

They are different power supplies, and we should have way to tell them
apart.
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

[PATCH 1/3] ARM: dts: OMAP5+: separate the cpu thermal zone definition from omap4

[Nishanth Menon]

From: Tero Kristo 

OMAP4 has a finer counter granularity, which allows for a delay of 1000ms
in the thermal zone polling intervals. OMAP5/DRA7 have different counter
mechanism, which allows at maximum a 500ms timer. Adjust the cpu thermal
zone accordingly for OMAP5/DRA7.

Signed-off-by: Tero Kristo 
Signed-off-by: Nishanth Menon 
---
 arch/arm/boot/dts/omap5-cpu-thermal.dtsi |   41 ++
 arch/arm/boot/dts/omap5.dtsi |2 +-
 2 files changed, 42 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/omap5-cpu-thermal.dtsi

diff --git a/arch/arm/boot/dts/omap5-cpu-thermal.dtsi 
b/arch/arm/boot/dts/omap5-cpu-thermal.dtsi
new file mode 100644
index ..4a6427c1e47e
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-cpu-thermal.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Device Tree Source for OMAP4/5 SoC CPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Tero Kristo 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include 
+
+cpu_thermal: cpu_thermal {
+   polling-delay-passive = <250>; /* milliseconds */
+   polling-delay = <500>; /* milliseconds */
+
+   /* sensor   ID */
+   thermal-sensors = <&bandgap 0>;
+
+   cpu_trips: trips {
+   cpu_alert0: cpu_alert {
+   temperature = <10>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "passive";
+   };
+   cpu_crit: cpu_crit {
+   temperature = <125000>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "critical";
+   };
+   };
+
+   cpu_cooling_maps: cooling-maps {
+   map0 {
+   trip = <&cpu_alert0>;
+   cooling-device =
+   <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index ddff674bd05e..e650d4eb59dd 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -67,7 +67,7 @@
};
 
thermal-zones {
-   #include "omap4-cpu-thermal.dtsi"
+   #include "omap5-cpu-thermal.dtsi"
#include "omap5-gpu-thermal.dtsi"
#include "omap5-core-thermal.dtsi"
};
-- 
1.7.9.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 3/3] ARM: dts: am57xx-beagle-x15: Add thermal map

[Nishanth Menon]

BeagleBoard-X15 has capability for a fan and has an onboard TMP102
temperature sensor as well. This allows us to create a new thermal
zone (called, un-imaginatively "board"), and allows us to use some
active cooling as temperatures start edge upward in the system by
creating a new alert temperature (emperically 50C) for cpu.

NOTE: Fan is NOT mounted by default on the platform, in such a case,
all we end up doing is switch on a regulator and leak very minimal
current.

Signed-off-by: Nishanth Menon 
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts |   49 +++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 41642fe770a1..6a3621c23017 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -86,6 +86,7 @@
gpios =  <&tps659038_gpio 1 GPIO_ACTIVE_HIGH>;
gpio-fan,speed-map = <0 0>,
 <13000 1>;
+   #cooling-cells = <2>;
};
 
extcon_usb1: extcon_usb1 {
@@ -441,6 +442,7 @@
pinctrl-0 = <&tmp102_pins_default>;
interrupt-parent = <&gpio7>;
interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
+   #thermal-sensor-cells = <1>;
};
 };
 
@@ -559,3 +561,50 @@
 &usb2 {
dr_mode = "peripheral";
 };
+
+&cpu_trips {
+   cpu_alert1: cpu_alert1 {
+   temperature = <5>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "active";
+   };
+};
+
+&cpu_cooling_maps {
+   map1 {
+   trip = <&cpu_alert1>;
+   cooling-device = <&gpio_fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+};
+
+&thermal_zones {
+   board_thermal: board_thermal {
+   polling-delay-passive = <1250>; /* milliseconds */
+   polling-delay = <1500>; /* milliseconds */
+
+   /* sensor   ID */
+   thermal-sensors = <&tmp102 0>;
+
+   board_trips: trips {
+   board_alert0: board_alert {
+   temperature = <4>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "active";
+   };
+
+   board_crit: board_crit {
+   temperature = <105000>; /* millicelsius */
+   hysteresis = <0>; /* millicelsius */
+   type = "critical";
+   };
+   };
+
+   board_cooling_maps: cooling-maps {
+   map0 {
+   trip = <&board_alert0>;
+   cooling-device =
+ <&gpio_fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   };
+   };
+};
-- 
1.7.9.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 0/3] ARM: omap5/dra7/x15: Thermal dts patches

[Nishanth Menon]

Hi,

Here are a few pending patches for DRA7/ OMAP5 and patch hooking the
GPIO fan to the thermal framework.

Tested on BeagleBoard-X15, uEVM with next-20150320. (just load up
cpufreq_dt and gpio_fan modules with omap2plus_defconfig, run cpuburn
to generate thermal and just wait for the fan to trigger - and it does-
we dont hit the frequency throttling temps)

The patches are based on
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
branch: omap-for-v4.1/dt-v2 10709c0858d8 ARM: dts: Update Nanobone dts file

The patch #3(gpio fan-thermal hookup) depends on 
(from linus master):
12ca7188468e thermal: Introduce dummy functions when thermal is not defined
and the following currently in linux-next(next-20150320) queued for future.
b5cf88e46bad (gpio-fan): Add thermal control hooks

Keerthy (1):
  ARM: dts: DRA7: Add bandgap and related thermal nodes

Nishanth Menon (1):
  ARM: dts: am57xx-beagle-x15: Add thermal map

Tero Kristo (1):
  ARM: dts: OMAP5+: separate the cpu thermal zone definition from omap4

 arch/arm/boot/dts/am57xx-beagle-x15.dts  |   49 ++
 arch/arm/boot/dts/dra7.dtsi  |   12 
 arch/arm/boot/dts/dra72x.dtsi|9 ++
 arch/arm/boot/dts/dra74x.dtsi|9 ++
 arch/arm/boot/dts/omap5-cpu-thermal.dtsi |   41 +
 arch/arm/boot/dts/omap5.dtsi |2 +-
 6 files changed, 121 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/omap5-cpu-thermal.dtsi

Regards,
Nishanth Menon
-- 
1.7.9.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 2/3] ARM: dts: DRA7: Add bandgap and related thermal nodes

[Nishanth Menon]

From: Keerthy 

Add bandgap and related thermal nodes. The patch adds 5 thermal
sensors. Only one cooling device for mpu as of now. The sensors are
the exact same on both dra72 and dra7.

Signed-off-by: Keerthy 
Signed-off-by: Nishanth Menon 
---
 arch/arm/boot/dts/dra7.dtsi   |   12 
 arch/arm/boot/dts/dra72x.dtsi |9 +
 arch/arm/boot/dts/dra74x.dtsi |9 +
 3 files changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index eea4a54d6cb3..4b975cc377fd 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -177,6 +177,18 @@
};
};
 
+   bandgap: bandgap@4a0021e0 {
+   reg = <0x4a0021e0 0xc
+   0x4a00232c 0xc
+   0x4a002380 0x2c
+   0x4a0023C0 0x3c
+   0x4a002564 0x8
+   0x4a002574 0x50>;
+   compatible = "ti,dra752-bandgap";
+   interrupts = ;
+   #thermal-sensor-cells = <1>;
+   };
+
cm_core_aon: cm_core_aon@4a005000 {
compatible = "ti,dra7-cm-core-aon";
reg = <0x4a005000 0x2000>;
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index e5a3d23a3df1..43bd0709bde9 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -20,6 +20,11 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0>;
+
+   /* cooling options */
+   cooling-min-level = <0>;
+   cooling-max-level = <2>;
+   #cooling-cells = <2>; /* min followed by max */
};
};
 
@@ -27,4 +32,8 @@
compatible = "arm,cortex-a15-pmu";
interrupts = ;
};
+
+   thermal_zones: thermal-zones {
+   #include "omap5-cpu-thermal.dtsi"
+   };
 };
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index 10173fab1a15..4f2c870836fe 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -31,6 +31,11 @@
clock-names = "cpu";
 
clock-latency = <30>; /* From omap-cpufreq driver */
+
+   /* cooling options */
+   cooling-min-level = <0>;
+   cooling-max-level = <2>;
+   #cooling-cells = <2>; /* min followed by max */
};
cpu@1 {
device_type = "cpu";
@@ -45,6 +50,10 @@
 ;
};
 
+   thermal_zones: thermal-zones {
+   #include "omap5-cpu-thermal.dtsi"
+   };
+
ocp {
omap_dwc3_4: omap_dwc3_4@4894 {
compatible = "ti,dwc3";
-- 
1.7.9.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 2/3] TTY: add support for tty_slave devices.

[Pavel Machek]

Hi!

(And yes, I now see dts examples, sorry for the noise.)

Acked-by: Pavel Machek 

Minor nits below.

> --- /dev/null
> +++ b/drivers/tty/slave/tty_slave_core.c
> @@ -0,0 +1,136 @@
> +/*
> + * tty-slave-core - device bus for tty slaves

Filename actually uses underscores.

> + container_of(parent, struct tty_slave, dev);
> + tty->ops = &dev->ops;
> + }
> +}
> +EXPORT_SYMBOL(tty_slave_activate);

Not "_GPL"?

> +postcore_initcall(tty_slave_init);
> +module_exit(tty_slave_exit);

Should it have MODULE_LICENSE tag?


> +int tty_register_finalize(struct tty_driver *driver, struct device *dev)
> +{
> + int retval;
> + bool cdev = false;
> + int index = dev->devt - MKDEV(driver->major,
> +   driver->minor_start);
> + printk("REGISTER %d %d 0x%x %d\n", driver->major, driver->minor_start, 
> dev->devt, index);

That printk should probably be removed for merge?

> + if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) {
> + retval = tty_cdev_add(driver,
> +   dev->devt,
> +   index, 1);

You can put this on one line.

> --- /dev/null
> +++ b/include/linux/tty_slave.h
> @@ -0,0 +1,26 @@
> +
> +struct tty_slave {
> + struct device *tty_dev;
> + struct tty_driver *tty_drv;
> + struct tty_operations ops;
> + struct device dev;
> +};

Header files usually have #include guards, and some kind of comment on
top.

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 0/3] tty slave device support - version 3.

[Pavel Machek]

Hi!

>  here is version 3 of support for tty-slaves.
> 
>  This version introduces a new bus-type for tty-slaves, and causes
>  a tty-slave device to appear in /sys/devices between the uart and the
>  tty.
>  It effectively intercepts and calls from the tty to the uart (i.e. any
>  tty_operations) and applies extra functionality at that point.
> 
>  Currently the only driver intercepts open and close.
>  It powers on the device on open, and powers off at last-close.
> 
>  Power can be controlled by a regulator or by toggling a GPIO.
> 
>  I think I've incorporated most of the feed back I received from
>  previous versions, but if I missed something - I apologize.  If
>  this approach is structurally acceptable then I can fix up all the
>  smaller issues.

Do you have dts example? Anyway, we'll need something similar for
bluetooth on N900. But we'd like the /dev/ttyXX not to be visible to
the userspace in that case.

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 3/4 v4] mailbox: Enable BCM2835 mailbox support

[Stephen Warren]

On 03/20/2015 11:24 AM, Eric Anholt wrote:

Stephen Warren  writes:


On 03/18/2015 05:28 PM, Eric Anholt wrote:

Stephen Warren  writes:


On 03/12/2015 08:32 PM, Eric Anholt wrote:

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?


I guess?  If we found another firmware protocol, we could have
that device's dt just specify a different compatible string.  But
in the absence of another firmware to talk to, I'm not sure what
you want here.


I would expect the mailbox driver to expose a single channel that just
transports 32-bit values, since the HW doesn't impose any kind of
structure on the values it transports AFAIK. Clients of the mailbox
driver would formulate the messages they send through the mailox using
the macros above.

I'm not sure whether the mailbox core allows multiple clients for the
same mailbox channel though? This HW appears to require it.


Yeah, that's the problem.


I expect you'd end up representing the low-level mbox HW and the remote 
firmware as separate nodes in DT. There's certainly precedent for 
representing firmware in DT as a separate node. Perhaps something like:


// Exports just one channel, since there's 1 channel in HW
// Driver solely transports u32s through the registers and nothing else
// Driver allows a single client on the channel
mailbox: mailbox@7e00b800 {
compatible = "brcm,bcm2835-mbox";
reg = <0x7e00b880 0x40>;
interrupts = <0 1>;
#mbox-cells = <1>;
};

// implements all RPI- (rather than bcm2835-)specific aspects of the
// firmware interface, such as merging data and channel ID into the data
// sent into the mailbox registers, handling multiple clients on a
// channel, etc.
firmware {
compatible = "raspberrypi,firmware";
mboxes = <&mailbox 8>;
};

The driver for the FW node could either register itself with all the 
relevant subsystems (power domains, clocks, ...) or in turn exports its 
services to other nodes like:


  firmware {
compatible = "raspberrypi,firmware";
mboxes = <&mailbox 8>;
+   #fw-cells = <1>; # or whatever's needed
  };

clocks {
compatible = "raspberrypi,clocks";
fw = <&firmware 0>; // or whatever channel # clocks are on
};
--
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/7] dt: dtb version: add version info to dtb

[Uwe Kleine-König]

Hello,

On Fri, Mar 20, 2015 at 08:46:09AM -0500, Rob Herring wrote:
> On Wed, Mar 18, 2015 at 10:29 PM, Frank Rowand  wrote:
> > Can this be added to the next trees to get some test exposure before 
> > submitting
> > to Linus?
> 
> No. I've yet to see anyone think this is a good idea.
To push the balance a bit into the IMHO right direction: I think the
version info is a bad idea and fully agree with Russell's concerns.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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/5] iommu/mediatek: Add mt8173 IOMMU driver

[Robin Murphy]

On 18/03/15 11:22, Yong Wu wrote:

Hi Tomasz,
Thanks very much for your review. please help check below.
The others I will fix in the next version.

Hi Robin,
There are some place I would like you can have a look and give me
some suggestion.

On Wed, 2015-03-11 at 19:53 +0900, Tomasz Figa wrote:

Hi,

Please find next part of my comments inline.

On Fri, Mar 6, 2015 at 7:48 PM,   wrote:

[snip]


+/*
+ * pimudev is a global var for dma_alloc_coherent.
+ * It is not accepatable, we will delete it if "domain_alloc" is enabled


It looks like we indeed need to use dma_alloc_coherent() and we don't
have a good way to pass the device pointer to domain_init callback.

If you don't expect SoCs in the nearest future to have multiple M4U
blocks, then I guess this global variable could stay, after changing
the comment into an explanation why it's correct. Also it should be
moved to the top of the file, below #include directives, as this is
where usually global variables are located.

@Robin,
  We have merged this patch[0] in order to delete the global var, But
it seems that your patch of "arm64:IOMMU" isn't based on it right row.
it will build fail.


Yeah, I've not yet managed to try pulling in that series (much as I 
approve of it), partly as I know doing so is going to lean towards a 
not-insignificant rework and I'd rather avoid picking up more unmerged 
dependencies to block getting _something_ in for arm64 (which we can 
then improve).




[0]:http://lists.linuxfoundation.org/pipermail/iommu/2015-January/011939.html


+ */
+static struct device *pimudev;
+

[snip]

+
+static int mtk_iommu_attach_device(struct iommu_domain *domain,
+  struct device *dev)
+{
+   unsigned long flags;
+   struct mtk_iommu_domain *priv = domain->priv;
+   struct mtk_iommu_info *piommu = priv->piommuinfo;
+   struct of_phandle_args out_args = {0};
+   struct device *imudev;
+   unsigned int i = 0;
+
+   if (!piommu)


Could you explain when this can happen?

If we call arch_setup_dma_ops to create a iommu domain,
it will enter iommu_dma_attach_device, then enter here. At that time, we
don't add the private data to this "struct iommu_domain *".
@Robin, Could this be improved?


Calling arch_setup_dma_ops() from the driver looks plain wrong, 
especially given that you apparently attach the IOMMU to itself - if you 
want your own domain you should use iommu_dma_create_domain(). I admit 
that still leaves you having to dance around a bit in order to tear down 
the automatic domains for now, but hopefully we'll get the core code 
sorted out sooner rather than later.





+   goto imudev;


return 0;


+   else


No else needed.


+   imudev = piommu->dev;
+
+   spin_lock_irqsave(&priv->portlock, flags);


What is protected by this spinlock?

We will write a register of the local arbiter while config port. If
some modules are in the same local arbiter, it may be overwrite. so I
add it here.



+
+   while (!of_parse_phandle_with_args(dev->of_node, "iommus",
+  "#iommu-cells", i, &out_args)) {
+   if (1 == out_args.args_count) {


Can we be sure that this is actually referring to our IOMMU?

Maybe this should be rewritten to

if (out_args.np != imudev->of_node)
 continue;
if (out_args.args_count != 1) {
 dev_err(imudev, "invalid #iommu-cells property for IOMMU %s\n",

}


+   unsigned int portid = out_args.args[0];
+
+   dev_dbg(dev, "iommu add port:%d\n", portid);


imudev should be used here instead of dev.


+
+   mtk_iommu_config_port(piommu, portid);
+
+   if (i == 0)
+   dev->archdata.dma_ops =
+   piommu->dev->archdata.dma_ops;


Shouldn't this be set automatically by IOMMU or DMA mapping core?

@Robin,
  In the original "arm_iommu_attach_device" of arm/mm, it will call
set_dma_ops to add iommu_ops for each iommu device.
But iommu_dma_attach_device don't help this, so I have to add it here.
Could this be improved?


If you implemented a simple of_xlate callback so that the core code 
handles the dma_ops as intended, I think the simplest cheat would be to 
check the client device's domain, either on attachment or when they 
start mapping/unmapping, and move them to your own domain if necessary. 
I'm putting together a v3 of the DMA mapping series, so I'll have a look 
to see if I can squeeze in a way to make that a bit less painful until 
we solve it properly.



Robin.




+   }
+   i++;
+   }
+
+   spin_unlock_irqrestore(&priv->portlock, flags);
+
+imudev:
+   return 0;
+}
+
+static void mtk_iommu_detach_device(struct iommu_domain *domain,
+   struct device *dev)
+{


No hardware (de)configuration or clean-up necessary?

I will ad

[PATCH v2 10/13] ARM: dts: sun4i: Enable USB DRC on Chuwi V7 CW0825

[Hans de Goede]

Enable the otg/drc usb controller on the Chuwi V7 CW0825 tablet.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts | 31 +
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts 
b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
index 97fca89..8a2f4c5 100644
--- a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
+++ b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
@@ -111,6 +111,26 @@
status = "okay";
 };
 
+&pio {
+   usb0_id_detect_pin: usb0_id_detect_pin@0 {
+   allwinner,pins = "PH4";
+   allwinner,function = "gpio_in";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
+   allwinner,pins = "PH5";
+   allwinner,function = "gpio_in";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+};
+
+®_usb0_vbus {
+   status = "okay";
+};
+
 ®_usb2_vbus {
status = "okay";
 };
@@ -121,7 +141,18 @@
status = "okay";
 };
 
+&usb_otg {
+   dr_mode = "otg";
+   status = "okay";
+};
+
 &usbphy {
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb0_id_detect_pin
+&usb0_vbus_detect_pin>;
+   usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+   usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+   usb0_vbus-supply = <®_usb0_vbus>;
usb2_vbus-supply = <®_usb2_vbus>;
status = "okay";
 };
-- 
2.3.3

--
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/2] Documentation: devicetree: m25p80: add "nor-jedec" binding

[Brian Norris]

On Thu, Mar 12, 2015 at 10:58:24AM +, Mark Rutland wrote:
> On Wed, Mar 11, 2015 at 09:57:25PM +, Brian Norris wrote:
> > Almost all flash that are "compatible" with m25p80 support the JEDEC
> > READ ID opcode (0x95), and in fact, that is often the only thing that is
> > used to differentiate them. Let's add a compatible string that
> > represents this lowest common denominator of compatibility.
> > 
> > Device trees can still specify manufacturer/device names in addition,
> > but (until some reason is found to differentiate between them through
> > device tree) software will likely want to bind just against the generic
> > name, and avoid unnecessarily growing its device ID binding tables.
> > 
> > This is related to the work of commit a5b7616c55e1 ("mtd:
> > m25p80,spi-nor: Fix module aliases for m25p80"), which showed that
> > maintaining these device tables as stable device-tree/modalias binding
> > tables is not a worthwhile burden for mostly-comptatible flash.
> > 
> > At the same time, let's update the binding doc to point to the
> > m25p_ids[] ID list instead of spi_nor_ids[]. The former can be used for
> > device tree bindings, but the latter cannot. In the future, we should
> > pare down the m25p_ids[] list to only those IDs which are actually used
> > in device trees.
> 
> We really should not be referring to C files for the binding. The right
> fix is to define the list in the binding document.

Yes, and that is an eventual goal I suppose, but the current list is
excessive and is most likely not currently relied on by any one. So I
don't just want to C&P the entire list into this binding immediately.

I guess my plan looks like this:

1. add "nor-jedec" binding, to provide lowest common denominator binding
(this series)

2. stop adding to the m25p_ids[] table unless necessary (enabled by this
series)

3. gauge whether we can remove certain entries from m25p_ids[] (e.g., if
they were only used in platform_data, not DT; or if they were very
recently added just to synchronize with spi-nor.c)

4. once m25p_ids[] contains a reasonable set, maintain it in the binding
doc, like we really should

I don't feel like step 4 is ready yet.

Is that a reasonable plan in your eyes?

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

[PATCH v2 08/13] ARM: dts: sun5i: Add USB Dual Role Controller

[Hans de Goede]

Add a node for the otg/drc usb controller to sun5i-a1*.dtsi.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index c3e11ec..eb5bce5 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -425,6 +425,17 @@
#size-cells = <0>;
};
 
+   usb_otg: usb@01c13000 {
+   compatible = "allwinner,sun4i-a10-musb";
+   reg = <0x01c13000 0x0400>;
+   clocks = <&ahb_gates 0>;
+   interrupts = <38>;
+   interrupt-names = "mc";
+   phys = <&usbphy 0>;
+   phy-names = "usb";
+   status = "disabled";
+   };
+
usbphy: phy@01c13400 {
#phy-cells = <1>;
compatible = "allwinner,sun5i-a13-usb-phy";
-- 
2.3.3

--
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 06/13] musb: Add support for the Allwinner sunxi musb controller

[Hans de Goede]

This is based on initial code to get the Allwinner sunxi musb controller
supported by Chen-Yu Tsai and Roman Byshko.

This adds support for the Allwinner sunxi musb controller in both host only
and otg mode. Peripheral only mode is not supported, as no boards use that.

This has been tested on a cubietruck (A20 SoC) and an UTOO P66 tablet
(A13 SoC) with a variety of devices in host mode and with the g_serial gadget
driver in peripheral mode, plugging otg / host cables in/out a lot of times
in all possible imaginable plug orders.

Signed-off-by: Hans de Goede 
---
 .../bindings/usb/allwinner,sun4i-a10-musb.txt  |  25 +
 drivers/usb/musb/Kconfig   |  12 +-
 drivers/usb/musb/Makefile  |   1 +
 drivers/usb/musb/musb_core.h   |   1 +
 drivers/usb/musb/musb_gadget.c |   6 +
 drivers/usb/musb/musb_virthub.c|   6 +
 drivers/usb/musb/sunxi.c   | 671 +
 7 files changed, 721 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
 create mode 100644 drivers/usb/musb/sunxi.c

diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt 
b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
new file mode 100644
index 000..21dfc7f
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
@@ -0,0 +1,25 @@
+Allwinner sun4i A10 musb DRC/OTG controller
+---
+
+Required properties:
+ - compatible  : "allwinner,sun4i-a10-musb"
+ - reg : mmio address range of the musb controller
+ - clocks  : clock specifier for the musb controller ahb gate clock
+ - interrupts  : interrupt to which the musb controller is connected
+ - interrupt-names : must be "mc"
+ - phys: phy specifier for the otg phy
+ - phy-names   : must be "usb"
+ - dr_mode : Dual-Role mode must be "host" or "otg"
+
+Example:
+
+   usb_otg: usb@01c13000 {
+   compatible = "allwinner,sun4i-a10-musb";
+   reg = <0x01c13000 0x0400>;
+   clocks = <&ahb_gates 0>;
+   interrupts = <38>;
+   interrupt-names = "mc";
+   phys = <&usbphy 0>;
+   phy-names = "usb";
+   status = "disabled";
+   };
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 14e1628..c83cad1 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -5,7 +5,7 @@
 
 # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller
 config USB_MUSB_HDRC
-   tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)'
+   tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, AW, ...)'
depends on (USB || USB_GADGET)
help
  Say Y here if your system has a dual role high speed USB
@@ -20,6 +20,8 @@ config USB_MUSB_HDRC
  Analog Devices parts using this IP include Blackfin BF54x,
  BF525 and BF527.
 
+ Allwinner SoCs using this IP include A10, A13, A20, ...
+
  If you do not know what this is, please say N.
 
  To compile this driver as a module, choose M here; the
@@ -60,6 +62,14 @@ endchoice
 
 comment "Platform Glue Layer"
 
+config USB_MUSB_SUNXI
+   tristate "Allwinner (sunxi)"
+   depends on ARCH_SUNXI
+   depends on NOP_USB_XCEIV
+   select EXTCON
+   select GENERIC_PHY
+   select SUNXI_SRAM
+
 config USB_MUSB_DAVINCI
tristate "DaVinci"
depends on ARCH_DAVINCI_DMx
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index ba49501..f95befe 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_USB_MUSB_DA8XX)  += da8xx.o
 obj-$(CONFIG_USB_MUSB_BLACKFIN)+= blackfin.o
 obj-$(CONFIG_USB_MUSB_UX500)   += ux500.o
 obj-$(CONFIG_USB_MUSB_JZ4740)  += jz4740.o
+obj-$(CONFIG_USB_MUSB_SUNXI)   += sunxi.o
 
 
 obj-$(CONFIG_USB_MUSB_AM335X_CHILD)+= musb_am335x.o
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index ba8dd78..444b936 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -166,6 +166,7 @@ struct musb_io;
  */
 struct musb_platform_ops {
 
+#define MUSB_SUN4I BIT(7)
 #define MUSB_DMA_UX500 BIT(6)
 #define MUSB_DMA_CPPI41BIT(5)
 #define MUSB_DMA_CPPI  BIT(4)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index b2d9040..7d13eb9 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -2041,6 +2041,12 @@ void musb_g_disconnect(struct musb *musb)
spin_lock(&musb->lock);
}
 
+   /* On sunxi ep0 FADDR must be 0 when (re)entering peripheral mode */
+   if (musb->io

[PATCH v2 11/13] ARM: dts: sun5i: Enable USB DRC on UTOO P66

[Hans de Goede]

Enable the OTG controller on the UTOO P66 tablet.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts 
b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
index d1d4d30..6c9f5f3 100644
--- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
+++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
@@ -160,6 +160,20 @@
allwinner,pull = ;
};
 
+   usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
+   allwinner,pins = "PG1";
+   allwinner,function = "gpio_in";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   usb0_id_detect_pin: usb0_id_detect_pin@0 {
+   allwinner,pins = "PG2";
+   allwinner,function = "gpio_in";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
i2c_lcd_pins: i2c_lcd_pin@0 {
allwinner,pins = "PG10", "PG12";
allwinner,function = "gpio_out";
@@ -218,7 +232,16 @@
status = "okay";
 };
 
+&usb_otg {
+   dr_mode = "otg";
+   status = "okay";
+};
+
 &usbphy {
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+   usb0_id_det-gpio = <&pio 6 2 GPIO_ACTIVE_HIGH>; /* PG2 */
+   usb0_vbus_det-gpio = <&pio 6 1 GPIO_ACTIVE_HIGH>; /* PG1 */
usb0_vbus-supply = <®_usb0_vbus>;
usb1_vbus-supply = <®_ldo3>;
status = "okay";
-- 
2.3.3

--
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 12/13] ARM: dts: sun7i: Enable USB DRC on Cubietruck

[Hans de Goede]

From: Roman Byshko 

Enable the otg/drc usb controller on the cubietruck.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts 
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index 5af1df7..e14c1a6 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -224,6 +224,20 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   usb0_id_detect_pin: usb0_id_detect_pin@0 {
+   allwinner,pins = "PH19";
+   allwinner,function = "gpio_in";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
+   allwinner,pins = "PH22";
+   allwinner,function = "gpio_in";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
 };
 
 &pwm {
@@ -285,7 +299,16 @@
status = "okay";
 };
 
+&usb_otg {
+   dr_mode = "otg";
+   status = "okay";
+};
+
 &usbphy {
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+   usb0_id_det-gpios = <&pio 7 19 GPIO_ACTIVE_HIGH>; /* PH19 */
+   usb0_vbus_det-gpios = <&pio 7 22 GPIO_ACTIVE_HIGH>; /* PH22 */
usb0_vbus-supply = <®_usb0_vbus>;
usb1_vbus-supply = <®_usb1_vbus>;
usb2_vbus-supply = <®_usb2_vbus>;
-- 
2.3.3

--
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 05/13] musb: Fix platform code being unable to override ep access ops

[Hans de Goede]

musb-core was setting the ops to the default indexed or flat handlers after
checking for platform overrides. Reverse the order of this so that platform
overrides actually work.

Signed-off-by: Hans de Goede 
---
 drivers/usb/musb/musb_core.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 016b5b9..6e9b839 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2021,13 +2021,7 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
if (musb->ops->quirks)
musb->io.quirks = musb->ops->quirks;
 
-   /* At least tusb6010 has it's own offsets.. */
-   if (musb->ops->ep_offset)
-   musb->io.ep_offset = musb->ops->ep_offset;
-   if (musb->ops->ep_select)
-   musb->io.ep_select = musb->ops->ep_select;
-
-   /* ..and some devices use indexed offset or flat offset */
+   /* Set default ep access to indexed offset or flat offset ops */
if (musb->io.quirks & MUSB_INDEXED_EP) {
musb->io.ep_offset = musb_indexed_ep_offset;
musb->io.ep_select = musb_indexed_ep_select;
@@ -2035,6 +2029,11 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
musb->io.ep_offset = musb_flat_ep_offset;
musb->io.ep_select = musb_flat_ep_select;
}
+   /* And override them with platform specific ops if specified. */
+   if (musb->ops->ep_offset)
+   musb->io.ep_offset = musb->ops->ep_offset;
+   if (musb->ops->ep_select)
+   musb->io.ep_select = musb->ops->ep_select;
 
if (musb->ops->fifo_mode)
fifo_mode = musb->ops->fifo_mode;
-- 
2.3.3

--
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 04/13] musb: Do not use musb_read[b|w] / _write[b|w] wrappers in generic fifo functions

[Hans de Goede]

The generic fifo functions already use non wrapped accesses in various
cases through the iowrite#_rep functions, and all platforms which override
the default musb_read[b|w] / _write[b|w] functions also provide their own
fifo access functions, so we can safely drop the unnecessary indirection
from the fifo access functions.

Signed-off-by: Hans de Goede 
---
 drivers/usb/musb/musb_core.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 01ed3a6..016b5b9 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -313,7 +313,7 @@ static void musb_default_write_fifo(struct musb_hw_ep 
*hw_ep, u16 len,
index += len & ~0x03;
}
if (len & 0x02) {
-   musb_writew(fifo, 0, *(u16 *)&src[index]);
+   __raw_writew(*(u16 *)&src[index], fifo);
index += 2;
}
} else {
@@ -323,7 +323,7 @@ static void musb_default_write_fifo(struct musb_hw_ep 
*hw_ep, u16 len,
}
}
if (len & 0x01)
-   musb_writeb(fifo, 0, src[index]);
+   __raw_writeb(src[index], fifo);
} else  {
/* byte aligned */
iowrite8_rep(fifo, src, len);
@@ -355,7 +355,7 @@ static void musb_default_read_fifo(struct musb_hw_ep 
*hw_ep, u16 len, u8 *dst)
index = len & ~0x03;
}
if (len & 0x02) {
-   *(u16 *)&dst[index] = musb_readw(fifo, 0);
+   *(u16 *)&dst[index] = __raw_readw(fifo);
index += 2;
}
} else {
@@ -365,7 +365,7 @@ static void musb_default_read_fifo(struct musb_hw_ep 
*hw_ep, u16 len, u8 *dst)
}
}
if (len & 0x01)
-   dst[index] = musb_readb(fifo, 0);
+   dst[index] = __raw_readb(fifo);
} else  {
/* byte aligned */
ioread8_rep(fifo, dst, len);
-- 
2.3.3

--
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 07/13] ARM: dts: sun4i: Add USB Dual Role Controller

[Hans de Goede]

Add a node for the otg/drc usb controller to sun4i-a10.dtsi.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun4i-a10.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index a932c1c..88f57b4 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -611,6 +611,17 @@
#size-cells = <0>;
};
 
+   usb_otg: usb@01c13000 {
+   compatible = "allwinner,sun4i-a10-musb";
+   reg = <0x01c13000 0x0400>;
+   clocks = <&ahb_gates 0>;
+   interrupts = <38>;
+   interrupt-names = "mc";
+   phys = <&usbphy 0>;
+   phy-names = "usb";
+   status = "disabled";
+   };
+
usbphy: phy@01c13400 {
#phy-cells = <1>;
compatible = "allwinner,sun4i-a10-usb-phy";
-- 
2.3.3

--
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 03/13] musb: Make busctl_offset an io-op rather then a define

[Hans de Goede]

The Allwinner (sunxi) implementation of the musb has its busctl registers
indexed by the MUSB_INDEX register rather then in a flat address space.

This commit turns MUSB_BUSCTL_OFFSET from a macro into an io-op which can
be overridden from the platform ops.

Signed-off-by: Hans de Goede 
---
 drivers/usb/musb/musb_core.c | 34 +++-
 drivers/usb/musb/musb_core.h |  5 +++-
 drivers/usb/musb/musb_host.c | 12 -
 drivers/usb/musb/musb_io.h   |  2 ++
 drivers/usb/musb/musb_regs.h | 63 
 5 files changed, 68 insertions(+), 48 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index e2892fa..01ed3a6 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -250,6 +250,11 @@ static u32 musb_indexed_ep_offset(u8 epnum, u16 offset)
return 0x10 + offset;
 }
 
+static u32 musb_default_busctl_offset(u8 epnum, u16 offset)
+{
+   return 0x80 + (0x08 * epnum) + offset;
+}
+
 static u8 musb_default_readb(const void __iomem *addr, unsigned offset)
 {
return __raw_readb(addr + offset);
@@ -2041,6 +2046,11 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
else
musb->io.fifo_offset = musb_default_fifo_offset;
 
+   if (musb->ops->busctl_offset)
+   musb->io.busctl_offset = musb->ops->busctl_offset;
+   else
+   musb->io.busctl_offset = musb_default_busctl_offset;
+
if (musb->ops->readb)
musb_readb = musb->ops->readb;
if (musb->ops->writeb)
@@ -2314,18 +2324,18 @@ static void musb_save_context(struct musb *musb)
musb_readb(epio, MUSB_RXINTERVAL);
 
musb->context.index_regs[i].txfunaddr =
-   musb_read_txfunaddr(musb_base, i);
+   musb_read_txfunaddr(musb, i);
musb->context.index_regs[i].txhubaddr =
-   musb_read_txhubaddr(musb_base, i);
+   musb_read_txhubaddr(musb, i);
musb->context.index_regs[i].txhubport =
-   musb_read_txhubport(musb_base, i);
+   musb_read_txhubport(musb, i);
 
musb->context.index_regs[i].rxfunaddr =
-   musb_read_rxfunaddr(musb_base, i);
+   musb_read_rxfunaddr(musb, i);
musb->context.index_regs[i].rxhubaddr =
-   musb_read_rxhubaddr(musb_base, i);
+   musb_read_rxhubaddr(musb, i);
musb->context.index_regs[i].rxhubport =
-   musb_read_rxhubport(musb_base, i);
+   musb_read_rxhubport(musb, i);
}
 }
 
@@ -2393,18 +2403,18 @@ static void musb_restore_context(struct musb *musb)
musb_writeb(epio, MUSB_RXINTERVAL,
 
musb->context.index_regs[i].rxinterval);
-   musb_write_txfunaddr(musb_base, i,
+   musb_write_txfunaddr(musb, i,
musb->context.index_regs[i].txfunaddr);
-   musb_write_txhubaddr(musb_base, i,
+   musb_write_txhubaddr(musb, i,
musb->context.index_regs[i].txhubaddr);
-   musb_write_txhubport(musb_base, i,
+   musb_write_txhubport(musb, i,
musb->context.index_regs[i].txhubport);
 
-   musb_write_rxfunaddr(musb_base, i,
+   musb_write_rxfunaddr(musb, i,
musb->context.index_regs[i].rxfunaddr);
-   musb_write_rxhubaddr(musb_base, i,
+   musb_write_rxhubaddr(musb, i,
musb->context.index_regs[i].rxhubaddr);
-   musb_write_rxhubport(musb_base, i,
+   musb_write_rxhubport(musb, i,
musb->context.index_regs[i].rxhubport);
}
musb_writeb(musb_base, MUSB_INDEX, musb->context.index);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index a31d709..ba8dd78 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -67,7 +67,6 @@ struct musb_ep;
 #include "musb_dma.h"
 
 #include "musb_io.h"
-#include "musb_regs.h"
 
 #include "musb_gadget.h"
 #include 
@@ -186,6 +185,7 @@ struct musb_platform_ops {
void(*ep_select)(void __iomem *mbase, u8 epnum);
u16 fifo_mode;
u32 (*fifo_offset)(u8 epnum);
+   u32 (*busctl_offset)(u8 epnum, u16 offset);
u8  (*readb)(const void __iomem *addr, unsigned offset);
void(*writeb)(void __iomem *addr, unsigned offset, u8 data);
u16 (*readw)(const void __iomem *addr, unsigned offset);
@@ -435,6 +435,9 @@ struct musb {
 #endif
 };
 
+/* This must be included after struct musb is defined */
+#include "musb_regs.h"
+
 static inline struct musb *gadget_to_musb(stru

[PATCH v2 13/13] ARM: dts: sun7i: Enable USB DRC on A20-OLinuxIno-Lime

[Hans de Goede]

Enable the otg/drc usb controller on the A20-OLinuxIno-Lime.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts | 28 ++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts 
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
index 68efd2f..e3812e9 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
@@ -146,6 +146,20 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   usb0_id_detect_pin: usb0_id_detect_pin@0 {
+   allwinner,pins = "PH4";
+   allwinner,function = "gpio_in";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
+   allwinner,pins = "PH5";
+   allwinner,function = "gpio_in";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
 };
 
 ®_ahci_5v {
@@ -154,6 +168,10 @@
status = "okay";
 };
 
+®_usb0_vbus {
+   status = "okay";
+};
+
 ®_usb1_vbus {
status = "okay";
 };
@@ -168,7 +186,17 @@
status = "okay";
 };
 
+&usb_otg {
+   dr_mode = "otg";
+   status = "okay";
+};
+
 &usbphy {
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+   usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+   usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+   usb0_vbus-supply = <®_usb0_vbus>;
usb1_vbus-supply = <®_usb1_vbus>;
usb2_vbus-supply = <®_usb2_vbus>;
status = "okay";
-- 
2.3.3

--
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 09/13] ARM: dts: sun7i: Add USB Dual Role Controller

[Hans de Goede]

From: Roman Byshko 

Add a node for the otg/drc usb controller to sun7i-a20.dtsi

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index fb911c9..7c04a24 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -696,6 +696,17 @@
#size-cells = <0>;
};
 
+   usb_otg: usb@01c13000 {
+   compatible = "allwinner,sun4i-a10-musb";
+   reg = <0x01c13000 0x0400>;
+   clocks = <&ahb_gates 0>;
+   interrupts = <0 38 4>;
+   interrupt-names = "mc";
+   phys = <&usbphy 0>;
+   phy-names = "usb";
+   status = "disabled";
+   };
+
usbphy: phy@01c13400 {
#phy-cells = <1>;
compatible = "allwinner,sun7i-a20-usb-phy";
-- 
2.3.3

--
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 01/13] phy-sun4i-usb: Add full support for usb0 phy / OTG

[Hans de Goede]

The usb0 phy is connected to an OTG controller, and as such needs some special
handling:

1) It allows explicit control over the pullups, enable these on phy_init and
disable them on phy_exit.

2) It has bits to signal id and vbus detect to the musb-core, add support for
for monitoring id and vbus detect gpio-s for use in dual role mode, and set
these bits to the correct values for operating in host only mode when no
gpios are specified in the devicetree.

3) When in dual role mode the musb sunxi glue needs to know if the a host or
device cable is plugged in, so when in dual role mode register an extcon.

While updating the devicetree binding documentation also add documentation
for the sofar undocumented usage of regulators for vbus for all 3 phys.

Signed-off-by: Hans de Goede 
---
 .../devicetree/bindings/phy/sun4i-usb-phy.txt  |  18 +-
 drivers/phy/Kconfig|   1 +
 drivers/phy/phy-sun4i-usb.c| 269 -
 3 files changed, 277 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt 
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index 16528b9..557fa99 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -23,6 +23,13 @@ Required properties:
   * "usb1_reset"
   * "usb2_reset" for sun4i, sun6i or sun7i
 
+Optional properties:
+- usb0_id_det-gpios : gpio phandle for reading the otg id pin value
+- usb0_vbus_det-gpios : gpio phandle for detecting the presence of usb0 vbus
+- usb0_vbus-supply : regulator phandle for controller usb0 vbus
+- usb1_vbus-supply : regulator phandle for controller usb1 vbus
+- usb2_vbus-supply : regulator phandle for controller usb2 vbus
+
 Example:
usbphy: phy@0x01c13400 {
#phy-cells = <1>;
@@ -32,6 +39,13 @@ Example:
reg-names = "phy_ctrl", "pmu1", "pmu2";
clocks = <&usb_clk 8>;
clock-names = "usb_phy";
-   resets = <&usb_clk 1>, <&usb_clk 2>;
-   reset-names = "usb1_reset", "usb2_reset";
+   resets = <&usb_clk 0>, <&usb_clk 1>, <&usb_clk 2>;
+   reset-names = "usb0_reset", "usb1_reset", "usb2_reset";
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+   usb0_id_det-gpios = <&pio 7 19 GPIO_ACTIVE_HIGH>; /* PH19 */
+   usb0_vbus_det-gpios = <&pio 7 22 GPIO_ACTIVE_HIGH>; /* PH22 */
+   usb0_vbus-supply = <®_usb0_vbus>;
+   usb1_vbus-supply = <®_usb1_vbus>;
+   usb2_vbus-supply = <®_usb2_vbus>;
};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 3e6b176..0795b3a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -166,6 +166,7 @@ config PHY_SUN4I_USB
tristate "Allwinner sunxi SoC USB PHY driver"
depends on ARCH_SUNXI && HAS_IOMEM && OF
depends on RESET_CONTROLLER
+   select EXTCON
select GENERIC_PHY
help
  Enable this to support the transceiver that is part of Allwinner
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index a2b08f3c..221e8ab 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -1,7 +1,7 @@
 /*
  * Allwinner sun4i USB phy driver
  *
- * Copyright (C) 2014 Hans de Goede 
+ * Copyright (C) 2014-2015 Hans de Goede 
  *
  * Based on code from
  * Allwinner Technology Co., Ltd. 
@@ -23,16 +23,22 @@
 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+
+#define DRIVER_NAME "sun4i-usb-phy"
 
 #define REG_ISCR   0x00
 #define REG_PHYCTL 0x04
@@ -46,6 +52,17 @@
 #define SUNXI_AHB_INCRX_ALIGN_EN   BIT(8)
 #define SUNXI_ULPI_BYPASS_EN   BIT(0)
 
+/* ISCR, Interface Status and Control bits */
+#define ISCR_ID_PULLUP_EN  (1 << 17)
+#define ISCR_DPDM_PULLUP_EN(1 << 16)
+/* sunxi has the phy id/vbus pins not connected, so we use the force bits */
+#define ISCR_FORCE_ID_MASK (3 << 14)
+#define ISCR_FORCE_ID_LOW  (2 << 14)
+#define ISCR_FORCE_ID_HIGH (3 << 14)
+#define ISCR_FORCE_VBUS_MASK   (3 << 12)
+#define ISCR_FORCE_VBUS_LOW(2 << 12)
+#define ISCR_FORCE_VBUS_HIGH   (3 << 12)
+
 /* Common Control Bits for Both PHYs */
 #define PHY_PLL_BW 0x03
 #define PHY_RES45_CAL_EN   0x0c
@@ -61,6 +78,13 @@
 
 #define MAX_PHYS   3
 
+/*
+ * Note do not raise the debounce time, we must report Vusb high within 100ms
+ * otherwise we get Vbus errors
+ */
+#define DEBOUNCE_TIME  msecs_to_jiffies(50)
+#define POLL_TIME  msecs_to_jiffies(250)
+
 struct sun4i_usb_phy_data {
void __iomem *base;
struct mutex 

[PATCH v2 00/13] musb: Add support for the Allwinner sunxi musb controller

[Hans de Goede]

Hi All,

Here is v2 of my patch-set to add support for the musb variant found on
Allwinner sunxi SoCs.

Changes since the original posting:
-Removed the sunxi specific phy functions, instead the id / vbus gpio polling
 has been moved to the phy-sun4i-usb driver and their status is exported
 through extcon for the sunxi-musb glue
-Stop using syscon, instead Maxime Ripard's sunxi SRAM controller driver is now
 used

This should address all review remarks against v1 of this patch-set, so
hopefully we can start merging this upstream.

The "musb: Add support for the Allwinner sunxi musb" commit relies on
Maxime's SRAM controller patches, so those need to get merged first,
but the phy-sun4i-usb and musb preparation patches can be merged already
(assuming there are no objections).

And then once the SRAM controller patches are in next we can also merge
the "musb: Add support for the Allwinner sunxi musb" commit and the dts
changes.

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

[PATCH v2 02/13] musb: Make musb_write_rxfun* and musb_write_rxhub* work like their tx versions

[Hans de Goede]

For some reason the musb_write_rxfun* and musb_write_rxhub* functions had
a different function prototype and some extra magic needed on the caller side
compared to their tx counterparts, this commit makes them work the same as
their tx counterparts.

Signed-off-by: Hans de Goede 
---
 drivers/usb/musb/musb_core.c | 11 +++
 drivers/usb/musb/musb_core.h |  2 --
 drivers/usb/musb/musb_host.c | 12 ++--
 drivers/usb/musb/musb_regs.h | 31 ---
 4 files changed, 21 insertions(+), 35 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 067920f..e2892fa 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1546,7 +1546,6 @@ static int musb_core_init(u16 musb_type, struct musb 
*musb)
 #endif
 
hw_ep->regs = musb->io.ep_offset(i, 0) + mbase;
-   hw_ep->target_regs = musb_read_target_reg_base(i, mbase);
hw_ep->rx_reinit = 1;
hw_ep->tx_reinit = 1;
 
@@ -2334,7 +2333,6 @@ static void musb_restore_context(struct musb *musb)
 {
int i;
void __iomem *musb_base = musb->mregs;
-   void __iomem *ep_target_regs;
void __iomem *epio;
u8 power;
 
@@ -2402,14 +2400,11 @@ static void musb_restore_context(struct musb *musb)
musb_write_txhubport(musb_base, i,
musb->context.index_regs[i].txhubport);
 
-   ep_target_regs =
-   musb_read_target_reg_base(i, musb_base);
-
-   musb_write_rxfunaddr(ep_target_regs,
+   musb_write_rxfunaddr(musb_base, i,
musb->context.index_regs[i].rxfunaddr);
-   musb_write_rxhubaddr(ep_target_regs,
+   musb_write_rxhubaddr(musb_base, i,
musb->context.index_regs[i].rxhubaddr);
-   musb_write_rxhubport(ep_target_regs,
+   musb_write_rxhubport(musb_base, i,
musb->context.index_regs[i].rxhubport);
}
musb_writeb(musb_base, MUSB_INDEX, musb->context.index);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 5e65958..a31d709 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -240,8 +240,6 @@ struct musb_hw_ep {
void __iomem*fifo_sync_va;
 #endif
 
-   void __iomem*target_regs;
-
/* currently scheduled peripheral endpoint */
struct musb_qh  *in_qh;
struct musb_qh  *out_qh;
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index c3d5fc9..c4732a7 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -555,8 +555,9 @@ musb_host_packet_rx(struct musb *musb, struct urb *urb, u8 
epnum, u8 iso_err)
  * the busy/not-empty tests are basically paranoia.
  */
 static void
-musb_rx_reinit(struct musb *musb, struct musb_qh *qh, struct musb_hw_ep *ep)
+musb_rx_reinit(struct musb *musb, struct musb_qh *qh, u8 epnum)
 {
+   struct musb_hw_ep *ep = musb->endpoints + epnum;
u16 csr;
 
/* NOTE:  we know the "rx" fifo reinit never triggers for ep0.
@@ -594,10 +595,9 @@ musb_rx_reinit(struct musb *musb, struct musb_qh *qh, 
struct musb_hw_ep *ep)
 
/* target addr and (for multipoint) hub addr/port */
if (musb->is_multipoint) {
-   musb_write_rxfunaddr(ep->target_regs, qh->addr_reg);
-   musb_write_rxhubaddr(ep->target_regs, qh->h_addr_reg);
-   musb_write_rxhubport(ep->target_regs, qh->h_port_reg);
-
+   musb_write_rxfunaddr(musb->mregs, epnum, qh->addr_reg);
+   musb_write_rxhubaddr(musb->mregs, epnum, qh->h_addr_reg);
+   musb_write_rxhubport(musb->mregs, epnum, qh->h_port_reg);
} else
musb_writeb(musb->mregs, MUSB_FADDR, qh->addr_reg);
 
@@ -875,7 +875,7 @@ finish:
u16 csr;
 
if (hw_ep->rx_reinit) {
-   musb_rx_reinit(musb, qh, hw_ep);
+   musb_rx_reinit(musb, qh, epnum);
 
/* init new state: toggle and NYET, maybe DMA later */
if (usb_gettoggle(urb->dev, qh->epnum, 0))
diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h
index 11f0be0..edfc730 100644
--- a/drivers/usb/musb/musb_regs.h
+++ b/drivers/usb/musb/musb_regs.h
@@ -364,27 +364,25 @@ static inline u16 musb_read_hwvers(void __iomem *mbase)
return musb_readw(mbase, MUSB_HWVERS);
 }
 
-static inline void __iomem *musb_read_target_reg_base(u8 i, void __iomem 
*mbase)
-{
-   return (MUSB_BUSCTL_OFFSET(i, 0) + mbase);
-}
-
-static inline void musb_write_rxfunaddr(void __iomem *ep_target_regs,
+static inline void musb_write_rxfunaddr(void __iomem *mbase, u8 epnum,
u8 qh_addr_reg)
 {
-   musb_writeb(ep_target_regs, MUSB_RXFUNCADDR, qh_ad

Re: [PATCH 1/2] Documentation: devicetree: m25p80: add "nor-jedec" binding

[Brian Norris]

On Thu, Mar 12, 2015 at 10:53:52AM +, Mark Rutland wrote:
> On Thu, Mar 12, 2015 at 10:36:29AM +, Rafał Miłecki wrote:
> > On 12 March 2015 at 11:19, Geert Uytterhoeven  wrote:
> > > On Wed, Mar 11, 2015 at 10:57 PM, Brian Norris
> > >  wrote:
> > >> diff --git a/Documentation/devicetree/bindings/mtd/m25p80.txt 
> > >> b/Documentation/devicetree/bindings/mtd/m25p80.txt
> > >> index 4611aa83531b..1b2997d4cee4 100644
> > >> --- a/Documentation/devicetree/bindings/mtd/m25p80.txt
> > >> +++ b/Documentation/devicetree/bindings/mtd/m25p80.txt
> > >> @@ -3,9 +3,12 @@
> > >>  Required properties:
> > >>  - #address-cells, #size-cells : Must be present if the device has 
> > >> sub-nodes
> > >>representing partitions.
> > >> -- compatible : Should be the manufacturer and the name of the chip. 
> > >> Bear in mind
> > >> +- compatible : Should be "nor-jedec" for any SPI NOR flash that can be
> > >> +   identified by the JEDEC READ ID opcode (0x95).
> > >> +   Additionally, may include a device-specific string 
> > >> consisting of
> > >> +   the manufacturer and name of the chip. Bear in mind
> > >
> > > For the casual reader, this suggests putting "nor-jedec" first, which is 
> > > not
> > > what we want. So I would write it like e.g.
> > >
> > > "Should be the manufacturer and the name of the chip. Additionally,
> > >  should contain "nor-jedec" for any SPI NOR flash that can be
> > >  identified by the JEDEC READ ID opcode (0x95)."
> > 
> > I don't really like above. It suggests using manufacturer,name
> > always/in most cases. This is what we want to avoid. Let's use
> > "nor-jedec" wherever possible (when dealing with JEDEC compatible
> > flashes).
> 
> The compatible property is a list. We should have "nor-jedec" in the
> list, but a more specific string should come first. If we don't
> recognise the more specific string, we'll still recognise nor-jedec, if
> we do recognise it then we can do more advacned things with the HW (or
> work around errata).

Right, I think this is fair, and that was really the intention, even if
it wasn't communicated well.

I *do* want to communicate that (where applicable) "nor-jedec" must be
included, since that would eliminate the need for maintaining a stable
list of bindings for >95% of flash. But the 'manufacturer,model' option
is still a good safeguard, and it would definitely come first in the
compatible list.

I'll reword this so the more specific option comes first, but still make
it clear that "nor-jedec" is strongly suggested.

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 5/5] net: allwinner: emac: Claim our SRAM

[Hans de Goede]

Hi,

On 20-03-15 19:52, Hans de Goede wrote:

From: Maxime Ripard 

The SRAM the EMAC is using might not have been mapped accordingly by the
bootloader, preventing the EMAC to work properly.

Ask for that SRAM to be mapped at probe time to make sure that this never
happens.

Signed-off-by: Maxime Ripard 
[hdego...@redhat.com: Make sure SUNXI_SRAM gets enabled in Kconfig]
Signed-off-by: Hans de Goede 


Note this patch is only included for completeness / as an example,
it should probably go upstream through the network-drivers tree
once the rest is merged.

Regards,

Hans


---
  drivers/net/ethernet/allwinner/sun4i-emac.c | 13 +++--
  drivers/net/ethernet/stmicro/stmmac/Kconfig |  1 +
  2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c 
b/drivers/net/ethernet/allwinner/sun4i-emac.c
index f3470d9..9d0136b 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -29,6 +29,8 @@
  #include 
  #include 

+#include 
+
  #include "sun4i-emac.h"

  #define DRV_NAME  "sun4i-emac"
@@ -857,11 +859,15 @@ static int emac_probe(struct platform_device *pdev)

clk_prepare_enable(db->clk);

+   ret = sunxi_sram_claim(SUNXI_SRAM_EMAC, "emac");
+   if (ret)
+   dev_warn(&pdev->dev, "Couldn't map SRAM to device\n");
+
db->phy_node = of_parse_phandle(np, "phy", 0);
if (!db->phy_node) {
dev_err(&pdev->dev, "no associated PHY\n");
ret = -ENODEV;
-   goto out;
+   goto out_release_sram;
}

/* Read MAC-address from DT */
@@ -893,7 +899,7 @@ static int emac_probe(struct platform_device *pdev)
if (ret) {
dev_err(&pdev->dev, "Registering netdev failed!\n");
ret = -ENODEV;
-   goto out;
+   goto out_release_sram;
}

dev_info(&pdev->dev, "%s: at %p, IRQ %d MAC: %pM\n",
@@ -901,6 +907,8 @@ static int emac_probe(struct platform_device *pdev)

return 0;

+out_release_sram:
+   sunxi_sram_release(SUNXI_SRAM_EMAC);
  out:
dev_err(db->dev, "not found (%d).\n", ret);

@@ -914,6 +922,7 @@ static int emac_remove(struct platform_device *pdev)
struct net_device *ndev = platform_get_drvdata(pdev);

unregister_netdev(ndev);
+   sunxi_sram_release(SUNXI_SRAM_EMAC);
free_netdev(ndev);

dev_dbg(&pdev->dev, "released and freed device\n");
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig 
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 7d3af19..785ca22 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -16,6 +16,7 @@ if STMMAC_ETH
  config STMMAC_PLATFORM
tristate "STMMAC Platform bus support"
depends on STMMAC_ETH
+   select SUNXI_SRAM if ARCH_SUNXI
default y
---help---
  This selects the platform specific bus support for the stmmac driver.


--
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 3/5] ARM: dts: sun5i: Add A13 and A10s SRAM and SRAM controller

[Hans de Goede]

The A13 / A10s has a few SRAM that can be mapped either to a device or to
the CPU, with the mapping being controlled by a SRAM controller.

Since most of the time these SRAM won't be accessible by the CPU,
we can't use the mmio-sram driver and compatible.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i.dtsi | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index de48692..eb5bce5 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -298,12 +298,46 @@
};
};
 
+   /*
+* Note we use the address were mmio registers start, not where the
+* SRAM blocks start, this cannot be changed because that would be
+* a devicetree ABI change.
+*/
soc@01c0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
 
+   sram@ {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x 0x4000>;
+   allwinner,sram-name = "A1";
+   };
+
+   sram@4000 {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x4000 0x4000>;
+   allwinner,sram-name = "A2";
+   };
+
+   sram@8000 {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x8000 0x4000>;
+   allwinner,sram-name = "A3-A4";
+   };
+
+   sram@0001 {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x0001 0x1000>;
+   allwinner,sram-name = "D";
+   };
+
+   sram-controller@01c0 {
+   compatible = "allwinner,sun4i-a10-sram-controller";
+   reg = <0x01c0 0x30>;
+   };
+
dma: dma-controller@01c02000 {
compatible = "allwinner,sun4i-a10-dma";
reg = <0x01c02000 0x1000>;
-- 
2.3.3

--
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 0/5] ARM: sunxi: SRAM mapping support

[Hans de Goede]

Hi All,

Here is a cleaned up version of Maxime's sunxi SRAM controller driver.

I've been using / testing this together with the sunxi musb support patches
I've been working on, and it works well. I've tested it on sun4i, sun5i and
sun7i. See the per patch commit messages for the (minor) changes which I did
compared to Maxime's RFC.

A note about the changing of the compatible to a sun4i-a10 prefix, I've
looked at the user manual for all 3 generations and the sram controller is
the same for all 3. Register 0x1c00024 (SoC version) is only documented in
the A20 manual, but is present and works indentical in all 3 generations.

Since this is a prereq for my musb work, if there are no objections then I
would like to see this go upstream soon.

Since it only touches sunxi files (and one Makefile), it is probably best if
this all goes upstream through Maxime.

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

[PATCH 2/5] ARM: dts: sun4i: Add A10 SRAM and SRAM controller

[Hans de Goede]

The A10 has a few SRAM that can be mapped either to a device or to the CPU,
with the mapping being controlled by a SRAM controller.

Since most of the time these SRAM won't be accessible by the CPU,
we can't use the mmio-sram driver and compatible.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun4i-a10.dtsi | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index b66ebb3..88f57b4 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -451,12 +451,46 @@
};
};
 
+   /*
+* Note we use the address were mmio registers start, not where the
+* SRAM blocks start, this cannot be changed because that would be
+* a devicetree ABI change.
+*/
soc@01c0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
 
+   sram@ {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x 0x4000>;
+   allwinner,sram-name = "A1";
+   };
+
+   sram@4000 {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x4000 0x4000>;
+   allwinner,sram-name = "A2";
+   };
+
+   sram@8000 {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x8000 0x4000>;
+   allwinner,sram-name = "A3-A4";
+   };
+
+   sram@0001 {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x0001 0x1000>;
+   allwinner,sram-name = "D";
+   };
+
+   sram-controller@01c0 {
+   compatible = "allwinner,sun4i-a10-sram-controller";
+   reg = <0x01c0 0x30>;
+   };
+
dma: dma-controller@01c02000 {
compatible = "allwinner,sun4i-a10-dma";
reg = <0x01c02000 0x1000>;
-- 
2.3.3

--
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 5/5] net: allwinner: emac: Claim our SRAM

[Hans de Goede]

From: Maxime Ripard 

The SRAM the EMAC is using might not have been mapped accordingly by the
bootloader, preventing the EMAC to work properly.

Ask for that SRAM to be mapped at probe time to make sure that this never
happens.

Signed-off-by: Maxime Ripard 
[hdego...@redhat.com: Make sure SUNXI_SRAM gets enabled in Kconfig]
Signed-off-by: Hans de Goede 
---
 drivers/net/ethernet/allwinner/sun4i-emac.c | 13 +++--
 drivers/net/ethernet/stmicro/stmmac/Kconfig |  1 +
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c 
b/drivers/net/ethernet/allwinner/sun4i-emac.c
index f3470d9..9d0136b 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -29,6 +29,8 @@
 #include 
 #include 
 
+#include 
+
 #include "sun4i-emac.h"
 
 #define DRV_NAME   "sun4i-emac"
@@ -857,11 +859,15 @@ static int emac_probe(struct platform_device *pdev)
 
clk_prepare_enable(db->clk);
 
+   ret = sunxi_sram_claim(SUNXI_SRAM_EMAC, "emac");
+   if (ret)
+   dev_warn(&pdev->dev, "Couldn't map SRAM to device\n");
+
db->phy_node = of_parse_phandle(np, "phy", 0);
if (!db->phy_node) {
dev_err(&pdev->dev, "no associated PHY\n");
ret = -ENODEV;
-   goto out;
+   goto out_release_sram;
}
 
/* Read MAC-address from DT */
@@ -893,7 +899,7 @@ static int emac_probe(struct platform_device *pdev)
if (ret) {
dev_err(&pdev->dev, "Registering netdev failed!\n");
ret = -ENODEV;
-   goto out;
+   goto out_release_sram;
}
 
dev_info(&pdev->dev, "%s: at %p, IRQ %d MAC: %pM\n",
@@ -901,6 +907,8 @@ static int emac_probe(struct platform_device *pdev)
 
return 0;
 
+out_release_sram:
+   sunxi_sram_release(SUNXI_SRAM_EMAC);
 out:
dev_err(db->dev, "not found (%d).\n", ret);
 
@@ -914,6 +922,7 @@ static int emac_remove(struct platform_device *pdev)
struct net_device *ndev = platform_get_drvdata(pdev);
 
unregister_netdev(ndev);
+   sunxi_sram_release(SUNXI_SRAM_EMAC);
free_netdev(ndev);
 
dev_dbg(&pdev->dev, "released and freed device\n");
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig 
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 7d3af19..785ca22 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -16,6 +16,7 @@ if STMMAC_ETH
 config STMMAC_PLATFORM
tristate "STMMAC Platform bus support"
depends on STMMAC_ETH
+   select SUNXI_SRAM if ARCH_SUNXI
default y
---help---
  This selects the platform specific bus support for the stmmac driver.
-- 
2.3.3

--
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 4/5] ARM: dts: sun7i: Add A20 SRAM and SRAM controller

[Hans de Goede]

From: Maxime Ripard 

The A20 has a few SRAM that can be mapped either to a device or to the CPU,
with the mapping being controlled by a SRAM controller.

Since most of the time these SRAM won't be accessible by the CPU,
we can't use the mmio-sram driver and compatible.

Signed-off-by: Maxime Ripard 
[hdego...@redhat.com: Do not change soc node name, change compatible to
 sun4i-a10-sram-controller to match the driver change]
Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 4673c11..7c04a24 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -528,12 +528,46 @@
};
};
 
+   /*
+* Note we use the address were mmio registers start, not where the
+* SRAM blocks start, this cannot be changed because that would be
+* a devicetree ABI change.
+*/
soc@01c0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
 
+   sram@ {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x 0x4000>;
+   allwinner,sram-name = "A1";
+   };
+
+   sram@4000 {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x4000 0x4000>;
+   allwinner,sram-name = "A2";
+   };
+
+   sram@8000 {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x8000 0x4000>;
+   allwinner,sram-name = "A3-A4";
+   };
+
+   sram@0001 {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x0001 0x1000>;
+   allwinner,sram-name = "D";
+   };
+
+   sram-controller@01c0 {
+   compatible = "allwinner,sun4i-a10-sram-controller";
+   reg = <0x01c0 0x30>;
+   };
+
nmi_intc: interrupt-controller@01c00030 {
compatible = "allwinner,sun7i-a20-sc-nmi";
interrupt-controller;
-- 
2.3.3

--
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 1/5] drivers: soc: sunxi: Introduce SoC driver to map SRAMs

[Hans de Goede]

From: Maxime Ripard 

The Allwinner SoCs have a handful of SRAM that can be either mapped to be
accessible by devices or the CPU.

That mapping is controlled by an SRAM controller, and that mapping might not be
set by the bootloader, for example if the device wasn't used at all, or if
we're using solutions like the U-Boot's Falcon Boot.

We could also imagine changing this at runtime for example to change the
mapping of these SRAMs to use them for suspend/resume or runtime memory rate
change, if that ever happens.

These use cases require some API in the kernel to control that mapping,
exported through a drivers/soc driver.

This driver also implement a debugfs file that shows the SRAM found in the
system, the current mapping and the SRAM that have been claimed by some drivers
in the kernel.

Signed-off-by: Maxime Ripard 
[hdego...@redhat.com: Changed compat string to sun4i-a10-sram-controller, as
 the sram controller is identical on sun4i, sun5i & sun7i, added devicetree
 binding documentation, fixed some checkpatch warnings]
Signed-off-by: Hans de Goede 
---
 .../devicetree/bindings/soc/sunxi/sram.txt |  64 ++
 drivers/soc/Kconfig|   1 +
 drivers/soc/Makefile   |   1 +
 drivers/soc/sunxi/Kconfig  |  12 ++
 drivers/soc/sunxi/Makefile |   1 +
 drivers/soc/sunxi/sunxi_sram.c | 235 +
 include/linux/soc/sunxi/sunxi_sram.h   |  24 +++
 7 files changed, 338 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/sunxi/sram.txt
 create mode 100644 drivers/soc/sunxi/Kconfig
 create mode 100644 drivers/soc/sunxi/Makefile
 create mode 100644 drivers/soc/sunxi/sunxi_sram.c
 create mode 100644 include/linux/soc/sunxi/sunxi_sram.h

diff --git a/Documentation/devicetree/bindings/soc/sunxi/sram.txt 
b/Documentation/devicetree/bindings/soc/sunxi/sram.txt
new file mode 100644
index 000..6e1bc80
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/sunxi/sram.txt
@@ -0,0 +1,64 @@
+Allwinnner sun4i / sun5i / sun7i SoC SRAM controllers
+-
+
+Required properties:
+- compatible : "allwinner,sun4i-a10-sram-controller"
+- reg : sram controller register offset + length
+
+SRAM nodes
+--
+
+Besides a node for the SRAM controller the devicetree must also contain a
+node for each SRAM block controlled by the controller.
+
+Required sram node properties:
+- compatible : "allwinner,sun4i-a10-sram"
+- allwinner,sram-name : should be one of
+  * "A1"
+  * "A2"
+  * "A3-A4"
+  * "D"
+
+Example
+---
+
+/*
+ * Note we use the address were mmio register start, not where
+ * the SRAM blocks starts, this cannot be changed because doing
+ * doing so would be a devicetree ABI change.
+ */
+soc@01c0 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   sram@ {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x 0x4000>;
+   allwinner,sram-name = "A1";
+   };
+
+   sram@4000 {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x4000 0x4000>;
+   allwinner,sram-name = "A2";
+   };
+
+   sram@8000 {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x8000 0x4000>;
+   allwinner,sram-name = "A3-A4";
+   };
+
+   sram@0001 {
+   compatible = "allwinner,sun4i-a10-sram";
+   reg = <0x0001 0x1000>;
+   allwinner,sram-name = "D";
+   };
+
+   sram-controller@01c0 {
+   compatible = "allwinner,sun4i-a10-sram-controller";
+   reg = <0x01c0 0x30>;
+   };
+};
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 76d6bd4..5d0f55d 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,6 +1,7 @@
 menu "SOC (System On Chip) specific Drivers"
 
 source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/sunxi/Kconfig"
 source "drivers/soc/ti/Kconfig"
 source "drivers/soc/versatile/Kconfig"
 
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 063113d..170bba3 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -3,6 +3,7 @@
 #
 
 obj-$(CONFIG_ARCH_QCOM)+= qcom/
+obj-$(CONFIG_ARCH_SUNXI)   += sunxi/
 obj-$(CONFIG_ARCH_TEGRA)   += tegra/
 obj-$(CONFIG_SOC_TI)   += ti/
 obj-$(CONFIG_PLAT_VERSATILE)   += versatile/
diff --git a/drivers/soc/sunxi/Kconfig b/drivers/soc/sunxi/Kconfig
new file mode 100644
index 000..212c634
--- /dev/null
+++ b/drivers/soc/sunxi/Kconfig
@@ -0,0 +1,12 @@
+#
+# Allwinner sunXi SoC drivers
+#
+config SUNXI_SRAM
+tristate "Allwinner sunXi SRAM Controller"
+depends on ARCH_SUNXI
+   default y
+help
+  Say y here to enable the SRAM controller support

Re: [PATCH V3 0/8] ARM: cpuidle: Unify the ARM64/ARM DT approach

[Daniel Lezcano]

On 03/20/2015 07:31 PM, Lorenzo Pieralisi wrote:

Hi Daniel,

On Fri, Mar 20, 2015 at 11:43:53AM +, Daniel Lezcano wrote:

There is a big number of cpuidle drivers for the ARM architecture.

These drivers have been cleaned up and grouped into the drivers/cpuidle
directory to keep track of the changes more easily and ensure the code
is following the same scheme across the drivers.

That had the benefit of simplifying the code and factor out a lot of common
parts. Beside that, as the drivers belong to the 'drivers' directory, we had
to split the arch specific bits and the generic code in order to keep
everything self contained. The platform driver paradigm was used for this
purpose.

Unfortunately, this approach is now no longer accepted and a different solution
must be provided to reach the same goal: one example is the Qualcomm cpuidle
driver upstreaming attempt.

In the meantime, ARM64 developed a generic cpuidle driver based on DT 
definition.

The DT definition provides an 'enable-method' to specify one of the cpu
operations (PSCI, ...).

This patchset unify this driver with ARM32, using the same DT definition.

Thanks with this patchset we can use the 'enable-method' to specify a cpu
operations, hence get rid of the platform driver approach and go further in the
cpuidle driver flexibility via the DT.


I had a look and the series seems fine, if you have a branch I can pull from
I will test on arm64 and add the required tags.


Yes, sure.

http://git.linaro.org/git-ro/people/daniel.lezcano/linux.git cpuidle/4.1

Thanks !

  -- Daniel


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
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/8] ARM: cpuidle: Unify the ARM64/ARM DT approach

[Lorenzo Pieralisi]

Hi Daniel,

On Fri, Mar 20, 2015 at 11:43:53AM +, Daniel Lezcano wrote:
> There is a big number of cpuidle drivers for the ARM architecture.
> 
> These drivers have been cleaned up and grouped into the drivers/cpuidle
> directory to keep track of the changes more easily and ensure the code
> is following the same scheme across the drivers.
> 
> That had the benefit of simplifying the code and factor out a lot of common
> parts. Beside that, as the drivers belong to the 'drivers' directory, we had
> to split the arch specific bits and the generic code in order to keep
> everything self contained. The platform driver paradigm was used for this
> purpose.
> 
> Unfortunately, this approach is now no longer accepted and a different 
> solution
> must be provided to reach the same goal: one example is the Qualcomm cpuidle
> driver upstreaming attempt.
> 
> In the meantime, ARM64 developed a generic cpuidle driver based on DT 
> definition.
> 
> The DT definition provides an 'enable-method' to specify one of the cpu
> operations (PSCI, ...).
> 
> This patchset unify this driver with ARM32, using the same DT definition.
> 
> Thanks with this patchset we can use the 'enable-method' to specify a cpu
> operations, hence get rid of the platform driver approach and go further in 
> the
> cpuidle driver flexibility via the DT.

I had a look and the series seems fine, if you have a branch I can pull from
I will test on arm64 and add the required tags.

Thank you,
Lorenzo
--
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] Doc: dt: arch_timer: discourage clock-frequency use

[Rob Herring]

On Fri, Mar 20, 2015 at 12:57 PM, Mark Rutland  wrote:
> The ARM Generic Timer (AKA the architected timer, arm_arch_timer)
> features a CPU register (CNTFRQ) which firmware is intended to
> initialize, and non-secure software can read to determine the frequency
> of the timer. On CPUs with secure state, this register cannot be written
> from non-secure states.
>
> The firmware of early SoCs featuring the timer did not correctly
> initialize CNTFRQ correctly on all CPUs, requiring the frequency to be
> described in DT as a workaround. This workaround is not complete however
> as it is exposed to all software in a privileged non-secure mode
> (including guests running under a hypervisor). The firmware and DTs for
> recent SoCs have followed the example set by these early SoCs.
>
> This patch updates the arch timer binding documentation to make it
> clearer that the use of the clock-frequency property is a poor
> work-around. The MMIO generic timer binding is similarly updated, though
> this is less of a concern as there is generally no need to expose the
> MMIO timers to guest OSs.
>
> Signed-off-by: Mark Rutland 
> Acked-by: Catalin Marinas 
> Acked-by: Marc Zyngier 
> Acked-by: Olof Johansson 
> Acked-by: Stephen Boyd 
> Cc: Rob Herring 
> Cc: Will Deacon 
> ---
>  Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> This patch has fallen through the cracks a few times [1,2], though that 
> appears
> to be my fault for not sorting out a reasonable Cc list.
>
> Rob, are you happy to take this through your tree?

Yes, I'll take it.

Rob

>
> Mark.
>
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/282804.html
> [2] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/282830.html
>
>
> diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt 
> b/Documentation/devicetree/bindings/arm/arch_timer.txt
> index 256b4d8..e774128 100644
> --- a/Documentation/devicetree/bindings/arm/arch_timer.txt
> +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
> @@ -17,7 +17,10 @@ to deliver its interrupts via SPIs.
>  - interrupts : Interrupt list for secure, non-secure, virtual and
>hypervisor timers, in that order.
>
> -- clock-frequency : The frequency of the main counter, in Hz. Optional.
> +- clock-frequency : The frequency of the main counter, in Hz. Should be 
> present
> +  only where necessary to work around broken firmware which does not 
> configure
> +  CNTFRQ on all CPUs to a uniform correct value. Use of this property is
> +  strongly discouraged; fix your firmware unless absolutely impossible.
>
>  - always-on : a boolean property. If present, the timer is powered through an
>always-on power domain, therefore it never loses context.
> @@ -46,7 +49,8 @@ Example:
>
>  - compatible : Should at least contain "arm,armv7-timer-mem".
>
> -- clock-frequency : The frequency of the main counter, in Hz. Optional.
> +- clock-frequency : The frequency of the main counter, in Hz. Should be 
> present
> +  only when firmware has not configured the MMIO CNTFRQ registers.
>
>  - reg : The control frame base address.
>
> --
> 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] arm64: dts: kill skeleton.dtsi

[Rob Herring]

On Fri, Mar 20, 2015 at 12:02 PM, Mark Rutland  wrote:
> While skeleton.dtsi was initially conceived as a simple way to bootstrap
> writing a dts, it has proven to be problematic:
>
> * The #address-cells and #size-cells values used in skeleton.dtsi may
>   not match what a user wants (e.g. when they need to describe a range
>   larger than 4GB).
>
> * For dts files where memory nodes have unit-addresses, it adds a
>   redundant /memory node, for which the reg entry may not be
>   appropriately sized (e.g. where #size-cells has been overridden).
>
> * For dts files which assume that a bootloader will fill in the memory
>   node(s), no node is present in the dts (and hence there is no attached
>   comment), making it hard to distinguish these cases from bad dts
>   files, and masking any warnings dtc may produce w.r.t. missing nodes.
>
> * The default empty /chosen and /aliases are somewhat useless, and it
>   would be preferable for dts to fill these in (e.g. for
>   /aliases/serial0 and /chosen/stdout-path).
>
> This patch removes skeleton.dtsi from arm64. There are currently no
> users, so we can remove it before any appear.
>
> Signed-off-by: Mark Rutland 
> Cc: Arnd Bergmann 
> Cc: Catalin Marinas 
> Cc: Olof Johansson 
> Cc: Rob Herring 
> Cc: Will Deacon 

Acked-by: Rob Herring 

> ---
>  arch/arm64/boot/dts/skeleton.dtsi | 13 -
>  1 file changed, 13 deletions(-)
>  delete mode 100644 arch/arm64/boot/dts/skeleton.dtsi
>
> Recent comments reminded me to send this.
>
> I've taken a look in mainline and linux-next and I see no skeleton.dtsi users
> in arch/arm64/boot/dts/.
>
> Mark.
>
> diff --git a/arch/arm64/boot/dts/skeleton.dtsi 
> b/arch/arm64/boot/dts/skeleton.dtsi
> deleted file mode 100644
> index 38ead82..000
> --- a/arch/arm64/boot/dts/skeleton.dtsi
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -/*
> - * Skeleton device tree; the bare minimum needed to boot; just include and
> - * add a compatible value.  The bootloader will typically populate the memory
> - * node.
> - */
> -
> -/ {
> -   #address-cells = <2>;
> -   #size-cells = <1>;
> -   chosen { };
> -   aliases { };
> -   memory { device_type = "memory"; reg = <0 0 0>; };
> -};
> --
> 1.9.1
>
>
> ___
> 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

[PATCH RESEND] Doc: dt: arch_timer: discourage clock-frequency use

[Mark Rutland]

The ARM Generic Timer (AKA the architected timer, arm_arch_timer)
features a CPU register (CNTFRQ) which firmware is intended to
initialize, and non-secure software can read to determine the frequency
of the timer. On CPUs with secure state, this register cannot be written
from non-secure states.

The firmware of early SoCs featuring the timer did not correctly
initialize CNTFRQ correctly on all CPUs, requiring the frequency to be
described in DT as a workaround. This workaround is not complete however
as it is exposed to all software in a privileged non-secure mode
(including guests running under a hypervisor). The firmware and DTs for
recent SoCs have followed the example set by these early SoCs.

This patch updates the arch timer binding documentation to make it
clearer that the use of the clock-frequency property is a poor
work-around. The MMIO generic timer binding is similarly updated, though
this is less of a concern as there is generally no need to expose the
MMIO timers to guest OSs.

Signed-off-by: Mark Rutland 
Acked-by: Catalin Marinas 
Acked-by: Marc Zyngier 
Acked-by: Olof Johansson 
Acked-by: Stephen Boyd 
Cc: Rob Herring 
Cc: Will Deacon 
---
 Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

This patch has fallen through the cracks a few times [1,2], though that appears
to be my fault for not sorting out a reasonable Cc list.

Rob, are you happy to take this through your tree?

Mark.

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/282804.html
[2] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/282830.html


diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt 
b/Documentation/devicetree/bindings/arm/arch_timer.txt
index 256b4d8..e774128 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -17,7 +17,10 @@ to deliver its interrupts via SPIs.
 - interrupts : Interrupt list for secure, non-secure, virtual and
   hypervisor timers, in that order.
 
-- clock-frequency : The frequency of the main counter, in Hz. Optional.
+- clock-frequency : The frequency of the main counter, in Hz. Should be present
+  only where necessary to work around broken firmware which does not configure
+  CNTFRQ on all CPUs to a uniform correct value. Use of this property is
+  strongly discouraged; fix your firmware unless absolutely impossible.
 
 - always-on : a boolean property. If present, the timer is powered through an
   always-on power domain, therefore it never loses context.
@@ -46,7 +49,8 @@ Example:
 
 - compatible : Should at least contain "arm,armv7-timer-mem".
 
-- clock-frequency : The frequency of the main counter, in Hz. Optional.
+- clock-frequency : The frequency of the main counter, in Hz. Should be present
+  only when firmware has not configured the MMIO CNTFRQ registers.
 
 - reg : The control frame base address.
 
-- 
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 3/4 v4] mailbox: Enable BCM2835 mailbox support

[Eric Anholt]

Jassi Brar  writes:

> On Fri, Mar 20, 2015 at 10:18 AM, Stephen Warren  
> wrote:
>> On 03/18/2015 05:28 PM, Eric Anholt wrote:
>>> Stephen Warren  writes:
>>>
 On 03/12/2015 08:32 PM, Eric Anholt wrote:
> 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?
>>>
>>> I guess?  If we found another firmware protocol, we could have
>>> that device's dt just specify a different compatible string.  But
>>> in the absence of another firmware to talk to, I'm not sure what
>>> you want here.
>>
>> I would expect the mailbox driver to expose a single channel that just
>> transports 32-bit values, since the HW doesn't impose any kind of
>> structure on the values it transports AFAIK. Clients of the mailbox
>> driver would formulate the messages they send through the mailox using
>> the macros above.
>>
> Yes, it should be so.

I'm getting pretty frustrated here.

So, if I build a global client serializing requests and stop presenting
channels, what exactly is the generic mailbox infrastructure gaining me?
I don't need add_to_rbuf.  I don't need tpoll_txdone.  I don't need
tx_tick.  I don't need peek_data.  I don't need channels.  It doesn't
even handle waiting on requests for me, and I keep having to do it in
clients.  There's nothing left that the generic code is doing for me.

If I have to do any more changes ot this driver (we're at 27 hours of
just my work on it so far...), I'd rather go back to the trivial driver
we had before that simply, obviously did what we wanted.


signature.asc
Description: PGP signature

Re: [PATCH 4/6] ARM64: cpuidle: Rename cpu_init_idle to a common function name

[Catalin Marinas]

On Tue, Mar 03, 2015 at 01:29:35PM +0100, Daniel Lezcano wrote:
> With this change the cpuidle-arm64.c file calls the same function name
> for both ARM and ARM64.
> 
> Signed-off-by: Daniel Lezcano 

Acked-by: Catalin Marinas 

That said, if you find some names to avoid the arm_ prefix it's even
better but either way my ack still stands.
--
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] mmc: OCTEON: Add host driver for OCTEON MMC controller

[David Daney]

On 03/20/2015 02:57 AM, Ulf Hansson wrote:

On 16 March 2015 at 16:06, Aleksey Makarov  wrote:

The OCTEON MMC controller is currently found on cn61XX and cnf71XX
devices.  Device parameters are configured from device tree data.

eMMC, MMC and SD devices are supported.

Tested-by: Aaro Koskinen 
Signed-off-by: Chandrakala Chavva 
Signed-off-by: David Daney 
Signed-off-by: Aleksey Makarov 
Signed-off-by: Leonid Rosenboim 
Signed-off-by: Peter Swain 
Signed-off-by: Aaron Williams 
---
  .../devicetree/bindings/mmc/octeon-mmc.txt |   69 +
  drivers/mmc/host/Kconfig   |   10 +
  drivers/mmc/host/Makefile  |1 +
  drivers/mmc/host/octeon_mmc.c  | 1415 
  4 files changed, 1495 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/mmc/octeon-mmc.txt
  create mode 100644 drivers/mmc/host/octeon_mmc.c

This patch should be applied on top of the patchset
"MIPS: OCTEON: flash: syncronize bootbus access"
https://lkml.kernel.org/g/<1425565893-30614-1-git-send-email-aleksey.maka...@auriga.com>

v3:
https://lkml.kernel.org/g/<1425567033-31236-1-git-send-email-aleksey.maka...@auriga.com>

Changes in v4:
- The sparse error discovered by Aaro Koskinen has been fixed
- Other sparse warnings have been silenced

Changes in v3:
- Rebased to v4.0-rc2
- Use gpiod_*() functions instead of legacy gpio
- Cosmetic changes

Changes in v2: All the fixes suggested by Mark Rutland were implemented:
- Device tree parsing has been fixed
- Device tree docs have been fixed
- Comment about errata workaroud has been added

diff --git a/Documentation/devicetree/bindings/mmc/octeon-mmc.txt 
b/Documentation/devicetree/bindings/mmc/octeon-mmc.txt
new file mode 100644
index 000..40dd7f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/octeon-mmc.txt
@@ -0,0 +1,69 @@
+* OCTEON SD/MMC Host Controller
+
+This controller is present on some members of the Cavium OCTEON SoC
+family, provide an interface for eMMC, MMC and SD devices.  There is a
+single controller that may have several "slots" connected.  These


Even it it may have several slots, that's not being supported by the
mmc core from a MMC/SD/SDIO protocol perspective.

We have hade some discussions around this historocally, and I doubt
that we ever will be adding this.

So, with that in mind I would rather see that you remove the concept
of "slot" entirely and thus don't do the DT configuration within a
child node.


As you note this is a device tree representation, and thus really has 
nothing to do with the capabilities and internal structure of any given 
operating system.


The hardware really is structured as a single controller with a single 
set of registers and register fields that can control multiple "slots". 
 There are not multiple independent slot controllers.


This device tree representation reflects,  with fidelity, the actual 
hardware topology.


But none of this matters, because the device tree bindings train has 
already left the station.  You should have expressed opposition to this 
binding back when it was first discussed:


http://www.linux-mips.org/archives/linux-mips/2012-05/msg00119.html

The device tree is deployed in the boot firmware of shipping devices, 
and we are merely documenting what is there.





+slots appear as children of the main controller node.
+The DMA engine is an integral part of the controller block.
+
+Required properties:
+- compatible : Should be "cavium,octeon-6130-mmc" or "cavium,octeon-7890-mmc"
+- reg : Two entries:
+   1) The base address of the MMC controller register bank.
+   2) The base address of the MMC DMA engine register bank.
+- interrupts :
+   For "cavium,octeon-6130-mmc": two entries:
+   1) The MMC controller interrupt line.
+   2) The MMC DMA engine interrupt line.
+   For "cavium,octeon-7890-mmc": nine entries:
+   1) The next block transfer of a multiblock transfer has completed 
(BUF_DONE)
+   2) Operation completed successfully (CMD_DONE).
+   3) DMA transfer completed successfully (DMA_DONE).
+   4) Operation encountered an error (CMD_ERR).
+   5) DMA transfer encountered an error (DMA_ERR).
+   6) Switch operation completed successfully (SWITCH_DONE).
+   7) Switch operation encountered an error (SWITCH_ERR).
+   8) Internal DMA engine request completion interrupt (DONE).
+   9) Internal DMA FIFO underflow (FIFO).


So are you really having that many irq lines to the controller?


Yes.  It's weird, isn't it.

The interrupt controller has 2^20 sources, these are just 10 of them.




+- #address-cells : Must be <1>
+- #size-cells : Must be <0>
+
+Required properties of child nodes:
+- compatible : Should be "cavium,octeon-6130-mmc-slot".
+- reg : The slot number.
+
+Optional properties of child nodes:
+- cd-gpios : Specify GPIOs for card detection
+- wp-gpios : Specify GPIOs for write protection
+- power-gpios : Specify GPIOs for power 

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

[Eric Anholt]

Stephen Warren  writes:

> On 03/18/2015 05:28 PM, Eric Anholt wrote:
>> Stephen Warren  writes:
>> 
>>> On 03/12/2015 08:32 PM, Eric Anholt wrote:
 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?
>> 
>> I guess?  If we found another firmware protocol, we could have
>> that device's dt just specify a different compatible string.  But
>> in the absence of another firmware to talk to, I'm not sure what
>> you want here.
>
> I would expect the mailbox driver to expose a single channel that just
> transports 32-bit values, since the HW doesn't impose any kind of
> structure on the values it transports AFAIK. Clients of the mailbox
> driver would formulate the messages they send through the mailox using
> the macros above.
>
> I'm not sure whether the mailbox core allows multiple clients for the
> same mailbox channel though? This HW appears to require it.

Yeah, that's the problem.


signature.asc
Description: PGP signature

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

[Catalin Marinas]

On Tue, Mar 03, 2015 at 01:29:33PM +0100, Daniel Lezcano wrote:
> diff --git a/arch/arm64/include/asm/cpuidle.h 
> b/arch/arm64/include/asm/cpuidle.h
> index 0710654..1bee287 100644
> --- a/arch/arm64/include/asm/cpuidle.h
> +++ b/arch/arm64/include/asm/cpuidle.h
> @@ -15,5 +15,8 @@ static inline int cpu_suspend(unsigned long arg)
>   return -EOPNOTSUPP;
>  }
>  #endif
> -
> +static inline int arm_cpuidle_suspend(int index)
> +{
> + return cpu_suspend(index);
> +}
>  #endif

Acked-by: Catalin Marinas 
--
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: [FOR DISCUSSION 0/9] Dove PMU support

[Russell King - ARM Linux]

On Fri, Mar 20, 2015 at 01:44:30PM +0100, Rafael J. Wysocki wrote:
> Both work for me, actually.  I think that Kevin has ACKed the patch despite
> the comments, so it would be fine to apply it I guess.

Here's the set of three - with the second one reworked.

 drivers/base/power/domain.c | 58 +
 include/linux/pm_domain.h   |  6 ++---
 2 files changed, 40 insertions(+), 24 deletions(-)

-- 
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: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Sebastian Reichel]

Hi,

On Fri, Mar 20, 2015 at 02:57:12PM +0100, Dr. H. Nikolaus Schaller wrote:
> > On Fri, Mar 20, 2015 at 09:54:21AM +0100, Dr. H. Nikolaus Schaller wrote:
> >> [...]
> >> And we do not write a driver for the w2sg0004 but the regulator inside that
> >> chip.
> > 
> > DT describes the hardware structure and not the Linux driver
> > structure.
> 
> I am not advocating for describing the Linux driver structure in DT.
> Rather I suggest that the DT should describe hardware and there
> is a regulator inside that chip…

some drivers also have embedded clocks, which are not described,
since they are only useful for the device itself. Exposing them
is not useful.

> Linux drivers can follow that or mix everything into a single
> driver if that is better.

The DT binding is completly independent of drivers.

> >> You also won’t expect that the omap3 driver hides everything. You
> >> expect that the twl4030 provides some regulators that can be enabled
> >> by subsystems inside the omap3. And if I remember correctly there are
> >> regulators inside the omap3 which have explicit regulator nodes in the DT.
> > 
> > so let's have a look at twl regulators. They can be found below
> > the twl node, so they will look similar to
> > 
> > / -> omap3 -> i2c -> twl -> regulator
> > 
> > So properly mapped to the w2sg0004 device this would put your
> > regulator to
> > 
> > / -> omap3 -> serial -> w2sg0004 -> regulator
> 
> Yes. Indeed.
> 
> Currently it is
> 
> omap3 -> serial -> serial-power-manager (trying to cover a multitude
> of different chips).

No. The DT is omap3 -> serial -> w2sg0004 and w2sg0004 is
handled by a generic driver. If the kernel ever gets more
specific support for UART attached gps you can simply remove
the compatible value from the generic driver and create a
specific one.

> > This will gain you nothing as far as I can tell.
> 
> And because of that I think Neil’s argument isn’t for or against
> anything.
> 
> > 
> > Please note that subdevices under the serial node are pretty useful,
> > since then the kernel can e.g. automatically setup correct line
> > disciplines for serial attached bluetooth chips and make bluetooth
> > work out of the box.
> 
> I don’t doubt that such subnodes are useful. I just object mixing
> different chips and controls into a single subnode driver.

Well the binding allows to split this into multiple drivers
in the future (if needed).

> And as soon as you want to control line disciplines from such
> a subnode, you indeed need a driver for each variant.

Obviously I do not use the generic driver, but a specific one for
this task. Very simple devices (from kernel's point of view) can
still be handled by a generic driver (as Neil does).

> So a GPS chip needing some line discipline could be
> 
> > / -> omap3 -> serial -> w2sg0004 -> line-discipline
> > / -> omap3 -> serial -> w2sg0004 -> regulator

Actually no. The line discipline does not describe HW, but just
how linux handles the device. It should not be part of DT at all.
The kernel will see compatible string for w2sg0004 and load the
correct line discipline.

> And if omap3 -> serial can directly control a regulator, it can
> easily be the w2sg0004 -> regulator

sure.

> > I am aware, that the Linux kernel has no such thing for serial
> > attached GPS devices, but that's Linux specific and irrelevant
> > for the DT description.
> > 
> >> The w2sg0004-regulator approach just follows this principle.
> >> Anyone willing to control the power of the w2sg0004 can use this
> >> regulator interface.
> > 
> > From a HW perspective your regulator "hides" the information, that
> > there is a device attached to the serial port and instead claims,
> > that a regulator is needed to make the serial port work.
> 
> Yes, without this regulator the serial port does not work. It is IMHO
> more important than stating the obvious that a serial device is
> connected to a serial port.

This is actually not correct though. The serial port does work
without the regulator. The remote side does not work without the
regulator. So the regulator should be referenced by the w2sg0004
node, so it would be

serial-port {
w2sg0004 {
w2sg_vdd: gpio-regulator { enable-gpio = <&some_gpio> };
vdd-supply = <&w2sg_vdd>;
}
}

And at this point you can simply drop the regulator stuff from DT,
since its device internal (and only adds complexity). For other
devices these kind of ressources are also not exposed in DT (e.g.
internal clocks).

> And if there is nothing to hide (the obvious serial interface
> wiring), why describe it at all?
> 
> Anyways, in my proposal there will be a subnode of the uart, the
> one where it is specified that it should control the regulator of the
> w2sg.
> 
> Basically, Neil’s proposal already covers this case. His bluetooth
> subnode just controls &vaux4 which turns on power for the w2cbw003
> chip.
> 
> So for my view it is not really understandable why one uart subnode
> can control a regulator, and the other

[PATCH] arm64: dts: kill skeleton.dtsi

[Mark Rutland]

While skeleton.dtsi was initially conceived as a simple way to bootstrap
writing a dts, it has proven to be problematic:

* The #address-cells and #size-cells values used in skeleton.dtsi may
  not match what a user wants (e.g. when they need to describe a range
  larger than 4GB).

* For dts files where memory nodes have unit-addresses, it adds a
  redundant /memory node, for which the reg entry may not be
  appropriately sized (e.g. where #size-cells has been overridden).

* For dts files which assume that a bootloader will fill in the memory
  node(s), no node is present in the dts (and hence there is no attached
  comment), making it hard to distinguish these cases from bad dts
  files, and masking any warnings dtc may produce w.r.t. missing nodes.

* The default empty /chosen and /aliases are somewhat useless, and it
  would be preferable for dts to fill these in (e.g. for
  /aliases/serial0 and /chosen/stdout-path).

This patch removes skeleton.dtsi from arm64. There are currently no
users, so we can remove it before any appear.

Signed-off-by: Mark Rutland 
Cc: Arnd Bergmann 
Cc: Catalin Marinas 
Cc: Olof Johansson 
Cc: Rob Herring 
Cc: Will Deacon 
---
 arch/arm64/boot/dts/skeleton.dtsi | 13 -
 1 file changed, 13 deletions(-)
 delete mode 100644 arch/arm64/boot/dts/skeleton.dtsi

Recent comments reminded me to send this.

I've taken a look in mainline and linux-next and I see no skeleton.dtsi users
in arch/arm64/boot/dts/.

Mark.

diff --git a/arch/arm64/boot/dts/skeleton.dtsi 
b/arch/arm64/boot/dts/skeleton.dtsi
deleted file mode 100644
index 38ead82..000
--- a/arch/arm64/boot/dts/skeleton.dtsi
+++ /dev/null
@@ -1,13 +0,0 @@
-/*
- * Skeleton device tree; the bare minimum needed to boot; just include and
- * add a compatible value.  The bootloader will typically populate the memory
- * node.
- */
-
-/ {
-   #address-cells = <2>;
-   #size-cells = <1>;
-   chosen { };
-   aliases { };
-   memory { device_type = "memory"; reg = <0 0 0>; };
-};
-- 
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

[PATCH v5] add support for Freescale's MMA8653FC 10 bit accelerometer

[Martin Kepplinger]

From: Martin Kepplinger 

The MMA8653FC is a low-power, three-axis, capacitive micromachined
accelerometer with 10 bits of resolution with flexible user-programmable
options.

Embedded interrupt functions enable overall power savings, by relieving the
host processor from continuously polling data, for example using the poll()
system call.

The device can be configured to generate wake-up interrupt signals from any
combination of the configurable embedded functions, enabling the MMA8653FC
to monitor events while remaining in a low-power mode during periods of
inactivity.

This driver provides devicetree properties to program the device's behaviour
and a simple, tested and documented sysfs interface. The data sheet and more
information is available on Freescale's website.

Signed-off-by: Martin Kepplinger 
Signed-off-by: Christoph Muellner 
---

This would be v5 aswell, but appies to the current -next tree.

 drivers/staging/mma8653fc/Kconfig |  10 +
 drivers/staging/mma8653fc/Makefile|   1 +
 drivers/staging/mma8653fc/TODO| 146 ++
 drivers/staging/mma8653fc/mma8653fc.c | 864 ++
 4 files changed, 1021 insertions(+)
 create mode 100644 drivers/staging/mma8653fc/Kconfig
 create mode 100644 drivers/staging/mma8653fc/Makefile
 create mode 100644 drivers/staging/mma8653fc/TODO
 create mode 100644 drivers/staging/mma8653fc/mma8653fc.c

diff --git a/drivers/staging/mma8653fc/Kconfig 
b/drivers/staging/mma8653fc/Kconfig
new file mode 100644
index 000..988451b
--- /dev/null
+++ b/drivers/staging/mma8653fc/Kconfig
@@ -0,0 +1,10 @@
+config MMA8653FC
+tristate "MMA8653FC - Freescale's 3-Axis, 10-bit Digital Accelerometer"
+depends on I2C
+default n
+help
+  Say Y here if you want to support Freescale's MMA8653FC Accelerometer
+  through I2C interface.
+
+  To compile this driver as a module, choose M here: the
+  module will be called mma8653fc.
diff --git a/drivers/staging/mma8653fc/Makefile 
b/drivers/staging/mma8653fc/Makefile
new file mode 100644
index 000..9a245a3
--- /dev/null
+++ b/drivers/staging/mma8653fc/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MMA8653FC) += mma8653fc.o
diff --git a/drivers/staging/mma8653fc/TODO b/drivers/staging/mma8653fc/TODO
new file mode 100644
index 000..0a31225
--- /dev/null
+++ b/drivers/staging/mma8653fc/TODO
@@ -0,0 +1,146 @@
+- move to IIO device API. The current DT/sysfs interface is documented below
+
+Documentation/ABI/testing/...
+-
+What:  /sys/bus/i2c/drivers/mma8653fc/*/standby
+Date:  March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Write 0 to this in order to turn on the device, and 1 to turn
+   it off. Read to see if it is turned on or off.
+
+
+What:  /sys/bus/i2c/drivers/mma8653fc/*/currentmode
+Date:  March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Reading this provides the current state of the device, read
+   directly from a register. This can be "standby", "wake" or
+   "sleep".
+
+
+What:  /sys/bus/i2c/drivers/mma8653fc/*/position
+Date:  March 2015
+Contact:   Martin Kepplinger 
+Description:
+   Read only. Without interrupts enabled gets current position
+   values by reading. Poll "position" with interrupt conditions
+   set, to get notified; see Documentation/.../fsl,mma8653fc.txt
+
+   position file format:
+   "x y z [landscape/portrait status] [front/back status]"
+
+   x y z values:
+   in mg
+   landscape/portrait status char:
+   r   landscape right
+   d   portrait down
+   u   portrait up
+   l   landscape left
+   front/back status char:
+   f   front facing
+   b   back facing
+
+
+Documentation/devicetree/bindings/...
+-
+Required properties:
+- compatible
+   "fsl,mma8653fc"
+- reg
+   I2C address
+
+Optional properties:
+
+- interrupt-parent
+   a phandle for the interrupt controller (see
+   Documentation/devicetree/bindings/interrupt-controller/interrupts.txt)
+- interrupts
+   interrupt line to which the chip is connected (active low)
+- int1
+   set to use interrupt line 1, default is line 2
+   the interrupt sources can be routed to one of the two lines
+- ir-freefall-motion-x
+   activate freefall/motion interrupts on x axis
+- ir-freefall-motion-y
+   activate freefall/motion interrupts on y axis
+- ir-freefall-motion-z
+   activate freefall/motion interrupts on z axis
+- irq-threshold
+   0 < value < 8000: threshold for motion interrupts in mg
+- ir-landscape-portrait
+   activate landscape/portrait interr