[PATCH v4 2/2] devicetree: Add Cadence WDT devicetree bindings documentation

[Harini Katakam]

Add cadence-wdt bindings documentation.

Signed-off-by: Harini Katakam 
---

v4 changes:
- Change name of property "reset" to "reset-on-timeout".
- Use cdns compatible string in example.
- Improve description of clocks and interrupts.

v3 changes:
- Change reset property type and improve description.
- Improve description of clocks and interrupts.
- Use watchdog@ in the example.
- Use only cdns compatible string for now.

v2:
No changes

---
 .../devicetree/bindings/watchdog/cadence-wdt.txt   |   24 
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/cadence-wdt.txt

diff --git a/Documentation/devicetree/bindings/watchdog/cadence-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/cadence-wdt.txt
new file mode 100644
index 000..c3a36ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/cadence-wdt.txt
@@ -0,0 +1,24 @@
+Zynq Watchdog Device Tree Bindings
+---
+
+Required properties:
+- compatible   : Should be "cdns,wdt-r1p2".
+- clocks   : This is pclk (APB clock).
+- interrupts   : This is wd_irq - watchdog timeout interrupt.
+- interrupt-parent : Must be core interrupt controller.
+
+Optional properties
+- reset-on-timeout : If this property exists, then a reset is done
+ when watchdog times out.
+- timeout-sec  : Watchdog timeout value (in seconds).
+
+Example:
+   watchdog@f8005000 {
+   compatible = "cdns,wdt-r1p2";
+   clocks = <&clkc 45>;
+   interrupt-parent = <&intc>;
+   interrupts = <0 9 1>;
+   reg = <0xf8005000 0x1000>;
+   reset-on-timeout;
+   timeout-sec = <10>;
+   };
-- 
1.7.9.5

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

[PATCH v4 1/2] watchdog: Add Cadence WDT driver

[Harini Katakam]

Add Cadence WDT driver. This is used by Xilinx Zynq.

Signed-off-by: Harini Katakam 
---

v4 changes:
- Change name of property "reset" to "reset-on-timeout".

v3 changes:
- Make rst a boolean and use of_property_read_boolean.
- Use only cdns compatible string. If customization is required in the
  future, xlnx compatible string can be added.

v2 changes:
- Update IO helpers.
- Use dev_dbg instead of dev_info where possible.
- Use watchdog_init_timeout
- Spinlock for restart register where missing.
- Change order of probe to move reboot notifier register to the end
- Remove unecessary comments
- Do clk_prepare_enabel and clk_disable_unprepare in resume/suspend
  respectively.
- There is an input from dts to decide whether internal reset should be
  enabled or not. When this is enabled, reset happens wutomatically when
  counter reaches zero. In case this is not enabled, a message is disaplayed
  to indicate that the watchdog has timed out. Elaborated this message
  to describe the above.

---
 drivers/watchdog/Kconfig   |7 +
 drivers/watchdog/Makefile  |1 +
 drivers/watchdog/cadence_wdt.c |  516 
 3 files changed, 524 insertions(+)
 create mode 100644 drivers/watchdog/cadence_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 76dd541..adf5110 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -147,6 +147,13 @@ config AT91SAM9X_WATCHDOG
  Watchdog timer embedded into AT91SAM9X and AT91CAP9 chips. This will
  reboot your system when the timeout is reached.
 
+config CADENCE_WATCHDOG
+   tristate "Cadence Watchdog Timer"
+   select WATCHDOG_CORE
+   help
+ Say Y here if you want to include support for the watchdog
+ timer in the Xilinx Zynq.
+
 config 21285_WATCHDOG
tristate "DC21285 watchdog"
depends on FOOTBRIDGE
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 468c320..bae2fb0 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
 obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
 obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
 obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
+obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o
 obj-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o
 obj-$(CONFIG_TWL4030_WATCHDOG) += twl4030_wdt.o
 obj-$(CONFIG_21285_WATCHDOG) += wdt285.o
diff --git a/drivers/watchdog/cadence_wdt.c b/drivers/watchdog/cadence_wdt.c
new file mode 100644
index 000..5927c0a
--- /dev/null
+++ b/drivers/watchdog/cadence_wdt.c
@@ -0,0 +1,516 @@
+/*
+ * Cadence WDT driver - Used by Xilinx Zynq
+ *
+ * Copyright (C) 2010 - 2014 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CDNS_WDT_DEFAULT_TIMEOUT   10
+/* Supports 1 - 516 sec */
+#define CDNS_WDT_MIN_TIMEOUT   1
+#define CDNS_WDT_MAX_TIMEOUT   516
+
+/* Restart key */
+#define CDNS_WDT_RESTART_KEY 0x1999
+
+/* Counter register access key */
+#define CDNS_WDT_REGISTER_ACCESS_KEY 0x0092
+
+/* Counter value divisor */
+#define CDNS_WDT_COUNTER_VALUE_DIVISOR 0x1000
+
+/* Clock prescaler value and selection */
+#define CDNS_WDT_PRESCALE_64   64
+#define CDNS_WDT_PRESCALE_512  512
+#define CDNS_WDT_PRESCALE_4096 4096
+#define CDNS_WDT_PRESCALE_SELECT_641
+#define CDNS_WDT_PRESCALE_SELECT_512   2
+#define CDNS_WDT_PRESCALE_SELECT_4096  3
+
+/* Input clock frequency */
+#define CDNS_WDT_CLK_10MHZ 1000
+#define CDNS_WDT_CLK_75MHZ 7500
+
+/* Counter maximum value */
+#define CDNS_WDT_COUNTER_MAX 0xFFF
+
+static int wdt_timeout = CDNS_WDT_DEFAULT_TIMEOUT;
+static int nowayout = WATCHDOG_NOWAYOUT;
+
+module_param(wdt_timeout, int, 0);
+MODULE_PARM_DESC(wdt_timeout,
+"Watchdog time in seconds. (default="
+__MODULE_STRING(CDNS_WDT_DEFAULT_TIMEOUT) ")");
+
+module_param(nowayout, int, 0);
+MODULE_PARM_DESC(nowayout,
+"Watchdog cannot be stopped once started (default="
+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+/**
+ * struct cdns_wdt - Watchdog device structure
+ * @regs: baseaddress of device
+ * @rst: reset flag
+ * @clk: struct clk * of a clock source
+ * @prescaler: for saving prescaler value
+ * @ctrl_clksel: counter clock prescaler selection
+ * @io_lock: spinlock for IO register access
+ * @cdns_wdt_device: watchdog device structure
+ * @cdns_wdt_notifier: notifier structure
+ *
+ * Structure containing parameters specific to cadence watchdog.
+ */
+struct cdns_wdt {
+   void __iomem*regs;
+   boolrst;
+   

Re: [PATCH 29/35] arm: omap: intc: switch over to linear irq domain

[Tony Lindgren]

* Felipe Balbi  [140730 09:23]:
> Hi,
> 
> On Wed, Jul 30, 2014 at 10:45:41AM -0500, Nishanth Menon wrote:
> > On Wed, Jul 30, 2014 at 9:40 AM, Felipe Balbi  wrote:
> > > HI,
> > >
> > > On Tue, Jul 29, 2014 at 11:04:21PM -0700, Tony Lindgren wrote:
> > >> * Felipe Balbi  [140729 09:36]:
> > >> > Hi,
> > >> >
> > >> > On Tue, Jul 29, 2014 at 10:40:57AM -0500, Felipe Balbi wrote:
> > >> > > On Tue, Jul 29, 2014 at 08:20:52AM -0700, Tony Lindgren wrote:
> > >> > > > * Felipe Balbi  [140729 07:18]:
> > >> > > > > Hi,
> > >> > > > >
> > >> > > > > On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote:
> > >> > > > > > * Felipe Balbi  [140728 14:19]:
> > >> > > > > > > now that we don't need to support legacy board-files,
> > >> > > > > > > we can completely switch over to a linear irq domain
> > >> > > > > > > and make use of irq_alloc_domain_generic_chips() to
> > >> > > > > > > allocate all generic irq chips for us.
> > >> > > > > >
> > >> > > > > > This patch seems to somehow break off-idle for omap3
> > >> > > > > > where it no longer wakes up.
> > >> > > > >
> > >> > > > > Sure your bisection is correct ? This patch just switches from 
> > >> > > > > legacy
> > >> > > > > irq domain to linear irq domain.
> > >> > > >
> > >> > > > Yes, I tried it a few times. Just enabling
> > >> > > > retention idle hangs too with this patch.
> > >> > > >
> > >> > > > Maybe it's omap3_prcm_irq_setup that relies on
> > >> > > > 11 + OMAP_INTC_START? There may be other such issues
> > >> > >
> > >> > > lol.
> > >> > >
> > >> > > OMAP4 has the same nonsense.
> > >> >
> > >> > made me think why (if) OMAP4 works with that same setup. Does wake from
> > >> > OFF work with OMAP4 ?
> > >>
> > >> Not without similar changes, omap4+ has the same issue.. There's a RFC
> > >> series from Nishant to fix some of this, and Tero is moving the PRCM
> > >> into a driver.
> > >>
> > >> > Anyway, here's a quick little hack to check if that's the reason for 
> > >> > the
> > >> > regression:
> > >>
> > >> OK yeah that's along the same lines with Nishant's RFC series in thread
> > >> "[RFC PATCH 0/7] ARM: OMAP4+: PRM: minor cleanups and dt support of
> > >> interrupts"
> > >>
> > >> FYI, it did not compile, needs to include linux/of_irq.h. But yes,
> > >
> > > I might have sent the wrong version as I had that same build error and
> > > fixed it localy.
> > >
> > >> it fixes the regression for me, Also now the whole series works for
> > >> me :)
> > >
> > > good to know.
> > >
> > > What do you want to do now ? Wait for PRCM to become a driver ? Wait for
> > > Nishanth's series to get accepted ? I guess the same thing could be done
> > > for OMAP3 and AM33, then we would have a chance of having working wake
> > > from idle with the new irqchip.
> > 
> > I can repost the current series as it stands now once 17-rc1 comes out
> > (without the build failure ofcourse).. if that helps to move it out of
> > RFC status.
> 
> That'd be great. It would be ever greater if you could add support for
> OMAP3 on that too.

Yeah sounds good to me. Tero, does that work OK for your PRCM changes?

Regards,

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

[PATCH] mmc: dw_mmc: add support for RK3288

[Addy Ke]

This patch focuses on clock setting for RK3288 mmc controller.

In RK3288 mmc controller, CLKDIV register can only be set 0 or 1,
and if DDR 8bit mode, CLKDIV register must be set 1.

Reported-by Doug Anderson 
Suggested-by: Jaehoon Chung 
Suggested-by: Doug Anderson 
Signed-off-by: Addy Ke 
---
changes since v1:
- dw_mci_rk3288_setup_clock: do not call clk_get_rate(), just use the
  host->bus_hz which is already called by dw_mmc.c, suggested by Jaehoon Chung

changes since v2:
- merge from ChromiumOS tree, fix up clock settting bug, 
  which cause DDR50 mode for emmc not to work, reported by Doug Anderson
- remove MMC_TIMING_UHS_DDR50 condition, because on RK3288 only emmc can work
  in 8bit mode, suggested by Doug Anderson

 .../devicetree/bindings/mmc/rockchip-dw-mshc.txt   |  6 ++-
 drivers/mmc/host/dw_mmc-pltfm.c| 56 +-
 2 files changed, 58 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
index c559f3f..c327c2d 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
@@ -10,12 +10,14 @@ extensions to the Synopsys Designware Mobile Storage Host 
Controller.
 Required Properties:
 
 * compatible: should be
-   - "rockchip,rk2928-dw-mshc": for Rockchip RK2928 and following
+   - "rockchip,rk2928-dw-mshc": for Rockchip RK2928 and following,
+   before RK3288
+   - "rockchip,rk3288-dw-mshc": for Rockchip RK3288
 
 Example:
 
rkdwmmc0@1220 {
-   compatible = "rockchip,rk2928-dw-mshc";
+   compatible = "rockchip,rk3288-dw-mshc";
reg = <0x1220 0x1000>;
interrupts = <0 75 0>;
#address-cells = <1>;
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index d4a47a9..b547f7a 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -21,17 +21,67 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "dw_mmc.h"
 #include "dw_mmc-pltfm.h"
 
+#define RK3288_CLKGEN_DIV  2
+
 static void dw_mci_pltfm_prepare_command(struct dw_mci *host, u32 *cmdr)
 {
*cmdr |= SDMMC_CMD_USE_HOLD_REG;
 }
 
-static const struct dw_mci_drv_data rockchip_drv_data = {
+static int dw_mci_rk3288_setup_clock(struct dw_mci *host)
+{
+   host->bus_hz /= RK3288_CLKGEN_DIV;
+
+   return 0;
+}
+
+static void dw_mci_rk3288_set_ios(struct dw_mci *host, struct mmc_ios *ios)
+{
+   int ret;
+   unsigned int cclkin;
+   u32 bus_hz;
+
+   /*
+* cclkin: source clock of mmc controller.
+* bus_hz: card interface clock generated by CLKGEN.
+* bus_hz = cclkin / RK3288_CLKGEN_DIV;
+* ios->clock = (div == 0) ? bus_hz : (bus_hz / (2 * div))
+*
+* Note: div can only be 0 or 1
+*   if DDR50 8bit mode(only emmc work in 8bit mode),
+*   div must be set 1
+*/
+   if ((ios->bus_width == MMC_BUS_WIDTH_8) &&
+   (ios->timing == MMC_TIMING_MMC_DDR52))
+   cclkin = 2 * ios->clock * RK3288_CLKGEN_DIV;
+   else
+   cclkin = ios->clock * RK3288_CLKGEN_DIV;
+
+   ret = clk_set_rate(host->ciu_clk, cclkin);
+   if (ret)
+   dev_warn(host->dev, "failed to set rate %uHz\n", ios->clock);
+
+   bus_hz = clk_get_rate(host->ciu_clk) / RK3288_CLKGEN_DIV;
+   if (bus_hz != host->bus_hz) {
+   host->bus_hz = bus_hz;
+   /* force dw_mci_setup_bus() */
+   host->current_speed = 0;
+   }
+}
+
+static const struct dw_mci_drv_data rk2928_drv_data = {
+   .prepare_command= dw_mci_pltfm_prepare_command,
+};
+
+static const struct dw_mci_drv_data rk3288_drv_data = {
.prepare_command= dw_mci_pltfm_prepare_command,
+   .set_ios= dw_mci_rk3288_set_ios,
+   .setup_clock= dw_mci_rk3288_setup_clock,
 };
 
 static const struct dw_mci_drv_data socfpga_drv_data = {
@@ -95,7 +145,9 @@ EXPORT_SYMBOL_GPL(dw_mci_pltfm_pmops);
 static const struct of_device_id dw_mci_pltfm_match[] = {
{ .compatible = "snps,dw-mshc", },
{ .compatible = "rockchip,rk2928-dw-mshc",
-   .data = &rockchip_drv_data },
+   .data = &rk2928_drv_data },
+   { .compatible = "rockchip,rk3288-dw-mshc",
+   .data = &rk3288_drv_data },
{ .compatible = "altr,socfpga-dw-mshc",
.data = &socfpga_drv_data },
{},
-- 
1.8.3.2


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

Re: [Patch v4] input: drv260x: Add TI drv260x haptics driver

[Dmitry Torokhov]

Hi Dan,

On Wed, Jul 30, 2014 at 09:14:40AM -0500, Dan Murphy wrote:
> Add the TI drv260x haptics/vibrator driver.
> This device uses the input force feedback
> to produce a wave form to driver an
> ERM or LRA actuator device.
> 
> The initial driver supports the devices
> real time playback mode.  But the device
> has additional wave patterns in ROM.
> 
> This functionality will be added in
> future patchsets.
> 
> Product data sheet is located here:
> http://www.ti.com/product/drv2605
> 
> Signed-off-by: Dan Murphy 
> ---
> 
> v4 - Convert regulator to devm, added error checking where required,
> updated bindings doc, moved dt parsing to separate call and made platform
> data the first data point, moved vibrator enable and mode programming from
> play entry to worker thread, added user check and input mutex in 
> suspend/resume
> calls, moved platform data to individual file and into include platform-data 
> directory,
> removed file names from file headers - 
> https://patchwork.kernel.org/patch/4642221/
> v3 - Updated binding doc, changed to memless device, updated input alloc to
> devm, removed mutex locking, add sanity checks for mode and library - 
> https://patchwork.kernel.org/patch/4635421/
> v2 - Fixed binding doc and patch headline - 
> https://patchwork.kernel.org/patch/4619641/

Thank you for making changes, just a few more small nits from me and if
Mark is OK with the bindings then I will merge it.

...

> +
> +
> + if (haptics->mode < DRV260X_LRA_MODE ||
> + haptics->mode > DRV260X_ERM_MODE) {
> + dev_err(&client->dev,
> + "Vibrator mode is invalid: %i\n",
> + haptics->mode);
> + return -EINVAL;

Indentation for the body is wrong here.

> + }
> + 
> + if (haptics->library < DRV260X_LIB_SEL_DEFAULT ||
> + haptics->library > DRV260X_LIB_F) {
> + dev_err(&client->dev,
> + "Library value is invalid: %i\n", 
> haptics->library);
> + return -EINVAL;

Here as well

> + }   
> +
> + haptics->regulator = devm_regulator_get(&client->dev, "vbat");
> + if (IS_ERR(haptics->regulator)) {
> + ret = PTR_ERR(haptics->regulator);
> + dev_err(&client->dev,
> + "unable to get regulator, error: %d\n", ret);
> + goto err_regulator;

Here and below you can return directly from the probe function, there is
no need keeping "empty" labels.

> + }
> +
> + haptics->enable_gpio = devm_gpiod_get(&client->dev, "enable");
> + if (IS_ERR(haptics->enable_gpio)) {
> + ret = PTR_ERR(haptics->enable_gpio);
> + if (ret != -ENOENT && ret != -ENOSYS)
> + goto err_gpio;
> +
> + haptics->enable_gpio = NULL;
> + } else {
> + gpiod_direction_output(haptics->enable_gpio, 1);
> + }
> +
> + haptics->input_dev = devm_input_allocate_device(&client->dev);
> + if (haptics->input_dev == NULL) {
> + dev_err(&client->dev, "Failed to allocate input device\n");
> + ret = -ENOMEM;
> + goto err_input_alloc;
> + }
> +
> + haptics->input_dev->name = "drv260x:haptics";
> + haptics->input_dev->dev.parent = client->dev.parent;
> + haptics->input_dev->close = drv260x_close;
> + input_set_drvdata(haptics->input_dev, haptics);
> + input_set_capability(haptics->input_dev, EV_FF, FF_RUMBLE);
> +
> + ret = input_ff_create_memless(haptics->input_dev, NULL,
> +   drv260x_haptics_play);
> + if (ret < 0) {
> + dev_err(&client->dev, "input_ff_create() failed: %d\n",
> + ret);
> + goto err_ff_create;
> + }
> +
> + INIT_WORK(&haptics->work, drv260x_worker);
> +
> + haptics->client = client;
> + i2c_set_clientdata(client, haptics);
> +
> + haptics->regmap = devm_regmap_init_i2c(client, &drv260x_regmap_config);
> + if (IS_ERR(haptics->regmap)) {
> + ret = PTR_ERR(haptics->regmap);
> + dev_err(&client->dev, "Failed to allocate register map: %d\n",
> + ret);
> + goto err_regmap;
> + }
> +
> + drv260x_init(haptics);

I believe we should abort if init fails.

> +
> + ret = input_register_device(haptics->input_dev);
> + if (ret < 0) {
> + dev_err(&client->dev, "couldn't register input device: %d\n",
> + ret);
> + goto err_iff;
> + }
> + return 0;
> +
> +err_iff:
> +err_regmap:
> +err_ff_create:
> +err_input_alloc:
> +err_gpio:
> +err_regulator:
> + return ret;
> +}
> +
> +static int drv260x_remove(struct i2c_client *client)
> +{
> + struct drv260x_data *haptics = i2c_get_clientdata(client);
> +
> + cancel_work_sync(&haptics->work);
> +
> + regmap_write(haptics->regmap, DRV260X_MODE, DRV260X_STANDBY);
> + 

[PATCHv9 4/5] ARM: dts: socfpga: unuse the slot-node and deprecate the supports-highspeed for dw-mmc

[Jaehoon Chung]

dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And "supports-highspeed" property in dw-mmc is deprecated.
"supports-highspeed" property can be replaced with "cap-sd/mmc-highspeed".

Signed-off-by: Jaehoon Chung 
Reviewed-by: Tushar Behera 
Reviewed-by: Ulf Hansson 
Acked-by: Seungwon Jeon 
Acked-by: Dinh Nguyen 
---
 arch/arm/boot/dts/socfpga_arria5.dtsi   |9 +++--
 arch/arm/boot/dts/socfpga_cyclone5.dtsi |9 +++--
 arch/arm/boot/dts/socfpga_vt.dts|9 +++--
 3 files changed, 9 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/socfpga_arria5.dtsi 
b/arch/arm/boot/dts/socfpga_arria5.dtsi
index 12d1c2c..468fc4c 100644
--- a/arch/arm/boot/dts/socfpga_arria5.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria5.dtsi
@@ -29,13 +29,10 @@
 
dwmmc0@ff704000 {
num-slots = <1>;
-   supports-highspeed;
broken-cd;
-
-   slot@0 {
-   reg = <0>;
-   bus-width = <4>;
-   };
+   bus-width = <4>;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
};
 
sysmgr@ffd08000 {
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dtsi 
b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
index bf51182..1ee03c4 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dtsi
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
@@ -30,13 +30,10 @@
 
dwmmc0@ff704000 {
num-slots = <1>;
-   supports-highspeed;
broken-cd;
-
-   slot@0 {
-   reg = <0>;
-   bus-width = <4>;
-   };
+   bus-width = <4>;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
};
 
ethernet@ff702000 {
diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
index 09792b4..f9345e0 100644
--- a/arch/arm/boot/dts/socfpga_vt.dts
+++ b/arch/arm/boot/dts/socfpga_vt.dts
@@ -43,13 +43,10 @@
 
dwmmc0@ff704000 {
num-slots = <1>;
-   supports-highspeed;
broken-cd;
-
-   slot@0 {
-   reg = <0>;
-   bus-width = <4>;
-   };
+   bus-width = <4>;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
};
 
ethernet@ff70 {
-- 
1.7.9.5

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

[PATCHv9 2/5] mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed

[Jaehoon Chung]

Almost all SoCs use one slot per host controller.
(Even if controller can support the multiple slot, Recommend to use one slot 
per host controller.)
Don't use the slot-node and deprecate the "supports-highspeed" property.
Instead, use the cap-mmc/sd-highspeed.

Signed-off-by: Jaehoon Chung 
Reviewed-by: Tushar Behera 
Reviewed-by: Ulf Hansson 
Tested-by: Sachin Kamat 
Acked-by: Seungwon Jeon 
Reviewed-by: Doug Anderson 
---
 .../devicetree/bindings/mmc/exynos-dw-mshc.txt |   17 +
 .../devicetree/bindings/mmc/k3-dw-mshc.txt |   12 +---
 .../devicetree/bindings/mmc/synopsys-dw-mshc.txt   |   12 +---
 3 files changed, 15 insertions(+), 26 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
index 532b1d4..6cd3525 100644
--- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
@@ -46,13 +46,14 @@ Required Properties:
   - if CIU clock divider value is 0 (that is divide by 1), both tx and rx
 phase shift clocks should be 0.
 
-Required properties for a slot:
+Required properties for a slot (Deprecated - Recommend to use one slot per 
host):
 
 * gpios: specifies a list of gpios used for command, clock and data bus. The
   first gpio is the command line and the second gpio is the clock line. The
   rest of the gpios (depending on the bus-width property) are the data lines in
   no particular order. The format of the gpio specifier depends on the gpio
   controller.
+(Deprecated - Refer to 
Documentation/devicetree/binding/pinctrl/samsung-pinctrl.txt)
 
 Example:
 
@@ -69,21 +70,13 @@ Example:
 
dwmmc0@1220 {
num-slots = <1>;
-   supports-highspeed;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
broken-cd;
fifo-depth = <0x80>;
card-detect-delay = <200>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
-
-   slot@0 {
-   reg = <0>;
-   bus-width = <8>;
-   gpios = <&gpc0 0 2 0 3>, <&gpc0 1 2 0 3>,
-   <&gpc1 0 2 3 3>, <&gpc1 1 2 3 3>,
-   <&gpc1 2 2 3 3>, <&gpc1 3 2 3 3>,
-   <&gpc0 3 2 3 3>, <&gpc0 4 2 3 3>,
-   <&gpc0 5 2 3 3>, <&gpc0 6 2 3 3>;
-   };
+   bus-width = <8>;
};
diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
index e5bc49f..3b35449 100644
--- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
@@ -34,13 +34,11 @@ Example:
num-slots = <1>;
vmmc-supply = <&ldo12>;
fifo-depth = <0x100>;
-   supports-highspeed;
pinctrl-names = "default";
pinctrl-0 = <&sd_pmx_pins &sd_cfg_func1 &sd_cfg_func2>;
-   slot@0 {
-   reg = <0>;
-   bus-width = <4>;
-   disable-wp;
-   cd-gpios = <&gpio10 3 0>;
-   };
+   bus-width = <4>;
+   disable-wp;
+   cd-gpios = <&gpio10 3 0>;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
};
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 2d4a725..346c609 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -67,7 +67,8 @@ Optional properties:
 * card-detect-delay: Delay in milli-seconds before detecting card after card
   insert event. The default value is 0.
 
-* supports-highspeed: Enables support for high speed cards (up to 50MHz)
+* supports-highspeed (DEPRECATED): Enables support for high speed cards (up to 
50MHz)
+  (use "cap-mmc-highspeed" or "cap-sd-highspeed" 
instead)
 
 * broken-cd: as documented in mmc core bindings.
 
@@ -98,14 +99,11 @@ board specific portions as listed below.
clock-frequency = <4>;
clock-freq-min-max = <40 2>;
num-slots = <1>;
-   supports-highspeed;
broken-cd;
fifo-depth = <0x80>;
card-detect-delay = <200>;
vmmc-supply = <&buck8>;
-
-   slot@0 {
-   reg = <0>;
-   bus-width = <8>;
-   };
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
};
-- 
1.7.9.5

--
To unsubscribe

[PATCHv9 5/5] ARM: dts: rockchip: unuse the slot-node and deprecate the supports-highspeed for dw-mmc

[Jaehoon Chung]

dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And "supports-highspeed" property in dw-mmc is deprecated.
"supports-highspeed" property can be replaced with "cap-sd/mmc-highspeed".

Signed-off-by: Jaehoon Chung 
Reviewed-by: Tushar Behera 
Reviewed-by: Ulf Hansson 
Reviewed-by: Heiko Stuebner 
Acked-by: Seungwon Jeon 
---
 arch/arm/boot/dts/rk3066a-bqcurie2.dts |   16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts 
b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
index afb3273..ecea889 100644
--- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
+++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
@@ -59,12 +59,8 @@
pinctrl-names = "default";
pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_cd &sd0_bus4>;
vmmc-supply = <&vcc_sd0>;
-
-   slot@0 {
-   reg = <0>;
-   bus-width = <4>;
-   disable-wp;
-   };
+   bus-width = <4>;
+   disable-wp;
};
 
dwmmc@10218000 { /* wifi */
@@ -74,12 +70,8 @@
 
pinctrl-names = "default";
pinctrl-0 = <&sd1_clk &sd1_cmd &sd1_bus4>;
-
-   slot@0 {
-   reg = <0>;
-   bus-width = <4>;
-   disable-wp;
-   };
+   bus-width = <4>;
+   disable-wp;
};
 
gpio-keys {
-- 
1.7.9.5

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

[PATCHv9 3/5] ARM: dts: exynos: unuse the slot-node and deprecate the supports-highspeed for dw-mmc

[Jaehoon Chung]

dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And "supports-highspeed" property in dw-mmc is deprecated.
"supports-highspeed" property can be replaced with "cap-sd/mmc-highspeed".

Signed-off-by: Jaehoon Chung 
Reviewed-by: Tushar Behera 
Reviewed-by: Ulf Hansson 
Tested-by: Sachin Kamat 
Acked-by: Seungwon Jeon 
Acked-by: Kukjin Kim 
---
 arch/arm/boot/dts/exynos4412-odroidx.dts  |8 ++--
 arch/arm/boot/dts/exynos4412-origen.dts   |8 ++--
 arch/arm/boot/dts/exynos4412-trats2.dts   |8 ++--
 arch/arm/boot/dts/exynos5250-arndale.dts  |   18 +
 arch/arm/boot/dts/exynos5250-cros-common.dtsi |   26 +++--
 arch/arm/boot/dts/exynos5250-smdk5250.dts |   18 +
 arch/arm/boot/dts/exynos5250-snow.dts |6 ++
 arch/arm/boot/dts/exynos5260-xyref5260.dts|   18 +
 arch/arm/boot/dts/exynos5410-smdk5410.dts |   18 +
 arch/arm/boot/dts/exynos5420-arndale-octa.dts |   16 ---
 arch/arm/boot/dts/exynos5420-peach-pit.dts|   16 ---
 arch/arm/boot/dts/exynos5420-smdk5420.dts |   16 ---
 arch/arm/boot/dts/exynos5800-peach-pi.dts |   16 ---
 13 files changed, 51 insertions(+), 141 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts 
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 31db28a..778aec6 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -45,17 +45,13 @@
status = "okay";
 
num-slots = <1>;
-   supports-highspeed;
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>;
-
-   slot@0 {
-   reg = <0>;
-   bus-width = <8>;
-   };
+   bus-width = <8>;
+   cap-mmc-highspeed;
};
 
regulator_p3v3 {
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts 
b/arch/arm/boot/dts/exynos4412-origen.dts
index e925c9f..de15114 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -137,17 +137,13 @@
status = "okay";
 
num-slots = <1>;
-   supports-highspeed;
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>;
-
-   slot@0 {
-   reg = <0>;
-   bus-width = <8>;
-   };
+   bus-width = <8>;
+   cap-mmc-highspeed;
};
 
codec@1340 {
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 7787844..65ab885 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -520,7 +520,6 @@
 
mmc@1255 {
num-slots = <1>;
-   supports-highspeed;
broken-cd;
non-removable;
card-detect-delay = <200>;
@@ -532,11 +531,8 @@
pinctrl-0 = <&sd4_clk &sd4_cmd &sd4_bus4 &sd4_bus8>;
pinctrl-names = "default";
status = "okay";
-
-   slot@0 {
-   reg = <0>;
-   bus-width = <8>;
-   };
+   bus-width = <8>;
+   cap-mmc-highspeed;
};
 
serial@1380 {
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..42a3590 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -401,7 +401,6 @@
mmc_0: mmc@1220 {
status = "okay";
num-slots = <1>;
-   supports-highspeed;
broken-cd;
card-detect-delay = <200>;
samsung,dw-mshc-ciu-div = <3>;
@@ -410,17 +409,13 @@
vmmc-supply = <&mmc_reg>;
pinctrl-names = "default";
pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
-
-   slot@0 {
-   reg = <0>;
-   bus-width = <8>;
-   };
+   bus-width = <8>;
+   cap-mmc-highspeed;
};
 
mmc_2: mmc@1222 {
status = "okay";
num-slots = <1>;
-   supports-highspeed;
card-detect-delay = <200>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
@@ -428,12 +423,9 @@
vmmc-

[PATCHv9 1/5] mmc: dw_mmc: Slot quirk "disable-wp" is deprecated.

[Jaehoon Chung]

Slot quirks "disable-wp" is deprecated.
Instead, use the host quirk "disable-wp".
(Because the slot-node is removed in dt-file.)

Signed-off-by: Jaehoon Chung 
Tested-by: Sachin Kamat 
Acked-by: Seungwon Jeon 
---
 drivers/mmc/host/dw_mmc.c  |   11 +--
 include/linux/mmc/dw_mmc.h |2 ++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..47b52cc 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -997,7 +997,8 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
int gpio_ro = mmc_gpio_get_ro(mmc);
 
/* Use platform get_ro function, else try on board write protect */
-   if (slot->quirks & DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT)
+   if ((slot->quirks & DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT) ||
+   (slot->host->quirks & DW_MCI_QUIRK_NO_WRITE_PROTECT))
read_only = 0;
else if (!IS_ERR_VALUE(gpio_ro))
read_only = gpio_ro;
@@ -2021,8 +2022,11 @@ static int dw_mci_of_get_slot_quirks(struct device *dev, 
u8 slot)
 
/* get quirks */
for (idx = 0; idx < ARRAY_SIZE(of_slot_quirks); idx++)
-   if (of_get_property(np, of_slot_quirks[idx].quirk, NULL))
+   if (of_get_property(np, of_slot_quirks[idx].quirk, NULL)) {
+   dev_warn(dev, "Slot quirk %s is deprecated\n",
+   of_slot_quirks[idx].quirk);
quirks |= of_slot_quirks[idx].id;
+   }
 
return quirks;
 }
@@ -2238,6 +2242,9 @@ static struct dw_mci_of_quirks {
{
.quirk  = "broken-cd",
.id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
+   }, {
+   .quirk  = "disable-wp",
+   .id = DW_MCI_QUIRK_NO_WRITE_PROTECT,
},
 };
 
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index babaea9..29ce014 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -213,6 +213,8 @@ struct dw_mci_dma_ops {
 #define DW_MCI_QUIRK_HIGHSPEED BIT(2)
 /* Unreliable card detection */
 #define DW_MCI_QUIRK_BROKEN_CARD_DETECTION BIT(3)
+/* No write protect */
+#define DW_MCI_QUIRK_NO_WRITE_PROTECT  BIT(4)
 
 /* Slot level quirks */
 /* This slot has no write protect */
-- 
1.7.9.5

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

[PATCHv9 0/5] ARM: remove the sub-node and deprecate supports-highspeed property for dwmmc.

[Jaehoon Chung]

Since used the mmc_of_parse(), didn't parse the sub-node.
So we can remove the sub-node, because almost SoC used the only one card per a 
host.
And supports-highspeed can be replaced with "cap-mmc/sd-highspeed" property.

Changelog V9:
- Fix typos.
- Relocated the warning message.
- Change patch's sequence.
Changelog V8:
- Add the warning message to notice that slot-node was removed.
(As Doug's suggestion)
Changelog V7:
- Fixed typo and modified the commit message.
Changelog V6:
- Fixed Wrong bit control for host's quirks and rename.
- Add "Acked-by" for each SoC maintainers.
Changelog V5:
- Rebased on v3.16-rc4.
- Add Acked-by.
Changelog V4:
- Fix the checkpatch error.
Changelog V3:
- Fix the wrong bus-width value.
- Use the slot->host->quirks instead of brq->quirks.
- Add tested-by and reviewd-by.
Changelog V2:
- Add the "mmc: dw_mmc: replace "disable-wp" from slot's quirks to 
host's quirk"


Jaehoon Chung (5):
  mmc: dw_mmc: Slot quirk "disable-wp" is deprecated.
  mmc: dw_mmc: modify the dt-binding for removing slot-node and
supports-highspeed
  ARM: dts: exynos: unuse the slot-node and deprecate the
supports-highspeed for dw-mmc
  ARM: dts: socfpga: unuse the slot-node and deprecate the
supports-highspeed for dw-mmc
  ARM: dts: rockchip: unuse the slot-node and deprecate the
supports-highspeed for dw-mmc

 .../devicetree/bindings/mmc/exynos-dw-mshc.txt |   17 -
 .../devicetree/bindings/mmc/k3-dw-mshc.txt |   12 -
 .../devicetree/bindings/mmc/synopsys-dw-mshc.txt   |   12 -
 arch/arm/boot/dts/exynos4412-odroidx.dts   |8 ++
 arch/arm/boot/dts/exynos4412-origen.dts|8 ++
 arch/arm/boot/dts/exynos4412-trats2.dts|8 ++
 arch/arm/boot/dts/exynos5250-arndale.dts   |   18 --
 arch/arm/boot/dts/exynos5250-cros-common.dtsi  |   26 ++--
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |   18 --
 arch/arm/boot/dts/exynos5250-snow.dts  |6 ++---
 arch/arm/boot/dts/exynos5260-xyref5260.dts |   18 --
 arch/arm/boot/dts/exynos5410-smdk5410.dts  |   18 --
 arch/arm/boot/dts/exynos5420-arndale-octa.dts  |   16 +++-
 arch/arm/boot/dts/exynos5420-peach-pit.dts |   16 +++-
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |   16 +++-
 arch/arm/boot/dts/exynos5800-peach-pi.dts  |   16 +++-
 arch/arm/boot/dts/rk3066a-bqcurie2.dts |   16 +++-
 arch/arm/boot/dts/socfpga_arria5.dtsi  |9 +++
 arch/arm/boot/dts/socfpga_cyclone5.dtsi|9 +++
 arch/arm/boot/dts/socfpga_vt.dts   |9 +++
 drivers/mmc/host/dw_mmc.c  |   11 +++--
 include/linux/mmc/dw_mmc.h |2 ++
 22 files changed, 90 insertions(+), 199 deletions(-)

-- 
1.7.9.5

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

Re: [PATCH v2 RESEND 3/4] drivers: dma-coherent: add initialization from device tree

[Marek Szyprowski]

Hello,

On 2014-07-31 01:49, Grant Likely wrote:

On Tue, Jul 29, 2014 at 11:33 PM, Marek Szyprowski
 wrote:

Hello,


On 2014-07-29 23:54, Grant Likely wrote:

On Mon, 14 Jul 2014 10:28:06 +0200, Marek Szyprowski
 wrote:

Initialization procedure of dma coherent pool has been split into two
parts, so memory pool can now be initialized without assigning to
particular struct device. Then initialized region can be assigned to
more than one struct device. To protect from concurent allocations from
different devices, a spinlock has been added to dma_coherent_mem
structure. The last part of this patch adds support for handling
'shared-dma-pool' reserved-memory device tree nodes.

Signed-off-by: Marek Szyprowski 

I think this looks okay. It isn't in my area of expertise though.
Comments below.


---
   drivers/base/dma-coherent.c | 137
++--
   1 file changed, 118 insertions(+), 19 deletions(-)

diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index 7d6e84a51424..7185a4f247e1 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -14,11 +14,14 @@ struct dma_coherent_mem {
 int size;
 int flags;
 unsigned long   *bitmap;
+   spinlock_t  spinlock;
   };
   -int dma_declare_coherent_memory(struct device *dev, phys_addr_t
phys_addr,
-   dma_addr_t device_addr, size_t size, int
flags)
+static int dma_init_coherent_memory(phys_addr_t phys_addr, dma_addr_t
device_addr,
+size_t size, int flags,
+struct dma_coherent_mem **mem)

This is a bit odd. Why wouldn't you return the dma_mem pointer directly
instead of passing in a **mem argument?


Because this function (as a direct successor of dma_declare_coherent_memory)
doesn't
return typical error codes, but some custom values like DMA_MEMORY_MAP,
DMA_MEMORY_IO
or zero (which means failure). I wanted to avoid confusion with typical
error
handling path and IS_ERR/ERR_PTR usage used widely in other functions. This
probably
should be unified with the rest of kernel some day, but right now I wanted
to keep
the patch simple and easy to review.



   {
+   struct dma_coherent_mem *dma_mem = NULL;
 void __iomem *mem_base = NULL;
 int pages = size >> PAGE_SHIFT;
 int bitmap_size = BITS_TO_LONGS(pages) * sizeof(long);
@@ -27,27 +30,26 @@ int dma_declare_coherent_memory(struct device *dev,
phys_addr_t phys_addr,
 goto out;
 if (!size)
 goto out;
-   if (dev->dma_mem)
-   goto out;
-
-   /* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN
*/
 mem_base = ioremap(phys_addr, size);
 if (!mem_base)
 goto out;
   - dev->dma_mem = kzalloc(sizeof(struct dma_coherent_mem),
GFP_KERNEL);
-   if (!dev->dma_mem)
+   dma_mem = kzalloc(sizeof(struct dma_coherent_mem), GFP_KERNEL);
+   if (!dma_mem)
 goto out;
-   dev->dma_mem->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
-   if (!dev->dma_mem->bitmap)
+   dma_mem->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+   if (!dma_mem->bitmap)
 goto free1_out;
   - dev->dma_mem->virt_base = mem_base;
-   dev->dma_mem->device_base = device_addr;
-   dev->dma_mem->pfn_base = PFN_DOWN(phys_addr);
-   dev->dma_mem->size = pages;
-   dev->dma_mem->flags = flags;
+   dma_mem->virt_base = mem_base;
+   dma_mem->device_base = device_addr;
+   dma_mem->pfn_base = PFN_DOWN(phys_addr);
+   dma_mem->size = pages;
+   dma_mem->flags = flags;
+   spin_lock_init(&dma_mem->spinlock);
+
+   *mem = dma_mem;
 if (flags & DMA_MEMORY_MAP)
 return DMA_MEMORY_MAP;
@@ -55,12 +57,51 @@ int dma_declare_coherent_memory(struct device *dev,
phys_addr_t phys_addr,
 return DMA_MEMORY_IO;
  free1_out:
-   kfree(dev->dma_mem);
+   kfree(dma_mem);
out:
 if (mem_base)
 iounmap(mem_base);
 return 0;
   }
+
+static void dma_release_coherent_memory(struct dma_coherent_mem *mem)
+{
+   if (!mem)
+   return;
+   iounmap(mem->virt_base);
+   kfree(mem->bitmap);
+   kfree(mem);
+}
+
+static int dma_assign_coherent_memory(struct device *dev,
+ struct dma_coherent_mem *mem)
+{
+   if (dev->dma_mem)
+   return -EBUSY;
+
+   dev->dma_mem = mem;
+   /* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN
*/
+
+   return 0;
+}
+
+int dma_declare_coherent_memory(struct device *dev, phys_addr_t
phys_addr,
+   dma_addr_t device_addr, size_t size, int
flags)
+{
+   struct dma_coherent_mem *mem;
+   int ret;
+
+   ret = dma_init_coherent_memory(phys_addr, device_addr, size,
flags,
+  &mem);
+   if

Re: [2/2] powerpc/fsl-booke: Add initial T1042RDB_PI board support

[Scott Wood]

On Wed, 2014-07-30 at 23:37 -0500, Jain Priyanka-B32167 wrote:
> 
> -Original Message-
> From: Wood Scott-B07421 
> Sent: Thursday, July 31, 2014 1:43 AM
> To: Jain Priyanka-B32167
> Cc: devicetree@vger.kernel.org; linuxppc-...@lists.ozlabs.org; Aggrwal 
> Poonam-B10812; Kushwaha Prabhakar-B32579
> Subject: Re: [2/2] powerpc/fsl-booke: Add initial T1042RDB_PI board support
> 
> On Wed, Jul 09, 2014 at 09:54:11AM +0530, Priyanka Jain wrote:
> > diff --git a/arch/powerpc/boot/dts/t104xrdb.dtsi 
> > b/arch/powerpc/boot/dts/t104xrdb.dtsi
> > index 9aaefa5..e7e765f 100644
> > --- a/arch/powerpc/boot/dts/t104xrdb.dtsi
> > +++ b/arch/powerpc/boot/dts/t104xrdb.dtsi
> > @@ -57,7 +57,8 @@
> > };
> >  
> > cpld@3,0 {
> > -   compatible = "fsl,t1040rdb-cpld","fsl,t1042rdb-cpld";
> > +   compatible = "fsl,t1040rdb-cpld","fsl,t1042rdb-cpld",
> > +   "fsl,t1042rdb_pi-cpld";
> > reg = <3 0 0x300>;
> > };
> > };
> 
> What's going on here?  This file is used by all three boards.  If you need to 
> distinguish one board's CPLD from another's, you'll have to do it somewhere 
> else.  If the CPLDs are exactly the same and no distinction needs to be made, 
> then you don't need three compatible strings.  Even then, you may wish to 
> specify the exact board as the first compatible string, but again you'll need 
> to patch that in elsewhere so that it actually matches the board
> .
> As the register set of CPLD for all three boards is same, I am thinking of 
> replacing this with t104srdb-cpld
> compatible = "fsl,t104xrdb-cpld","
> Is this OK?

No.  Wildcards aren't allowed in compatible strings, because you never
know what other devices might exist in the future that match the
wildcard.

If the CPLD logic is truly 100% identical, just pick one of the three to
be the canonical name.

-Scott


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

RE: [2/2] powerpc/fsl-booke: Add initial T1042RDB_PI board support

[Priyanka Jain]

-Original Message-
From: Wood Scott-B07421 
Sent: Thursday, July 31, 2014 1:43 AM
To: Jain Priyanka-B32167
Cc: devicetree@vger.kernel.org; linuxppc-...@lists.ozlabs.org; Aggrwal 
Poonam-B10812; Kushwaha Prabhakar-B32579
Subject: Re: [2/2] powerpc/fsl-booke: Add initial T1042RDB_PI board support

On Wed, Jul 09, 2014 at 09:54:11AM +0530, Priyanka Jain wrote:
> diff --git a/arch/powerpc/boot/dts/t104xrdb.dtsi 
> b/arch/powerpc/boot/dts/t104xrdb.dtsi
> index 9aaefa5..e7e765f 100644
> --- a/arch/powerpc/boot/dts/t104xrdb.dtsi
> +++ b/arch/powerpc/boot/dts/t104xrdb.dtsi
> @@ -57,7 +57,8 @@
>   };
>  
>   cpld@3,0 {
> - compatible = "fsl,t1040rdb-cpld","fsl,t1042rdb-cpld";
> + compatible = "fsl,t1040rdb-cpld","fsl,t1042rdb-cpld",
> + "fsl,t1042rdb_pi-cpld";
>   reg = <3 0 0x300>;
>   };
>   };

What's going on here?  This file is used by all three boards.  If you need to 
distinguish one board's CPLD from another's, you'll have to do it somewhere 
else.  If the CPLDs are exactly the same and no distinction needs to be made, 
then you don't need three compatible strings.  Even then, you may wish to 
specify the exact board as the first compatible string, but again you'll need 
to patch that in elsewhere so that it actually matches the board
.
As the register set of CPLD for all three boards is same, I am thinking of 
replacing this with t104srdb-cpld
compatible = "fsl,t104xrdb-cpld","
Is this OK?

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

[PATCH v2 1/4] Documentation: dt-bindings: add dt binding info for Rockchip dwc2

[Kever Yang]

This add necessary dwc2 binding documentation for Rockchip socs:
rk3066, rk3188 and rk3288

Signed-off-by: Kever Yang 
---

Changes in v2:
- Split out dr_mode and rk3288 bindings.
- add compatible "snps,dwc2" bingding info

 Documentation/devicetree/bindings/usb/dwc2.txt |3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
b/Documentation/devicetree/bindings/usb/dwc2.txt
index 801a284..6a87b27 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -4,6 +4,9 @@ Platform DesignWare HS OTG USB 2.0 controller
 Required properties:
 - compatible : One of:
   - brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC.
+  - rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc;
+  - "rockchip,rk3188-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3188 Soc;
+  - "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc;
   - snps,dwc2: A generic DWC2 USB controller with default parameters.
 - reg : Should contain 1 register range (address and length)
 - interrupts : Should contain 1 interrupt
-- 
1.7.9.5

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

[PATCH v2 4/4] ARM: dts: Enable USB otg and host1(dwc) on rk3288-evb

[Kever Yang]

USB otg port is the usb3.0 b-port on the board.
USB host1 port is the host A port nearby the otg port.

Signed-off-by: Kever Yang 
---

Changes in v2:
- evb patch added in version 2

 arch/arm/boot/dts/rk3288-evb.dtsi |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi 
b/arch/arm/boot/dts/rk3288-evb.dtsi
index da665f6..aa60a3d 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -83,5 +83,11 @@
uart4: serial@ff1c {
status = "okay";
};*/
+   &usb_otg {
+   status = "okay";
+   }
+   &usb_host1 {
+   status = "okay";
+   };
};
 };
-- 
1.7.9.5

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

[PATCH v2 0/4] Patches to add support for Rockchip dwc2 controller

[Kever Yang]

From: Kever Yang 

These patches to add support for dwc2 controller found in
Rockchip processors rk3066, rk3188 and rk3288,
and enable dts for rk3288 evb.

Changes in v2:
- Split out dr_mode and rk3288 bindings.
- add compatible "snps,dwc2" bingding info
- set most parameters as driver auto-detect
- change the node name from 'dwc2' to 'usb'
- evb patch added in version 2

Kever Yang (4):
  Documentation: dt-bindings: add dt binding info for Rockchip dwc2
  usb: dwc2: add compatible data for rockchip soc
  ARM: dts: add rk3288 dwc2 controller support
  ARM: dts: Enable USB otg and host1(dwc) on rk3288-evb

 Documentation/devicetree/bindings/usb/dwc2.txt |3 +++
 arch/arm/boot/dts/rk3288-evb.dtsi  |6 +
 arch/arm/boot/dts/rk3288.dtsi  |   20 
 drivers/usb/dwc2/platform.c|   29 
 4 files changed, 58 insertions(+)

-- 
1.7.9.5

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

[PATCH v2 3/4] ARM: dts: add rk3288 dwc2 controller support

[Kever Yang]

rk3288 has two kind of usb controller, this add the dwc2 controller
for otg and host1.

Controller can works with usb PHY default setting and Vbus on.

Signed-off-by: Kever Yang 
---

Changes in v2:
- change the node name from 'dwc2' to 'usb'

 arch/arm/boot/dts/rk3288.dtsi |   20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index abc51f5..9555857 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -646,5 +646,25 @@
clock-names = "baudclk", "apb_pclk";
status = "disabled";
};
+
+   usb_otg: usb@ff58 {
+   compatible = "rockchip,rk3288-usb", 
"rockchip,rk3066-usb",
+   "snps,dwc2";
+   reg = <0xff58 0x4>;
+   interrupts = ;
+   clocks = <&cru HCLK_OTG0>;
+   clock-names = "otg";
+   status = "disabled";
+   };
+
+   usb_host1: usb@ff54 {
+   compatible = "rockchip,rk3288-usb", 
"rockchip,rk3066-usb",
+   "snps,dwc2";
+   reg = <0xff54 0x4>;
+   interrupts = ;
+   clocks = <&cru HCLK_USBHOST1>;
+   clock-names = "otg";
+   status = "disabled";
+   };
};
 };
-- 
1.7.9.5

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

Re: [PATCH v2 1/2] Documentation: dt-bindings: add dt binding info for dwc2 dr_mode

[Doug Anderson]

Kever,

On Wed, Jul 30, 2014 at 5:29 PM, Kever Yang  wrote:
> Indicate that the generic dr_mode binding should be used for dwc2.
>
> Signed-off-by: Kever Yang 
> ---
>
> Changes in v2:
> - Split out dr_mode and rk3288 bindings.
>
>  Documentation/devicetree/bindings/usb/dwc2.txt |2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Doug Anderson 
--
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: ARC fails to boot on linux-next of 20140711

[Grant Likely]

On Sat, 26 Jul 2014 15:10:28 -0500, Rob Herring  wrote:
> On Sat, Jul 26, 2014 at 11:50 AM, Grant Likely
>  wrote:
> > On Sat, 26 Jul 2014 06:52:36 +, Vineet Gupta 
> >  wrote:
> >> Hi Rob,
> >>
> >> On Friday 25 July 2014 07:45 PM, Rob Herring wrote:
> >> > On Fri, Jul 25, 2014 at 6:02 AM, Vineet Gupta
> >> >  wrote:
> >> >> > Hi Grant,
> >> >> >
> >> >> > linux-next has a series for arc_uart (via tty tree) which converts it 
> >> >> > to generic
> >> >> > earlycon and specifies console via /chosen/stdout-path vs.  an 
> >> >> > explicit param in
> >> >> > /chose/bootargs
> >> >> >
> >> >> > 2014-06-24 9da433c0a0b5 ARC: [arcfpga] stdout-path now suffices for 
> >> >> > earlycon/console
> >> >> >
> >> >> > This relied on prev commit of yours (from linux next of 20140711), 
> >> >> > which seem to
> >> >> > have disappeared now.
> >> >> >
> >> >> > 2014-03-27 a9296cf2d0b6 of: Create of_console_check() for selecting a 
> >> >> > console
> >> >> > specified in /chosen
> >> >> > 2014-03-27 cfa9cacc5dd3 of: Enable console on serial ports specified 
> >> >> > by
> >> >> > /chosen/stdout-path
> >> >> >
> >> >> > Is there a specific reason for dropping these patches (or perhaps a 
> >> >> > merge to be
> >> >> > merged). I cherry-picked both but still doesn't work.
> >> >> >
> >> >> > Can you please advise next step forward, before I go off debugging 
> >> >> > with those
> >> >> > patches in.
> >> > There's an issue that if you have stdout-path and "earlycon" on the
> >> > command line, the kernel will switch to tty0 and disable the earlycon.
> >> >
> >> > This is the "fix", but I don't like adding the DT dependency into 
> >> > generic code:
> >> >
> >> > @@ -2382,7 +2386,7 @@ void register_console(struct console *newcon)
> >> > if (newcon->setup == NULL ||
> >> > newcon->setup(newcon, NULL) == 0) {
> >> > newcon->flags |= CON_ENABLED;
> >> > -   if (newcon->device) {
> >> > +   if (newcon->device  && !of_stdout) {
> >> > newcon->flags |= CON_CONSDEV;
> >> > preferred_console = 0;
> >> > }
> >>
> >> The DT settings relevant for ARC, which enable generic-earlycon and
> >> console-with-stdout-path are as follows
> >>
> >> chosen {
> >> bootargs = "earlycon";
> >> stdout-path = &arcuart0;
> >> };
> >>
> >> 
> >> arcuart0: serial@c0fc1000 {
> >> compatible = "snps,arc-uart";
> >>
> >> And it works w/o above hunk, provided the 2 patches from Grant exist in 
> >> linux-next
> >> which they don't at the moment. I'm pretty confused how the hunk above 
> >> comes into
> >> picture.
> >>
> >> And if not then I will have to get the ARC std-out patch reverted in 
> >> tty-next as
> >> it is broken.
> >
> > You need to revert it anyway, the dependency chain is broken. Just
> > because something is in linux-next doesn't mean it will be merged.
> > Dependencies must always be in the branch to which you commit.
> >
> > If that doesn't happen (like here) then bisecting is broken and the
> > dependencies may not actually get merged.
> >
> > When this happens, what you're supposed to do is tell the maintainers
> > what commits the patch depends on so that it can be applied to the
> > correct tree. In this case I could take it through my devicetree branch
> > that contains the console patches.
> >
> > If a patch depends on commits in several branches then it is a bit more
> > complex. What we usually do is create a new branch that merges in each
> > branch that is depended on, and then apply the commit on top of that.
> >
> > As for the console patches, I'm only going to be putting them back if I
> > can devise a good fix for the earlycon duplication issue.
> 
> There is also a simple work-around. You have to specify the console
> when you use earlycon. For example, you can add "earlycon
> console=ttyAMA0" instead of just earlycon. To summarize, this is the
> state of combinations of console params:
> 
> Working:
> stdout-path
> console=blah
> stdout-path + console=blah
> earlycon=blah
> 
> Not working:
> stdout-path + earlycon
> 
> Also, it is a developer only feature which is new. You will be aware
> of an issue because the earlycon starts output and then stops on
> switching to tty0 versus complete silence which could be anything.

Fair enough. Okay, I'm going to put it back into linux-next. The proper
fix can come later.

> There are other landmines in this area already. For example, setting
> earlycon on ARM will break the boot because an ioremap is attempted
> before paging_init. This is nothing new, but has always been the case
> if the 8250 driver was enabled.

We should not allow earlycon to be selectable on ARM until this is
fixed. Can you do a patch for this?

g.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the 

[PATCH RESEND v11 3/3] ASoC: fsl: add imx-es8328 machine driver

[Sean Cross]

This adds an initial machine driver for the ES8328 audio codec on Freescale
boards.  The driver supports headphones and an audio regulator for an onboard
speaker amp.

Signed-off-by: Sean Cross 
---
 .../devicetree/bindings/sound/imx-audio-es8328.txt |  60 ++
 sound/soc/fsl/Kconfig  |  14 ++
 sound/soc/fsl/Makefile |   2 +
 sound/soc/fsl/imx-es8328.c | 232 +
 4 files changed, 308 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-es8328.txt
 create mode 100644 sound/soc/fsl/imx-es8328.c

diff --git a/Documentation/devicetree/bindings/sound/imx-audio-es8328.txt 
b/Documentation/devicetree/bindings/sound/imx-audio-es8328.txt
new file mode 100644
index 000..07b68ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/imx-audio-es8328.txt
@@ -0,0 +1,60 @@
+Freescale i.MX audio complex with ES8328 codec
+
+Required properties:
+- compatible   : "fsl,imx-audio-es8328"
+- model: The user-visible name of this sound complex
+- ssi-controller   : The phandle of the i.MX SSI controller
+- jack-gpio: Optional GPIO for headphone jack
+- audio-amp-supply : Power regulator for speaker amps
+- audio-codec  : The phandle of the ES8328 audio codec
+- audio-routing: A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the
+connection's sink, the second being the connection's
+source. Valid names could be power supplies, ES8328
+pins, and the jacks on the board:
+
+   Power supplies:
+  * audio-amp
+
+   ES8328 pins:
+  * LOUT1
+  * LOUT2
+  * ROUT1
+  * ROUT2
+  * LINPUT1
+  * LINPUT2
+  * RINPUT1
+  * RINPUT2
+  * Mic PGA
+
+   Board connectors:
+  * Headphone
+  * Speaker
+  * Mic Jack
+- mux-int-port : The internal port of the i.MX audio muxer (AUDMUX)
+- mux-ext-port : The external port of the i.MX audio muxer (AUDMIX)
+
+Note: The AUDMUX port numbering should start at 1, which is consistent with
+hardware manual.
+
+Example:
+
+sound {
+   compatible = "fsl,imx-audio-es8328";
+   model = "imx-audio-es8328";
+   ssi-controller = <&ssi1>;
+   audio-codec = <&codec>;
+   jack-gpio = <&gpio5 15 0>;
+   audio-amp-supply = <®_audio_amp>;
+   audio-routing =
+   "Speaker", "LOUT2",
+   "Speaker", "ROUT2",
+   "Speaker", "audio-amp",
+   "Headphone", "ROUT1",
+   "Headphone", "LOUT1",
+   "LINPUT1", "Mic Jack",
+   "RINPUT1", "Mic Jack",
+   "Mic Jack", "Mic Bias";
+   mux-int-port = <1>;
+   mux-ext-port = <3>;
+};
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3793362..c0ace69 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -229,6 +229,20 @@ config SND_SOC_IMX_WM8962
  Say Y if you want to add support for SoC audio on an i.MX board with
  a wm8962 codec.
 
+config SND_SOC_IMX_ES8328
+   tristate "SoC Audio support for i.MX boards with the ES8328 codec"
+   depends on OF && (I2C || SPI)
+   select SND_SOC_ES8328_I2C if I2C
+   select SND_SOC_ES8328_SPI if SPI_MASTER
+   select SND_SOC_IMX_PCM_DMA
+   select SND_SOC_IMX_AUDMUX
+   select SND_SOC_FSL_SSI
+   select SND_SOC_FSL_UTILS
+   select SND_SOC_IMX_PCM_FIQ
+   help
+ Say Y if you want to add support for the ES8328 audio codec connected
+ via SSI/I2S over either SPI or I2C.
+
 config SND_SOC_IMX_SGTL5000
tristate "SoC Audio support for i.MX boards with sgtl5000"
depends on OF && I2C
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index db254e3..e561766 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -48,6 +48,7 @@ snd-soc-eukrea-tlv320-objs := eukrea-tlv320.o
 snd-soc-phycore-ac97-objs := phycore-ac97.o
 snd-soc-mx27vis-aic32x4-objs := mx27vis-aic32x4.o
 snd-soc-wm1133-ev1-objs := wm1133-ev1.o
+snd-soc-imx-es8328-objs := imx-es8328.o
 snd-soc-imx-sgtl5000-objs := imx-sgtl5000.o
 snd-soc-imx-wm8962-objs := imx-wm8962.o
 snd-soc-imx-spdif-objs := imx-spdif.o
@@ -57,6 +58,7 @@ obj-$(CONFIG_SND_SOC_EUKREA_TLV320) += snd-soc-eukrea-tlv320.o
 obj-$(CONFIG_SND_SOC_PHYCORE_AC97) += snd-soc-phycore-ac97.o
 obj-$(CONFIG_SND_SOC_MX27VIS_AIC32X4) += snd-soc-mx27vis-aic32x4.o
 obj-$(CONFIG_SND_MXC_SOC_WM1133_EV1) += snd-soc-wm1133-ev1.o
+obj-$(CONFIG_SND_SOC_IMX_ES8328) += snd-soc-imx-es8328.o
 obj-$(CONFIG_SND_SOC_IMX_SGTL50

[PATCH RESEND v11 2/3] ASoC: add es8328 codec driver

[Sean Cross]

Add a codec driver for the Everest ES8328.  It supports two separate audio
outputs and two separate audio inputs.

Signed-off-by: Sean Cross 
---
 Documentation/devicetree/bindings/sound/es8328.txt |  38 ++
 sound/soc/codecs/Kconfig   |  13 +
 sound/soc/codecs/Makefile  |   6 +
 sound/soc/codecs/es8328-i2c.c  |  60 ++
 sound/soc/codecs/es8328-spi.c  |  49 ++
 sound/soc/codecs/es8328.c  | 756 +
 sound/soc/codecs/es8328.h  | 314 +
 7 files changed, 1236 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/es8328.txt
 create mode 100644 sound/soc/codecs/es8328-i2c.c
 create mode 100644 sound/soc/codecs/es8328-spi.c
 create mode 100644 sound/soc/codecs/es8328.c
 create mode 100644 sound/soc/codecs/es8328.h

diff --git a/Documentation/devicetree/bindings/sound/es8328.txt 
b/Documentation/devicetree/bindings/sound/es8328.txt
new file mode 100644
index 000..30ea8a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/es8328.txt
@@ -0,0 +1,38 @@
+Everest ES8328 audio CODEC
+
+This device supports both I2C and SPI.
+
+Required properties:
+
+  - compatible : "everest,es8328"
+  - DVDD-supply : Regulator providing digital core supply voltage 1.8 - 3.6V
+  - AVDD-supply : Regulator providing analog supply voltage 3.3V
+  - PVDD-supply : Regulator providing digital IO supply voltage 1.8 - 3.6V
+  - IPVDD-supply : Regulator providing analog output voltage 3.3V
+  - clocks : A 22.5792 or 11.2896 MHz clock
+  - reg : the I2C address of the device for I2C, the chip select number for SPI
+
+Pins on the device (for linking into audio routes):
+
+  * LOUT1
+  * LOUT2
+  * ROUT1
+  * ROUT2
+  * LINPUT1
+  * RINPUT1
+  * LINPUT2
+  * RINPUT2
+  * Mic Bias
+
+
+Example:
+
+codec: es8328@11 {
+   compatible = "everest,es8328";
+   DVDD-supply = <®_3p3v>;
+   AVDD-supply = <®_3p3v>;
+   PVDD-supply = <®_3p3v>;
+   HPVDD-supply = <®_3p3v>;
+   clocks = <&clks 169>;
+   reg = <0x11>;
+};
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0b9571c..d30acec 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -56,6 +56,8 @@ config SND_SOC_ALL_CODECS
select SND_SOC_DA732X if I2C
select SND_SOC_DA9055 if I2C
select SND_SOC_BT_SCO
+   select SND_SOC_ES8328_SPI if SPI_MASTER
+   select SND_SOC_ES8328_I2C if I2C
select SND_SOC_ISABELLE if I2C
select SND_SOC_JZ4740_CODEC
select SND_SOC_LM4857 if I2C
@@ -396,6 +398,17 @@ config SND_SOC_DMIC
 config SND_SOC_HDMI_CODEC
tristate "HDMI stub CODEC"
 
+config SND_SOC_ES8328
+   tristate "Everest Semi ES8328 CODEC"
+
+config SND_SOC_ES8328_I2C
+   tristate
+   select SND_SOC_ES8328
+
+config SND_SOC_ES8328_SPI
+   tristate
+   select SND_SOC_ES8328
+
 config SND_SOC_ISABELLE
 tristate
 
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 1bd6e1c..d24cb62 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -48,6 +48,9 @@ snd-soc-da732x-objs := da732x.o
 snd-soc-da9055-objs := da9055.o
 snd-soc-bt-sco-objs := bt-sco.o
 snd-soc-dmic-objs := dmic.o
+snd-soc-es8328-objs := es8328.o
+snd-soc-es8328-i2c-objs := es8328-i2c.o
+snd-soc-es8328-spi-objs := es8328-spi.o
 snd-soc-isabelle-objs := isabelle.o
 snd-soc-jz4740-codec-objs := jz4740.o
 snd-soc-l3-objs := l3.o
@@ -215,6 +218,9 @@ obj-$(CONFIG_SND_SOC_DA732X)+= snd-soc-da732x.o
 obj-$(CONFIG_SND_SOC_DA9055)   += snd-soc-da9055.o
 obj-$(CONFIG_SND_SOC_BT_SCO)   += snd-soc-bt-sco.o
 obj-$(CONFIG_SND_SOC_DMIC) += snd-soc-dmic.o
+obj-$(CONFIG_SND_SOC_ES8328)   += snd-soc-es8328.o
+obj-$(CONFIG_SND_SOC_ES8328_I2C)+= snd-soc-es8328-i2c.o
+obj-$(CONFIG_SND_SOC_ES8328_SPI)+= snd-soc-es8328-spi.o
 obj-$(CONFIG_SND_SOC_ISABELLE) += snd-soc-isabelle.o
 obj-$(CONFIG_SND_SOC_JZ4740_CODEC) += snd-soc-jz4740-codec.o
 obj-$(CONFIG_SND_SOC_L3)   += snd-soc-l3.o
diff --git a/sound/soc/codecs/es8328-i2c.c b/sound/soc/codecs/es8328-i2c.c
new file mode 100644
index 000..aae410d
--- /dev/null
+++ b/sound/soc/codecs/es8328-i2c.c
@@ -0,0 +1,60 @@
+/*
+ * es8328-i2c.c  --  ES8328 ALSA SoC I2C Audio driver
+ *
+ * Copyright 2014 Sutajio Ko-Usagi PTE LTD
+ *
+ * Author: Sean Cross 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include "es8328.h"
+
+static const struct i2c_device_id es8328_id[] = {
+   { "everest,es8328", 0 },
+   { }
+};
+MODULE_DEVICE_TABLE(i2c, es8328_id);
+
+static const struct of_device_id es8328_of_match[] = {
+   { .compatible = "everest,es8328", },
+   { }
+};
+MODULE_DEVICE_TABLE(of, es8328_of_match);
+
+static int es8328_i2

[PATCH RESEND v11 1/3] devicetree: bindings: Add Everest Semicodunctor

[Sean Cross]

Everest Semiconductor makes audio codecs.

Signed-off-by: Sean Cross 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4d7f375..2d88c10 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -46,6 +46,7 @@ epfl  Ecole Polytechnique Fédérale de Lausanne
 epson  Seiko Epson Corp.
 estESTeem Wireless Modems
 eukrea  Eukréa Electromatique
+everestEverest Semiconductor Co. Ltd.
 excito Excito
 fslFreescale Semiconductor
 GEFanucGE Fanuc Intelligent Platforms Embedded Systems, Inc.
-- 
2.0.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 RESEND v11 0/3] Add ES8328 audio codec

[Sean Cross]

This patchset adds support for the Everest Semi ES8328 audio codec, used in
the Novena open source laptop.  It also adds support for using the es8328 on
IMX boards.

We write a machine driver rather than using simple-card because the machine
driver needs to support regulators for the speaker amps and as well as
supporting headphone jacks, in addition to the i.MX audmux routing.

Changes since v10:
- Minor documentation reformatting
- Minor spacing reformatting in sound/soc/fsl/imx-audio-es8328.c

Changes since v9:
- Minor formatting corrections
- Rework DAPM registers in es8328.h.  DAPM widgets use offsets, and the
  v9 patch turned snd_soc_write() calls into widgets without converting
  from i2c masks to offsets first.
- Rename DAC and ADC PLL to DLL, to reflect latest documentation.

Changes since v8:
- For the mclk ratios, move from an array to a lookup table, and rename
  the variable to be clearer.
- Move all CHIPPOWER accesses into DAPM supplies.
- Fix sloppy compile problems introduced in v8.
- Shut down clocks and supplies on suspend, and enable them on resume.
- Remove double set of ES8328_MASTERMODE_MSC.

Changes since v7:
- We now fetch the regulators in the device-level probe rather than
  in the ASoC-level probe.

Changes since v6:
- Minor clarification of AUDMUX in imx-audio-es8328.txt
- Use u32 instead of int in imx-es8328.c for int-mux and ext-mux
- Bounds checking on mux-int-port and mux-ext-port in imx-es8328.c
- Remove NULL checks before calling of_node_put()

Changes since v5:
- Removed empty imx_set_frequency function from imx-es8328.c
- Move the clock from imx-audio-es8328 to the es8328 codec itself
- Add support for 2x (22.5792 MHz) and 1x (11.2896 MHz) source clocks
- Restore registers on resume
- Document pins for ES8328, including input pins

Changes since v4:
- Simplify clock handling and use assigned-clock-parents
- Move the codec regulator from the machine driver to the codec
- Specify all four regulators, and require their presence
- Fix audio recording, such that it enables the PGA

Changes since v3:
- Add OF bindings for everest,es8328
- Add back in patch to add everest as a vendor prefix
- Give clocks more generic names
- Document required clocks in DT bindings document

Changes since v2:
- Change deemph to a bool, and update based on sample rate
- Replace value enums with regular enums
- Break SPI and I2C drivers into their own modules
- Rename everest,es8328 to es8328 as the module wasn't getting detected.
  Because of this, the patch to vendor-prefixes.txt has been dropped.

Changes since v1:
- Rename HP/Speaker to OUT1/OUT2
- Use DAPM widgets for startup/shutdown
- Add regulator support to machine driver

Sean Cross (3):
  devicetree: bindings: Add Everest Semicodunctor
  ASoC: add es8328 codec driver
  ASoC: fsl: add imx-es8328 machine driver

 Documentation/devicetree/bindings/sound/es8328.txt |  38 ++
 .../devicetree/bindings/sound/imx-audio-es8328.txt |  60 ++
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 sound/soc/codecs/Kconfig   |  13 +
 sound/soc/codecs/Makefile  |   6 +
 sound/soc/codecs/es8328-i2c.c  |  60 ++
 sound/soc/codecs/es8328-spi.c  |  49 ++
 sound/soc/codecs/es8328.c  | 756 +
 sound/soc/codecs/es8328.h  | 314 +
 sound/soc/fsl/Kconfig  |  14 +
 sound/soc/fsl/Makefile |   2 +
 sound/soc/fsl/imx-es8328.c | 232 +++
 12 files changed, 1545 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/es8328.txt
 create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-es8328.txt
 create mode 100644 sound/soc/codecs/es8328-i2c.c
 create mode 100644 sound/soc/codecs/es8328-spi.c
 create mode 100644 sound/soc/codecs/es8328.c
 create mode 100644 sound/soc/codecs/es8328.h
 create mode 100644 sound/soc/fsl/imx-es8328.c

-- 
2.0.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 v8 01/11] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs

[Brian Norris]

Hi Russell,

On Wed, Jul 30, 2014 at 10:26:35AM +0100, Russell King wrote:
> On Mon, Jul 21, 2014 at 02:07:56PM -0700, Brian Norris wrote:
> > +static DEFINE_SPINLOCK(boot_lock);
> > +
> > +static void brcmstb_secondary_init(unsigned int cpu)
> > +{
> > +   /*
> > +* Synchronise with the boot thread.
> > +*/
> > +   spin_lock(&boot_lock);
> > +   spin_unlock(&boot_lock);
> > +}
> > +
> > +static int brcmstb_boot_secondary(unsigned int cpu, struct task_struct 
> > *idle)
> > +{
> > +   /*
> > +* set synchronisation state between this boot processor
> > +* and the secondary one
> > +*/
> > +   spin_lock(&boot_lock);
> > +
> > +   /* Bring up power to the core if necessary */
> > +   if (brcmstb_cpu_get_power_state(cpu) == 0)
> > +   brcmstb_cpu_power_on(cpu);
> > +
> > +   brcmstb_cpu_boot(cpu);
> > +
> > +   /*
> > +* now the secondary core is starting up let it run its
> > +* calibrations, then wait for it to finish
> > +*/
> > +   spin_unlock(&boot_lock);
> 
> I've just read through this code (because it caused my allmodconfig to
> break) and spotted this.

Sorry about the allmodconfig problems. I never compile-tested with ARMv6
enabled. This look OK?

diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index f3665121729b..5ce82b4ba931 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_ARCH_BCM2835)+= board_bcm2835.o
 obj-$(CONFIG_ARCH_BCM_5301X)   += bcm_5301x.o
 
 ifeq ($(CONFIG_ARCH_BRCMSTB),y)
+CFLAGS_platsmp-brcmstb.o   += -march=armv7-a
 obj-y  += brcmstb.o
 obj-$(CONFIG_SMP)  += headsmp-brcmstb.o platsmp-brcmstb.o
 endif

> What function does boot_lock perform here?  Please, don't quote the
> comments (I know where the comments came from) but what I want to hear
> is your comments about why you decided to retain this.

You might glean a little more from my response to Rob, but I'm not sure
there was a good reason for retaining this. We do need to be sure the
CPU is fully powered online before bringing it out of reset, but the
spinlock seems overkill AFAICT.

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

Re: [PATCH v8 01/11] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs

[Brian Norris]

Hi Rob,

I appreciate your comments, but where were many of these 5 months ago on
the first 7 revisions? :)

On a practical note: v9 is already queued for 3.17. Should I send
patches for the 3.17 cycle (or later) to fixup some of these issues? Or
would you recommend pulling the patches out of Matt Porter's tree now,
and reintroducing for 3.18? (I would be much happier with the first.)

I do note that we at least need to fix allmodconfig ASAP; I'll reply to
Russell on that one.

On Wed, Jul 30, 2014 at 12:09:48PM -0500, Rob Herring wrote:
> On Mon, Jul 21, 2014 at 4:07 PM, Brian Norris  
> wrote:
> > From: Marc Carino 
> >
> > The BCM7xxx series of Broadcom SoCs are used primarily in set-top boxes.
> >
> > This patch adds machine support for the ARM-based Broadcom SoCs.
> >
> > Signed-off-by: Marc Carino 
> > Signed-off-by: Brian Norris 
> > ---
> >  arch/arm/configs/multi_v7_defconfig |   1 +
> >  arch/arm/mach-bcm/Kconfig   |  14 ++
> >  arch/arm/mach-bcm/Makefile  |   5 +
> >  arch/arm/mach-bcm/brcmstb.c |  28 +++
> >  arch/arm/mach-bcm/brcmstb.h |  19 ++
> >  arch/arm/mach-bcm/headsmp-brcmstb.S |  33 
> >  arch/arm/mach-bcm/platsmp-brcmstb.c | 363 
> > 
> >  7 files changed, 463 insertions(+)
> >  create mode 100644 arch/arm/mach-bcm/brcmstb.c
> >  create mode 100644 arch/arm/mach-bcm/brcmstb.h
> >  create mode 100644 arch/arm/mach-bcm/headsmp-brcmstb.S
> >  create mode 100644 arch/arm/mach-bcm/platsmp-brcmstb.c
> >
> > diff --git a/arch/arm/configs/multi_v7_defconfig 
> > b/arch/arm/configs/multi_v7_defconfig
> > index 534836497998..bf0df396a3cf 100644
> > --- a/arch/arm/configs/multi_v7_defconfig
> > +++ b/arch/arm/configs/multi_v7_defconfig
> > @@ -19,6 +19,7 @@ CONFIG_MACH_DOVE=y
> >  CONFIG_ARCH_BCM=y
> >  CONFIG_ARCH_BCM_MOBILE=y
> >  CONFIG_ARCH_BCM_5301X=y
> > +CONFIG_ARCH_BRCMSTB=y
> >  CONFIG_ARCH_BERLIN=y
> >  CONFIG_MACH_BERLIN_BG2=y
> >  CONFIG_MACH_BERLIN_BG2CD=y
> > diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> > index 41c839167e87..0073633e7699 100644
> > --- a/arch/arm/mach-bcm/Kconfig
> > +++ b/arch/arm/mach-bcm/Kconfig
> > @@ -87,4 +87,18 @@ config ARCH_BCM_5301X
> >   different SoC or with the older BCM47XX and BCM53XX based
> >   network SoC using a MIPS CPU, they are supported by 
> > arch/mips/bcm47xx
> >
> > +config ARCH_BRCMSTB
> > +   bool "Broadcom BCM7XXX based boards" if ARCH_MULTI_V7
> > +   depends on MMU
> 
> This was implied, but there are some patches from Arnd in this area.
> Does it really not build with !MMU?

I suppose it probably builds, it likely won't run. I can drop this line
and then reassess if ARCH_MULTIPLATFORM becomes buildable with !MMU.

> > +   select ARM_GIC
> 
> > +   select MIGHT_HAVE_PCI
> > +   select HAVE_SMP
> 
> At least HAVE_SMP is for sure, but I think both of these are selected already 
> .

You're correct. ARCH_MULTIPLATFORM selects MIGHT_HAVE_PCI and
ARCH_MULTI_V7 selects HAVE_SMP. I can look at dropping these.

> > +   select HAVE_ARM_ARCH_TIMER
> > +   help
> > + Say Y if you intend to run the kernel on a Broadcom ARM-based STB
> > + chipset.
> > +
> > + This enables support for Broadcom ARM-based set-top box chipsets,
> > + including the 7445 family of chips.
> > +
> >  endif
> > diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> > index 731292114975..f3665121729b 100644
> > --- a/arch/arm/mach-bcm/Makefile
> > +++ b/arch/arm/mach-bcm/Makefile
> > @@ -30,3 +30,8 @@ obj-$(CONFIG_ARCH_BCM2835)+= board_bcm2835.o
> >
> >  # BCM5301X
> >  obj-$(CONFIG_ARCH_BCM_5301X)   += bcm_5301x.o
> > +
> > +ifeq ($(CONFIG_ARCH_BRCMSTB),y)
> > +obj-y  += brcmstb.o
> > +obj-$(CONFIG_SMP)  += headsmp-brcmstb.o platsmp-brcmstb.o
> > +endif
> > diff --git a/arch/arm/mach-bcm/brcmstb.c b/arch/arm/mach-bcm/brcmstb.c
> > new file mode 100644
> > index ..60a5afa06ed7
> > --- /dev/null
> > +++ b/arch/arm/mach-bcm/brcmstb.c
> > @@ -0,0 +1,28 @@
> > +/*
> > + * Copyright (C) 2013-2014 Broadcom Corporation
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation version 2.
> > + *
> > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> > + * kind, whether express or implied; without even the implied warranty
> > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +static const char *brcmstb_match[] __initconst = {
> > +   "brcm,bcm7445",
> > +   "brcm,brcmstb",
> > +   NULL
> > +};
> > +
> > +DT_MACHINE_START(BRCMSTB, "Broadcom STB (Flattened Device Tree)")
> > +   .dt_compat  = brcmstb_match,
> 

[PATCH 4/6] dmaengine: rcar-dmac: Add device tree bindings documentation

[Simon Horman]

From: Laurent Pinchart 

Document the device tree bindings for the R-Car Generation 2 DMA
Controller (DMAC).

Cc: devicetree@vger.kernel.org
Signed-off-by: Laurent Pinchart 
Signed-off-by: Simon Horman 
---
 .../devicetree/bindings/dma/renesas,rcar-dmac.txt  | 98 ++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt

diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt 
b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
new file mode 100644
index 000..df0f48b
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
@@ -0,0 +1,98 @@
+* Renesas R-Car DMA Controller Device Tree bindings
+
+Renesas R-Car Generation 2 SoCs have have multiple multi-channel DMA
+controller instances named DMAC capable of serving multiple clients. Channels
+can be dedicated to specific clients or shared between a large number of
+clients.
+
+DMA clients are connected to the DMAC ports referenced by an 8-bit identifier
+called MID/RID.
+
+Each DMA client is connected to one dedicated port of the DMAC, identified by
+an 8-bit port number called the MID/RID. A DMA controller can thus serve up to
+256 clients in total. When the number of hardware channels is lower than the
+number of clients to be served, channels must be shared between multiple DMA
+clients. The association of DMA clients to DMAC channels is fully dynamic and
+not described in these device tree bindings.
+
+Required Properties:
+
+- compatible: must contain "renesas,rcar-dmac"
+
+- reg: base address and length of the registers block for the DMAC
+
+- interrupts: interrupt specifiers for the DMAC, one for each entry in
+  interrupt-names.
+- interrupt-names: one entry per channel, named "ch%u", where %u is the
+  channel number ranging from zero to the number of channels minus one.
+
+- clock-names: "fck" for the functional clock
+- clocks: a list of phandle + clock-specifier pairs, one for each entry
+  in clock-names.
+- clock-names: must contain "fck" for the functional clock.
+
+- #dma-cells: must be <1>, the cell specifies the MID/RID of the DMAC port
+  connected to the DMA client
+- dma-channels: number of DMA channels
+
+Example: R8A7790 (R-Car H2) SYS-DMACs
+
+   dmac0: dma-controller@e670 {
+   compatible = "renesas,rcar-dmac";
+   reg = <0 0xe670 0 0x2>;
+   interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH
+ 0 200 IRQ_TYPE_LEVEL_HIGH
+ 0 201 IRQ_TYPE_LEVEL_HIGH
+ 0 202 IRQ_TYPE_LEVEL_HIGH
+ 0 203 IRQ_TYPE_LEVEL_HIGH
+ 0 204 IRQ_TYPE_LEVEL_HIGH
+ 0 205 IRQ_TYPE_LEVEL_HIGH
+ 0 206 IRQ_TYPE_LEVEL_HIGH
+ 0 207 IRQ_TYPE_LEVEL_HIGH
+ 0 208 IRQ_TYPE_LEVEL_HIGH
+ 0 209 IRQ_TYPE_LEVEL_HIGH
+ 0 210 IRQ_TYPE_LEVEL_HIGH
+ 0 211 IRQ_TYPE_LEVEL_HIGH
+ 0 212 IRQ_TYPE_LEVEL_HIGH
+ 0 213 IRQ_TYPE_LEVEL_HIGH
+ 0 214 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-names = "error",
+   "ch0", "ch1", "ch2", "ch3",
+   "ch4", "ch5", "ch6", "ch7",
+   "ch8", "ch9", "ch10", "ch11",
+   "ch12", "ch13", "ch14";
+   clocks = <&mstp2_clks R8A7790_CLK_SYS_DMAC0>;
+   clock-names = "fck";
+   #dma-cells = <1>;
+   dma-channels = <15>;
+   };
+
+   dmac1: dma-controller@e672 {
+   compatible = "renesas,rcar-dmac";
+   reg = <0 0xe672 0 0x2>;
+   interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
+ 0 216 IRQ_TYPE_LEVEL_HIGH
+ 0 217 IRQ_TYPE_LEVEL_HIGH
+ 0 218 IRQ_TYPE_LEVEL_HIGH
+ 0 219 IRQ_TYPE_LEVEL_HIGH
+ 0 308 IRQ_TYPE_LEVEL_HIGH
+ 0 309 IRQ_TYPE_LEVEL_HIGH
+ 0 310 IRQ_TYPE_LEVEL_HIGH
+ 0 311 IRQ_TYPE_LEVEL_HIGH
+ 0 312 IRQ_TYPE_LEVEL_HIGH
+ 0 313 IRQ_TYPE_LEVEL_HIGH
+ 0 314 IRQ_TYPE_LEVEL_HIGH
+ 0 315 IRQ_TYPE_LEVEL_HIGH
+ 0 316 IRQ_TYPE_LEVEL_HIGH
+ 0 317 IRQ_TYPE_LEVEL_HIGH
+ 0 318 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-names = "error",
+   "ch0", "ch1", "ch2", "ch3",
+   "ch4", "ch5", "ch6", "ch7",
+

[PATCH v2 1/2] Documentation: dt-bindings: add dt binding info for dwc2 dr_mode

[Kever Yang]

Indicate that the generic dr_mode binding should be used for dwc2.

Signed-off-by: Kever Yang 
---

Changes in v2:
- Split out dr_mode and rk3288 bindings.

 Documentation/devicetree/bindings/usb/dwc2.txt |2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
b/Documentation/devicetree/bindings/usb/dwc2.txt
index 94cdc9b..eb80d7b 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -18,6 +18,8 @@ Optional properties:
 - phys: phy provider specifier
 - phy-names: shall be "usb2-phy"
 Refer to phy/phy-bindings.txt for generic phy consumer properties
+- dr_mode: shall be one of "host", "peripheral" and "otg"
+  Refer to usb/generic.txt
 
 Example:
 
-- 
1.7.9.5


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

[PATCH v2 0/2] Patches to add dr_mode for dwc2

[Kever Yang]

These two patches enable the dr_mode for the dwc2 usb
controller.  These are split from the patch series adding
rk3288 dwc2 support.

Changes in v2:
- Split out dr_mode and rk3288 bindings.
- put spaces around '+' operator
- expand the comment for dr_mode
- handle dr_mode is USB_DR_MODE_OTG

Kever Yang (2):
  Documentation: dt-bindings: add dt binding info for dwc2 dr_mode
  usb: dwc2: add dr_mode support for dwc2

 Documentation/devicetree/bindings/usb/dwc2.txt |2 ++
 drivers/usb/dwc2/core.c|   18 ++
 drivers/usb/dwc2/core.h|5 +
 drivers/usb/dwc2/platform.c|4 
 4 files changed, 29 insertions(+)

-- 
1.7.9.5


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

Re: ARC fails to boot on linux-next of 20140711

[Grant Likely]

On Mon, 28 Jul 2014 04:38:38 +, Vineet Gupta  
wrote:
> On Saturday 26 July 2014 10:21 PM, Grant Likely wrote:
> > On Sat, 26 Jul 2014 06:52:36 +, Vineet Gupta 
> >  wrote:
> >> Hi Rob,
> >>
> >> On Friday 25 July 2014 07:45 PM, Rob Herring wrote:
> >>> On Fri, Jul 25, 2014 at 6:02 AM, Vineet Gupta
> >>>  wrote:
> > Hi Grant,
> >
> > linux-next has a series for arc_uart (via tty tree) which converts it 
> > to generic
> > earlycon and specifies console via /chosen/stdout-path vs.  an explicit 
> > param in
> > /chose/bootargs
> >
> > 2014-06-24 9da433c0a0b5 ARC: [arcfpga] stdout-path now suffices for 
> > earlycon/console
> >
> > This relied on prev commit of yours (from linux next of 20140711), 
> > which seem to
> > have disappeared now.
> >
> > 2014-03-27 a9296cf2d0b6 of: Create of_console_check() for selecting a 
> > console
> > specified in /chosen
> > 2014-03-27 cfa9cacc5dd3 of: Enable console on serial ports specified by
> > /chosen/stdout-path
> >
> > Is there a specific reason for dropping these patches (or perhaps a 
> > merge to be
> > merged). I cherry-picked both but still doesn't work.
> >
> > Can you please advise next step forward, before I go off debugging with 
> > those
> > patches in.
> >>> There's an issue that if you have stdout-path and "earlycon" on the
> >>> command line, the kernel will switch to tty0 and disable the earlycon.
> >>>
> >>> This is the "fix", but I don't like adding the DT dependency into generic 
> >>> code:
> >>>
> >>> @@ -2382,7 +2386,7 @@ void register_console(struct console *newcon)
> >>> if (newcon->setup == NULL ||
> >>> newcon->setup(newcon, NULL) == 0) {
> >>> newcon->flags |= CON_ENABLED;
> >>> -   if (newcon->device) {
> >>> +   if (newcon->device  && !of_stdout) {
> >>> newcon->flags |= CON_CONSDEV;
> >>> preferred_console = 0;
> >>> }
> >> The DT settings relevant for ARC, which enable generic-earlycon and
> >> console-with-stdout-path are as follows
> >>
> >> chosen {
> >> bootargs = "earlycon";
> >> stdout-path = &arcuart0;
> >> };
> >>
> >> 
> >> arcuart0: serial@c0fc1000 {
> >> compatible = "snps,arc-uart";
> >>
> >> And it works w/o above hunk, provided the 2 patches from Grant exist in 
> >> linux-next
> >> which they don't at the moment. I'm pretty confused how the hunk above 
> >> comes into
> >> picture.
> >>
> >> And if not then I will have to get the ARC std-out patch reverted in 
> >> tty-next as
> >> it is broken.
> > You need to revert it anyway, the dependency chain is broken. Just
> > because something is in linux-next doesn't mean it will be merged.
> > Dependencies must always be in the branch to which you commit.
> >
> > If that doesn't happen (like here) then bisecting is broken and the
> > dependencies may not actually get merged.
> >
> > When this happens, what you're supposed to do is tell the maintainers
> > what commits the patch depends on so that it can be applied to the
> > correct tree. In this case I could take it through my devicetree branch
> > that contains the console patches.
> 
> I understand all of that. Actually 9 out of 10 of my changes were for 
> switching to
> earlycon for which corresponding core changes from Rob were already in 
> mainline.
> When reviewing my code, Rob pointed me to your on going work on use of 
> stdout-path
> so my mistake was to pile that up in the same series vs. asking you to add 
> that
> patch in ur tree for precisely the multi dependency reason.
> 
> > If a patch depends on commits in several branches then it is a bit more
> > complex. What we usually do is create a new branch that merges in each
> > branch that is depended on, and then apply the commit on top of that.
> >
> > As for the console patches, I'm only going to be putting them back if I
> > can devise a good fix for the earlycon duplication issue.
> 
> If you have an internal branch for this work, can you please add the patch 
> below
> to it so that we don't forget abt it.
> 
> https://lkml.org/lkml/2014/6/24/127
> 
> I'll ask Greg to revert it from tty tree !

Isn't that also broken for bisect? Doesn't that patch depend on the
patches in Greg's tree? If so, then same problem. At this point you'll
need to wait until both are mainlined before this patch gets applied
since I don't want to deal with cross merging trees.

However, this patch is trivial, so I don't see any problem with not
having it in linux-next before the merge window.

g.

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

Re: [PATCH v2 RESEND 3/4] drivers: dma-coherent: add initialization from device tree

[Grant Likely]

On Tue, Jul 29, 2014 at 11:33 PM, Marek Szyprowski
 wrote:
> Hello,
>
>
> On 2014-07-29 23:54, Grant Likely wrote:
>>
>> On Mon, 14 Jul 2014 10:28:06 +0200, Marek Szyprowski
>>  wrote:
>>>
>>> Initialization procedure of dma coherent pool has been split into two
>>> parts, so memory pool can now be initialized without assigning to
>>> particular struct device. Then initialized region can be assigned to
>>> more than one struct device. To protect from concurent allocations from
>>> different devices, a spinlock has been added to dma_coherent_mem
>>> structure. The last part of this patch adds support for handling
>>> 'shared-dma-pool' reserved-memory device tree nodes.
>>>
>>> Signed-off-by: Marek Szyprowski 
>>
>> I think this looks okay. It isn't in my area of expertise though.
>> Comments below.
>>
>>> ---
>>>   drivers/base/dma-coherent.c | 137
>>> ++--
>>>   1 file changed, 118 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
>>> index 7d6e84a51424..7185a4f247e1 100644
>>> --- a/drivers/base/dma-coherent.c
>>> +++ b/drivers/base/dma-coherent.c
>>> @@ -14,11 +14,14 @@ struct dma_coherent_mem {
>>> int size;
>>> int flags;
>>> unsigned long   *bitmap;
>>> +   spinlock_t  spinlock;
>>>   };
>>>   -int dma_declare_coherent_memory(struct device *dev, phys_addr_t
>>> phys_addr,
>>> -   dma_addr_t device_addr, size_t size, int
>>> flags)
>>> +static int dma_init_coherent_memory(phys_addr_t phys_addr, dma_addr_t
>>> device_addr,
>>> +size_t size, int flags,
>>> +struct dma_coherent_mem **mem)
>>
>> This is a bit odd. Why wouldn't you return the dma_mem pointer directly
>> instead of passing in a **mem argument?
>
>
> Because this function (as a direct successor of dma_declare_coherent_memory)
> doesn't
> return typical error codes, but some custom values like DMA_MEMORY_MAP,
> DMA_MEMORY_IO
> or zero (which means failure). I wanted to avoid confusion with typical
> error
> handling path and IS_ERR/ERR_PTR usage used widely in other functions. This
> probably
> should be unified with the rest of kernel some day, but right now I wanted
> to keep
> the patch simple and easy to review.
>
>
>>>   {
>>> +   struct dma_coherent_mem *dma_mem = NULL;
>>> void __iomem *mem_base = NULL;
>>> int pages = size >> PAGE_SHIFT;
>>> int bitmap_size = BITS_TO_LONGS(pages) * sizeof(long);
>>> @@ -27,27 +30,26 @@ int dma_declare_coherent_memory(struct device *dev,
>>> phys_addr_t phys_addr,
>>> goto out;
>>> if (!size)
>>> goto out;
>>> -   if (dev->dma_mem)
>>> -   goto out;
>>> -
>>> -   /* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN
>>> */
>>> mem_base = ioremap(phys_addr, size);
>>> if (!mem_base)
>>> goto out;
>>>   - dev->dma_mem = kzalloc(sizeof(struct dma_coherent_mem),
>>> GFP_KERNEL);
>>> -   if (!dev->dma_mem)
>>> +   dma_mem = kzalloc(sizeof(struct dma_coherent_mem), GFP_KERNEL);
>>> +   if (!dma_mem)
>>> goto out;
>>> -   dev->dma_mem->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
>>> -   if (!dev->dma_mem->bitmap)
>>> +   dma_mem->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
>>> +   if (!dma_mem->bitmap)
>>> goto free1_out;
>>>   - dev->dma_mem->virt_base = mem_base;
>>> -   dev->dma_mem->device_base = device_addr;
>>> -   dev->dma_mem->pfn_base = PFN_DOWN(phys_addr);
>>> -   dev->dma_mem->size = pages;
>>> -   dev->dma_mem->flags = flags;
>>> +   dma_mem->virt_base = mem_base;
>>> +   dma_mem->device_base = device_addr;
>>> +   dma_mem->pfn_base = PFN_DOWN(phys_addr);
>>> +   dma_mem->size = pages;
>>> +   dma_mem->flags = flags;
>>> +   spin_lock_init(&dma_mem->spinlock);
>>> +
>>> +   *mem = dma_mem;
>>> if (flags & DMA_MEMORY_MAP)
>>> return DMA_MEMORY_MAP;
>>> @@ -55,12 +57,51 @@ int dma_declare_coherent_memory(struct device *dev,
>>> phys_addr_t phys_addr,
>>> return DMA_MEMORY_IO;
>>>  free1_out:
>>> -   kfree(dev->dma_mem);
>>> +   kfree(dma_mem);
>>>out:
>>> if (mem_base)
>>> iounmap(mem_base);
>>> return 0;
>>>   }
>>> +
>>> +static void dma_release_coherent_memory(struct dma_coherent_mem *mem)
>>> +{
>>> +   if (!mem)
>>> +   return;
>>> +   iounmap(mem->virt_base);
>>> +   kfree(mem->bitmap);
>>> +   kfree(mem);
>>> +}
>>> +
>>> +static int dma_assign_coherent_memory(struct device *dev,
>>> + struct dma_coherent_mem *mem)
>>> +{
>>> +   if (dev->dma_mem)
>>> +   return -EBUSY;
>>> +
>>> +   dev->dma_mem = mem;
>>> +   /* FIXME: this routine just ignores DMA_MEMORY

Re: [RESEND RFC V2] devicetree: Dialog Semiconductor consolidate existing vendor prefixes to standardise on 'dlg'

[Simon Horman]

On Wed, Jul 30, 2014 at 11:05:01AM +, Opensource [Steve Twiss] wrote:
> 
> On 30 July 2014 03:37 Simon Horman wrote:
> >On Mon, Jul 28, 2014 at 09:53:56AM +, Opensource [Steve Twiss] wrote:
> >> On 25 July 2014 08:00, Lee Jones wrote:
> >>
> >> >On Thu, 24 Jul 2014, Opensource [Steve Twiss] wrote:
> >> >> From: Steve Twiss 
> >> >>
> >> >> This patch series updates the device tree vendor prefix for
> >> >> Dialog Semiconductor.
> >> >>
> >> >> Various methods are currently used throughout the kernel: 'diasemi',
> >> >> 'dialog' and 'dlg'. Others have also been suggested.
> >> >>
> >> >> This patch set aims to consolidate the usage of the vendor prefix to
> >> >> use a common standard. The prefix 'dlg' is used.
> >> >>
> >> >>
> >> >> Signed-off-by: Steve Twiss 
> >> >
> >> >Didn't I Ack the MFD parts already?
> >> >
> >>
> >> Yes -- certainly.
> >>  (I should have put them in the main body of the e-mail shouldn't I ..?)
> >>
> >> I just need the SHMobile responses now.
> >> I will try to make contact with those guys this week.
> >
> >Hi Steve,
> >
> >I apologise for not noticing this earlier:
> >I am entirely unsure how I missed it.
> 
> Hi Simon,
> 
> Thank you for responding to this. No problem.
> 
> >
> >In principle I am fine with this change so long as it does not
> >introduce any backwards-compatibility problems. In particular removing
> >compatibility strings that may already be in use by DTB blobs in the wild.
> >
> >For SH Mobile it seems that Lager and Koelsch were using "diasemi,da9210"
> >which is unsupported by the driver at this time. So it seems there is no
> >backwards-compatibility problem there. I'm less sure about other aspects of
> >the patch. And I'm also less concerned about them.
> >
> >I do have a slight preference for SH Mobile changes to go through my
> >renesas tree rather than elsewhere (as part of a more global change)
> >principally to try to avoid the possibility of conflicts. The SH Mobile dts
> >files in question are often updated. And for example I notice some fuzz
> >when applying this patch on top of the next-20140729 tag of linux-next.
> 
> I have applied the patch to linux-next/next-20140729 and the patch
> program does throw some warnings,
> 
> patching file arch/arm/boot/dts/r8a7790-lager.dts
> Hunk #1 succeeded at 378 (offset 4 lines).
> patching file arch/arm/boot/dts/r8a7791-koelsch.dts
> Hunk #1 succeeded at 430 (offset 4 lines).
> 
> But when I checked the output, the patch was applied correctly.
> They are one-line changes in both cases:
> 
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
> b/arch/arm/boot/dts/r8a7790-lager.dts
> index 7853c2c..becaaab 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -378,7 +378,7 @@
> status = "okay";
>  
> vdd_dvfs: regulator@68 {
> -   compatible = "diasemi,da9210";
> +   compatible = "dlg,da9210";
> reg = <0x68>;
>  
> regulator-min-microvolt = <100>;
> diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
> b/arch/arm/boot/dts/r8a7791-koelsch.dts
> index 8f36d4f..684fc44 100644
> --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> @@ -430,7 +430,7 @@
> clock-frequency = <10>;
>  
> vdd_dvfs: regulator@68 {
> -   compatible = "diasemi,da9210";
> +   compatible = "dlg,da9210";
> reg = <0x68>;
>  
> regulator-min-microvolt = <100>;
> 
> 
> >
> >If you were to break out the SH Mobile portion of this patch I would be
> >happy to take it once the driver portion is accepted.  That said, I do see
> >that everyone else has acked the change so clearly this is not an issue
> >from their point of view. So I will not complain if you decide not to break
> >the patch up (though please note my warning about possible conflicts).
> 
> I have been trying to get Acked-by: tags for a while now, and it has taken a
> fair amount of time to get everybody's responses. For that reason and
> because the patch managed to be applied cleanly to next-20140729 (despite
> 4 line offsets) I would like to resend this patch with your Acked-by: applied
> instead of splitting up the patch into several sections and then touting
> for new Acked-by: all over again.
> 
> I realise that your DTS files are updated constantly -- I do hope this will
> not cause any problems with the merge.

Hi Steve,

thanks. I'm happy for you to proceed with the plan you outline above.
I think the risk of a non-trivial conflict is minimal.

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

[git:media_tree/master] [media] media: atmel-isi: add primary DT support

[Mauro Carvalho Chehab]

This is an automatic generated email to let you know that the following patch 
were queued at the 
http://git.linuxtv.org/media_tree.git tree:

Subject: [media] media: atmel-isi: add primary DT support
Author:  Josh Wu 
Date:Mon Jul 28 04:25:17 2014 -0300

This patch add the DT support for Atmel ISI driver.
It use the same v4l2 DT interface that defined in video-interfaces.txt.

Signed-off-by: Josh Wu 
Cc: devicetree@vger.kernel.org
Reviewed-by: Laurent Pinchart 
Signed-off-by: Guennadi Liakhovetski 
Signed-off-by: Mauro Carvalho Chehab 

 .../devicetree/bindings/media/atmel-isi.txt|   51 +++
 drivers/media/platform/soc_camera/atmel-isi.c  |   65 +++-
 2 files changed, 114 insertions(+), 2 deletions(-)

---

http://git.linuxtv.org/media_tree.git?a=commitdiff;h=8ff19bc437f8d42d8a03dafe2bb28c5b3fc1bff1

diff --git a/Documentation/devicetree/bindings/media/atmel-isi.txt 
b/Documentation/devicetree/bindings/media/atmel-isi.txt
new file mode 100644
index 000..17e71b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel-isi.txt
@@ -0,0 +1,51 @@
+Atmel Image Sensor Interface (ISI) SoC Camera Subsystem
+--
+
+Required properties:
+- compatible: must be "atmel,at91sam9g45-isi"
+- reg: physical base address and length of the registers set for the device;
+- interrupts: should contain IRQ line for the ISI;
+- clocks: list of clock specifiers, corresponding to entries in
+  the clock-names property;
+- clock-names: must contain "isi_clk", which is the isi peripherial clock.
+
+ISI supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+   isi: isi@f0034000 {
+   compatible = "atmel,at91sam9g45-isi";
+   reg = <0xf0034000 0x4000>;
+   interrupts = <37 IRQ_TYPE_LEVEL_HIGH 5>;
+
+   clocks = <&isi_clk>;
+   clock-names = "isi_clk";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_isi>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   isi_0: endpoint {
+   remote-endpoint = <&ov2640_0>;
+   bus-width = <8>;
+   };
+   };
+   };
+
+   i2c1: i2c@f0018000 {
+   ov2640: camera@0x30 {
+   compatible = "omnivision,ov2640";
+   reg = <0x30>;
+
+   port {
+   ov2640_0: endpoint {
+   remote-endpoint = <&isi_0>;
+   bus-width = <8>;
+   };
+   };
+   };
+   };
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c 
b/drivers/media/platform/soc_camera/atmel-isi.c
index d32c533..3408b04 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define MAX_BUFFER_NUM 32
@@ -33,6 +34,7 @@
 #define VID_LIMIT_BYTES(16 * 1024 * 1024)
 #define MIN_FRAME_RATE 15
 #define FRAME_INTERVAL_MILLI_SEC   (1000 / MIN_FRAME_RATE)
+#define ISI_DEFAULT_MCLK_FREQ  2500
 
 /* Frame buffer descriptor */
 struct fbd {
@@ -876,6 +878,51 @@ static int atmel_isi_remove(struct platform_device *pdev)
return 0;
 }
 
+static int atmel_isi_probe_dt(struct atmel_isi *isi,
+   struct platform_device *pdev)
+{
+   struct device_node *np= pdev->dev.of_node;
+   struct v4l2_of_endpoint ep;
+   int err;
+
+   /* Default settings for ISI */
+   isi->pdata.full_mode = 1;
+   isi->pdata.mck_hz = ISI_DEFAULT_MCLK_FREQ;
+   isi->pdata.frate = ISI_CFG1_FRATE_CAPTURE_ALL;
+
+   np = of_graph_get_next_endpoint(np, NULL);
+   if (!np) {
+   dev_err(&pdev->dev, "Could not find the endpoint\n");
+   return -EINVAL;
+   }
+
+   err = v4l2_of_parse_endpoint(np, &ep);
+   if (err) {
+   dev_err(&pdev->dev, "Could not parse the endpoint\n");
+   goto err_probe_dt;
+   }
+
+   switch (ep.bus.parallel.bus_width) {
+   case 8:
+   isi->pdata.data_width_flags = ISI_DATAWIDTH_8;
+   break;
+   case 10:
+   isi->pdata.data_width_flags =
+   ISI_DATAWIDTH_8 | ISI_DATAWIDTH_10;
+   break;
+   default:
+   dev_err(&pdev->dev, "Unsupported bus width: %d\n",
+   ep.bus.parallel.bus_width);
+   err = -EINVAL;
+   goto er

[PATCH] scsi: ibmvscsi: ibmvfc.c: Cleaning up missing null-terminate in conjunction with strncpy

[Rickard Strandqvist]

Replacing strncpy with strlcpy to avoid strings that lacks null terminate.

Signed-off-by: Rickard Strandqvist 
---
 drivers/scsi/ibmvscsi/ibmvfc.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 8dd4768..56c26ef 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -1149,7 +1149,8 @@ static void ibmvfc_gather_partition_info(struct 
ibmvfc_host *vhost)
 
name = of_get_property(rootdn, "ibm,partition-name", NULL);
if (name)
-   strncpy(vhost->partition_name, name, 
sizeof(vhost->partition_name));
+   strlcpy(vhost->partition_name, name,
+   sizeof(vhost->partition_name));
num = of_get_property(rootdn, "ibm,partition-no", NULL);
if (num)
vhost->partition_number = *num;
@@ -1186,13 +1187,14 @@ static void ibmvfc_set_login_info(struct ibmvfc_host 
*vhost)
login_info->capabilities = IBMVFC_CAN_MIGRATE;
login_info->async.va = vhost->async_crq.msg_token;
login_info->async.len = vhost->async_crq.size * 
sizeof(*vhost->async_crq.msgs);
-   strncpy(login_info->partition_name, vhost->partition_name, 
IBMVFC_MAX_NAME);
-   strncpy(login_info->device_name,
+   strlcpy(login_info->partition_name, vhost->partition_name,
+   IBMVFC_MAX_NAME);
+   strlcpy(login_info->device_name,
dev_name(&vhost->host->shost_gendev), IBMVFC_MAX_NAME);
 
location = of_get_property(of_node, "ibm,loc-code", NULL);
location = location ? location : dev_name(vhost->dev);
-   strncpy(login_info->drc_name, location, IBMVFC_MAX_NAME);
+   strlcpy(login_info->drc_name, location, IBMVFC_MAX_NAME);
 }
 
 /**
-- 
1.7.10.4

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

[PATCH] scsi: ibmvscsi: ibmvfc.c: Cleaning up missing null-terminate in conjunction with strncpy

[Rickard Strandqvist]

And as I understand it, it is fine to replace strncpy to strlcpy here.
But if any of this code do not want a null terminated, or want to have the 
whole rest of size filled with null characters. 
If that is the case this is not a good patch.

Rickard Strandqvist (1):
  scsi: ibmvscsi: ibmvfc.c:  Cleaning up missing null-terminate in conjunction 
with
strncpy

 drivers/scsi/ibmvscsi/ibmvfc.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

-- 
1.7.10.4

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

[PATCH v3 3/3] ARM: shmobile: henninger: add CAN0 DT support

[Sergei Shtylyov]

Define the Henninger board dependent part of the CAN0 device node.

Signed-off-by: Sergei Shtylyov 

---
Changes in version 3:
- changed "can0_data_a" to "can0_data", removed "can_clk_d" in the
  "renesas,groups" property;
- moved CAN0 node to go after all others;
- refreshed the patch.

 arch/arm/boot/dts/r8a7791-henninger.dts |   11 +++
 1 file changed, 11 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7791-henninger.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-henninger.dts
+++ renesas/arch/arm/boot/dts/r8a7791-henninger.dts
@@ -135,6 +135,11 @@
renesas,groups = "usb1";
renesas,function = "usb1";
};
+
+   can0_pins: can0 {
+   renesas,groups = "can0_data";
+   renesas,function = "can0";
+   };
 };
 
 &scif0 {
@@ -260,3 +265,9 @@
 &pciec {
status = "okay";
 };
+
+&can0 {
+   pinctrl-0 = <&can0_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/3] ARM: shmobile: r8a7791: add CAN DT support

[Sergei Shtylyov]

Define the generic R8A7791 parts of the CAN0/1 device nodes.

Signed-off-by: Sergei Shtylyov 

---
Changes in version 3:
- added 2 more CAN clocks along with "clock-names" property in the CAN0/1 device
  nodes;
- refreshed the patch.

Changes in version 2:
- fixed the "compatible" property in the CAN device nodes.

 arch/arm/boot/dts/r8a7791.dtsi |   20 
 1 file changed, 20 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
+++ renesas/arch/arm/boot/dts/r8a7791.dtsi
@@ -550,6 +550,26 @@
status = "disabled";
};
 
+   can0: can@e6e8 {
+   compatible = "renesas,can-r8a7791";
+   reg = <0 0xe6e8 0 0x1000>;
+   interrupts = <0 186 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&mstp9_clks R8A7791_CLK_RCAN0>,
+<&cpg_clocks R8A7791_CLK_RCAN>, <&can_clk>;
+   clock-names = "clkp1", "clkp2", "can_clk";
+   status = "disabled";
+   };
+
+   can1: can@e6e88000 {
+   compatible = "renesas,can-r8a7791";
+   reg = <0 0xe6e88000 0 0x1000>;
+   interrupts = <0 187 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&mstp9_clks R8A7791_CLK_RCAN1>,
+<&cpg_clocks R8A7791_CLK_RCAN>, <&can_clk>;
+   clock-names = "clkp1", "clkp2", "can_clk";
+   status = "disabled";
+   };
+
clocks {
#address-cells = <2>;
#size-cells = <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/3] ARM: shmobile: r8a7791: add CAN clocks

[Sergei Shtylyov]

The R-Car CAN controllers can derive the CAN bus clock not only from their
peripheral clock input (clkp1) but also from the other internal clock (clkp2)
and external clock fed on CAN_CLK pin.  Describe those clocks in the device
tree,  along with  the USB_EXTAL clock  from which clkp2 is derived.

Signed-off-by: Sergei Shtylyov 

---
Changes in version 3:
- new patch.

 arch/arm/boot/dts/r8a7791.dtsi|   23 +--
 include/dt-bindings/clock/r8a7791-clock.h |1 +
 2 files changed, 22 insertions(+), 2 deletions(-)

Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
+++ renesas/arch/arm/boot/dts/r8a7791.dtsi
@@ -596,15 +596,34 @@
status = "disabled";
};
 
+   /* External USB clock - can be overridden by the board */
+   usb_extal_clk: usb_extal_clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <4800>;
+   clock-output-names = "usb_extal";
+   };
+
+   /* External CAN clock */
+   can_clk: can_clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   /* This value must be overriden by the board. */
+   clock-frequency = <0>;
+   clock-output-names = "can_clk";
+   status = "disabled";
+   };
+
/* Special CPG clocks */
cpg_clocks: cpg_clocks@e615 {
compatible = "renesas,r8a7791-cpg-clocks",
 "renesas,rcar-gen2-cpg-clocks";
reg = <0 0xe615 0 0x1000>;
-   clocks = <&extal_clk>;
+   clocks = <&extal_clk &usb_extal_clk>;
#clock-cells = <1>;
clock-output-names = "main", "pll0", "pll1", "pll3",
-"lb", "qspi", "sdh", "sd0", "z";
+"lb", "qspi", "sdh", "sd0", "z",
+"rcan";
};
 
/* Variable factor clocks */
Index: renesas/include/dt-bindings/clock/r8a7791-clock.h
===
--- renesas.orig/include/dt-bindings/clock/r8a7791-clock.h
+++ renesas/include/dt-bindings/clock/r8a7791-clock.h
@@ -20,6 +20,7 @@
 #define R8A7791_CLK_SDH6
 #define R8A7791_CLK_SD07
 #define R8A7791_CLK_Z  8
+#define R8A7791_CLK_RCAN   9
 
 /* MSTP0 */
 #define R8A7791_CLK_MSIOF0 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 v3 0/3] Add R8A7791/Henninger board CAN DT support

[Sergei Shtylyov]

Hello.

   Here's the set of 3 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-v3.16-rc7-20140729' tag. Here we add the CAN device tree support
for the R8A7791-based Henninger board. It depends on the PFC CAN fix, R-Car CAN
driver clock support and device tree support patches, and the clk driver RCAN
clock patch posted recently in order to work.

[1/3] ARM: shmobile: r8a7791: add CAN clocks
[2/3] ARM: shmobile: r8a7791: add CAN DT support
[3/3] ARM: shmobile: henninger: add CAN0 DT support

WBR, Sergei
--
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] Documentation: devicetree: Fix tps65090 typos in example

[Andreas Färber]

Specification and existing device trees use vsys-l{1,2}-supply,
not vsys_l{1,2}-supply. Fix the example to match the specification.

Reviewed-by: Doug Anderson 
Acked-by: Mark Rutland 
Fixes: 21d2202158e9 ("mfd: tps65090: add DT support for tps65090")
Signed-off-by: Andreas Färber 
---
 v2 -> v3:
 * Added Fixes header
 * + regulator and mfd maintainers
 
 v1 -> v2:
 * More verbose commit message (requested by Mark Rutland)
 
 Documentation/devicetree/bindings/regulator/tps65090.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt 
b/Documentation/devicetree/bindings/regulator/tps65090.txt
index 340980239ea9..ca69f5e3040c 100644
--- a/Documentation/devicetree/bindings/regulator/tps65090.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
@@ -45,8 +45,8 @@ Example:
infet5-supply = <&some_reg>;
infet6-supply = <&some_reg>;
infet7-supply = <&some_reg>;
-   vsys_l1-supply = <&some_reg>;
-   vsys_l2-supply = <&some_reg>;
+   vsys-l1-supply = <&some_reg>;
+   vsys-l2-supply = <&some_reg>;
 
regulators {
dcdc1 {
-- 
1.9.3

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

Re: [PATCH v4 2/2] dmaengine: add a driver for AMBA AXI NBPF DMAC IP cores

[Guennadi Liakhovetski]

Hi Vinod,

On Mon, 28 Jul 2014, Guennadi Liakhovetski wrote:

> > Looking at the code again, I think we need to free irq (you can call
> > devm_free_irq()) and call syncronize_irq so that anything pending is
> > flushed.  So if you can send follow up patch doing these in .remove, we can
> > merge these
> 
> This is a nice offer, thanks! But to accept it I'd like to understand: why 
> do you think we need that? In my previous email I presented to you a 
> theoretical and improbable race situation, that I can foresee. You erased 
> it in your reply, but it was dealing with the 
> .device_free_chan_resources() method, so, your suspected race is a 
> different one. Could you please explain to me, why do you think interrupts 
> are possible during .release()? Aren't all channels guaranteed to have 
> been freed by that time?

It would be great to get an explanation for your comment, please? How can 
interrupts come after all channels have been freed? Or how can .release() 
be called while some channels are still in use?

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

[PATCH v3 5/6] dts: add devicetree bindings for pxa27x clocks

[Robert Jarzmik]

Add the clock tree description for the PXA27x based boards.

Signed-off-by: Robert Jarzmik 
---
 arch/arm/boot/dts/pxa27x.dtsi | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index a705469..80fc5d7 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -1,5 +1,6 @@
 /* The pxa3xx skeleton simply augments the 2xx version */
-/include/ "pxa2xx.dtsi"
+#include "pxa2xx.dtsi"
+#include "dt-bindings/clock/pxa2xx-clock.h"
 
 / {
model = "Marvell PXA27x familiy SoC";
@@ -35,4 +36,21 @@
#pwm-cells = <1>;
};
};
+
+   clocks {
+  /*
+   * The muxing of external clocks/internal dividers for osc* clock
+   * sources has been hidden under the carpet by now.
+   */
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   pxa2xx_clks: pxa2xx_clks@4134 {
+   compatible = "marvell,pxa-clocks";
+   #clock-cells = <1>;
+   status = "okay";
+   };
+   };
+
 };
-- 
2.0.0.rc2

--
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/6] clk: add pxa clocks infrastructure

[Robert Jarzmik]

Add a the common code used by all PXA variants.

This is the first step in the transition from architecture defined
clocks (in arch/arm/mach-pxa) towards clock framework. The goal is to
have the same features (and not all the features) of the existing
clocks, and enable the transition of PXA to device-tree.

All PXA rely on a "CKEN" type clock, which :
 - has a gate (bit in CKEN register)
 - is generated from a PLL, generally divided
 - has an alternate low power clock

Each variant will specialize the CKEN clock :
 - pxa25x have no low power clock
 - pxa27x in low power use always the 13 MHz ring oscillator
 - pxa3xx in low power have specific dividers for each clock

The device-tree provides a list of CLK_* (ex: CLK_USB or CLK_I2C) to get
a handle on the clock. While pxa-clock.h will describe all the clocks of
all the variants, each variant will only use a subset of it.

Signed-off-by: Robert Jarzmik 
---
 drivers/clk/Makefile  |   1 +
 drivers/clk/pxa/Makefile  |   1 +
 drivers/clk/pxa/clk-pxa.c |  97 ++
 drivers/clk/pxa/clk-pxa.h | 107 ++
 include/dt-bindings/clock/pxa-clock.h |  77 
 5 files changed, 283 insertions(+)
 create mode 100644 drivers/clk/pxa/Makefile
 create mode 100644 drivers/clk/pxa/clk-pxa.c
 create mode 100644 drivers/clk/pxa/clk-pxa.h
 create mode 100644 include/dt-bindings/clock/pxa-clock.h

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 567f102..40390ea 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_ARCH_MMP)+= mmp/
 endif
 obj-$(CONFIG_PLAT_ORION)   += mvebu/
 obj-$(CONFIG_ARCH_MXS) += mxs/
+obj-$(CONFIG_ARCH_PXA) += pxa/
 obj-$(CONFIG_COMMON_CLK_QCOM)  += qcom/
 obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
 obj-$(CONFIG_COMMON_CLK_SAMSUNG)   += samsung/
diff --git a/drivers/clk/pxa/Makefile b/drivers/clk/pxa/Makefile
new file mode 100644
index 000..cb2bd8f
--- /dev/null
+++ b/drivers/clk/pxa/Makefile
@@ -0,0 +1 @@
+obj-y  += clk-pxa.o
diff --git a/drivers/clk/pxa/clk-pxa.c b/drivers/clk/pxa/clk-pxa.c
new file mode 100644
index 000..ef3c053
--- /dev/null
+++ b/drivers/clk/pxa/clk-pxa.c
@@ -0,0 +1,97 @@
+/*
+ * Marvell PXA family clocks
+ *
+ * Copyright (C) 2014 Robert Jarzmik
+ *
+ * Common clock code for PXA clocks ("CKEN" type clocks + DT)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "clk-pxa.h"
+
+DEFINE_SPINLOCK(lock);
+
+static struct clk *pxa_clocks[CLK_MAX];
+static struct clk_onecell_data onecell_data = {
+   .clks = pxa_clocks,
+   .clk_num = CLK_MAX,
+};
+
+#define to_pxa_clk(_hw) container_of(_hw, struct pxa_clk_cken, hw)
+
+static unsigned long cken_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+   struct pxa_clk_cken *pclk = to_pxa_clk(hw);
+   struct clk_fixed_factor *fix;
+
+   if (!pclk->is_in_low_power || pclk->is_in_low_power())
+   fix = &pclk->lp;
+   else
+   fix = &pclk->hp;
+   fix->hw.clk = hw->clk;
+   return clk_fixed_factor_ops.recalc_rate(&fix->hw, parent_rate);
+}
+
+static struct clk_ops cken_rate_ops = {
+   .recalc_rate = cken_recalc_rate,
+};
+
+static u8 cken_get_parent(struct clk_hw *hw)
+{
+   struct pxa_clk_cken *pclk = to_pxa_clk(hw);
+
+   if (!pclk->is_in_low_power)
+   return 0;
+   return pclk->is_in_low_power() ? 0 : 1;
+}
+
+static struct clk_ops cken_mux_ops = {
+   .get_parent = cken_get_parent,
+   .set_parent = dummy_clk_set_parent,
+};
+
+void __init clkdev_pxa_register(int ckid, const char *con_id,
+   const char *dev_id, struct clk *clk)
+{
+   if (!IS_ERR(clk) && (ckid != CLK_NONE))
+   pxa_clocks[ckid] = clk;
+   if (!IS_ERR(clk))
+   clk_register_clkdev(clk, con_id, dev_id);
+}
+
+int __init clk_pxa_cken_init(struct pxa_clk_cken *clks, int nb_clks)
+{
+   int i;
+   struct pxa_clk_cken *pclk;
+   struct clk *clk;
+
+   for (i = 0; i < nb_clks; i++) {
+   pclk = clks + i;
+   pclk->gate.lock = &lock;
+   clk = clk_register_composite(NULL, pclk->name,
+pclk->parent_names, 2,
+&pclk->hw, &cken_mux_ops,
+&pclk->hw, &cken_rate_ops,
+&pclk->gate.hw, &clk_gate_ops,
+pclk->flags);
+   clkdev_pxa_register(pclk

[PATCH v3 4/6] clk: add pxa27x clock drivers

[Robert Jarzmik]

Move pxa27x clock drivers from arch/arm/mach-pxa to driver/clk.
In the move :
 - convert to new clock framework legacy clocks
 - provide clocks as before for platform data based boards
 - provide clocks through devicetree

Signed-off-by: Robert Jarzmik 
---
 drivers/clk/pxa/Makefile |   1 +
 drivers/clk/pxa/clk-pxa27x.c | 370 +++
 2 files changed, 371 insertions(+)
 create mode 100644 drivers/clk/pxa/clk-pxa27x.c

diff --git a/drivers/clk/pxa/Makefile b/drivers/clk/pxa/Makefile
index cb2bd8f..4ff2abc 100644
--- a/drivers/clk/pxa/Makefile
+++ b/drivers/clk/pxa/Makefile
@@ -1 +1,2 @@
 obj-y  += clk-pxa.o
+obj-$(CONFIG_PXA27x)   += clk-pxa27x.o
diff --git a/drivers/clk/pxa/clk-pxa27x.c b/drivers/clk/pxa/clk-pxa27x.c
new file mode 100644
index 000..b345cc7
--- /dev/null
+++ b/drivers/clk/pxa/clk-pxa27x.c
@@ -0,0 +1,370 @@
+/*
+ * Marvell PXA27x family clocks
+ *
+ * Copyright (C) 2014 Robert Jarzmik
+ *
+ * Heavily inspired from former arch/arm/mach-pxa/clock.c.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "clk-pxa.h"
+
+#define KHz 1000
+#define MHz (1000 * 1000)
+
+enum {
+   PXA_CORE_13Mhz = 0,
+   PXA_CORE_RUN,
+   PXA_CORE_TURBO,
+};
+
+enum {
+   PXA_BUS_13Mhz = 0,
+   PXA_BUS_RUN,
+};
+
+enum {
+   PXA_LCD_13Mhz = 0,
+   PXA_LCD_RUN,
+};
+
+enum {
+   PXA_MEM_13Mhz = 0,
+   PXA_MEM_SYSTEM_BUS,
+   PXA_MEM_RUN,
+};
+
+static const char * const get_freq_khz[] = {
+   "core", "run", "cpll", "memory",
+   "system_bus"
+};
+
+/*
+ * Get the clock frequency as reflected by CCSR and the turbo flag.
+ * We assume these values have been applied via a fcs.
+ * If info is not 0 we also display the current settings.
+ */
+unsigned int pxa27x_get_clk_frequency_khz(int info)
+{
+   struct clk *clk;
+   unsigned long clks[5];
+   int i;
+
+   for (i = 0; i < 5; i++) {
+   clk = clk_get(NULL, get_freq_khz[i]);
+   if (IS_ERR(clk)) {
+   clks[i] = 0;
+   } else {
+   clks[i] = clk_get_rate(clk);
+   clk_put(clk);
+   }
+   }
+   if (info) {
+   pr_info("Run Mode clock: %ld.%02ldMHz\n",
+   clks[1] / 100, (clks[1] % 100) / 1);
+   pr_info("Turbo Mode clock: %ld.%02ldMHz\n",
+   clks[2] / 100, (clks[2] % 100) / 1);
+   pr_info("Memory clock: %ld.%02ldMHz\n",
+   clks[3] / 100, (clks[3] % 100) / 1);
+   pr_info("System bus clock: %ld.%02ldMHz\n",
+   clks[4] / 100, (clks[4] % 100) / 1);
+   }
+   return (unsigned int)clks[0];
+}
+
+bool pxa27x_is_ppll_disabled(void)
+{
+   unsigned long ccsr = CCSR;
+
+   return ccsr & (1 << CCCR_PPDIS_BIT);
+}
+
+#define PXA27X_CKEN(dev_id, con_id, parents, mult_hp, div_hp,  \
+   bit, is_lp, flags)  \
+   PXA_CKEN(dev_id, con_id, bit, parents, 1, 1, mult_hp, div_hp,   \
+is_lp,  &CKEN, CKEN_ ## bit, flags)
+#define PXA27X_PBUS_CKEN(dev_id, con_id, bit, mult_hp, div_hp, delay)  \
+   PXA27X_CKEN(dev_id, con_id, pxa27x_pbus_parents, mult_hp,   \
+   div_hp, bit, pxa27x_is_ppll_disabled, 0)
+
+PARENTS(pxa27x_pbus) = { "osc_13mhz", "ppll_312mhz" };
+PARENTS(pxa27x_sbus) = { "system_bus", "system_bus" };
+PARENTS(pxa27x_32Mhz_bus) = { "osc_32_768khz", "osc_32_768khz" };
+PARENTS(pxa27x_lcd_bus) = { "lcd_base", "lcd_base" };
+PARENTS(pxa27x_membus) = { "lcd_base", "lcd_base" };
+
+#define PXA27X_CKEN_1RATE(dev_id, con_id, bit, parents, delay) \
+   PXA_CKEN_1RATE(dev_id, con_id, bit, parents,\
+  &CKEN, CKEN_ ## bit, 0)
+#define PXA27X_CKEN_1RATE_AO(dev_id, con_id, bit, parents, delay)  \
+   PXA_CKEN_1RATE(dev_id, con_id, bit, parents,\
+  &CKEN, CKEN_ ## bit, CLK_IGNORE_UNUSED)
+
+static struct pxa_clk_cken pxa27x_clocks[] = {
+   PXA27X_PBUS_CKEN("pxa2xx-uart.0", NULL, FFUART, 2, 42, 1),
+   PXA27X_PBUS_CKEN("pxa2xx-uart.1", NULL, BTUART, 2, 42, 1),
+   PXA27X_PBUS_CKEN("pxa2xx-uart.2", NULL, STUART, 2, 42, 1),
+   PXA27X_PBUS_CKEN("pxa2xx-i2s", NULL, I2S, 2, 51, 0),
+   PXA27X_PBUS_CKEN("pxa2xx-i2c.0", NULL, I2C, 2, 19, 0),
+   PXA27X_PBUS_CKEN("pxa27x-udc", NULL, USB, 2, 13, 5),
+   PXA27X_PBUS_CKEN("pxa2xx-mci.0", NULL, MMC, 2, 32, 0),
+   PXA27X_PBUS_CKEN("pxa2xx-ir", "FICPCLK", FICP, 2, 13, 0),
+   PXA27X_PBUS_CKEN("pxa27x-ohci", NULL, USBHOST, 2, 13, 0

[PATCH v3 0/6] Migrate PXA27x platforms to clock framework

[Robert Jarzmik]

This is the third opus of this serie.
>From the previous one :
 - the boot ordering was fixed
   For DT, we rely on time_init() in arch/arm
   For non-DT, we keep the postcore_init() until all 3 PXA variants are
   converted, and meanwhile I'll discuss with Haojian where to call directly the
   clocks init function.
 - the section mismatches were fixed
   A split is done between CKEN clock descriptor and CKEN clock structure

The result was tested with a Mitac MIO A701 :
 - with the upstream platform-data based machine code
 - with the device-tree version

As for the patches, if they are carried fully by Mike, I think there will be a
minor conflict in arch/arm/mach-pxa/Makefile with the clocksource patches I
submitted earlier.

As before, the goal remains the same :
 - keeping legacy platforms working (ie. without device-tree)
 - enable PXA27x to work with a device-tree kernel, and hence
   open the way to drivers conversion
 - be robust enough to support pxa25x and pxa3xx later inclusion
   with almost no change to clk-pxa-dt.c.

Robert Jarzmik (6):
  clk: add pxa clocks infrastructure
  clk: dts: document pxa clock binding
  arm: pxa: add clock pll selection bits
  clk: add pxa27x clock drivers
  dts: add devicetree bindings for pxa27x clocks
  arm: pxa: Transition pxa27x to clk framework

 .../devicetree/bindings/clock/pxa-clock.txt|  16 +
 arch/arm/Kconfig   |   1 +
 arch/arm/boot/dts/pxa27x.dtsi  |  20 +-
 arch/arm/mach-pxa/Makefile |   8 +-
 arch/arm/mach-pxa/include/mach/pxa2xx-regs.h   |  10 +
 arch/arm/mach-pxa/pxa27x.c | 186 +--
 drivers/clk/Makefile   |   1 +
 drivers/clk/pxa/Makefile   |   2 +
 drivers/clk/pxa/clk-pxa.c  |  97 ++
 drivers/clk/pxa/clk-pxa.h  | 107 ++
 drivers/clk/pxa/clk-pxa27x.c   | 370 +
 include/dt-bindings/clock/pxa-clock.h  |  77 +
 12 files changed, 716 insertions(+), 179 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/pxa-clock.txt
 create mode 100644 drivers/clk/pxa/Makefile
 create mode 100644 drivers/clk/pxa/clk-pxa.c
 create mode 100644 drivers/clk/pxa/clk-pxa.h
 create mode 100644 drivers/clk/pxa/clk-pxa27x.c
 create mode 100644 include/dt-bindings/clock/pxa-clock.h

-- 
2.0.0.rc2

--
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 6/6] arm: pxa: Transition pxa27x to clk framework

[Robert Jarzmik]

Transition the PXA27x CPUs to the clock framework.
This transition still enables legacy platforms to run without device
tree as before, ie relying on platform data encoded in board specific
files.

Signed-off-by: Robert Jarzmik 
---
 arch/arm/Kconfig   |   1 +
 arch/arm/mach-pxa/Makefile |   8 +-
 arch/arm/mach-pxa/pxa27x.c | 186 +++--
 3 files changed, 17 insertions(+), 178 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 87b63fd..96bdc7b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -642,6 +642,7 @@ config ARCH_PXA
select ARCH_REQUIRE_GPIOLIB
select ARM_CPU_SUSPEND if PM
select AUTO_ZRELADDR
+   select COMMON_CLK if PXA27x
select CLKDEV_LOOKUP
select CLKSRC_MMIO
select GENERIC_CLOCKEVENTS
diff --git a/arch/arm/mach-pxa/Makefile b/arch/arm/mach-pxa/Makefile
index 648867a..ce15823 100644
--- a/arch/arm/mach-pxa/Makefile
+++ b/arch/arm/mach-pxa/Makefile
@@ -3,16 +3,16 @@
 #
 
 # Common support (must be linked before board specific support)
-obj-y  += clock.o devices.o generic.o irq.o \
+obj-y  += devices.o generic.o irq.o \
   time.o reset.o
 obj-$(CONFIG_PM)   += pm.o sleep.o standby.o
 
 # Generic drivers that other drivers may depend upon
 
 # SoC-specific code
-obj-$(CONFIG_PXA25x)   += mfp-pxa2xx.o clock-pxa2xx.o pxa2xx.o pxa25x.o
-obj-$(CONFIG_PXA27x)   += mfp-pxa2xx.o clock-pxa2xx.o pxa2xx.o pxa27x.o
-obj-$(CONFIG_PXA3xx)   += mfp-pxa3xx.o clock-pxa3xx.o pxa3xx.o smemc.o 
pxa3xx-ulpi.o
+obj-$(CONFIG_PXA25x)   += mfp-pxa2xx.o clock.o clock-pxa2xx.o pxa2xx.o 
pxa25x.o
+obj-$(CONFIG_PXA27x)   += mfp-pxa2xx.o pxa2xx.o pxa27x.o
+obj-$(CONFIG_PXA3xx)   += mfp-pxa3xx.o clock.o clock-pxa3xx.o pxa3xx.o 
smemc.o pxa3xx-ulpi.o
 obj-$(CONFIG_CPU_PXA300)   += pxa300.o
 obj-$(CONFIG_CPU_PXA320)   += pxa320.o
 obj-$(CONFIG_CPU_PXA930)   += pxa930.o
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 301471a..6beb32cd 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -37,7 +37,8 @@
 
 #include "generic.h"
 #include "devices.h"
-#include "clock.h"
+#include 
+#include 
 
 void pxa27x_clear_otgph(void)
 {
@@ -73,174 +74,6 @@ void pxa27x_configure_ac97reset(int reset_gpio, bool 
to_gpio)
 }
 EXPORT_SYMBOL_GPL(pxa27x_configure_ac97reset);
 
-/* Crystal clock: 13MHz */
-#define BASE_CLK   1300
-
-/*
- * Get the clock frequency as reflected by CCSR and the turbo flag.
- * We assume these values have been applied via a fcs.
- * If info is not 0 we also display the current settings.
- */
-unsigned int pxa27x_get_clk_frequency_khz(int info)
-{
-   unsigned long ccsr, clkcfg;
-   unsigned int l, L, m, M, n2, N, S;
-   int cccr_a, t, ht, b;
-
-   ccsr = CCSR;
-   cccr_a = CCCR & (1 << 25);
-
-   /* Read clkcfg register: it has turbo, b, half-turbo (and f) */
-   asm( "mrc\tp14, 0, %0, c6, c0, 0" : "=r" (clkcfg) );
-   t  = clkcfg & (1 << 0);
-   ht = clkcfg & (1 << 2);
-   b  = clkcfg & (1 << 3);
-
-   l  = ccsr & 0x1f;
-   n2 = (ccsr>>7) & 0xf;
-   m  = (l <= 10) ? 1 : (l <= 20) ? 2 : 4;
-
-   L  = l * BASE_CLK;
-   N  = (L * n2) / 2;
-   M  = (!cccr_a) ? (L/m) : ((b) ? L : (L/2));
-   S  = (b) ? L : (L/2);
-
-   if (info) {
-   printk( KERN_INFO "Run Mode clock: %d.%02dMHz (*%d)\n",
-   L / 100, (L % 100) / 1, l );
-   printk( KERN_INFO "Turbo Mode clock: %d.%02dMHz (*%d.%d, 
%sactive)\n",
-   N / 100, (N % 100)/1, n2 / 2, (n2 % 2)*5,
-   (t) ? "" : "in" );
-   printk( KERN_INFO "Memory clock: %d.%02dMHz (/%d)\n",
-   M / 100, (M % 100) / 1, m );
-   printk( KERN_INFO "System bus clock: %d.%02dMHz \n",
-   S / 100, (S % 100) / 1 );
-   }
-
-   return (t) ? (N/1000) : (L/1000);
-}
-
-/*
- * Return the current mem clock frequency as reflected by CCCR[A], B, and L
- */
-static unsigned long clk_pxa27x_mem_getrate(struct clk *clk)
-{
-   unsigned long ccsr, clkcfg;
-   unsigned int l, L, m, M;
-   int cccr_a, b;
-
-   ccsr = CCSR;
-   cccr_a = CCCR & (1 << 25);
-
-   /* Read clkcfg register: it has turbo, b, half-turbo (and f) */
-   asm( "mrc\tp14, 0, %0, c6, c0, 0" : "=r" (clkcfg) );
-   b = clkcfg & (1 << 3);
-
-   l = ccsr & 0x1f;
-   m = (l <= 10) ? 1 : (l <= 20) ? 2 : 4;
-
-   L = l * BASE_CLK;
-   M = (!cccr_a) ? (L/m) : ((b) ? L : (L/2));
-
-   return M;
-}
-
-static const struct clkops clk_pxa27x_mem_ops = {
-   .enable = clk_dummy_enable,
-   .disable= clk_dummy_disable,
-   .getrate= clk_pxa27x_mem_getrate,
-};
-

[PATCH v3 2/6] clk: dts: document pxa clock binding

[Robert Jarzmik]

Document the device-tree binding of Marvell PXA based SoCs.
PXA clocks are mostly fixed rate and fixed ratio clocks derived from an
external oscillator, and gated by a register set (CKEN or CKEN*).

Signed-off-by: Robert Jarzmik 
---
 Documentation/devicetree/bindings/clock/pxa-clock.txt | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/pxa-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/pxa-clock.txt 
b/Documentation/devicetree/bindings/clock/pxa-clock.txt
new file mode 100644
index 000..4b4a902
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/pxa-clock.txt
@@ -0,0 +1,16 @@
+* Clock bindings for Marvell PXA chips
+
+Required properties:
+- compatible: Should be "marvell,pxa-clocks"
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell (see include/.../pxa-clock.h).
+
+Examples:
+
+pxa2xx_clks: pxa2xx_clks@4134 {
+compatible = "marvell,pxa-clocks";
+#clock-cells = <1>;
+status = "okay";
+};
-- 
2.0.0.rc2

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

[PATCH v3 3/6] arm: pxa: add clock pll selection bits

[Robert Jarzmik]

Add missing bits for CCCR and CCSR :
 - CPLL and PPLL selection, either full speed or 13MHz
 - CPSR masks

Signed-off-by: Robert Jarzmik 
---
 arch/arm/mach-pxa/include/mach/pxa2xx-regs.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-pxa/include/mach/pxa2xx-regs.h 
b/arch/arm/mach-pxa/include/mach/pxa2xx-regs.h
index ee6ced1..f1dd629 100644
--- a/arch/arm/mach-pxa/include/mach/pxa2xx-regs.h
+++ b/arch/arm/mach-pxa/include/mach/pxa2xx-regs.h
@@ -143,6 +143,16 @@
 #define CCCR_M_MASK0x0060  /* Memory Frequency to Run Mode Frequency 
Multiplier */
 #define CCCR_L_MASK0x001f  /* Crystal Frequency to Memory Frequency 
Multiplier */
 
+#define CCCR_CPDIS_BIT (31)
+#define CCCR_PPDIS_BIT (30)
+#define CCCR_LCD_26_BIT(27)
+#define CCCR_A_BIT (25)
+
+#define CCSR_N2_MASK   CCCR_N_MASK
+#define CCSR_M_MASKCCCR_M_MASK
+#define CCSR_L_MASKCCCR_L_MASK
+#define CCSR_N2_SHIFT  7
+
 #define CKEN_AC97CONF   (31)/* AC97 Controller Configuration */
 #define CKEN_CAMERA(24)/* Camera Interface Clock Enable */
 #define CKEN_SSP1  (23)/* SSP1 Unit Clock Enable */
-- 
2.0.0.rc2

--
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: [2/2] powerpc/fsl-booke: Add initial T1042RDB_PI board support

[Scott Wood]

On Wed, Jul 09, 2014 at 09:54:11AM +0530, Priyanka Jain wrote:
> diff --git a/arch/powerpc/boot/dts/t104xrdb.dtsi 
> b/arch/powerpc/boot/dts/t104xrdb.dtsi
> index 9aaefa5..e7e765f 100644
> --- a/arch/powerpc/boot/dts/t104xrdb.dtsi
> +++ b/arch/powerpc/boot/dts/t104xrdb.dtsi
> @@ -57,7 +57,8 @@
>   };
>  
>   cpld@3,0 {
> - compatible = "fsl,t1040rdb-cpld","fsl,t1042rdb-cpld";
> + compatible = "fsl,t1040rdb-cpld","fsl,t1042rdb-cpld",
> + "fsl,t1042rdb_pi-cpld";
>   reg = <3 0 0x300>;
>   };
>   };

What's going on here?  This file is used by all three boards.  If you
need to distinguish one board's CPLD from another's, you'll have to do it
somewhere else.  If the CPLDs are exactly the same and no distinction
needs to be made, then you don't need three compatible strings.  Even
then, you may wish to specify the exact board as the first compatible
string, but again you'll need to patch that in elsewhere so that it
actually matches the board.

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

Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings

[Arnd Bergmann]

On Wednesday 30 July 2014, Thierry Reding wrote:
se?
> 
> I think there weren't any comments left for me to address and I've
> mostly been waiting for Joerg to pick it up.
> 
> Joerg, can you take this through the iommu tree for 3.17? Will acked
> this, but perhaps you were waiting for an ACK from the device tree
> bindings maintainers?
> 
> Will, perhaps you can get Pawel or Mark to look at this?
> 
> Arnd, I'm sure if we had your Acked-by that would go a long way too.


Sorry for missing this before my vacation.

Reviewed-by: Arnd Bergmann 

Olof, please merge it into arm-soc so we can finally build on top
of this!

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 3/3] ARM: dts: Enable USB host0 (EHCI) on rk3288-evb

[Doug Anderson]

This is the top USB port on the evb (the one closest to the Ethernet
connector).

Signed-off-by: Doug Anderson 
Signed-off-by: Kever Yang 
---
Changes in v2: None

 arch/arm/boot/dts/rk3288-evb.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi 
b/arch/arm/boot/dts/rk3288-evb.dtsi
index e6c5b03..4f57209 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -90,3 +90,7 @@
};
};
 };
+
+&usb_host0_ehci {
+   status = "okay";
+};
-- 
2.0.0.526.g5318336

--
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/3] ARM: dts: add rk3288 ehci usb devices

[Doug Anderson]

From: Kever Yang 

rk3288 has two kind of usb controller; this adds the ehci variant for
host0 and hsic.

At the moment we don't add any phys for these controllers, but the
default settings seem to work OK.

There is a hardware problem in ohci controller which make it
unavailable and host0 controller can only support high-speed devices.

Signed-off-by: Kever Yang 
Signed-off-by: Doug Anderson 
---
Changes in v2:
- Kever is now the author
- Node is now named usb

 arch/arm/boot/dts/rk3288.dtsi | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 3ef8951..e7cb008 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -251,6 +251,26 @@
status = "disabled";
};
 
+   usb_host0_ehci: usb@ff50 {
+   compatible = "generic-ehci";
+   reg = <0xff50 0x100>;
+   interrupts = ;
+   clocks = <&cru HCLK_USBHOST0>;
+   clock-names = "usbhost";
+   status = "disabled";
+   };
+
+   /* NOTE: ohci@ff52 doesn't actually work on hardware */
+
+   usb_hsic: usb@ff5c {
+   compatible = "generic-ehci";
+   reg = <0xff5c 0x100>;
+   interrupts = ;
+   clocks = <&cru HCLK_HSIC>;
+   clock-names = "usbhost";
+   status = "disabled";
+   };
+
gic: interrupt-controller@ffc01000 {
compatible = "arm,gic-400";
interrupt-controller;
-- 
2.0.0.526.g5318336

--
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/3] Enable EHCI port on rk3288-evb

[Doug Anderson]

This series enables the EHCI port on the rk3288-evb boards.  A later
patch series (from Kever) will enable the dwc2 ports.

Changes in v2:
- usb_host_vbus => vcc_host to match supply name, not pin name.
- pin name now matches in name in schematic
- Kever is now the author
- Node is now named usb

Doug Anderson (2):
  ARM: dts: Turn on USB host vbus on rk3288-evb
  ARM: dts: Enable USB host0 (EHCI) on rk3288-evb

Kever Yang (1):
  ARM: dts: add rk3288 ehci usb devices

 arch/arm/boot/dts/rk3288-evb.dtsi | 22 ++
 arch/arm/boot/dts/rk3288.dtsi | 20 
 2 files changed, 42 insertions(+)

-- 
2.0.0.526.g5318336

--
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/3] ARM: dts: Turn on USB host vbus on rk3288-evb

[Doug Anderson]

There is no phy driver that works on the Rockchip board for either USB
host port yet.  For now just hardcode the vbus signal to be on all the
time which makes both the dwc2 host and the EHCI port work.

Signed-off-by: Doug Anderson 
---
Changes in v2:
- usb_host_vbus => vcc_host to match supply name, not pin name.
- pin name now matches in name in schematic

 arch/arm/boot/dts/rk3288-evb.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi 
b/arch/arm/boot/dts/rk3288-evb.dtsi
index 749e20d..e6c5b03 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -35,6 +35,18 @@
debounce-interval = <100>;
};
};
+
+   /* This turns on USB vbus for both host0 (ehci) and host1 (dwc2) */
+   vcc_host: vcc-host-regulator {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&host_vbus_drv>;
+   regulator-name = "vcc_host";
+   regulator-always-on;
+   regulator-boot-on;
+   };
 };
 
 &i2c0 {
@@ -71,4 +83,10 @@
rockchip,pins = <0 5 RK_FUNC_GPIO &pcfg_pull_up>;
};
};
+
+   usb {
+   host_vbus_drv: host-vbus-drv {
+   rockchip,pins = <0 14 RK_FUNC_GPIO &pcfg_pull_none>;
+   };
+   };
 };
-- 
2.0.0.526.g5318336

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

Re: [PATCH 1/3] ARM: dts: Turn on USB host vbus on rk3288-evb

[Doug Anderson]

Heiko,

On Wed, Jul 30, 2014 at 11:24 AM, Heiko Stübner  wrote:
> Hi Doug,
>
> Am Mittwoch, 30. Juli 2014, 08:13:52 schrieb Doug Anderson:
>> On Wed, Jul 30, 2014 at 4:24 AM, Heiko Stübner  wrote:
>> > Am Dienstag, 29. Juli 2014, 16:24:31 schrieb Doug Anderson:
>> >> There is no phy driver that works on the Rockchip board for either USB
>> >> host port yet.  For now just hardcode the vbus signal to be on all the
>> >> time which makes both the dwc2 host and the EHCI port work.
>> >>
>> >> Signed-off-by: Doug Anderson 
>> >> ---
>> >>
>> >>  arch/arm/boot/dts/rk3288-evb.dtsi | 18 ++
>> >>  1 file changed, 18 insertions(+)
>> >>
>> >> diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
>> >> b/arch/arm/boot/dts/rk3288-evb.dtsi index 749e20d..efd625e 100644
>> >> --- a/arch/arm/boot/dts/rk3288-evb.dtsi
>> >> +++ b/arch/arm/boot/dts/rk3288-evb.dtsi
>> >> @@ -35,6 +35,18 @@
>> >>
>> >>   debounce-interval = <100>;
>> >>
>> >>   };
>> >>
>> >>   };
>> >>
>> >> +
>> >> + /* This turns on vbus for both host0 (ehci) and host1 (dwc2) */
>> >> + usb_host_vbus_regulator: usb-host-vbus-regulator {
>> >> + compatible = "regulator-fixed";
>> >> + enable-active-high;
>> >> + gpio = <&gpio0 14 GPIO_ACTIVE_HIGH>;
>> >> + pinctrl-names = "default";
>> >> + pinctrl-0 = <&usb_host_vbus>;
>> >> + regulator-name = "usb-host-vbus";
>> >> + regulator-always-on;
>> >> + regulator-boot-on;
>> >> + };
>> >>
>> >>  };
>> >
>> > It seems I have a slightly outdated schematics pdf for the evb ... and
>> > only
>> > see the OTG vbus pin, on <&gpio0 12>, but am missing the whole host vbus.
>>
>> I have schematics that claim to be from January 25, 2014 and claim to
>> be rev 1.0.  On my schematics:
>>
>> * GPIO0_B4 (12) = OTG_VBUS_DRV = pin 233 of the mainboard connector
>> * GPIO0_B6 (14) = HOST_VBUS_DRV = pin 239 of the mainboard connector
>>
>> On the mainboard schematics I have the OTG signal (233) doesn't
>> actually go to the OTG port.  It goes to a debug header and nowhere
>> else.  The HOST VBUS controls VBUS on both of the two "host" ports.
>>
>> > Could you think about finding another name for the handle? For example, in
>> > my incomplete evb-schematics the supply coming from the otg regulator is
>> > called vcc50_usb and there should be something similar for the host
>> > supply, so I'd like something like
>> >
>> > vcc50_usbhost: usb-host-vbus-regulator { /* or whatever it gets
>> > called */
>> > ...
>> > };
>> >
>> > simply to keep with the supply names defined in the schematics - makes
>> > reading easier.
>>
>> I did!  ;)  ...but I matched my schematics, not yours.  Can you
>> provide the date / version number from your schematics and we can see
>> which is newer?  Just for reference I was emailed schematics last week
>> but that doesn't necessarily guarantee that they're the newest ones.
>
> the schematics I have is "RK3288_BETA", REV 0.2, created in 2014/02/12, last
> changed on 2014/03/04.

OK, yours is clearly newer.


> At least in my schematics on page 16 of 44, the OTG_VBUS_DRV pin leads to a
> switch, that gets supplied by VCC50_BOOST and emits the VCC50_USB .
> So, a later phy node should in the otg case probably have a
> whatever-supply = <&vcc50_usb>;
> and not
> whatever-supply = <&usb_otg_vbus_regulator>

Ah, nice.  I wonder if that's the "2.0" mainboard?  I've seen some
people with that.  I have a "1.0 mainboard".


> And there I'd guess the host supply will probably be structured similarly -
> even if I can't see it right now :-) .
>
>
>> Given the above, I'm not planning to spin this patch unless you
>> confirm you want me to.  Thanks!  :)
>
> I'd like the regulator handle to be named after the supply name, not after the
> pin-name :-) .

Got it.  That means I can use the pin name for the pinctrl, which is nice.

One thing I'm always wary of: hardware designers tend to like to
change the names of things from revision to revision.

-Doug
--
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 0/8] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Hi Ajay,

Am 30.07.2014 08:21, schrieb Ajay kumar:
> On Tue, Jul 29, 2014 at 4:51 PM, Andreas Färber  wrote:
>> Am 28.07.2014 08:13, schrieb Ajay kumar:
>>> On 7/27/14, Andreas Färber  wrote:
 Am 25.07.2014 21:22, schrieb Ajay Kumar:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> I have tested this after adding few DT changes for exynos5250-snow,
> exynos5420-peach-pit and exynos5800-peach-pi boards.

 I'm trying to test this with a modified exynos5250-spring DT based off
 kgene's for-next branch due to DT, and I run into the following:
>>
>> Unfortunately the most I got on Spring with attached DT was a blank
>> screen with a white horizontal line in the middle.
> Then, I think bridge chip is working fine.
> You just need to configure the proper mode for FIMD.
> You can see backlight also, right?
> 
>> Do I need to specify a specific panel model for Spring?
> Yes! Try using "chunghwa,claa101wb01" as compatible string for
> panel node.

With just your v6 applied plus updated DT patch (attached) [1], I see
backlight and a black screen (no white line any more). dmesg attached.

>> For testing I re-applied your iommu patches (which btw fail now for 5420
>> due to disp_pd) but didn't know what to do about your panel-lvds
>> regulator patch now that it's gone.
> Ignore that regulator patch.
> 
> Also, please attach the bootlog if possible after trying this.

If I further apply the IOMMU patches [2], I get no backlight nor USB and
thus can't obtain a boot log.

Regards,
Andreas

[1] https://github.com/afaerber/linux/commits/spring-next
[2] https://github.com/afaerber/linux/commits/spring-bridge.v6

P.S. Note that your Snow DT patch will conflict with my Snow cleanups,
shuffling some nodes around: https://patchwork.kernel.org/patch/4649471/

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>From 64fdedabdfcfa5ac8ec97ab647ccfdd4520430d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= 
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Ajay Kumar 
[AF: Redone for v6]
Signed-off-by: Andreas Färber 
---
 arch/arm/boot/dts/exynos5250-spring.dts | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
index 6d1d175e910e..8baad7ebe739 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -90,6 +90,10 @@
 		samsung,invert-vclk;
 	};
 
+	panel: panel {
+		compatible = "chunghwa,claa101wb01";
+	};
+
 	dp-controller@145B {
 		status = "okay";
 		pinctrl-names = "default";
@@ -101,6 +105,7 @@
 		samsung,link-rate = <0x0a>;
 		samsung,lane-count = <1>;
 		samsung,hpd-gpio = <&gpc3 0 GPIO_ACTIVE_HIGH>;
+		bridge = <&ps8622>;
 	};
 };
 
@@ -405,6 +410,17 @@
 	status = "okay";
 	samsung,i2c-sda-delay = <100>;
 	samsung,i2c-max-bus-freq = <66000>;
+
+	ps8622: lvds-bridge@08 {
+		compatible = "parade,ps8622";
+		reg = <0x08>;
+		sleep-gpios = <&gpc3 6 0>;
+		reset-gpios = <&gpc3 1 0>;
+		lane-count = <1>;
+		panel = <&panel>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ps8622_gpios>;
+	};
 };
 
 &i2c_8 {
@@ -461,11 +477,18 @@
 &pinctrl_0 {
 	dp_hpd_gpio: dp-hpd-gpio {
 		samsung,pins = "gpc3-0";
-		samsung,pin-function = <1>;
+		samsung,pin-function = <0>;
 		samsung,pin-pud = <3>;
 		samsung,pin-drv = <0>;
 	};
 
+	ps8622_gpios: ps8622-gpios {
+		samsung,pins = "gpc3-1", "gpc3-6";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <0>;
+	};
+
 	s5m8767_dvs: s5m8767-dvs {
 		samsung,pins = "gpd1-0", "gpd1-1", "gpd1-2";
 		samsung,pin-function = <0>;
-- 
1.9.3

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.16.0-rc6+ (andr...@chrome11.site) (gcc version 
4.8.2 20140404 [gcc-4_8-branch revision 209122] (SUSE Linux) ) #23 SMP PREEMPT 
Wed Jul 30 20:11:19 CEST 2014
[0.00] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=30c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] Machine model: Google Spring
[0.00] cma: CMA: reserved 64 MiB at 6b80
[0.00] Forcing write-allocate cache policy for SMP
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 523264
[0.00] free_area_init_node: node 0, pgdat c066b400, node_mem_map 
ea7dc000
[0.00]   Normal zone: 1520 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 194560 pages, LIFO batch:31
[0.00]   HighMem zone: 2568 pages used for memmap
[0.00]   HighMem zone: 328704 page

[PATCH] ARM: dts: DRA7: fix interrupt-cells for GPIO

[Nishanth Menon]

GPIO modules are also interrupt sources. However, they require both the
GPIO number and IRQ type to function properly.

By declaring that GPIO uses interrupt-cells=<1>, we essentially do not
allow users of the nodes to use the interrupt property appropritely.

With this change, the following now works:

interrupt-parent = <&gpio6>;
interrupts = <5 IRQ_TYPE_LEVEL_LOW>;

Fixes: 6e58b8f1daaf ('ARM: dts: DRA7: Add the dts files for dra7 SoC and 
dra7-evm board')
Signed-off-by: Nishanth Menon 
---
Based on v3.16-rc7

 arch/arm/boot/dts/dra7.dtsi |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8012763..f21ef39 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -172,7 +172,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
-   #interrupt-cells = <1>;
+   #interrupt-cells = <2>;
};
 
gpio2: gpio@48055000 {
@@ -183,7 +183,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
-   #interrupt-cells = <1>;
+   #interrupt-cells = <2>;
};
 
gpio3: gpio@48057000 {
@@ -194,7 +194,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
-   #interrupt-cells = <1>;
+   #interrupt-cells = <2>;
};
 
gpio4: gpio@48059000 {
@@ -205,7 +205,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
-   #interrupt-cells = <1>;
+   #interrupt-cells = <2>;
};
 
gpio5: gpio@4805b000 {
@@ -216,7 +216,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
-   #interrupt-cells = <1>;
+   #interrupt-cells = <2>;
};
 
gpio6: gpio@4805d000 {
@@ -227,7 +227,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
-   #interrupt-cells = <1>;
+   #interrupt-cells = <2>;
};
 
gpio7: gpio@48051000 {
@@ -238,7 +238,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
-   #interrupt-cells = <1>;
+   #interrupt-cells = <2>;
};
 
gpio8: gpio@48053000 {
@@ -249,7 +249,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
-   #interrupt-cells = <1>;
+   #interrupt-cells = <2>;
};
 
uart1: serial@4806a000 {
-- 
1.7.9.5

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

RE: [PATCH 4/4] usb: dwc2: add dr_mode support for dwc2

[Paul Zimmerman]

> From: Kever Yang [mailto:kever.y...@rock-chips.com]
> Sent: Tuesday, July 29, 2014 6:35 PM
> 
> Some devices with A female host port and without use of usb_id pin
> will need this for the otg controller works as device role
> during firmware period and works as host role in rich os.
> 
> Signed-off-by: Kever Yang 
> ---
>  drivers/usb/dwc2/core.c |   13 +
>  drivers/usb/dwc2/core.h |2 ++
>  drivers/usb/dwc2/platform.c |4 
>  3 files changed, 19 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 27d2c9b..6688951 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -118,6 +118,7 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>  {
>   u32 greset;
>   int count = 0;
> + u32 gusbcfg;
> 
>   dev_vdbg(hsotg->dev, "%s()\n", __func__);
> 
> @@ -148,6 +149,18 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>   }
>   } while (greset & GRSTCTL_CSFTRST);
> 
> + if (hsotg->dr_mode == USB_DR_MODE_HOST) {
> + gusbcfg = readl(hsotg->regs+GUSBCFG);
> + gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
> + gusbcfg |= GUSBCFG_FORCEHOSTMODE;
> + writel(gusbcfg, hsotg->regs+GUSBCFG);
> + } else if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL) {
> + gusbcfg = readl(hsotg->regs+GUSBCFG);
> + gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
> + gusbcfg |= GUSBCFG_FORCEDEVMODE;
> + writel(gusbcfg, hsotg->regs+GUSBCFG);
> + }

Please put spaces around the '+' operator. Did you run these patches
through checkpatch?

> +
>   /*
>* NOTE: This long sleep is _very_ important, otherwise the core will
>* not stay in host mode after a connector ID change!
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 1efd10c..9fe960b 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -501,6 +501,7 @@ struct dwc2_hw_params {
>   *  a_peripheral and b_device=>b_host) this may not match
>   *  the core, but allows the software to determine
>   *  transitions
> + * @dr_mode:requested mode of operation

Please expand this comment, e.g.
"Requested mode of operation (host/peripheral/dual-role)"

-- 
Paul

--
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] usb: dwc2: add compatible data for rockchip soc

[Paul Zimmerman]

> From: Kever Yang [mailto:kever.y...@rock-chips.com]
> Sent: Tuesday, July 29, 2014 6:35 PM
> 
> This patch add compatible data for dwc2 controller found on
> rk3066, rk3188 and rk3288 processors from rockchip.
> 
> Signed-off-by: Kever Yang 
> ---
>  drivers/usb/dwc2/platform.c |   29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index a10e7a3..cc5983c 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -75,6 +75,34 @@ static const struct dwc2_core_params params_bcm2835 = {
>   .uframe_sched   = 0,
>  };
> 
> +static const struct dwc2_core_params params_rk3066 = {
> + .otg_cap= 2,/* no HNP/SRP capable */
> + .otg_ver= 0,/* 1.3 */
> + .dma_enable = 1,
> + .dma_desc_enable= 0,
> + .speed  = 0,/* High Speed */
> + .enable_dynamic_fifo= 1,
> + .en_multiple_tx_fifo= 1,
> + .host_rx_fifo_size  = 520,  /* 520 DWORDs */
> + .host_nperio_tx_fifo_size   = 128,  /* 128 DWORDs */
> + .host_perio_tx_fifo_size= 256,  /* 256 DWORDs */
> + .max_transfer_size  = 65536,
> + .max_packet_count   = 512,
> + .host_channels  = 9,
> + .phy_type   = 1,/* UTMI */
> + .phy_utmi_width = 16,   /* 8 bits */

The comment doesn't match the value.

> + .phy_ulpi_ddr   = 0,/* Single */
> + .phy_ulpi_ext_vbus  = 0,
> + .i2c_enable = 0,
> + .ulpi_fs_ls = 0,
> + .host_support_fs_ls_low_power   = 0,
> + .host_ls_low_power_phy_clk  = 0,/* 48 MHz */
> + .ts_dline   = 0,
> + .reload_ctl = 1,
> + .ahbcfg = 0x17, /* dma enable &  INCR16 */

Don't set the dma enable bit here, the driver will set that bit
according to the '.dma_enable' member above.

-- 
Paul

--
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] Documentation: dt-bindings: add dt binding info for Rockchip dwc2

[Paul Zimmerman]

> From: Kever Yang [mailto:kever.y...@rock-chips.com]
> Sent: Tuesday, July 29, 2014 6:31 PM
> 
> This add necessary dwc2 binding documentation for Rockchip socs:
> rk3066, rk3188 and rk3288
> 
> add dr_mode as optional properties.
> 
> Signed-off-by: Kever Yang 
> ---
>  Documentation/devicetree/bindings/usb/dwc2.txt |5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt
> b/Documentation/devicetree/bindings/usb/dwc2.txt
> index aa91034..eb80d7b 100644
> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
> @@ -4,6 +4,9 @@ Platform DesignWare HS OTG USB 2.0 controller
>  Required properties:
>  - compatible : One of:
>- brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC.
> +  - rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc;
> +  - "rockchip,rk3188-usb","rockchip,rk3066-usb": for rk3188 Soc;
> +  - "rockchip,rk3288-usb","rockchip,rk3066-usb": for rk3288 Soc;
>- snps,dwc2: A generic DWC2 USB controller with default parameters.

Do you really need three different bindings here? I believe the 
recommended approach is to define one binding for the common case, and
reuse it for similar SOCs. Additional bindings should only be added if
there is some difference in the SOC that requires it.

>  - reg : Should contain 1 register range (address and length)
>  - interrupts : Should contain 1 interrupt
> @@ -15,6 +18,8 @@ Optional properties:
>  - phys: phy provider specifier
>  - phy-names: shall be "usb2-phy"
>  Refer to phy/phy-bindings.txt for generic phy consumer properties
> +- dr_mode: shall be one of "host", "peripheral" and "otg"

I don't see where you use 'dr_mode' in any of the DTS files. Are you
going to add the uses later? And please us a more descriptive name,
such as 'dual-role-mode'.

-- 
Paul

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

Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC

[Mark Rutland]

On Wed, Jul 30, 2014 at 07:12:17PM +0100, Olof Johansson wrote:
> On Wed, Jul 30, 2014 at 8:06 AM, Robert Richter  wrote:
> > From: Radha Mohan Chintakuntla 
> >
> > Add initial device tree nodes for Cavium Thunder SoCs with support of
> > 48 cores and gicv3. The dts file requires further changes, esp. for
> > pci, gicv3-its and smmu. This changes will be added later together
> > with the device drivers.
> >
> > Signed-off-by: Radha Mohan Chintakuntla 
> > Signed-off-by: Robert Richter 
> > ---
> >  arch/arm64/boot/dts/Makefile |   1 +
> >  arch/arm64/boot/dts/thunder-88xx.dts | 387 
> > +++
> >  2 files changed, 388 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts
> >
> > diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> > index c52bdb051f66..f8001a62029c 100644
> > --- a/arch/arm64/boot/dts/Makefile
> > +++ b/arch/arm64/boot/dts/Makefile
> > @@ -1,3 +1,4 @@
> > +dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
> >  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
> >  dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
> >
> > diff --git a/arch/arm64/boot/dts/thunder-88xx.dts 
> > b/arch/arm64/boot/dts/thunder-88xx.dts
> > new file mode 100644
> > index ..4cf20ac9138b
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/thunder-88xx.dts
> > @@ -0,0 +1,387 @@
> > +/*
> > + * Cavium Thunder DTS file
> > + *
> > + * Copyright (C) 2013, Cavium Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of
> > + * the License, or (at your option) any later version.
> > + */
> > +/dts-v1/;
> > +
> > +/* Reserving first 12MB of DDR for firmware */
> > +/memreserve/ 0x 0x00c0;
> > +
> > +/ {
> > +   model = "Cavium ThunderX CN88XX Family";
> > +   compatible = "cavium,thunder-88xx";
> 
> Hmm. I take it this platform is compliant with some level of SBSA? We
> should probably have a compatible value for that so that platforms can
> communicate it.
> 
> Mark, are there already plans for this?

Not so far, but my monitor now has a sticky note telling me to look into
it. :)

Many of the useful properties provided by SBSA are already described
elsewhere (e.g. page and ASID size can be found in ID registers), and
hardware properties it mandates (e.g. PPI assignment for level 2
compliant systems) will be described elsewhere.

I'll have to read the spec in more detail to figure out what we can
derive from an SBSA compliance property. Regardless it probably makes
sense to have a compatible string or other property on the root node; at
worst it only costs us a few bytes.

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

Re: [PATCH 1/3] ARM: dts: Turn on USB host vbus on rk3288-evb

[Heiko Stübner]

Hi Doug,

Am Mittwoch, 30. Juli 2014, 08:13:52 schrieb Doug Anderson:
> On Wed, Jul 30, 2014 at 4:24 AM, Heiko Stübner  wrote:
> > Am Dienstag, 29. Juli 2014, 16:24:31 schrieb Doug Anderson:
> >> There is no phy driver that works on the Rockchip board for either USB
> >> host port yet.  For now just hardcode the vbus signal to be on all the
> >> time which makes both the dwc2 host and the EHCI port work.
> >> 
> >> Signed-off-by: Doug Anderson 
> >> ---
> >> 
> >>  arch/arm/boot/dts/rk3288-evb.dtsi | 18 ++
> >>  1 file changed, 18 insertions(+)
> >> 
> >> diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
> >> b/arch/arm/boot/dts/rk3288-evb.dtsi index 749e20d..efd625e 100644
> >> --- a/arch/arm/boot/dts/rk3288-evb.dtsi
> >> +++ b/arch/arm/boot/dts/rk3288-evb.dtsi
> >> @@ -35,6 +35,18 @@
> >> 
> >>   debounce-interval = <100>;
> >>   
> >>   };
> >>   
> >>   };
> >> 
> >> +
> >> + /* This turns on vbus for both host0 (ehci) and host1 (dwc2) */
> >> + usb_host_vbus_regulator: usb-host-vbus-regulator {
> >> + compatible = "regulator-fixed";
> >> + enable-active-high;
> >> + gpio = <&gpio0 14 GPIO_ACTIVE_HIGH>;
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&usb_host_vbus>;
> >> + regulator-name = "usb-host-vbus";
> >> + regulator-always-on;
> >> + regulator-boot-on;
> >> + };
> >> 
> >>  };
> > 
> > It seems I have a slightly outdated schematics pdf for the evb ... and
> > only
> > see the OTG vbus pin, on <&gpio0 12>, but am missing the whole host vbus.
> 
> I have schematics that claim to be from January 25, 2014 and claim to
> be rev 1.0.  On my schematics:
> 
> * GPIO0_B4 (12) = OTG_VBUS_DRV = pin 233 of the mainboard connector
> * GPIO0_B6 (14) = HOST_VBUS_DRV = pin 239 of the mainboard connector
> 
> On the mainboard schematics I have the OTG signal (233) doesn't
> actually go to the OTG port.  It goes to a debug header and nowhere
> else.  The HOST VBUS controls VBUS on both of the two "host" ports.
> 
> > Could you think about finding another name for the handle? For example, in
> > my incomplete evb-schematics the supply coming from the otg regulator is
> > called vcc50_usb and there should be something similar for the host
> > supply, so I'd like something like
> > 
> > vcc50_usbhost: usb-host-vbus-regulator { /* or whatever it gets
> > called */
> > ...
> > };
> > 
> > simply to keep with the supply names defined in the schematics - makes
> > reading easier.
> 
> I did!  ;)  ...but I matched my schematics, not yours.  Can you
> provide the date / version number from your schematics and we can see
> which is newer?  Just for reference I was emailed schematics last week
> but that doesn't necessarily guarantee that they're the newest ones.

the schematics I have is "RK3288_BETA", REV 0.2, created in 2014/02/12, last 
changed on 2014/03/04.

At least in my schematics on page 16 of 44, the OTG_VBUS_DRV pin leads to a 
switch, that gets supplied by VCC50_BOOST and emits the VCC50_USB .
So, a later phy node should in the otg case probably have a
whatever-supply = <&vcc50_usb>;
and not
whatever-supply = <&usb_otg_vbus_regulator>


And there I'd guess the host supply will probably be structured similarly - 
even if I can't see it right now :-) .


> Given the above, I'm not planning to spin this patch unless you
> confirm you want me to.  Thanks!  :)

I'd like the regulator handle to be named after the supply name, not after the 
pin-name :-) .


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

[PATCHv9 3/3] arm: dts: Add Altera SDRAM controller bindings

[tthayer]

From: Thor Thayer 

Add the Altera SDRAM controller bindings and device tree changes to the Altera 
SoC project.

Signed-off-by: Thor Thayer 
---
v2: Changes to SoC SDRAM EDAC code.

v3: Implement code suggestions for SDRAM EDAC code.

v4: Remove syscon from SDRAM controller bindings.

v5: No Change, bump version for consistency.

v6: Only map the ctrlcfg register as syscon.

v7: No change. Bump for consistency.

v8: No change. Bump for consistency.

v9: Changes to support a MFD SDRAM controller with nested EDAC.
---
 .../devicetree/bindings/arm/altera/socfpga-sdr.txt |   13 +
 arch/arm/boot/dts/socfpga.dtsi |   10 ++
 2 files changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-sdr.txt

diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-sdr.txt 
b/Documentation/devicetree/bindings/arm/altera/socfpga-sdr.txt
new file mode 100644
index 000..2bb1ddf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdr.txt
@@ -0,0 +1,13 @@
+Altera SOCFPGA SDRAM Controller
+The SDRAM controller is implemented as a MFD so various drivers may
+nest under this main SDRAM controller binding.
+
+Required properties:
+- compatible : "altr,sdr";
+- reg : Should contain 1 register range(address and length)
+
+Example:
+   sdr@0xffc25000 {
+   compatible = "altr,sdr";
+   reg = <0xffc25000 0x1000>;
+   };
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 4676f25..ecb306d 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -603,6 +603,16 @@
};
};
 
+   sdr@0xffc25000 {
+   compatible = "altr,sdr";
+   reg = <0xffc25000 0x1000>;
+
+   sdramedac@0 {
+   compatible = "altr,sdram-edac";
+   interrupts = <0 39 4>;
+   };
+   };
+
L2: l2-cache@fffef000 {
compatible = "arm,pl310-cache";
reg = <0xfffef000 0x1000>;
-- 
1.7.9.5

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

Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings

[Mark Rutland]

[...]

> >> +Multiple-master IOMMU:
> >> +--
> >> +
> >> + iommu {
> >> + /* the specifier represents the ID of the master */
> >> + #iommu-cells = <1>;
> >> + };
> >> +
> >> + master@1 {
> >> + /* device has master ID 42 in the IOMMU */
> >> + iommus = <&/iommu 42>;
> >> + };
> >> +
> >> + master@2 {
> >> + /* device has master IDs 23 and 24 in the IOMMU */
> >> + iommus = <&/iommu 23>, <&/iommu 24>;
> >> + };
> >
> > In future I suspect master will need to be able to identify which master
> > IDs correspond to which of their master ports (where each port might
> > have an arbitrary number of master IDs).
> >
> > While we don't need that for the first run, it would be nice to have
> > that looked into so master bindings don't come up with arbitrarily
> > different ways of doing that.
> 
> iommu-names would be the logical extension to handle that, just like
> we do with other resources, right?

Possibly. If the master has multiple IDs assigned to transactions from a
single master port then it depends on how the master wants to group
those for the sake of the binding. If it's per-port then you'd need the
same name multiple times:

iommus = <&iommu 0>, <&iommu 4>, <&iommu 17>, <&iommu 25>;
iommu-names = "video", "video", "dram", dram";

This is really specific to a given master, so we can table that until
the first master appears which needs to distinguish between IDs.

> >> +
> >> +Multiple-master IOMMU with configurable DMA window:
> >> +---
> >> +
> >> + / {
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> +
> >> + iommu {
> >> + /* master ID, address and length of DMA window */
> >> + #iommu-cells = <4>;
> >> + };
> >> +
> >> + master {
> >> + /* master ID 42, 4 GiB DMA window starting at 0 */
> >> + iommus = <&/iommu  42  0  0x1 0x0>;
> >
> > Is this that window is from the POV of the master, i.e. the master can
> > address 0x0 to 0x when generating transactions, and these get
> > translated somehow?
> >
> > Or is this the physical addresses to allocate to the master?
> 
> It needs to be clarified in the documentation, but as far as I know it
> is the DMA address space that is used.

Ok. So that's pre-translation, from the POV of the master?

If we don't have that knowledge about the master already (e.g. based on
the compatible string), surely we always need that information in a
given iommu-specifier format? Otherwise certain iommus won't be able to
handle masters with limited addressing only due to limitations of their
binding.

> It is somewhat confusing to have size-cells = 1 and then use 2 cells
> for size in the iommu property. It's legal and expected, but having
> size-cells in the example adds a little confusion.
> 
> Either way, I'm OK with fixing the above with an incremental patch,
> assuming there is no disagreements on what's said above.

I like the general idea.

Given my concerns are to do with implementation details I'm happy to
have this go through and fix it up as the first implementations of the
binding take shape.

Thanks,
Mark.
--
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

[PATCHv9 0/3] Addition of Altera EDAC support.

[tthayer]

From: Thor Thayer 

The Altera SDRAM controller and EDAC support are added in this
patch series. The SDRAM controller is an MFD so that multiple
drivers can access it's registers.

Thor Thayer (3):
  mfd: altera: Add Altera SDRAM Controller
  edac: altera: Add Altera EDAC support.
  arm: dts: Add Altera SDRAM controller bindings

 .../devicetree/bindings/arm/altera/socfpga-sdr.txt |   13 +
 MAINTAINERS|6 +
 arch/arm/boot/dts/socfpga.dtsi |   10 +
 drivers/edac/Kconfig   |   10 +
 drivers/edac/Makefile  |2 +
 drivers/edac/altera_edac.c |  293 
 drivers/mfd/Kconfig|7 +
 drivers/mfd/Makefile   |1 +
 drivers/mfd/altera-sdr.c   |  162 +++
 include/linux/mfd/altera-sdr.h |  102 +++
 10 files changed, 606 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-sdr.txt
 create mode 100644 drivers/edac/altera_edac.c
 create mode 100644 drivers/mfd/altera-sdr.c
 create mode 100644 include/linux/mfd/altera-sdr.h

-- 
1.7.9.5

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

[PATCHv9 1/3] mfd: altera: Add Altera SDRAM Controller

[tthayer]

From: Thor Thayer 

Add a simple MFD for the Altera SDRAM Controller.

Signed-off-by: Alan Tull 
Signed-off-by: Thor Thayer 
---
v1-8: The MFD implementation was not included in the original series.

v9: New MFD implementation.
---
 MAINTAINERS|5 ++
 drivers/mfd/Kconfig|7 ++
 drivers/mfd/Makefile   |1 +
 drivers/mfd/altera-sdr.c   |  162 
 include/linux/mfd/altera-sdr.h |  102 +
 5 files changed, 277 insertions(+)
 create mode 100644 drivers/mfd/altera-sdr.c
 create mode 100644 include/linux/mfd/altera-sdr.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 86efa7e..48a8923 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1340,6 +1340,11 @@ M:   Dinh Nguyen 
 S: Maintained
 F: drivers/clk/socfpga/
 
+ARM/SOCFPGA SDRAM CONTROLLER SUPPORT
+M: Thor Thayer 
+S: Maintained
+F: drivers/mfd/altera-sdr.c
+
 ARM/STI ARCHITECTURE
 M: Srinivas Kandagatla 
 M: Maxime Coquelin 
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6cc4b6a..8ce4961 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -719,6 +719,13 @@ config MFD_STMPE
Keypad: stmpe-keypad
Touchscreen: stmpe-ts
 
+config MFD_ALTERA_SDR
+   bool "Altera SDRAM Controller MFD"
+   depends on ARCH_SOCFPGA
+   select MFD_CORE
+   help
+ Support for Altera SDRAM Controller (SDR) MFD.
+
 menu "STMicroelectronics STMPE Interface Drivers"
 depends on MFD_STMPE
 
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8afedba..24cc2b7 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -169,3 +169,4 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
 obj-$(CONFIG_MFD_AS3722)   += as3722.o
 obj-$(CONFIG_MFD_STW481X)  += stw481x.o
 obj-$(CONFIG_MFD_IPAQ_MICRO)   += ipaq-micro.o
+obj-$(CONFIG_MFD_ALTERA_SDR)   += altera-sdr.o
diff --git a/drivers/mfd/altera-sdr.c b/drivers/mfd/altera-sdr.c
new file mode 100644
index 000..b5c6646
--- /dev/null
+++ b/drivers/mfd/altera-sdr.c
@@ -0,0 +1,162 @@
+/*
+ * SDRAM Controller (SDR) MFD
+ *
+ * Copyright (C) 2014 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct mfd_cell altera_sdr_devs[] = {
+#if defined(CONFIG_EDAC_ALTERA_MC)
+   {
+   .name = "altr_sdram_edac",
+   .of_compatible = "altr,sdram-edac",
+   },
+#endif
+};
+
+u32 altera_sdr_readl(struct altera_sdr *sdr, u32 reg_offset)
+{
+   return readl(sdr->reg_base + reg_offset);
+}
+EXPORT_SYMBOL_GPL(altera_sdr_readl);
+
+void altera_sdr_writel(struct altera_sdr *sdr, u32 reg_offset, u32 value)
+{
+   writel(value, sdr->reg_base + reg_offset);
+}
+EXPORT_SYMBOL_GPL(altera_sdr_writel);
+
+/* Get total memory size in bytes */
+u32 altera_sdr_mem_size(struct altera_sdr *sdr)
+{
+   u32 size;
+   u32 read_reg, row, bank, col, cs, width;
+
+   read_reg = altera_sdr_readl(sdr, SDR_DRAMADDRW_OFST);
+   if (read_reg < 0)
+   return 0;
+
+   width = altera_sdr_readl(sdr, SDR_DRAMIFWIDTH_OFST);
+   if (width < 0)
+   return 0;
+
+   col = (read_reg & SDR_DRAMADDRW_COLBITS_MASK) >>
+   SDR_DRAMADDRW_COLBITS_LSB;
+   row = (read_reg & SDR_DRAMADDRW_ROWBITS_MASK) >>
+   SDR_DRAMADDRW_ROWBITS_LSB;
+   bank = (read_reg & SDR_DRAMADDRW_BANKBITS_MASK) >>
+   SDR_DRAMADDRW_BANKBITS_LSB;
+   cs = (read_reg & SDR_DRAMADDRW_CSBITS_MASK) >>
+   SDR_DRAMADDRW_CSBITS_LSB;
+
+   /* Correct for ECC as its not addressible */
+   if (width == SDR_DRAMIFWIDTH_32B_ECC)
+   width = 32;
+   if (width == SDR_DRAMIFWIDTH_16B_ECC)
+   width = 16;
+
+   /* calculate the SDRAM size base on this info */
+   size = 1 << (row + bank + col);
+   size = size * cs * (width / 8);
+   return size;
+}
+EXPORT_SYMBOL_GPL(altera_sdr_mem_size);
+
+static int altera_sdr_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct altera_sdr *sdr;
+   struct resource *res;
+   void __iomem *base;
+   int ret;
+
+   sdr = devm_kzalloc(dev, sizeof(*sdr), GFP_KERNEL);
+   if (!sdr)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_ME

[PATCHv9 2/3] edac: altera: Add Altera EDAC support.

[tthayer]

From: Thor Thayer 

This patch adds support for the CycloneV and ArriaV SDRAM controllers.
Correction and reporting of SBEs, Panic on DBEs.

Signed-off-by: Thor Thayer 
---
v2: Use the SDRAM controller registers to calculate memory size
instead of the Device Tree. Update To & Cc list. Add maintainer
information.

v3: EDAC driver cleanup based on comments from Mailing list.

v4: Panic on DBE. Add macro around inject-error reads to prevent
them from being optimized out. Remove of_match_ptr since this
will always use Device Tree.

v5: Addition of printk to trigger function to ensure read vars
are not optimized out.

v6: Changes to split out shared SDRAM controller reg (offset 0x00)
as a syscon device and allocate ECC specific SDRAM registers
to EDAC.

v7: No changes. Bump for consistency.

v8: Alphabetize headers.

v9: Move Altera EDAC driver to use SDRAM MFD device since controller
registers are shared between different drivers.
---
 MAINTAINERS|1 +
 drivers/edac/Kconfig   |   10 ++
 drivers/edac/Makefile  |2 +
 drivers/edac/altera_edac.c |  293 
 4 files changed, 306 insertions(+)
 create mode 100644 drivers/edac/altera_edac.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 48a8923..7fde28b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1344,6 +1344,7 @@ ARM/SOCFPGA SDRAM CONTROLLER SUPPORT
 M: Thor Thayer 
 S: Maintained
 F: drivers/mfd/altera-sdr.c
+F: drivers/edac/altera_edac.c
 
 ARM/STI ARCHITECTURE
 M: Srinivas Kandagatla 
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 878f090..429e244 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -368,4 +368,14 @@ config EDAC_OCTEON_PCI
  Support for error detection and correction on the
  Cavium Octeon family of SOCs.
 
+config EDAC_ALTERA_MC
+   bool "Altera SDRAM Memory Controller EDAC"
+   depends on EDAC_MM_EDAC && ARCH_SOCFPGA
+   select MFD_ALTERA_SDR
+   help
+ Support for error detection and correction on the
+ Altera SDRAM memory controller. Note that the
+ preloader must initialize the SDRAM before loading
+ the kernel.
+
 endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 4154ed6..70845c4 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -64,3 +64,5 @@ obj-$(CONFIG_EDAC_OCTEON_PC)  += octeon_edac-pc.o
 obj-$(CONFIG_EDAC_OCTEON_L2C)  += octeon_edac-l2c.o
 obj-$(CONFIG_EDAC_OCTEON_LMC)  += octeon_edac-lmc.o
 obj-$(CONFIG_EDAC_OCTEON_PCI)  += octeon_edac-pci.o
+
+obj-$(CONFIG_EDAC_ALTERA_MC)   += altera_edac.o
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
new file mode 100644
index 000..602ae62
--- /dev/null
+++ b/drivers/edac/altera_edac.c
@@ -0,0 +1,293 @@
+/*
+ *  Copyright Altera Corporation (C) 2014. All rights reserved.
+ *  Copyright 2011-2012 Calxeda, 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.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ *
+ * Adapted from the highbank_mc_edac driver.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "edac_core.h"
+#include "edac_module.h"
+
+#define EDAC_MOD_STR   "altera_edac"
+#define EDAC_VERSION   "1"
+
+/* Altera SDRAM Memory Controller data */
+struct altr_sdram_mc_data {
+   struct altera_sdr *sdr;
+};
+
+static irqreturn_t altr_sdram_mc_err_handler(int irq, void *dev_id)
+{
+   struct mem_ctl_info *mci = dev_id;
+   struct altr_sdram_mc_data *drvdata = mci->pvt_info;
+   u32 status, err_count, err_addr;
+
+   /* Error Address is shared by both SBE & DBE */
+   err_addr = altera_sdr_readl(drvdata->sdr, SDR_ERRADDR_OFST);
+   status = altera_sdr_readl(drvdata->sdr, SDR_DRAMSTS_OFST);
+
+   if (status & SDR_DRAMSTS_DBEERR) {
+   err_count = altera_sdr_readl(drvdata->sdr, SDR_DBECOUNT_OFST);
+   panic("\nEDAC: [%d Uncorrectable errors @ 0x%08X]\n",
+ err_count, err_addr);
+   }
+   if (status & SDR_DRAMSTS_SBEERR) {
+   err_count = altera_sdr_readl(drvdata->sdr, SDR_SBECOUNT_OFST);
+   edac_mc_handle_error(HW_EVENT_ERR_CORRECTED, mci, err_count,
+err_addr >> PAGE_SHIFT,
+err_addr & ~PAGE_MASK, 0,
+ 

Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC

[Olof Johansson]

On Wed, Jul 30, 2014 at 8:06 AM, Robert Richter  wrote:
> From: Radha Mohan Chintakuntla 
>
> Add initial device tree nodes for Cavium Thunder SoCs with support of
> 48 cores and gicv3. The dts file requires further changes, esp. for
> pci, gicv3-its and smmu. This changes will be added later together
> with the device drivers.
>
> Signed-off-by: Radha Mohan Chintakuntla 
> Signed-off-by: Robert Richter 
> ---
>  arch/arm64/boot/dts/Makefile |   1 +
>  arch/arm64/boot/dts/thunder-88xx.dts | 387 
> +++
>  2 files changed, 388 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts
>
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index c52bdb051f66..f8001a62029c 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,3 +1,4 @@
> +dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
>  dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb

Oh, and:

Let's fix the mistake we made on 32-bit here (that we can't undo
unless we move all dts files now, which is too much churn), and put
each SoC vendor in its own subdirectory.

So, please add a arch/arm64/boot/dts/cavium/ directory, add a Makefile
and the dts there.

We should move vexpress under arm/   and xgene under apm/ too.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC

[Olof Johansson]

On Wed, Jul 30, 2014 at 8:06 AM, Robert Richter  wrote:
> From: Radha Mohan Chintakuntla 
>
> Add initial device tree nodes for Cavium Thunder SoCs with support of
> 48 cores and gicv3. The dts file requires further changes, esp. for
> pci, gicv3-its and smmu. This changes will be added later together
> with the device drivers.
>
> Signed-off-by: Radha Mohan Chintakuntla 
> Signed-off-by: Robert Richter 
> ---
>  arch/arm64/boot/dts/Makefile |   1 +
>  arch/arm64/boot/dts/thunder-88xx.dts | 387 
> +++
>  2 files changed, 388 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts
>
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index c52bdb051f66..f8001a62029c 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,3 +1,4 @@
> +dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
>  dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
>
> diff --git a/arch/arm64/boot/dts/thunder-88xx.dts 
> b/arch/arm64/boot/dts/thunder-88xx.dts
> new file mode 100644
> index ..4cf20ac9138b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/thunder-88xx.dts
> @@ -0,0 +1,387 @@
> +/*
> + * Cavium Thunder DTS file
> + *
> + * Copyright (C) 2013, Cavium Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +/dts-v1/;
> +
> +/* Reserving first 12MB of DDR for firmware */
> +/memreserve/ 0x 0x00c0;
> +
> +/ {
> +   model = "Cavium ThunderX CN88XX Family";
> +   compatible = "cavium,thunder-88xx";

Hmm. I take it this platform is compliant with some level of SBSA? We
should probably have a compatible value for that so that platforms can
communicate it.

Mark, are there already plans for this?


-Olof
--
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] devicetree: Add generic IOMMU device tree bindings

[Rob Herring]

On Wed, Jul 30, 2014 at 9:30 AM, Will Deacon  wrote:
> On Wed, Jul 30, 2014 at 02:23:50PM +0100, Thierry Reding wrote:
>> On Wed, Jul 30, 2014 at 12:04:25PM +0100, Will Deacon wrote:
>> > On Fri, Jul 04, 2014 at 04:29:17PM +0100, Thierry Reding wrote:
>> > > From: Thierry Reding 
>> > >
>> > > This commit introduces a generic device tree binding for IOMMU devices.
>> > > Only a very minimal subset is described here, but it is enough to cover
>> > > the requirements of both the Exynos System MMU and Tegra SMMU as
>> > > discussed here:
>> > >
>> > > https://lkml.org/lkml/2014/4/27/346
>> > >
>> > > Signed-off-by: Thierry Reding 
>> > > ---
>> > > Changes in v4:
>> > > - clarify that disabling an IOMMU DT node may not disable translation
>> > > - be more explicit that examples are only examples
>> > > - add multi-ID master example
>> > >
>> > > Changes in v3:
>> > > - use #iommu-cells instead of #address-cells/#size-cells
>> > > - drop optional iommu-names property
>> > >
>> > > Changes in v2:
>> > > - add notes about "dma-ranges" property (drop note from commit message)
>> > > - document priorities of "iommus" property vs. "dma-ranges" property
>> > > - drop #iommu-cells in favour of #address-cells and #size-cells
>> > > - remove multiple-master device example
>> > >
>> > >  Documentation/devicetree/bindings/iommu/iommu.txt | 172 
>> > > ++
>> > >  1 file changed, 172 insertions(+)
>> > >  create mode 100644 Documentation/devicetree/bindings/iommu/iommu.txt
>> >
>> > I'm concerned that this patch hasn't been picked up for 3.17 (I can't see 
>> > it
>> > in -next). If we want to move the ARM SMMU driver over to this new binding,
>> > we can't keep dragging our feet for much longer as I *really* don't plan to
>> > support two bindings in parallel (one is complicated enough already).
>> >
>> > Any chance we can see this merged, please?
>>
>> I think there weren't any comments left for me to address and I've
>> mostly been waiting for Joerg to pick it up.
>>
>> Joerg, can you take this through the iommu tree for 3.17? Will acked
>> this, but perhaps you were waiting for an ACK from the device tree
>> bindings maintainers?
>
> Rob, Mark: can one or both of you take a look at this please?

I've been quiet on this round, but I think prior input I've had has
been addressed. If we believe this will work for ARM SMMU and MSM
IOMMU and some of the crazy chaining scenarios, then I'm fine with the
binding.

Acked-by: Rob Herring 

Rob

P.S. Thankfully, there are no Calxeda systems with the SMMU enabled,
so a binding change should not cause much pain.
--
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] ARM: dts: add rk3288 dwc2 controller support

[Sergei Shtylyov]

On 07/30/2014 07:18 PM, Sergei Shtylyov wrote:


rk3288 has two kind of usb controller, this add the dwc2 controller
for otg and host1.



Controller can works with usb PHY default setting and Vbus on.



Signed-off-by: Kever Yang 
---
  arch/arm/boot/dts/rk3288.dtsi |   20 
  1 file changed, 20 insertions(+)



diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index abc51f5..4309c4f 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -646,5 +646,25 @@
  clock-names = "baudclk", "apb_pclk";
  status = "disabled";
  };
+
+usb_otg: dwc2@ff58 {



The ePAPR standard [1] says:



The name of a node should be somewhat generic, reflecting the function of the
device and not its precise programming model. If appropriate, the name should
be one of the following choices:



[...]
• usb



+compatible = "rockchip,rk3288-usb", "rockchip,rk3066-usb",
+"snps,dwc2";
+reg = <0xff58 0x4>;
+interrupts = ;
+clocks = <&cru HCLK_OTG0>;
+clock-names = "otg";
+status = "disabled";
+};
+
+usb_host1: dwc2@ff54 {



Same here.


   Oops, forgot to give the ePAPR link:

[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei

--
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] clk: initial clock driver for TWL6030

[Mark Brown]

On Wed, Jul 30, 2014 at 04:02:29PM +0200, Stefan Assmann wrote:

> +static int twl6030_clk32kg_is_prepared(struct clk_hw *hw)
> +{
> + struct twl6030_desc *desc = to_twl6030_desc(hw);
> +
> + return desc->enabled;
> +}

Why not just check the register map - can't the register be cached?  If
that's not possible a comment would be good.

> +static int of_twl6030_clk32kg_probe(struct platform_device *pdev)
> +{
> + struct device_node *node = pdev->dev.of_node;
> + struct clk *clk;
> + int ret = 0;
> +
> + if (!node)
> + return -ENODEV;
> +
> + clk = clk_get(&pdev->dev, "clk32kg");

devm_clk_get()?

> + if (IS_ERR(clk))
> + ret = -EPROBE_DEFER;

Shouldn't the provided return code be being used?

> + else
> + clk_prepare(clk);

Why is the clock driver defaulting to enabling the clock, and if it
needs to shouldn't it be doing a prepere_enable() even if the enable
happens not to do anything to the hardware?  Otherwise child clocks
might get confused.

The return value is also not being checked.


signature.asc
Description: Digital signature

Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC

[Mark Rutland]

[...]

> >> + gic0: interrupt-controller@8010 {
> >
> > To make this easier to read, please place a comma between 32-bit
> > portions of the unit address (e.g. here have 8010,).
> 
> Mark, perhaps a dtc or checkpatch.pl check for this?

Sure. Dodgy first atttempt at checkpatch below.

>8
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 182be0f..8aee3f5 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2136,6 +2136,14 @@ sub process {
}
}
 
+# check for difficult-to-read unit-addresses
+   if (defined $root &&
+   ($realfile =~ /\.dtsi?$/ && $line =~ 
/([a-z0-9._\-+]++@([0-9a-f]+))\s*{/gi) &&
+   (length($2) > 8)) {
+   WARN("LONG_DT_UNIT_ADDRESS",
+"Consider splitting long unit address 
\"$2\" with a comma between cells\n" . $herecurr);
+   }
+
 # check we are in a valid source file if not then ignore this hunk
next if ($realfile !~ /\.(h|c|s|S|pl|sh)$/);
8<

It would also be nice to check matching unit-address and reg, but doing
that correctly requires knowing #address-cells, which sounds a little
painful.

I'm not sure where I picked up the comma convention, as it doesn't seem
to be in ePAPR.  It does seem common though, and is my personal
preference:

[mark@leverpostej:~/src/linux]% git grep '@[a-z0-9]\+,[a-b0-9]\+' \ 
 
-- arch/arm/boot/dts | wc -l
254
[mark@leverpostej:~/src/linux]% git grep '@[a-z0-9]\+,[a-b0-9]\+' \
-- arch/powerpc/boot/dts | wc -l
370
[mark@leverpostej:~/src/linux]% git grep '@[a-z0-9]\+,[a-b0-9]\+' \
-- arch/*/boot/dts | wc -l
631

[...]

> >> + uaa0: serial@87e02400 {
> >> + compatible = "arm,pl011", "arm,primecell";
> >> + reg = <0x87e0 0x2400 0x0 0x1000>;
> >> + interrupts = <1 21 4>;
> >> + clocks = <&refclk50mhz>;
> >> + clock-names = "apb_pclk";
> >
> > Is this actually the apb_pclk, or is the the uartclk? I assume it's the
> > latter.
> 
> Shouldn't new bindings have both clocks here? A single clock was a
> mistake I think (mine in fact).

I don't think we fixed it up in the end. It made drivers look a bit messy and
it dropped off my priority queue.

Cheers,
Mark.
--
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] devicetree: Add generic IOMMU device tree bindings

[Olof Johansson]

On Wed, Jul 30, 2014 at 6:33 AM, Joerg Roedel  wrote:
> On Wed, Jul 30, 2014 at 03:23:50PM +0200, Thierry Reding wrote:
>> I think there weren't any comments left for me to address and I've
>> mostly been waiting for Joerg to pick it up.
>>
>> Joerg, can you take this through the iommu tree for 3.17? Will acked
>> this, but perhaps you were waiting for an ACK from the device tree
>> bindings maintainers?
>>
>> Will, perhaps you can get Pawel or Mark to look at this?
>>
>> Arnd, I'm sure if we had your Acked-by that would go a long way too.
>
> Yes, as Arnd requested this generic binding it would be good to have his
> Acked-by before proceeding. Arnd?

Arnd is on vacation now, unfortunately. I've read up on the history
and the current proposal from Thierry looks sane to me. As discussed,
there might be a need for some common helpers to walk the tree and
figure out things.

There's also the possibility that the IOMMU at init time actually
modifies and configures the stream IDs for the clients, but that again
is an implementation detail and not something that affects the binding
per se.

I'm not giving my Ack now since I want to make sure there are no
disagreements on my separate reply from a minute ago, but I expect
you'll have it once we've had that round trip of comments. :)


-Olof
--
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] devicetree: Add generic IOMMU device tree bindings

[Olof Johansson]

Hi,

On Wed, Jul 30, 2014 at 8:26 AM, Mark Rutland  wrote:
> Hi Thierry,
>
> This looks sane to me.
>
> I just have a few questions below which are hopefully simple/stupid.
>
> On Fri, Jul 04, 2014 at 04:29:17PM +0100, Thierry Reding wrote:
>> From: Thierry Reding 
>>
>> This commit introduces a generic device tree binding for IOMMU devices.
>> Only a very minimal subset is described here, but it is enough to cover
>> the requirements of both the Exynos System MMU and Tegra SMMU as
>> discussed here:
>>
>> https://lkml.org/lkml/2014/4/27/346
>>
>> Signed-off-by: Thierry Reding 
>> ---
>> Changes in v4:
>> - clarify that disabling an IOMMU DT node may not disable translation
>> - be more explicit that examples are only examples
>> - add multi-ID master example
>>
>> Changes in v3:
>> - use #iommu-cells instead of #address-cells/#size-cells
>> - drop optional iommu-names property
>>
>> Changes in v2:
>> - add notes about "dma-ranges" property (drop note from commit message)
>> - document priorities of "iommus" property vs. "dma-ranges" property
>> - drop #iommu-cells in favour of #address-cells and #size-cells
>> - remove multiple-master device example
>>
>>  Documentation/devicetree/bindings/iommu/iommu.txt | 172 
>> ++
>>  1 file changed, 172 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/iommu/iommu.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt 
>> b/Documentation/devicetree/bindings/iommu/iommu.txt
>> new file mode 100644
>> index ..464a81eaaf61
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iommu/iommu.txt
>> @@ -0,0 +1,172 @@
>> +This document describes the generic device tree binding for IOMMUs and their
>> +master(s).
>> +
>> +
>> +IOMMU device node:
>> +==
>> +
>> +An IOMMU can provide the following services:
>> +
>> +* Remap address space to allow devices to access physical memory ranges that
>> +  they otherwise wouldn't be capable of accessing.
>> +
>> +  Example: 32-bit DMA to 64-bit physical addresses
>> +
>> +* Implement scatter-gather at page level granularity so that the device does
>> +  not have to.
>> +
>> +* Provide system protection against "rogue" DMA by forcing all accesses to 
>> go
>> +  through the IOMMU and faulting when encountering accesses to unmapped
>> +  address regions.
>> +
>> +* Provide address space isolation between multiple contexts.
>> +
>> +  Example: Virtualization
>> +
>> +Device nodes compatible with this binding represent hardware with some of 
>> the
>> +above capabilities.
>> +
>> +IOMMUs can be single-master or multiple-master. Single-master IOMMU devices
>> +typically have a fixed association to the master device, whereas multiple-
>> +master IOMMU devices can translate accesses from more than one master.
>> +
>> +The device tree node of the IOMMU device's parent bus must contain a valid
>> +"dma-ranges" property that describes how the physical address space of the
>> +IOMMU maps to memory. An empty "dma-ranges" property means that there is a
>> +1:1 mapping from IOMMU to memory.
>> +
>> +Required properties:
>> +
>> +- #iommu-cells: The number of cells in an IOMMU specifier needed to encode 
>> an
>> +  address.
>> +
>> +The meaning of the IOMMU specifier is defined by the device tree binding of
>> +the specific IOMMU. Below are a few examples of typical use-cases:
>> +
>> +- #iommu-cells = <0>: Single master IOMMU devices are not configurable and
>> +  therefore no additional information needs to be encoded in the specifier.
>> +  This may also apply to multiple master IOMMU devices that do not allow the
>> +  association of masters to be configured. Note that an IOMMU can by design
>> +  be multi-master yet only expose a single master in a given configuration.
>> +  In such cases the number of cells will usually be 1 as in the next case.
>> +- #iommu-cells = <1>: Multiple master IOMMU devices may need to be 
>> configured
>> +  in order to enable translation for a given master. In such cases the 
>> single
>> +  address cell corresponds to the master device's ID. In some cases more 
>> than
>> +  one cell can be required to represent a single master ID.
>> +- #iommu-cells = <4>: Some IOMMU devices allow the DMA window for masters to
>> +  be configured. The first cell of the address in this may contain the 
>> master
>> +  device's ID for example, while the second cell could contain the start of
>> +  the DMA window for the given device. The length of the DMA window is given
>> +  by the third and fourth cells.
>> +
>> +Note that these are merely examples and real-world use-cases may use 
>> different
>> +definitions to represent their individual needs. Always refer to the 
>> specific
>> +IOMMU binding for the exact meaning of the cells that make up the specifier.
>> +
>> +
>> +IOMMU master node:
>> +==
>> +
>> +Devices that access memory through an IOMMU are called masters. A device can
>> +have multiple 

Re: [PATCH v8 01/11] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs

[Rob Herring]

On Mon, Jul 21, 2014 at 4:07 PM, Brian Norris
 wrote:
> From: Marc Carino 
>
> The BCM7xxx series of Broadcom SoCs are used primarily in set-top boxes.
>
> This patch adds machine support for the ARM-based Broadcom SoCs.
>
> Signed-off-by: Marc Carino 
> Signed-off-by: Brian Norris 
> ---
>  arch/arm/configs/multi_v7_defconfig |   1 +
>  arch/arm/mach-bcm/Kconfig   |  14 ++
>  arch/arm/mach-bcm/Makefile  |   5 +
>  arch/arm/mach-bcm/brcmstb.c |  28 +++
>  arch/arm/mach-bcm/brcmstb.h |  19 ++
>  arch/arm/mach-bcm/headsmp-brcmstb.S |  33 
>  arch/arm/mach-bcm/platsmp-brcmstb.c | 363 
> 
>  7 files changed, 463 insertions(+)
>  create mode 100644 arch/arm/mach-bcm/brcmstb.c
>  create mode 100644 arch/arm/mach-bcm/brcmstb.h
>  create mode 100644 arch/arm/mach-bcm/headsmp-brcmstb.S
>  create mode 100644 arch/arm/mach-bcm/platsmp-brcmstb.c
>
> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index 534836497998..bf0df396a3cf 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -19,6 +19,7 @@ CONFIG_MACH_DOVE=y
>  CONFIG_ARCH_BCM=y
>  CONFIG_ARCH_BCM_MOBILE=y
>  CONFIG_ARCH_BCM_5301X=y
> +CONFIG_ARCH_BRCMSTB=y
>  CONFIG_ARCH_BERLIN=y
>  CONFIG_MACH_BERLIN_BG2=y
>  CONFIG_MACH_BERLIN_BG2CD=y
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index 41c839167e87..0073633e7699 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -87,4 +87,18 @@ config ARCH_BCM_5301X
>   different SoC or with the older BCM47XX and BCM53XX based
>   network SoC using a MIPS CPU, they are supported by 
> arch/mips/bcm47xx
>
> +config ARCH_BRCMSTB
> +   bool "Broadcom BCM7XXX based boards" if ARCH_MULTI_V7
> +   depends on MMU

This was implied, but there are some patches from Arnd in this area.
Does it really not build with !MMU?

> +   select ARM_GIC

> +   select MIGHT_HAVE_PCI
> +   select HAVE_SMP

At least HAVE_SMP is for sure, but I think both of these are selected already .

> +   select HAVE_ARM_ARCH_TIMER
> +   help
> + Say Y if you intend to run the kernel on a Broadcom ARM-based STB
> + chipset.
> +
> + This enables support for Broadcom ARM-based set-top box chipsets,
> + including the 7445 family of chips.
> +
>  endif
> diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> index 731292114975..f3665121729b 100644
> --- a/arch/arm/mach-bcm/Makefile
> +++ b/arch/arm/mach-bcm/Makefile
> @@ -30,3 +30,8 @@ obj-$(CONFIG_ARCH_BCM2835)+= board_bcm2835.o
>
>  # BCM5301X
>  obj-$(CONFIG_ARCH_BCM_5301X)   += bcm_5301x.o
> +
> +ifeq ($(CONFIG_ARCH_BRCMSTB),y)
> +obj-y  += brcmstb.o
> +obj-$(CONFIG_SMP)  += headsmp-brcmstb.o platsmp-brcmstb.o
> +endif
> diff --git a/arch/arm/mach-bcm/brcmstb.c b/arch/arm/mach-bcm/brcmstb.c
> new file mode 100644
> index ..60a5afa06ed7
> --- /dev/null
> +++ b/arch/arm/mach-bcm/brcmstb.c
> @@ -0,0 +1,28 @@
> +/*
> + * Copyright (C) 2013-2014 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static const char *brcmstb_match[] __initconst = {
> +   "brcm,bcm7445",
> +   "brcm,brcmstb",
> +   NULL
> +};
> +
> +DT_MACHINE_START(BRCMSTB, "Broadcom STB (Flattened Device Tree)")
> +   .dt_compat  = brcmstb_match,
> +MACHINE_END

Do you plan to add more here? Otherwise you don't need this file.

> diff --git a/arch/arm/mach-bcm/brcmstb.h b/arch/arm/mach-bcm/brcmstb.h
> new file mode 100644
> index ..ec0c3d112b36
> --- /dev/null
> +++ b/arch/arm/mach-bcm/brcmstb.h
> @@ -0,0 +1,19 @@
> +/*
> + * Copyright (C) 2013-2014 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __BRCMSTB_H__
> +#define __BRCMSTB_H__
> +
> +void brcmstb_secondary_startup(void);
> +
> +#endif /* __BRCMSTB_H__ */
> diff --git a/arch/arm/mach-bcm/headsmp-brcmstb.S 
> b/arch/arm/mach-bcm/headsmp-brcmstb

Re: [PATCH v11 3/8] ata: libahci_platform: move port_map parameters into the AHCI structure

[Tejun Heo]

On Wed, Jul 30, 2014 at 06:47:21PM +0200, Antoine Ténart wrote:
> On Wed, Jul 30, 2014 at 11:35:26AM -0400, Tejun Heo wrote:
> > On Wed, Jul 30, 2014 at 10:20:38AM +0200, Antoine Ténart wrote:
> > > How do you want me to send the series? There is two conflicts when
> > > applying to libata/for-3.17:
> > > - patch 4/8: it takes into account a patch not in libata/for-3.17 but
> > >   added before rc7. It should be better to first merge rc7, otherwise
> > >   some modifications won't make sense.
> > > - patch 6/8: "fsl,imx53-ahci" was removed from the documentation in
> > >   libata/for-3.17 but not in rc7. Resolving the conflict is really
> > >   simple.
> > > 
> > > I think it's better to apply the whole thing after merging rc7 into
> > > libata/for-3.17, because it will only have a really simple conflict to
> > > resolve.
> > > 
> > > Please tell me what do you prefer before I send the updated version.
> > 
> > Hmmm... does pulling in libata/for-3.16-fixes into libata/for-3.17
> > resolves the conflict?  If so, please send the patch on top of the
> > merged branch.  I wanna avoid pulling in -rc7 wholesale at this point.
> 
> Works for me. I'll cook and send a series based on top of
> libata/for-3.16-fixes merged into libata/for-3.17.

I pulled libata/for-3.16-fixes into for-3.17, so you can just base on
that one.

Thanks.

-- 
tejun
--
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 v11 3/8] ata: libahci_platform: move port_map parameters into the AHCI structure

[Antoine Ténart]

On Wed, Jul 30, 2014 at 11:35:26AM -0400, Tejun Heo wrote:
> On Wed, Jul 30, 2014 at 10:20:38AM +0200, Antoine Ténart wrote:
> > How do you want me to send the series? There is two conflicts when
> > applying to libata/for-3.17:
> > - patch 4/8: it takes into account a patch not in libata/for-3.17 but
> >   added before rc7. It should be better to first merge rc7, otherwise
> >   some modifications won't make sense.
> > - patch 6/8: "fsl,imx53-ahci" was removed from the documentation in
> >   libata/for-3.17 but not in rc7. Resolving the conflict is really
> >   simple.
> > 
> > I think it's better to apply the whole thing after merging rc7 into
> > libata/for-3.17, because it will only have a really simple conflict to
> > resolve.
> > 
> > Please tell me what do you prefer before I send the updated version.
> 
> Hmmm... does pulling in libata/for-3.16-fixes into libata/for-3.17
> resolves the conflict?  If so, please send the patch on top of the
> merged branch.  I wanna avoid pulling in -rc7 wholesale at this point.

Works for me. I'll cook and send a series based on top of
libata/for-3.16-fixes merged into libata/for-3.17.

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] regulator: userspace-consumer: add DT binding details

[Mark Brown]

On Wed, Jul 30, 2014 at 04:53:03PM +0100, Mark Rutland wrote:
> On Wed, Jul 30, 2014 at 02:54:00PM +0100, Laxman Dewangan wrote:

> > +Required properties:
> > +- compatible   : Must be "reg-userspace-consumer".

> I would never expect to see "userspace" in a DT beinding string; this is
> entirely a software abstraction description and has nothing to do with
> the interaction of HW components.

> Why do you think we need this in the DT?

Yes, this is test code - it is not intended to be used in production.
Any binding should be for the consumer using this, not for this
implementation detail.


signature.asc
Description: Digital signature

Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC

[Rob Herring]

On Wed, Jul 30, 2014 at 10:46 AM, Mark Rutland  wrote:
> Hi,
>
> On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert Richter wrote:
>> From: Radha Mohan Chintakuntla 
>>
>> Add initial device tree nodes for Cavium Thunder SoCs with support of
>> 48 cores and gicv3. The dts file requires further changes, esp. for
>> pci, gicv3-its and smmu. This changes will be added later together
>> with the device drivers.
>>
>> Signed-off-by: Radha Mohan Chintakuntla 
>> Signed-off-by: Robert Richter 
>> ---
>>  arch/arm64/boot/dts/Makefile |   1 +
>>  arch/arm64/boot/dts/thunder-88xx.dts | 387 
>> +++
>>  2 files changed, 388 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts
>>
>> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
>> index c52bdb051f66..f8001a62029c 100644
>> --- a/arch/arm64/boot/dts/Makefile
>> +++ b/arch/arm64/boot/dts/Makefile
>> @@ -1,3 +1,4 @@
>> +dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
>>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
>>  dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
>>
>> diff --git a/arch/arm64/boot/dts/thunder-88xx.dts 
>> b/arch/arm64/boot/dts/thunder-88xx.dts
>> new file mode 100644
>> index ..4cf20ac9138b
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/thunder-88xx.dts
>> @@ -0,0 +1,387 @@
>> +/*
>> + * Cavium Thunder DTS file
>> + *
>> + * Copyright (C) 2013, Cavium Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of
>> + * the License, or (at your option) any later version.
>> + */

You may want to reconsider if this should be BSD.

>> +/dts-v1/;
>> +
>> +/* Reserving first 12MB of DDR for firmware */
>> +/memreserve/ 0x 0x00c0;
>
> What exactly is this memreserve intended to protect at runtime?
>
> The only item of runtime firmware I see in use below is PSCI on the
> secure side.
>
> How is the kernel booted on this platform? UEFI?
>
>> +/ {
>> + model = "Cavium ThunderX CN88XX Family";
>> + compatible = "cavium,thunder-88xx";
>
> Please don't use wildcards in compatible strings. Give this an absolute
> name, and override as necessary.
>
>> + interrupt-parent = <&gic0>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + aliases {
>> + serial0 = &uaa0;
>> + serial1 = &uaa1;
>> + };
>> +
>> + psci {
>> + compatible = "arm,psci-0.2";
>> + method = "smc";
>> + };
>
> Nice!
>
>> +
>> + cpus {
>> + #address-cells = <2>;
>> + #size-cells = <0>;
>> +
>> + cpu@000 {
>> + device_type = "cpu";
>> + compatible = "cavium,thunder", "arm,armv8";
>> + reg = <0x0 0x000>;
>> + enable-method = "psci";
>> + };
>
> Just to check: both the SoC and CPU are called thunder?
>
> [...]
>
>> +
>> + memory@ {
>> + device_type = "memory";
>> + reg = <0x0 0x 0x0 0x8000>;
>> + };
>> +
>> + gic0: interrupt-controller@8010 {
>
> To make this easier to read, please place a comma between 32-bit
> portions of the unit address (e.g. here have 8010,).

Mark, perhaps a dtc or checkpatch.pl check for this?

This should also be under a bus node.

>> + compatible = "arm,gic-v3";
>> + #interrupt-cells = <3>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>
> This has no children, so why have ranges, #address-cells, and
> #size-cells?
>
>> + interrupt-controller;
>> + reg = <0x8010 0x 0x0 0x01>, /* GICD */
>> +   <0x8010 0x8000 0x0 0x20>; /* GICR */
>> + interrupts = <1 9 0xf04>;
>> + };
>> +
>> + timer {
>> + compatible = "arm,armv8-timer";
>> + interrupts = <1 13 0xff01>,
>> +  <1 14 0xff01>,
>> +  <1 11 0xff01>,
>> +  <1 10 0xff01>;
>> + };
>> +
>> + soc {
>> + compatible = "simple-bus";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + clocks {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + refclk50mhz: refclk50mhz {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <5000>;
>> + clock-output-names = "refclk50mhz";
>> + };
>> + };
>
> Please get rid of the clocks node and just put the clocks here.
>
>> +

Re: [PATCH 29/35] arm: omap: intc: switch over to linear irq domain

[Felipe Balbi]

Hi,

On Wed, Jul 30, 2014 at 10:45:41AM -0500, Nishanth Menon wrote:
> On Wed, Jul 30, 2014 at 9:40 AM, Felipe Balbi  wrote:
> > HI,
> >
> > On Tue, Jul 29, 2014 at 11:04:21PM -0700, Tony Lindgren wrote:
> >> * Felipe Balbi  [140729 09:36]:
> >> > Hi,
> >> >
> >> > On Tue, Jul 29, 2014 at 10:40:57AM -0500, Felipe Balbi wrote:
> >> > > On Tue, Jul 29, 2014 at 08:20:52AM -0700, Tony Lindgren wrote:
> >> > > > * Felipe Balbi  [140729 07:18]:
> >> > > > > Hi,
> >> > > > >
> >> > > > > On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote:
> >> > > > > > * Felipe Balbi  [140728 14:19]:
> >> > > > > > > now that we don't need to support legacy board-files,
> >> > > > > > > we can completely switch over to a linear irq domain
> >> > > > > > > and make use of irq_alloc_domain_generic_chips() to
> >> > > > > > > allocate all generic irq chips for us.
> >> > > > > >
> >> > > > > > This patch seems to somehow break off-idle for omap3
> >> > > > > > where it no longer wakes up.
> >> > > > >
> >> > > > > Sure your bisection is correct ? This patch just switches from 
> >> > > > > legacy
> >> > > > > irq domain to linear irq domain.
> >> > > >
> >> > > > Yes, I tried it a few times. Just enabling
> >> > > > retention idle hangs too with this patch.
> >> > > >
> >> > > > Maybe it's omap3_prcm_irq_setup that relies on
> >> > > > 11 + OMAP_INTC_START? There may be other such issues
> >> > >
> >> > > lol.
> >> > >
> >> > > OMAP4 has the same nonsense.
> >> >
> >> > made me think why (if) OMAP4 works with that same setup. Does wake from
> >> > OFF work with OMAP4 ?
> >>
> >> Not without similar changes, omap4+ has the same issue.. There's a RFC
> >> series from Nishant to fix some of this, and Tero is moving the PRCM
> >> into a driver.
> >>
> >> > Anyway, here's a quick little hack to check if that's the reason for the
> >> > regression:
> >>
> >> OK yeah that's along the same lines with Nishant's RFC series in thread
> >> "[RFC PATCH 0/7] ARM: OMAP4+: PRM: minor cleanups and dt support of
> >> interrupts"
> >>
> >> FYI, it did not compile, needs to include linux/of_irq.h. But yes,
> >
> > I might have sent the wrong version as I had that same build error and
> > fixed it localy.
> >
> >> it fixes the regression for me, Also now the whole series works for
> >> me :)
> >
> > good to know.
> >
> > What do you want to do now ? Wait for PRCM to become a driver ? Wait for
> > Nishanth's series to get accepted ? I guess the same thing could be done
> > for OMAP3 and AM33, then we would have a chance of having working wake
> > from idle with the new irqchip.
> 
> I can repost the current series as it stands now once 17-rc1 comes out
> (without the build failure ofcourse).. if that helps to move it out of
> RFC status.

That'd be great. It would be ever greater if you could add support for
OMAP3 on that too.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge

[Ajay kumar]

On Wed, Jul 30, 2014 at 9:10 PM, Thierry Reding
 wrote:
> On Wed, Jul 30, 2014 at 08:46:44PM +0530, Ajay kumar wrote:
>> On Wed, Jul 30, 2014 at 5:35 PM, Thierry Reding  
>> wrote:
>> > On Sat, Jul 26, 2014 at 12:52:09AM +0530, Ajay Kumar wrote:
> [...]
>> >> +int ptn3460_post_encoder_init(struct drm_bridge *bridge)
>> >> +{
>> >> + struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
>> >> + int ret;
>> >> +
>> >> + /* bridge is attached to encoder.
>> >> +  * safe to remove it from the bridge_lookup table.
>> >> +  */
>> >> + drm_bridge_remove_from_lookup(bridge);
>> >
>> > No, you should never do this. First, you're not adding it back to the
>> > registry when the bridge is detached, so unloading and reloading the
>> > display driver will fail. Second there should never be a need to remove
>> > it from the registry as long as the driver itself is loaded. If you're
>> > concerned about a single bridge being used multiple times, there's
>> > already code to handle that in your previous patch:
>> >
>> > int drm_bridge_attach_encoder(...)
>> > {
>> > ...
>> >
>> > if (bridge->encoder)
>> > return -EBUSY;
>> >
>> > ...
>> > }
>> >
>> > Generally the registry should contain a list of bridges that have been
>> > registered, whether they're used or not is irrelevant.
>> I was just wondering if it is ok to have a node in two independent lists?
>> bridge_lookup_table and the other mode_config.bridge_list?
>
> Oh, it reuses the head field for the registry. I hadn't noticed before.
> No, you certainly can't have the same node in two lists. Honestly I
> don't quite understand why there was a need to expose drm_bridge as a
> drm_mode_object in the first place since it's never exported to
> userspace.
>
> So I think that perhaps we could simply get rid of the base field and
> not tie in drm_bridge objects with the DRM object as we currently do.
> But until Sean or Rob comment on this it might be better to simply add
> another struct list_head field for the registry. That way both can
> coexist and we can independently still decide to remove the base and
> head fields if they're no longer needed.
Ok. What shall I name the new list_head?

>> >> + ret = drm_connector_init(bridge->drm_dev, &ptn_bridge->connector,
>> >> + &ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
>> >> + if (ret) {
>> >> + DRM_ERROR("Failed to initialize connector with drm\n");
>> >> + return ret;
>> >> + }
>> >> + drm_connector_helper_add(&ptn_bridge->connector,
>> >> + &ptn3460_connector_helper_funcs);
>> >> + drm_connector_register(&ptn_bridge->connector);
>> >> + drm_mode_connector_attach_encoder(&ptn_bridge->connector,
>> >> + bridge->encoder);
>> >> +
>> >> + if (ptn_bridge->panel)
>> >> + drm_panel_attach(ptn_bridge->panel, &ptn_bridge->connector);
>> >> +
>> >> + return ret;
>> >> +}
>> >
>> > I'm thinking that eventually we'll want to register the connector only
>> > when a panel is attached to the bridge. This will only become important
>> > when we implement bridge chaining because if you instantiate a connector
>> > for each bridge then you'll get a list of connectors for the DRM device
>> > representing the output of each bridge rather than just the final one
>> > that goes to the display.
>> So, do not initialize connector if there is no panel? and, get_modes
>> via panel instead of doing it by edid-emulation?
>
> If there's no panel, then there's nothing to connect the connector to,
> so it's unneeded. Also if you have chained bridges, then each bridge
> would expose a connector and it would become impossible to choose the
> correct one. So only the final bridge in the chain should instantiate
> the connector.
Since there is only a single bridge when it comes to ptn3460/ps8622, lets
not talk about chaining of bridges now.
And, I agree that if there is no panel, then no need to register connector.

> .get_modes() still needs to be done from the bridge because that is the
> most closely connected to the display controller and therefore dictates
> the timing that the display controller needs to generate.
>
> Querying the panel's .get_modes() might be useful to figure out which
> emulation mode to use in the bridge.
But, get_modes from panel returns me only the no_of_modes but
not the actual mode structure. How do I compare the list of supported
emulation modes?

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

Re: [PATCH 2/3] ARM: dts: add rk3288 ehci usb devices

[Doug Anderson]

Hi,

On Tue, Jul 29, 2014 at 4:24 PM, Doug Anderson  wrote:
> rk3288 has two kind of usb controller; this adds the ehci variant for
> host0 and hsic.
>
> At the moment we don't add any phys for these controllers, but the
> default settings seem to work OK.
>
> There is a hardware problem in ohci controller which make it
> unavailable and host0 controller can only support high-speed devices.
>
> Signed-off-by: Kever Yang 
> Signed-off-by: Doug Anderson 
> ---
>  arch/arm/boot/dts/rk3288.dtsi | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index 3ef8951..0bb4480 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -251,6 +251,26 @@
> status = "disabled";
> };
>
> +   usb_host0_ehci: ehci@ff50 {

According to sergei.shtyl...@cogentembedded.com in another thread,
this should be "usb@ff50".

I will fix (and the hsic one) this when I spin the series shortly.

-Doug
--
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: [PATCHv8 5/5] mmc: dw_mmc: replace "disable-wp" from slot's quirk to host's quirk

[Doug Anderson]

Jaehoon,

On Wed, Jul 30, 2014 at 4:05 AM, Jaehoon Chung  wrote:
> Replaced the "disable-wp" into host's quirks.
> (Because the slot-node is removed at dt-file.)
>
> Signed-off-by: Jaehoon Chung 
> Tested-by: Sachin Kamat 
> Acked-by: Seungwon Jeon 
> ---
>  drivers/mmc/host/dw_mmc.c  |8 +++-
>  include/linux/mmc/dw_mmc.h |2 ++
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 1ac227c..8d9edc6 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -997,7 +997,10 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
> int gpio_ro = mmc_gpio_get_ro(mmc);
>
> /* Use platform get_ro function, else try on board write protect */
> -   if (slot->quirks & DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT)
> +   if (slot->quirks & DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT) {
> +   dev_warn(slot->host->dev, "Recommend not to use 'disable-wp'"
> +   "into slot-node. Change your dt-file!!");
> +   } else if (slot->host->quirks & DW_MCI_QUIRK_NO_WRITE_PROTECT)

This isn't what I meant.  I meant that
"DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT" should continue to work normally
but print a warning once at bootup.  In other words, this code should
be:

-   if (slot->quirks & DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT)
+   if ((slot->quirks & DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT) ||
+   (slot->host->quirks & DW_MCI_QUIRK_NO_WRITE_PROTECT)) {

Then add the warning in "dw_mci_of_get_slot_quirks" which is only
called once at init time.  You can warn if ANY slot quirks are
actually applied, like:

for (idx = 0; idx < ARRAY_SIZE(of_slot_quirks); idx++)
  if (of_get_property(np, of_slot_quirks[idx].quirk, NULL)) {
dev_warn(dev, "Slot quirk %s is deprecated\n", of_slot_quirks[idx].quirk);
quirks |= of_slot_quirks[idx].id;
  }


> read_only = 0;
> else if (!IS_ERR_VALUE(gpio_ro))
> read_only = gpio_ro;
> @@ -2238,6 +2241,9 @@ static struct dw_mci_of_quirks {
> {
> .quirk  = "broken-cd",
> .id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
> +   }, {
> +   .quirk  = "disable-wp",
> +   .id = DW_MCI_QUIRK_NO_WRITE_PROTECT,
> },
>  };

If you fix it like I say, then this patch should actually be patch #2
in your series and can be applied _before_ the device tree files.
That means you could land patch #1 and patch #2 right away without
even getting acks for the dts changes.  ...and if the dts changes have
conflicts they can be resolved later without blocking this patch.

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

Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model

[Ajay kumar]

On Wed, Jul 30, 2014 at 8:38 PM, Thierry Reding
 wrote:
> On Wed, Jul 30, 2014 at 08:01:44PM +0530, Ajay kumar wrote:
>> On Wed, Jul 30, 2014 at 4:49 PM, Thierry Reding
>>  wrote:
>> > On Sat, Jul 26, 2014 at 12:52:08AM +0530, Ajay Kumar wrote:
>> >> This patch tries to seperate drm_bridge implementation
>> >> into 2 parts, a drm part and a non_drm part.
>> >>
>> >> A set of helper functions are defined in this patch to make
>> >> bridge driver probe independent of the drm flow.
>> >>
>> >> The bridge devices register themselves on a lookup table
>> >> when they get probed by calling "drm_bridge_add_for_lookup".
>> >>
>> >> The parent encoder driver waits till the bridge is available in the
>> >> lookup table(by calling "of_drm_find_bridge") and then continues with
>> >> its initialization.
>> >>
>> >> The encoder driver should call "drm_bridge_attach_encoder" to pass on
>> >> the drm_device and the encoder pointers to the bridge object.
>> >>
>> >> Now that the drm_device pointer is available, the encoder then calls
>> >> "bridge->funcs->post_encoder_init" to allow the bridge to continue
>> >> registering itself with the drm core.
>> >>
>> >> Also, non driver model based ptn3460 driver is removed in this patch.
>> >
>> > Why is it removed in this patch? Can't you do this incrementally rather
>> > than remove the driver in this patch and add it again later? If you do
>> > it this way then we'll always have this one commit where devices that
>> > have a ptn3460 don't work, so it becomes impossible to bisect across
>> > this commit.
>> Ok. I will try to modify ptn3460 to support driver model in this patch 
>> itself.
>> And then, adding panel support, converting it to gpiod interface and other
>> cleanups should follow.
>
> I think it should even be possible to do this in more separate steps.
> For example you could add the new bridge infrastructure without touching
> any of the existing drivers (so that they are completely unaffected by
> the changes) and then start converting one by one.
>
> For some of the changes this may be difficult (such as the dev ->
> drm_dev rename to make room for the new struct device *dev). But that
> could for example be done in a preparatory patch that first renames the
> field, so that the "infrastructure" patch can add the new field without
> renaming any fields and therefore needing changes to drivers directly.
>
> The goal of that whole exercise is to allow display drivers to keep
> working with the existing API (ptn3460_init()) while we convert the
> bridge drivers to register with the new framework. Then we can more
> safely convert each display driver individually to make use of the new
> framework and once all drivers have been converted the old API can
> simply be removed.
>
> That way there should be no impact on existing functionality at any
> point.
As of now only exynos_dp uses ptn3460_init.
And, also only 2 drivers use drm_bridge_init.
It should be really easy to bisect if something goes wrong.
Still, I will try to divide it so that each patch contains minimal change.

>> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> > [...]
>> >
>> > Maybe since you're introducing a new drm_bridge.c file above already it
>> > would make sense to move out existing drm_bridge related code in a
>> > preparatory patch?
>> >
>> > Maybe Sean or Rob can comment on whether there was a specific reason to
>> > include it in drm_crtc.c in the first place.
>> >
>> >> @@ -1012,8 +1010,7 @@ int drm_bridge_init(struct drm_device *dev, struct 
>> >> drm_bridge *bridge,
>> >>   if (ret)
>> >>   goto out;
>> >>
>> >> - bridge->dev = dev;
>> >> - bridge->funcs = funcs;
>> >> + bridge->drm_dev = dev;
>> >
>> > This sets ->drm_dev, but it was already set in drm_bridge_attach(), so I
>> > think that's one more argument to call this function when attaching.
>> Point accepted.
>
> I forgot to mention earlier. drm_dev seems redundant to me. I'd go with
> just "drm".
Ok.

>> >> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> >> index e529b68..e5a41ad 100644
>> >> --- a/include/drm/drm_crtc.h
>> >> +++ b/include/drm/drm_crtc.h
>> >> @@ -619,6 +619,7 @@ struct drm_plane {
>> >>
>> >>  /**
>> >>   * drm_bridge_funcs - drm_bridge control functions
>> >> + * @post_encoder_init: called by the parent encoder
>> >
>> > Maybe rename this to "attach" to make it more obvious when exactly it's
>> > called?
>> "post_encoder_attach"?
>
> "post_encoder_" doesn't contain much information, or even ambiguous
> information. What does "post" "encoder" mean? A bridge is always
> attached to an encoder, so "encoder" can be dropped. Now "post" has
> implications as to the time when it is called, but does it mean after
> the encoder has been initialized, or after the encoder has been removed?
> Simply "attach" means it's called by the parent encoder to initialize
> the bridge once it's been attached to an encoder. So obviously it's
> after the encoder has 

Re: [PATCHv8 2/5] ARM: dts: exynos: unuse the slot-node and deprecated the supports-highspeed for dw-mmc

[Doug Anderson]

Jaehoon,

On Wed, Jul 30, 2014 at 4:05 AM, Jaehoon Chung  wrote:
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
> b/arch/arm/boot/dts/exynos5250-arndale.dts
> index d0de1f5..42a3590 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -401,7 +401,6 @@
> mmc_0: mmc@1220 {
> status = "okay";
> num-slots = <1>;
> -   supports-highspeed;
> broken-cd;
> card-detect-delay = <200>;
> samsung,dw-mshc-ciu-div = <3>;
> @@ -410,17 +409,13 @@
> vmmc-supply = <&mmc_reg>;
> pinctrl-names = "default";
> pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
> -
> -   slot@0 {
> -   reg = <0>;
> -   bus-width = <8>;
> -   };
> +   bus-width = <8>;
> +   cap-mmc-highspeed;
> };
>
> mmc_2: mmc@1222 {
> status = "okay";
> num-slots = <1>;
> -   supports-highspeed;
> card-detect-delay = <200>;
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <2 3>;
> @@ -428,12 +423,9 @@
> vmmc-supply = <&mmc_reg>;
> pinctrl-names = "default";
> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
> -
> -   slot@0 {
> -   reg = <0>;
> -   bus-width = <4>;
> -   disable-wp;
> -   };
> +   bus-width = <4>;
> +   disable-wp;
> +   cap-sd-highspeed;

It seems like you ought to include cap-mmc-highspeed in addition to
cap-sd-highspeed, but I could be wrong.  I know that I have some
full-sized MMC cards (not eMMC) that can be plugged into an SD card
slot.  I know that the SD/MMC slot on this port only has 4 pins on
exynos5250, but I think you can still run MMC highspeed on 4 pins,
right?

-Doug
--
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: [PATCHv8 1/5] mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed

[Doug Anderson]

Jaehoon,

On Wed, Jul 30, 2014 at 4:05 AM, Jaehoon Chung  wrote:
> Almost SoCs use one slot per host controller.
> (Even if controller can support the multiple slot, Recommend to use one slot 
> per host controller.)
> Don't use the slot-node and deprecate the "supports-highspeed" property.
> Instead, use the cap-mmc/sd-highspeed.
>
> Signed-off-by: Jaehoon Chung 
> Reviewed-by: Tushar Behera 
> Reviewed-by: Ulf Hansson 
> Tested-by: Sachin Kamat 
> Acked-by: Seungwon Jeon 

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

Re: [PATCH 1/2] regulator: userspace-consumer: add DT binding details

[Mark Rutland]

On Wed, Jul 30, 2014 at 02:54:00PM +0100, Laxman Dewangan wrote:
> Add DT binding document and details DT binding for the driver
> regulator/userspace-consumer.
> 
> Signed-off-by: Laxman Dewangan 
> ---
>  .../bindings/regulator/userspace-consumer.txt  | 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/userspace-consumer.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/regulator/userspace-consumer.txt 
> b/Documentation/devicetree/bindings/regulator/userspace-consumer.txt
> new file mode 100644
> index 000..73c651c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/userspace-consumer.txt
> @@ -0,0 +1,26 @@
> +Userspace consumer regulators
> +
> +Required properties:
> +- compatible : Must be "reg-userspace-consumer".

I would never expect to see "userspace" in a DT beinding string; this is
entirely a software abstraction description and has nothing to do with
the interaction of HW components.

Why do you think we need this in the DT?

Thanks,
Mark.

> +- regulator-supplies: Supply names for this regulator. This can be
> + multiple strings.
> +
> +Optional properties:
> +- regulator-name: Name of the consumer line.
> +- regulator-boot-on: Enable regulator on booting.
> +
> +With all supply names, there should be -supply to pass 
> regulators
> +handle as defined in regulator.txt.
> +
> +Example:
> +
> + userspace-consumer {
> + compatible = "reg-userspace-consumer";
> +
> + regulator-name = "gps-consumer";
> + regulator-boot-on;
> + regulator-supplies = "vdd", "vcc", "vdd-3v3";
> + vdd-supply = <®1>;
> + vcc-supply = <®2>;
> + vdd-3v3-supply = <®3>;
> + };
> -- 
> 1.8.1.5
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] arm64, thunder: Add initial dts for Cavium Thunder SoC

[Mark Rutland]

Hi,

On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert Richter wrote:
> From: Radha Mohan Chintakuntla 
> 
> Add initial device tree nodes for Cavium Thunder SoCs with support of
> 48 cores and gicv3. The dts file requires further changes, esp. for
> pci, gicv3-its and smmu. This changes will be added later together
> with the device drivers.
> 
> Signed-off-by: Radha Mohan Chintakuntla 
> Signed-off-by: Robert Richter 
> ---
>  arch/arm64/boot/dts/Makefile |   1 +
>  arch/arm64/boot/dts/thunder-88xx.dts | 387 
> +++
>  2 files changed, 388 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts
> 
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index c52bdb051f66..f8001a62029c 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,3 +1,4 @@
> +dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
>  dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
>  
> diff --git a/arch/arm64/boot/dts/thunder-88xx.dts 
> b/arch/arm64/boot/dts/thunder-88xx.dts
> new file mode 100644
> index ..4cf20ac9138b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/thunder-88xx.dts
> @@ -0,0 +1,387 @@
> +/*
> + * Cavium Thunder DTS file
> + *
> + * Copyright (C) 2013, Cavium Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +/dts-v1/;
> +
> +/* Reserving first 12MB of DDR for firmware */
> +/memreserve/ 0x 0x00c0;

What exactly is this memreserve intended to protect at runtime?

The only item of runtime firmware I see in use below is PSCI on the
secure side.

How is the kernel booted on this platform? UEFI?

> +/ {
> + model = "Cavium ThunderX CN88XX Family";
> + compatible = "cavium,thunder-88xx";

Please don't use wildcards in compatible strings. Give this an absolute
name, and override as necessary.

> + interrupt-parent = <&gic0>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = &uaa0;
> + serial1 = &uaa1;
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };

Nice!

> +
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu@000 {
> + device_type = "cpu";
> + compatible = "cavium,thunder", "arm,armv8";
> + reg = <0x0 0x000>;
> + enable-method = "psci";
> + };

Just to check: both the SoC and CPU are called thunder?

[...]

> +
> + memory@ {
> + device_type = "memory";
> + reg = <0x0 0x 0x0 0x8000>;
> + };
> +
> + gic0: interrupt-controller@8010 {

To make this easier to read, please place a comma between 32-bit
portions of the unit address (e.g. here have 8010,).

> + compatible = "arm,gic-v3";
> + #interrupt-cells = <3>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;

This has no children, so why have ranges, #address-cells, and
#size-cells?

> + interrupt-controller;
> + reg = <0x8010 0x 0x0 0x01>, /* GICD */
> +   <0x8010 0x8000 0x0 0x20>; /* GICR */
> + interrupts = <1 9 0xf04>;
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <1 13 0xff01>,
> +  <1 14 0xff01>,
> +  <1 11 0xff01>,
> +  <1 10 0xff01>;
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + clocks {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + refclk50mhz: refclk50mhz {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <5000>;
> + clock-output-names = "refclk50mhz";
> + };
> + };

Please get rid of the clocks node and just put the clocks here.

> +
> + uaa0: serial@87e02400 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x87e0 0x2400 0x0 0x1000>;
> + interrupts = <1 21 4>;
> + clocks = <&refclk50mhz>;
> + clock-names = "apb_pclk";

Is this actually the apb_pclk, or is the t

Re: [PATCH 29/35] arm: omap: intc: switch over to linear irq domain

[Nishanth Menon]

On Wed, Jul 30, 2014 at 9:40 AM, Felipe Balbi  wrote:
> HI,
>
> On Tue, Jul 29, 2014 at 11:04:21PM -0700, Tony Lindgren wrote:
>> * Felipe Balbi  [140729 09:36]:
>> > Hi,
>> >
>> > On Tue, Jul 29, 2014 at 10:40:57AM -0500, Felipe Balbi wrote:
>> > > On Tue, Jul 29, 2014 at 08:20:52AM -0700, Tony Lindgren wrote:
>> > > > * Felipe Balbi  [140729 07:18]:
>> > > > > Hi,
>> > > > >
>> > > > > On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote:
>> > > > > > * Felipe Balbi  [140728 14:19]:
>> > > > > > > now that we don't need to support legacy board-files,
>> > > > > > > we can completely switch over to a linear irq domain
>> > > > > > > and make use of irq_alloc_domain_generic_chips() to
>> > > > > > > allocate all generic irq chips for us.
>> > > > > >
>> > > > > > This patch seems to somehow break off-idle for omap3
>> > > > > > where it no longer wakes up.
>> > > > >
>> > > > > Sure your bisection is correct ? This patch just switches from legacy
>> > > > > irq domain to linear irq domain.
>> > > >
>> > > > Yes, I tried it a few times. Just enabling
>> > > > retention idle hangs too with this patch.
>> > > >
>> > > > Maybe it's omap3_prcm_irq_setup that relies on
>> > > > 11 + OMAP_INTC_START? There may be other such issues
>> > >
>> > > lol.
>> > >
>> > > OMAP4 has the same nonsense.
>> >
>> > made me think why (if) OMAP4 works with that same setup. Does wake from
>> > OFF work with OMAP4 ?
>>
>> Not without similar changes, omap4+ has the same issue.. There's a RFC
>> series from Nishant to fix some of this, and Tero is moving the PRCM
>> into a driver.
>>
>> > Anyway, here's a quick little hack to check if that's the reason for the
>> > regression:
>>
>> OK yeah that's along the same lines with Nishant's RFC series in thread
>> "[RFC PATCH 0/7] ARM: OMAP4+: PRM: minor cleanups and dt support of
>> interrupts"
>>
>> FYI, it did not compile, needs to include linux/of_irq.h. But yes,
>
> I might have sent the wrong version as I had that same build error and
> fixed it localy.
>
>> it fixes the regression for me, Also now the whole series works for
>> me :)
>
> good to know.
>
> What do you want to do now ? Wait for PRCM to become a driver ? Wait for
> Nishanth's series to get accepted ? I guess the same thing could be done
> for OMAP3 and AM33, then we would have a chance of having working wake
> from idle with the new irqchip.

I can repost the current series as it stands now once 17-rc1 comes out
(without the build failure ofcourse).. if that helps to move it out of
RFC status.


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

RE: [RFC PATCH v3] edac: synps: Added EDAC support for zynq ddr ecc controller

[Punnaiah Choudary Kalluri]

Hi Boris,

>-Original Message-
>From: Borislav Petkov [mailto:b...@alien8.de]
>Sent: Monday, July 28, 2014 11:32 PM
>To: Punnaiah Choudary Kalluri
>Cc: Punnaiah Choudary Kalluri; dougthomp...@xmission.com;
>robh...@kernel.org; pawel.m...@arm.com; Michal Simek;
>mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; Kumar Gala; Rob
>Landley; devicetree@vger.kernel.org; linux-...@vger.kernel.org; linux-
>e...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-arm-
>ker...@lists.infradead.org; Punnaiah Choudary; Anirudha Sarangi; Srikanth
>Vemula
>Subject: Re: [RFC PATCH v3] edac: synps: Added EDAC support for zynq ddr
>ecc controller
>
>On Mon, Jul 28, 2014 at 10:53:26PM +0530, punnaiah choudary kalluri wrote:
>> I can agree with you that we can use shorter names.But ZYNQ has
>> programmable logic next to processing system where one can add soft
>> memory controller in the same system and may use different driver. So,
>> the edac driver for zynq may include multiple drivers for different
>> memory controllers in the same file. In this case it is difficult to
>> maintain generic macros as you suggested above.
>
>So?
>
>You can still shorten them a bit - the current names are awfully long.
>SYNPS_DDRC_ECC_ is too much information, for example. We know it is DDR
>and we know it is about ECC. So do SYNPS and ZYNQ or OTHER or whatever
>you wanna call it prefix and then the rest. I.e.,
>
>SYNPS__
>ZYNQ__bits*>
>
>You can even use single letter prefixes like S_ and Z_ and add a comment
>explaining what those mean. Still much more readable than the long
>repeating prefixes currently.

Ok.
>
>> Also the current edac framework for edac memory controllers is
>> expecting the mc_num from the driver while allocating the memory
>> controller instance using the edac_mc_alloc function. This requirement
>> mandates that if the system contains two different memory controllers
>> then the corresponding edac drivers should be in single file.
>
>So you're telling me that you want one edac driver for *two* memory
>controllers which can be present on a single system *at* *the* *same*
>*time*? Is that it?

Yes.
>
>How exactly is that topology supposed to look like, work, etc, etc? What
>kind of error reporting do you imagine you want to do with EDAC?

Zynq (All programmable SOC) contains a dual core ARM cortex A9 based processing
System(PS) and Xilinx programmable logic(PL) in a single device.

Assume the application is a broadcast camera. The design for this system use PS 
as
Control plane and use PL as data plane for processing the video data. So, the 
design 
may have two different memory controllers one in PS and another one in PL.   
PS is running with Linux OS and PL doesn't have the OS and it is  controlled by 
the 
OS running on PS.
 Now the requirement is to develop a monitoring system for all the hardware 
failures 
Including ddr ecc errors. Since the broadcast camera involves more data 
processing and
DDR memory access, there is a high probability of getting ddr ecc errors over 
the period.
So, the user should be intimated with these errors when they occur and if the 
error rate
 is high, then the user can consider the preventive methods. Without this error 
reporting
mechanism it is difficult to debug the issues like memory corruption, kernel 
oops which
 may occur due to ddr ecc failures.

Since, the memory controllers are different, it need two edac drivers for 
reporting the ecc 
errors and also maintaining the statistics of that particular memory 
controller. With the current
framework, there is a chance that both the drivers get mc_num as zero and 
malfunction. 
Assume the code for the two drivers looks like below

Driver 1:
mci = edac_mc_alloc(0, ARRAY_SIZE(layers), layers,
sizeof(struct  ctrl1_drvdata));

Driver 2:
mci = edac_mc_alloc(0, ARRAY_SIZE(layers), layers,
sizeof(struct ctrl2_drvdata));

Issue:
  Since driver is providing the mc_num to framework, now there is chance that 
only one device active as
 both the drivers claiming the same number.

Solution 1:
 Keep two drivers in single file and use static global variable for tracking 
the mc_num. This solution looks
good but the drivers may not be generic as these driver would be in a 
zynq_edac.c file. So others may not
reuse these drivers
static int mc_num = 0;

Driver 1:
mci = edac_mc_alloc(mc_num, ARRAY_SIZE(layers), layers,
sizeof(struct  ctrl1_drvdata));
  mc_num++;

Driver 2:
mci = edac_mc_alloc(mc_num, ARRAY_SIZE(layers), layers,
sizeof(struct ctrl2_drvdata));
 mc_num++;

Solution 2:
  Let the framework assign the mc_num to the edac driver

 mc_num = edac_mc_get_id(); /* returns the next available mci slot */
 mci = edac_mc_alloc(mc_num,...);


In my opinion solution 2  looks neat and it eliminates the dependency on 
tracking
 the mc_num.

Please suggest your

Re: [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge

[Thierry Reding]

On Wed, Jul 30, 2014 at 08:46:44PM +0530, Ajay kumar wrote:
> On Wed, Jul 30, 2014 at 5:35 PM, Thierry Reding  
> wrote:
> > On Sat, Jul 26, 2014 at 12:52:09AM +0530, Ajay Kumar wrote:
[...]
> >> +int ptn3460_post_encoder_init(struct drm_bridge *bridge)
> >> +{
> >> + struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
> >> + int ret;
> >> +
> >> + /* bridge is attached to encoder.
> >> +  * safe to remove it from the bridge_lookup table.
> >> +  */
> >> + drm_bridge_remove_from_lookup(bridge);
> >
> > No, you should never do this. First, you're not adding it back to the
> > registry when the bridge is detached, so unloading and reloading the
> > display driver will fail. Second there should never be a need to remove
> > it from the registry as long as the driver itself is loaded. If you're
> > concerned about a single bridge being used multiple times, there's
> > already code to handle that in your previous patch:
> >
> > int drm_bridge_attach_encoder(...)
> > {
> > ...
> >
> > if (bridge->encoder)
> > return -EBUSY;
> >
> > ...
> > }
> >
> > Generally the registry should contain a list of bridges that have been
> > registered, whether they're used or not is irrelevant.
> I was just wondering if it is ok to have a node in two independent lists?
> bridge_lookup_table and the other mode_config.bridge_list?

Oh, it reuses the head field for the registry. I hadn't noticed before.
No, you certainly can't have the same node in two lists. Honestly I
don't quite understand why there was a need to expose drm_bridge as a
drm_mode_object in the first place since it's never exported to
userspace.

So I think that perhaps we could simply get rid of the base field and
not tie in drm_bridge objects with the DRM object as we currently do.
But until Sean or Rob comment on this it might be better to simply add
another struct list_head field for the registry. That way both can
coexist and we can independently still decide to remove the base and
head fields if they're no longer needed.

> >> + ret = drm_connector_init(bridge->drm_dev, &ptn_bridge->connector,
> >> + &ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
> >> + if (ret) {
> >> + DRM_ERROR("Failed to initialize connector with drm\n");
> >> + return ret;
> >> + }
> >> + drm_connector_helper_add(&ptn_bridge->connector,
> >> + &ptn3460_connector_helper_funcs);
> >> + drm_connector_register(&ptn_bridge->connector);
> >> + drm_mode_connector_attach_encoder(&ptn_bridge->connector,
> >> + bridge->encoder);
> >> +
> >> + if (ptn_bridge->panel)
> >> + drm_panel_attach(ptn_bridge->panel, &ptn_bridge->connector);
> >> +
> >> + return ret;
> >> +}
> >
> > I'm thinking that eventually we'll want to register the connector only
> > when a panel is attached to the bridge. This will only become important
> > when we implement bridge chaining because if you instantiate a connector
> > for each bridge then you'll get a list of connectors for the DRM device
> > representing the output of each bridge rather than just the final one
> > that goes to the display.
> So, do not initialize connector if there is no panel? and, get_modes
> via panel instead of doing it by edid-emulation?

If there's no panel, then there's nothing to connect the connector to,
so it's unneeded. Also if you have chained bridges, then each bridge
would expose a connector and it would become impossible to choose the
correct one. So only the final bridge in the chain should instantiate
the connector.

.get_modes() still needs to be done from the bridge because that is the
most closely connected to the display controller and therefore dictates
the timing that the display controller needs to generate.

Querying the panel's .get_modes() might be useful to figure out which
emulation mode to use in the bridge.

Thierry


pgpIbREF7jezN.pgp
Description: PGP signature

Re: [PATCH v11 3/8] ata: libahci_platform: move port_map parameters into the AHCI structure

[Tejun Heo]

Hello,

On Wed, Jul 30, 2014 at 10:20:38AM +0200, Antoine Ténart wrote:
> How do you want me to send the series? There is two conflicts when
> applying to libata/for-3.17:
> - patch 4/8: it takes into account a patch not in libata/for-3.17 but
>   added before rc7. It should be better to first merge rc7, otherwise
>   some modifications won't make sense.
> - patch 6/8: "fsl,imx53-ahci" was removed from the documentation in
>   libata/for-3.17 but not in rc7. Resolving the conflict is really
>   simple.
> 
> I think it's better to apply the whole thing after merging rc7 into
> libata/for-3.17, because it will only have a really simple conflict to
> resolve.
> 
> Please tell me what do you prefer before I send the updated version.

Hmmm... does pulling in libata/for-3.16-fixes into libata/for-3.17
resolves the conflict?  If so, please send the patch on top of the
merged branch.  I wanna avoid pulling in -rc7 wholesale at this point.

Thanks.

-- 
tejun
--
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 2/3] usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation

[Peter Griffin]

This patch documents the device tree documentation required for
the ST usb3 controller glue layer found in STiH407 devices.

Signed-off-by: Giuseppe Cavallaro 
Signed-off-by: Peter Griffin 
Acked-by: Lee Jones 
---
 Documentation/devicetree/bindings/usb/dwc3-st.txt | 69 +++
 1 file changed, 69 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt

diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt 
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
new file mode 100644
index 000..de3fea3
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -0,0 +1,69 @@
+ST DWC3 glue logic
+
+This file documents the parameters for the dwc3-st driver.
+This driver controls the glue logic used to configure the dwc3 core on
+STiH407 based platforms.
+
+Required properties:
+ - compatible  : must be "st,stih407-dwc3"
+ - reg : glue logic base address and USB syscfg ctrl register offset
+ - reg-names   : should be "reg-glue" and "syscfg-reg"
+ - st,syscon   : should be phandle to system configuration node which
+ encompasses the glue registers
+ - resets  : list of phandle and reset specifier pairs. There should be 
two entries, one
+ for the powerdown and softreset lines of the usb3 IP
+ - reset-names : list of reset signal names. Names should be "powerdown" and 
"softreset"
+See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+See: Documentation/devicetree/bindings/reset/reset.txt
+
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property
+
+ - pinctl-names: A pinctrl state named "default" must be defined
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - pinctrl-0   : Pin control group
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - ranges  : allows valid 1:1 translation between child's address space and
+ parent's address space
+
+Sub-nodes:
+The dwc3 core should be added as subnode to ST DWC3 glue as shown in the
+example below. The DT binding details of dwc3 can be found in:
+Documentation/devicetree/bindings/usb/dwc3.txt
+
+NB: The dr_mode property described in [1] is NOT optional for this driver, as 
the default value
+is "otg", which isn't supported by this SoC. Valid dr_mode values for dwc3-st 
are either "host"
+or "device".
+
+[1] Documentation/devicetree/bindings/usb/generic.txt
+
+Example:
+
+st_dwc3: dwc3@8f94000 {
+   status  = "disabled";
+   compatible  = "st,stih407-dwc3";
+   reg = <0x08f94000 0x1000>, <0x110 0x4>;
+   reg-names   = "reg-glue", "syscfg-reg";
+   st,syscfg   = <&syscfg_core>;
+   resets  = <&powerdown STIH407_USB3_POWERDOWN>;
+ <&softreset STIH407_MIPHY2_SOFTRESET>;
+   reset-names = "powerdown",
+ "softreset";
+   #address-cells  = <1>;
+   #size-cells = <1>;
+   pinctrl-names   = "default";
+   pinctrl-0   = <&pinctrl_usb3>;
+   ranges;
+
+   dwc3: dwc3@990 {
+   compatible  = "snps,dwc3";
+   reg = <0x0990 0x10>;
+   interrupts  = ;
+   dr_mode = "host"
+   usb-phy = <&usb3_phy>;
+   phy-names   = "usb2-phy";
+   phys= <&usb2_picophy2>;
+   };
+};
-- 
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/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC

[Peter Griffin]

This patch adds the ST glue logic to manage the DWC3 HC
on STiH407 SoC family. It manages the powerdown signal,
and configures the internal glue logic and syscfg registers.

Signed-off-by: Giuseppe Cavallaro 
Signed-off-by: Peter Griffin 
Acked-by: Lee Jones 
---
 drivers/usb/dwc3/Kconfig   |   9 ++
 drivers/usb/dwc3/Makefile  |   1 +
 drivers/usb/dwc3/dwc3-st.c | 336 +
 3 files changed, 346 insertions(+)
 create mode 100644 drivers/usb/dwc3/dwc3-st.c

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 8eb996e..6c85c43 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -79,6 +79,15 @@ config USB_DWC3_KEYSTONE
  Support of USB2/3 functionality in TI Keystone2 platforms.
  Say 'Y' or 'M' here if you have one such device
 
+config USB_DWC3_ST
+   tristate "STMicroelectronics Platforms"
+   depends on ARCH_STI && OF
+   default USB_DWC3_HOST
+   help
+ STMicroelectronics SoCs with one DesignWare Core USB3 IP
+ inside (i.e. STiH407).
+ Say 'Y' or 'M' if you have one such device.
+
 comment "Debugging features"
 
 config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..11c9f54 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP)   += dwc3-omap.o
 obj-$(CONFIG_USB_DWC3_EXYNOS)  += dwc3-exynos.o
 obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
 obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
+obj-$(CONFIG_USB_DWC3_ST)  += dwc3-st.o
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
new file mode 100644
index 000..227698f
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -0,0 +1,336 @@
+/**
+ * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics platforms
+ *
+ * This is a small driver for the dwc3 to provide the glue logic
+ * to configure the controller. Tested on STi platforms.
+ *
+ * Copyright (C) 2014 Stmicroelectronics
+ *
+ * Author: Giuseppe Cavallaro 
+ * Contributors: Aymen Bouattay 
+ *   Peter Griffin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Inspired by dwc3-omap.c and dwc3-exynos.c.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "io.h"
+
+/* glue registers */
+#define CLKRST_CTRL0x00
+#define AUX_CLK_EN BIT(0)
+#define SW_PIPEW_RESET_N   BIT(4)
+#define EXT_CFG_RESET_NBIT(8)
+/*
+ * 1'b0 : The host controller complies with the xHCI revision 0.96
+ * 1'b1 : The host controller complies with the xHCI revision 1.0
+ */
+#define XHCI_REVISION  BIT(12)
+
+#define USB2_VBUS_MNGMNT_SEL1  0x2C
+/*
+ * For all fields in USB2_VBUS_MNGMNT_SEL1
+ * 2’b00 : Override value from Reg 0x30 is selected
+ * 2’b01 : utmiotg_ from usb3_top is selected
+ * 2’b10 : pipew_ from PIPEW instance is selected
+ * 2’b11 : value is 1'b0
+ */
+#define USB2_VBUS_REG300x0
+#define USB2_VBUS_UTMIOTG  0x1
+#define USB2_VBUS_PIPEW0x2
+#define USB2_VBUS_ZERO 0x3
+
+#define SEL_OVERRIDE_VBUSVALID(n)  (n << 0)
+#define SEL_OVERRIDE_POWERPRESENT(n)   (n << 4)
+#define SEL_OVERRIDE_BVALID(n) (n << 8)
+
+/* Static DRD configuration */
+#define USB_HOST_DEFAULT_MASK  0xffe
+#define USB_SET_PORT_DEVICE0x1
+
+/**
+ * struct st_dwc3 - dwc3-st driver private structure
+ * @dev:   device pointer
+ * @glue_base: ioaddr for the glue registers
+ * @regmap:regmap pointer for getting syscfg
+ * @syscfg_reg_off:usb syscfg control offset
+ * @dr_mode:   drd static host/device config
+ * @rstc_pwrdn:rest controller for powerdown signal
+ * @rstc_rst:  reset controller for softreset signal
+ */
+
+struct st_dwc3 {
+   struct device *dev;
+   void __iomem *glue_base;
+   struct regmap *regmap;
+   int syscfg_reg_off;
+   enum usb_dr_mode dr_mode;
+   struct reset_control *rstc_pwrdn;
+   struct reset_control *rstc_rst;
+};
+
+static inline u32 st_dwc3_readl(void __iomem *base, u32 offset)
+{
+   return readl_relaxed(base + offset);
+}
+
+static inline void st_dwc3_writel(void __iomem *base, u32 offset, u32 value)
+{
+   writel_relaxed(value, base + offset);
+}
+
+/**
+ * st_dwc3_drd_init: program the port
+ * @dwc3_data: driver private structure
+ * Description: this function is to program the port as either host or device
+ * according to the static configuration passed from devicetree.
+ * OTG and dual role are not yet supported!
+ *

[PATCH v4 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture

[Peter Griffin]

Signed-off-by: Peter Griffin 
Acked-by: Lee Jones 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 702ca10..269ad3b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1325,6 +1325,7 @@ F:drivers/pinctrl/pinctrl-st.c
 F: drivers/media/rc/st_rc.c
 F: drivers/i2c/busses/i2c-st.c
 F: drivers/tty/serial/st-asc.c
+F: drivers/usb/dwc3/dwc3-st.c
 
 ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
 M: Lennert Buytenhek 
-- 
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 0/3] Add ST dwc3 glue layer driver

[Peter Griffin]

This series adds support for the ST glue logic which wraps the DWC3 controller
on STiH407 SoC family chipsets.

Changes since v3
 - Various formating nits

Changes since v2
 - Use dr_mode for host/device static configuration
 - Manage shared reset signal to usbss to avoid hang if probing before usb3 phy
 - Remove DT checks and make driver depend on OF
 - Change some #define to use BIT macro
 - Make some comments clearer
 - Use kerneldoc for struct documentation
 - Remove udelay
 - Let DT create platform_devices, and remove legacy alloc
 - Change some logging levels to dev_dbg
 - Various whitespace and formatting cleanup
 - Use SIMPLE_DEV_PM_OPS()
 - Add const to of_device struct
 - Reorder header files alphabetically
 - Use devm_ioremap_resource instead of devm_request_and_ioremap
 - Remove of_match_ptr()

Changes since v1
 - Fix Kconfig mistake

Peter Griffin (3):
  usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
  usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation
  MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture

 Documentation/devicetree/bindings/usb/dwc3-st.txt |  69 +
 MAINTAINERS   |   1 +
 drivers/usb/dwc3/Kconfig  |   9 +
 drivers/usb/dwc3/Makefile |   1 +
 drivers/usb/dwc3/dwc3-st.c| 336 ++
 5 files changed, 416 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt
 create mode 100644 drivers/usb/dwc3/dwc3-st.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

Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings

[Mark Rutland]

Hi Thierry,

This looks sane to me.

I just have a few questions below which are hopefully simple/stupid.

On Fri, Jul 04, 2014 at 04:29:17PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> This commit introduces a generic device tree binding for IOMMU devices.
> Only a very minimal subset is described here, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra SMMU as
> discussed here:
> 
> https://lkml.org/lkml/2014/4/27/346
> 
> Signed-off-by: Thierry Reding 
> ---
> Changes in v4:
> - clarify that disabling an IOMMU DT node may not disable translation
> - be more explicit that examples are only examples
> - add multi-ID master example
> 
> Changes in v3:
> - use #iommu-cells instead of #address-cells/#size-cells
> - drop optional iommu-names property
> 
> Changes in v2:
> - add notes about "dma-ranges" property (drop note from commit message)
> - document priorities of "iommus" property vs. "dma-ranges" property
> - drop #iommu-cells in favour of #address-cells and #size-cells
> - remove multiple-master device example
> 
>  Documentation/devicetree/bindings/iommu/iommu.txt | 172 
> ++
>  1 file changed, 172 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/iommu.txt
> 
> diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt 
> b/Documentation/devicetree/bindings/iommu/iommu.txt
> new file mode 100644
> index ..464a81eaaf61
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/iommu.txt
> @@ -0,0 +1,172 @@
> +This document describes the generic device tree binding for IOMMUs and their
> +master(s).
> +
> +
> +IOMMU device node:
> +==
> +
> +An IOMMU can provide the following services:
> +
> +* Remap address space to allow devices to access physical memory ranges that
> +  they otherwise wouldn't be capable of accessing.
> +
> +  Example: 32-bit DMA to 64-bit physical addresses
> +
> +* Implement scatter-gather at page level granularity so that the device does
> +  not have to.
> +
> +* Provide system protection against "rogue" DMA by forcing all accesses to go
> +  through the IOMMU and faulting when encountering accesses to unmapped
> +  address regions.
> +
> +* Provide address space isolation between multiple contexts.
> +
> +  Example: Virtualization
> +
> +Device nodes compatible with this binding represent hardware with some of the
> +above capabilities.
> +
> +IOMMUs can be single-master or multiple-master. Single-master IOMMU devices
> +typically have a fixed association to the master device, whereas multiple-
> +master IOMMU devices can translate accesses from more than one master.
> +
> +The device tree node of the IOMMU device's parent bus must contain a valid
> +"dma-ranges" property that describes how the physical address space of the
> +IOMMU maps to memory. An empty "dma-ranges" property means that there is a
> +1:1 mapping from IOMMU to memory.
> +
> +Required properties:
> +
> +- #iommu-cells: The number of cells in an IOMMU specifier needed to encode an
> +  address.
> +
> +The meaning of the IOMMU specifier is defined by the device tree binding of
> +the specific IOMMU. Below are a few examples of typical use-cases:
> +
> +- #iommu-cells = <0>: Single master IOMMU devices are not configurable and
> +  therefore no additional information needs to be encoded in the specifier.
> +  This may also apply to multiple master IOMMU devices that do not allow the
> +  association of masters to be configured. Note that an IOMMU can by design
> +  be multi-master yet only expose a single master in a given configuration.
> +  In such cases the number of cells will usually be 1 as in the next case.
> +- #iommu-cells = <1>: Multiple master IOMMU devices may need to be configured
> +  in order to enable translation for a given master. In such cases the single
> +  address cell corresponds to the master device's ID. In some cases more than
> +  one cell can be required to represent a single master ID.
> +- #iommu-cells = <4>: Some IOMMU devices allow the DMA window for masters to
> +  be configured. The first cell of the address in this may contain the master
> +  device's ID for example, while the second cell could contain the start of
> +  the DMA window for the given device. The length of the DMA window is given
> +  by the third and fourth cells.
> +
> +Note that these are merely examples and real-world use-cases may use 
> different
> +definitions to represent their individual needs. Always refer to the specific
> +IOMMU binding for the exact meaning of the cells that make up the specifier.
> +
> +
> +IOMMU master node:
> +==
> +
> +Devices that access memory through an IOMMU are called masters. A device can
> +have multiple master interfaces (to one or more IOMMU devices).
> +
> +Required properties:
> +
> +- iommus: A list of phandle and IOMMU specifier pairs that describe the IOMMU
> +  master interfaces

Re: [PATCH v2 03/10] mtd: spi-nor: add DDR quad read support

[Huang Shijie]

On Wed, Jul 30, 2014 at 12:45:00AM -0700, Brian Norris wrote:
> 
> BTW, does your quadspi controller unconditionally support DDR, or is
> there any dependency on board/clock configuration? I'm just curious
> whether you need a DT binding to describe DDR support, or if (as long as
> the flash supports it, and we get the dummy cycles right) you can always
> use DDR QUAD.
The fsl-quadspi controller can support the DDR quad mode unconditionally.
In the other word, this controller is _designed_ for the DDR quad mode.

the driver does not needs a DT binding for the DDR. thanks.


> 
> > Please correct me if I am wrong. :)
> > 
> > > >   [1] add SPI_NOR_DDR_QUAD read mode.
> > > > 
> > > >   [2] add DDR Quad read opcodes:
> > > >SPINOR_OP_READ_1_4_4_D / SPINOR_OP_READ4_1_4_4_D
> > > > 
> > > >   [3] add set_ddr_quad_mode() to initialize for the DDR quad read.
> > > >   Currently it only works for Spansion NOR.
> > > > 
> > > >   [3] about the dummy cycles.
> > > >   We set the dummy with 8 for DDR quad read by default.
> > > 
> > > Why? That seems wrong. You need to know for sure how many cycles should
> > > be used, not just guess a default.
> > 
> > Do you mean that if people do not set the DT node for dummy, we should
> > return an -EINVAL immediately?
> 
> Possibly. But I actually don't think this belongs in DT at all. See
> below.
> 
> > > >   The m25p80.c can not support the DDR quad read, but the SPI NOR 
> > > > controller
> > > >   can set the dummy value in its child DT node, and the SPI NOR 
> > > > framework
> > > >   can parse it out.
> > > 
> > > Why does the dummy value belong in device tree? I think this can be
> > > handled in software.

We can not handle it in the software way.
Why? since there are too many modes,and each mode needs different dummy
cycles. Even the same chips, different versions may uses different dummy
cycles in the same mode. ..

You can refer to the Spansion's  S25fs128s.

If you want to put these dummy cycles in the device ID, it will make you
crazy in the end. :)
> 
> Can you answer me this question?
> 
> > > You might, however, want a few other hardware
> > > description parameters in device tree to help you.
> > > 
> > > So I think spi-nor.c needs to know a few things:
> > > 
> > >  1. Does the hardware/driver support DDR clocking?
> > >  2. What granularity of dummy cycles are supported? So m25p80.c needs to
> > > communicate that it only supports dummy cycles of multiples of 8,
> > > and fsl-quadspi supports single clock cycles.
> > 
> > I think you can send patches for these features. I does not clear about:
> >   for what does the spi-nor needs to know the above things.
> 
> To properly abstract features between a driver and the spi-nor
> "library." For example, we need to make sure we don't try to use a
> command mode with 7 dummy cycles on m25p80.c; right now, each driver has
> to (implicitly) know the details of dummy cycles when selecting a 'mode'
> parameter for spi_nor_scan(). spi-nor.c should be selecting this for us,
> not forcing the driver to make the selection.
> 
> > > And spi-nor.c should be able to do the following:
> > > 
> > >  3. Set how many dummy cycles should be used.
> > where can we get the number of the cycles? 
> 
> This should be a property of the flash device, just like everything else
> we detect in spi-nor.c.
This is indeed a probably of the flash device.
and this is why I add a new DT binding file for the flash.

> 
> > >  4. Write to the configuration register, to choose a Latency Code
> > > according to what the flash supports. I see modes that support 3, 6,
> > > 7, or 8. We'd probably just go for the fastest mode, which requires
> > > 8, right?
> > not right.
> > 
> > The DDR mode can not work if we set a wrong dummy cycles for the flash.
> > 
> > for some chips, the fastest mode may need 6 cycles, not 8. 
> 
> OK, but can spi-nor.c detect this instead of putting this in DT? e.g.,
> associate this with the device ID?

see the my comment above.
> 
> Or even better, we can support CFI detection for SPI NOR flash. I notice
> the datasheet for your Spansion flash [1] has an extensive set of CFI
> parameters defined, including the dummy cycle information. I think it
> might be more sustainable to try to support CFI [2] and SFDP [3] for
> detecting new flash, rather than adding new table entries ad-hoc.
I think different chip vendors may have different format to store the
info, just like the read-retry for nand chips.

do you want to add the code only available for Spansion?
What's more the code will be very long, i think.

Add a new DT binding file for the flash maybe is the simplest way.


> 
> > > So far, none of this seems to require a DT binding, unless there's
> > > something I'm missing about your fsl-quadspi controller.
> > > 
> > > > Test this patch for Spansion s25fl128s NOR flash.
> > > > 
> > > > Signed-off-by: Huang Shijie 
> > > > ---
> > > > +   /* DDR Quad/Quad/Dual-read mod

Re: [PATCH 3/3] ARM: dts: Enable USB host0 (EHCI) on rk3288-evb

[Doug Anderson]

Heiko,

On Wed, Jul 30, 2014 at 4:26 AM, Heiko Stübner  wrote:
> Am Dienstag, 29. Juli 2014, 16:24:33 schrieb Doug Anderson:
>> This is the top USB port on the evb (the one closest to the Ethernet
>> connector).
>>
>> Signed-off-by: Doug Anderson 
>> Signed-off-by: Kever Yang 
>
> shouldn't the signed-offs be the other way around, like in patch 2/3?

I wasn't aware that the order was too relevant, but I'll happily swap
them.  I generally try to list them based on contribution.  Things get
complicated when lots of WIP patches are sent around and then someone
eventually puts things together.  My work enabling the EHCI port was
based on something Kever sent me in email, so I felt he should have
SoB.  ...but cleaning it up / organizing was done by me.  Probably
should be this to get it totally right:

* Patch #1: Author and SoB are me, since Kever just pointed me to the
GPIO number
* Patch #2: Probably should be author Kever, first SoB Kever, second SoB me
* Patch #3: Probably should be author me, first SoB me, second SoB Kever

...in that case I just need to tweak the author of Patch #2 and leave
everything else the same.  I'll plan to do that when I repost.

...but I don't really care a whole lot and I'm OK with any authorship
of patch set #2/#3 and any SoB order of patch set #2/#3.  Just let me
know which you prefer!  :)

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