date:20150406

Stephen Boyd pointed out that the current design of the Qualcomm RPM and
regulator driver consumes 12-20kB of ram just for the platform_device structs.

This third iteration of the patch comes with a patch at the end to tidy up the
probe function - after the various refactorings.

Dropped from the series is the patch to add "regulator-allow-drms"; so it has a
functional dependency towards such a patch, to get drms handling running again.
But if Stephen is fine with patch 5 as answer to his concerns with patch 4 I
think we should merge this.

Changes since v2:
- Dropped unrelated drms dt property patch
- Fixed minor spelling misstake in dt binding
- Added patch to tidy up probe function

Changes since v1:
- Reworked DRMS handling to not have the driver specify the support

Bjorn Andersson (5):
  mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes
  regulator: qcom: Don't enable DRMS in driver
  regulator: qcom: Refactor of-parsing code
  regulator: qcom: Rework to single platform device
  regulator: qcom: Tidy up probe()

 Documentation/devicetree/bindings/mfd/qcom-rpm.txt | 217 ++-
 drivers/regulator/qcom_rpm-regulator.c | 290 ++---
 2 files changed, 398 insertions(+), 109 deletions(-)

-- 
1.8.2.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 v3 1/5] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes

Add the regulator subnodes to the Qualcomm RPM MFD device tree bindings.

Reviewed-by: Stephen Boyd 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- s/notes/nodes from Stephen

 Documentation/devicetree/bindings/mfd/qcom-rpm.txt | 217 +++--
 1 file changed, 205 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt 
b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt
index 85e3198..f7c22c5 100644
--- a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt
+++ b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt
@@ -31,16 +31,6 @@ frequencies.
Value type: 
Definition: must be the three strings "ack", "err" and "wakeup", in 
order
 
-- #address-cells:
-   Usage: required
-   Value type: 
-   Definition: must be 1
-
-- #size-cells:
-   Usage: required
-   Value type: 
-   Definition: must be 0
-
 - qcom,ipc:
Usage: required
Value type: 
@@ -52,6 +42,188 @@ frequencies.
- u32 representing the ipc bit within the register
 
 
+= SUBNODES
+
+The RPM exposes resources to its subnodes. The below bindings specify the set
+of valid subnodes that can operate on these resources.
+
+== Regulators
+
+Regulator nodes are identified by their compatible:
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,rpm-pm8058-regulators"
+   "qcom,rpm-pm8901-regulators"
+   "qcom,rpm-pm8921-regulators"
+
+- vdd_l0_l1_lvs-supply:
+- vdd_l2_l11_l12-supply:
+- vdd_l3_l4_l5-supply:
+- vdd_l6_l7-supply:
+- vdd_l8-supply:
+- vdd_l9-supply:
+- vdd_l10-supply:
+- vdd_l13_l16-supply:
+- vdd_l14_l15-supply:
+- vdd_l17_l18-supply:
+- vdd_l19_l20-supply:
+- vdd_l21-supply:
+- vdd_l22-supply:
+- vdd_l23_l24_l25-supply:
+- vdd_ncp-supply:
+- vdd_s0-supply:
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s3-supply:
+- vdd_s4-supply:
+   Usage: optional (pm8058 only)
+   Value type: 
+   Definition: reference to regulator supplying the input pin, as
+   described in the data sheet
+
+- lvs0_in-supply:
+- lvs1_in-supply:
+- lvs2_in-supply:
+- lvs3_in-supply:
+- mvs_in-supply:
+- vdd_l0-supply:
+- vdd_l1-supply:
+- vdd_l2-supply:
+- vdd_l3-supply:
+- vdd_l4-supply:
+- vdd_l5-supply:
+- vdd_l6-supply:
+- vdd_s0-supply:
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s3-supply:
+- vdd_s4-supply:
+   Usage: optional (pm8901 only)
+   Value type: 
+   Definition: reference to regulator supplying the input pin, as
+   described in the data sheet
+
+- vdd_l1_l2_l12_l18-supply:
+- vdd_l3_l15_l17-supply:
+- vdd_l4_l14-supply:
+- vdd_l5_l8_l16-supply:
+- vdd_l6_l7-supply:
+- vdd_l9_l11-supply:
+- vdd_l10_l22-supply:
+- vdd_l21_l23_l29-supply:
+- vdd_l24-supply:
+- vdd_l25-supply:
+- vdd_l26-supply:
+- vdd_l27-supply:
+- vdd_l28-supply:
+- vdd_ncp-supply:
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s4-supply:
+- vdd_s5-supply:
+- vdd_s6-supply:
+- vdd_s7-supply:
+- vdd_s8-supply:
+- vin_5vs-supply:
+- vin_lvs1_3_6-supply:
+- vin_lvs2-supply:
+- vin_lvs4_5_7-supply:
+   Usage: optional (pm8921 only)
+   Value type: 
+   Definition: reference to regulator supplying the input pin, as
+   described in the data sheet
+
+The regulator node houses sub-nodes for each regulator within the device. Each
+sub-node is identified using the node's name, with valid values listed for each
+of the pmics below.
+
+pm8058:
+   l0, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15,
+   l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, s0, s1, s2, s3, s4,
+   lvs0, lvs1, ncp
+
+pm8901:
+   l0, l1, l2, l3, l4, l5, l6, s0, s1, s2, s3, s4, lvs0, lvs1, lvs2, lvs3,
+   mvs
+
+pm8921:
+   s1, s2, s3, s4, s7, s8, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
+   l12, l14, l15, l16, l17, l18, l21, l22, l23, l24, l25, l26, l27, l28,
+   l29, lvs1, lvs2, lvs3, lvs4, lvs5, lvs6, lvs7, usb-switch, hdmi-switch,
+   ncp
+
+The content of each sub-node is defined by the standard binding for regulators 
-
+see regulator.txt - with additional custom properties described below:
+
+=== Switch-mode Power Supply regulator custom properties
+
+- bias-pull-down:
+   Usage: optional
+   Value type: 
+   Definition: enable pull down of the regulator when inactive
+
+- qcom,switch-mode-frequency:
+   Usage: required
+   Value type: 
+   Definition: Frequency (Hz) of the switch-mode power supply;
+   must be one of:
+   1920, 960, 640, 480, 384, 320,
+   274, 240, 213, 192, 175, 160,
+   148, 137, 128, 120
+
+- qcom,force-mode:
+   Usage: optional (default if no other qcom,force-mode is specified)
+   Value type: 
+   Defintion: indicates that the regulator should be forced to a
+

Re: [PATCH v2 07/17] soc: tegra: pmc: Add generic PM domain support

2015-04-06 Thread Kevin Hilman

Hi Vince,

Vince Hsu  writes:

> From: Thierry Reding 
>
> The PM domains are populated from DT, and the PM domain consumer devices are
> also bound to their relevant PM domains by DT.
>
> Signed-off-by: Thierry Reding 
> [vinceh: make changes based on Thierry and Peter's suggestions]
> Signed-off-by: Vince Hsu 
> ---
> v2: revise comment in tegra_powergate_remove_clamping()
> address Alex's comments

Sorry for the late review..., somehow I just noticed this while
reviewing some other PM domain support.

It's nice to see this migrating to PM domains.  Some comments below...

[...]

>  /**
>   * struct tegra_pmc - NVIDIA Tegra PMC
> + * @dev: pointer to parent device
>   * @base: pointer to I/O remapped register region
>   * @clk: pointer to pclk clock
> + * @soc: SoC-specific data
>   * @rate: currently configured rate of pclk
>   * @suspend_mode: lowest suspend mode available
>   * @cpu_good_time: CPU power good time (in microseconds)
> @@ -126,7 +158,9 @@ struct tegra_pmc_soc {
>   * @cpu_pwr_good_en: CPU power good signal is enabled
>   * @lp0_vec_phys: physical base address of the LP0 warm boot code
>   * @lp0_vec_size: size of the LP0 warm boot code
> + * @powergates: list of power gates
>   * @powergates_lock: mutex for power gate register access
> + * @nb: bus notifier for generic power domains
>   */
>  struct tegra_pmc {
>   struct device *dev;
> @@ -150,7 +184,12 @@ struct tegra_pmc {
>   u32 lp0_vec_phys;
>   u32 lp0_vec_size;
>  
> + struct tegra_powergate *powergates;
>   struct mutex powergates_lock;
> + struct notifier_block nb;

I don't see these notifiers used anywhere in this series.  What is the
intended use here?   There have been some other discussions about how to
do this more generically for  PM domains[1], so I'd prefer not to see this
in SoC specific PM domains.  In this case, it appears unused, so should
be fine to drop (for now.)

[...]

> +static int tegra_pmc_powergate_power_off(struct generic_pm_domain *domain)
> +{
> + struct tegra_powergate *powergate = to_powergate(domain);
> + struct tegra_pmc *pmc = powergate->pmc;
> + int err;
> +
> + dev_dbg(pmc->dev, "> %s(domain=%p)\n", __func__, domain);
> + dev_dbg(pmc->dev, "  name: %s\n", domain->name);
> +
> + /* never turn off these partitions */
> + switch (powergate->id) {
> + case TEGRA_POWERGATE_CPU:
> + case TEGRA_POWERGATE_CPU1:
> + case TEGRA_POWERGATE_CPU2:
> + case TEGRA_POWERGATE_CPU3:
> + case TEGRA_POWERGATE_CPU0:
> + case TEGRA_POWERGATE_C0NC:
> + case TEGRA_POWERGATE_IRAM:
> + dev_dbg(pmc->dev, "not disabling always-on partition %s\n",
> + domain->name);
> + err = -EINVAL;
> + goto out;
> + }

You're re-inventing the per-device QoS flag: PM_QOS_FLAG_NO_POWER_OFF
which could be used here to prevent ->power_off from ever being called.

Alternately, if this really a static configuraion, why even register the
->power_off hook for these domains in the first place?

[...]

> +static int tegra_pmc_powergate_init_subdomain(struct tegra_pmc *pmc)
> +{
> + struct tegra_powergate *powergate;
> +
> + list_for_each_entry(powergate, &pmc->powergate_list, head) {
> + struct device_node *pdn;
> + struct tegra_powergate *parent = NULL;
> + struct tegra_powergate *temp;
> + int err;
> +
> + pdn = of_parse_phandle(powergate->of_node, "depend-on", 0);
> + if (!pdn)
> + continue;

I'm not really following the need for the "depend-on" property here.

Looking at the example .dtsi files in this series, it seems to me what
is being described is nested hardware power domains, which genpd already
supports.  Any reason you're not using that build-in support?

[...]

> @@ -831,12 +1405,19 @@ static int tegra_pmc_probe(struct platform_device 
> *pdev)
>  
>   tegra_pmc_init_tsense_reset(pmc);
>  
> + if (IS_ENABLED(CONFIG_PM_GENERIC_DOMAINS)) {
> + err = tegra_powergate_init(pmc);
> + if (err < 0)
> + return err;
> + }

On many SoCs there's some special handling for the !CONFIG_PM case here
such that all the PM domains are enabled by default in case they are not
enabled by the bootloader.

>   if (IS_ENABLED(CONFIG_DEBUG_FS)) {
>   err = tegra_powergate_debugfs_init();
>   if (err < 0)
>   return err;
>   }
>  
> + dev_dbg(&pdev->dev, "< %s()\n", __func__);
>   return 0;
>  }

Kevin

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/299345.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 V2 2/2] stmmac: Add IMG Pistachio platform glue layer

2015-04-06 Thread Andrew Bresticker

On Mon, Apr 6, 2015 at 3:10 PM, Arnd Bergmann  wrote:
> On Monday 06 April 2015 14:42:38 Andrew Bresticker wrote:
>> At the moment, the only additional setup required for the DWMAC
>> on the IMG Pistachio SoC is to request and enable a separate gate
>> clock for the register interface.
>>
>> Signed-off-by: Andrew Bresticker 
>> Signed-off-by: Govindraj Raja 
>> Cc: James Hartley 
>
> Why do you need a special glue driver for that?
>
> Since you don't do anything special, I'd say it should be possible
> to handle this with just the default driver.

Right, at the moment we only need to request and enable a second
clock, which could be added to the core driver.  If we don't expect to
have to extend this driver to deal with other configurations (which
IIRC there were some concerns about when I wrote this), then I'm fine
with folding this change into the core driver - James?

Thanks,
Andrew
--
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 2/2] stmmac: Add IMG Pistachio platform glue layer

2015-04-06 Thread Arnd Bergmann

On Monday 06 April 2015 14:42:38 Andrew Bresticker wrote:
> At the moment, the only additional setup required for the DWMAC
> on the IMG Pistachio SoC is to request and enable a separate gate
> clock for the register interface.
> 
> Signed-off-by: Andrew Bresticker 
> Signed-off-by: Govindraj Raja 
> Cc: James Hartley 

Why do you need a special glue driver for that?

Since you don't do anything special, I'd say it should be possible
to handle this with just the default driver.

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

[PATCH V2 2/2] stmmac: Add IMG Pistachio platform glue layer

2015-04-06 Thread Andrew Bresticker

At the moment, the only additional setup required for the DWMAC
on the IMG Pistachio SoC is to request and enable a separate gate
clock for the register interface.

Signed-off-by: Andrew Bresticker 
Signed-off-by: Govindraj Raja 
Cc: James Hartley 
---
Changes from v1:
 - Do not potentially assign an error pointer to pdata->sys_clk
---
 drivers/net/ethernet/stmicro/stmmac/Makefile   |  3 +-
 .../net/ethernet/stmicro/stmmac/dwmac-pistachio.c  | 59 ++
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |  1 +
 .../net/ethernet/stmicro/stmmac/stmmac_platform.h  |  1 +
 4 files changed, 63 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-pistachio.c

diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile 
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 73c2715..8efb622 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -6,7 +6,8 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o 
ring_mode.o  \
 
 obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
 stmmac-platform-objs:= stmmac_platform.o dwmac-meson.o dwmac-sunxi.o   \
-  dwmac-sti.o dwmac-socfpga.o dwmac-rk.o
+  dwmac-sti.o dwmac-socfpga.o dwmac-rk.o   \
+  dwmac-pistachio.o
 
 obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
 stmmac-pci-objs:= stmmac_pci.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-pistachio.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-pistachio.c
new file mode 100644
index 000..5e0b958
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-pistachio.c
@@ -0,0 +1,59 @@
+/*
+ * IMG Pistachio DWMAC glue layer
+ *
+ * Copyright (C) 2015 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct pistachio_dwmac_priv_data {
+   struct clk *sys_clk;
+};
+
+static void *pistachio_dwmac_setup(struct platform_device *pdev)
+{
+   struct pistachio_dwmac_priv_data *pdata;
+   struct clk *clk;
+
+   pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return ERR_PTR(-ENOMEM);
+
+   clk = devm_clk_get(&pdev->dev, "sys");
+   if (IS_ERR(clk)) {
+   dev_err(&pdev->dev, "Failed to get sys clock: %ld\n",
+   PTR_ERR(clk));
+   return clk;
+   }
+   pdata->sys_clk = clk;
+
+   return pdata;
+}
+
+static int pistachio_dwmac_init(struct platform_device *pdev, void *priv)
+{
+   struct pistachio_dwmac_priv_data *pdata = priv;
+
+   return clk_prepare_enable(pdata->sys_clk);
+}
+
+static void pistachio_dwmac_exit(struct platform_device *pdev, void *priv)
+{
+   struct pistachio_dwmac_priv_data *pdata = priv;
+
+   clk_disable_unprepare(pdata->sys_clk);
+}
+
+const struct stmmac_of_data pistachio_dwmac_data = {
+   .setup = pistachio_dwmac_setup,
+   .init = pistachio_dwmac_init,
+   .exit = pistachio_dwmac_exit,
+   .has_gmac = true,
+};
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index f9b42f1..d5de361 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -34,6 +34,7 @@
 static const struct of_device_id stmmac_dt_ids[] = {
/* SoC specific glue layers should come before generic bindings */
{ .compatible = "rockchip,rk3288-gmac", .data = &rk3288_gmac_data},
+   { .compatible = "img,pistachio-dwmac", .data = &pistachio_dwmac_data},
{ .compatible = "amlogic,meson6-dwmac", .data = &meson6_dwmac_data},
{ .compatible = "allwinner,sun7i-a20-gmac", .data = &sun7i_gmac_data},
{ .compatible = "st,stih415-dwmac", .data = &stih4xx_dwmac_data},
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.h 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.h
index 093eb99..101e635 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.h
@@ -25,5 +25,6 @@ extern const struct stmmac_of_data stih4xx_dwmac_data;
 extern const struct stmmac_of_data stid127_dwmac_data;
 extern const struct stmmac_of_data socfpga_gmac_data;
 extern const struct stmmac_of_data rk3288_gmac_data;
+extern const struct stmmac_of_data pistachio_dwmac_data;
 
 #endif /* __STMMAC_PLATFORM_H__ */
-- 
2.2.0.rc0.207.ga3a616c

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

[PATCH V2 1/2] stmmac: Add binding document for IMG Pistachio DWMAC

2015-04-06 Thread Andrew Bresticker

Add a binding document for the DWMAC ethernet controller found on the
IMG Pistachio SoC.

Signed-off-by: Andrew Bresticker 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: James Hartley 
---
No changes from v1.
---
 .../devicetree/bindings/net/pistachio-dwmac.txt| 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/pistachio-dwmac.txt

diff --git a/Documentation/devicetree/bindings/net/pistachio-dwmac.txt 
b/Documentation/devicetree/bindings/net/pistachio-dwmac.txt
new file mode 100644
index 000..9781469
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/pistachio-dwmac.txt
@@ -0,0 +1,24 @@
+IMG Pistachio Ethernet Controller
+=
+
+This device is a variant of the DWMAC and inherits the properties described
+in ./stmmac.txt.
+
+Required properties:
+
+ - compatible: Must contain "img,pistachio-dwmac" and "snps,dwmac".
+ - clocks: Must contain an entry for each entry in clock-names.
+   See ../clock/clock-bindings.txt for details.
+ - clock-names: Must include "stmmaceth" and "sys".
+
+Example:
+
+ethernet@1814 {
+   compatible = "img,pistachio-dwmac";
+   reg = <0x1814 0x2000>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   clocks = <&clk_core CLK_ENET>, <&cr_periph SYS_CLK_ENET>;
+   clock-names = "stmmaceth", "sys";
+   phy-mode = "rmii";
+};
-- 
2.2.0.rc0.207.ga3a616c

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

Re: [PATCH 2/3] of: OF_IRQ should depend on IRQ_DOMAIN

2015-04-06 Thread Arnd Bergmann

On Monday 06 April 2015 17:26:57 Geert Uytterhoeven wrote:
> Given drivers/base/platform.c:
> 
> int platform_get_irq(struct platform_device *dev, unsigned int num)
> {
> #ifdef CONFIG_SPARC
> ...
> #else
> struct resource *r;
> if (IS_ENABLED(CONFIG_OF_IRQ) && dev->dev.of_node) {
> ...
> }
> ...
> #endif
> }
> 
> yes I do want to keep it explicit.
> 

Ok, makes sense, thanks!

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

Re: [PATCH V3 5/7] serial: earlycon: Set UPIO_MEM32BE based on DT properties

On Mon, Apr 6, 2015 at 12:36 PM, Peter Hurley  wrote:
> On 04/02/2015 11:35 AM, Peter Hurley wrote:
>> On 04/02/2015 09:46 AM, Rob Herring wrote:
>>> Sorry about that. I had thought about doing the same thing. At least
>>> unifying the macros, but not necessarily the tables. If it is also
>>> extendable to other firmware interfaces like ACPI perhaps that would
>>> be good.
>>
>> No need to apologize; I'll make those changes and resubmit for your
>> review.
>
> What about something like the following?
>
> This patch makes both __earlycon_table and __earlycon_of_table
> arrays of struct earlycon_id, and a follow-on patch would use the
> earlycon name to initialize the struct console fields.
>
> The benefits of this approach are
> 1. diagnostics can readily identify the earlycon if there is some error
> 2. it would be trivial to enable both command line and devicetree
>earlycon from the same earlycon declaration.
>
> And a single table is doable from this point.
>
> AFAICT there is no benefit to using actual OF tables, and I see no
> other reasonable way to initialize the name of the struct console
> for devicetree earlycons.

Just to align all the OF linker sections, but having a common table is
better. So the patch looks okay to me.

Rob

>
> Regards,
> Peter Hurley
>
>
> --- >% ---
> Subject: [PATCH] serial: earlycon: Use common framework for earlycon
>  declarations
>
> Use common table definition and implementation macro to declare an
> earlycon, but retain separate tables for command line and devicetree.
> Add __EARLYCON_DECLARE() macro to instance a unique earlycon
> declaration for the specified table.
>
> This enables all earlycons to properly initialize the earlycon console
> structure with name and index.
>
> Signed-off-by: Peter Hurley 
> ---
>  drivers/of/fdt.c  |  6 +++---
>  drivers/tty/serial/earlycon.c |  3 +--
>  include/asm-generic/vmlinux.lds.h |  8 ++--
>  include/linux/serial_core.h   | 30 +-
>  4 files changed, 31 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 7cef9f9..f640efa 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -760,14 +760,14 @@ static inline void 
> early_init_dt_check_for_initrd(unsigned long node)
>  #endif /* CONFIG_BLK_DEV_INITRD */
>
>  #ifdef CONFIG_SERIAL_EARLYCON
> -extern struct of_device_id __earlycon_of_table[];
> +extern struct earlycon_id __earlycon_of_table[];
>
>  static int __init early_init_dt_scan_chosen_serial(void)
>  {
> int offset;
> const char *p, *q;
> int l;
> -   const struct of_device_id *match = __earlycon_of_table;
> +   const struct earlycon_id *match = __earlycon_of_table;
> const void *fdt = initial_boot_params;
>
> offset = fdt_path_offset(fdt, "/chosen");
> @@ -800,7 +800,7 @@ static int __init early_init_dt_scan_chosen_serial(void)
> if (!addr)
> return -ENXIO;
>
> -   of_setup_earlycon(addr, match->data);
> +   of_setup_earlycon(addr, match->setup);
> return 0;
> }
> return -ENODEV;
> diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> index 5fdc9f3..bf7eb76 100644
> --- a/drivers/tty/serial/earlycon.c
> +++ b/drivers/tty/serial/earlycon.c
> @@ -19,7 +19,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>
>  #ifdef CONFIG_FIX_EARLYCON_MEM
>  #include 
> @@ -41,7 +40,7 @@ extern struct earlycon_id __earlycon_table[];
>  static const struct earlycon_id __earlycon_table_sentinel
> __used __section(__earlycon_table_end);
>
> -static const struct of_device_id __earlycon_of_table_sentinel
> +static const struct earlycon_id __earlycon_of_table_sentinel
> __used __section(__earlycon_of_table_end);
>
>  static void __iomem * __init earlycon_map(unsigned long paddr, size_t size)
> diff --git a/include/asm-generic/vmlinux.lds.h 
> b/include/asm-generic/vmlinux.lds.h
> index 561daf4..7322c30 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -155,8 +155,13 @@
>  VMLINUX_SYMBOL(__earlycon_table) = .;  \
>  *(__earlycon_table)\
>  *(__earlycon_table_end)
> +#define EARLYCON_OF_TABLE()STRUCT_ALIGN();  \
> +   VMLINUX_SYMBOL(__earlycon_of_table) = .; \
> +   *(__earlycon_of_table)   \
> +   *(__earlycon_of_table_end)
>  #else
>  #define EARLYCON_TABLE()
> +#define EARLYCON_OF_TABLE()
>  #endif
>
>  #define ___OF_TABLE(cfg, name) _OF_TABLE_##cfg(name)
> @@ -175,7 +180,6 @@
>  #define IOMMU_OF_TABLES()  OF_TABLE(CONFIG_OF_IOMMU, iommu)
>  #define RESERVEDMEM_OF_TABLES()OF_TABLE(CONFIG_OF_RESERVED_MEM, 
> reservedmem)
>  #define CPU_METHOD_OF_TABLES() OF_TABLE(CONFIG_SMP, cpu_me

Re: [PATCH 2/2] stmmac: Add IMG Pistachio platform glue layer

2015-04-06 Thread David Miller

From: Andrew Bresticker 
Date: Thu,  2 Apr 2015 16:46:36 -0700

> +static void *pistachio_dwmac_setup(struct platform_device *pdev)
> +{
> + struct pistachio_dwmac_priv_data *pdata;
> +
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return ERR_PTR(-ENOMEM);
> +
> + pdata->sys_clk = devm_clk_get(&pdev->dev, "sys");
> + if (IS_ERR(pdata->sys_clk)) {
> + dev_err(&pdev->dev, "Failed to get sys clock: %ld\n",
> + PTR_ERR(pdata->sys_clk));
> + return pdata->sys_clk;

Please do not store potential error pointers in dynamically allocated
memory.

Put it in a local variable for the devm_clk_get() call, then if it
succeeds and is not an error pointer, place it into pdata->sys_clk.

You must resubmit this entire patch series when updating any aspect
of it.  I'm pre-emptively telling you this because often people think
they can just post a new version of the fixed patch, but that's not
how things work here :-)

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 03/11] ARM: dts: Use phandle notation for overriding nodes in Exynos4210 Origen

The phandle notation reduces possible mistakes when overriding nodes.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4210-origen.dts | 418 
 1 file changed, 209 insertions(+), 209 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210-origen.dts 
b/arch/arm/boot/dts/exynos4210-origen.dts
index b81146141402..e0abfc3324d1 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -50,209 +50,6 @@
};
};
 
-   watchdog@1006 {
-   status = "okay";
-   };
-
-   rtc@1007 {
-   status = "okay";
-   };
-
-   tmu@100C {
-   status = "okay";
-   };
-
-   sdhci@1253 {
-   bus-width = <4>;
-   pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus4 &sd2_cd>;
-   pinctrl-names = "default";
-   vmmc-supply = <&mmc_reg>;
-   status = "okay";
-   };
-
-   sdhci@1251 {
-   bus-width = <4>;
-   pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_cd>;
-   pinctrl-names = "default";
-   vmmc-supply = <&mmc_reg>;
-   status = "okay";
-   };
-
-   g2d@1280 {
-   status = "okay";
-   };
-
-   codec@1340 {
-   samsung,mfc-r = <0x4300 0x80>;
-   samsung,mfc-l = <0x5100 0x80>;
-   status = "okay";
-   };
-
-   serial@1380 {
-   status = "okay";
-   };
-
-   serial@1381 {
-   status = "okay";
-   };
-
-   serial@1382 {
-   status = "okay";
-   };
-
-   serial@1383 {
-   status = "okay";
-   };
-
-   i2c@1386 {
-   status = "okay";
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-max-bus-freq = <2>;
-   pinctrl-0 = <&i2c0_bus>;
-   pinctrl-names = "default";
-
-   max8997_pmic@66 {
-   compatible = "maxim,max8997-pmic";
-   reg = <0x66>;
-   interrupt-parent = <&gpx0>;
-   interrupts = <4 0>, <3 0>;
-
-   max8997,pmic-buck1-dvs-voltage = <135>;
-   max8997,pmic-buck2-dvs-voltage = <110>;
-   max8997,pmic-buck5-dvs-voltage = <120>;
-
-   regulators {
-   ldo1_reg: LDO1 {
-   regulator-name = "VDD_ABB_3.3V";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   };
-
-   ldo2_reg: LDO2 {
-   regulator-name = "VDD_ALIVE_1.1V";
-   regulator-min-microvolt = <110>;
-   regulator-max-microvolt = <110>;
-   regulator-always-on;
-   };
-
-   ldo3_reg: LDO3 {
-   regulator-name = "VMIPI_1.1V";
-   regulator-min-microvolt = <110>;
-   regulator-max-microvolt = <110>;
-   };
-
-   ldo4_reg: LDO4 {
-   regulator-name = "VDD_RTC_1.8V";
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <180>;
-   regulator-always-on;
-   };
-
-   ldo6_reg: LDO6 {
-   regulator-name = "VMIPI_1.8V";
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <180>;
-   regulator-always-on;
-   };
-
-   ldo7_reg: LDO7 {
-   regulator-name = "VDD_AUD_1.8V";
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <180>;
-   };
-
-   ldo8_reg: LDO8 {
-   regulator-name = "VADC_3.3V";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   };
-
-   ldo9_reg: LDO9 {
-   regulator-name = "DVDD_SWB_2.8V";

[PATCH 01/11] ARM: dts: Add labels to nodes used in Exynos4 based DTS

Add new labels to certain nodes so they could be easily referenced by
Exynos4 board DTS.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4.dtsi| 22 +++---
 arch/arm/boot/dts/exynos4210-pinctrl.dtsi |  6 +++---
 arch/arm/boot/dts/exynos4210.dtsi |  6 +++---
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |  8 
 arch/arm/boot/dts/exynos4x12.dtsi |  2 +-
 5 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e20cdc24c3bb..ef944e4f42d0 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -257,7 +257,7 @@
};
};
 
-   watchdog@1006 {
+   watchdog: watchdog@1006 {
compatible = "samsung,s3c2410-wdt";
reg = <0x1006 0x100>;
interrupts = <0 43 0>;
@@ -266,7 +266,7 @@
status = "disabled";
};
 
-   rtc@1007 {
+   rtc: rtc@1007 {
compatible = "samsung,s3c6410-rtc";
reg = <0x1007 0x100>;
interrupt-parent = <&pmu_system_controller>;
@@ -276,7 +276,7 @@
status = "disabled";
};
 
-   keypad@100A {
+   keypad: keypad@100A {
compatible = "samsung,s5pv210-keypad";
reg = <0x100A 0x100>;
interrupts = <0 109 0>;
@@ -285,7 +285,7 @@
status = "disabled";
};
 
-   sdhci@1251 {
+   sdhci_0: sdhci@1251 {
compatible = "samsung,exynos4210-sdhci";
reg = <0x1251 0x100>;
interrupts = <0 73 0>;
@@ -294,7 +294,7 @@
status = "disabled";
};
 
-   sdhci@1252 {
+   sdhci_1: sdhci@1252 {
compatible = "samsung,exynos4210-sdhci";
reg = <0x1252 0x100>;
interrupts = <0 74 0>;
@@ -303,7 +303,7 @@
status = "disabled";
};
 
-   sdhci@1253 {
+   sdhci_2: sdhci@1253 {
compatible = "samsung,exynos4210-sdhci";
reg = <0x1253 0x100>;
interrupts = <0 75 0>;
@@ -312,7 +312,7 @@
status = "disabled";
};
 
-   sdhci@1254 {
+   sdhci_3: sdhci@1254 {
compatible = "samsung,exynos4210-sdhci";
reg = <0x1254 0x100>;
interrupts = <0 76 0>;
@@ -331,7 +331,7 @@
status = "disabled";
};
 
-   hsotg@1248 {
+   hsotg: hsotg@1248 {
compatible = "samsung,s3c6400-hsotg";
reg = <0x1248 0x2>;
interrupts = <0 71 0>;
@@ -342,7 +342,7 @@
status = "disabled";
};
 
-   ehci@1258 {
+   ehci: ehci@1258 {
compatible = "samsung,exynos4210-ehci";
reg = <0x1258 0x100>;
interrupts = <0 70 0>;
@@ -368,7 +368,7 @@
};
};
 
-   ohci@1259 {
+   ohci: ohci@1259 {
compatible = "samsung,exynos4210-ohci";
reg = <0x1259 0x100>;
interrupts = <0 70 0>;
@@ -621,7 +621,7 @@
status = "disabled";
};
 
-   pwm@139D {
+   pwm: pwm@139D {
compatible = "samsung,exynos4210-pwm";
reg = <0x139D 0x1000>;
interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
index a7c212891674..4704e7bb2628 100644
--- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
@@ -15,7 +15,7 @@
 */
 
 / {
-   pinctrl@1140 {
+   pinctrl_0: pinctrl@1140 {
gpa0: gpa0 {
gpio-controller;
#gpio-cells = <2>;
@@ -421,7 +421,7 @@
};
};
 
-   pinctrl@1100 {
+   pinctrl_1: pinctrl@1100 {
gpj0: gpj0 {
gpio-controller;
#gpio-cells = <2>;
@@ -822,7 +822,7 @@
};
};
 
-   pinctrl@0386 {
+   pinctrl_3: pinctrl@0386 {
gpz: gpz {
gpio-controller;
#gpio-cells = <2>;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index be89f83f70e7..76b84852f29c 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -62,7 +62,7 @@
#clock-cells = <1>;
};
 
-   sysram@0202 {
+   sysram: sysram@0202 {
compatible = "mmio-sram";
reg = <0x0202 0x2>;
#address-cells = <1>;
@@ -107,7 +107,7 @@
 <0

[PATCH 02/11] ARM: dts: Use phandle notation for overriding nodes in Exynos4210

The phandle notation reduces possible mistakes when overriding nodes.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4210.dtsi | 43 +++
 1 file changed, 21 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index 76b84852f29c..a9a55304e31a 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -52,16 +52,6 @@
};
};
 
-   pmu_system_controller: system-controller@1002 {
-   clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
-   "clkout4", "clkout8", "clkout9";
-   clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
-   <&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
-   <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>,
-   <&clock CLK_XUSBXTI>;
-   #clock-cells = <1>;
-   };
-
sysram: sysram@0202 {
compatible = "mmio-sram";
reg = <0x0202 0x2>;
@@ -95,18 +85,6 @@
arm,data-latency = <2 2 1>;
};
 
-   gic: interrupt-controller@1049 {
-   cpu-offset = <0x8000>;
-   };
-
-   combiner: interrupt-controller@1044 {
-   samsung,combiner-nr = <16>;
-   interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
-<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
-<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
-<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>;
-   };
-
mct: mct@1005 {
compatible = "samsung,exynos4210-mct";
reg = <0x1005 0x800>;
@@ -245,3 +223,24 @@
status = "disabled";
};
 };
+
+&gic {
+   cpu-offset = <0x8000>;
+};
+
+&combiner {
+   samsung,combiner-nr = <16>;
+   interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
+<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
+<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
+<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>;
+};
+
+&pmu_system_controller {
+   clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
+   "clkout4", "clkout8", "clkout9";
+   clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
+   <&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
+   <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>, <&clock CLK_XUSBXTI>;
+   #clock-cells = <1>;
+};
-- 
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 04/11] ARM: dts: Use phandle notation for overriding nodes in SMDKv310

The phandle notation reduces possible mistakes when overriding nodes.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4210-smdkv310.dts | 280 +++---
 1 file changed, 140 insertions(+), 140 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts 
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index 86216fff1b4f..043b03caff8f 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -30,181 +30,181 @@
stdout-path = &serial_1;
};
 
-   sdhci@1253 {
-   bus-width = <4>;
-   pinctrl-names = "default";
-   pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
-   status = "okay";
-   };
+   fixed-rate-clocks {
+   xxti {
+   compatible = "samsung,clock-xxti";
+   clock-frequency = <1200>;
+   };
 
-   g2d@1280 {
-   status = "okay";
+   xusbxti {
+   compatible = "samsung,clock-xusbxti";
+   clock-frequency = <2400>;
+   };
};
+};
 
-   codec@1340 {
-   samsung,mfc-r = <0x4300 0x80>;
-   samsung,mfc-l = <0x5100 0x80>;
-   status = "okay";
-   };
+&g2d {
+   status = "okay";
+};
 
-   serial@1380 {
-   status = "okay";
-   };
+&i2c_0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   samsung,i2c-sda-delay = <100>;
+   samsung,i2c-max-bus-freq = <10>;
+   status = "okay";
 
-   serial@1381 {
-   status = "okay";
+   eeprom@50 {
+   compatible = "samsung,24ad0xd1";
+   reg = <0x50>;
};
 
-   serial@1382 {
-   status = "okay";
+   eeprom@52 {
+   compatible = "samsung,24ad0xd1";
+   reg = <0x52>;
};
+};
 
-   serial@1383 {
-   status = "okay";
+&keypad {
+   samsung,keypad-num-rows = <2>;
+   samsung,keypad-num-columns = <8>;
+   linux,keypad-no-autorepeat;
+   linux,keypad-wakeup;
+   pinctrl-names = "default";
+   pinctrl-0 = <&keypad_rows &keypad_cols>;
+   status = "okay";
+
+   key_1 {
+   keypad,row = <0>;
+   keypad,column = <3>;
+   linux,code = <2>;
};
 
-   pinctrl@1100 {
-   keypad_rows: keypad-rows {
-   samsung,pins = "gpx2-0", "gpx2-1";
-   samsung,pin-function = <3>;
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <0>;
-   };
-
-   keypad_cols: keypad-cols {
-   samsung,pins = "gpx1-0", "gpx1-1", "gpx1-2", "gpx1-3",
-  "gpx1-4", "gpx1-5", "gpx1-6", "gpx1-7";
-   samsung,pin-function = <3>;
-   samsung,pin-pud = <0>;
-   samsung,pin-drv = <0>;
-   };
+   key_2 {
+   keypad,row = <0>;
+   keypad,column = <4>;
+   linux,code = <3>;
};
 
-   keypad@100A {
-   samsung,keypad-num-rows = <2>;
-   samsung,keypad-num-columns = <8>;
-   linux,keypad-no-autorepeat;
-   linux,keypad-wakeup;
-   pinctrl-names = "default";
-   pinctrl-0 = <&keypad_rows &keypad_cols>;
-   status = "okay";
+   key_3 {
+   keypad,row = <0>;
+   keypad,column = <5>;
+   linux,code = <4>;
+   };
 
-   key_1 {
-   keypad,row = <0>;
-   keypad,column = <3>;
-   linux,code = <2>;
-   };
+   key_4 {
+   keypad,row = <0>;
+   keypad,column = <6>;
+   linux,code = <5>;
+   };
 
-   key_2 {
-   keypad,row = <0>;
-   keypad,column = <4>;
-   linux,code = <3>;
-   };
+   key_5 {
+   keypad,row = <0>;
+   keypad,column = <7>;
+   linux,code = <6>;
+   };
 
-   key_3 {
-   keypad,row = <0>;
-   keypad,column = <5>;
-   linux,code = <4>;
-   };
+   key_a {
+   keypad,row = <1>;
+   keypad,column = <3>;
+   linux,code = <30>;
+   };
 
-   key_4 {
-   keypad,row = <0>;
-   keypad,column = <6>;
-   linux,code = <5>;
-   };
+   key_b {
+   keypad,row = <1>;
+   keypad,column = <4>;
+   linux,code = <48>;
+   };
 
-   key_5 {
-

[PATCH 05/11] ARM: dts: Use phandle notation for overriding nodes in Trats

The phandle notation reduces possible mistakes when overriding nodes.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4210-trats.dts | 592 -
 1 file changed, 296 insertions(+), 296 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 32c5fd8f6269..98f3ce65cb9a 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -89,42 +89,6 @@
};
};
 
-   hsotg@1248 {
-   vusb_d-supply = <&vusb_reg>;
-   vusb_a-supply = <&vusbdac_reg>;
-   dr_mode = "peripheral";
-   status = "okay";
-   };
-
-   sdhci_emmc: sdhci@1251 {
-   bus-width = <8>;
-   non-removable;
-   pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus8>;
-   pinctrl-names = "default";
-   vmmc-supply = <&vemmc_reg>;
-   status = "okay";
-   };
-
-   exynos-usbphy@125B {
-   status = "okay";
-   };
-
-   serial@1380 {
-   status = "okay";
-   };
-
-   serial@1381 {
-   status = "okay";
-   };
-
-   serial@1382 {
-   status = "okay";
-   };
-
-   serial@1383 {
-   status = "okay";
-   };
-
gpio-keys {
compatible = "gpio-keys";
 
@@ -158,201 +122,6 @@
};
};
 
-   i2c@1389 {
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-slave-addr = <0x10>;
-   samsung,i2c-max-bus-freq = <40>;
-   pinctrl-0 = <&i2c3_bus>;
-   pinctrl-names = "default";
-   status = "okay";
-
-   mms114-touchscreen@48 {
-   compatible = "melfas,mms114";
-   reg = <0x48>;
-   interrupt-parent = <&gpx0>;
-   interrupts = <4 2>;
-   x-size = <720>;
-   y-size = <1280>;
-   avdd-supply = <&tsp_reg>;
-   vdd-supply = <&tsp_reg>;
-   };
-   };
-
-   i2c@138B {
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-slave-addr = <0x10>;
-   samsung,i2c-max-bus-freq = <10>;
-   pinctrl-0 = <&i2c5_bus>;
-   pinctrl-names = "default";
-   status = "okay";
-
-   max8997_pmic@66 {
-   compatible = "maxim,max8997-pmic";
-
-   reg = <0x66>;
-
-   max8997,pmic-buck1-uses-gpio-dvs;
-   max8997,pmic-buck2-uses-gpio-dvs;
-   max8997,pmic-buck5-uses-gpio-dvs;
-
-   max8997,pmic-ignore-gpiodvs-side-effect;
-   max8997,pmic-buck125-default-dvs-idx = <0>;
-
-   max8997,pmic-buck125-dvs-gpios = <&gpx0 5 0>,
-<&gpx0 6 0>,
-<&gpl0 0 0>;
-
-   max8997,pmic-buck1-dvs-voltage = <135>, <130>,
-<125>, <120>,
-<115>, <110>,
-<100>, <95>;
-
-   max8997,pmic-buck2-dvs-voltage = <110>, <100>,
-<95>,  <90>,
-<110>, <100>,
-<95>,  <90>;
-
-   max8997,pmic-buck5-dvs-voltage = <120>, <120>,
-<120>, <120>,
-<120>, <120>,
-<120>, <120>;
-
-   regulators {
-   valive_reg: LDO2 {
-regulator-name = "VALIVE_1.1V_C210";
-regulator-min-microvolt = <110>;
-regulator-max-microvolt = <110>;
-regulator-always-on;
-   };
-
-   vusb_reg: LDO3 {
-regulator-name = "VUSB_1.1V_C210";
-regulator-min-microvolt = <110>;
-regulator-max-microvolt = <110>;
-   };
-
-   vmipi_reg: LDO4 {
-regulator-name = "VMIPI_1.8V";
-

[PATCH 06/11] ARM: dts: Use phandle notation for overriding nodes in Exynos4212

The phandle notation reduces possible mistakes when overriding nodes.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4212.dtsi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4212.dtsi 
b/arch/arm/boot/dts/exynos4212.dtsi
index 5be03288f1ee..d9c8efeef208 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -41,12 +41,12 @@
reg = <0xA01>;
};
};
+};
 
-   combiner: interrupt-controller@1044 {
-   samsung,combiner-nr = <18>;
-   };
+&combiner {
+   samsung,combiner-nr = <18>;
+};
 
-   gic: interrupt-controller@1049 {
-   cpu-offset = <0x8000>;
-   };
+&gic {
+   cpu-offset = <0x8000>;
 };
-- 
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 10/11] ARM: dts: Use phandle notation for overriding nodes in SMDK4412

The phandle notation reduces possible mistakes when overriding nodes.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4412-smdk4412.dts | 210 +++---
 1 file changed, 105 insertions(+), 105 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-smdk4412.dts 
b/arch/arm/boot/dts/exynos4412-smdk4412.dts
index b9256afbcc68..c2421df1fa43 100644
--- a/arch/arm/boot/dts/exynos4412-smdk4412.dts
+++ b/arch/arm/boot/dts/exynos4412-smdk4412.dts
@@ -28,135 +28,135 @@
stdout-path = &serial_1;
};
 
-   g2d@1080 {
-   status = "okay";
-   };
-
-   pinctrl@1100 {
-   keypad_rows: keypad-rows {
-   samsung,pins = "gpx2-0", "gpx2-1", "gpx2-2";
-   samsung,pin-function = <3>;
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <0>;
+   fixed-rate-clocks {
+   xxti {
+   compatible = "samsung,clock-xxti";
+   clock-frequency = <0>;
};
 
-   keypad_cols: keypad-cols {
-   samsung,pins = "gpx1-0", "gpx1-1", "gpx1-2", "gpx1-3",
-  "gpx1-4", "gpx1-5", "gpx1-6", "gpx1-7";
-   samsung,pin-function = <3>;
-   samsung,pin-pud = <0>;
-   samsung,pin-drv = <0>;
+   xusbxti {
+   compatible = "samsung,clock-xusbxti";
+   clock-frequency = <2400>;
};
};
+};
 
-   keypad@100A {
-   samsung,keypad-num-rows = <3>;
-   samsung,keypad-num-columns = <8>;
-   linux,keypad-no-autorepeat;
-   linux,keypad-wakeup;
-   pinctrl-0 = <&keypad_rows &keypad_cols>;
-   pinctrl-names = "default";
-   status = "okay";
-
-   key_1 {
-   keypad,row = <1>;
-   keypad,column = <3>;
-   linux,code = <2>;
-   };
-
-   key_2 {
-   keypad,row = <1>;
-   keypad,column = <4>;
-   linux,code = <3>;
-   };
-
-   key_3 {
-   keypad,row = <1>;
-   keypad,column = <5>;
-   linux,code = <4>;
-   };
-
-   key_4 {
-   keypad,row = <1>;
-   keypad,column = <6>;
-   linux,code = <5>;
-   };
+&g2d {
+   status = "okay";
+};
 
-   key_5 {
-   keypad,row = <1>;
-   keypad,column = <7>;
-   linux,code = <6>;
-   };
+&keypad {
+   samsung,keypad-num-rows = <3>;
+   samsung,keypad-num-columns = <8>;
+   linux,keypad-no-autorepeat;
+   linux,keypad-wakeup;
+   pinctrl-0 = <&keypad_rows &keypad_cols>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   key_1 {
+   keypad,row = <1>;
+   keypad,column = <3>;
+   linux,code = <2>;
+   };
 
-   key_A {
-   keypad,row = <2>;
-   keypad,column = <6>;
-   linux,code = <30>;
-   };
+   key_2 {
+   keypad,row = <1>;
+   keypad,column = <4>;
+   linux,code = <3>;
+   };
 
-   key_B {
-   keypad,row = <2>;
-   keypad,column = <7>;
-   linux,code = <48>;
-   };
+   key_3 {
+   keypad,row = <1>;
+   keypad,column = <5>;
+   linux,code = <4>;
+   };
 
-   key_C {
-   keypad,row = <0>;
-   keypad,column = <5>;
-   linux,code = <46>;
-   };
+   key_4 {
+   keypad,row = <1>;
+   keypad,column = <6>;
+   linux,code = <5>;
+   };
 
-   key_D {
-   keypad,row = <2>;
-   keypad,column = <5>;
-   linux,code = <32>;
-   };
+   key_5 {
+   keypad,row = <1>;
+   keypad,column = <7>;
+   linux,code = <6>;
+   };
 
-   key_E {
-   keypad,row = <0>;
-   keypad,column = <7>;
-   linux,code = <18>;
-   };
+   key_A {
+   keypad,row = <2>;
+   keypad,column = <6>;
+   linux,code = <30>;
};
 
-   sdhci@1253 {
-   bus-width = <4>;
-   pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus4 &sd2_cd>;
-   pinctrl-names = "default";
-   status = "okay";
+

[PATCH 08/11] ARM: dts: Use phandle notation for overriding nodes in Exynos4412

The phandle notation reduces possible mistakes when overriding nodes.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4412.dtsi | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412.dtsi 
b/arch/arm/boot/dts/exynos4412.dtsi
index 68ad43b391ae..b78ada70bd05 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -54,19 +54,19 @@
};
};
 
-   combiner: interrupt-controller@1044 {
-   samsung,combiner-nr = <20>;
-   };
-
pmu {
interrupts = <2 2>, <3 2>, <18 2>, <19 2>;
};
+};
 
-   gic: interrupt-controller@1049 {
-   cpu-offset = <0x4000>;
-   };
+&pmu_system_controller {
+   compatible = "samsung,exynos4412-pmu", "syscon";
+};
 
-   pmu_system_controller: system-controller@1002 {
-   compatible = "samsung,exynos4412-pmu", "syscon";
-   };
+&combiner {
+   samsung,combiner-nr = <20>;
+};
+
+&gic {
+   cpu-offset = <0x4000>;
 };
-- 
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 07/11] ARM: dts: Use phandle notation for overriding nodes in Exynos4x12

The phandle notation reduces possible mistakes when overriding nodes.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4x12.dtsi | 210 +++---
 1 file changed, 105 insertions(+), 105 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index 657b5ca39ce8..04812b842290 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -96,32 +96,6 @@
};
};
 
-   combiner: interrupt-controller@1044 {
-   interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
-<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
-<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
-<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
-<0 107 0>, <0 108 0>, <0 48 0>, <0 42 0>;
-   };
-
-   pinctrl_0: pinctrl@1140 {
-   compatible = "samsung,exynos4x12-pinctrl";
-   reg = <0x1140 0x1000>;
-   interrupts = <0 47 0>;
-   };
-
-   pinctrl_1: pinctrl@1100 {
-   compatible = "samsung,exynos4x12-pinctrl";
-   reg = <0x1100 0x1000>;
-   interrupts = <0 46 0>;
-
-   wakup_eint: wakeup-interrupt-controller {
-   compatible = "samsung,exynos4210-wakeup-eint";
-   interrupt-parent = <&gic>;
-   interrupts = <0 32 0>;
-   };
-   };
-
adc: adc@126C {
compatible = "samsung,exynos-adc-v1";
reg = <0x126C 0x100>;
@@ -135,30 +109,6 @@
status = "disabled";
};
 
-   pinctrl_2: pinctrl@0386 {
-   compatible = "samsung,exynos4x12-pinctrl";
-   reg = <0x0386 0x1000>;
-   interrupt-parent = <&combiner>;
-   interrupts = <10 0>;
-   };
-
-   pinctrl_3: pinctrl@106E {
-   compatible = "samsung,exynos4x12-pinctrl";
-   reg = <0x106E 0x1000>;
-   interrupts = <0 72 0>;
-   };
-
-   pmu_system_controller: system-controller@1002 {
-   compatible = "samsung,exynos4212-pmu", "syscon";
-   clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
-   "clkout4", "clkout8", "clkout9";
-   clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
-   <&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
-   <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>,
-   <&clock CLK_XUSBXTI>;
-   #clock-cells = <1>;
-   };
-
g2d: g2d@1080 {
compatible = "samsung,exynos4212-g2d";
reg = <0x1080 0x1000>;
@@ -173,40 +123,7 @@
 <&clock CLK_PIXELASYNCM0>, <&clock CLK_PIXELASYNCM1>;
clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0", 
"pxl_async1";
 
-   fimc_0: fimc@1180 {
-   compatible = "samsung,exynos4212-fimc";
-   samsung,pix-limits = <4224 8192 1920 4224>;
-   samsung,mainscaler-ext;
-   samsung,isp-wb;
-   samsung,cam-if;
-   };
-
-   fimc_1: fimc@1181 {
-   compatible = "samsung,exynos4212-fimc";
-   samsung,pix-limits = <4224 8192 1920 4224>;
-   samsung,mainscaler-ext;
-   samsung,isp-wb;
-   samsung,cam-if;
-   };
-
-   fimc_2: fimc@1182 {
-   compatible = "samsung,exynos4212-fimc";
-   samsung,pix-limits = <4224 8192 1920 4224>;
-   samsung,mainscaler-ext;
-   samsung,isp-wb;
-   samsung,lcd-wb;
-   samsung,cam-if;
-   };
-
-   fimc_3: fimc@1183 {
-   compatible = "samsung,exynos4212-fimc";
-   samsung,pix-limits = <1920 8192 1366 1920>;
-   samsung,rotators = <0>;
-   samsung,mainscaler-ext;
-   samsung,isp-wb;
-   samsung,lcd-wb;
-   };
-
+   /* fimc_[0-3] are configured outside, under phandles */
fimc_lite_0: fimc-lite@1239 {
compatible = "samsung,exynos4212-fimc-lite";
reg = <0x1239 0x1000>;
@@ -283,30 +200,113 @@
clock-names = "biu", "ciu";
status = "disabled";
};
+};
 
-   exynos-usbphy@125B {
-   compatible = "samsung,exynos4x12-usb2-phy";
-   samsung,sysreg-phandle = <&sys_reg>;
-   };
+&combiner {
+   interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0

[PATCH 09/11] ARM: dts: Use phandle notation for overriding nodes in Odroid

The phandle notation reduces possible mistakes when overriding nodes.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 728 
 arch/arm/boot/dts/exynos4412-odroidx.dts|  16 +-
 2 files changed, 372 insertions(+), 372 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 8de12af7c276..6801ee6c4449 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -37,16 +37,6 @@
};
};
 
-   i2s0: i2s@0383 {
-   pinctrl-0 = <&i2s0_bus>;
-   pinctrl-names = "default";
-   status = "okay";
-   clocks = <&clock_audss EXYNOS_I2S_BUS>,
-<&clock_audss EXYNOS_DOUT_AUD_BUS>,
-<&clock_audss EXYNOS_SCLK_I2S>;
-   clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
-   };
-
sound: sound {
compatible = "simple-audio-card";
assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
@@ -82,425 +72,435 @@
reset-gpios = <&gpk1 2 1>;
};
 
-   mmc@1255 {
-   pinctrl-0 = <&sd4_clk &sd4_cmd &sd4_bus4 &sd4_bus8>;
-   pinctrl-names = "default";
-   vmmc-supply = <&ldo20_reg &buck8_reg>;
-   mmc-pwrseq = <&emmc_pwrseq>;
-   status = "okay";
-
-   num-slots = <1>;
-   broken-cd;
-   card-detect-delay = <200>;
-   samsung,dw-mshc-ciu-div = <3>;
-   samsung,dw-mshc-sdr-timing = <2 3>;
-   samsung,dw-mshc-ddr-timing = <1 2>;
-   bus-width = <8>;
-   cap-mmc-highspeed;
-   };
-
-   watchdog@1006 {
-   status = "okay";
-   };
-
-   rtc@1007 {
-   status = "okay";
-   };
-
-   g2d@1080 {
-   status = "okay";
-   };
-
camera {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <>;
+   };
 
-   fimc_0: fimc@1180 {
-   status = "okay";
-   assigned-clocks = <&clock CLK_MOUT_FIMC0>,
-   <&clock CLK_SCLK_FIMC0>;
-   assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>;
-   assigned-clock-rates = <0>, <17600>;
-   };
-
-   fimc_1: fimc@1181 {
-   status = "okay";
-   assigned-clocks = <&clock CLK_MOUT_FIMC1>,
-   <&clock CLK_SCLK_FIMC1>;
-   assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>;
-   assigned-clock-rates = <0>, <17600>;
+   fixed-rate-clocks {
+   xxti {
+   compatible = "samsung,clock-xxti";
+   clock-frequency = <0>;
};
 
-   fimc_2: fimc@1182 {
-   status = "okay";
-   assigned-clocks = <&clock CLK_MOUT_FIMC2>,
-   <&clock CLK_SCLK_FIMC2>;
-   assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>;
-   assigned-clock-rates = <0>, <17600>;
+   xusbxti {
+   compatible = "samsung,clock-xusbxti";
+   clock-frequency = <2400>;
};
+   };
 
-   fimc_3: fimc@1183 {
-   status = "okay";
-   assigned-clocks = <&clock CLK_MOUT_FIMC3>,
-   <&clock CLK_SCLK_FIMC3>;
-   assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>;
-   assigned-clock-rates = <0>, <17600>;
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   cooling-maps {
+   map0 {
+/* Corresponds to 800MHz at freq_table */
+cooling-device = <&cpu0 7 7>;
+   };
+   map1 {
+/* Corresponds to 200MHz at freq_table */
+cooling-device = <&cpu0 13 13>;
+  };
+  };
};
};
+};
 
-   sdhci@1253 {
-   bus-width = <4>;
-   pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
-   pinctrl-names = "default";
-   vmmc-supply = <&ldo4_reg &ldo21_reg>;
-   cd-gpios = <&gpk2 2 0>;
-   cd-inverted;
-   status = "okay";
-   };
+/* RSTN signal for eMMC */
+&sd1_cd {
+   samsung,pin-pud

[PATCH 11/11] ARM: dts: Use phandle notation for overriding nodes in Trats2

The phandle notation reduces possible mistakes when overriding nodes.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 1331 ---
 1 file changed, 666 insertions(+), 665 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 173ffa479ad3..e83929c2dc90 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -130,411 +130,6 @@
};
};
 
-   adc: adc@126C {
-   vdd-supply = <&ldo3_reg>;
-   status = "okay";
-   };
-
-   i2c@1389 {
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-slave-addr = <0x10>;
-   samsung,i2c-max-bus-freq = <40>;
-   pinctrl-0 = <&i2c3_bus>;
-   pinctrl-names = "default";
-   status = "okay";
-
-   mms114-touchscreen@48 {
-   compatible = "melfas,mms114";
-   reg = <0x48>;
-   interrupt-parent = <&gpm2>;
-   interrupts = <3 2>;
-   x-size = <720>;
-   y-size = <1280>;
-   avdd-supply = <&ldo23_reg>;
-   vdd-supply = <&ldo24_reg>;
-   };
-   };
-
-   i2c_0: i2c@1386 {
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-slave-addr = <0x10>;
-   samsung,i2c-max-bus-freq = <40>;
-   pinctrl-0 = <&i2c0_bus>;
-   pinctrl-names = "default";
-   status = "okay";
-
-   s5c73m3@3c {
-   compatible = "samsung,s5c73m3";
-   reg = <0x3c>;
-   standby-gpios = <&gpm0 1 1>;   /* ISP_STANDBY */
-   xshutdown-gpios = <&gpf1 3 1>; /* ISP_RESET */
-   vdd-int-supply = <&buck9_reg>;
-   vddio-cis-supply = <&ldo9_reg>;
-   vdda-supply = <&ldo17_reg>;
-   vddio-host-supply = <&ldo18_reg>;
-   vdd-af-supply = <&cam_af_reg>;
-   vdd-reg-supply = <&cam_io_reg>;
-   clock-frequency = <2400>;
-   /* CAM_A_CLKOUT */
-   clocks = <&camera 0>;
-   clock-names = "cis_extclk";
-   port {
-   s5c73m3_ep: endpoint {
-   remote-endpoint = <&csis0_ep>;
-   data-lanes = <1 2 3 4>;
-   };
-   };
-   };
-   };
-
-   i2c@138A {
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-slave-addr = <0x10>;
-   samsung,i2c-max-bus-freq = <10>;
-   pinctrl-0 = <&i2c4_bus>;
-   pinctrl-names = "default";
-   status = "okay";
-
-   wm1811: wm1811@1a {
-   compatible = "wlf,wm1811";
-   reg = <0x1a>;
-   clocks = <&pmu_system_controller 0>;
-   clock-names = "MCLK1";
-   DCVDD-supply = <&ldo3_reg>;
-   DBVDD1-supply = <&ldo3_reg>;
-   wlf,ldo1ena = <&gpj0 4 0>;
-   };
-   };
-
-   i2c@138D {
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-slave-addr = <0x10>;
-   samsung,i2c-max-bus-freq = <10>;
-   pinctrl-0 = <&i2c7_bus>;
-   pinctrl-names = "default";
-   status = "okay";
-
-   max77686_pmic@09 {
-   compatible = "maxim,max77686";
-   interrupt-parent = <&gpx0>;
-   interrupts = <7 0>;
-   reg = <0x09>;
-   #clock-cells = <1>;
-
-   voltage-regulators {
-   ldo1_reg: ldo1 {
-   regulator-compatible = "LDO1";
-   regulator-name = "VALIVE_1.0V_AP";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
-   regulator-always-on;
-   };
-
-   ldo2_reg: ldo2 {
-   regulator-compatible = "LDO2";
-   regulator-name = "VM1M2_1.2V_AP";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
-   regulator-always-on;
-

[PATCH 00/11] ARM: dts: Refactor Exynos4 boards for phandle notation

Hi,


The phandle notation reduces possible mistakes when overriding nodes
by child board files and reduces duplication of addresses.

The patchset refactors Exynos4 boards to use the phandle way.

Tested by comparison of decompiled DTB for each commit.

The same refactoring for Exynos5 is on the way.


Best regards,
Krzysztof

Krzysztof Kozlowski (11):
  ARM: dts: Add labels to nodes used in Exynos4 based DTS
  ARM: dts: Use phandle notation for overriding nodes in Exynos4210
  ARM: dts: Use phandle notation for overriding nodes in Exynos4210
Origen
  ARM: dts: Use phandle notation for overriding nodes in SMDKv310
  ARM: dts: Use phandle notation for overriding nodes in Trats
  ARM: dts: Use phandle notation for overriding nodes in Exynos4212
  ARM: dts: Use phandle notation for overriding nodes in Exynos4x12
  ARM: dts: Use phandle notation for overriding nodes in Exynos4412
  ARM: dts: Use phandle notation for overriding nodes in Odroid
  ARM: dts: Use phandle notation for overriding nodes in SMDK4412
  ARM: dts: Use phandle notation for overriding nodes in Trats2

 arch/arm/boot/dts/exynos4.dtsi  |   22 +-
 arch/arm/boot/dts/exynos4210-origen.dts |  418 +++
 arch/arm/boot/dts/exynos4210-pinctrl.dtsi   |6 +-
 arch/arm/boot/dts/exynos4210-smdkv310.dts   |  280 ++---
 arch/arm/boot/dts/exynos4210-trats.dts  |  592 +-
 arch/arm/boot/dts/exynos4210.dtsi   |   49 +-
 arch/arm/boot/dts/exynos4212.dtsi   |   12 +-
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi |  728 ++---
 arch/arm/boot/dts/exynos4412-odroidx.dts|   16 +-
 arch/arm/boot/dts/exynos4412-smdk4412.dts   |  210 ++--
 arch/arm/boot/dts/exynos4412-trats2.dts | 1331 ---
 arch/arm/boot/dts/exynos4412.dtsi   |   20 +-
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi   |8 +-
 arch/arm/boot/dts/exynos4x12.dtsi   |  212 ++--
 14 files changed, 1952 insertions(+), 1952 deletions(-)

-- 
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 3/4] spi: bcm-mspi: Make BCMA optional to support non-BCMA chips

On 15-04-06 03:36 AM, Rafał Miłecki wrote:
> On 3 April 2015 at 19:52, Florian Fainelli  wrote:
>> On 03/04/15 06:38, Andy Shevchenko wrote:
>>> On Thu, Apr 2, 2015 at 10:23 PM, Jonathan Richardson
>>>  wrote:
 The Broadcom MSPI controller is used on various chips. The driver only
 supported BCM53xx chips with BCMA (an AMBA bus variant). The driver is
 refactored to make BCMA optional and provides a new config for non BCMA
 systems.
>>>
  struct bcm_mspi {
 +   #ifdef CONFIG_SPI_BCMA_MSPI
 struct bcma_device *core;
 -   struct spi_master *master;
 +   #endif

 +   void __iomem *base;
 +   struct spi_master *master;
 size_t read_offset;
>>>
 +   void (*mspi_write)(struct bcm_mspi *mspi, u16 offset, u32 value);
 +   u32 (*mspi_read)(struct bcm_mspi *mspi, u16 offset);
 +};
>>>
>>> To avoid ugly ifdefs I think better to split driver to core part and
>>> the actual driver part, at the end you will have something like
>>> mspi-core.c mspi-53xx.c mspi-whatever.c. Check for example spi-dw*.c
>>
>> Actually, I am really curious whether we need the special BCMA I/O
>> accessors in the first place, cannot we just access the MSPI core on
>> BCM53xx chips using regular MMIO? That would probably solve the
>> "problem" entirely. Rafal, did you try this before?
> 
> It's a matter of choice between:
> 1) Using one design for all bcma users
> 2) Using one design for all bcm-mspi users
> I believe no matter which one you choose, you'll break another one.
> 
> If you take a look at drivers/bcma/host_soc.c, you'll see we've there
> core->io_addr. I guess you could use it as the base in bcm-mspi. That
> of course will make you a bit less compatible with other bcma drivers
> (skipping bcma R/W layer).

That would require compiling in BCMA for a driver/chip that doesn't use
BCMA but then I could do DT parsing in init only anyway. I don't think
that's really an option so I'm going to leave as is unless there is
further opinion on it.

> 
> 
>> As for splitting the driver into a "library" driver which is mostly
>> independent from the bus and a bus-specific wrapper, I think BCMA is
>> really the only special case here, which is why I suggested earlier to
>> Jonathan that we might just prefer ifdefing things out instead of
>> creating a separate layer just for BCMA.
> 
> I think you may be right, this #if for bcma shouldn't be that bad and
> it shouldn't grow in the future.
> Still, I'd like to get this patch split nicely to review independent changes.
> 

Making BCMA optional was made possible by using DT. I'm not sure I could
split it into two commits. I would have to add a hard coded SPI device
for non-BMCA as well. I thought the driver was a bit odd in that this
was hard coded. Normally this should be in a separate driver. How would
you use it if you wanted to use m25p80 for example?


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

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

2015-04-06 Thread Ohad Ben-Cohen

On Mon, Apr 6, 2015 at 7:48 PM, Bjorn Andersson  wrote:
> Based on the long discussion we had on one of the previous iterations
> of Suman's DT binding, with the DT maintainers I believe that it would
> be fine to move along and sent Suman's patches to Linus - without an
> explicit Ack from the DT guys (or did I just miss one?).

Thanks Bjorn.

Mark, are you OK with the latest iteration from Suman? it would be
nice to get your +1 just to make sure we don't merge stuff you're
uncomfortable with.

Thanks!
Ohad.
--
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/4] spi: bcm53xx: Refactor to make driver nonspecific to 53xx SoCs

On 15-04-06 03:18 AM, Rafał Miłecki wrote:
> On 3 April 2015 at 15:35, Andy Shevchenko  wrote:
>> On Thu, Apr 2, 2015 at 10:23 PM, Jonathan Richardson
>>  wrote:
>>> The Broadcom MSPI controller is used on various SoCs. It is being
>>> renamed so that it can be extended and reused on other chips. It is
>>> renamed to bcm-mspi.
>>>
>> What if you resend this one with -M -C applied?
> 
> Definitely, right now I can't really review this patch (and I want to).
> 

Thanks Rafal for the review. Please see previous reply to Andy and let
me know if I'm missing something.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] spi: bcm-mspi: Add support to set serial baud clock rate

On 15-04-06 02:46 AM, Mark Brown wrote:
> On Sat, Apr 04, 2015 at 12:12:59PM -0700, Florian Fainelli wrote:
>> Le 02/04/2015 12:23, Jonathan Richardson a écrit :
> 
>>> +   /* Calculate SPBR if clock-frequency provided. */
>>> +   if (of_property_read_u32(dev->of_node, "clock-frequency",
>>> +   &desired_rate) >= 0) {
>>> +   u32 spbr = clk_get_rate(data->clk) / (2 * desired_rate);
> 
>> Usually, specifying a "clock-frequency" property is done when there is
>> no clock provider available, yet we take this code path only if we could
>> find a "mspi_clk" which sounds a litle weird.
> 
>> Once there is a proper "mspi_clk" clock, I would make it mandatory for
>> the clock provider to be able to provide the rate as well?
> 
> As far as I can tell it's already mandatory if the property is present -
> it's taking the clock presented to the block and then using an internal
> divider to bring that down to the desired rate.
> 
> We are missing error handling though.
> 

Thanks for the review. Yes that's correct. I also tried to make it
backwards compatible with the current version of the driver where you
can ignore configuring the frequency. The result being ref clock
frequency / 2 * 255. If you provide the clock then it will
enable/prepare it. If you also provide clock-frequency then it will
configure the SPBR. If you don't provide anything then it works as
before - it assumes the clock is already enabled and uses the h/w
default SPBR.

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

Re: [PATCH 1/4] ARM: dts: Add binding for Broadcom MSPI driver.

On 15-04-04 12:17 PM, Florian Fainelli wrote:
> Le 02/04/2015 12:23, Jonathan Richardson a écrit :
>>
>> Signed-off-by: Jonathan Richardson 
>> ---
>>  .../devicetree/bindings/spi/brcm,mspi-spi.txt  |   38 
>> 
>>  1 file changed, 38 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt 
>> b/Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt
>> new file mode 100644
>> index 000..16164e3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt
>> @@ -0,0 +1,38 @@
>> +Broadcom MSPI controller
>> +
>> +Required properties:
>> +- compatible: Must be either "brcm,mspi" or "brcm,bcma-mspi". Use
>> +  "brcm,bcma-mspi" for controllers on a bcma bus and "brcm,mspi" otherwise.
> 
> We need a more specific compatible property here since there are at
> least 3 known SoCs families within Broadcom (Cygnus, BCM53xx, BCM7xxx)
> that use this controller, also older versions of the core did not have a
> revision register, yet they had an internal version numbering that we
> might want to reflect here. This does not need to be fixed immediately
> though, we can add compatible strings as we start adding support for
> older cores.
> 
>> +
>> +- reg:  Physical base address and length of the controller's registers.
>> +
>> +- interrupts: The interrupt id for the controller.
> 
> I think this should be two cells, on BCM7xxx chips there is a MSPI_DONE
> and a MSPI_ERROR interrupt bit, we typically only use the first one, but
> since we are describing the hardware here, we need to be exhaustive.

My mistake. Interrupts are not supported by this driver yet. I intend on
adding this later. I will remove this from the docs.

> 
>> +
>> +- #address-cells: should be 1.
>> +
>> +- #size-cells: should be 0.
>> +
>> +Optional properties:
>> +- clocks: The MSPI reference clock. If not provided then it is assumed a 
>> clock
>> +  is enabled by default and no control of clock-frequency (see below) is
>> +  possible.
>> +
>> +- clock-names: The name of the reference clock.
>> +
>> +- clock-frequency: Desired frequency of the clock. This will set the serial
>> +  clock baud rate (SPBR) based on the reference clock frequency. The 
>> frequency
>> +  of the SPBR is mspi_clk / (2 * SPBR) where SPBR is a value between 1-255
>> +  determined by the desired 'clock-frequency'. If not provided then the 
>> default
>> +  baud rate of the controller is used.
> 
> See my reply to the patch 4, that does not seem to match the
> "clock-frequency" vs. clock phandles practices in DT.

I could use a different property for it. I agree it's a bit weird since
we're not changing the frequency of the reference clock but the clock
derived from it for the baud rate of the controller. Does this warrant
adding a different property though?

> 
>> +
>> +Example:
>> +
>> +mspi@18047000 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +compatible = "brcm,mspi";
>> +reg = <0x18047000 0x1000>;
>> +clocks = <&axi41_clk>;
>> +clock-names = "mspi_clk";
>> +clock-frequency = <1250>;
> 
> Since "interrupts" is a mandatory property you might want the example to
> show it 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 3/4] spi: bcm-mspi: Make BCMA optional to support non-BCMA chips

On 15-04-03 10:52 AM, Florian Fainelli wrote:
> On 03/04/15 06:38, Andy Shevchenko wrote:
>> On Thu, Apr 2, 2015 at 10:23 PM, Jonathan Richardson
>>  wrote:
>>> The Broadcom MSPI controller is used on various chips. The driver only
>>> supported BCM53xx chips with BCMA (an AMBA bus variant). The driver is
>>> refactored to make BCMA optional and provides a new config for non BCMA
>>> systems.
>>
>>>  struct bcm_mspi {
>>> +   #ifdef CONFIG_SPI_BCMA_MSPI
>>> struct bcma_device *core;
>>> -   struct spi_master *master;
>>> +   #endif
>>>
>>> +   void __iomem *base;
>>> +   struct spi_master *master;
>>> size_t read_offset;
>>
>>> +   void (*mspi_write)(struct bcm_mspi *mspi, u16 offset, u32 value);
>>> +   u32 (*mspi_read)(struct bcm_mspi *mspi, u16 offset);
>>> +};
>>
>> To avoid ugly ifdefs I think better to split driver to core part and
>> the actual driver part, at the end you will have something like
>> mspi-core.c mspi-53xx.c mspi-whatever.c. Check for example spi-dw*.c
>>
> 
> Actually, I am really curious whether we need the special BCMA I/O
> accessors in the first place, cannot we just access the MSPI core on
> BCM53xx chips using regular MMIO? That would probably solve the
> "problem" entirely. Rafal, did you try this before?
> 
> As for splitting the driver into a "library" driver which is mostly
> independent from the bus and a bus-specific wrapper, I think BCMA is
> really the only special case here, which is why I suggested earlier to
> Jonathan that we might just prefer ifdefing things out instead of
> creating a separate layer just for BCMA.
> 

I cringed adding the ifdefs to the driver but didn't think the small
amount of code that wouldn't be used again warranted 3 files. I could
also handle the two different probe routines by doing some DT parsing in
init, but then BCMA would have to be compiled for the non-BCMA MSPI
driver and I didn't want to do that either.



--
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/4] spi: bcm53xx: Refactor to make driver nonspecific to 53xx SoCs

On 15-04-03 06:35 AM, Andy Shevchenko wrote:
> On Thu, Apr 2, 2015 at 10:23 PM, Jonathan Richardson
>  wrote:
>> The Broadcom MSPI controller is used on various SoCs. It is being
>> renamed so that it can be extended and reused on other chips. It is
>> renamed to bcm-mspi.
>>
> What if you resend this one with -M -C applied?
> 
> 

I'm not seeing any difference in the patches unfortunately. I'll keep
playing with it and re-send if I can find a way to improve it.

The changes are just renaming variables, structures, functions, file
name to get rid of 53xx and replace with mspi. The config is renamed
from SPI_BCM53XX to SPI_BCMA_MSPI.

--
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 3/6] i2c: qup: Add bam dma capabilities

QUP cores can be attached to a BAM module, which acts as
a dma engine for the QUP core. When DMA with BAM is enabled,
the BAM consumer pipe transmitted data is written to the output FIFO
and the BAM producer pipe received data is read from the input FIFO.

With BAM capabilities, qup-i2c core can transfer more than 256 bytes,
without a 'stop' which is not possible otherwise.

Signed-off-by: Sricharan R 
---
 [v2] Addressed comments from Ivan T. Ivanov 

 drivers/i2c/busses/i2c-qup.c | 371 ++-
 1 file changed, 366 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 8605557..2fd141d 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -25,6 +25,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 /* QUP Registers */
 #define QUP_CONFIG 0x000
@@ -34,6 +39,7 @@
 #define QUP_OPERATIONAL0x018
 #define QUP_ERROR_FLAGS0x01c
 #define QUP_ERROR_FLAGS_EN 0x020
+#define QUP_OPERATIONAL_MASK   0x028
 #define QUP_HW_VERSION 0x030
 #define QUP_MX_OUTPUT_CNT  0x100
 #define QUP_OUT_FIFO_BASE  0x110
@@ -53,6 +59,7 @@
 
 #define QUP_STATE_VALIDBIT(2)
 #define QUP_I2C_MAST_GEN   BIT(4)
+#define QUP_I2C_FLUSH  BIT(6)
 
 #define QUP_OPERATIONAL_RESET  0x000ff0
 #define QUP_I2C_STATUS_RESET   0xfc
@@ -78,7 +85,10 @@
 
 /* Packing/Unpacking words in FIFOs, and IO modes */
 #define QUP_OUTPUT_BLK_MODE(1 << 10)
+#define QUP_OUTPUT_BAM_MODE(3 << 10)
 #define QUP_INPUT_BLK_MODE (1 << 12)
+#define QUP_INPUT_BAM_MODE (3 << 12)
+#define QUP_BAM_MODE   (QUP_OUTPUT_BAM_MODE | QUP_INPUT_BAM_MODE)
 #define QUP_UNPACK_EN  BIT(14)
 #define QUP_PACK_ENBIT(15)
 
@@ -105,6 +115,10 @@
 #define QUP_TAG_V2_DATARD  0x85
 #define QUP_TAG_V2_DATARD_STOP 0x87
 
+/* QUP BAM v2 tags */
+#define QUP_BAM_INPUT_EOT  0x93
+#define QUP_BAM_FLUSH_STOP 0x96
+
 /* frequency definitions for high speed and max speed */
 #define I2C_QUP_CLK_FAST_FREQ  100
 
@@ -115,6 +129,11 @@
 #define QUP_STATUS_ERROR_FLAGS 0x7c
 
 #define QUP_READ_LIMIT 256
+#define MX_TX_RX_LEN   SZ_64K
+#define MX_BLOCKS  (MX_TX_RX_LEN / QUP_READ_LIMIT)
+
+/* Max timeout in ms for 32k bytes */
+#define TOUT_MAX   300
 
 struct qup_i2c_block {
int blocks;
@@ -123,6 +142,23 @@ struct qup_i2c_block {
int block_pos;
 };
 
+struct qup_i2c_tag {
+   u8 *start;
+   dma_addr_t addr;
+};
+
+struct qup_i2c_bam_rx {
+   struct  qup_i2c_tag scratch_tag;
+   struct  dma_chan *dma_rx;
+   struct  scatterlist *sg_rx;
+};
+
+struct qup_i2c_bam_tx {
+   struct  qup_i2c_tag footer_tag;
+   struct  dma_chan *dma_tx;
+   struct scatterlist *sg_tx;
+};
+
 struct qup_i2c_dev {
struct device   *dev;
void __iomem*base;
@@ -155,6 +191,12 @@ struct qup_i2c_dev {
/* QUP core errors */
u32 qup_err;
 
+   /* dma parameters */
+   boolis_dma;
+   struct  dma_pool *dpool;
+   struct  qup_i2c_tag start_tag;
+   struct  qup_i2c_bam_rx brx;
+   struct  qup_i2c_bam_tx btx;
struct completion   xfer;
 };
 
@@ -231,6 +273,14 @@ static int qup_i2c_poll_state(struct qup_i2c_dev *qup, u32 
req_state)
return qup_i2c_poll_state_mask(qup, req_state, QUP_STATE_MASK);
 }
 
+static void qup_i2c_flush(struct qup_i2c_dev *qup)
+{
+   u32 val = readl(qup->base + QUP_STATE);
+
+   val |= QUP_I2C_FLUSH;
+   writel(val, qup->base + QUP_STATE);
+}
+
 static int qup_i2c_poll_state_valid(struct qup_i2c_dev *qup)
 {
return qup_i2c_poll_state_mask(qup, 0, 0);
@@ -715,12 +765,242 @@ err:
return ret;
 }
 
+static void qup_i2c_bam_cb(void *data)
+{
+   struct qup_i2c_dev *qup = data;
+
+   complete(&qup->xfer);
+}
+
+static int get_tag_code(struct i2c_msg *msg, int last)
+{
+   u8 op;
+
+   /* always issue stop for each read block */
+   if (last) {
+   if (msg->flags & I2C_M_RD)
+   op = QUP_TAG_V2_DATARD_STOP;
+   else
+   op = QUP_TAG_V2_DATAWR_STOP;
+   } else {
+   if (msg->flags & I2C_M_RD)
+   op = QUP_TAG_V2_DATARD;
+   else
+   op = QUP_TAG_V2_DATAWR;
+   }
+
+   return op;
+}
+
+static int get_start_tag(u8 *tag, struct i2c_msg *msg, int first, int last,
+int blen)
+{
+   u16 addr = (msg->addr << 1) | ((msg->flags & I2C_M_RD) == I2C_M_RD);
+   u8 op;
+   int len = 0;
+
+   op = get_tag_code(msg, last);
+
+   if (first) {
+

[PATCH V2 6/6] dts: msm8974: Add dma channels for blsp2_i2c1 node

Signed-off-by: Sricharan R 
---
 [v2] Changed dma channel names as per comments.

 arch/arm/boot/dts/qcom-msm8974.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index c2e8711..5cb0772 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -246,6 +246,8 @@
clock-names = "core", "iface";
#address-cells = <1>;
#size-cells = <0>;
+   dmas = <&blsp2_dma 20>, <&blsp2_dma 21>;
+   dma-names = "tx", "rx";
};
 
spmi_bus: spmi@fc4cf000 {
-- 
1.8.2.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 V2 4/6] i2c: qup: Transfer every i2c_msg in i2c_msgs without stop

The definition of i2c_msg says that

"If this is the last message in a group, it is followed by a STOP.
  Otherwise it is followed by the next @i2c_msg transaction segment,
  beginning with a (repeated) START"

So the expectation is that there is no 'STOP' bit inbetween individual
i2c_msg segments with repeated 'START'. The QUP i2c hardware has no way
to inform that there should not be a 'STOP' at the end of transaction.
The only way to implement this is to coalesce all the i2c_msg in i2c_msgs
in to one transaction and transfer them. Adding the support for the same.

This is required for some clients like touchscreen which keeps
incrementing counts across individual transfers and 'STOP' bit inbetween
resets the counter, which is not required.

Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 199 ++-
 1 file changed, 121 insertions(+), 78 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 2fd141d..85c326f 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -830,76 +830,94 @@ void qup_sg_set_buf(struct scatterlist *sg, void *buf, 
struct qup_i2c_tag *tg,
sg_dma_address(sg) = tg->addr + ((u8 *)buf - tg->start);
 }
 
-static int bam_do_xfer(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+static int bam_do_xfer(struct qup_i2c_dev *qup, struct i2c_msg *msg, int num)
 {
struct dma_async_tx_descriptor *txd, *rxd = NULL;
int ret = 0;
dma_cookie_t cookie_rx, cookie_tx;
-   u32 rx_nents = 0, tx_nents = 0, len = 0;
-   /* QUP I2C read/write limit for single command is 256bytes max*/
-   int blocks = (msg->len + QUP_READ_LIMIT) / QUP_READ_LIMIT;
-   int rem = msg->len % QUP_READ_LIMIT;
-   int tlen, i = 0, tx_len = 0;
-
-   if (msg->flags & I2C_M_RD) {
-   tx_nents = 1;
-   rx_nents = (blocks << 1) + 1;
-   sg_init_table(qup->brx.sg_rx, rx_nents);
-
-   while (i < blocks) {
-   /* transfer length set to '0' implies 256 bytes */
-   tlen = (i == (blocks - 1)) ? rem : 0;
-   len += get_start_tag(&qup->start_tag.start[len],
- msg, !i, (i == (blocks - 1)),
- tlen);
-
-   qup_sg_set_buf(&qup->brx.sg_rx[i << 1],
-  &qup->brx.scratch_tag.start[0],
-  &qup->brx.scratch_tag,
-  2, qup, 0, 0);
-
-   qup_sg_set_buf(&qup->brx.sg_rx[(i << 1) + 1],
-  &msg->buf[QUP_READ_LIMIT * i],
-  NULL, tlen, qup, 1,
-  DMA_FROM_DEVICE);
-
-   i++;
-   }
-
-   sg_init_one(qup->btx.sg_tx, &qup->start_tag.start[0], len);
-   qup_sg_set_buf(qup->btx.sg_tx, &qup->start_tag.start[0],
-  &qup->start_tag, len, qup, 0, 0);
-   qup_sg_set_buf(&qup->brx.sg_rx[i << 1],
-  &qup->brx.scratch_tag.start[1],
-  &qup->brx.scratch_tag, 2,
-  qup, 0, 0);
-   } else {
-   qup->btx.footer_tag.start[0] = QUP_BAM_FLUSH_STOP;
-   qup->btx.footer_tag.start[1] = QUP_BAM_FLUSH_STOP;
-
-   tx_nents = (blocks << 1) + 1;
-   sg_init_table(qup->btx.sg_tx, tx_nents);
-
-   while (i < blocks) {
-   tlen = (i == (blocks - 1)) ? rem : 0;
-   len = get_start_tag(&qup->start_tag.start[tx_len],
-   msg, !i, (i == (blocks - 1)), tlen);
-
-   qup_sg_set_buf(&qup->btx.sg_tx[i << 1],
-  &qup->start_tag.start[tx_len],
-  &qup->start_tag,
-  len, qup, 0, 0);
-
-   tx_len += len;
-   qup_sg_set_buf(&qup->btx.sg_tx[(i << 1) + 1],
-  &msg->buf[QUP_READ_LIMIT * i], NULL,
-  tlen, qup, 1, DMA_TO_DEVICE);
-   i++;
+   u32 rx_nents = 0, tx_nents = 0, len, blocks, rem, last;
+   u32 cur_rx_nents, cur_tx_nents;
+   u32 tlen, i, tx_len, tx_buf = 0, rx_buf = 0, off = 0;
+
+   while (num) {
+   blocks = (msg->len + QUP_READ_LIMIT) / QUP_READ_LIMIT;
+   rem = msg->len % QUP_READ_LIMIT;
+   i = 0, tx_len = 0, len = 0;
+
+   if (msg->flags & I2C_M_RD) {
+   cur_tx_nents = 1;
+   cur_rx_nents = (blocks * 2) + 1;
+   rx_nents += cur_rx_nents;
+   tx_nents += cur_t

[PATCH V2 2/6] i2c: qup: Add V2 tags support

From: Andy Gross 

QUP from version 2.1.1 onwards, supports a new format of
i2c command tags. Tag codes instructs the controller to
perform a operation like read/write. This new tagging version
supports bam dma and transfers of more than 256 bytes without 'stop'
in between. Adding the support for the same.

For each block a data_write/read tag and data_len tag is added to
the output fifo. For the final block of data write_stop/read_stop
tag is used.

Signed-off-by: Andy Gross 
Signed-off-by: Sricharan R 
---
 [v2] Addressed comments from Ivan T. Ivanov 

 drivers/i2c/busses/i2c-qup.c | 336 ++-
 1 file changed, 299 insertions(+), 37 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 49c6cba..8605557 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* QUP Registers */
 #define QUP_CONFIG 0x000
@@ -42,6 +43,7 @@
 #define QUP_IN_FIFO_BASE   0x218
 #define QUP_I2C_CLK_CTL0x400
 #define QUP_I2C_STATUS 0x404
+#define QUP_I2C_MASTER_GEN 0x408
 
 /* QUP States and reset values */
 #define QUP_RESET_STATE0
@@ -69,6 +71,8 @@
 #define QUP_CLOCK_AUTO_GATEBIT(13)
 #define I2C_MINI_CORE  (2 << 8)
 #define I2C_N_VAL  15
+#define I2C_N_VAL_V2   7
+
 /* Most significant word offset in FIFO port */
 #define QUP_MSW_SHIFT  (I2C_N_VAL + 1)
 
@@ -80,17 +84,30 @@
 
 #define QUP_REPACK_EN  (QUP_UNPACK_EN | QUP_PACK_EN)
 
+#define QUP_V2_TAGS_EN 1
+
 #define QUP_OUTPUT_BLOCK_SIZE(x)(((x) >> 0) & 0x03)
 #define QUP_OUTPUT_FIFO_SIZE(x)(((x) >> 2) & 0x07)
 #define QUP_INPUT_BLOCK_SIZE(x)(((x) >> 5) & 0x03)
 #define QUP_INPUT_FIFO_SIZE(x) (((x) >> 7) & 0x07)
 
-/* QUP tags */
+/* QUP V1 tags */
 #define QUP_TAG_START  (1 << 8)
 #define QUP_TAG_DATA   (2 << 8)
 #define QUP_TAG_STOP   (3 << 8)
 #define QUP_TAG_REC(4 << 8)
 
+/* QUP v2 tags */
+#define QUP_TAG_V2_HS  0xff
+#define QUP_TAG_V2_START   0x81
+#define QUP_TAG_V2_DATAWR  0x82
+#define QUP_TAG_V2_DATAWR_STOP 0x83
+#define QUP_TAG_V2_DATARD  0x85
+#define QUP_TAG_V2_DATARD_STOP 0x87
+
+/* frequency definitions for high speed and max speed */
+#define I2C_QUP_CLK_FAST_FREQ  100
+
 /* Status, Error flags */
 #define I2C_STATUS_WR_BUFFER_FULL  BIT(0)
 #define I2C_STATUS_BUS_ACTIVE  BIT(8)
@@ -99,6 +116,13 @@
 
 #define QUP_READ_LIMIT 256
 
+struct qup_i2c_block {
+   int blocks;
+   u8  *block_tag_len;
+   int *block_data_len;
+   int block_pos;
+};
+
 struct qup_i2c_dev {
struct device   *dev;
void __iomem*base;
@@ -112,9 +136,17 @@ struct qup_i2c_dev {
int in_fifo_sz;
int out_blk_sz;
int in_blk_sz;
-
+   struct  qup_i2c_block   blk;
unsigned long   one_byte_t;
 
+   int is_hs;
+   booluse_v2_tags;
+
+   int tx_tag_len;
+   int rx_tag_len;
+   u8  *tags;
+   int tags_pos;
+
struct i2c_msg  *msg;
/* Current posion in user message buffer */
int pos;
@@ -262,8 +294,13 @@ static int qup_i2c_wait_ready(struct qup_i2c_dev *qup, int 
op, bool val,
 
 static void qup_i2c_set_write_mode(struct qup_i2c_dev *qup, struct i2c_msg 
*msg)
 {
-   /* Number of entries to shift out, including the start */
-   int total = msg->len + 1;
+   /* Total Number of entries to shift out, including the tags */
+   int total;
+
+   if (qup->use_v2_tags)
+   total = msg->len + qup->tx_tag_len;
+   else
+   total = msg->len + 1; /* plus start tag */
 
if (total < qup->out_fifo_sz) {
/* FIFO mode */
@@ -277,7 +314,7 @@ static void qup_i2c_set_write_mode(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
}
 }
 
-static void qup_i2c_issue_write(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+static void qup_i2c_issue_write_v1(struct qup_i2c_dev *qup, struct i2c_msg 
*msg)
 {
u32 addr = msg->addr << 1;
u32 qup_tag;
@@ -318,6 +355,134 @@ static void qup_i2c_issue_write(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
}
 }
 
+static void qup_i2c_create_tag_v2(struct qup_i2c_dev *qup,
+ struct i2c_msg *msg)
+{
+   u16 addr = (msg->addr << 1) | ((msg->flags & I2C_M_RD) == I2C_M_RD);
+   int len = 0, prev_len = 0;
+   int blocks = 0;
+   int rem;
+   int block_len = 0;
+   int data_len;
+
+   qup->blk.block_pos = 0;
+   qup->pos = 0;
+   qup->blk.blocks =

[PATCH V2 5/6] dts: msm8974: Add blsp2_bam dma node

Signed-off-by: Sricharan R 
---
 [v2] Used macros for interrupts property.

 arch/arm/boot/dts/qcom-msm8974.dtsi | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 2d11641..c2e8711 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-#include 
+#include 
 #include 
 #include "skeleton.dtsi"
 
@@ -263,5 +263,15 @@
interrupt-controller;
#interrupt-cells = <4>;
};
+
+   blsp2_dma: dma@f9944000 {
+   compatible = "qcom,bam-v1.4.0";
+   reg = <0xf9944000 0x19000>;
+   interrupts = ;
+   clocks = <&gcc GCC_BLSP2_AHB_CLK>;
+   clock-names = "bam_clk";
+   #dma-cells = <1>;
+   qcom,ee = <0>;
+   };
};
 };
-- 
1.8.2.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 V2 1/6] i2c: qup: Change qup_wait_writeready function to use for all timeouts

qup_wait_writeready waits only on a output fifo empty event.
Change the same function to accept the event and data length
to wait as parameters. This way the same function can be used for
timeouts in otherplaces as well.

Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 4dad23b..49c6cba 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -221,26 +221,42 @@ static int qup_i2c_change_state(struct qup_i2c_dev *qup, 
u32 state)
return 0;
 }
 
-static int qup_i2c_wait_writeready(struct qup_i2c_dev *qup)
+/**
+ * qup_i2c_wait_ready - wait for a give number of bytes in tx/rx path
+ * @qup: The qup_i2c_dev device
+ * @op: The bit/event to wait on
+ * @val: value of the bit to wait on, 0 or 1
+ * @len: The length the bytes to be transferred
+ */
+static int qup_i2c_wait_ready(struct qup_i2c_dev *qup, int op, bool val,
+ int len)
 {
unsigned long timeout;
u32 opflags;
u32 status;
+   u32 shift = __ffs(op);
 
-   timeout = jiffies + HZ;
+   len *= qup->one_byte_t;
+   /* timeout after a wait of twice the max time */
+   timeout = jiffies + len * 4;
 
for (;;) {
opflags = readl(qup->base + QUP_OPERATIONAL);
status = readl(qup->base + QUP_I2C_STATUS);
 
-   if (!(opflags & QUP_OUT_NOT_EMPTY) &&
-   !(status & I2C_STATUS_BUS_ACTIVE))
-   return 0;
+   if (((opflags & op) >> shift) == val) {
+   if (op == QUP_OUT_NOT_EMPTY) {
+   if (!(status & I2C_STATUS_BUS_ACTIVE))
+   return 0;
+   } else {
+   return 0;
+   }
+   }
 
if (time_after(jiffies, timeout))
return -ETIMEDOUT;
 
-   usleep_range(qup->one_byte_t, qup->one_byte_t * 2);
+   usleep_range(len, len * 2);
}
 }
 
@@ -347,7 +363,7 @@ static int qup_i2c_write_one(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
} while (qup->pos < msg->len);
 
/* Wait for the outstanding data in the fifo to drain */
-   ret = qup_i2c_wait_writeready(qup);
+   ret = qup_i2c_wait_ready(qup, QUP_OUT_NOT_EMPTY, 0, 1);
 
 err:
disable_irq(qup->irq);
-- 
1.8.2.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 V2 0/6] i2c: qup: Add support for v2 tags and bam dma

QUP from version 2.1.1 onwards, supports a new format of i2c command tags. Tag 
codes instructs the controller to perform a operation like read/write. This new 
tagging version supports and is required for adding bam dma capabilities.
v2 tags supports transfer of more than 256 bytes in a single i2c transaction. 
Also adding bam dma support facilitates transferring each i2c_msg in i2c_msgs 
without a 'stop' bit in between which is required for some of the clients.

This series depends on the below bam dma bug fix
 https://lkml.org/lkml/2015/2/20/47

Tested this series on apq8074 dragon board eeprom client on i2c bus1

[V2] Addressed comments from Ivan T. Ivanov, Andy Gross
[v1] Initial Version

Andy Gross (1):
  i2c: qup: Add V2 tags support

Sricharan R (5):
  i2c: qup: Change qup_wait_writeready function to use for all timeouts
  i2c: qup: Add bam dma capabilities
  i2c: qup: Transfer every i2c_msg in i2c_msgs without stop
  dts: msm8974: Add blsp2_bam dma node
  dts: msm8974: Add dma channels for blsp2_i2c1 node

 arch/arm/boot/dts/qcom-msm8974.dtsi |  14 +-
 drivers/i2c/busses/i2c-qup.c| 788 +---
 2 files changed, 748 insertions(+), 54 deletions(-)

-- 
1.8.2.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 v2 2/5] regulator: Introduce property to flag drms

On Thu, Apr 02, 2015 at 02:35:07PM -0700, Bjorn Andersson wrote:

> Would you mind picking the other patches from this series or do you
> want me to resend them? They are unrelated to this issue and will give
> us working regulators (without set_load support) on the affected
> platforms.

There seem to be some dependencies (at least for patch 3) and Stephen
had some review comments on patch 5 so it might be safer to leave them -
but in theory yes.

signature.asc
Description: Digital signature

Re: [PATCH v2 0/5] Refactor Qualcomm RPM regulator to single platform_device

On Mon, Apr 06, 2015 at 10:11:02AM -0700, Bjorn Andersson wrote:

> The RPM will instantiate one regulator device per pmic and parent will
> hence differ between the various regulator instances.
> So with Guenter's patch this does indeed work.

Ah, excellent!  That's easy then...


signature.asc
Description: Digital signature

Re: [PATCH v4 6/6] power: twl4030_madc_battery: Add missing MODULE_ALIAS

2015-04-06 Thread Sebastian Reichel

Hi,

On Tue, Mar 10, 2015 at 10:27:27PM +0100, Marek Belisko wrote:
> Without MODULE_ALIAS twl4030_madc_battery won't get loaded
> automatically.

Thanks, pulled.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4 1/6] power: twl4030-madc-battery: Convert to iio consumer.

2015-04-06 Thread Sebastian Reichel

Hi,

On Tue, Mar 10, 2015 at 10:27:22PM +0100, Marek Belisko wrote:
> Because of added iio error handling private data allocation was
> converted to managed to simplify code.

Thanks, pulled (only PATCH 1/6 for now).

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH V3 5/7] serial: earlycon: Set UPIO_MEM32BE based on DT properties

2015-04-06 Thread Peter Hurley

On 04/02/2015 11:35 AM, Peter Hurley wrote:
> On 04/02/2015 09:46 AM, Rob Herring wrote:
>> Sorry about that. I had thought about doing the same thing. At least
>> unifying the macros, but not necessarily the tables. If it is also
>> extendable to other firmware interfaces like ACPI perhaps that would
>> be good.
> 
> No need to apologize; I'll make those changes and resubmit for your
> review.

What about something like the following?

This patch makes both __earlycon_table and __earlycon_of_table
arrays of struct earlycon_id, and a follow-on patch would use the
earlycon name to initialize the struct console fields.

The benefits of this approach are
1. diagnostics can readily identify the earlycon if there is some error
2. it would be trivial to enable both command line and devicetree
   earlycon from the same earlycon declaration.

And a single table is doable from this point.

AFAICT there is no benefit to using actual OF tables, and I see no
other reasonable way to initialize the name of the struct console
for devicetree earlycons.

Regards,
Peter Hurley


--- >% ---
Subject: [PATCH] serial: earlycon: Use common framework for earlycon
 declarations

Use common table definition and implementation macro to declare an
earlycon, but retain separate tables for command line and devicetree.
Add __EARLYCON_DECLARE() macro to instance a unique earlycon
declaration for the specified table.

This enables all earlycons to properly initialize the earlycon console
structure with name and index.

Signed-off-by: Peter Hurley 
---
 drivers/of/fdt.c  |  6 +++---
 drivers/tty/serial/earlycon.c |  3 +--
 include/asm-generic/vmlinux.lds.h |  8 ++--
 include/linux/serial_core.h   | 30 +-
 4 files changed, 31 insertions(+), 16 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 7cef9f9..f640efa 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -760,14 +760,14 @@ static inline void 
early_init_dt_check_for_initrd(unsigned long node)
 #endif /* CONFIG_BLK_DEV_INITRD */
 
 #ifdef CONFIG_SERIAL_EARLYCON
-extern struct of_device_id __earlycon_of_table[];
+extern struct earlycon_id __earlycon_of_table[];
 
 static int __init early_init_dt_scan_chosen_serial(void)
 {
int offset;
const char *p, *q;
int l;
-   const struct of_device_id *match = __earlycon_of_table;
+   const struct earlycon_id *match = __earlycon_of_table;
const void *fdt = initial_boot_params;
 
offset = fdt_path_offset(fdt, "/chosen");
@@ -800,7 +800,7 @@ static int __init early_init_dt_scan_chosen_serial(void)
if (!addr)
return -ENXIO;
 
-   of_setup_earlycon(addr, match->data);
+   of_setup_earlycon(addr, match->setup);
return 0;
}
return -ENODEV;
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 5fdc9f3..bf7eb76 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #ifdef CONFIG_FIX_EARLYCON_MEM
 #include 
@@ -41,7 +40,7 @@ extern struct earlycon_id __earlycon_table[];
 static const struct earlycon_id __earlycon_table_sentinel
__used __section(__earlycon_table_end);
 
-static const struct of_device_id __earlycon_of_table_sentinel
+static const struct earlycon_id __earlycon_of_table_sentinel
__used __section(__earlycon_of_table_end);
 
 static void __iomem * __init earlycon_map(unsigned long paddr, size_t size)
diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 561daf4..7322c30 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -155,8 +155,13 @@
 VMLINUX_SYMBOL(__earlycon_table) = .;  \
 *(__earlycon_table)\
 *(__earlycon_table_end)
+#define EARLYCON_OF_TABLE()STRUCT_ALIGN();  \
+   VMLINUX_SYMBOL(__earlycon_of_table) = .; \
+   *(__earlycon_of_table)   \
+   *(__earlycon_of_table_end)
 #else
 #define EARLYCON_TABLE()
+#define EARLYCON_OF_TABLE()
 #endif
 
 #define ___OF_TABLE(cfg, name) _OF_TABLE_##cfg(name)
@@ -175,7 +180,6 @@
 #define IOMMU_OF_TABLES()  OF_TABLE(CONFIG_OF_IOMMU, iommu)
 #define RESERVEDMEM_OF_TABLES()OF_TABLE(CONFIG_OF_RESERVED_MEM, 
reservedmem)
 #define CPU_METHOD_OF_TABLES() OF_TABLE(CONFIG_SMP, cpu_method)
-#define EARLYCON_OF_TABLES()   OF_TABLE(CONFIG_SERIAL_EARLYCON, earlycon)
 
 #define KERNEL_DTB()   \
STRUCT_ALIGN(); \
@@ -512,7 +516,7 @@
KERNEL_DTB()\
IRQCHIP_OF_MATCH_TABLE()

Re: [PATCH v3 2/3] devicetree: spi: fsl-dspi: Add cs-sck delays

On Fri, Apr 03, 2015 at 01:39:30PM -0700, Aaron Brice wrote:
> Adding fsl,spi-cs-sck-delay and fsl,spi-sck-cs-delay properties to
> support delays before and after starting the clock in a transfer.

Applied, please use subject lines matching the style for the subsystem.


signature.asc
Description: Digital signature

Re: [PATCH v3 3/3] spi: fsl-dspi: Add ~50ns delay between cs and sck

On Fri, Apr 03, 2015 at 01:39:31PM -0700, Aaron Brice wrote:
> Add delay between chip select and clock signals, before clock starts and
> after clock stops.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH v3 1/3] spi: fsl-dspi: Fix clock rate scale values

On Fri, Apr 03, 2015 at 01:39:29PM -0700, Aaron Brice wrote:
> Previous algorithm had an outer loop with the values {2,3,5,7} and an
> inner loop with {2,4,6,8,16,32,...,32768}, and would pick the first
> value over the required scaling value (where the total scale was the two
> numbers multiplied).

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH v2 0/5] Refactor Qualcomm RPM regulator to single platform_device

On Mon, Apr 6, 2015 at 9:51 AM, Mark Brown  wrote:
> On Thu, Apr 02, 2015 at 03:57:16PM -0700, Stephen Boyd wrote:
>> On 04/02/15 15:26, Mark Brown wrote:
>
>> > Guenther sent a patch fixing that a while back.
>
>> This one?
>
> Yes.
>
>> regulator: Ensure unique regulator debugfs directory names
>
>> Ok. Seems to be only in next. I'm not sure it will work though because
>> in this case the parent device is the same for both regulators on
>> different PMICs that the RPM is controlling. I could be wrong though
>> because I haven't tested it.
>
> I'd say that if the driver is doing this then the driver is buggy - the
> user should be able to distinguish between two regulators appearing for
> the same device.  Either the RPM should create dummy devices for the two
> PMICs or something should insert the PMIC name into the regulator name
> somewhere along the line (perhaps in the static data).

Sorry, I spoke before I had coffee...

The RPM will instantiate one regulator device per pmic and parent will
hence differ between the various regulator instances.
So with Guenter's patch this does indeed work.

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: [PATCHv3 0/2] Add support for generic register mapped poweroff.

2015-04-06 Thread Sebastian Reichel

Hi,

On Wed, Mar 11, 2015 at 05:37:17PM -0700, Moritz Fischer wrote:
> This patchset adds support for generic register mapped poweroff
> via SYCON.

Thanks, pulled:

http://git.infradead.org/battery-2.6.git/commit/8a577608ba4a3cab1d74025cea382e40544ab9cd
http://git.infradead.org/battery-2.6.git/commit/0db739fa06f95a040313c4479e1940caeb48e92f

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v2 0/5] Refactor Qualcomm RPM regulator to single platform_device

On Thu, Apr 02, 2015 at 03:57:16PM -0700, Stephen Boyd wrote:
> On 04/02/15 15:26, Mark Brown wrote:

> > Guenther sent a patch fixing that a while back.

> This one?

Yes.

> regulator: Ensure unique regulator debugfs directory names

> Ok. Seems to be only in next. I'm not sure it will work though because
> in this case the parent device is the same for both regulators on
> different PMICs that the RPM is controlling. I could be wrong though
> because I haven't tested it.

I'd say that if the driver is doing this then the driver is buggy - the
user should be able to distinguish between two regulators appearing for
the same device.  Either the RPM should create dummy devices for the two
PMICs or something should insert the PMIC name into the regulator name
somewhere along the line (perhaps in the static data).

signature.asc
Description: Digital signature

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

On Mon, Apr 6, 2015 at 9:31 AM, Ohad Ben-Cohen  wrote:
> On Mon, Apr 6, 2015 at 7:22 PM, Tim Bird  wrote:
>> On Fri, Apr 3, 2015 at 6:55 AM, Ohad Ben-Cohen  wrote:
>>> On Thu, Apr 2, 2015 at 9:11 PM, Tim Bird  wrote:
 On Wed, Apr 1, 2015 at 9:40 PM, Ohad Ben-Cohen  wrote:
> Sorry, I can't take this without a DT ack.

 Hmmm.

 The policy seems to be:
  "For driver (not subsystem) bindings: If you are comfortable with the
  binding, and it hasn't received an Acked-by from the devicetree
  maintainers after a few weeks, go ahead and take it."

 The syscon property is only relative to the qcom hwspinlock driver,
 (unless I'm missing something) and both Qualcomm and Sony devs are
 OK with it.  So while an ACK from the DT side would be nice, I don't
 think it's required.  This is exactly the type of delay that is really
 holding up a lot of out-of-tree code.
>>>
>>> Sorry, I do prefer to make sure Mark is OK with this devicetree patch,
>>> especially since it wasn't clear whether Mark is entirely comfortable
>>> with it in his last response.
>>
>> Just to be clear - do you personally have any objections to the patch?
>
> No, but this patch is for a folder I don't maintain so I prefer
> someone who does to take a look.
>
> Mark did take a look, and said he's confused by this patch (see this thread).
>
> Do you want me to ignore him and just send it to Linus anyway?

Ohad, Tim,

For this patch to be useful to us we also need Suman's DT patch, so we
should try to get them both in asap.

Based on the long discussion we had on one of the previous iterations
of Suman's DT binding, with the DT maintainers I believe that it would
be fine to move along and sent Suman's patches to Linus - without an
explicit Ack from the DT guys (or did I just miss one?).

Regarding this patch I agree with Ohad that it would be good if we
verify that Mark's question is answered before moving on. So I will
reach out to him to see if he has any remaining concerns.

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 v2 0/5] Refactor Qualcomm RPM regulator to single platform_device

On Thu, Apr 2, 2015 at 3:57 PM, Stephen Boyd  wrote:
> On 04/02/15 15:26, Mark Brown wrote:
>> On Thu, Apr 02, 2015 at 03:00:37PM -0700, Stephen Boyd wrote:
>>
>>> What happens with debugfs when you have multiple pmics with the same
>>> named regulator? I thought that in this case we needed to make the names
>>> unique somehow or we would end up with the same directory for two
>>> different regulators.
>> Guenther sent a patch fixing that a while back.
>
> This one?
>
> commit a9eaa8130707d4013fb109b80323489c0d0111ac
> Author: Guenter Roeck 
> AuthorDate: Fri Oct 17 08:17:03 2014 -0700
> Commit: Mark Brown 
> CommitDate: Fri Mar 27 16:14:18 2015 -0700
>
> regulator: Ensure unique regulator debugfs directory names
>
> Ok. Seems to be only in next. I'm not sure it will work though because
> in this case the parent device is the same for both regulators on
> different PMICs that the RPM is controlling. I could be wrong though
> because I haven't tested it.
>

You're right Stephen; for the platforms with multiple pmics this will
spit out a bunch of warnings and Guenter's fix does not change that
fact.

Either we make the regulator names more specific (like pm8058_l1) or
we build desc.name out of pdev->dev.of_node->name and the regulator
name. I like the latter, so unless someone object I'll respin it that
way.

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

2015-04-06 Thread Ohad Ben-Cohen

On Mon, Apr 6, 2015 at 7:22 PM, Tim Bird  wrote:
> On Fri, Apr 3, 2015 at 6:55 AM, Ohad Ben-Cohen  wrote:
>> On Thu, Apr 2, 2015 at 9:11 PM, Tim Bird  wrote:
>>> On Wed, Apr 1, 2015 at 9:40 PM, Ohad Ben-Cohen  wrote:
 Sorry, I can't take this without a DT ack.
>>>
>>> Hmmm.
>>>
>>> The policy seems to be:
>>>  "For driver (not subsystem) bindings: If you are comfortable with the
>>>  binding, and it hasn't received an Acked-by from the devicetree
>>>  maintainers after a few weeks, go ahead and take it."
>>>
>>> The syscon property is only relative to the qcom hwspinlock driver,
>>> (unless I'm missing something) and both Qualcomm and Sony devs are
>>> OK with it.  So while an ACK from the DT side would be nice, I don't
>>> think it's required.  This is exactly the type of delay that is really
>>> holding up a lot of out-of-tree code.
>>
>> Sorry, I do prefer to make sure Mark is OK with this devicetree patch,
>> especially since it wasn't clear whether Mark is entirely comfortable
>> with it in his last response.
>
> Just to be clear - do you personally have any objections to the patch?

No, but this patch is for a folder I don't maintain so I prefer
someone who does to take a look.

Mark did take a look, and said he's confused by this patch (see this thread).

Do you want me to ignore him and just send it to Linus anyway?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-04-06 Thread Tim Bird

On Fri, Apr 3, 2015 at 6:55 AM, Ohad Ben-Cohen  wrote:
> On Thu, Apr 2, 2015 at 9:11 PM, Tim Bird  wrote:
>> On Wed, Apr 1, 2015 at 9:40 PM, Ohad Ben-Cohen  wrote:
>>> Sorry, I can't take this without a DT ack.
>>
>> Hmmm.
>>
>> The policy seems to be:
>>  "For driver (not subsystem) bindings: If you are comfortable with the
>>  binding, and it hasn't received an Acked-by from the devicetree
>>  maintainers after a few weeks, go ahead and take it."
>>
>> The syscon property is only relative to the qcom hwspinlock driver,
>> (unless I'm missing something) and both Qualcomm and Sony devs are
>> OK with it.  So while an ACK from the DT side would be nice, I don't
>> think it's required.  This is exactly the type of delay that is really
>> holding up a lot of out-of-tree code.
>
> Sorry, I do prefer to make sure Mark is OK with this devicetree patch,
> especially since it wasn't clear whether Mark is entirely comfortable
> with it in his last response.

Just to be clear - do you personally have any objections to the patch?
Are we now stuck in limbo until such time as the device tree maintainers
get around to us?

I'm worried about this status because my understanding is that the
DT maintainers are hugely backlogged and let a lot of stuff drop on the
floor.  In particular, see slide 21 of the following presentation:
http://www.elinux.org/images/0/0a/The_Device_Tree_as_a_Stable_ABI-_A_Fairy_Tale%3F.pdf
That graph shows that the DT maintainers are falling way behind in
their reviews and ACKs.

The policy of not waiting for an ACK from device tree maintainers
was specifically created to help the situation we are now in, and yet
you seem to be unwilling to follow it.  This is extremely frustrating.

One idea we discussed at a recent meeting on mainlining was to submit
SoC-blocking items to drivers/staging.  Then, stuff is at least in the tree
and can be tested by others pending some approval.  Do you have any
opinion on that?

Is there any way to move ahead?  Or are we doomed to just sit around
and wait indefinitely? For the record, after what amount of time without
a DT ACK would you consider accepting this (if ever)?

Another idea I'm considering is to write our own hwspinlock layer
and become the maintainer of that, so we're not blocked by you.
At this point, the value of using your hwspinlock framework
is vastly outweighed by the negative effect is has on our mainlining
effort.

Regards,

 -- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ASoC: add core audio driver for Broadcom Cygnus SOC.

On Thu, Apr 02, 2015 at 11:47:18AM -0700, Lori Hikichi wrote:
> On 15-03-30 11:42 PM, Mark Brown wrote:

> >>+config SND_SOC_CYGNUS
> >>+   tristate "SoC platform audio for Broadcom Cygnus chips"
> >>+   depends on ARCH_BCM_CYGNUS || COMPILE_TEST
> >>+   default ARCH_BCM_CYGNUS

> Okay.

You don't need to reply to every single comment, the general assumption
will be that if there's no other followup all review comments will be
addressed.  It's better to just reply to things where there's something
more detailed to say, if you explicitly reply to everything then that
makes it easier for actual replies to be missed since there's a lot of
there's a lot of the mail that's just going to be skipped through.

> >>+static void ringbuf_inc(void __iomem *audio_io, bool is_playback,
> >>+   const struct ringbuf_regs *p_rbuf)

> >So it looks like we're getting an interrupt per period and we have to
> >manually advance to the next one?

> Yes.

OK, so that seems fragile - what happens if we're slightly late
processing an interrupt or miss one entirely?  Most hardware has some
way to read back the current position which tends to be more reliable,
is that not an option here?

signature.asc
Description: Digital signature

Re: [PATCH 2/3] of: OF_IRQ should depend on IRQ_DOMAIN

On Mon, Apr 6, 2015 at 9:40 AM, Arnd Bergmann  wrote:
> On Sunday 05 April 2015 16:59:24 Geert Uytterhoeven wrote:
>> If CONFIG_IRQ_DOMAIN=n:
>>
>> drivers/of/irq.c: In function ‘of_irq_get’:
>> drivers/of/irq.c:406: error: implicit declaration of function ‘irq_find_host’
>> drivers/of/irq.c:406: warning: assignment makes pointer from integer without 
>> a cast
>> make[2]: *** [drivers/of/irq.o] Error 1
>>
>> Signed-off-by: Geert Uytterhoeven 
>> ---
>>  drivers/of/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
>> index 4c98f14694458794..92adecd3ecb28fc7 100644
>> --- a/drivers/of/Kconfig
>> +++ b/drivers/of/Kconfig
>> @@ -50,7 +50,7 @@ config OF_ADDRESS_PCI
>>
>>  config OF_IRQ
>> def_bool y
>> -   depends on !SPARC
>> +   depends on !SPARC && IRQ_DOMAIN
>>
>>  config OF_NET
>> depends on NETDEVICES
>>
>
> Sparc does not set IRQ_DOMAIN, so we can probably simplify this to
>
> config OF_IRQ
> def_bool IRQ_DOMAIN
>
> unless you want to keep the sparc antidependency explicit.

IRQ_DOMAIN is selected in quite a few places. We'd need to make sure
none of those can be selected by Sparc.

Rob
--
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] of: OF_IRQ should depend on IRQ_DOMAIN

2015-04-06 Thread Geert Uytterhoeven

Hi Arnd,

On Mon, Apr 6, 2015 at 4:40 PM, Arnd Bergmann  wrote:
>> --- a/drivers/of/Kconfig
>> +++ b/drivers/of/Kconfig
>> @@ -50,7 +50,7 @@ config OF_ADDRESS_PCI
>>
>>  config OF_IRQ
>> def_bool y
>> -   depends on !SPARC
>> +   depends on !SPARC && IRQ_DOMAIN
>>
>>  config OF_NET
>> depends on NETDEVICES
>>
>
> Sparc does not set IRQ_DOMAIN, so we can probably simplify this to
>
> config OF_IRQ
> def_bool IRQ_DOMAIN
>
> unless you want to keep the sparc antidependency explicit.

Given drivers/base/platform.c:

int platform_get_irq(struct platform_device *dev, unsigned int num)
{
#ifdef CONFIG_SPARC
...
#else
struct resource *r;
if (IS_ENABLED(CONFIG_OF_IRQ) && dev->dev.of_node) {
...
}
...
#endif
}

yes I do want to keep it explicit.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework

2015-04-06 Thread Matt Porter

On Mon, Apr 06, 2015 at 09:11:05AM -0500, Rob Herring wrote:
> On Mon, Apr 6, 2015 at 8:32 AM, Matt Porter  wrote:
> > On Mon, Mar 30, 2015 at 10:57:59PM +0100, Srinivas Kandagatla wrote:
> >> This patch adds bindings for simple eeprom framework which allows eeprom
> >> consumers to talk to eeprom providers to get access to eeprom cell data.
> >>
> >> Signed-off-by: Maxime Ripard 
> >> [Maxime Ripard: intial version of eeprom framework]
> >> Signed-off-by: Srinivas Kandagatla 
> >> ---
> >>  .../devicetree/bindings/eeprom/eeprom.txt  | 58 
> >> ++
> >>  1 file changed, 58 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt 
> >> b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> >> new file mode 100644
> >> index 000..fb71d46
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> >> @@ -0,0 +1,58 @@
> >> += EEPROM Data Device Tree Bindings =
> >> +
> >> +This binding is intended to represent the location of hardware
> >> +configuration data stored in EEPROMs.
> >> +
> >> +On a significant proportion of boards, the manufacturer has stored
> >> +some data on an EEPROM-like device, for the OS to be able to retrieve
> >> +these information and act upon it. Obviously, the OS has to know
> >> +about where to retrieve these data from, and where they are stored on
> >> +the storage device.
> >
> > Since this binding (and the kernel framework supporting it) describes
> > non-volatile memory devices other than EEPROMs (e.g. EFuses) it should
> > be named more generically like "nvmem".
> >
> >> +
> >> +This document is here to document this.
> >> +
> >> += Data providers =
> >> +Contains bindings specific to provider drivers and data cells as children
> >> +to this node.
> >> +
> >> += Data cells =
> >> +These are the child nodes of the provider which contain data cell
> >> +information like offset and size in eeprom provider.
> >> +
> >> +Required properties:
> >> +reg: specifies the offset in byte within that storage device, and the 
> >> length
> >> + in bytes of the data we care about.
> >> + There could be more then one offset-length pairs in this property.
> >> +
> >> +Optional properties:
> >> +As required by specific data parsers/interpreters.
> >
> > The generic binding could really use a "read-only" property here as this
> > is a common hardware attribute for many nvmem devices. A serial EEPROM
> > commonly has a write protect pin which may be hard-wired such that the
> > hardware description should reflect that. An EFuse is typically blown with
> > the required information at manufacturing time (for an end product case)
> > and would be marked with the "read-only" flag.
> >
> > Having this optional flag in the generic binding would allow the
> > framework to hint to consumers about the inability to write to the
> > provided region.
> 
> This could get fairly complex if you wanted to describe grouping of WP
> regions which could have different layout than the fields here. This
> may be better left as a device property listing addr & size pairs.
> However, there is the notion of s/w "read-only" which means the OS
> should not allow write access. The MTD partition binding supports this
> with the "read-only" property.

Yes, if the backing device has the capability to hw write protect
regions the exported fields overlap those then it does get ugly.
The MTD partition property was the inspiration here so perhaps it's
best to term this as a property indicating how the data region is
used in an implementation.

If it's left as a device property, then a binding with this property
would need to be defined for the Efuse, etc. cases..or a simple-nvmem
binding to handle the various OTP technologies.

> > The framework sysfs attributes provide a userspace EEPROM consumer where
> > it would be useful information to know that a data provider region is
> > read only rather than having the exported writeable attribute simply
> > fail a write cycle. This would allow the consumer to be aware that a
> > failed write (if even attempted) is expected if the data provider
> > advertised itself as read-only.
> 
> You could distinguish with RW versus RO file attributes.

Right, that would be preferred, based on the what the data provider
advertises.

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

irqchip heirarchy DT "break" series awareness?

2015-04-06 Thread Jason Cooper

Arnd, Olof, others,

Have you been following Marc's irqchip series(es) leveraging stacked
domains to remove the abuse of gic_arch_extn ?

Tegra LIC

https://lkml.kernel.org/r/1426088583-15097-1-git-send-email-marc.zyng...@arm.com

OMAP Crossbar

https://lkml.kernel.org/r/1426088629-15377-1-git-send-email-marc.zyng...@arm.com

Exynos PM

https://lkml.kernel.org/r/1426088693-15724-1-git-send-email-marc.zyng...@arm.com

shmobile, ux500, zynq irq_set_wake

https://lkml.kernel.org/r/1426088737-15817-1-git-send-email-marc.zyng...@arm.com

imx6 was taken by Shawn

https://lkml.kernel.org/r/1426262737-32762-1-git-send-email-marc.zyng...@arm.com

You can find the patches in one series per branch at:

git://git.infradead.org/users/jcooper/linux.git irqchip/stacked-tegra
git://git.infradead.org/users/jcooper/linux.git irqchip/stacked-omap
git://git.infradead.org/users/jcooper/linux.git irqchip/stacked-exynos
git://git.infradead.org/users/jcooper/linux.git irqchip/stacked-irq_set_wake

I ask because with Thomas' (tglx) absence, it looks like I'm going to be
sending the pull request directly to Linus. This has increased my
pucker factor a bit. :-)

The logistical stuff is in order. It'll be my second pull request, and
it'll only contain the changes relevant. The whole set has gone through
several rounds of review. All the arm sub-arch maintainers have either
taken the part relevant to them, Acked me taking them, or failed to
object while they've been in linux-next for several weeks now.

My concern is the DT ABI stability problem. In short, we fucked up.
When we added several of the irqchip bindings, we designed them based on
the Linux implementation (gic_arch_extn). *Not* by describing the
hardware.

Marc's series undoes this in the best way possible. He changes the DT
bindings to actually describe the hardware, which then gets modeled in
stacked domains quite well.

This causes two problems:

1) Upgrade kernel, but not DTB.

System will boot, and print a big fat warning that
suspend/resume will not work until the DTB is upgraded.

2) Upgrade DTB, but not kernel.

System will fail to boot.

In light of Thomas Petazonni's well-researched talk at ELC:

"The Device Tree as a stable ABI: a fairy tale?"

http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-dt-as-stable-abi-fairy-tale.pdf

I'm confident that #2 won't be an issue. Distro's and OEMs seem to have
worked around the instability by keeping the dtb tied to the kernel
version.

And, on the off chance that end users upgrade their kernel, say, by
building mainline, there's a very clear warning that tells them exactly
what to do: Upgrade the dtb as well.

Do you foresee any problem with this? Is there anything I haven't
considered? Or extra information I'll need to present in my pull
request?

thx,

Jason.
--
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] of: OF_IRQ should depend on IRQ_DOMAIN

2015-04-06 Thread Arnd Bergmann

On Sunday 05 April 2015 16:59:24 Geert Uytterhoeven wrote:
> If CONFIG_IRQ_DOMAIN=n:
> 
> drivers/of/irq.c: In function ‘of_irq_get’:
> drivers/of/irq.c:406: error: implicit declaration of function ‘irq_find_host’
> drivers/of/irq.c:406: warning: assignment makes pointer from integer without 
> a cast
> make[2]: *** [drivers/of/irq.o] Error 1
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  drivers/of/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 4c98f14694458794..92adecd3ecb28fc7 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -50,7 +50,7 @@ config OF_ADDRESS_PCI
>  
>  config OF_IRQ
> def_bool y
> -   depends on !SPARC
> +   depends on !SPARC && IRQ_DOMAIN
>  
>  config OF_NET
> depends on NETDEVICES
> 

Sparc does not set IRQ_DOMAIN, so we can probably simplify this to 

config OF_IRQ
def_bool IRQ_DOMAIN

unless you want to keep the sparc antidependency explicit.

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

Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework

On Mon, Apr 6, 2015 at 8:32 AM, Matt Porter  wrote:
> On Mon, Mar 30, 2015 at 10:57:59PM +0100, Srinivas Kandagatla wrote:
>> This patch adds bindings for simple eeprom framework which allows eeprom
>> consumers to talk to eeprom providers to get access to eeprom cell data.
>>
>> Signed-off-by: Maxime Ripard 
>> [Maxime Ripard: intial version of eeprom framework]
>> Signed-off-by: Srinivas Kandagatla 
>> ---
>>  .../devicetree/bindings/eeprom/eeprom.txt  | 58 
>> ++
>>  1 file changed, 58 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt
>>
>> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt 
>> b/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> new file mode 100644
>> index 000..fb71d46
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> @@ -0,0 +1,58 @@
>> += EEPROM Data Device Tree Bindings =
>> +
>> +This binding is intended to represent the location of hardware
>> +configuration data stored in EEPROMs.
>> +
>> +On a significant proportion of boards, the manufacturer has stored
>> +some data on an EEPROM-like device, for the OS to be able to retrieve
>> +these information and act upon it. Obviously, the OS has to know
>> +about where to retrieve these data from, and where they are stored on
>> +the storage device.
>
> Since this binding (and the kernel framework supporting it) describes
> non-volatile memory devices other than EEPROMs (e.g. EFuses) it should
> be named more generically like "nvmem".
>
>> +
>> +This document is here to document this.
>> +
>> += Data providers =
>> +Contains bindings specific to provider drivers and data cells as children
>> +to this node.
>> +
>> += Data cells =
>> +These are the child nodes of the provider which contain data cell
>> +information like offset and size in eeprom provider.
>> +
>> +Required properties:
>> +reg: specifies the offset in byte within that storage device, and the length
>> + in bytes of the data we care about.
>> + There could be more then one offset-length pairs in this property.
>> +
>> +Optional properties:
>> +As required by specific data parsers/interpreters.
>
> The generic binding could really use a "read-only" property here as this
> is a common hardware attribute for many nvmem devices. A serial EEPROM
> commonly has a write protect pin which may be hard-wired such that the
> hardware description should reflect that. An EFuse is typically blown with
> the required information at manufacturing time (for an end product case)
> and would be marked with the "read-only" flag.
>
> Having this optional flag in the generic binding would allow the
> framework to hint to consumers about the inability to write to the
> provided region.

This could get fairly complex if you wanted to describe grouping of WP
regions which could have different layout than the fields here. This
may be better left as a device property listing addr & size pairs.
However, there is the notion of s/w "read-only" which means the OS
should not allow write access. The MTD partition binding supports this
with the "read-only" property.

> The framework sysfs attributes provide a userspace EEPROM consumer where
> it would be useful information to know that a data provider region is
> read only rather than having the exported writeable attribute simply
> fail a write cycle. This would allow the consumer to be aware that a
> failed write (if even attempted) is expected if the data provider
> advertised itself as read-only.

You could distinguish with RW versus RO file attributes.

Rob
--
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 1/2] dt-bindings: Document the hi6220 thermal sensor bindings

2015-04-06 Thread Matt Porter

On Tue, Mar 31, 2015 at 02:59:21PM +0800, Xinwei Kong wrote:
> From: kongxinwei 
> 
> This adds documentation of device tree bindings for the
> thermal sensor controller of hi6220 SoC.
> 
> Signed-off-by: Leo Yan 
> Signed-off-by: kongxinwei 
> ---
>  .../bindings/thermal/hisilicon-thermal.txt | 45 
> ++
>  1 file changed, 45 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
> 
> diff --git a/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
> new file mode 100644
> index 000..ceb6e2e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
> @@ -0,0 +1,45 @@
> +* Hisilicon Thermal
> +
> +This driver is for hi6220 SoC which contain 4 thermal sensor.
> +
> + 1. sensor 0: local sensor;
> + 2. sensor 1: remote sensor for ACPU cluster 1;
> + 3. sensor 2: remote sensor for ACPU cluster 2;
> + 4. sensor 3: remote sensor for GPU.
> +
> +Every sensor use one child node to represent it, so thermal sensor include
> +parent node and four child node. The parent node describe common feature and
> +child node describe private feature for thermal sensor;
> +
> +** Required properties :
> +
> +- compatible: "hisilicon,tsensor".
> +- reg: physical base address of thermal sensor and length of memory mapped
> +  region.
> +- interrupt: The interrupt number to the cpu. Defines the interrupt used
> +  by SOCTHERM.
> +- clock-names: Input clock name, should be 'thermal_clk'.
> +- clocks: phandles for clock specified in "clock-names" property.
> +- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description.
> +
> +** Required properties for child nodes :
> +
> +- hisilicon,tsensor-id: the index of thermal sensor and use it to distinguish
> +  thermal sensor. For example: <0> stands for local sensor; <1> stands for
> +  acpu1 sensor;

Please show an example illustrating why this property is needed. The
example below doesn't show any per sensor properties aside from the
sensor id. Other bindings with a similar sub-sensor hardware design like
tegra-soctherm and rockchip-thermal don't have a need for a vendor
specific property like this. Their drivers simply iterate over an id
index during thermal sensor registration.

-Matt

> +
> +Example :
> +
> + tsensor: tsensor@0,f7030700 {
> + compatible = "hisilicon,tsensor";
> + reg = <0x0 0xf7030700 0x0 0x1000>;
> + interrupts = <0 7 0x4>;
> + clocks = <&clock_sys HI6220_TSENSOR_CLK>;
> + clock-names = "thermal_clk";
> + #thermal-sensor-cells = <1>;
> +
> + local_sensor {
> + hisilicon,tsensor-id = <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

Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework

2015-04-06 Thread Matt Porter

On Mon, Mar 30, 2015 at 10:57:59PM +0100, Srinivas Kandagatla wrote:
> This patch adds bindings for simple eeprom framework which allows eeprom
> consumers to talk to eeprom providers to get access to eeprom cell data.
> 
> Signed-off-by: Maxime Ripard 
> [Maxime Ripard: intial version of eeprom framework]
> Signed-off-by: Srinivas Kandagatla 
> ---
>  .../devicetree/bindings/eeprom/eeprom.txt  | 58 
> ++
>  1 file changed, 58 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt
> 
> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt 
> b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> new file mode 100644
> index 000..fb71d46
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> @@ -0,0 +1,58 @@
> += EEPROM Data Device Tree Bindings =
> +
> +This binding is intended to represent the location of hardware
> +configuration data stored in EEPROMs.
> +
> +On a significant proportion of boards, the manufacturer has stored
> +some data on an EEPROM-like device, for the OS to be able to retrieve
> +these information and act upon it. Obviously, the OS has to know
> +about where to retrieve these data from, and where they are stored on
> +the storage device.

Since this binding (and the kernel framework supporting it) describes
non-volatile memory devices other than EEPROMs (e.g. EFuses) it should
be named more generically like "nvmem".

> +
> +This document is here to document this.
> +
> += Data providers =
> +Contains bindings specific to provider drivers and data cells as children
> +to this node.
> +
> += Data cells =
> +These are the child nodes of the provider which contain data cell
> +information like offset and size in eeprom provider.
> +
> +Required properties:
> +reg: specifies the offset in byte within that storage device, and the length
> + in bytes of the data we care about.
> + There could be more then one offset-length pairs in this property.
> +
> +Optional properties:
> +As required by specific data parsers/interpreters.

The generic binding could really use a "read-only" property here as this
is a common hardware attribute for many nvmem devices. A serial EEPROM
commonly has a write protect pin which may be hard-wired such that the
hardware description should reflect that. An EFuse is typically blown with
the required information at manufacturing time (for an end product case)
and would be marked with the "read-only" flag.

Having this optional flag in the generic binding would allow the
framework to hint to consumers about the inability to write to the
provided region.

The framework sysfs attributes provide a userspace EEPROM consumer where
it would be useful information to know that a data provider region is
read only rather than having the exported writeable attribute simply
fail a write cycle. This would allow the consumer to be aware that a
failed write (if even attempted) is expected if the data provider
advertised itself as read-only.

-Matt

> +
> +For example:
> +
> + /* Provider */
> + qfprom: qfprom@0070 {
> + compatible  = "qcom,qfprom";
> + reg = <0x0070 0x8000>;
> + ...
> +
> + /* Data cells */
> + tsens_calibration: calib@4404 {
> + reg = <0x4404 0x10>;
> + };
> +
> + serial_number: sn {
> + reg = <0x104 0x4>, <0x204 0x4>, <0x30c 0x4>;
> +
> + };
> + ...
> + };
> +
> += Data consumers =
> +Are device nodes which consume eeprom data cells.
> +
> +For example:
> +
> + tsens {
> + ...
> + calibration = <&tsens_calibration>;
> + };
> -- 
> 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

Re: [PATCH 1/3] of: Allow OF to be enabled if COMPILE_TEST to increase coverage

+Pantelis

On Sun, Apr 5, 2015 at 9:59 AM, Geert Uytterhoeven  wrote:
> Currently the OF configuration symbol is explicitly selected on
> architectures that support device trees and/or Open Firmware.
> However, there's no technical reason to limit the device tree
> infrastructure to these architectures. Hence allow OF to be enabled when
> compile testing, to increase compile coverage.
>
> Signed-off-by: Geert Uytterhoeven 
> ---
>  drivers/of/Kconfig | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 7bcaeec876c0c3a5..4c98f14694458794 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -2,7 +2,11 @@ config DTC
> bool
>
>  config OF
> -   bool
> +   bool "Device Tree and Open Firmware support" if COMPILE_TEST

Actually, I think we want to just make this always visible. There are
now use cases with overlays where we may want to enable DT even if the
architecture is not booting with DT. However, there may be more work
needed to do that.

Rob

> +   help
> + This option enables the device tree infrastructure.
> + If is automatically selected by platforms that need it, but can
> + be enabled manually to increase compile-coverage.
>
>  menu "Device Tree and Open Firmware support"
> depends on OF
> --
> 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
--
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 3/3] i2c: davinci: use ICPFUNC to toggle I2C as gpio for bus recovery

2015-04-06 Thread grygorii.strashko

From: Grygorii Strashko 

Having a board where the I2C bus locks up occasionally made it clear
that the bus recovery in the i2c-davinci driver will only work on
some boards, because on regular boards, this will only toggle GPIO
lines that aren't muxed to the actual pins.

The I2C controller on SoCs like da850 (and da830), Keystone 2 has the
built-in capability to bit-bang its lines by using the ICPFUNC registers
of the i2c controller.
Implement the suggested procedure by toggling SCL and checking SDA using
the ICPFUNC registers of the I2C controller when present. Allow platforms
to indicate the presence of the ICPFUNC registers with a has_pfunc platform
data flag and add optional DT property "ti,has-pfunc" to indicate
the same in DT.

CC: Sekhar Nori 
CC: Kevin Hilman 
CC: Santosh Shilimkar 
CC: Murali Karicheri 
CC: Mike Looijmans 
CC: 
Reviewed-by: Uwe Kleine-König 
Acked-by: Alexander Sverdlin 
Tested-by: Michael Lawnick 
Signed-off-by: Ben Gardiner 
Signed-off-by: Mike Looijmans 
[grygorii.stras...@ti.com: combined patches from Ben Gardiner and
Mike Looijmans and reimplemented ICPFUNC bus recovery using I2C
bus recovery infrastructure]
Signed-off-by: Grygorii Strashko 
---
 .../devicetree/bindings/i2c/i2c-davinci.txt|   3 +
 drivers/i2c/busses/i2c-davinci.c   | 102 -
 include/linux/platform_data/i2c-davinci.h  |   1 +
 3 files changed, 105 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt 
b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt
index 2dc935b..a4e1cbc 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt
@@ -10,6 +10,9 @@ Required properties:
 Recommended properties :
 - interrupts : standard interrupt property.
 - clock-frequency : desired I2C bus clock frequency in Hz.
+- ti,has-pfunc: boolean; if defined, it indicates that SoC supports PFUNC
+   registers. PFUNC registers allow to switch I2C pins to function as
+   GPIOs, so they can by toggled manually.
 
 Example (enbw_cmc board):
i2c@1c22000 {
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 54819fb..4788a32 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -60,6 +60,12 @@
 #define DAVINCI_I2C_IVR_REG0x28
 #define DAVINCI_I2C_EMDR_REG   0x2c
 #define DAVINCI_I2C_PSC_REG0x30
+#define DAVINCI_I2C_FUNC_REG   0x48
+#define DAVINCI_I2C_DIR_REG0x4c
+#define DAVINCI_I2C_DIN_REG0x50
+#define DAVINCI_I2C_DOUT_REG   0x54
+#define DAVINCI_I2C_DSET_REG   0x58
+#define DAVINCI_I2C_DCLR_REG   0x5c
 
 #define DAVINCI_I2C_IVR_AAS0x07
 #define DAVINCI_I2C_IVR_SCD0x06
@@ -93,6 +99,29 @@
 #define DAVINCI_I2C_IMR_NACK   BIT(1)
 #define DAVINCI_I2C_IMR_AL BIT(0)
 
+/* set SDA and SCL as GPIO */
+#define DAVINCI_I2C_FUNC_PFUNC0BIT(0)
+
+/* set SCL as output when used as GPIO*/
+#define DAVINCI_I2C_DIR_PDIR0  BIT(0)
+/* set SDA as output when used as GPIO*/
+#define DAVINCI_I2C_DIR_PDIR1  BIT(1)
+
+/* read SCL GPIO level */
+#define DAVINCI_I2C_DIN_PDIN0 BIT(0)
+/* read SDA GPIO level */
+#define DAVINCI_I2C_DIN_PDIN1 BIT(1)
+
+/*set the SCL GPIO high */
+#define DAVINCI_I2C_DSET_PDSET0BIT(0)
+/*set the SDA GPIO high */
+#define DAVINCI_I2C_DSET_PDSET1BIT(1)
+
+/* set the SCL GPIO low */
+#define DAVINCI_I2C_DCLR_PDCLR0BIT(0)
+/* set the SDA GPIO low */
+#define DAVINCI_I2C_DCLR_PDCLR1BIT(1)
+
 struct davinci_i2c_dev {
struct device   *dev;
void __iomem*base;
@@ -253,6 +282,71 @@ static struct i2c_bus_recovery_info 
davinci_i2c_gpio_recovery_info = {
.unprepare_recovery = davinci_i2c_unprepare_recovery,
 };
 
+static void davinci_i2c_set_scl(struct i2c_adapter *adap, int val)
+{
+   struct davinci_i2c_dev *dev = i2c_get_adapdata(adap);
+
+   if (val)
+   davinci_i2c_write_reg(dev, DAVINCI_I2C_DSET_REG,
+ DAVINCI_I2C_DSET_PDSET0);
+   else
+   davinci_i2c_write_reg(dev, DAVINCI_I2C_DCLR_REG,
+ DAVINCI_I2C_DCLR_PDCLR0);
+}
+
+static int davinci_i2c_get_scl(struct i2c_adapter *adap)
+{
+   struct davinci_i2c_dev *dev = i2c_get_adapdata(adap);
+   int val;
+
+   /* read the state of SCL */
+   val = davinci_i2c_read_reg(dev, DAVINCI_I2C_DIN_REG);
+   return val & DAVINCI_I2C_DIN_PDIN0;
+}
+
+static int davinci_i2c_get_sda(struct i2c_adapter *adap)
+{
+   struct davinci_i2c_dev *dev = i2c_get_adapdata(adap);
+   int val;
+
+   /* read the state of SDA */
+   val = davinci_i2c_read_reg(dev, DAVINCI_I2C_DIN_REG);
+   return val & DAVINCI_I2C_DIN_PDIN1;
+}
+
+static void davinci_i2c_scl_prepare_recovery(struct i2c_adapter *adap)
+{
+   struct davinci_i2c_dev *dev = i2c_get_adapdata(adap);
+
+   davinci_i2c_prepare_recovery(adap);
+
+

Re: [PATCH/RFC 0/6] staging: board: armadillo800eva: Board staging for sh_mobile_lcdc_fb

2015-04-06 Thread Marc Zyngier


Hi Geert,

On 2015-04-03 13:41, Geert Uytterhoeven wrote:

Hi all,

This RFC patch series adds board staging support for 
r8a7740/armadillo.
For now this supports only the frame buffer device for the on-board 
LCD.

The goal is to complete the move to ARM multiplatform kernels for all
shmobile platforms, and drop the existing board files
(arch/arm/mach-shmobile/board-*).

The board staging area was introduced last year to allow continuous
upstream in-tree development and integration of platform devices. It
helps developers integrate devices as platform devices for device
drivers that only provide platform device bindings.  This in turn 
allows

for incremental development of both hardware feature support and DT
binding work in parallel.

This series consists of 4 parts:
  - Patch 1 re-enables compilation of the board staging area, which 
was

disabled after a compile breakage, but has been fixed in the mean
time,
  - Path 2 moves initialization of staging board code to an earlier
moment, as currently it happens after unused PM domains are 
powered

down,
  - Patches 3 and 4 (hopefully) fix the existing kzm9d board staging
code, which was presumably broken by commit 9a1091ef0017c40a
("irqchip: gic: Support hierarchy irq domain."),


Please allow me a semantic correction here: this commit never broke 
anything. It merely revealed how platform code (OMAP, iMX6, shmobile) 
abused the irq_domain subsystem, hoping to get away with only a partial 
conversion to DT. The platform code itself was broken from the moment it 
used DT to discover its interrupt controller.


The truth is, it is not possible to sanely convert bits of a platform 
to DT. The changes creep into all the subsystems, and doing it in stages 
requires tons of ugly hacks (and I've written my share of them).


That being said, I'm off reviewing these two matches.

Thanks,

M.
--
Fast, cheap, reliable. Pick two.
--
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/RFC 3/6] staging: board: Add support for translating hwirq to virq numbers

2015-04-06 Thread Marc Zyngier


On 2015-04-03 13:42, Geert Uytterhoeven wrote:

As of commit 9a1091ef0017c40a ("irqchip: gic: Support hierarchy irq
domain."), GIC IRQ numbers are virtual, breaking hardcoded hardware 
IRQ

numbers in platform device resources.

Add support for translating hardware IRQ numbers to virtual IRQ 
numbers,

and fixing up platform device resources with hardcoded IRQ numbers.

Add a copyright header, including the original author.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/staging/board/board.c | 66
+++
 drivers/staging/board/board.h |  5 
 2 files changed, 71 insertions(+)

diff --git a/drivers/staging/board/board.c 
b/drivers/staging/board/board.c

index d5a6abc845191c93..b84ac2837a20bf06 100644
--- a/drivers/staging/board/board.c
+++ b/drivers/staging/board/board.c
@@ -1,10 +1,27 @@
+/*
+ * Copyright (C) 2014 Magnus Damm
+ * Copyright (C) 2015 Glider bvba
+ *
+ * This file is subject to the terms and conditions of the GNU
General Public
+ * License.  See the file "COPYING" in the main directory of this 
archive

+ * for more details.
+ */
+
+#define pr_fmt(fmt)"board_staging: "  fmt
+
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+
 #include "board.h"

+static struct device_node *irqc_node __initdata;
+static unsigned int irqc_base __initdata;
+
 static bool find_by_address(u64 base_address)
 {
struct device_node *dn = of_find_all_nodes(NULL);
@@ -38,3 +55,52 @@ bool __init board_staging_dt_node_available(const
struct resource *resource,

return false; /* Nothing found */
 }
+
+int __init board_staging_setup_hwirq_xlate(const char *irqc_match,
+  unsigned int base)
+{
+   irqc_node = of_find_compatible_node(NULL, NULL, irqc_match);
+
+   WARN_ON(!irqc_node);
+   if (!irqc_node)
+   return -ENOENT;
+
+   irqc_base = base;
+   return 0;
+}


And what happens when you have multiple (cascaded) interrupt 
controllers, each wanting to register with this translation service? You 
should at least check that nobody has been here before.



+static unsigned int __init xlate_hwirq(unsigned int hwirq)
+{
+   struct of_phandle_args irq_data;
+   unsigned int irq;
+
+   if (!irqc_node)
+   return hwirq;
+
+   irq_data.np = irqc_node;
+   irq_data.args_count = 3;
+   irq_data.args[0] = 0;
+   irq_data.args[1] = hwirq - irqc_base;
+   irq_data.args[2] = IRQ_TYPE_LEVEL_HIGH;


And what happens for edge interrupts? Or LEVEL_LOW? This is very much 
GIC specific (3 args...). How does it work with non-GIC interrupt 
controllers?



+
+   irq = irq_create_of_mapping(&irq_data);
+   if (WARN_ON(!irq))
+   irq = hwirq;
+
+   return irq;
+}
+
+void __init board_staging_fixup_irq_resources(struct resource *res,
+ unsigned int nres)
+{
+   unsigned int i;
+
+   for (i = 0; i < nres; i++)
+   if (res[i].flags == IORESOURCE_IRQ) {
+   unsigned int hwirq = res[i].start;
+   unsigned int virq = xlate_hwirq(hwirq);
+
+   pr_debug("hwirq %u -> virq %u\n", hwirq, virq);
+   res[i].start = virq;
+   }
+}
diff --git a/drivers/staging/board/board.h 
b/drivers/staging/board/board.h

index e9c914985d4acb36..4cedc3c46e287eb7 100644
--- a/drivers/staging/board/board.h
+++ b/drivers/staging/board/board.h
@@ -1,10 +1,15 @@
 #ifndef __BOARD_H__
 #define __BOARD_H__
+
 #include 
 #include 

+struct resource;
+
 bool board_staging_dt_node_available(const struct resource 
*resource,

 unsigned int num_resources);
+int board_staging_setup_hwirq_xlate(const char *irqc_match, unsigned
int base);
+void board_staging_fixup_irq_resources(struct resource *res,
unsigned int nres);

 #define board_staging(str, fn) \
 static int __init runtime_board_check(void)\


It won't surprise you that I don't really like this approach. It is 
controller-specific, restrictive, and allows platform code to continue 
doing something that is essentially wrong. Should this code ever move 
out of staging, it should depend on CONFIG_BROKEN, because this is 
essentially what it is - support code for broken systems. I'd also 
welcome moving parts of the OMAP4/5 code to such CONFIG_BROKEN 
dependency.


Thanks,

M.
--
Fast, cheap, reliable. Pick two.
--
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] spi: bcm-mspi: Make BCMA optional to support non-BCMA chips

On 3 April 2015 at 19:52, Florian Fainelli  wrote:
> On 03/04/15 06:38, Andy Shevchenko wrote:
>> On Thu, Apr 2, 2015 at 10:23 PM, Jonathan Richardson
>>  wrote:
>>> The Broadcom MSPI controller is used on various chips. The driver only
>>> supported BCM53xx chips with BCMA (an AMBA bus variant). The driver is
>>> refactored to make BCMA optional and provides a new config for non BCMA
>>> systems.
>>
>>>  struct bcm_mspi {
>>> +   #ifdef CONFIG_SPI_BCMA_MSPI
>>> struct bcma_device *core;
>>> -   struct spi_master *master;
>>> +   #endif
>>>
>>> +   void __iomem *base;
>>> +   struct spi_master *master;
>>> size_t read_offset;
>>
>>> +   void (*mspi_write)(struct bcm_mspi *mspi, u16 offset, u32 value);
>>> +   u32 (*mspi_read)(struct bcm_mspi *mspi, u16 offset);
>>> +};
>>
>> To avoid ugly ifdefs I think better to split driver to core part and
>> the actual driver part, at the end you will have something like
>> mspi-core.c mspi-53xx.c mspi-whatever.c. Check for example spi-dw*.c
>
> Actually, I am really curious whether we need the special BCMA I/O
> accessors in the first place, cannot we just access the MSPI core on
> BCM53xx chips using regular MMIO? That would probably solve the
> "problem" entirely. Rafal, did you try this before?

It's a matter of choice between:
1) Using one design for all bcma users
2) Using one design for all bcm-mspi users
I believe no matter which one you choose, you'll break another one.

If you take a look at drivers/bcma/host_soc.c, you'll see we've there
core->io_addr. I guess you could use it as the base in bcm-mspi. That
of course will make you a bit less compatible with other bcma drivers
(skipping bcma R/W layer).


> As for splitting the driver into a "library" driver which is mostly
> independent from the bus and a bus-specific wrapper, I think BCMA is
> really the only special case here, which is why I suggested earlier to
> Jonathan that we might just prefer ifdefing things out instead of
> creating a separate layer just for BCMA.

I think you may be right, this #if for bcma shouldn't be that bad and
it shouldn't grow in the future.
Still, I'd like to get this patch split nicely to review independent changes.

-- 
Rafał
--
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] spi: bcm-mspi: Make BCMA optional to support non-BCMA chips

On 3 April 2015 at 15:38, Andy Shevchenko  wrote:
> On Thu, Apr 2, 2015 at 10:23 PM, Jonathan Richardson
>  wrote:
>> The Broadcom MSPI controller is used on various chips. The driver only
>> supported BCM53xx chips with BCMA (an AMBA bus variant). The driver is
>> refactored to make BCMA optional and provides a new config for non BCMA
>> systems.
>
>>  struct bcm_mspi {
>> +   #ifdef CONFIG_SPI_BCMA_MSPI
>> struct bcma_device *core;
>> -   struct spi_master *master;
>> +   #endif
>>
>> +   void __iomem *base;
>> +   struct spi_master *master;
>> size_t read_offset;
>
>> +   void (*mspi_write)(struct bcm_mspi *mspi, u16 offset, u32 value);
>> +   u32 (*mspi_read)(struct bcm_mspi *mspi, u16 offset);
>> +};
>
> To avoid ugly ifdefs I think better to split driver to core part and
> the actual driver part, at the end you will have something like
> mspi-core.c mspi-53xx.c mspi-whatever.c. Check for example spi-dw*.c

I also believe we usually (always?) don't align any #if-s (no indent/tabs).

-- 
Rafał
--
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] spi: bcm-mspi: Make BCMA optional to support non-BCMA chips

On 2 April 2015 at 21:23, Jonathan Richardson  wrote:
> The Broadcom MSPI controller is used on various chips. The driver only
> supported BCM53xx chips with BCMA (an AMBA bus variant). The driver is
> refactored to make BCMA optional and provides a new config for non BCMA
> systems.

I think this patch provides 3 changes instead of just one described
above. You refactored R/W ops (pointers), made bcma optional and added
DT support. What about patch-per-change?
--
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/4] spi: bcm53xx: Refactor to make driver nonspecific to 53xx SoCs

On 3 April 2015 at 15:35, Andy Shevchenko  wrote:
> On Thu, Apr 2, 2015 at 10:23 PM, Jonathan Richardson
>  wrote:
>> The Broadcom MSPI controller is used on various SoCs. It is being
>> renamed so that it can be extended and reused on other chips. It is
>> renamed to bcm-mspi.
>>
> What if you resend this one with -M -C applied?

Definitely, right now I can't really review this patch (and I want to).

-- 
Rafał
--
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 07/11] ARM: allow MULTIPLATFORM with !MMU

2015-04-06 Thread Russell King - ARM Linux

On Mon, Apr 06, 2015 at 11:33:53AM +0200, Stefan Agner wrote:
> On 2015-04-06 10:54, Russell King - ARM Linux wrote:
> > On Mon, Apr 06, 2015 at 10:38:10AM +0200, Stefan Agner wrote:
> >> We already prevent a kernel image which mixes V4/V4T/V5 and V6/V7. And
> >> so we would do with V7M too. Just because it's in multiplatform doesn't
> >> mean we need to mix things up.
> > 
> > I don't think you're getting what I'm saying at all... :(
> 
> It's not that I don't get it. I'm just arguing against it.
> 
> IMHO, it's wrong to create a parallel universe for v7M multiplatform...
> 
> Multiplatform as I understand it is mainly about selecting multiple SoC
> _platforms_ but not necessarily multiple CPU platforms. It happens to
> work well for V6/V7, but does not for others, and preventing
> multiselection for incompatible CPU platforms is the way to prevent
> creating such images.

Let's be clear: I'm _not_ arguing against being able to select multiple
SoC platforms at all.  I'm merely arguing about how it should be done.

What I'm saying, is that MULTIPLATFORM itself does _not_ work for all
noMMU platforms.  Yes, it _may_ work for V7M, but it doesn't work for
previous generation stuff - and that's confusing.

Let's look at what needs to happen to make V7M work the way you're
suggesting:
* Add "depends on !MMU" to all the existing ARCH_MULTI_* symbols.
* Append "if MMU" to the selection of ARM_PATCH_PHYS_VIRT and
  AUTO_ZRELADDR in multiplatform.

We then have the problem for the older generation noMMU stuff.  Should
we stuff into the multiplatform architecture options for selecting the
older generation noMMU _platforms_ into the "CPU Core family selection"
menu?  That's clearly wrong because they're not "CPU Cores".

So, we have to find somewhere else to put the older generation stuff,
and by doing so, that causes confusion, because we now have to select
multiplatform for one group of noMMU implementations, and _not_
select it for another group of noMMU implementations.

Imagine yourself writing up a document describing how to configure the
kernel for all noMMU platforms which will be read by many people with
varying degrees of English comprehension across the world, and how you
would describe to them, such that they clearly understood, how to
choose the right options.

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

Re: [PATCH 0/2] Cygnus Audio Driver

On Fri, Apr 03, 2015 at 12:33:12PM -0700, Scott Branden wrote:
> On 15-03-30 11:43 PM, Mark Brown wrote:
> >On Mon, Mar 30, 2015 at 08:16:22PM -0700, Scott Branden wrote:

> >>The audio PLL is embedded in the audio block and only used
> >>by the audio block. The audio PLL registers are also in the middle of
> >>the audio register map.

> >When you say it's only used by the audio block do you mean to say that
> >the audio block exposes no clock signals other than the bit and frame
> >clocks?

> The audio block exposes the MCLK in addition to the bit and frame clock.

OK, then it's going to need to be a clock provider at some point - the
clock will be going into external devices which are going to need to be
able to interact with the clock (for example, to get the rate).


signature.asc
Description: Digital signature

Re: [PATCH 4/4] spi: bcm-mspi: Add support to set serial baud clock rate

On Sat, Apr 04, 2015 at 12:12:59PM -0700, Florian Fainelli wrote:
> Le 02/04/2015 12:23, Jonathan Richardson a écrit :

> > +   /* Calculate SPBR if clock-frequency provided. */
> > +   if (of_property_read_u32(dev->of_node, "clock-frequency",
> > +   &desired_rate) >= 0) {
> > +   u32 spbr = clk_get_rate(data->clk) / (2 * desired_rate);

> Usually, specifying a "clock-frequency" property is done when there is
> no clock provider available, yet we take this code path only if we could
> find a "mspi_clk" which sounds a litle weird.

> Once there is a proper "mspi_clk" clock, I would make it mandatory for
> the clock provider to be able to provide the rate as well?

As far as I can tell it's already mandatory if the property is present -
it's taking the clock presented to the block and then using an internal
divider to bring that down to the desired rate.

We are missing error handling though.


signature.asc
Description: Digital signature

Re: [PATCH v3 1/2] pinctrl: Add driver for Alphascale asm9260 pinctrl

Am 06.04.2015 um 11:41 schrieb Paul Bolle:
> On Mon, 2015-04-06 at 10:38 +0200, Oleksij Rempel wrote:
>> If you won't to say: "You have a mismatch between header and
>> MODULE_LICENSE, please make sure it will match."
>> You saying some thing like this: "I was right last time. Make module
>> License like I saying."
> 
> No, that's not what I wrote.
>
>> I'm confuse, what is your actual point? Do you trying to prove some thing?
> 
> My point is that there's a mismatch between the license described in the
> comment at the top of this file and the ident used in the
> MODULE_LICENSE() macro. In my comments on v2 I wrote:
> By the way, you probably want to use "GPL v2" as the license ident
> [...].
> 
> In this v3 I noticed the same mismatch (which was not surprising because
> you already stated that "GPL" actually did match what's stated at the
> comment in the top of this file). Therefor I wrote:
> So only "GPL v2" matches what's found in the comment at top of this
> file.
> 
> There now seem to be a few options:
> - change either the comment at the top of this file or the license ident
> used in MODULE_LICENSE() to make them actually match;
> - show that I misread the comment at top of this file;
> - or show that my reading of module.h is incorrect.

Ok, thank you for your review.

i send new version of patch with fixing header license to "v2 and later".


> (Another option would be a patch that somehow merges the "GPL" and "GPL
> v2" license idents. That patch would put an end to discussions like the
> one we're having here. I'm _not_ volunteering to submit it.)
> 
> Thanks,
> 
> 
> Paul Bolle
> 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 1/2] pinctrl: Add driver for Alphascale asm9260 pinctrl

2015-04-06 Thread Paul Bolle

On Mon, 2015-04-06 at 10:38 +0200, Oleksij Rempel wrote:
> If you won't to say: "You have a mismatch between header and
> MODULE_LICENSE, please make sure it will match."
> You saying some thing like this: "I was right last time. Make module
> License like I saying."

No, that's not what I wrote.

> I'm confuse, what is your actual point? Do you trying to prove some thing?

My point is that there's a mismatch between the license described in the
comment at the top of this file and the ident used in the
MODULE_LICENSE() macro. In my comments on v2 I wrote:
By the way, you probably want to use "GPL v2" as the license ident
[...].

In this v3 I noticed the same mismatch (which was not surprising because
you already stated that "GPL" actually did match what's stated at the
comment in the top of this file). Therefor I wrote:
So only "GPL v2" matches what's found in the comment at top of this
file.

There now seem to be a few options:
- change either the comment at the top of this file or the license ident
used in MODULE_LICENSE() to make them actually match;
- show that I misread the comment at top of this file;
- or show that my reading of module.h is incorrect.

(Another option would be a patch that somehow merges the "GPL" and "GPL
v2" license idents. That patch would put an end to discussions like the
one we're having here. I'm _not_ volunteering to submit it.)

Thanks,

Paul Bolle

--
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 07/11] ARM: allow MULTIPLATFORM with !MMU

2015-04-06 Thread Stefan Agner

On 2015-04-06 10:54, Russell King - ARM Linux wrote:
> On Mon, Apr 06, 2015 at 10:38:10AM +0200, Stefan Agner wrote:
>> We already prevent a kernel image which mixes V4/V4T/V5 and V6/V7. And
>> so we would do with V7M too. Just because it's in multiplatform doesn't
>> mean we need to mix things up.
> 
> I don't think you're getting what I'm saying at all... :(

It's not that I don't get it. I'm just arguing against it.

IMHO, it's wrong to create a parallel universe for v7M multiplatform...

Multiplatform as I understand it is mainly about selecting multiple SoC
_platforms_ but not necessarily multiple CPU platforms. It happens to
work well for V6/V7, but does not for others, and preventing
multiselection for incompatible CPU platforms is the way to prevent
creating such images.

> Please read the first bit of my replies again, where I say that we do
> _not_ want to remove the !MMU dependency from multiplatform.  This is
> something I feel _very_ strongly about, and something which I've written
> about many times on this list.

Ok, I don't have such a strong feel for multiplatform, it just feels a
bit better to me. I need a top level ARCH which is able to live with
!MMU. Will try the ARCH_SINGLE_ARMV7M approach then.

--
Stefan
--
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 0/2] Add driver and documentation for Alphascale asm9260 pinctrl

changes:
- v4. As Paul Bolle sugested, fixing License in the header.

Oleksij Rempel (2):
  pinctrl: Add driver for Alphascale asm9260 pinctrl
  pinctrl: asm9260: add pinctrl add device tree bindings documentation

 .../pinctrl/alphascale,asm9260-pinctrl.txt |  76 +++
 drivers/pinctrl/Kconfig|   8 +
 drivers/pinctrl/Makefile   |   1 +
 drivers/pinctrl/pinctrl-asm9260.c  | 733 +
 4 files changed, 818 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/alphascale,asm9260-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-asm9260.c

-- 
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 v4 1/2] pinctrl: Add driver for Alphascale asm9260 pinctrl

This patch adds driver for Alphascale asm9260 pinctrl support.
Alphascale asm9260t is SoC based on ARM926EJ (240MHz) in LQFP176 package.
On silicon are:
- 32MB SDRAM
- USB2.0 HS/OTG
- 2x CAN
- SD/MMC
- 5x Times/PWM
- 10x USART
- 24-channel DMA
- 2x i2c
- 2x SPI
- Quad SPI
- 10/100 Ethernet MAC
- Camera IF
- WD
- RTC
- i2s
- GPIO
- 12-bit A/D
- LCD IF
- 8-channel 12-bit ADC
- NAND

Signed-off-by: Oleksij Rempel 
---
 drivers/pinctrl/Kconfig   |   8 +
 drivers/pinctrl/Makefile  |   1 +
 drivers/pinctrl/pinctrl-asm9260.c | 733 ++
 3 files changed, 742 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-asm9260.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index d014f22..054ecbc 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -47,6 +47,14 @@ config PINCTRL_AS3722
  open drain configuration for the GPIO pins of AS3722 devices. It also
  supports the GPIO functionality through gpiolib.
 
+config PINCTRL_ASM9260
+   tristate "Pinctrl driver for Alphascale asm9260"
+   depends on MACH_ASM9260
+   select PINMUX
+   select GENERIC_PINCONF
+   help
+ Say Y here to enable the Alphascale asm9260 pinctrl driver
+
 config PINCTRL_BF54x
def_bool y if BF54x
select PINCTRL_ADI2
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index c030b3d..46ba7d1c 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -11,6 +11,7 @@ endif
 obj-$(CONFIG_GENERIC_PINCONF)  += pinconf-generic.o
 obj-$(CONFIG_PINCTRL_ADI2) += pinctrl-adi2.o
 obj-$(CONFIG_PINCTRL_AS3722)   += pinctrl-as3722.o
+obj-$(CONFIG_PINCTRL_ASM9260)  += pinctrl-asm9260.o
 obj-$(CONFIG_PINCTRL_BF54x)+= pinctrl-adi2-bf54x.o
 obj-$(CONFIG_PINCTRL_BF60x)+= pinctrl-adi2-bf60x.o
 obj-$(CONFIG_PINCTRL_AT91) += pinctrl-at91.o
diff --git a/drivers/pinctrl/pinctrl-asm9260.c 
b/drivers/pinctrl/pinctrl-asm9260.c
new file mode 100644
index 000..2bd72d1
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-asm9260.c
@@ -0,0 +1,733 @@
+/*
+ * Pinctrl driver for the Alphascale ASM9260 SoC
+ *
+ * Copyright (c) 2014, Oleksij Rempel 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "pinctrl-utils.h"
+
+/* pinctrl register */
+#define IOCON_PIO0_0   0x
+/* only two modes are supported NONE and PULL UP */
+#define IOCON_MODE_SHIFT   3
+#define IOCON_MODE_MASK(0x3 << IOCON_MODE_SHIFT)
+/* Only GPIO0_* pins support pull up. */
+#define IOCON_MODE_PULL_UP (0x2 << IOCON_MODE_SHIFT)
+/* Only GPIO0_* pins don't support pull down. */
+#define IOCON_MODE_PULL_DOWN   (0x1 << IOCON_MODE_SHIFT)
+#define IOCON_MODE_NONE(0x0 << IOCON_MODE_SHIFT)
+/* up to 8 functions per pin */
+#define IOCON_PINMUX_MASK  (0x7 << 0)
+
+#define MUX_OFFSET(bank, pin)  ((bank) * 32 + (pin) * 4)
+
+enum asm9260_mux {
+   ASM9260_MUX_na = -1,
+
+   ASM9260_MUX_gpio0,
+   ASM9260_MUX_cam0,
+   ASM9260_MUX_can0,
+   ASM9260_MUX_can1,
+   ASM9260_MUX_ct0,
+   ASM9260_MUX_ct1,
+   ASM9260_MUX_ct2,
+   ASM9260_MUX_ct3,
+   ASM9260_MUX_i2c0,
+   ASM9260_MUX_i2c1,
+   ASM9260_MUX_i2s0,
+   ASM9260_MUX_i2s1,
+   ASM9260_MUX_jtag,
+   ASM9260_MUX_lcd0,
+   ASM9260_MUX_lcd_if0,
+   ASM9260_MUX_mc,
+   ASM9260_MUX_mc0,
+   ASM9260_MUX_mii0,
+   ASM9260_MUX_nand0,
+   ASM9260_MUX_outclk,
+   ASM9260_MUX_qei0,
+   ASM9260_MUX_qspi0,
+   ASM9260_MUX_rmii0,
+   ASM9260_MUX_sd0,
+   ASM9260_MUX_spi0,
+   ASM9260_MUX_spi1,
+   ASM9260_MUX_uart0,
+   ASM9260_MUX_uart1,
+   ASM9260_MUX_uart2,
+   ASM9260_MUX_uart3,
+   ASM9260_MUX_uart4,
+   ASM9260_MUX_uart5,
+   ASM9260_MUX_uart6,
+   ASM9260_MUX_uart7,
+   ASM9260_MUX_uart8,
+   ASM9260_MUX_uart9,
+};
+
+struct asm9260_function {
+   const char  *name;
+   const char  **groups;
+   unsigned intngroups;
+};
+
+#define FUNCTION(mux)  \
+   [(ASM9260_MUX_ ## mux)] = { \
+   .name = #mux,   \
+   .groups = NULL, \
+   .ngroups = 0,   \
+   }
+
+static struct asm9260_function asm9260_functions[] = {
+   FUNCTION(gpio0),
+   FUNCTION(cam0),
+   FUNCTION(can0),
+   FUNCTION(can1),
+   FUNCTION(ct0),
+   FUNCTION(ct1),
+   FUNCTION(ct2),
+   FUNCTION(ct3),
+   FUNCTION(i2c0),
+   FUNCTION(i2c1),
+   FUNCTION(i2s0),
+   FUNCTION(i2s1),
+   FUNCTION(jtag),
+

[PATCH v4 2/2] pinctrl: asm9260: add pinctrl add device tree bindings documentation

Add device tree bindings documentation for Alphascale asm9260 pin controller

Signed-off-by: Oleksij Rempel 
---
 .../pinctrl/alphascale,asm9260-pinctrl.txt | 76 ++
 1 file changed, 76 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/alphascale,asm9260-pinctrl.txt

diff --git 
a/Documentation/devicetree/bindings/pinctrl/alphascale,asm9260-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/alphascale,asm9260-pinctrl.txt
new file mode 100644
index 000..dbeea4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/alphascale,asm9260-pinctrl.txt
@@ -0,0 +1,76 @@
+* Alphascale ASM9260 SoC pinctrl core driver
+
+The pinctrl driver enables Alphascale ASM9260 to configure pin multiplexing
+to a specific function.
+
+Required properties for pinctrl driver:
+- compatible: "alphascale,asm9260-pinctrl"
+- reg: Register base of the MPP block and length.
+- clocks: clock ids.
+- clock-names:
+   * 1 "ahb" : AHB gating clock.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+The pin configuration nodes act as a container for an arbitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin or a list of pins. This configuration can include the
+mux function to select on those pin(s), and various pin configuration
+parameters, as listed below.
+
+SUBNODES:
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function.
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pin configuration subnode:
+pins   - the list of pins that properties in the node
+ apply to (either this or "groups" has to be
+ specified)
+function   - the mux function to select
+bias-disable   - disable any pin bias
+bias-pull-up   - pull up the pin. Supported only on GPIO0_* pins.
+bias-pull-down - pull down the pin. Supported on all pins except of 
GPIO0_*.
+
+Examples:
+
+pinctrl: pinctrl@80044000 {
+   compatible = "alphascale,asm9260-pinctrl";
+   reg = <0x80044000 0x400>;
+   clocks = <&acc CLKID_AHB_IOCONFIG>;
+   clock-names = "ahb";
+
+nand_fc0_pins_a: nand_fc0 {
+nand_main_gr {
+pins = "GPIO11_0", "GPIO11_1", "GPIO11_2",
+   "GPIO11_3", "GPIO11_4", "GPIO11_6",
+   "GPIO12_0", "GPIO12_1", "GPIO12_2",
+   "GPIO12_3", "GPIO12_4", "GPIO12_5",
+   "GPIO12_6", "GPIO12_7";
+function = "nand0";
+bias-disable;
+};
+};
+};
+
+nand_controller0 {
+status = "okay";
+#address-cells = <1>;
+#size-cells = <1>;
+nand-ecc-strength = <4>;
+nand-ecc-step-size = <512>;
+nand-max-chips = <1>;
+nand-on-flash-bbt;
+
+pinctrl-names = "default";
+pinctrl-0 = <&nand_fc0_pins_a>;
+};
-- 
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 v4 07/11] ARM: allow MULTIPLATFORM with !MMU

2015-04-06 Thread Russell King - ARM Linux

On Mon, Apr 06, 2015 at 10:38:10AM +0200, Stefan Agner wrote:
> We already prevent a kernel image which mixes V4/V4T/V5 and V6/V7. And
> so we would do with V7M too. Just because it's in multiplatform doesn't
> mean we need to mix things up.

I don't think you're getting what I'm saying at all... :(

Please read the first bit of my replies again, where I say that we do
_not_ want to remove the !MMU dependency from multiplatform.  This is
something I feel _very_ strongly about, and something which I've written
about many times on this list.

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

Re: [PATCH v4 07/11] ARM: allow MULTIPLATFORM with !MMU

2015-04-06 Thread Stefan Agner

On 2015-04-06 10:15, Russell King - ARM Linux wrote:
> On Mon, Apr 06, 2015 at 01:50:17AM +0200, Stefan Agner wrote:
>> On 2015-04-06 00:44, Russell King - ARM Linux wrote:
>> > On Mon, Apr 06, 2015 at 12:19:43AM +0200, Stefan Agner wrote:
>> >> On 2015-04-05 18:10, Russell King - ARM Linux wrote:
>> >> > config ARM_SINGLE_ARMV7M
>> >> > bool "ARM architecture v7M compliant (Cortex-M0/M3/M4) SoC"
>> >> > depends on !MMU
>> >> > select ARM_NVIC
>> >> > ... etc ...
>> >>
>> >> I guess that would be ARCH_SINGLE_ARMV7M?
>> >
>> > No, I meant ARM_SINGLE_xxx
>> >
>> >> > which then allows a /multiplatform/ v7M kernel to be built, allowing the
>> >> > selection of EFM32, SOC_VF610, and any other v7M compliant SoC.
>> >>
>> >> In my view, that wouldn't end up being much different than what that
>> >> patchset is doing:
>> >
>> > It's different.  It's different because we are _not_ enabling 
>> > multiplatform.
>> > Multiplatform brings with it all the MMU-full stuff that we don't want on
>> > !MMU.
>>
>> You mean config symbols? There are 2-3 config symbols we don't want with
>> ARCH_MULTI_V7M and we have to exclude. But there would be also a
>> duplication of some already given by multiplatform when creating a new
>> top level config symbol...
> 
> Let me repeat: enabling multiplatform with !MMU is wrong.  It allows
> you to build totally incompatible machines together that will never
> boot.  It will cause users headaches when they try to build for something
> only to find that they've got a bunch if incompatible other platforms
> or other symbols enabled too.  Then they've got to work out how to
> disable those, and that's not easy with the abuse that "select" gets.
> 
>> > You're thinking far too specifically about V7M here.  We have other !MMU
>> > CPUs, such as ARM946 and ARM940 which are older generation mmuless CPUs.
>> >
>> > The problem with the ARCH_MULTI_V7M approach is that they're V4T and V5
>> > CPUs, and we _really_ don't want to enable ARCH_MULTI_V4T and
>> > ARCH_MULTI_V5.  If we did that, we'll allow _every_ V4T and V5
>> > multiplatform to be selected, whether they're compatible with nommu
>> > or not - and whether they're compatible with each other or not.
>>
>> Just from a selection view, ARM946 and ARM940 would still _not_ be
>> selectable because this change makes ARCH_MULTI_V4T/V5 being dependent
>> on MMU.
> 
> Thanks for telling me something I already know, and already have a patch
> to fix.
> 
>> > So, that kind of solution _doesn't_ scale to what we _once_ already
>> > allowed.
>> >
>> >> As far as I can tell, this is already the case with that patchset.
>> >
>> > What I'm trying to do here is to fix the cockup that the multiplatform
>> > conversion has created with previous generation noMMU and restore it
>> > back to where it should be without excluding the newer stuff from it.
>>
>> Would be a partial revert (remove ARCH_MULTI_* from CPU_ARM940T and
>> CPU_ARM946E) of dc680b989d51 ("ARM: fix multiplatform allmodcompile") be
>> the right thing to do then? Given that ARCH_MULTI_V4T/V5 is MMU
>> dependent, those CPU's will not be selected even when building the
>> integrator multiplatform image... However, due to the selection
>> limitations outlined above, this would only be cosmetic anyway.
> 
> You've identified the problem that I ran into... I already have this
> fixed, thanks.
> 
>> > What you're interested in is just the newer stuff.  You're approaching
>> > the problem from a different angle and thinking that your solution is
>> > the best.  I'm saying it has deficiencies.
>>
>> When keeping the old CPU's out of multiplatform game properly, what
>> would speak against ARCH_MULTI_V7M? I still think if we allow a
>> multiplatform v7M image, it is cleaner to align that to the MMU
>> multiplatform stuff.
>>
>> Maybe I don't really get the grasp of ARM_SINGLE_ARMV7M. In my
>> understanding it would be a new top level config symbol which kind of
>> merges ARCH_MULTIPLATFORM and ARCH_MULTI_V7M.
> 
> Exactly, but without the ability to select the other ARCH_MULTI_* symbols
> along with ARCH_MULTI_V7M.
> 
>> It is not my goal to enable !MMU on MULTIARCH per se. It's just that
>> when enabling V7M with ARCH_MULTIPLATFORM, it makes it easier to enable
>> the Cortex-M4 for the HMP platforms on those multiplatform only SoC's.
>> When creating a new config symbol on a high level, this advantage is
>> gone... I then could also create a top level ARCH_MXCV7M, which selects
>> multiplatform only ARCH_MXC.
> 
> No, you'd have a top level ARCH_SINGLE_ARMV7M.  You would then be
> able to select the MXC V7M platforms along side any other V7M platform
> because the V7M platforms share the same basic memory layout.
>
> What you couldn't do is include _both_ support for Cortex-A9 and
> Cortex-M4 in one image - the two are incompatible because they have
> different physical address space layouts.

We already prevent a kernel image which mixes V4/V4T/V5 and V6/V7. And
so w

Re: [PATCH v3 1/2] pinctrl: Add driver for Alphascale asm9260 pinctrl