Re: [PATCH v2 3/5] [media] c8sectpfe: Remove select on undefined LIBELF_32

[Lee Jones]

On Thu, 27 Aug 2015, Peter Griffin wrote:

> LIBELF_32 is not defined in Kconfig, and is left over legacy
> which is not required in the upstream driver, so remove it.
> 
> Signed-off-by: Peter Griffin 
> Suggested-by: Valentin Rothberg 

These are the wrong way round, they should be in chronological order.

> ---
>  drivers/media/platform/sti/c8sectpfe/Kconfig | 1 -
>  1 file changed, 1 deletion(-)

Acked-by: Lee Jones 

> diff --git a/drivers/media/platform/sti/c8sectpfe/Kconfig 
> b/drivers/media/platform/sti/c8sectpfe/Kconfig
> index d1bfd4c..b9ec667 100644
> --- a/drivers/media/platform/sti/c8sectpfe/Kconfig
> +++ b/drivers/media/platform/sti/c8sectpfe/Kconfig
> @@ -1,7 +1,6 @@
>  config DVB_C8SECTPFE
>   tristate "STMicroelectronics C8SECTPFE DVB support"
>   depends on DVB_CORE && I2C && (ARCH_STI || ARCH_MULTIPLATFORM)
> - select LIBELF_32
>   select FW_LOADER
>   select FW_LOADER_USER_HELPER_FALLBACK
>   select DEBUG_FS

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] [media] c8sectpfe: Update binding to reset-gpios

[Lee Jones]

On Thu, 27 Aug 2015, Peter Griffin wrote:

> gpio.txt documents that GPIO properties should be named
> "[-]gpios", with  being the purpose of this
> GPIO for the device.
> 
> This change has been done as one atomic commit.
> 
> Signed-off-by: Peter Griffin 
> ---
>  Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt | 6 +++---
>  arch/arm/boot/dts/stihxxx-b2120.dtsi  | 4 ++--
>  drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 2 +-
>  3 files changed, 6 insertions(+), 6 deletions(-)

Acked-by: Lee Jones 

> diff --git a/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt 
> b/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
> index d4def76..e70d840 100644
> --- a/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
> +++ b/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
> @@ -35,7 +35,7 @@ Required properties (tsin (child) node):
>  
>  - tsin-num   : tsin id of the InputBlock (must be between 0 to 6)
>  - i2c-bus: phandle to the I2C bus DT node which the demodulators & 
> tuners on this tsin channel are connected.
> -- rst-gpio   : reset gpio for this tsin channel.
> +- reset-gpios: reset gpio for this tsin channel.
>  
>  Optional properties (tsin (child) node):
>  
> @@ -75,7 +75,7 @@ Example:
>   tsin-num= <0>;
>   serial-not-parallel;
>   i2c-bus = <&ssc2>;
> - rst-gpio= <&pio15 4 0>;
> + reset-gpios = <&pio15 4 GPIO_ACTIVE_HIGH>;
>   dvb-card= ;
>   };
>  
> @@ -83,7 +83,7 @@ Example:
>   tsin-num= <3>;
>   serial-not-parallel;
>   i2c-bus = <&ssc3>;
> - rst-gpio= <&pio15 7 0>;
> + reset-gpios = <&pio15 7 GPIO_ACTIVE_HIGH>;
>   dvb-card= ;
>   };
>   };
> diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi 
> b/arch/arm/boot/dts/stihxxx-b2120.dtsi
> index c014173..f932bfd 100644
> --- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
> +++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
> @@ -6,8 +6,8 @@
>   * it under the terms of the GNU General Public License version 2 as
>   * published by the Free Software Foundation.
>   */
> -
>  #include 
> +#include 
>  #include 
>  / {
>   soc {
> @@ -115,7 +115,7 @@
>   tsin-num= <0>;
>   serial-not-parallel;
>   i2c-bus = <&ssc2>;
> - rst-gpio= <&pio15 4 0>;
> + reset-gpios = <&pio15 4 GPIO_ACTIVE_HIGH>;
>   dvb-card= ;
>   };
>   };
> diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c 
> b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> index 3a91093..c691e13 100644
> --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> @@ -822,7 +822,7 @@ static int c8sectpfe_probe(struct platform_device *pdev)
>   }
>   of_node_put(i2c_bus);
>  
> - tsin->rst_gpio = of_get_named_gpio(child, "rst-gpio", 0);
> + tsin->rst_gpio = of_get_named_gpio(child, "reset-gpios", 0);
>  
>   ret = gpio_is_valid(tsin->rst_gpio);
>   if (!ret) {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/5] [media] c8sectpfe: Update DT binding doc with some minor fixes

[Lee Jones]

On Thu, 27 Aug 2015, Peter Griffin wrote:

> Signed-off-by: Peter Griffin 
> ---
>  .../devicetree/bindings/media/stih407-c8sectpfe.txt  | 16 
> +++-
>  1 file changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt 
> b/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
> index e70d840..5d6438c 100644
> --- a/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
> +++ b/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
> @@ -55,21 +55,20 @@ Example:
>   status = "okay";
>   reg = <0x08a2 0x1>, <0x08a0 0x4000>;
>   reg-names = "stfe", "stfe-ram";
> - interrupts = <0 34 0>, <0 35 0>;
> + interrupts = ,  IRQ_TYPE_NONE>;
>   interrupt-names = "stfe-error-irq", "stfe-idle-irq";
> -
> - pinctrl-names   = "tsin0-serial", "tsin0-parallel", 
> "tsin3-serial",
> - "tsin4-serial", "tsin5-serial";
> -
> + pinctrl-names   = "tsin0-serial",
> +   "tsin0-parallel",
> +   "tsin3-serial",
> +   "tsin4-serial",
> +   "tsin5-serial";
>   pinctrl-0   = <&pinctrl_tsin0_serial>;
>   pinctrl-1   = <&pinctrl_tsin0_parallel>;
>   pinctrl-2   = <&pinctrl_tsin3_serial>;
>   pinctrl-3   = <&pinctrl_tsin4_serial_alt3>;
>   pinctrl-4   = <&pinctrl_tsin5_serial_alt1>;
> -
>   clocks = <&clk_s_c0_flexgen CLK_PROC_STFE>;
> - clock-names = "stfe";
> -
> + clock-names = "c8sectpfe";

Are you sure you even need this property?  I'm thinking that *-names
properties are *usually* only required if there are more than one in a
single property.

>   /* tsin0 is TSA on NIMA */
>   tsin0: port@0 {
>   tsin-num= <0>;
> @@ -78,7 +77,6 @@ Example:
>   reset-gpios = <&pio15 4 GPIO_ACTIVE_HIGH>;
>   dvb-card= ;
>   };
> -

My personal preference is to have a '\n' between nodes.

>   tsin3: port@3 {
>   tsin-num= <3>;
>   serial-not-parallel;

But these comments are pretty trivial, so agree or not, or fix-up or
not, it's that big of a deal.

Either way,
  Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node

[Leo Yan]

Hi Mark,

On Thu, Aug 27, 2015 at 05:31:09PM +0100, Mark Rutland wrote:
> On Wed, Aug 26, 2015 at 07:59:50AM +0100, Leo Yan wrote:
> > Hi Haojian,
> > 
> > On Wed, Aug 26, 2015 at 09:25:41AM +0800, Haojian Zhuang wrote:
> > > On Wed, 2015-08-26 at 00:00 +0800, Leo Yan wrote:
> > > > On Tue, Aug 25, 2015 at 09:43:14PM +0800, Haojian Zhuang wrote:
> > > > > On Tue, 2015-08-25 at 11:42 +0100, Mark Rutland wrote:
> > > > > > > > Are you then going to hack GRUB, release a special HiKey 
> > > > > > > > version of
> > > > > > > > GRUB, not support any other versions, and still can your 
> > > > > > > > firmware
> > > > > > > > UEFI?
> > > > > > > 
> > > > > > > I don't need to hack GRUB at all.
> > > > > > 
> > > > > > Then it is working for you by pure chance alone.
> > > > > > 
> > > > > > Please listen to the advice you are being given here; we're trying 
> > > > > > to
> > > > > > ensure that your platform functions (and continues to function) as 
> > > > > > best
> > > > > > it can.
> > > > > 
> > > > > Since we discussed a lot on this, let's make a conclusion on it.
> > > > > 
> > > > > 1. UEFI could append the reserved buffer in it's memory mapping.
> > > > > 2. These reserved buffer must be declared in DT, since we also need to
> > > > >support non-UEFI (uboot) at the same time.
> > > > > 3. Mailbox node should reference reserved buffer by phandle in DT. 
> > > > > Then
> > > > >map the buffer as non-cacheable in driver.
> > > > > 4. These reserved buffer must use "no-map" property since it should be
> > > > >non-cacheable in driver.
> > > > 
> > > > For more specific discussion for DTS, i list two options at here;
> > > > 
> > > > - Option 1: just simply reserve memory regions through memory node,
> > > >   and mailbox node will directly use the buffer through reg ranges;
> > > > 
> > > > - Option 2: use reserved-memory and mailbox node will refer phandle
> > > >   of reserved-memory;
> > > > 
> > > > These two options both can work well with UEFI and Uboot, but option 1
> > > > is more simple and straightforward; so i personally prefer it. But
> > > > look forwarding your guys' suggestion.
> > > > 
> > > > Option 1:
> > > > 
> > > > memory@0 {
> > > > device_type = "memory";
> > > > reg = <0x 0x 0x 0x05e0>,
> > > >   <0x 0x05f0 0x 0x00eff000>,
> > > >   <0x 0x06e0 0x 0x0060f000>,
> > > >   <0x 0x0741 0x 0x38bf>;
> > > > };
> > > > 
> > > > [...]
> > > > 
> > > > mailbox: mailbox@f751 {
> > > > #mbox-cells = <1>;
> > > > compatible = "hisilicon,hi6220-mbox";
> > > > reg = <0x0 0xf751 0x0 0x1000>, /* IPC_S */
> > > >   <0x0 0x06dff800 0x0 0x0800>; /* Mailbox buffer */
> > > > interrupts = ;
> > > > };
> > > > 
> > > > Option 2:
> > > > 
> > > > memory@0 {
> > > > device_type = "memory";
> > > > reg = <0x0 0x0 0x0 0x4000>;
> > > > };
> > > > 
> > > > reserved-memory {
> > > > #address-cells = <2>;
> > > > #size-cells = <2>;
> > > > ranges;
> > > > 
> > > > mcu_reserved: mcu_reserved@06dff000 {
> > > > no-map;
> > > > reg = <0x0 0x06dff000 0x0 0x1000>,  /* MCU 
> > > > mailbox buffer */
> > > >   <0x0 0x05e0 0x0 0x0010>,  /* MCU 
> > > > firmware buffer */
> > > >   <0x0 0x0740f000 0x0 0x1000>;  /* MCU 
> > > > firmware section */
> > > > };
> > > > };
> > > > 
> > > > [...]
> > > > 
> > > > mailbox: mailbox@f751 {
> > > > #mbox-cells = <1>;
> > > > compatible = "hisilicon,hi6220-mbox";
> > > > reg = <0x0 0xf751 0x0 0x1000>; /* IPC_S */
> > > > memory-region = <&mcu_reserved>;   /* Mailbox buffer */
> > > > interrupts = ;
> > > > };
> > > 
> > > I prefer the second one. From my view, memory node should only describe
> > > the hardware information of memory.
> > 
> > Yes, option 2 will be more simple for memory node.
> > 
> > But option 2 also will introduce complexity for mailbox node, due mailbox
> > driver need use property "reg" and "memory-region" to sepeately depict
> > the regions for mailbox's ipc and slots. If later mailbox is designed to
> > use SRAM for both ipc and slots, then it will no matter with DDR anymore,
> > in this case option 1 will easily switch to support it.
> > 
> > Another question is a general question: for Linux kernel, which is the
> > best method to reserve memory regions? According to previous discussion,
> > we can use /memory/ node or /reseved-memory/ node to reserve memory
> > r

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Dr. H. Nikolaus Schaller]

Hi Linus,

Am 12.08.2015 um 01:20 schrieb NeilBrown :

> On Fri, 7 Aug 2015 15:01:47 +0200 Linus Walleij
>  wrote:
> 
>> Hi Neil,
>> 
>> first, this is a *VERY* interesting and much needed patch series,
>> I intend to look closer at it, and if possible test it with some
>> (heh) board file device. Would be happy of you put me on CC for these.
>> 
>> On Mon, May 11, 2015 at 3:56 AM, NeilBrown  wrote:
>> 
>>> When a device is connected to a UART via RS-232 (or similar), there
>>> is a DTR line that can be used for power management, and other "modem
>>> control" lines.
>>> 
>>> On an embedded board, it is very likely that there is no "DTR", and
>>> any power management need to be done using some completely separate
>>> mechanism.
>>> 
>>> So these "slaves" are really just for devices permanently attached to
>>> UARTs without a full "RS-232" (or similar) connection.  The driver
>>> does all the extra control beyond Tx/Rx.
>> 
>> What is usually happening (and I have seen it in a few places) is that
>> the SoC has *one* fully featured RS232 with CTS/RTS and even
>> DTS,DCD,RI and other esoterica, which is intended to be connected to a
>> host serial port or so, for example if this SoC is to act as a modem
>> or a fax machine, or if it is to drive one.
>> 
>> Then they often have a few more UART blocks, usually identical, which
>> only have RxD+TxD available, so they are "just" UARTs.
>> 
>> To complicate things further, you may wonder what happened with
>> the CTS/RTS (etc) signals from the other blocks. Usually they are there
>> in the silicon but just routed to dead ends.
>> 
>> To complicate it even further, usually all these pins are placed under
>> pin control multiplexing, so in an actual electronic design, the
>> system will mux out CTS/RTS (etc) from the fully featured RS232
>> blocks and only use them as UARTs anyways.
>> 
>> Then there are those who created real simple RxD/TxD-only UARTs
>> ("yeah lets dump this RS232 legacy crap" / "yeah yeah")
>> and then realized they want to drive modems ("oh crap, it seemed
>> like a good idea at the time"). Then they usually take
>> two GPIO pins for CTS/RTS and drive them as GPIOs using
>> software and you have a cheap 4-line modem line. This is what
>> drivers/tty/serial/serial_mctrl_gpio.c is for if you wondered.
>> 
>>> I've tested this set and it seems to work ... except that something
>>> is sadly broken with bluetooth support in 4.1-rc1 so I've only really
>>> tested the GPS driver.  I guess it is time to rebase to -rc3.
>> 
>> You have a hardware taget I see. Which one?
> 
> GTA04 (www.gta04.org - openmoko successor).
> 
> 3 uarts on OMAP3 are wired: one as RS-232 for console, one to bluetooth
> half of a wifi/bluetooth module, and one to a GPS.
> 
> For the GPS, I just want to power on/off when the TTY is opened/closed,
> but the power-on sequence is non-trivial as both "turn on" and
> "turn-off' toggle the same line, so I need to be able to detect current
> state.
> 
> For the bluetooth, the power is a (shared) regulator.  As well as
> power-on when the TTY is opened, I'd like regulator to be turned of
> when I "hciconfig down" - even though the TTY is still open.
> I did a patch a while ago which hooked in to hci_uart_{open,close} to
> make this work, but it isn't a really good patch.
> 
> It would be nice to hide the TTY from user-space in the bluetooth case,
> and have the "hciattach" happen in the kernel, but I think hciattach
> does extra initialisation...
> 
> NeilBrown


we (the developers of the hardware) have proposed an alternative
approach to Neil’s implementation - for the same device and solving
the same problem (notifying tty open/close and uart activity to the
slave device driver), but differently.

See:
https://lkml.org/lkml/2015/6/28/91

Discussion has not yet settled on which approach is better. So your
opinion of comparing both is welcome.

BR,
Nikolaus


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

[PATCH v1 3/3] clk: rockchip: add clock controller for rk3036

[Xing Zheng]

Add the clock tree definition for the new rk3036 SoC,
but there are some issues to be fixed:
1. soc will crash if gpll run rate_change_remuxed
2. rk3036_clk_suspend and rk3036_clk_resume should be done
   in clk-rk3036.c

---

Changes in v1:
Signed-off-by: Xing Zheng 

 drivers/clk/rockchip/Makefile  |1 +
 drivers/clk/rockchip/clk-pll.c |  247 ++-
 drivers/clk/rockchip/clk-rk3036.c  |  539 
 drivers/clk/rockchip/clk.h |   30 ++
 include/dt-bindings/clock/rk3036-cru.h |  247 +++
 5 files changed, 1063 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/rockchip/clk-rk3036.c
 create mode 100644 include/dt-bindings/clock/rk3036-cru.h

diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index b27edd6..d599829 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -10,6 +10,7 @@ obj-y += clk-inverter.o
 obj-y  += clk-mmc-phase.o
 obj-$(CONFIG_RESET_CONTROLLER) += softrst.o
 
+obj-y  += clk-rk3036.o
 obj-y  += clk-rk3188.o
 obj-y  += clk-rk3288.o
 obj-y  += clk-rk3368.o
diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 96903ae..cf56826 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -2,6 +2,9 @@
  * Copyright (c) 2014 MundoReader S.L.
  * Author: Heiko Stuebner 
  *
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng 
+ *
  * 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
@@ -48,6 +51,8 @@ struct rockchip_clk_pll {
 #define to_rockchip_clk_pll_nb(nb) \
container_of(nb, struct rockchip_clk_pll, clk_nb)
 
+static int rockchip_rk3036_pll_wait_lock(struct rockchip_clk_pll *pll);
+
 static const struct rockchip_pll_rate_table *rockchip_get_pll_settings(
struct rockchip_clk_pll *pll, unsigned long rate)
 {
@@ -90,6 +95,11 @@ static int rockchip_pll_wait_lock(struct rockchip_clk_pll 
*pll)
unsigned int val;
int delay = 2400, ret;
 
+   /* the plls of rk3036 wait lock */
+   if (pll->type == pll_rk3036 || pll->lock_offset == -1) {
+   return rockchip_rk3036_pll_wait_lock(pll);
+   }
+
while (delay > 0) {
ret = regmap_read(grf, pll->lock_offset, &val);
if (ret) {
@@ -305,6 +315,235 @@ static void rockchip_rk3066_pll_init(struct clk_hw *hw)
rockchip_rk3066_pll_set_rate(hw, drate, prate);
}
 }
+/**
+ * PLL used in RK3036
+ */
+
+#define RK3036_PLL_RESET_DELAY(nr) ((nr * 500) / 24 + 1)
+
+#define RK3036_PLLCON(i)   (i * 0x4)
+#define RK3036_PLLCON0_FBDIV_MASK  0xfff
+#define RK3036_PLLCON0_FBDIV_SHIFT 0
+#define RK3036_PLLCON0_POSTDIV1_MASK   0x7
+#define RK3036_PLLCON0_POSTDIV1_SHIFT  12
+#define RK3036_PLLCON1_REFDIV_MASK 0x3f
+#define RK3036_PLLCON1_REFDIV_SHIFT0
+#define RK3036_PLLCON1_POSTDIV2_MASK   0x7
+#define RK3036_PLLCON1_POSTDIV2_SHIFT  6
+#define RK3036_PLLCON1_DSMPD_MASK  0x1
+#define RK3036_PLLCON1_DSMPD_SHIFT 12
+#define RK3036_PLLCON2_FRAC_MASK   0xff
+#define RK3036_PLLCON2_FRAC_SHIFT  0
+
+#define RK3036_MODECON 0x40
+#define RK3036_MODECON_AWM (1 << 0)  /* apll work mode */
+
+#define RK3036_PLLCON0_BYPASS  (1 << 15)
+#define RK3036_PLLCON1_LOCK_STATUS (1 << 10)
+#define RK3036_PLLCON1_RESET   (1 << 14)
+
+static int rockchip_rk3036_pll_wait_lock(struct rockchip_clk_pll *pll)
+{
+   u32 pllcon;
+   int delay = 2400;
+
+   /* poll check the lock status in rk3036 xPLLCON1 */
+   while (delay > 0) {
+   pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(1));
+   if (pllcon & RK3036_PLLCON1_LOCK_STATUS)
+   return 0;
+
+   delay--;
+   }
+
+   pr_err("%s: timeout waiting for pll to lock\n", __func__);
+   return -ETIMEDOUT;
+}
+
+static unsigned long rockchip_rk3036_pll_recalc_rate(struct clk_hw *hw,
+unsigned long prate)
+{
+   struct rockchip_clk_pll *pll = to_rockchip_clk_pll(hw);
+   unsigned int fbdiv, postdiv1, refdiv, postdiv2, dsmpd, frac;
+   u64 rate64 = prate;
+   u32 pllcon;
+
+   pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(0));
+   fbdiv = ((pllcon >> RK3036_PLLCON0_FBDIV_SHIFT) & 
RK3036_PLLCON0_FBDIV_MASK);
+   postdiv1 = ((pllcon >> RK3036_PLLCON0_POSTDIV1_SHIFT) & 
RK3036_PLLCON0_POSTDIV1_MASK);
+
+   pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(1));
+   refdiv = ((pllcon >> RK3036_PLLCON1_REFDIV_SHIFT)

[PATCH v1 1/3] ARM: dts: rockchip: add core rk3036 dts

[Xing Zheng]

Initial release for rk3036, node definitions rk3036 sdk board.

Signed-off-by: Xing Zheng 
---

Changes in v1: None

 arch/arm/boot/dts/Makefile   |1 +
 arch/arm/boot/dts/rk3036-sdk.dts |  362 ++
 2 files changed, 363 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3036-sdk.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 6d7cec1..7014a3b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -501,6 +501,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3066a-bqcurie2.dtb \
rk3066a-marsboard.dtb \
rk3066a-rayeager.dtb \
+   rk3036-sdk.dtb \
rk3188-radxarock.dtb \
rk3288-evb-act8846.dtb \
rk3288-evb-rk808.dtb \
diff --git a/arch/arm/boot/dts/rk3036-sdk.dts b/arch/arm/boot/dts/rk3036-sdk.dts
new file mode 100644
index 000..0149c9a
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036-sdk.dts
@@ -0,0 +1,362 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "skeleton.dtsi"
+
+/ {
+   compatible = "rockchip,rk3036";
+
+   interrupt-parent = <&gic>;
+
+   aliases {
+   serial0 = &uart0;
+   serial1 = &uart1;
+   serial2 = &uart2;
+   };
+
+   memory {
+   reg = <0x6000 0x4000>;
+   };
+
+arm-pmu {
+compatible = "arm,cortex-a7-pmu";
+interrupts = ,
+ ;
+};
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   //enable-method = "rockchip,rk3066-smp";
+
+   cpu@f00 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0xf00>;
+   operating-points = <
+   /* KHzuV */
+816000 100
+   >;
+   #cooling-cells = <2>; /* min followed by max */
+   clock-latency = <4>;
+   clocks = <&cru ARMCLK>;
+   resets = <&cru SRST_CORE0>;
+   };
+   cpu@f01 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0xf01>;
+   resets = <&cru SRST_CORE1>;
+   };
+   };
+
+   amba {
+   compatible = "arm,amba-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+pdma: pdma@20078000 {
+compatible = "arm,pl330", "arm,primecell";
+reg = <0x20078000 0x4000>;
+interrupts = ,
+ ;
+#dma-cells = <1>;
+clocks = <&cru ACLK_DMAC2>;
+clock-names = "apb_pclk";
+

[PATCH v1 0/3] Port and support rk3036 SoC platform

[Xing Zheng]

Hi,
We need to support rk3036 soc platform via upstream, there are
3 parts for the initial release of minimum system: dts, pinctrl,
and clock tree for rk3036, startup and run to init processs.

Thanks.


Changes in v1:
Signed-off-by: Xing Zheng 

Xing Zheng (3):
  ARM: dts: rockchip: add core rk3036 dts
  pinctrl: rockchip: add support for the rk3036
  clk: rockchip: add clock controller for rk3036

 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/rk3036-sdk.dts   |  362 +
 drivers/clk/rockchip/Makefile  |1 +
 drivers/clk/rockchip/clk-pll.c |  247 ++-
 drivers/clk/rockchip/clk-rk3036.c  |  539 
 drivers/clk/rockchip/clk.h |   30 ++
 drivers/pinctrl/pinctrl-rockchip.c |   17 +
 include/dt-bindings/clock/rk3036-cru.h |  247 +++
 8 files changed, 1443 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/rk3036-sdk.dts
 create mode 100644 drivers/clk/rockchip/clk-rk3036.c
 create mode 100644 include/dt-bindings/clock/rk3036-cru.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

[RFC PATCH 3/5] Documentation: dt-bindings: add YAML eeprom binding

[Matt Porter]

Convert the eeprom.txt binding to standard YAML DT
binding format.

Signed-off-by: Matt Porter 
---
 Documentation/devicetree/bindings/eeprom.yaml | 44 +++
 1 file changed, 44 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/eeprom.yaml

diff --git a/Documentation/devicetree/bindings/eeprom.yaml 
b/Documentation/devicetree/bindings/eeprom.yaml
new file mode 100644
index 000..bf1244b
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom.yaml
@@ -0,0 +1,44 @@
+%YAML 1.2
+---
+id: eeprom-i2c
+
+title: EEPROMs (I2C)
+
+compatible:
+  - name: ",24c00"
+  - name: ",24c01"
+  - name: ",24c02"
+  - name: ",24c04"
+  - name: ",24c08"
+  - name: ",24c16"
+  - name: ",24c32"
+  - name: ",24c64"
+  - name: ",24c128"
+  - name: ",24c256"
+  - name: ",24c512"
+  - name: ",24c1024"
+  - name: ",spd"
+
+required:
+  - name: "reg"
+description: the I2c address of the EEPROM
+
+optional:
+  - name: "pagesize"
+description: >
+  the length of the pagesize for writing. Please consult the
+  manual of your device, that value varies a lot. A wrong value
+  may result in data loss! If not specified, a safety value of
+  '1' is used which will be very slow.
+  - name: "read-only"
+description: >
+  this parameterless property disables writes to the eeprom
+
+example:
+  - dts: |
+  eeprom@52 {
+  compatible = "atmel,24c32";
+  reg = <0x52>;
+  pagesize = <32>;
+   };
+...
-- 
2.1.4

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

[RFC PATCH 5/5] Documentation: dt-bindings: phy: add YAML TI PHY binding

[Matt Porter]

Convert the ti-phy.txt binding to standard YAML DT binding
format. This binding references the YAML generic PHY binding.

Signed-off-by: Matt Porter 
---
 Documentation/devicetree/bindings/phy/ti-phy.yaml | 166 ++
 1 file changed, 166 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/ti-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.yaml 
b/Documentation/devicetree/bindings/phy/ti-phy.yaml
new file mode 100644
index 000..ec93501
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti-phy.yaml
@@ -0,0 +1,166 @@
+%YAML 1.2
+---
+id: omap-control-phy
+
+title: OMAP Control PHY
+
+compatible:
+  - name: "ti,control-phy-otghs"
+description: if it has otghs_control mailbox register as on OMAP4.
+  - name: "ti,control-phy-usb2"
+description: if it has Power down bit in control_dev_conf register
+ e.g. USB2_PHY on OMAP5.
+  - name: "ti,control-phy-pipe3"
+description: if it has DPLL and individual Rx & Tx power control
+ e.g. USB3 PHY and SATA PHY on OMAP5.
+  - name: "ti,control-phy-pcie"
+description: for pcie to support external clock for pcie and to
+ set PCS delay value. e.g. PCIE PHY in DRA7x
+  - name: "ti,control-phy-usb2-dra7"
+description: if it has power down register like USB2 PHY on DRA7
+ DRA7 platform.
+  - name: "ti,control-phy-usb2-am437"
+description: if it has power down register like USB2 PHY on AM437
+ platform.
+required:
+  - name: "reg"
+description: register ranges as listed in the reg-names property
+  - name: "reg-names"
+description: >
+ "otghs_control" for control-phy-otghs "power",
+ "pcie_pcs" and "control_sma" for control-phy-pcie
+ "power" for all other types
+
+example:
+  - dts: |
+  omap_control_usb: omap-control-usb@4a002300 {
+  compatible = "ti,control-phy-otghs";
+  reg = <0x4a00233c 0x4>;
+  reg-names = "otghs_control";
+  };
+...
+
+---
+id: omap-usb2-phy
+
+title: OMAP USB2 PHY
+
+compatible:
+  - name: "ti,omap-usb2"
+
+required:
+  - name: "reg"
+description: >
+ Address and length of the register set for the device.
+  - name: "#phy-cells"
+description: >
+ determine the number of cells that should be given in
+ the phandle while referencing this phy.
+reference: phy-device
+  - name: "clocks"
+description: >
+ a list of phandles and clock-specifier pairs, one for
+ each entry in clock-names.
+reference: clock-consumer
+  - name: "clock-names"
+description: >
+ should include:
+ * "wkupclk" - wakeup clock.
+ * "refclk" - reference clock (optional).
+reference: clock-consumer
+
+optional:
+  - name: "ctrl-module"
+description: >
+ phandle of the control module used by PHY driver to
+ power on the PHY.
+
+example:
+  - dts: |
+  usb2phy@4a0ad080 {
+compatible = "ti,omap-usb2";
+reg = <0x4a0ad080 0x58>;
+ctrl-module = <&omap_control_usb>;
+#phy-cells = <0>;
+clocks = <&usb_phy_cm_clk32k>, <&usb_otg_ss_refclk960m>;
+clock-names = "wkupclk", "refclk";
+  };
+description: >
+ This is usually a subnode of ocp2scp to which it is
+ connected.
+...
+
+---
+id: ti-pipe3-phy
+
+title: TI Pipe3 PHY
+
+compatible:
+  - name: "ti,phy-usb3"
+  - name: "ti,phy-pipe3-sata"
+  - name: "ti,phy-pipe3-pcie"
+  - deprecated: "ti,omap-usb3"
+
+required:
+  - name: "reg"
+description: >
+ Address and length of the register set for the device.
+  - name: "reg-names"
+description: >
+ The names of the register addresses corresponding to
+ the registers filled in "reg".
+  - name: "#phy-cells"
+description: >
+ determine the number of cells that should be given in
+ the phandle while referencing this phy.
+reference: phy-device
+  - name: "clocks"
+description: >
+ a list of phandles and clock-specifier pairs, one for
+ each entry in clock-names.
+reference: clock-consumer
+  - name: "clock-names"
+description: >
+ should include:
+ * "wkupclk" - wakeup clock.
+ * "sysclk" - system clock.
+ * "refclk" - reference clock.
+ * "dpll_ref" - external dpll ref clk
+ * "dpll_ref_m2" - external dpll ref clk
+ * "phy-div" - divider for apll
+ * "div-clk" - apll clock
+reference: clock-consumer
+
+optional:
+  - name: "ctrl-module"
+description: >
+ phandle of the control module used by PHY driver to
+ power

[RFC PATCH 4/5] Documentation: dt-bindings: phy: add YAML generic PHY binding

[Matt Porter]

Convert the generic phy-bindings.txt binding to standard YAML
DT binding format.

Signed-off-by: Matt Porter 
---
 .../devicetree/bindings/phy/phy-bindings.yaml  | 89 ++
 1 file changed, 89 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.yaml

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.yaml 
b/Documentation/devicetree/bindings/phy/phy-bindings.yaml
new file mode 100644
index 000..9b164d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.yaml
@@ -0,0 +1,89 @@
+%YAML 1.2
+---
+id: phy-device
+
+title: PHY device
+
+description: >
+  This document explains only the device tree data binding.  For general
+  information about PHY subsystem refer to Documentation/phy.txt
+
+required:
+  - name: "#phy-cells"
+description: >
+  number of cells in a PHY specifier. The meaning of all those
+  cells is defined by the binding for the phy node. The PHY
+  provider can use the values in cells to find the appropriate
+  PHY.
+
+optional:
+  - name: "phy-supply"
+description: >
+  phandle to a regulator that provides power to the PHY. This
+  regulator will be managed during the PHY power on/off sequence.
+
+example:
+  - dts: |
+  phys: phy {
+  compatible = "xxx";
+  reg = <...>;
+  .
+  .
+  #phy-cells = <1>;
+  .
+  .
+  };
+description: >
+  Describes an IP block (PHY provider) that implements 2 different
+  PHYs. In order to differentiate between these 2 PHYs, an
+  additional specifier should be given while trying to get a
+  reference to it.
+...
+
+---
+id: phy-user
+
+title: PHY user
+
+required:
+  - name: "phys"
+description: >
+  the phandle for the PHY device (used by the PHY subsystem)
+  - name: "phy-names"
+description: >
+  the names of the PHY corresponding to the PHYs present in the
+  *phys* phandle
+
+example:
+  - dts: |
+  usb1: usb_otg_ss@xxx {
+  compatible = "xxx";
+  reg = ;
+  .
+  .
+  phys = <&usb2_phy>, <&usb3_phy>;
+  phy-names = "usb2phy", "usb3phy";
+  .
+  .
+  };
+description: >
+   Represents a controller that uses two PHYs, one for usb2 and one
+   for usb3.
+
+  - dts: |
+  usb2: usb_otg_ss@xxx {
+  compatible = "xxx";
+  reg = ;
+  .
+  .
+  phys = <&phys 1>;
+  phy-names = "usbphy";
+  .
+  .
+  };
+description: >
+  Represents a controller that uses one of the PHYs of the PHY
+  provider device defined previously. Note that the phy handle
+  has an additional specifier "1" to differentiate between the
+  two PHYs.
+...
-- 
2.1.4

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

[RFC PATCH 0/5] DT binding documents using text markup

[Matt Porter]

During the Device Tree microconference at Linux Plumbers 2015, we had
a short discussion about how to improve DT Binding Documentation. A
number of issues were raised (again, as these things have been
discussed in the past) including:

* Inconsistency between binding documents due to prose text
  format.
* Inability to reliably machine read bindings for mass update
  or search.
* Bit rot of bindings as new conventions are agreed upon but
  only new bindings are changed.

Grant Likely probably summed up the issue best with "...as long as
bindings are human readable, we'll have issues...". The context
of that comment was, of course, regarding our current documents
written in very inconsistent prose style. When the topic of needing
the bindings in a rigid format was raised, there was general head
nodding that this was needed. It was noted that this has been
discussed many times before and nothing has been done.

My proposed solution to the problem is to convert all DT bindings
a rigid text markup format. In choosing a text markup language my
requirements were:

1) Human readable
2) Well documented
3) Easy to translate to other data formats
4) Well supported by tools and libraries

After looking at a number of markup options, YAML stood out as the
one that meets all of these requirements. The YAML syntax is adopted
in many projects specifically because of the high level of readability.
A comprehensive spec is at http://www.yaml.org/spec/1.2/spec.html.
There's a number of tools to convert between YAML and other popular
data formats such as JSON and XML. XML was cited by Behan Webster
during the microconference as an important data format as the type
of developers that may produce comprehensive DTS Binding validation
tools will want to use XML. Every major scripting language has a
high level binding to the low level libyaml C library to facilitate
handling of YAML data files.

One caveat with YAML is it does not tolerate tabs. Yes, I said it.
No tabs! This can be managed with proper editor modes and also with
helper scripts to strip tabs to aid in people passing planned
checkpatch.pl checks that would run YAML DT Binding specific tag
validators for new bindings.

The scope of the initial YAML DT Binding format was specifically
limited to supporting *only* the content we have in bindings today.
The idea here is to propose and agree on something that will take
us just a few steps in the right direction. If we move *all* current
binding content to a machine parseable format, additional features
can be added with more automation and scripting. As it stands today,
because of the inconsistency of the wording of the files, we can't
add a lot of new features to the content until we convert what we
have today into a standard format.

With that said, it should be noted that some new features such as
"type" tags to indicate cell types could be added to support
additional DTS validation beyond what the current content supports.
Another possibility is adding "range" type information to validate
the legal values for a cell.

This series is broken up into three major parts:

1) The documentation defining the YAML DT binding format
2) A skeleton device binding example illustrating use of this format
3) Some real binding conversions (eeprom.txt, phy-bindings.txt, and
   ti-phy.txt

As a proof of concept of what can be done with a proper machine
readable DT binding source file, there's a simple markdown document
generator at https://github.com/konsulko/dtgendoc. Also, to see
actual output from the generator, the generated markdown from those
bindings is viewable at https://github.com/konsulko/dtgendoc/wiki

There's a lot of other possibilities for validation tools using
only the data we have today in the bindings. In addition, Frank
Rowand covered some DT debug techniques that would benefit from
the binding documentation being 100% reliably searchable.

I found it useful to see a side-by-side view of a converted doc
versus the original content, so here's a screenshot of eeprom.txt
vs. eeprom.yaml:
https://github.com/konsulko/dtgendoc/wiki#eepromtxt-vs-eepromyaml

When we decide on a text markup format that is acceptable, then the
next step is to convert all the bindings. That process would start
with the complete set of generic bindings as they will be referenced
by the actual device bindings.

If the RFC wasn't explicit enough...comments welcome.

-Matt

Matt Porter (5):
  Documentation: dt-bindings: add documentation on new DT binding format
  Documentation: dt-bindings: add example DT binding document
  Documentation: dt-bindings: add YAML eeprom binding
  Documentation: dt-bindings: phy: add YAML generic PHY binding
  Documentation: dt-bindings: phy: add YAML TI PHY binding

 .../devicetree/bindings/dt-binding-format.txt  | 106 +
 Documentation/devicetree/bindings/eeprom.yaml  |  44 ++
 .../devicetree/bindings/phy/phy-bindi

[RFC PATCH 2/5] Documentation: dt-bindings: add example DT binding document

[Matt Porter]

Add a skeleton DT binding document that serves as the canonical
example for implementing YAML-based DT bindings documentation.
The skeleton binding illustrates use of all fields and variations
described in the dt-binding-format.txt documentation.

Signed-off-by: Matt Porter 
---
 Documentation/devicetree/bindings/skeleton.yaml | 98 +
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/skeleton.yaml

diff --git a/Documentation/devicetree/bindings/skeleton.yaml 
b/Documentation/devicetree/bindings/skeleton.yaml
new file mode 100644
index 000..175965f
--- /dev/null
+++ b/Documentation/devicetree/bindings/skeleton.yaml
@@ -0,0 +1,98 @@
+%YAML 1.2
+---
+id: skel-device
+
+title: Skeleton Device
+
+maintainer:
+  - name: Skeleton Person 
+
+description: >
+  The Skeleton Device binding represents the SK11 device produced by
+  the Skeleton Corporation. The binding can also support compatible
+  clones made by second source vendors.
+
+compatible:
+  - name: "skel,sk11"
+  - name: "faux,fx11"
+description: A clone of the original sk11 device
+
+required:
+  - name: "reg"
+description: chip select address of skeleton device
+reference: spi-slave
+  - name: "spi-max-frequency"
+description: >
+  Maximum SPI clocking speed of skeleton device in Hz, must be
+  100
+reference: spi-slave
+
+optional:
+  - name: "spi-cs-high"
+description: >
+  Set if skeleton device configuration straps are set for chip
+  select polarity high
+reference: spi-slave
+
+deprecated:
+  - name: "skel,deprecated1"
+description: >
+  First of two deprecated properties.
+  - name: "skel,deprecated2"
+description: >
+  Second of two deprecated properties.
+
+example:
+  - dts: |
+  sk11@0 {
+  compatible = "skel,sk11";
+  reg = <0>;
+  spi-max-frequency = <100>;
+  spi-cs-high;
+  };
+...
+
+---
+id: skel-mini
+
+title: Skeleton Mini Device
+
+maintainer:
+  - name: Rogue Developer 
+
+description: >
+  The Skeleton Mini Device binding represents the SK47x series devices
+  produced by the Skeleton Corporation.
+
+compatible:
+  - name: "skel,sk472"
+  - name: "skel,sk473"
+  - name: "skel,sk474"
+  - deprecated: "skel,sk47x"
+
+required:
+  - name: "reg"
+description: offset and length of the registers
+
+optional:
+  - name: "skel,sync-mode"
+description: Enable synchronous transfer mode
+
+example:
+  - dts: |
+  sk472@beef {
+  compatible = "skel,sk472";
+  reg = <0xbeef 0x100>;
+  };
+description: >
+  Demonstrates an SK472 in normal mode.
+
+  - dts: |
+  sk474@dead {
+  compatible = "skel,sk474";
+  reg = <0xdead 0x100>;
+  skel,sync-mode;
+  };
+description: >
+  Demonstrates an SK474 in synchronous mode.
+...
-- 
2.1.4

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

[RFC PATCH 1/5] Documentation: dt-bindings: add documentation on new DT binding format

[Matt Porter]

Documentation explaining the syntax and format of the YAML-based DT binding
documentation.

Signed-off-by: Matt Porter 
---
 .../devicetree/bindings/dt-binding-format.txt  | 106 +
 1 file changed, 106 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dt-binding-format.txt

diff --git a/Documentation/devicetree/bindings/dt-binding-format.txt 
b/Documentation/devicetree/bindings/dt-binding-format.txt
new file mode 100644
index 000..f9acc22
--- /dev/null
+++ b/Documentation/devicetree/bindings/dt-binding-format.txt
@@ -0,0 +1,106 @@
+--
+Device Tree Binding Format
+--
+
+Background
+--
+
+DT bindings historically were written as text in prose format which
+led to issues in usability of that source documentation. Some of
+these issues include the need to programmatically process binding
+source documentation to do DTS validation, perform mass updates to
+format/style, and to generate publishable documentation in HTML or
+PDF form.
+
+Overview
+
+
+The DT binding format is based on the YAML text markup language.
+Although there are many text markup options available, YAML
+fulfills all requirements considered for a DT binding source format
+which include:
+
+1) Must be human readable
+2) Must be easily translated to other data formats (XML, JSON, etc).
+3) Must have sufficient tools and libraries to enable developers to
+   build new tools for DT binding processing
+4) Must have a complete spec to refer to syntax
+
+YAML is documentated in the specification found at
+http://www.yaml.org/spec/1.2/spec.html
+
+The required YAML DT binding tag format and syntax are defined in
+the following sections.
+
+YAML DT Binding Syntax
+--
+
+* Lines starting with "#" are comments and not part of the binding itself
+* "%YAML 1.2" starts a file, indicating the version of YAML in use
+* "---" starts a binding document
+* "..." ends a binding document
+* Multiple binding documents may exist in a single file
+* Tabs are not permitted
+* Scope is denoted by indentation of two spaces
+* Key value pairs are denoted by "key: value"
+* Sequences are denoted by "- "
+* Scalar values may convert newlines to spaces and preserve blank
+  lines for long description formatting using ">"
+* Scalar values may escape all reserved characters and preserve
+  newlines by using "|" to denote literal style
+
+For additional information on YAML syntax, refer to the specification
+at http://www.yaml.org/spec/1.2/spec.html
+
+YAML DT Binding Format
+--
+
+The following YAML types are supported in the DT binding format:
+
+* [R] id: unique identifier in property form (e.g. skel-device)
+
+* [R] title: title of the binding
+
+* [O] maintainer: sequence of maintainers
+  [R] name: name and email of maintainer or mailing list in RFC822
+form.
+
+* [O] description: full description of the binding
+
+* [O] compatible: sequence of valid compatible descriptors
+  [R] name: the compatible string surrounded in double quotes
+  [O] deprecated: a deprecated compatible string surrounded in
+  double quotes
+  [O] description: description of the compatible string
+
+* [O] required: sequence of required properties:
+  [R] name: name of the property surrounded in double quotes
+  [R] description: description of the property
+  [O] reference: optional reference to a binding id
+
+* [O] optional: sequence of optional properties:
+  [R] name: name of the property surrounded in double quotes
+  [R] description: description of the property
+  [O] reference: optional reference to a binding id
+
+* [O] deprecated: sequence of deprecated properties:
+  [R] name: name of the property surrounded in double quotes
+  [R] description: description of the property
+  [O] reference: optional reference to a binding id
+
+* [R] example: sequence of examples:
+  [R] dts: DT source of example usage. The example text must use
+   literal style ("|") so that it retains indentation and
+   newlines.
+  [O] description: description of the example
+
+Note: [R] and [O] denote required and optional fields, respectively.
+
+Skeleton Binding
+
+
+The skeleton.yaml binding found in the top of the DT binding tree
+is the canonical example of syntax and format to use when writing
+a DT binding document. It is maintained with the latest formatting
+conventions, making it the best starting point when writing a new DT
+binding.
-- 
2.1.4

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

Re: [PATCH v6] arm64: dts: Add spi bus dts

[Daniel Kurtz]

Matthias,

On Mon, Aug 17, 2015 at 12:32 PM, Daniel Kurtz  wrote:
> On Mon, Aug 17, 2015 at 11:29 AM, Leilk Liu  wrote:
>>
>> This patch adds MT8173 spi bus controllers into device tree.
>>
>> Signed-off-by: Leilk Liu 
>
> Reviewed-by: Daniel Kurtz 

The other SPI patches have already been picked up in broonie's spi tree.
Can you pick this one into your mediatek tree?

Thanks.
-Dan

>
>> ---
>> Change in this patch:
>> pinctl and pad-select fields are board specific, so move to
>> mt8173-evb.dtsi, and status = "okay".
>> ---
>>  arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 ++
>>  arch/arm64/boot/dts/mediatek/mt8173.dtsi| 12 
>>  2 files changed, 30 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
>> b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> index 4be66ca..811cb76 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> @@ -387,6 +387,24 @@
>> };
>>  };
>>
>> +&pio {
>> +   spi_pins_a: spi0 {
>> +   pins_spi {
>> +   pinmux = ,
>> +   ,
>> +   ,
>> +   ;
>> +   };
>> +   };
>> +};
>> +
>> +&spi {
>> +   pinctrl-names = "default";
>> +   pinctrl-0 = <&spi_pins_a>;
>> +   mediatek,pad-select = <0>;
>> +   status = "okay";
>> +};
>> +
>>  &uart0 {
>> status = "okay";
>>  };
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
>> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index d18ee42..3dfb6ed 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -365,6 +365,18 @@
>> status = "disabled";
>> };
>>
>> +   spi: spi@1100a000 {
>> +   compatible = "mediatek,mt8173-spi";
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   reg = <0 0x1100a000 0 0x1000>;
>> +   interrupts = ;
>> +   clocks = <&topckgen CLK_TOP_SPI_SEL>,
>> +<&topckgen CLK_TOP_SYSPLL3_D2>;
>> +   clock-names = "spi-clk", "parent-clk";
>> +   status = "disabled";
>> +   };
>> +
>> i2c3: i2c3@1101 {
>> compatible = "mediatek,mt8173-i2c";
>> reg = <0 0x1101 0 0x70>,
>> --
>> 1.8.1.1.dirty
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer

[Guenter Roeck]

On 08/27/2015 06:30 PM, Yang, Wenyou wrote:




-Original Message-
From: Guenter Roeck [mailto:li...@roeck-us.net]
Sent: 2015年8月7日 23:26
To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free-
electrons.com; devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
watch...@vger.kernel.org
Subject: Re: [PATCH v6 1/2] drivers: watchdog: add a driver to support SAMA5D4
watchdog timer

On 08/06/2015 03:16 AM, Wenyou Yang wrote:

>From SAMA5D4, the watchdog timer is upgrated with a new feature,
which is describled as in the datasheet, "WDT_MR can be written until
a LOCKMR command is issued in WDT_CR".
That is to say, as long as the bootstrap and u-boot don't issue a
LOCKMR command, WDT_MR can be written more than once in the driver.

So the SAMA5D4 watchdog driver's implementation is different from the
at91sam9260 watchdog driver implemented in file at91sam9_wdt.c.
The user application open the device file to enable the watchdog timer
hardware, and close to disable it, and set the watchdog timer timeout
by seting WDV and WDD fields of WDT_MR register, and ping the watchdog
by issuing WDRSTT command to WDT_CR register with hard-coded key.

Signed-off-by: Wenyou Yang 


Reviewed-by: Guenter Roeck 


Hi Vim,

Can this patch series be merged? Could you please?


It is included in the pull request I sent to Wim last week.

Guenter


--
To unsubscribe from this list: send the line "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] usb: chipidea: add xilinx zynq platform data

[Peter Chen]

On Thu, Aug 27, 2015 at 09:33:07AM -0500, Nathan Sullivan wrote:
> On Thu, Aug 27, 2015 at 01:11:30PM +0530, punnaiah choudary kalluri wrote:
> > Hi,
> > 
> > On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen  
> > wrote:
> > > On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep subbaraya wrote:
> > >> Hi,
> > >>
> > >>
> > >> On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan 
> > >>  wrote:
> > >> > The Xilinx Zynq udc does not need the CI_HDRC_DISABLE_STREAMING flag,
> > >> > unlike the default platform data.  Add platform data specific to the
> > >> > Zynq udc.
> > >> >
> > >> > Based on a patch by the same name from the Xilinx vendor tree.
> > >>
> > >> I am that Xilinx guy who sent this patch :). It is in Xilinx tree as
> > >> temporary fix and
> > >> I did not debug further why UDC works only when streaming is enabled.
> > >> Probably this is right time to post my question here.
> > >> I was expecting like:
> > >> Streaming disabled - both low bandwidth and high bandwidth systems
> > >> should work fine
> > >> Streaming enabled - only for high bandwidth systems
> > >> but this is not the case, Zynq UDC works only when Streaming is enabled.
> > >> Please correct me if I am wrong.
> > >
> > > You are right, stream mode disabled should work at anytime.
> > > It is so strange why zynq UDC only works when stream mode is enabled.
> > 
> > I am referring the section 8.5.2 in Synopsys usb 2.0 HS controllervDoc 
> > 2.20a,
> >  this is what it says about SDIS (streaming mode disable option)
> > 
> > Before activating this mode, the user must check if the TX latency
> > buffers per endpoint are able to
> > accommodate at least one entire maximum size packet. The RX buffer
> > size must, at least, double the TX
> > buffer size per endpoint. To optimize the stream disable performance,
> > system bus burst must be set as high
> > as possible.
> > When the stream disable mode is used, the burst size (VUSB_HS_RX_BURST
> > and VUSB_HS_TX_BURST)
> > must be a integer sub-multiple of the latency buffer size
> > (VUSB_HS_RX_DEPTH for RX buffer and
> > VUSB_HS_TX_CHAN for the TX buffer). If this is not respected the
> > controller will not work properly in stream
> > disable mode.
> > The stream disable mode should just be used in situations where the
> > available system bandwidth is low or the
> > system bus access latency is high, in order to avoid underruns and
> > overruns in the latency buffers. This works
> > for all types of endpoints, except for ISO endpoints.
> > Such a system can't ensure the real time support that the ISO
> > endpoints require, so the ISO endpoints are not
> > supported when the SDIS bit is set.
> > 
> > Definitely we need to root cause why disable streaming mode is not
> > working for zynq but from controller spec
> > point of view it is possible that controller not work properly in
> > stream disable mode.
> > 
> > Regards,
> > Punnaiah
> > 
> 
> Maybe the burst size isn't set correctly by default?  It does say the 
> controller
> won't work correctly with stream disable set and an invalid burst size.  Looks
> like TX and RX burst both default to 16, per the Zynq manual.
> 
> With the stream disable bit set, the behvior we see on our hardware is
> that priming just stops, with an outstanding transfer in memory marked
> active in the status field by the controller.  This happens at random, even 
> when doing single transfers at a time like with g_ether set to have a queue
> size of 1.  With SDIS clear everything works great.  Given that the Zynq is 
> not
> bandwidth constrained, it seems like SDIS clear should be the default.
> 

I suspect the possible reason is the tx buffer for each endpoint is
small (<=512 bytes), so it can't copy one packet (assume max packet size
for bulk) to tx buffer, then the prime can't be finished.

Would you help to dump the registers HWTXBUF ($BASE + 0x10) and DCCPARAMS
($BASE + 124)?

tx buffer size = ((2 ^ HWTXBUF.VUSB_HS_TX_ADD) / DCCPARAMS.DEN) *
(DWORD_PER_BYTES)

DWORD_PER_BYTES is 4

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "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] dt-bindings: thermal: Add binding document for Mediatek thermal controller

[Daniel Kurtz]

On Thu, Aug 27, 2015 at 7:49 PM, Punit Agrawal  wrote:
> [ + device tree folks ]
>
> Hi Sascha,
>
> When introducing a new binding, it is a good idea to get reviews from
> the device tree maintainers. I've added a few folks here. Please keep
> them in the loop for future postings.
>
> Sascha Hauer  writes:
>
>> Signed-off-by: Sascha Hauer 
>> Reviewed-by: Daniel Kurtz 
>
> Please add a commit log.
>
>> ---
>>  .../bindings/thermal/mediatek-thermal.txt  | 38 
>> ++
>>  include/dt-bindings/thermal/mt8173.h   | 13 
>>  2 files changed, 51 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
>>  create mode 100644 include/dt-bindings/thermal/mt8173.h
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt 
>> b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
>> new file mode 100644
>> index 000..1697375
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
>> @@ -0,0 +1,38 @@
>> +* Mediatek Thermal
>> +
>> +This describes the device tree binding for the Mediatek thermal controller
>> +which measures the on-SoC temperatures. This device does not have its own 
>> ADC,
>> +instead it directly controls the AUXADC via AHB bus accesses. For this 
>> reason
>> +this device needs phandles to the AUXADC. Also it controls a mux in the
>> +apmixedsys register space via AHB bus accesses, so a phandle to the 
>> APMIXEDSYS
>> +is also needed.
>> +
>> +Required properties:
>> +- compatible: "mediatek,mt8173-thermal"
>> +- reg: Address range of the thermal controller
>> +- interrupts: IRQ for the thermal controller
>> +- clocks, clock-names: Clocks needed for the thermal controller. required
>> +   clocks are:
>> +"therm":  Main clock needed for register access
>> +"auxadc": The AUXADC clock
>> +- resets: Reference to the reset controller controlling the thermal 
>> controller.
>> +- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
>> +- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
>> +- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description. 
>> See
>> +   include/dt-bindings/thermal/mt8173.h for valid sensor
>> +   numbers.
>> +
>> +Example:
>> +
>> + thermal: thermal@1100b000 {
>> + #thermal-sensor-cells = <1>;
>> + compatible = "mediatek,mt8173-thermal";
>> + reg = <0 0x1100b000 0 0x1000>;
>> + interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
>> + clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
>> + clock-names = "therm", "auxadc";
>> + resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
>> + reset-names = "therm";
>> + mediatek,auxadc = <&auxadc>;
>> + mediatek,apmixedsys = <&apmixedsys>;
>> + };
>> diff --git a/include/dt-bindings/thermal/mt8173.h 
>> b/include/dt-bindings/thermal/mt8173.h
>> new file mode 100644
>> index 000..692e74c
>> --- /dev/null
>> +++ b/include/dt-bindings/thermal/mt8173.h
>> @@ -0,0 +1,13 @@
>> +/*
>> + * This header provides constants for mediatek,mt8173-thermal
>> + */
>> +
>> +#ifndef _DT_BINDINGS_THERMAL_MEDIATEK_MT8173_H
>> +#define _DT_BINDINGS_THERMAL_MEDIATEK_MT8173_H
>> +
>> +#define MT8173_THERMAL_ZONE_CA53 0
>> +#define MT8173_THERMAL_ZONE_CA57 1
>> +#define MT8173_THERMAL_ZONE_GPU  2
>> +#define MT8173_THERMAL_ZONE_CORE 3
>> +
>> +#endif /* _DT_BINDINGS_THERMAL_MEDIATEK_MT8173_H */
>
> The constants in this include are not used in the patchset. Please drop
> this hunk and introduce it when you use it.

These constants are part of the devicetree ABI, and I believe they
should be included with the binding.
To make this more concrete, I think these constants could be used as
array indices when initializing the corresponding banks of "bank_data"
in patch 2 (like you do when initializing scp_domain_data in the
scpsys driver).

-Dan

>
> Thanks,
> Punit
--
To unsubscribe from this list: send the line "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] arm64: dts: mediatek: mt8173 PSCI-1.0 support

[fan.chen]

From: Fan Chen 

This patch adds psci comatible properties to support all mandatory
functions of PSCI-1.0, PSCI-0.2 and PSCI-0.1, and system suspend
can be supported in PSCI-1.0.

Signed-off-by: Fan Chen 
---
Because PSCI-1.0 patches hadn't landed on mainline, this patch is
based on three patch sets below:
[0] http://www.spinics.net/lists/arm-kernel/msg425793.html
PSCI: system suspend support
[1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
psci/unification
[2] http://www.spinics.net/lists/devicetree/msg82017.html
[PATCH 0/6] drivers: firmware: psci: add basic v1.0 support

Before they are merged in, this patch still works fine with psci-0.2
support in current mainline.
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d18ee42..b9b4205 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -95,7 +95,7 @@
};
 
psci {
-   compatible = "arm,psci";
+   compatible = "arm,psci-1.0", "arm,psci-0.2", "arm,psci";
method = "smc";
cpu_suspend   = <0x8401>;
cpu_off   = <0x8402>;
-- 
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: [RESEND PATCH v16 4/4] ARM: dts: add the support power-domain node on RK3288 SoCs

[Doug Anderson]

Kevin,

On Thu, Aug 27, 2015 at 5:24 PM, Kevin Hilman  wrote:
>> That is not really workable: the attach and detach happen in
>> probe/remove path; if you do not have driver for the device you will
>> miss the clocks for it.
>
> And in my proposal, I suggested that clocks without drivers are
> good candidates to list in the domain, with the caveat that the be
> called out (documented) as being device clocks that are missing a
> driver, so when a driver shows up they can be moved accordingly, and in
> a way that actually describes the hardware.

What happens if someone disables the driver using the CONFIG subsystem?

What happens if this is a device that someone has set to 'status =
"disabled";' in the device tree?

Even if the device is disabled in one of those two ways, we still need
the clocks to be turned on.  ...so if we turn on/off the VIO domain we
need to turn on the EDP clock even if there's no EDP in the current
board / config.  We might turn on/off VIO for one of the other devices
in the VIO domain for one of the other devices in VIO that we are
using.

-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] ARM: dts: use vqmmc-supply of emmc/sd for exynos4412-odroid-common

[Krzysztof Kozlowski]

On 28.08.2015 10:48, Jaehoon Chung wrote:
> On 08/27/2015 09:26 PM, Krzysztof Kozlowski wrote:
>> W dniu 27.08.2015 o 18:29, Jaehoon Chung pisze:
>>> Currently vmmc's property is wrong.
>>> If it needs to control two supplies, then it has to use vmmc/vqmmc-supply.
>>> (Card supply power and I/O Line supply Power.)
>>>
>>> Signed-off-by: Jaehoon Chung 
>>> ---
>>>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 7 ---
>>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
>>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>>> index ca7d168..4ddabfd 100644
>>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>>> @@ -461,10 +461,10 @@
>>>  &mshc_0 {
>>> pinctrl-0 = <&sd4_clk &sd4_cmd &sd4_bus4 &sd4_bus8>;
>>> pinctrl-names = "default";
>>> -   vmmc-supply = <&ldo20_reg &buck8_reg>;
>>> +   vmmc-supply = <&ldo20_reg>;
>>> +   vqmmc-supply = <&buck8_reg>;
>>
>> Shouldn't this be reversed? LDO20 has 1.8V and it goes to MMC connector,
>> so it should be VQMMC?
> 
> If my schematics is right thing, buck8 is used LAN card power.
> I will send after removing buck8_reg. how about?
> Anyway, Thanks for pointing out. :)

Removing this regulator from this node would effectively disable it.
That could affect other components like LAN.

Anyway before fixing the order I would prefer to find the right
regulators used by MSHC node.

Best regards,
Krzysztof

> 
> I don't know who this regulator applied. I have guessed that it used for eMMC.
> Sorry for guessing.
> 
> Best Regards,
> Jaehoon Chung
> 
>>
>> In the same time I can't find on schematics where BUCK8 goes...
>>
>> The SDHCI_2 node below looks good.
>>
>> Best regards,
>> Krzysztof
>>
>>> mmc-pwrseq = <&emmc_pwrseq>;
>>> status = "okay";
>>> -
>>> num-slots = <1>;
>>> broken-cd;
>>> card-detect-delay = <200>;
>>> @@ -485,7 +485,8 @@
>>> bus-width = <4>;
>>> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
>>> pinctrl-names = "default";
>>> -   vmmc-supply = <&ldo4_reg &ldo21_reg>;
>>> +   vmmc-supply = <&ldo21_reg>;
>>> +   vqmmc-supply = <&ldo4_reg>;
>>> cd-gpios = <&gpk2 2 0>;
>>> cd-inverted;
>>> 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

Re: [PATCH] ARM: dts: use vqmmc-supply of emmc/sd for exynos4412-odroid-common

[Jaehoon Chung]

On 08/27/2015 09:26 PM, Krzysztof Kozlowski wrote:
> W dniu 27.08.2015 o 18:29, Jaehoon Chung pisze:
>> Currently vmmc's property is wrong.
>> If it needs to control two supplies, then it has to use vmmc/vqmmc-supply.
>> (Card supply power and I/O Line supply Power.)
>>
>> Signed-off-by: Jaehoon Chung 
>> ---
>>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> index ca7d168..4ddabfd 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> @@ -461,10 +461,10 @@
>>  &mshc_0 {
>>  pinctrl-0 = <&sd4_clk &sd4_cmd &sd4_bus4 &sd4_bus8>;
>>  pinctrl-names = "default";
>> -vmmc-supply = <&ldo20_reg &buck8_reg>;
>> +vmmc-supply = <&ldo20_reg>;
>> +vqmmc-supply = <&buck8_reg>;
> 
> Shouldn't this be reversed? LDO20 has 1.8V and it goes to MMC connector,
> so it should be VQMMC?

If my schematics is right thing, buck8 is used LAN card power.
I will send after removing buck8_reg. how about?
Anyway, Thanks for pointing out. :)

I don't know who this regulator applied. I have guessed that it used for eMMC.
Sorry for guessing.

Best Regards,
Jaehoon Chung

> 
> In the same time I can't find on schematics where BUCK8 goes...
> 
> The SDHCI_2 node below looks good.
> 
> Best regards,
> Krzysztof
> 
>>  mmc-pwrseq = <&emmc_pwrseq>;
>>  status = "okay";
>> -
>>  num-slots = <1>;
>>  broken-cd;
>>  card-detect-delay = <200>;
>> @@ -485,7 +485,8 @@
>>  bus-width = <4>;
>>  pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
>>  pinctrl-names = "default";
>> -vmmc-supply = <&ldo4_reg &ldo21_reg>;
>> +vmmc-supply = <&ldo21_reg>;
>> +vqmmc-supply = <&ldo4_reg>;
>>  cd-gpios = <&gpk2 2 0>;
>>  cd-inverted;
>>  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

RE: [PATCH v6 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer

[Yang, Wenyou]

> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 2015年8月7日 23:26
> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free-
> electrons.com; devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; 
> linux-
> watch...@vger.kernel.org
> Subject: Re: [PATCH v6 1/2] drivers: watchdog: add a driver to support SAMA5D4
> watchdog timer
> 
> On 08/06/2015 03:16 AM, Wenyou Yang wrote:
> >>From SAMA5D4, the watchdog timer is upgrated with a new feature,
> > which is describled as in the datasheet, "WDT_MR can be written until
> > a LOCKMR command is issued in WDT_CR".
> > That is to say, as long as the bootstrap and u-boot don't issue a
> > LOCKMR command, WDT_MR can be written more than once in the driver.
> >
> > So the SAMA5D4 watchdog driver's implementation is different from the
> > at91sam9260 watchdog driver implemented in file at91sam9_wdt.c.
> > The user application open the device file to enable the watchdog timer
> > hardware, and close to disable it, and set the watchdog timer timeout
> > by seting WDV and WDD fields of WDT_MR register, and ping the watchdog
> > by issuing WDRSTT command to WDT_CR register with hard-coded key.
> >
> > Signed-off-by: Wenyou Yang 
> 
> Reviewed-by: Guenter Roeck 

Hi Vim,

Can this patch series be merged? Could you please?

Best Regards,
Wenyou Yang

Re: [PATCH v2 1/2] watchdog: bcm7038: add device tree binding documentation

[Guenter Roeck]

On Thu, Aug 27, 2015 at 03:53:23PM -0700, Justin Chen wrote:
> Add device tree binding documentation for the watchdog hardware block
> on bcm7038 and newer SoCs.
> 
> Signed-off-by: Justin Chen 

Acked-by: Guenter Roeck 

> ---
>  .../devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt | 19 
> +++
>  1 file changed, 19 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
> new file mode 100644
> index 000..39e5cf5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
> @@ -0,0 +1,19 @@
> +BCM7038 Watchdog timer
> +
> +Required properties:
> +
> +- compatible : should be "brcm,bcm7038-wdt"
> +- reg : Specifies base physical address and size of the registers.
> +
> +Optional properties:
> +
> +- clocks: The clock running the watchdog. If no clock is found the
> +   driver will default to 2700 HZ.
> +
> +Example:
> +
> +watchdog {
> + compatible = "brcm,bcm7038-wdt";
> + clocks = <&upg_fixed>;
> + reg = <0xf040a7e8 0x16>;
> +};
> -- 
> 2.1.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] watchdog: Watchdog driver for Broadcom Set-Top Box

[Guenter Roeck]

Hi Justin,

On Thu, Aug 27, 2015 at 03:53:24PM -0700, Justin Chen wrote:
> Watchdog driver for Broadcom 7038 and newer chips.
> 
> Signed-off-by: Justin Chen 

Almost good. Two little but important details left ...

> ---
>  drivers/watchdog/Kconfig   |   8 ++
>  drivers/watchdog/Makefile  |   1 +
>  drivers/watchdog/bcm7038_wdt.c | 235 
> +
>  3 files changed, 244 insertions(+)
>  create mode 100644 drivers/watchdog/bcm7038_wdt.c
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 241fafd..4fbe8ab 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -1291,6 +1291,14 @@ config BCM_KONA_WDT_DEBUG
>  
> If in doubt, say 'N'.
>  
> +config BCM7038_WDT
> + tristate "BCM7038 Watchdog"
> + select WATCHDOG_CORE
> + help
> +  Watchdog driver for the built-in hardware in Broadcom 7038 SoCs.
> +
> +  Say 'Y or 'M' here to enable the driver.
> +
>  config IMGPDC_WDT
>   tristate "Imagination Technologies PDC Watchdog Timer"
>   depends on HAS_IOMEM
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 59ea9a1..65d4169 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -66,6 +66,7 @@ obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
>  obj-$(CONFIG_MESON_WATCHDOG) += meson_wdt.o
>  obj-$(CONFIG_MEDIATEK_WATCHDOG) += mtk_wdt.o
>  obj-$(CONFIG_DIGICOLOR_WATCHDOG) += digicolor_wdt.o
> +obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
>  
>  # AVR32 Architecture
>  obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> diff --git a/drivers/watchdog/bcm7038_wdt.c b/drivers/watchdog/bcm7038_wdt.c
> new file mode 100644
> index 000..5e54c1b
> --- /dev/null
> +++ b/drivers/watchdog/bcm7038_wdt.c
> @@ -0,0 +1,235 @@
> +/*
> + * Copyright (C) 2015 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define WDT_START_1  0xff00
> +#define WDT_START_2  0x00ff
> +#define WDT_STOP_1   0xee00
> +#define WDT_STOP_2   0x00ee
> +
> +#define WDT_TIMEOUT_REG  0x0
> +#define WDT_CMD_REG  0x4
> +
> +#define WDT_MIN_TIMEOUT  1 /* seconds */
> +#define WDT_DEFAULT_TIMEOUT  30 /* seconds */
> +#define WDT_DEFAULT_RATE 2700
> +
> +struct bcm7038_watchdog {
> + void __iomem*base;
> + struct watchdog_device  wdd;
> + u32 rate;
> + struct clk  *clk;
> +};
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +
> +static void bcm7038_wdt_set_timeout_reg(struct watchdog_device *wdog)
> +{
> + struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
> + u32 timeout;
> +
> + timeout = wdt->rate * wdog->timeout;
> +
> + writel(timeout, wdt->base + WDT_TIMEOUT_REG);
> +}
> +
> +static int bcm7038_wdt_ping(struct watchdog_device *wdog)
> +{
> + struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
> +
> + writel(WDT_START_1, wdt->base + WDT_CMD_REG);
> + writel(WDT_START_2, wdt->base + WDT_CMD_REG);
> +
> + return 0;
> +}
> +
> +static int bcm7038_wdt_start(struct watchdog_device *wdog)
> +{
> + bcm7038_wdt_set_timeout_reg(wdog);
> + bcm7038_wdt_ping(wdog);
> +
> + return 0;
> +}
> +
> +static int bcm7038_wdt_stop(struct watchdog_device *wdog)
> +{
> + struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
> +
> + writel(WDT_STOP_1, wdt->base + WDT_CMD_REG);
> + writel(WDT_STOP_2, wdt->base + WDT_CMD_REG);
> +
> + return 0;
> +}
> +
> +static int bcm7038_wdt_set_timeout(struct watchdog_device *wdog,
> +unsigned int t)
> +{
> + /* Can't modify timeout value if watchdog timer is running */
> + bcm7038_wdt_stop(wdog);
> + wdog->timeout = t;
> + bcm7038_wdt_start(wdog);
> +
> + return 0;
> +}
> +
> +static unsigned int bcm7038_wdt_get_timeleft(struct watchdog_device *wdog)
> +{
> + struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
> + u32 time_left;
> +
> + time_left = readl(wdt->base + WDT_CMD_REG);
> +
> + return time_left / wdt->rate;
> +}
> +
> +static struct watchdog_info bcm7038_wdt_info = {
> + .identity   = "Broadcom BCM7038 Watchdog Timer",
> + .options= WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
> + WDIOF_MAGICCLOSE
> +};
> +
> +static struct watc

Re: [PATCH v2 1/2] Documentation: dt: add Broadcom BCM7038 PWM controller binding

[Florian Fainelli]

On 24/08/15 11:27, Florian Fainelli wrote:
> Add a binding documentation for the Broadcom BCM7038 PWM controller found in
> BCM7xxx chips.

Got to think about this some more, I will just remove the optional
"clocks" phandle, since the PWM block really needs a input clock to
operate, will respin a v3 with these changes shortly.

> 
> Signed-off-by: Florian Fainelli 
> ---
>  .../devicetree/bindings/pwm/brcm,bcm7038-pwm.txt   | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt
> 
> diff --git a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt 
> b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt
> new file mode 100644
> index ..8b9bc43b561e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt
> @@ -0,0 +1,22 @@
> +Broadcom BCM7038 PWM controller (BCM7xxx Set Top Box PWM controller)
> +
> +Required properties:
> +
> +- compatible: must be "brcm,bcm7038-pwm"
> +- reg: physical base address and length for this controller
> +- #pwm-cells: should be 2. See pwm.txt in this directory for a description
> +  of the cells format.
> +
> +Optional properties:
> +
> +- clocks: a phandle to the reference clock for this block which is fed 
> through
> +  its internal variable clock frequency generator
> +
> +Example:
> +
> + pwm: pwm@f0408000 {
> + compatible = "brcm,bcm7038-pwm";
> + reg = <0xf0408000 0x28>;
> + #pwm-cells = <2>;
> + clocks = <&upg_fixed>;
> + };
> 


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

Re: [PATCH v2 4/5] ARM: multi_v7_defconfig: Add NSP to defconfig

[Florian Fainelli]

On 26/08/15 15:35, Jon Mason wrote:
> Add the Broadcom Northstar Plus SoC to the multi_v7_defconfig
> 
> Signed-off-by: Jon Mason 

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

Re: [PATCH v2 5/5] MAINTAINERS: add entry for the Broadcom Northstar Plus SoCs

[Florian Fainelli]

On 26/08/15 15:35, Jon Mason wrote:
> Modify the iProc MAINTAINER to cover the Nortstar Plus SoCs, and add me
> to the list of people responsible for it.  Since iProc is a family of
> SoCs that includes more than just Cygnus (i.e., Northstar (BCM5301X),
> Northstar Plus, Northstar 2, and a number of other platforms), remove it
> from the title to avoid any future confusion.
> 
> Signed-off-by: Jon Mason 
> Acked-by: Scott Branden 

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

Re: [PATCH v2 2/5] ARM: NSP: add minimal Northstar Plus device tree

[Florian Fainelli]

On 26/08/15 15:35, Jon Mason wrote:
> Add a very minimalistic set of Northstar Plus Device Tree files which
> describes the SoC and the BCM958625 implementation.  The perpherials
> described are:
> 
> ARM Cortex A9 CPU
> 2 8250 UARTs
> ARM GIC
> PL310 L2 Cache
> ARM A9 Global timer
> 
> Signed-off-by: Kapil Hali 
> Signed-off-by: Jon Mason 

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

Re: [PATCH v2 1/5] dt-bindings: Create Documentation for NSP DT bindings

[Florian Fainelli]

On 26/08/15 15:35, Jon Mason wrote:
> Add the documentation for the Broadcom Northstar Plus device tree
> bindings.
> 
> Signed-off-by: Jon Mason 

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

Re: [PATCH v2 3/5] ARM: NSP: Add basic support for Broadcom Northstar Plus SoC

[Florian Fainelli]

On 26/08/15 15:35, Jon Mason wrote:
> Broadcom Northstar Plus family of SoCs are used for switching
> control and management applications as well as residential
> router/gateway applications. The SoC features dual core Cortex
> A9 ARM CPUs, integrating several peripheral interfaces including
> multiple Gigabit Ethernet PHYs, DDR3 memory, PCIE Gen-2, USB 2.0
> and USB 3.0, serial and NAND flash, SATA and several other IO
> controllers.
> 
> Signed-off-by: Kapil Hali 
> Signed-off-by: Jon Mason 

Applied to soc/next at github.com/stblinux, thanks!

This is a little late for 4.3, so this will be queued for 4.4, thanks!
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial

[Stefan Agner]

This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.

Signed-off-by: Bill Pringlemeir 
Reviewed-by: Brian Norris 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf610-twr.dts | 47 +
 arch/arm/boot/dts/vfxxx.dtsi| 10 +
 2 files changed, 57 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 375ab23..64d1696 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -237,6 +237,33 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD31__NF_IO150x28df
+   VF610_PAD_PTD30__NF_IO140x28df
+   VF610_PAD_PTD29__NF_IO130x28df
+   VF610_PAD_PTD28__NF_IO120x28df
+   VF610_PAD_PTD27__NF_IO110x28df
+   VF610_PAD_PTD26__NF_IO100x28df
+   VF610_PAD_PTD25__NF_IO9 0x28df
+   VF610_PAD_PTD24__NF_IO8 0x28df
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1582
@@ -274,6 +301,26 @@
};
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc>;
+   status = "okay";
+
+   nand@0 {
+   compatible = "fsl,vf610-nfc-nandcs";
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   nand-bus-width = <16>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <24>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 4aa3351..17066a2 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -520,6 +520,16 @@
status = "disabled";
};
 
+   nfc: nand@400e {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-nfc";
+   reg = <0x400e 0x4000>;
+   interrupts = <83 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   status = "disabled";
+   };
};
};
 };
-- 
2.5.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 v11 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

[Stefan Agner]

This adds hardware ECC support using the BCH encoder in the NFC IP.
The ECC encoder supports up to 32-bit correction by using 60 error
correction bytes. There is no sub-page ECC step, ECC is calculated
always accross the whole page (up to 2k pages).

Limitations:
- HW ECC: Only 2K page with 64+ OOB.
- HW ECC: Only 24 and 32-bit error correction implemented.

Raw writes have been tested using the generic nand_write_page_raw
implementation. However, raw reads are currently not possible
because the controller need to know whether we are going to use
the ECC mode already at NAND_CMD_READ0 command time. At this point
we do not have the information whether it is a raw read or a
regular read at driver level...

Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 drivers/mtd/nand/Kconfig |   6 +-
 drivers/mtd/nand/vf610_nfc.c | 204 ++-
 2 files changed, 206 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 9f9736c..ccd1158 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -466,8 +466,10 @@ config MTD_NAND_VF610_NFC
help
  Enables support for NAND Flash Controller on some Freescale
  processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
- The driver supports a maximum 2k page size. The driver
- currently does not support hardware ECC.
+ The driver supports a maximum 2k page size. With 2k pages and
+ 64 bytes or more of OOB, hardware ECC with up to 32-bit error
+ correction is supported. Hardware ECC is only enabled through
+ device tree.
 
 config MTD_NAND_MXC
tristate "MXC NAND support"
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index eba67dc..14f51c8 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -19,8 +19,8 @@
  * - Untested on MPC5125 and M54418.
  * - DMA and pipelining not used.
  * - 2K pages or less.
- * - No chip select, one NAND chip per controller.
- * - No hardware ECC.
+ * - HW ECC: Only 2K page with 64+ OOB.
+ * - HW ECC: Only 24 and 32-bit error correction implemented.
  */
 
 #include 
@@ -77,6 +77,8 @@
 
 /* NFC ECC mode define */
 #define ECC_BYPASS 0
+#define ECC_45_BYTE6
+#define ECC_60_BYTE7
 
 /*** Register Mask and bit definitions */
 
@@ -129,6 +131,18 @@
 #define CMD_DONE_CLEAR_BIT BIT(18)
 #define IDLE_CLEAR_BIT BIT(17)
 
+/*
+ * ECC status - seems to consume 8 bytes (double word). The documented
+ * status byte is located in the lowest byte of the second word (which is
+ * the 4th or 7th byte depending on endianness).
+ * Calculate an offset to store the ECC status at the end of the buffer.
+ */
+#define ECC_SRAM_ADDR  (PAGE_2K + OOB_MAX - 8)
+
+#define ECC_STATUS 0x4
+#define ECC_STATUS_MASK0x80
+#define ECC_STATUS_ERR_COUNT   0x3F
+
 enum vf610_nfc_alt_buf {
ALT_BUF_DATA = 0,
ALT_BUF_ID = 1,
@@ -152,10 +166,40 @@ struct vf610_nfc {
enum vf610_nfc_alt_buf alt_buf;
enum vf610_nfc_variant variant;
struct clk *clk;
+   bool use_hw_ecc;
+   u32 ecc_mode;
 };
 
 #define mtd_to_nfc(_mtd) container_of(_mtd, struct vf610_nfc, mtd)
 
+static struct nand_ecclayout vf610_nfc_ecc45 = {
+   .eccbytes = 45,
+   .eccpos = {19, 20, 21, 22, 23,
+  24, 25, 26, 27, 28, 29, 30, 31,
+  32, 33, 34, 35, 36, 37, 38, 39,
+  40, 41, 42, 43, 44, 45, 46, 47,
+  48, 49, 50, 51, 52, 53, 54, 55,
+  56, 57, 58, 59, 60, 61, 62, 63},
+   .oobfree = {
+   {.offset = 2,
+.length = 17} }
+};
+
+static struct nand_ecclayout vf610_nfc_ecc60 = {
+   .eccbytes = 60,
+   .eccpos = { 4,  5,  6,  7,  8,  9, 10, 11,
+  12, 13, 14, 15, 16, 17, 18, 19,
+  20, 21, 22, 23, 24, 25, 26, 27,
+  28, 29, 30, 31, 32, 33, 34, 35,
+  36, 37, 38, 39, 40, 41, 42, 43,
+  44, 45, 46, 47, 48, 49, 50, 51,
+  52, 53, 54, 55, 56, 57, 58, 59,
+  60, 61, 62, 63 },
+   .oobfree = {
+   {.offset = 2,
+.length = 2} }
+};
+
 static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
 {
return readl(nfc->regs + reg);
@@ -298,6 +342,13 @@ static void vf610_nfc_addr_cycle(struct vf610_nfc *nfc, 
int column, int page)
ROW_ADDR_SHIFT, page);
 }
 
+static inline void vf610_nfc_ecc_mode(struct vf610_nfc *nfc, int ecc_mode)
+{
+   vf610_nfc_set_field(nfc, NFC_FLASH_CONFIG,
+   CONFIG_ECC_MODE_MASK,
+   CONFIG_ECC_MODE_SHIFT, ecc_mode);
+}
+
 static inline void vf610_nfc_transfer_size(struct vf610_nfc *nfc, int size)
 {
vf610_nf

[PATCH v11 5/5] ARM: dts: vf-colibri: enable NAND flash controller

[Stefan Agner]

Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.

Reviewed-by: Brian Norris 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri.dtsi | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index 68ca125..e5949b9 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -52,6 +52,26 @@
pinctrl-0 = <&pinctrl_i2c0>;
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc>;
+   status = "okay";
+
+   nand@0 {
+   compatible = "fsl,vf610-nfc-nandcs";
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <32>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
@@ -156,6 +176,25 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
-- 
2.5.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 v11 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

[Stefan Agner]

This driver supports Freescale NFC (NAND flash controller) found on
Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has
been tested using 8-bit and 16-bit NAND interface on the ARM based
Vybrid SoC VF500 and VF610 platform.
parameter page reading.

Limitations:
- Untested on MPC5125 and M54418.
- DMA and pipelining not used.
- 2K pages or less.
- No chip select, one NAND chip per controller.
- No hardware ECC.

Some paths have been hand-optimized and evaluated by measurements
made using mtd_speedtest.ko on a 100MB MTD partition.

Colibri VF50
eb write %   eb read %   page write  %   page read %
rel/opt 5175   115374560 11039
opt 5164 -0.21 11420 -1.01  4737 +3.88   10918 -1.10
none5113 -1.20 11352 -1.60  4490 -1.54   10865 -1.58

Colibri VF61
eb write %   eb read %   page write  %   page read %
rel/opt 5766   130965459 12846
opt 5883 +2.03 13064 -0.24  5561 +1.87   12802 -0.34
none5701 -1.13 12980 -0.89  5488 +0.53   12735 -0.86

rel = using readl_relaxed/writel_relaxed in optimized paths
opt = hand-optimized by combining multiple accesses into one read/write

The measurements have not been statistically verfied, hence use them
with care. The author came to the conclusion that using the relaxed
variants of readl/writel are not worth the additional code.

Signed-off-by: Bill Pringlemeir 
Tested-by: Albert ARIBAUD 
Signed-off-by: Stefan Agner 
---
 MAINTAINERS  |   6 +
 drivers/mtd/nand/Kconfig |   9 +
 drivers/mtd/nand/Makefile|   1 +
 drivers/mtd/nand/vf610_nfc.c | 690 +++
 4 files changed, 706 insertions(+)
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9567329..59975c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10835,6 +10835,12 @@ S: Maintained
 F: Documentation/fb/uvesafb.txt
 F: drivers/video/fbdev/uvesafb.*
 
+VF610 NAND DRIVER
+M: Stefan Agner 
+L: linux-...@lists.infradead.org
+S: Supported
+F: drivers/mtd/nand/vf610_nfc.c
+
 VFAT/FAT/MSDOS FILESYSTEM
 M: OGAWA Hirofumi 
 S: Maintained
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 3324281..9f9736c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -460,6 +460,15 @@ config MTD_NAND_MPC5121_NFC
  This enables the driver for the NAND flash controller on the
  MPC5121 SoC.
 
+config MTD_NAND_VF610_NFC
+   tristate "Support for Freescale NFC for VF610/MPC5125"
+   depends on (SOC_VF610 || COMPILE_TEST)
+   help
+ Enables support for NAND Flash Controller on some Freescale
+ processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
+ The driver supports a maximum 2k page size. The driver
+ currently does not support hardware ECC.
+
 config MTD_NAND_MXC
tristate "MXC NAND support"
depends on ARCH_MXC
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 1f897ec..a490af8 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_MTD_NAND_SOCRATES)   += 
socrates_nand.o
 obj-$(CONFIG_MTD_NAND_TXX9NDFMC)   += txx9ndfmc.o
 obj-$(CONFIG_MTD_NAND_NUC900)  += nuc900_nand.o
 obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o
+obj-$(CONFIG_MTD_NAND_VF610_NFC)   += vf610_nfc.o
 obj-$(CONFIG_MTD_NAND_RICOH)   += r852.o
 obj-$(CONFIG_MTD_NAND_JZ4740)  += jz4740_nand.o
 obj-$(CONFIG_MTD_NAND_GPMI_NAND)   += gpmi-nand/
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
new file mode 100644
index 000..eba67dc
--- /dev/null
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -0,0 +1,690 @@
+/*
+ * Copyright 2009-2015 Freescale Semiconductor, Inc. and others
+ *
+ * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver.
+ * Jason ported to M54418TWR and MVFA5 (VF610).
+ * Authors: Stefan Agner 
+ *  Bill Pringlemeir 
+ *  Shaohui Xie 
+ *  Jason Jin 
+ *
+ * Based on original driver mpc5121_nfc.c.
+ *
+ * This 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.
+ *
+ * Limitations:
+ * - Untested on MPC5125 and M54418.
+ * - DMA and pipelining not used.
+ * - 2K pages or less.
+ * - No chip select, one NAND chip per controller.
+ * - No hardware ECC.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#defineDRV_NAME"vf610_nfc"
+
+/* Register Offsets */
+#define NFC_FLASH_CMD1  

[PATCH v11 3/5] mtd: nand: vf610_nfc: add device tree bindings

[Stefan Agner]

Signed-off-by: Bill Pringlemeir 
Acked-by: Shawn Guo 
Signed-off-by: Stefan Agner 
---
 .../devicetree/bindings/mtd/vf610-nfc.txt  | 59 ++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt

diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt 
b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
new file mode 100644
index 000..6be4871
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
@@ -0,0 +1,59 @@
+Freescale's NAND flash controller (NFC)
+
+This variant of the Freescale NAND flash controller (NFC) can be found on
+Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc".
+- reg: address range of the NFC.
+- interrupts: interrupt of the NFC.
+- #address-cells: shall be set to 1. Encode the nand CS.
+- #size-cells : shall be set to 0.
+- assigned-clocks: main clock from the SoC, for Vybrid <&clks VF610_CLK_NFC>;
+- assigned-clock-rates: The NAND bus timing is derived from this clock
+rate and should not exceed maximum timing for any NAND memory chip
+in a board stuffing. Typical NAND memory timings derived from this
+clock are found in the SoC hardware reference manual. Furthermore,
+there might be restrictions on maximum rates when using hardware ECC.
+
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+  representing partitions.
+
+Required children nodes:
+Children nodes represent the available nand chips. Currently the driver can
+only handle one NAND chip.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc-cs".
+- nand-bus-width: see nand.txt
+- nand-ecc-mode: see nand.txt
+
+Required properties for hardware ECC:
+- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt)
+- nand-ecc-step-size: step size equals page size, currently only 2k pages are
+supported
+- nand-on-flash-bbt: see nand.txt
+
+Example:
+
+   nfc: nand@400e {
+   compatible = "fsl,vf610-nfc";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x400e 0x4000>;
+   interrupts = ;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+
+   nand@0 {
+   compatible = "fsl,vf610-nfc-nandcs";
+   reg = <0>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <32>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
+   };
-- 
2.5.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 v11 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610

[Stefan Agner]

In this 11th revision the driver now rereads the OOB area in case
hardware ECC fails. This allows to count the flipped bits accross
the whole page reliably. Also the device tree bindings have been
updated: NAND chips can be specified using sub-nodes, the ECC
properties are part of those chip nodes. Note however that the
driver currently only supports one NAND chip. The driver has been
verified again using the MTD tests.

More information and the full test log of earlier patchset version
can be found in the cover letter of the last revision v6:
http://thread.gmane.org/gmane.linux.kernel/1979868

Changes since v10:
- Rebased onto l2-mtd/master
- Use children nodes for NAND chips in device tree bindings
- Support exactly one NAND chip using the new device tree bindings
- Reread page OOB on ECC error in order to reliable determine the amount
  of bit flips on a erased page
- Use ECC strength/2 as the only bit flip threshold
- Rely on endianness aware word read to read the ECC status
- Introduce vf610_nfc_variant which reflects the variant according to
  the device tree compatible string
- Use variant to determine chip select implementation
- Use enum for alternate buffer indication
- Renamed page_sz variable in struct vf610_nfc as well as in the function
  vf610_nfc_command to more specific names
- Some smaller code cleanup (altered ECC_SRAM_ADDR, introduce OOB_MAX)

Changes since v9:
- Remove inline of vf610_nfc_done
- Add __iomem to src argument of vf610_nfc_memcpy
- Handle return value of mtd_device_parse_register correctly
- Count bits in OOB too (only non-ECC bits)
- Return bitflips in ecc.read_page callback vf610_nfc_read_page
- Fall-through ALT_BUF_ONFI
- Use BIT macros

Changes since v8:
- Fix 16-Bit NAND flash support by splitting up initialization
  (introduce vf610_nfc_preinit_controller)
- Updated comments in initialziation functions

Changes since v7:
- vf610-twr.dts: Moved NFC pinmux into the existing iomuxc node
  and sort new nfc node behind the existing iomuxc node as well.
- vf610-twr.dts/vf-colibri.dtsi: Dropped _1 suffixes

Changes since v6:
- Rebased ontop of l2-mtd/master (v4.2-rc1 based)
- Removed HAVE_NAND_VF610_NFC and use depends on. This made
  "[PATCH v6 4/6] ARM: vf610: enable NAND Flash Controller" unnecessary

Changes since v5:
- Removed fsl,mpc5125-nfc compatible string
- Removed readl/writel_relaxed
- Change interface of vf610_nfc_transfer_size to match other accessors

Changes since v4:
- Rebased ontop of l2-mtd/master (v4.1-rc4 based)
- Eliminate unnecessary page read (NAND_CMD_SEQIN) since the driver does
  not support sub-page writes anyway (improves write performance)
- Support ONFI by enabling READID command with offset and parameter page
  reads (CMD_PARAM)
- Change to dedicated read_page/write_page function, enables raw writes
- Use __LITTLE_ENDIAN to distingush between LE/BE relevant statements
- Eliminated vf610_nfc_probe_dt in favor of common DT init code
- Use wait_for_completion_timeout
- Some style fixes (spaces, etc.)

Changes since v3:
- Make the driver selectable when COMPILE_TEST is set
- Fix compile error due to superfluous ECC_STATUS configuration in initial
  patch (without ECC correction ECC_STATUS does not need to be configured)
- Remove custom BBT pattern and switch to in-band BBT in the initial patch
- Include two bug fixes, for details see the corresponding U-Boot patches:
  http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/215802

Changes since v2:
- Updated binding documentation

Changes since v1:
- Nest nfc_config struct within the main nfc struct
- Use assigned clock binding to specify NFC clock
- Rebased ontop of MSCM IR patchset (driver parts have been merged)
- Split out arch Kconfig in a separate config
- Fix module license
- Updated MAINTAINERS

Changes since RFC (Bill Pringlemeir):
- Renamed driver from fsl_nfc to vf610_nfc
- Use readl/writel for all register in accessor functions
- Optimized field accessor functions
- Implemented PM (suspend/resume) functions
- Implemented basic support for ECC strength/ECC step size from dt
- Improved performance of count_written_bits by using hweight32
- Support ECC with 60-bytes to correct up to 32 bit errors
- Changed to in-band BBT (NAND_BBT_NO_OOB) which also allows ECC modes
  which uses up to 60 bytes on 64 byte OOB
- Removed custom (downstream) BBT pattern since BBT table won't be
  compatible anyway (due to the change above)

mtd_speedtest of this 11th revision on a Colibri VF61:

[ 2321.921612] =
[ 2321.927459] mtd_speedtest: MTD device: 3
[ 2321.936619] mtd_speedtest: MTD device size 104857600, eraseblock size 
131072, page size 2048, count of eraseblocks 800, pages per eraseblock 64, OOB 
size 64
[ 2321.954428] mtd_test: scanning for bad eraseblocks
[ 2321.959626] mtd_test: block 142 is bad
[ 2321.966038] mtd_test: scanned 800 eraseblocks, 1 are bad
[ 2322.370120] mtd_speedtest: testing eraseblock write speed
[ 2344.047677] mtd_speedtest: eras

Re: [RESEND PATCH v16 4/4] ARM: dts: add the support power-domain node on RK3288 SoCs

[Kevin Hilman]

Dmitry Torokhov  writes:

> On Tue, Aug 25, 2015 at 3:45 PM, Kevin Hilman  wrote:
>> Doug Anderson  writes:
>>
>>> To put things in a
>>> concrete way, for pd_vio we'd go through the entire device tree
>>> ourselves and find all properties that look like "power-domains =
>>> <&power RK3288_PD_VIO>;".  We'd then find the parent of those
>>> properties and look for a property named "clocks".  We'd then iterate
>>> over all those clocks and turn those on.  Did I get that right?
>>
>> ... but you make it sound like more work than it is.  The genpd already
>> keeps a list of devices that refer to the power domain.  In fact, the
>> genpd 'attach' method can be platform-specific, so could be used to keep
>> track of a list (or a subset) of clocks which are needed for reset.
>
> That is not really workable: the attach and detach happen in
> probe/remove path; if you do not have driver for the device you will
> miss the clocks for it. 

And in my proposal, I suggested that clocks without drivers are
good candidates to list in the domain, with the caveat that the be
called out (documented) as being device clocks that are missing a
driver, so when a driver shows up they can be moved accordingly, and in
a way that actually describes the hardware.

> And the quirk of this SoC is that we need to
> turn all clocks during domain transition, regardless of whether there
> is a driver for all devices.

I understand.  And that "quirk" is not unique to rockchip socs.

Kevin




--
To unsubscribe from this list: send the line "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/4] PCI: st: Add Device Tree bindings for sti pcie

[Rob Herring]

On Thu, Aug 27, 2015 at 7:34 AM, Gabriel Fernandez
 wrote:
> sti pcie is built around a Synopsis Designware PCIe IP.
>
> Signed-off-by: Fabrice Gasnier 
> Signed-off-by: Gabriel Fernandez 
> ---
>  Documentation/devicetree/bindings/pci/st-pcie.txt | 53 
> +++
>  1 file changed, 53 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/st-pcie.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/st-pcie.txt 
> b/Documentation/devicetree/bindings/pci/st-pcie.txt
> new file mode 100644
> index 000..25fcab3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/st-pcie.txt
> @@ -0,0 +1,53 @@
> +STMicroelectronics STi PCIe controller
> +
> +This PCIe host controller is based on the Synopsis Designware PCIe IP
> +and thus inherits all the common properties defined in designware-pcie.txt.
> +
> +Required properties:
> + - compatible: "st,stih407-pcie"

What about "snps,dw-pcie" as well?

> + - reg: base address and length of the pcie controller, mem-window address
> +   and length available to the controller.

What is mem-window? Seems rather large and perhaps should be under ranges.

> + - interrupts: A list of interrupt outputs of the controller. Must contain an
> +   entry for each entry in the interrupt-names property.

Define how many interrupts.

> + - interrupt-names: Should be "msi". STi interrupt that is asserted when an
> +   MSI is received.

Kind of pointless with a single interrupt.

> + - st,syscfg : should be a phandle of the syscfg node. Also contains syscfg
> +   offset for IP configuration.
> + - resets, reset-names: the power-down and soft-reset lines of PCIe IP.
> +   Associated names must be "powerdown" and "softreset".
> + - phys, phy-names: the phandle for the PHY device.
> +   Associated name must be "pcie"

What does this mean?

> +
> +Optional properties:
> + - reset-gpio: a GPIO spec to define which pin is connected to the bus reset.
> +
> +Example:
> +
> +pcie0: pcie@9b0 {
> +   compatible = "st,pcie", "snps,dw-pcie";
> +   device_type = "pci";
> +   reg = <0x09b0 0x4000>,  /* dbi cntrl registers */
> + <0x2fff 0x0001>,  /* configuration space */
> + <0x4000 0x8000>;  /* lmi mem window */
> +   reg-names = "dbi", "config", "mem-window";
> +   st,syscfg = <&syscfg_core 0xd8 0xe0>;
> +   #address-cells = <3>;
> +   #size-cells = <2>;
> +   ranges = <0x8200 0 0x2000 0x2000 0 0x0FFF>; /* 
> non-prefetchable memory */

No i/o support?

> +   num-lanes = <1>;
> +   interrupts = ;
> +   interrupt-names = "msi";
> +   #interrupt-cells = <1>;
> +   interrupt-map-mask = <0 0 0 7>;
> +   interrupt-map = <0 0 0 1 &intc GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>, /* 
> INT A */
> +   <0 0 0 2 &intc GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>, /* 
> INT B */
> +   <0 0 0 3 &intc GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>, /* 
> INT C */
> +   <0 0 0 4 &intc GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>; /* 
> INT D */
> +
> +   resets = <&powerdown STIH407_PCIE0_POWERDOWN>,
> +<&softreset STIH407_PCIE0_SOFTRESET>;
> +   reset-names = "powerdown",
> + "softreset";
> +   phys = <&phy_port0 PHY_TYPE_PCIE>;
> +   phy-names = "pcie";
> +};
> --
> 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 v2 0/5] Add Broadcom Northstar Plus Support

[Scott Branden]

Patchset all look good.
Acked-by: Scott Branden 

On 15-08-26 03:35 PM, Jon Mason wrote:


Changes in version 2 incorporate Olof's comments regarding:
* the removal of all "Reviewed-by" lines not occurring on external
   mailing lists
* reordering of s-o-b lines
* modification of the device tree file to use labels when enabling
* increated description of the modification to the MAINTAINERS entry

Also, modifying the "to" and "cc" recepients so that everyone is
receving all of the patches.

--

This patch series adds support for the Broadcom Northstar Plus family of
SoCs.  NSP is a Cortex A9 based SoC under the Broadcom iProc family.

Jon Mason (5):
   dt-bindings: Create Documentation for NSP DT bindings
   ARM: NSP: add minimal Northstar Plus device tree
   ARM: NSP: Add basic support for Broadcom Northstar Plus SoC
   ARM: multi_v7_defconfig: Add NSP to defconfig
   MAINTAINERS: add entry for the Broadcom Northstar Plus SoCs

  .../devicetree/bindings/arm/bcm/brcm,nsp.txt   |  34 +++
  MAINTAINERS|  12 ++-
  arch/arm/boot/dts/Makefile |   2 +
  arch/arm/boot/dts/bcm-nsp.dtsi | 105 +
  arch/arm/boot/dts/bcm958625k.dts   |  57 +++
  arch/arm/configs/multi_v7_defconfig|   1 +
  arch/arm/mach-bcm/Kconfig  |  14 +++
  arch/arm/mach-bcm/Makefile |   5 +-
  arch/arm/mach-bcm/bcm_nsp.c|  25 +
  9 files changed, 252 insertions(+), 3 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt
  create mode 100644 arch/arm/boot/dts/bcm-nsp.dtsi
  create mode 100644 arch/arm/boot/dts/bcm958625k.dts
  create mode 100644 arch/arm/mach-bcm/bcm_nsp.c



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

Re: [PATCH v2 2/2] watchdog: Watchdog driver for Broadcom Set-Top Box

[Gregory Fong]

Gah, sorry, my email client did something really weird.  Sorry for the
duplication, please don't reply to those.

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

[PATCH v2 1/2] watchdog: bcm7038: add device tree binding documentation

[Gregory Fong]

Add device tree binding documentation for the watchdog hardware block
on bcm7038 and newer SoCs.

Signed-off-by: Justin Chen 
---
 .../devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt

diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
new file mode 100644
index 000..39e5cf5
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
@@ -0,0 +1,19 @@
+BCM7038 Watchdog timer
+
+Required properties:
+
+- compatible : should be "brcm,bcm7038-wdt"
+- reg : Specifies base physical address and size of the registers.
+
+Optional properties:
+
+- clocks: The clock running the watchdog. If no clock is found the
+ driver will default to 2700 HZ.
+
+Example:
+
+watchdog {
+   compatible = "brcm,bcm7038-wdt";
+   clocks = <&upg_fixed>;
+   reg = <0xf040a7e8 0x16>;
+};
-- 
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] watchdog: Watchdog driver for Broadcom Set-Top Box

[Gregory Fong]

Watchdog driver for Broadcom 7038 and newer chips.

Signed-off-by: Justin Chen 
---
 drivers/watchdog/Kconfig   |   8 ++
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/bcm7038_wdt.c | 235 +
 3 files changed, 244 insertions(+)
 create mode 100644 drivers/watchdog/bcm7038_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 241fafd..4fbe8ab 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1291,6 +1291,14 @@ config BCM_KONA_WDT_DEBUG
 
  If in doubt, say 'N'.
 
+config BCM7038_WDT
+   tristate "BCM7038 Watchdog"
+   select WATCHDOG_CORE
+   help
+Watchdog driver for the built-in hardware in Broadcom 7038 SoCs.
+
+Say 'Y or 'M' here to enable the driver.
+
 config IMGPDC_WDT
tristate "Imagination Technologies PDC Watchdog Timer"
depends on HAS_IOMEM
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 59ea9a1..65d4169 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
 obj-$(CONFIG_MESON_WATCHDOG) += meson_wdt.o
 obj-$(CONFIG_MEDIATEK_WATCHDOG) += mtk_wdt.o
 obj-$(CONFIG_DIGICOLOR_WATCHDOG) += digicolor_wdt.o
+obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
 
 # AVR32 Architecture
 obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/bcm7038_wdt.c b/drivers/watchdog/bcm7038_wdt.c
new file mode 100644
index 000..5e54c1b
--- /dev/null
+++ b/drivers/watchdog/bcm7038_wdt.c
@@ -0,0 +1,235 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WDT_START_10xff00
+#define WDT_START_20x00ff
+#define WDT_STOP_1 0xee00
+#define WDT_STOP_2 0x00ee
+
+#define WDT_TIMEOUT_REG0x0
+#define WDT_CMD_REG0x4
+
+#define WDT_MIN_TIMEOUT1 /* seconds */
+#define WDT_DEFAULT_TIMEOUT30 /* seconds */
+#define WDT_DEFAULT_RATE   2700
+
+struct bcm7038_watchdog {
+   void __iomem*base;
+   struct watchdog_device  wdd;
+   u32 rate;
+   struct clk  *clk;
+};
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+
+static void bcm7038_wdt_set_timeout_reg(struct watchdog_device *wdog)
+{
+   struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+   u32 timeout;
+
+   timeout = wdt->rate * wdog->timeout;
+
+   writel(timeout, wdt->base + WDT_TIMEOUT_REG);
+}
+
+static int bcm7038_wdt_ping(struct watchdog_device *wdog)
+{
+   struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+
+   writel(WDT_START_1, wdt->base + WDT_CMD_REG);
+   writel(WDT_START_2, wdt->base + WDT_CMD_REG);
+
+   return 0;
+}
+
+static int bcm7038_wdt_start(struct watchdog_device *wdog)
+{
+   bcm7038_wdt_set_timeout_reg(wdog);
+   bcm7038_wdt_ping(wdog);
+
+   return 0;
+}
+
+static int bcm7038_wdt_stop(struct watchdog_device *wdog)
+{
+   struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+
+   writel(WDT_STOP_1, wdt->base + WDT_CMD_REG);
+   writel(WDT_STOP_2, wdt->base + WDT_CMD_REG);
+
+   return 0;
+}
+
+static int bcm7038_wdt_set_timeout(struct watchdog_device *wdog,
+  unsigned int t)
+{
+   /* Can't modify timeout value if watchdog timer is running */
+   bcm7038_wdt_stop(wdog);
+   wdog->timeout = t;
+   bcm7038_wdt_start(wdog);
+
+   return 0;
+}
+
+static unsigned int bcm7038_wdt_get_timeleft(struct watchdog_device *wdog)
+{
+   struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+   u32 time_left;
+
+   time_left = readl(wdt->base + WDT_CMD_REG);
+
+   return time_left / wdt->rate;
+}
+
+static struct watchdog_info bcm7038_wdt_info = {
+   .identity   = "Broadcom BCM7038 Watchdog Timer",
+   .options= WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+   WDIOF_MAGICCLOSE
+};
+
+static struct watchdog_ops bcm7038_wdt_ops = {
+   .owner  = THIS_MODULE,
+   .start  = bcm7038_wdt_start,
+   .stop   = bcm7038_wdt_stop,
+   .set_timeout= bcm7038_wdt_set_timeout,
+   .get_timeleft   = bcm7038_wdt_get_timeleft,
+};
+
+static int bcm7038_wdt_probe(struct platform_device *pdev)
+{
+   struct devic

[PATCH v2 0/2] watchdog: driver for BCM7038 and newer chips.

[Gregory Fong]

This driver is for a watchdog block contained in all Broadcom Set-top
Box chips since BCM7038. BCM7038 was made public during the 2004 CES,
and since then, many chips use this watchdog block including some cable
modem chips.

Changes since v1:
Removed clock-frequency because it brought unnecessary complexity to the
driver.
Renamed a few variables.

Patch 1: watchdog device tree binding documentation

Patch 2: watchdog driver

Justin Chen (2):
  watchdog: bcm7038: add device tree binding documentation
  watchdog: Watchdog driver for Broadcom Set-Top Box

 .../bindings/watchdog/brcm,bcm7038-wdt.txt |  19 ++
 drivers/watchdog/Kconfig   |   8 +
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/bcm7038_wdt.c | 235 +
 4 files changed, 263 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
 create mode 100644 drivers/watchdog/bcm7038_wdt.c

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

[PATCH v2 2/2] watchdog: Watchdog driver for Broadcom Set-Top Box

[Justin Chen]

Watchdog driver for Broadcom 7038 and newer chips.

Signed-off-by: Justin Chen 
---
 drivers/watchdog/Kconfig   |   8 ++
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/bcm7038_wdt.c | 235 +
 3 files changed, 244 insertions(+)
 create mode 100644 drivers/watchdog/bcm7038_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 241fafd..4fbe8ab 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1291,6 +1291,14 @@ config BCM_KONA_WDT_DEBUG
 
  If in doubt, say 'N'.
 
+config BCM7038_WDT
+   tristate "BCM7038 Watchdog"
+   select WATCHDOG_CORE
+   help
+Watchdog driver for the built-in hardware in Broadcom 7038 SoCs.
+
+Say 'Y or 'M' here to enable the driver.
+
 config IMGPDC_WDT
tristate "Imagination Technologies PDC Watchdog Timer"
depends on HAS_IOMEM
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 59ea9a1..65d4169 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
 obj-$(CONFIG_MESON_WATCHDOG) += meson_wdt.o
 obj-$(CONFIG_MEDIATEK_WATCHDOG) += mtk_wdt.o
 obj-$(CONFIG_DIGICOLOR_WATCHDOG) += digicolor_wdt.o
+obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
 
 # AVR32 Architecture
 obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/bcm7038_wdt.c b/drivers/watchdog/bcm7038_wdt.c
new file mode 100644
index 000..5e54c1b
--- /dev/null
+++ b/drivers/watchdog/bcm7038_wdt.c
@@ -0,0 +1,235 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WDT_START_10xff00
+#define WDT_START_20x00ff
+#define WDT_STOP_1 0xee00
+#define WDT_STOP_2 0x00ee
+
+#define WDT_TIMEOUT_REG0x0
+#define WDT_CMD_REG0x4
+
+#define WDT_MIN_TIMEOUT1 /* seconds */
+#define WDT_DEFAULT_TIMEOUT30 /* seconds */
+#define WDT_DEFAULT_RATE   2700
+
+struct bcm7038_watchdog {
+   void __iomem*base;
+   struct watchdog_device  wdd;
+   u32 rate;
+   struct clk  *clk;
+};
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+
+static void bcm7038_wdt_set_timeout_reg(struct watchdog_device *wdog)
+{
+   struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+   u32 timeout;
+
+   timeout = wdt->rate * wdog->timeout;
+
+   writel(timeout, wdt->base + WDT_TIMEOUT_REG);
+}
+
+static int bcm7038_wdt_ping(struct watchdog_device *wdog)
+{
+   struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+
+   writel(WDT_START_1, wdt->base + WDT_CMD_REG);
+   writel(WDT_START_2, wdt->base + WDT_CMD_REG);
+
+   return 0;
+}
+
+static int bcm7038_wdt_start(struct watchdog_device *wdog)
+{
+   bcm7038_wdt_set_timeout_reg(wdog);
+   bcm7038_wdt_ping(wdog);
+
+   return 0;
+}
+
+static int bcm7038_wdt_stop(struct watchdog_device *wdog)
+{
+   struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+
+   writel(WDT_STOP_1, wdt->base + WDT_CMD_REG);
+   writel(WDT_STOP_2, wdt->base + WDT_CMD_REG);
+
+   return 0;
+}
+
+static int bcm7038_wdt_set_timeout(struct watchdog_device *wdog,
+  unsigned int t)
+{
+   /* Can't modify timeout value if watchdog timer is running */
+   bcm7038_wdt_stop(wdog);
+   wdog->timeout = t;
+   bcm7038_wdt_start(wdog);
+
+   return 0;
+}
+
+static unsigned int bcm7038_wdt_get_timeleft(struct watchdog_device *wdog)
+{
+   struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+   u32 time_left;
+
+   time_left = readl(wdt->base + WDT_CMD_REG);
+
+   return time_left / wdt->rate;
+}
+
+static struct watchdog_info bcm7038_wdt_info = {
+   .identity   = "Broadcom BCM7038 Watchdog Timer",
+   .options= WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+   WDIOF_MAGICCLOSE
+};
+
+static struct watchdog_ops bcm7038_wdt_ops = {
+   .owner  = THIS_MODULE,
+   .start  = bcm7038_wdt_start,
+   .stop   = bcm7038_wdt_stop,
+   .set_timeout= bcm7038_wdt_set_timeout,
+   .get_timeleft   = bcm7038_wdt_get_timeleft,
+};
+
+static int bcm7038_wdt_probe(struct platform_device *pdev)
+{
+   struct devic

[PATCH v2 1/2] watchdog: bcm7038: add device tree binding documentation

[Justin Chen]

Add device tree binding documentation for the watchdog hardware block
on bcm7038 and newer SoCs.

Signed-off-by: Justin Chen 
---
 .../devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt

diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
new file mode 100644
index 000..39e5cf5
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
@@ -0,0 +1,19 @@
+BCM7038 Watchdog timer
+
+Required properties:
+
+- compatible : should be "brcm,bcm7038-wdt"
+- reg : Specifies base physical address and size of the registers.
+
+Optional properties:
+
+- clocks: The clock running the watchdog. If no clock is found the
+ driver will default to 2700 HZ.
+
+Example:
+
+watchdog {
+   compatible = "brcm,bcm7038-wdt";
+   clocks = <&upg_fixed>;
+   reg = <0xf040a7e8 0x16>;
+};
-- 
2.1.0

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

[PATCH v2 0/2] watchdog: driver for BCM7038 and newer chips.

[Justin Chen]

This driver is for a watchdog block contained in all Broadcom Set-top
Box chips since BCM7038. BCM7038 was made public during the 2004 CES,
and since then, many chips use this watchdog block including some cable
modem chips.

Changes since v1:
Removed clock-frequency because it brought unnecessary complexity to the
driver.
Renamed a few variables.

Patch 1: watchdog device tree binding documentation

Patch 2: watchdog driver

Justin Chen (2):
  watchdog: bcm7038: add device tree binding documentation
  watchdog: Watchdog driver for Broadcom Set-Top Box

 .../bindings/watchdog/brcm,bcm7038-wdt.txt |  19 ++
 drivers/watchdog/Kconfig   |   8 +
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/bcm7038_wdt.c | 235 +
 4 files changed, 263 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
 create mode 100644 drivers/watchdog/bcm7038_wdt.c

-- 
2.1.0

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

Re: [PATCH v3] ARM: dts: rockchip: add veyron-jaq board

[Doug Anderson]

Brian,

On Mon, Aug 24, 2015 at 3:58 PM, Brian Norris  wrote:
> a.k.a. Haier Chromebook 11, and others
>
> Signed-off-by: Brian Norris 
> Cc: Alexandru M Stan 
> Cc: Douglas Anderson 
> Reviewed-by: Javier Martinez Canillas 
> ---
> v2 -> v3:
>  - add "and others" language
>  - drop other patches from series (picked up already by Heiko)
>
> v1 -> v2:
>  - add overlooked DT binding doc
>  - fixup regulator suspend state for LDO_REG2
>
>
>  Documentation/devicetree/bindings/arm/rockchip.txt |   7 +
>  arch/arm/boot/dts/Makefile |   1 +
>  arch/arm/boot/dts/rk3288-veyron-jaq.dts| 176 
> +
>  3 files changed, 184 insertions(+)

Reviewed-by: Douglas 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 2/2] ARM: dts: rockchip: correct regulator PM properties

[Brian Norris]

On Thu, Aug 27, 2015 at 10:51:22PM +0200, Heiko Stuebner wrote:
> Am Donnerstag, 27. August 2015, 12:30:51 schrieb Doug Anderson:
> > If I understand correctly, the distinction between "standby" and "mem"
> > is not too clearly defined, so if we wanted to use it for this it
> > wouldn't be terrible?

I never understood many clear definitions here either, personally.

> From reading Documentation/power/states.txt it looks like the boot-cpu is 
> supposed to retain power in the suspend state. Although we also do not lose 
> "operating state" in our suspend I guess?
> 
> So using the shallow suspend as standby sounds interesting, for the time when 
> the deep suspend works too. If there is only one suspend state it 
> automatically becomes the "mem"-state it seems.

It's not really "automatic", it's a product of this line:

static const struct platform_suspend_ops rk3288_suspend_ops = {
.enter   = rk3288_suspend_enter,
.valid   = suspend_valid_only_mem,  <--- here
.prepare = rk3288_suspend_prepare,
.finish  = rk3288_suspend_finish,
};

and the fact that we don't check the 'state' argument in
.enter/.prepare/.finish.

But still, I'm not sure it's productive to rename shallow until we support
deep.

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

Re: [PATCH 2/2] ARM: dts: rockchip: correct regulator PM properties

[Heiko Stuebner]

Am Donnerstag, 27. August 2015, 12:30:51 schrieb Doug Anderson:
> Hi,
> 
> On Tue, Aug 18, 2015 at 11:19 PM, Heiko Stuebner  wrote:
> > great, just take into account the deep vs. shallow suspend modes :-)
> 
> One note: do you think it would make sense to re-implement shallow
> suspend as "standby"?  I had a proof of concept doing that in
> .  One nice
> advantage is that you "magically" get a second set of regulator states
> for standby vs "mem".

Somewhere I've read something about keeping wifi associated to an ap during 
suspend which might be a candidate for such a distinction?


> If I understand correctly, the distinction between "standby" and "mem"
> is not too clearly defined, so if we wanted to use it for this it
> wouldn't be terrible?

>From reading Documentation/power/states.txt it looks like the boot-cpu is 
supposed to retain power in the suspend state. Although we also do not lose 
"operating state" in our suspend I guess?

So using the shallow suspend as standby sounds interesting, for the time when 
the deep suspend works too. If there is only one suspend state it 
automatically becomes the "mem"-state it seems.


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

Re: [RFC PATCH] arm/arm64: build all dtbs for CONPILE_TEST

[Geert Uytterhoeven]

Hi Rob,

On Thu, Aug 27, 2015 at 9:07 PM, Rob Herring  wrote:
>> It would be useful to build all files, but it's not the behavior that
>> COMPILE_TEST usually has.
>
> Just changing to dtb-n would be equivalent because there is no other
> dependency to enable building. Code has other dependencies typically.
> What dtb do we not want to built in an allyesconfig build? If dtb's
> have any dependencies, that would be a bug. To really make this
> equivalent to a driver using COMPILE_TEST, we would need kconfig
> symbols specifically for each platform's dtbs. Then we would have the
> 2 stage unhide (setting COMPILE_TEST) then enable the option.
>
> I was also thinking that perhaps we don't want to require a kconfig
> symbol for every platform family. Adding a kconfig entry is the only
> way to enable building a dtb ATM. I know there are 2 camps to this
> policy though.

I think it would be good to have a single Kconfig option (depending on
COMPILE_TEST) to build all dtbs.

For drivers, COMPILE_TEST doesn't enable anything by itself, it just
relaxes dependencies. Hence if any driver is broken, I can still
disable that driver in the .config.

If any dtb is broken, I cannot disable it, except by disabling COMPILE_TEST,
which I may not want to do for other reasons (e.g. I'm compile testing my
driver). If there would be an extra Kconfig symbol for building all dtbs,
I can still disable it.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH V8 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.

[vikas]

Hi,

On 08/27/2015 11:12 AM, Marek Vasut wrote:
> On Thursday, August 27, 2015 at 07:44:34 PM, vikas wrote:
>> Hi,
>>
>> On 08/21/2015 02:20 AM, Marek Vasut wrote:
>>> From: Graham Moore 
>>>
>>> Add binding document for the Cadence QSPI controller.
>>>
>>> Signed-off-by: Graham Moore 
>>> Signed-off-by: Marek Vasut 
>>> Cc: Alan Tull 
>>> Cc: Brian Norris 
>>> Cc: David Woodhouse 
>>> Cc: Dinh Nguyen 
>>> Cc: Graham Moore 
>>> Cc: Vikas MANOCHA 
>>> Cc: Yves Vandervennet 
>>> Cc: devicetree@vger.kernel.org
>>> ---
>>>
>>>  .../devicetree/bindings/mtd/cadence-quadspi.txt| 56
>>>  ++ 1 file changed, 56 insertions(+)
>>>  create mode 100644
>>>  Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
>>>
>>> V2: Add cdns prefix to driver-specific bindings.
>>> V3: Use existing property "is-decoded-cs" instead of creating a
>>>
>>> duplicate, "ext-decoder". Timing parameters are in nanoseconds,
>>> not master reference clocks. Remove bus-num completely.
>>>
>>> V4: Add new properties fifo-width and trigger-address
>>> V7: - Prefix all of the Cadence-specific properties with cdns prefix,
>>>
>>>   those are in particular "cdns,is-decoded-cs", "cdns,fifo-depth",
>>>   "cdns,fifo-width", "cdns,trigger-address".
>>> 
>>> - Drop bogus properties which were not used and were incorrect.
>>>
>>> V8: Align lines to 80 chars.
>>>
>>> diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
>>> b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt new file
>>> mode 100644
>>> index 000..f248056
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
>>> @@ -0,0 +1,56 @@
>>> +* Cadence Quad SPI controller
>>> +
>>> +Required properties:
>>> +- compatible : Should be "cdns,qspi-nor".
>>> +- reg : Contains two entries, each of which is a tuple consisting of a
>>> +   physical address and length. The first entry is the address and
>>> +   length of the controller register set. The second entry is the
>>> +   address and length of the QSPI Controller data area.
>>
>> still hooked up with  "Controller data area", it is ambiguous.
>> Use something which is more clear: Nor Flash memory mapped address.
> 
> I have to disagree, I will call it whatever it is called in the datasheet
> and it is called "controller data area".

It is preferable to use terminology which readers understand & that is the 
purpose
of explaining it here otherwise we could have just pasted the doc link.
I have to stop here for this point.

> 
>>> +- interrupts : Unit interrupt specifier for the controller interrupt.
>>> +- clocks : phandle to the Quad SPI clock.
>>> +- cdns,fifo-depth : Size of the data FIFO in words.
>>> +- cdns,fifo-width : Bus width of the data FIFO in bytes.
>>> +- cdns,trigger-address : 32-bit indirect AHB trigger address.
>>> +
>>
>>> +Optional properties:
>> again, is it optional ? can the driver be used without these properties ?
> 
> Why wouldn't it be possible to use the driver with no SPI NOR attached to
> it? It's a cornercase, but still a valid one.

that's not right, this controller is only spi flash controller.

> 
>>> +- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
>>
>> again, add info what the decoder is for ?
> 
> This is something Graham has to clarify. Based on the code (I'm sure you did
> check the code), it's a 4:16 demuxer.

Please clarify if possible & add the info for others benefit. This part is not 
common in other spi/nor controllers.

> 
>>> +
>>> +Optional subnodes:
>>> +Subnodes of the Cadence Quad SPI controller are spi slave nodes with
>>> additional +custom properties:
>>> +- cdns,read-delay : Delay for read capture logic, in clock cycles
>>> +- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
>>> +  mode chip select outputs are de-asserted between
>>> + transactions.
>>> +- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
>>> +  de-activated and the activation of another.
>>> +- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
>>> +  transaction and deasserting the device chip select
>>> + (qspi_n_ss_out).
>>> +- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
>>> +  and first bit transfer.
>>> +
>>> +Example:
>>> +
>>> +   qspi: spi@ff705000 {
>>> +   compatible = "cdns,qspi-nor";
>>> +   #address-cells = <1>;
>>> +   #size-cells = <0>;
>>> +   reg = <0xff705000 0x1000>,
>>> + <0xffa0 0x1000>;
>>> +   interrupts = <0 151 4>;
>>> +   clocks = <&qspi_clk>;
>>> +   cdns,is-decoded-cs;
>>
>> flag value ?
> 
> Sorry, I don't quite understand the question. If you mean why there is no
> value, it's because this is a boolean OF node, which just does't need to
> have a value ; it's either present or not.

you are right, thanks.

Cheers,
Vikas

> 
> B

Re: [PATCH v6 2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor

[Jonathan Cameron]

On 20/08/15 11:12, Adriana Reus wrote:
> Added entries in i2c/vendor-prefixes for the us5182d als and proximity sensor.
> Also added a documentation file for this sensor's properties.
> 
> Signed-off-by: Adriana Reus 
This isn't that trivial so I'd like some device tree maintainer
input if possible.

For now I've backed out the driver from my tree (given timing we have
loads of time to sort this out!)

Anyhow, anyone device tree related able to take a look at this.

Adriana, btw these should be cc'd to the device tree maintainers in
the first place (now added).

Jonathan
> ---
>  .../devicetree/bindings/iio/light/us5182d.txt  | 23 
> ++
>  .../devicetree/bindings/vendor-prefixes.txt|  1 +
>  2 files changed, 24 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt 
> b/Documentation/devicetree/bindings/iio/light/us5182d.txt
> new file mode 100644
> index 000..7785c56
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
> @@ -0,0 +1,23 @@
> +* UPISEMI us5182d I2C ALS and Proximity sensor
> +
> +Required properties:
> +- compatible: must be "upisemi,usd5182"
> +- reg: the I2C address of the device
> +
> +Optional properties:
> +- upisemi,glass-coef: glass attenuation factor
> +- upisemi,dark-ths: array of thresholds (adc counts) corresponding to every 
> scale
> +- upisemi,upper-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4) 
> applied when light > threshold
> +- upisemi,lower-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4) 
> applied when light < threshold
> +
> +Example:
> +
> +usd5182@39 {
> +compatible = "upisemi,usd5182";
> +reg = <0x39>;
> +upisemi,glass-coef = < 1000 >;
> +upisemi,dark-ths = /bits/ 16 <170 200 512 512 800 2000 4000 
> 8000>;
> +upisemi,upper-dark-gain = /bits/ 8 <0x00>;
> +upisemi,lower-dark-gain = /bits/ 8 <0x16>;
> +};
> +
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index d444757..5b40bab 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -211,6 +211,7 @@ toshiba   Toshiba Corporation
>  toumaz   Toumaz
>  tplink   TP-LINK Technologies Co., Ltd.
>  trulyTruly Semiconductors Limited
> +upisemi  uPI Semiconductor Corp.
>  usi  Universal Scientific Industrial Co., Ltd.
>  v3   V3 Semiconductor
>  varisciteVariscite Ltd.
> 

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

Re: [PATCH v6 1/2] iio: light: Add support for UPISEMI uS5182d als and proximity sensor

[Jonathan Cameron]

On 20/08/15 11:12, Adriana Reus wrote:
> Add support for UPISEMI us5182d als and proximity sensor.
> Supports raw readings.
> Data sheet for this device can be found here:
> http://www.upi-semi.com/temp/uS5182D-DS-P0103-temp.pdf
> 
> Signed-off-by: Adriana Reus 
Applied to the togreg branch of iio.git - initially pushed out
as testing for the autobuilders to play with it.

Thanks,

Jonathan
> ---
>  Changes since v5:
>  * fixed typos (thank you, Peter)
> 
>  drivers/iio/light/Kconfig   |  10 +
>  drivers/iio/light/Makefile  |   1 +
>  drivers/iio/light/us5182d.c | 507 
> 
>  3 files changed, 518 insertions(+)
>  create mode 100644 drivers/iio/light/us5182d.c
> 
> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> index 7ed859a..0442f01 100644
> --- a/drivers/iio/light/Kconfig
> +++ b/drivers/iio/light/Kconfig
> @@ -287,6 +287,16 @@ config TSL4531
>To compile this driver as a module, choose M here: the
>module will be called tsl4531.
>  
> +config US5182D
> + tristate "UPISEMI light and proximity sensor"
> + depends on I2C
> + help
> +  If you say yes here you get support for the UPISEMI US5182D
> +  ambient light and proximity sensor.
> +
> +  This driver can also be built as a module.  If so, the module
> +  will be called us5182d.
> +
>  config VCNL4000
>   tristate "VCNL4000 combined ALS and proximity sensor"
>   depends on I2C
> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
> index 91c74c0..528cc8f 100644
> --- a/drivers/iio/light/Makefile
> +++ b/drivers/iio/light/Makefile
> @@ -27,4 +27,5 @@ obj-$(CONFIG_STK3310)  += stk3310.o
>  obj-$(CONFIG_TCS3414)+= tcs3414.o
>  obj-$(CONFIG_TCS3472)+= tcs3472.o
>  obj-$(CONFIG_TSL4531)+= tsl4531.o
> +obj-$(CONFIG_US5182D)+= us5182d.o
>  obj-$(CONFIG_VCNL4000)   += vcnl4000.o
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> new file mode 100644
> index 000..49dab3c
> --- /dev/null
> +++ b/drivers/iio/light/us5182d.c
> @@ -0,0 +1,507 @@
> +/*
> + * Copyright (c) 2015 Intel Corporation
> + *
> + * Driver for UPISEMI us5182d Proximity and Ambient Light Sensor.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * To do: Interrupt support.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define US5182D_REG_CFG0 0x00
> +#define US5182D_CFG0_ONESHOT_EN  BIT(6)
> +#define US5182D_CFG0_SHUTDOWN_EN BIT(7)
> +#define US5182D_CFG0_WORD_ENABLE BIT(0)
> +
> +#define US5182D_REG_CFG1 0x01
> +#define US5182D_CFG1_ALS_RES16   BIT(4)
> +#define US5182D_CFG1_AGAIN_DEFAULT   0x00
> +
> +#define US5182D_REG_CFG2 0x02
> +#define US5182D_CFG2_PX_RES16BIT(4)
> +#define US5182D_CFG2_PXGAIN_DEFAULT  BIT(2)
> +
> +#define US5182D_REG_CFG3 0x03
> +#define US5182D_CFG3_LED_CURRENT100  (BIT(4) | BIT(5))
> +
> +#define US5182D_REG_CFG4 0x10
> +
> +/*
> + * Registers for tuning the auto dark current cancelling feature.
> + * DARK_TH(reg 0x27,0x28) - threshold (counts) for auto dark cancelling.
> + * when ALS  > DARK_TH --> ALS_Code = ALS - Upper(0x2A) * Dark
> + * when ALS < DARK_TH --> ALS_Code = ALS - Lower(0x29) * Dark
> + */
> +#define US5182D_REG_UDARK_TH 0x27
> +#define US5182D_REG_DARK_AUTO_EN 0x2b
> +#define US5182D_REG_AUTO_LDARK_GAIN  0x29
> +#define US5182D_REG_AUTO_HDARK_GAIN  0x2a
> +
> +#define US5182D_OPMODE_ALS   0x01
> +#define US5182D_OPMODE_PX0x02
> +#define US5182D_OPMODE_SHIFT 4
> +
> +#define US5182D_REG_DARK_AUTO_EN_DEFAULT 0x80
> +#define US5182D_REG_AUTO_LDARK_GAIN_DEFAULT  0x16
> +#define US5182D_REG_AUTO_HDARK_GAIN_DEFAULT  0x00
> +
> +#define US5182D_REG_ADL  0x0c
> +#define US5182D_REG_PDL  0x0e
> +
> +#define US5182D_REG_MODE_STORE   0x21
> +#define US5182D_STORE_MODE   0x01
> +
> +#define US5182D_REG_CHIPID   0xb2
> +
> +#define US5182D_OPMODE_MASK  GENMASK(5, 4)
> +#define US5182D_AGAIN_MASK 

Re: [PATCH v4 4/4] dt: Document Holt HI-8435 bindings

[Jonathan Cameron]

On 20/08/15 20:38, Vladimir Barinov wrote:
> These bindings can be used to register Holt HI-8435 threshold detector
> 
> Signed-off-by: Vladimir Barinov 
This is fine and trivial enough that I am not going to need a device tree
ack (not that I'd complain if one showed up :)


Will pick it up with the driver..
> ---
> Changes in version 2:
> - renamed file name hi-843x.txt to hi8435.txt
> - removed hi-8436,hi-8436,hi-8437
> - removed holt,debounce-soft field
> - renamed holt,debounc-soft-delay to holt,debounce-interval
> - renamed mr-gpio to reset-gpios
> Changes in version 3:
> - none
> Changes in version 4:
> - removed debounce_interval property
> - removed reset-gpios to use GPIO descriptor API
> 
>  .../devicetree/bindings/iio/adc/hi8435.txt  | 21 
> +
>  1 file changed, 21 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt 
> b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
> new file mode 100644
> index 000..3b0348c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
> @@ -0,0 +1,21 @@
> +Holt Integrated Circuits HI-8435 threshold detector bindings
> +
> +Required properties:
> + - compatible: should be "holt,hi8435"
> + - reg: spi chip select number for the device
> +
> +Recommended properties:
> + - spi-max-frequency: definition as per
> + Documentation/devicetree/bindings/spi/spi-bus.txt
> +
> +Optional properties:
> + - gpios: GPIO used for controlling the reset pin
> +
> +Example:
> +sensor@0 {
> + compatible = "holt,hi8435";
> + reg = <0>;
> + gpios = <&gpio6 1 0>;
> +
> + spi-max-frequency = <100>;
> +};
> 

--
To unsubscribe from this list: send the line "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 3/4] iio: adc: hi8435: Holt HI-8435 threshold detector

[Jonathan Cameron]

On 20/08/15 20:38, Vladimir Barinov wrote:
> Add Holt threshold detector driver for HI-8435 chip
> 
> Signed-off-by: Vladimir Barinov 
A few little bits and bobs below but basically there.

Jonathan
> ---
> Changes in version 2:
> - Added file sysfs-bus-iio-adc-hi8435
> - Changed naming from "discrete ADC" to "threshold detector"
> - Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup
> - Made *_show and *_store functions static
> - moved out from iio buffers to iio events
> - removed hi8436/hi8437 chips from the driver
> - moved from debounce_soft_delay/enable to debounce_interval via
>   IIO_CHAN_INFO_DEBOUNCE_TIME
> - added name extention "comparator"
> - moved threshold/hysteresis setup via generic iio event sysfs
> - added software mask/unmask channel events
> - added programming sensor outputs while in test mode via
>   IIO_CHAN_INFO_RAW
> - added channels .ext_info for programming sensing mode
> Changes in version 3:
> - fixed typos
> - moved  to match alphabetic order
> - fixed missed */event/* prefix in the ABI description
> - added missed colon in sysfs-bus-iio-adc-hi8435 file after "What"
> - moved in_voltageY_comparator_thresh_either_en and debounce_time
>   to sysfs-bus-iio file
> - added error checking for hi8435_write[b|w]
> Changes in version 4:
> - removed software debounce logic
> - fixed typo in comment s/threshold/thresholds
> - removed test_enable sysfs entry
> - removed *_raw entries
> - removed extended_name
> - switched to GPIO descriptor API
> - added comment describing the need of thresholds initialization
> - added debugfs_reg_access
> 
>  Documentation/ABI/testing/sysfs-bus-iio|   1 +
>  Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 |  39 ++
>  drivers/iio/adc/Kconfig|  11 +
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/hi8435.c   | 535 
> +
>  5 files changed, 587 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
>  create mode 100644 drivers/iio/adc/hi8435.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 42d360f..20312a0 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -581,6 +581,7 @@ What: 
> /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
>  What:
> /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
>  What:/sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
>  What:
> /sys/.../iio:deviceX/events/in_voltageY_thresh_falling_en
> +What:/sys/.../iio:deviceX/events/in_voltageY_thresh_either_en
>  What:/sys/.../iio:deviceX/events/in_tempY_thresh_rising_en
>  What:/sys/.../iio:deviceX/events/in_tempY_thresh_falling_en
>  KernelVersion:   2.6.37
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 
> b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
> new file mode 100644
> index 000..e3f1943
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
> @@ -0,0 +1,39 @@
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_voltageY_sensing_mode
> +Date:August 2015
> +KernelVersion:   4.2.0
> +Contact: sou...@cogentembedded.com
> +Description:
> + Program sensor type for threshold detector inputs.
> + Could be either "GND-Open" or "Supply-Open" mode. Y is a
> + threshold detector input channel. Channels 0..7, 8..15, 16..23
> + and 24..31 has common sensor types.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_falling_value
> +Date:August 2015
> +KernelVersion:   4.2.0
> +Contact: sou...@cogentembedded.com
> +Description:
> + Channel Y low voltage threshold. If sensor input voltage goes 
> lower then
> + this value then the threshold falling event is pushed.
> + Depending on in_voltageY_sensing_mode the low voltage threshold
> + is separately set for "GND-Open" and "Supply-Open" modes.
> + Channels 0..31 have common low threshold values, but could have 
> different
> + sensing_modes.
> + The low voltage threshold range is between 2..21V.
> + Hysteresis between low and high thresholds can not be lower 
> then 2 and
> + can not be odd.
Should note that what happens if it is set to odd.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_rising_value
> +Date:August 2015
> +KernelVersion:   4.2.0
> +Contact: sou...@cogentembedded.com
> +Description:
> + Channel Y high voltage threshold. If sensor input voltage goes 
> higher then
> + this value then the threshold rising event is pushed.
> + 

Re: [PATCH v4 2/4] dt: Add vendor prefix 'holt'

[Jonathan Cameron]

On 23/08/15 23:32, Rob Herring wrote:
> On Thu, Aug 20, 2015 at 2:38 PM, Vladimir Barinov
>  wrote:
>> Add Holt Integrated Circuits, Inc. to the list of device tree vendor
>> prefixes
>>
>> Signed-off-by: Vladimir Barinov 
> 
> Acked-by: Rob Herring 
Applied to the togreg branch of iio.git.

Thanks,

Jonathan
> 
>> ---
>> Changes in version 2:
>> - none
>> Changes in version 3:
>> - none
>> Changes in version 4:
>> - none
>>
>>  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 d444757..bc64cc9 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -99,6 +99,7 @@ himax Himax Technologies, Inc.
>>  hisilicon  Hisilicon Limited.
>>  hitHitachi Ltd.
>>  hitex  Hitex Development Tools
>> +holt   Holt Integrated Circuits, Inc.
>>  honeywell  Honeywell
>>  hp Hewlett Packard
>>  i2se   I2SE GmbH
>> --
>> 1.9.1
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

Re: [PATCH v4 1/4] iio: Support triggered events

[Jonathan Cameron]

On 20/08/15 20:43, Vladimir Barinov wrote:
> Verified event and buffer polling works concurrently on the same trigger with 
> hi-8435.
> The buffer interface part for hi-8435 was not sent.
> 
> On 20.08.2015 22:37, Vladimir Barinov wrote:
>> Support triggered events.
>>
>> This is useful for chips that don't have their own interrupt sources.
>> It allows to use generic/standalone iio triggers for those drivers.
>>
>> Signed-off-by: Vladimir Barinov 
Applied with a certain amount of fuzz (the buffers have moved out into
their own directory).

Jonathan
>> ---
>> Changes in version 2:
>> - initially added
>> Changes in version 3:
>> - fixed grammar in patch description
>> - changed license header to match "GNU Public License v2 or later"
>> Changes in version 4:
>> - added pollfunc_event to separate triggering buffer and event
>> interfaces. This allows runnig both from the same trigger
>> - removed 'currentmode' for triggered buffer since useless
>> - renamed parameters of iio_triggered_event_setup
>>
>>   drivers/iio/Kconfig|  6 +++
>>   drivers/iio/Makefile   |  1 +
>>   drivers/iio/industrialio-core.c|  4 +-
>>   drivers/iio/industrialio-trigger.c | 12 +-
>>   drivers/iio/industrialio-triggered-event.c | 68 
>> ++
>>   include/linux/iio/iio.h|  3 ++
>>   include/linux/iio/triggered_event.h| 11 +
>>   7 files changed, 101 insertions(+), 4 deletions(-)
>>   create mode 100644 drivers/iio/industrialio-triggered-event.c
>>   create mode 100644 include/linux/iio/triggered_event.h
>>
>> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
>> index 4011eff..8fcc92f 100644
>> --- a/drivers/iio/Kconfig
>> +++ b/drivers/iio/Kconfig
>> @@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
>>   This value controls the maximum number of consumers that a
>>   given trigger may handle. Default is 2.
>>   +config IIO_TRIGGERED_EVENT
>> +tristate
>> +select IIO_TRIGGER
>> +help
>> +  Provides helper functions for setting up triggered events.
>> +
>>   source "drivers/iio/accel/Kconfig"
>>   source "drivers/iio/adc/Kconfig"
>>   source "drivers/iio/amplifiers/Kconfig"
>> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
>> index 698afc2..40dc13e 100644
>> --- a/drivers/iio/Makefile
>> +++ b/drivers/iio/Makefile
>> @@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
>>   industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
>> obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
>> +obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
>>   obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
>> obj-y += accel/
>> diff --git a/drivers/iio/industrialio-core.c 
>> b/drivers/iio/industrialio-core.c
>> index b3fcc2c..2c3b6a1 100644
>> --- a/drivers/iio/industrialio-core.c
>> +++ b/drivers/iio/industrialio-core.c
>> @@ -962,7 +962,7 @@ static void iio_device_unregister_sysfs(struct iio_dev 
>> *indio_dev)
>>   static void iio_dev_release(struct device *device)
>>   {
>>   struct iio_dev *indio_dev = dev_to_iio_dev(device);
>> -if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
>> +if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
>>   iio_device_unregister_trigger_consumer(indio_dev);
>>   iio_device_unregister_eventset(indio_dev);
>>   iio_device_unregister_sysfs(indio_dev);
>> @@ -1241,7 +1241,7 @@ int iio_device_register(struct iio_dev *indio_dev)
>>   "Failed to register event set\n");
>>   goto error_free_sysfs;
>>   }
>> -if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
>> +if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
>>   iio_device_register_trigger_consumer(indio_dev);
>> if ((indio_dev->modes & INDIO_ALL_BUFFER_MODES) &&
>> diff --git a/drivers/iio/industrialio-trigger.c 
>> b/drivers/iio/industrialio-trigger.c
>> index 570606c..ae2806a 100644
>> --- a/drivers/iio/industrialio-trigger.c
>> +++ b/drivers/iio/industrialio-trigger.c
>> @@ -366,10 +366,18 @@ static ssize_t iio_trigger_write_current(struct device 
>> *dev,
>> indio_dev->trig = trig;
>>   -if (oldtrig)
>> +if (oldtrig) {
>> +if (indio_dev->modes & INDIO_EVENT_TRIGGERED)
>> +iio_trigger_detach_poll_func(oldtrig,
>> + indio_dev->pollfunc_event);
>>   iio_trigger_put(oldtrig);
>> -if (indio_dev->trig)
>> +}
>> +if (indio_dev->trig) {
>>   iio_trigger_get(indio_dev->trig);
>> +if (indio_dev->modes & INDIO_EVENT_TRIGGERED)
>> +iio_trigger_attach_poll_func(indio_dev->trig,
>> + indio_dev->pollfunc_event);
>> +}
>> return len;
>>   }
>> diff --git a/drivers/iio/industrialio-triggered-event.c 
>> b/drivers/iio/industrialio-triggered-event.c
>> new file mode 100644
>> index 000..8cc254f
>>

Re: [PATCH 2/2] ARM: dts: rockchip: correct regulator PM properties

[Doug Anderson]

Hi,

On Tue, Aug 18, 2015 at 11:19 PM, Heiko Stuebner  wrote:
> great, just take into account the deep vs. shallow suspend modes :-)

One note: do you think it would make sense to re-implement shallow
suspend as "standby"?  I had a proof of concept doing that in
.  One nice
advantage is that you "magically" get a second set of regulator states
for standby vs "mem".

If I understand correctly, the distinction between "standby" and "mem"
is not too clearly defined, so if we wanted to use it for this it
wouldn't be terrible?

-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 00/16] deps: deterministic driver initialization order

[Alexander Holler]

Am 27.08.2015 um 21:01 schrieb Alexander Holler:

Am 26.08.2015 um 14:28 schrieb Alexander Holler:


The final 2 patches are fixes which should end up in mainline, regardless
if this feature is merged or not.


Just in case your serial or MTD-NAND partitions don't work, the drivers
drivers/tty/serial/8250/8250_core.c and drivers/mtd/ofpart.c need the
same trivial fix for their initcall level as found in the last two
patches of my series. I'm not going to post these patches now until I've
got some feedback for the other stuff.


And just in case, I also have an idea how to fix such dependencies for 
drivers without DT (by adding hard-wired dependencies directly to 
drivers). That would also be usable for ACPI and x86.


But one step after another. Based on my past experiences, I don't even 
think the stuff I've just posted will ever end up in the kernel.



Regards,

Alexander Holler


--
To unsubscribe from this list: send the line "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] arm/arm64: build all dtbs for CONPILE_TEST

[Rob Herring]

On Thu, Aug 27, 2015 at 11:08 AM, Olof Johansson  wrote:
> On Thu, Aug 27, 2015 at 8:56 AM, Rob Herring  wrote:
>> Enable building all dtb files when COMPILE_TEST is enabled. The dtbs are
>> not really dependent on a platform being enabled or any other kernel
>> config, so for testing coverage it is convenient to build all of the
>> dtbs.
>>
>> This builds all dts files in the tree, not just targets listed. This
>> is simpler for arm64 which has a bunch of sub-dirs.
>>
>> Signed-off-by: Rob Herring 
>> Cc: Russell King 
>> Cc: Catalin Marinas 
>> Cc: Will Deacon 
>> ---
>> I've had this on my todo list for a while. RFC for now as I want to do
>> the rest of the arches as well. I was originally thinking a new target
>> for this, but thanks to Olof for the COMPILE_TEST suggestion.
>>
>> Rob
>>
>>  arch/arm/boot/dts/Makefile   | 4 
>>  arch/arm64/boot/dts/Makefile | 6 ++
>>  2 files changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 246473a..4968442a 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -712,5 +712,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
>>  dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
>>  endif
>>
>> +dtstree:= $(srctree)/$(src)
>> +
>> +dtb-$(CONFIG_COMPILE_TEST) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
>> $(dtstree)/*.dts))
>> +
>>  always := $(dtb-y)
>>  clean-files:= *.dtb
>> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
>> index 38913be..9f19390 100644
>> --- a/arch/arm64/boot/dts/Makefile
>> +++ b/arch/arm64/boot/dts/Makefile
>> @@ -11,3 +11,9 @@ dts-dirs += sprd
>>  dts-dirs += xilinx
>>
>>  subdir-y   := $(dts-dirs)
>> +
>> +dtstree:= $(srctree)/$(src)
>> +
>> +dtb-$(CONFIG_COMPILE_TEST) := $(patsubst $(dtstree)/%.dts,%.dtb, $(foreach 
>> d,$(dts-dirs), $(wildcard $(dtstree)/$(d)/*.dts)))
>
> I think it would be more appropriate to build dtb-n  here instead of
> _any_ file ending in dts.

The problem is here dtb-n is NULL. We have to add this into every
sub-dir. Not a big deal to do, but my concern was remembering to it
for new ones. Then again, most people are good at mindlessly
copy-pasting so maybe that won't be a problem. :)

> It would be useful to build all files, but it's not the behavior that
> COMPILE_TEST usually has.

Just changing to dtb-n would be equivalent because there is no other
dependency to enable building. Code has other dependencies typically.
What dtb do we not want to built in an allyesconfig build? If dtb's
have any dependencies, that would be a bug. To really make this
equivalent to a driver using COMPILE_TEST, we would need kconfig
symbols specifically for each platform's dtbs. Then we would have the
2 stage unhide (setting COMPILE_TEST) then enable the option.

I was also thinking that perhaps we don't want to require a kconfig
symbol for every platform family. Adding a kconfig entry is the only
way to enable building a dtb ATM. I know there are 2 camps to this
policy though.

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

Re: [PATCH 00/16] deps: deterministic driver initialization order

[Alexander Holler]

Am 26.08.2015 um 14:28 schrieb Alexander Holler:


The final 2 patches are fixes which should end up in mainline, regardless
if this feature is merged or not.


Just in case your serial or MTD-NAND partitions don't work, the drivers
drivers/tty/serial/8250/8250_core.c and drivers/mtd/ofpart.c need the 
same trivial fix for their initcall level as found in the last two 
patches of my series. I'm not going to post these patches now until I've 
got some feedback for the other stuff.


Regards,

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

Re: [PATCH-v3 1/2] mfd: devicetree: bindings: 88pm800: Add DT property for dual phase enable

[Mark Brown]

On Mon, Aug 24, 2015 at 08:24:10PM +0530, Vaibhav Hiremath wrote:

> Mark,

> Any comments here before I spin V4.

Please just resubmit things, seeing that a change was requested is
usually a good indication that a new version is incoming.


signature.asc
Description: Digital signature

[PATCH 0/1] ARM: dts: sun5i: inet98v_rev2 fix regulator for the usb wifi

[Hans de Goede]

Hi Maxime,

Here is a fixup patch for the patch adding a dts for the inet98v_rev2.

I'm not sure if you've merged the original patch yet, hence I'm sending
this as a follow-up patch. If you've not yet merged the original patch
feel free to squash this fix in.

Regards,

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

[PATCH] ARM: dts: sun5i: inet98v_rev2 fix regulator for the usb wifi module

[Hans de Goede]

The usb-wifi module is not connected to a gpio controller regulator
(as is typical on sunxi boards), instead is it connected to ldo3.

This commit fixes the us_phy usb1_vbus-supply setting thereby making
sure that we power the usb-wifi and that it can be used.

This commit also removes the wrong and now unused bits which refer to
the gpio controlled reg_usb1_vbus.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i-a13-inet-98v-rev2.dts | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a13-inet-98v-rev2.dts 
b/arch/arm/boot/dts/sun5i-a13-inet-98v-rev2.dts
index 6d466a2..6fa54b6 100644
--- a/arch/arm/boot/dts/sun5i-a13-inet-98v-rev2.dts
+++ b/arch/arm/boot/dts/sun5i-a13-inet-98v-rev2.dts
@@ -201,11 +201,6 @@
status = "okay";
 };
 
-®_usb1_vbus {
-   gpio = <&pio 6 11 GPIO_ACTIVE_HIGH>; /* PG11 */
-   status = "okay";
-};
-
 &uart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins_b>;
@@ -221,16 +216,12 @@
allwinner,pins = "PG12";
 };
 
-&usb1_vbus_pin_a {
-   allwinner,pins = "PG11";
-};
-
 &usbphy {
pinctrl-names = "default";
pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
usb0_id_det-gpio = <&pio 6 2 GPIO_ACTIVE_HIGH>; /* PG2 */
usb0_vbus_det-gpio = <&pio 6 1 GPIO_ACTIVE_HIGH>; /* PG1 */
usb0_vbus-supply = <®_usb0_vbus>;
-   usb1_vbus-supply = <®_usb1_vbus>;
+   usb1_vbus-supply = <®_ldo3>;
status = "okay";
 };
-- 
2.4.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 V8 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.

[Marek Vasut]

On Thursday, August 27, 2015 at 07:44:34 PM, vikas wrote:
> Hi,
> 
> On 08/21/2015 02:20 AM, Marek Vasut wrote:
> > From: Graham Moore 
> > 
> > Add binding document for the Cadence QSPI controller.
> > 
> > Signed-off-by: Graham Moore 
> > Signed-off-by: Marek Vasut 
> > Cc: Alan Tull 
> > Cc: Brian Norris 
> > Cc: David Woodhouse 
> > Cc: Dinh Nguyen 
> > Cc: Graham Moore 
> > Cc: Vikas MANOCHA 
> > Cc: Yves Vandervennet 
> > Cc: devicetree@vger.kernel.org
> > ---
> > 
> >  .../devicetree/bindings/mtd/cadence-quadspi.txt| 56
> >  ++ 1 file changed, 56 insertions(+)
> >  create mode 100644
> >  Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
> > 
> > V2: Add cdns prefix to driver-specific bindings.
> > V3: Use existing property "is-decoded-cs" instead of creating a
> > 
> > duplicate, "ext-decoder". Timing parameters are in nanoseconds,
> > not master reference clocks. Remove bus-num completely.
> > 
> > V4: Add new properties fifo-width and trigger-address
> > V7: - Prefix all of the Cadence-specific properties with cdns prefix,
> > 
> >   those are in particular "cdns,is-decoded-cs", "cdns,fifo-depth",
> >   "cdns,fifo-width", "cdns,trigger-address".
> > 
> > - Drop bogus properties which were not used and were incorrect.
> > 
> > V8: Align lines to 80 chars.
> > 
> > diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
> > b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt new file
> > mode 100644
> > index 000..f248056
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
> > @@ -0,0 +1,56 @@
> > +* Cadence Quad SPI controller
> > +
> > +Required properties:
> > +- compatible : Should be "cdns,qspi-nor".
> > +- reg : Contains two entries, each of which is a tuple consisting of a
> > +   physical address and length. The first entry is the address and
> > +   length of the controller register set. The second entry is the
> > +   address and length of the QSPI Controller data area.
> 
> still hooked up with  "Controller data area", it is ambiguous.
> Use something which is more clear: Nor Flash memory mapped address.

I have to disagree, I will call it whatever it is called in the datasheet
and it is called "controller data area".

> > +- interrupts : Unit interrupt specifier for the controller interrupt.
> > +- clocks : phandle to the Quad SPI clock.
> > +- cdns,fifo-depth : Size of the data FIFO in words.
> > +- cdns,fifo-width : Bus width of the data FIFO in bytes.
> > +- cdns,trigger-address : 32-bit indirect AHB trigger address.
> > +
> 
> > +Optional properties:
> again, is it optional ? can the driver be used without these properties ?

Why wouldn't it be possible to use the driver with no SPI NOR attached to
it? It's a cornercase, but still a valid one.

> > +- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
> 
> again, add info what the decoder is for ?

This is something Graham has to clarify. Based on the code (I'm sure you did
check the code), it's a 4:16 demuxer.

> > +
> > +Optional subnodes:
> > +Subnodes of the Cadence Quad SPI controller are spi slave nodes with
> > additional +custom properties:
> > +- cdns,read-delay : Delay for read capture logic, in clock cycles
> > +- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
> > +  mode chip select outputs are de-asserted between
> > + transactions.
> > +- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
> > +  de-activated and the activation of another.
> > +- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
> > +  transaction and deasserting the device chip select
> > + (qspi_n_ss_out).
> > +- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
> > +  and first bit transfer.
> > +
> > +Example:
> > +
> > +   qspi: spi@ff705000 {
> > +   compatible = "cdns,qspi-nor";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   reg = <0xff705000 0x1000>,
> > + <0xffa0 0x1000>;
> > +   interrupts = <0 151 4>;
> > +   clocks = <&qspi_clk>;
> > +   cdns,is-decoded-cs;
> 
> flag value ?

Sorry, I don't quite understand the question. If you mean why there is no
value, it's because this is a boolean OF node, which just does't need to
have a value ; it's either present or not.

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

Re: [PATCH] ARM: dts: rockchip: Add support for SD/MMC on MarsBoard-RK3066

[Heiko Stuebner]

Am Montag, 24. August 2015, 19:21:53 schrieb Heiko Stuebner:
> Am Montag, 24. August 2015, 18:04:41 schrieb Romain Perier:
> > This enables SDMMC0 on the board and gives a basic support for SD cards.
> > 
> > Signed-off-by: Romain Perier 
> 
> applied to my dts branch, after moving it above the "&pinctrl" node

just as notice, this moved down to linux-4.4 material
--
To unsubscribe from this list: send the line "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 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.

[vikas]

Hi,

On 08/21/2015 02:20 AM, Marek Vasut wrote:
> From: Graham Moore 
> 
> Add binding document for the Cadence QSPI controller.
> 
> Signed-off-by: Graham Moore 
> Signed-off-by: Marek Vasut 
> Cc: Alan Tull 
> Cc: Brian Norris 
> Cc: David Woodhouse 
> Cc: Dinh Nguyen 
> Cc: Graham Moore 
> Cc: Vikas MANOCHA 
> Cc: Yves Vandervennet 
> Cc: devicetree@vger.kernel.org
> ---
>  .../devicetree/bindings/mtd/cadence-quadspi.txt| 56 
> ++
>  1 file changed, 56 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
> 
> V2: Add cdns prefix to driver-specific bindings.
> V3: Use existing property "is-decoded-cs" instead of creating a
> duplicate, "ext-decoder". Timing parameters are in nanoseconds,
> not master reference clocks. Remove bus-num completely.
> V4: Add new properties fifo-width and trigger-address
> V7: - Prefix all of the Cadence-specific properties with cdns prefix,
>   those are in particular "cdns,is-decoded-cs", "cdns,fifo-depth",
>   "cdns,fifo-width", "cdns,trigger-address".
> - Drop bogus properties which were not used and were incorrect.
> V8: Align lines to 80 chars.
> 
> diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt 
> b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
> new file mode 100644
> index 000..f248056
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
> @@ -0,0 +1,56 @@
> +* Cadence Quad SPI controller
> +
> +Required properties:
> +- compatible : Should be "cdns,qspi-nor".
> +- reg : Contains two entries, each of which is a tuple consisting of a
> + physical address and length. The first entry is the address and
> + length of the controller register set. The second entry is the
> + address and length of the QSPI Controller data area.

still hooked up with  "Controller data area", it is ambiguous.
Use something which is more clear: Nor Flash memory mapped address.

> +- interrupts : Unit interrupt specifier for the controller interrupt.
> +- clocks : phandle to the Quad SPI clock.
> +- cdns,fifo-depth : Size of the data FIFO in words.
> +- cdns,fifo-width : Bus width of the data FIFO in bytes.
> +- cdns,trigger-address : 32-bit indirect AHB trigger address.
> +
> +Optional properties:

again, is it optional ? can the driver be used without these properties ?

> +- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.

again, add info what the decoder is for ? 

> +
> +Optional subnodes:
> +Subnodes of the Cadence Quad SPI controller are spi slave nodes with 
> additional
> +custom properties:
> +- cdns,read-delay : Delay for read capture logic, in clock cycles
> +- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
> +  mode chip select outputs are de-asserted between
> +   transactions.
> +- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
> +  de-activated and the activation of another.
> +- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
> +  transaction and deasserting the device chip select
> +   (qspi_n_ss_out).
> +- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
> +  and first bit transfer.
> +
> +Example:
> +
> + qspi: spi@ff705000 {
> + compatible = "cdns,qspi-nor";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0xff705000 0x1000>,
> +   <0xffa0 0x1000>;
> + interrupts = <0 151 4>;
> + clocks = <&qspi_clk>;
> + cdns,is-decoded-cs;

flag value ?

Cheers,
Vikas

> + cdns,fifo-depth = <128>;
> + cdns,fifo-width = <4>;
> + cdns,trigger-address = <0x>;
> +
> + flash0: n25q00@0 {
> + ...
> + cdns,read-delay = <4>;
> + cdns,tshsl-ns = <50>;
> + cdns,tsd2d-ns = <50>;
> + cdns,tchsh-ns = <4>;
> + cdns,tslch-ns = <4>;
> + };
> + };
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 6/8] scsi: ufs: make the UFS variant a platform device

[Rob Herring]

On Sun, Aug 23, 2015 at 8:09 AM, Yaniv Gardi  wrote:
> This change turns the UFS variant (SCSI_UFS_QCOM) into a UFS
> a platform device.
> In order to do so a few additional changes are required:
> 1. The ufshcd-pltfrm is no longer serves as a platform device.
>Now it only serves as a group of platform APIs such as PM APIs
>(runtime suspend/resume, system suspend/resume etc), parsers of
>clocks, regulators and pm_levels from DT.
> 2. What used to be the old platform "probe" is now "only"
>a pltfrm_init() routine, that does exactly the same, but only
>being called by the new probe function of the UFS variant.
>
> Signed-off-by: Yaniv Gardi 
>
> ---
>  .../devicetree/bindings/ufs/ufshcd-pltfrm.txt  |  2 +-
>  drivers/scsi/ufs/ufs-qcom.c| 78 +-
>  drivers/scsi/ufs/ufshcd-pltfrm.c   | 92 
> ++
>  drivers/scsi/ufs/ufshcd-pltfrm.h   | 41 ++
>  drivers/scsi/ufs/ufshcd.c  | 10 +++
>  drivers/scsi/ufs/ufshcd.h  |  1 +
>  6 files changed, 152 insertions(+), 72 deletions(-)
>  create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.h
>
> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt 
> b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> index 5357919..b39e765 100644
> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> @@ -4,7 +4,7 @@ UFSHC nodes are defined to describe on-chip UFS host 
> controllers.
>  Each UFS controller instance should have its own node.
>
>  Required properties:
> -- compatible: compatible list, contains "jedec,ufs-1.1"
> +- compatible: compatible list, contains "jedec,ufs-1.1" or 
> "qcom,ufshc"

Replying again as I inadvertently dropped everyone.

This should also have a more specific compatible string with the SOC
name/number in it. It may be "the same in all SOCs", but there is
always the possibility for bugs/limitations to be found that are
specific to an SOC even if all RTL versions are identical (e.g.
different max clock speeds). It is about making the dtb future proof,
not about what exactly you need today. You can keep qcom,ufshc for
driver matching if you want.

>  - interrupts: 
>  - reg   : 

What about phy properties? No Unipro PHY block that requires setup?

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

Re: [PATCH v4 3/4] PCI: st: Provide support for the sti PCIe controller

[Pratyush Anand]

Hi Gabriel,

Looks good to me.

On Thu, Aug 27, 2015 at 6:04 PM, Gabriel Fernandez
 wrote:
> sti pcie is built around a Synopsis Designware PCIe IP.
>
> Signed-off-by: Fabrice Gasnier 
> Signed-off-by: Gabriel Fernandez 


> +static int st_pcie_link_up(struct pcie_port *pp)
> +{
> +   u32 status;
> +   int link_up;

nit: why not bool

> +   int count = 0;

[...]

> +static void st_pcie_board_reset(struct pcie_port *pp)
> +{
> +   struct st_pcie *pcie = to_st_pcie(pp);
> +
> +   if (!gpio_is_valid(pcie->reset_gpio))
> +   return;
> +
> +   if (gpio_direction_output(pcie->reset_gpio, 0)) {
> +   dev_err(pp->dev, "Cannot set PERST# (gpio %u) to output\n",
> +   pcie->reset_gpio);
> +   return;
> +   }
> +
> +   /* From PCIe spec */
> +   msleep(2);
> +   gpio_direction_output(pcie->reset_gpio, 1);
> +
> +   /*
> +* PCIe specification states that you should not issue any config
> +* requests until 100ms after asserting reset, so we enforce that here
> +*/
> +   msleep(100);

IIRC, specification says to wait after link training completes. So
shouldn't it be after st_pcie_enable_ltssm. Moreover, I wonder why
others do not need it.

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

[PATCH 1/4] dt-binding: gpio: Add Qualcomm SMSM device tree documentation

[Bjorn Andersson]

This documents a device tree binding for exposing the Qualcomm Shared
Memory State Machine as a set of gpio- and interrupt-controllers.

Signed-off-by: Bjorn Andersson 
---
 .../devicetree/bindings/gpio/qcom,smsm.txt | 114 +
 drivers/gpio/Kconfig   |   8 ++
 drivers/gpio/Makefile  |   1 +
 3 files changed, 123 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smsm.txt

diff --git a/Documentation/devicetree/bindings/gpio/qcom,smsm.txt 
b/Documentation/devicetree/bindings/gpio/qcom,smsm.txt
new file mode 100644
index ..06201ba76594
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/qcom,smsm.txt
@@ -0,0 +1,114 @@
+Qualcomm Shared Memory State Machine
+
+The Shared Memory State Machine facilitates broadcasting of single bit state
+information between the processors in a Qualcomm SoC. Each processor is
+assigned 32 bits of state that can be modified. A processor can through a
+matrix of bitmaps signal subscription of notifications upon changes to a
+certain bit owned by a certain remote processor.
+
+This document defines the binding for a driver that implements and exposes this
+a GPIO controller and a set of interrupt controllers.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,smsm"
+
+- qcom,ipc-N:
+   Usage: required
+   Value type: 
+   Definition: three entries specifying the outgoing ipc bit used for
+   signaling the N:th remote processor
+   - phandle to a syscon node representing the apcs registers
+   - u32 representing offset to the register within the syscon
+   - u32 representing the ipc bit within the register
+
+- qcom,local-host:
+   Usage: optional
+   Value type: 
+   Definition: identifier of the local processor in the list of hosts, or
+   in other words specifier of the column in the subscription
+   matrix representing the local processor
+   defaults to host 0
+
+- #address-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 1
+
+- #size-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 0
+
+= SUBNODES
+Each processor's state bits are described by a subnode of the smsm device node.
+A node can either be a gpio-controller - denoting the local processors bits -
+or an interrupt-controller - denoting a remote processors state bits.  The node
+names are not important.
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: specifies the offset, in words, of the first bit for this
+   entry
+
+- gpio-controller:
+   Usage: required for local entry
+   Value type: 
+   Definition: marks the entry as a gpio-controller and the state bits to
+   belong to the local processor
+
+- #gpio-cells:
+   Usage: required for local entry
+   Value type: 
+   Definition: must be 2 - denotes bit number and GPIO flags
+
+- interrupt-controller:
+   Usage: required for remote entries
+   Value type: 
+   Definition: marks the entry as a interrupt-controller and the state bits
+   to belong to a remote processor
+
+- #interrupt-cells:
+   Usage: required for remote entries
+   Value type: 
+   Definition: must be 2 - denotes bit number and IRQ flags
+
+- interrupts:
+   Usage: required for remote entries
+   Value type: 
+   Definition: one entry specifying remote IRQ used by the remote processor
+   to signal changes of its state bits
+
+
+= EXAMPLE
+The following example shows the SMEM setup for controlling properties of the
+wireless processor, defined from the 8974 apps processor's point-of-view. It
+encompasses one outbound entry and the outgoing interrupt for the wireless
+processor.
+
+smsm {
+   compatible = "qcom,smsm";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   qcom,ipc-3 = <&apcs 8 19>;
+
+   apps_smsm: apps@0 {
+   reg = <0>;
+
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   wcnss_smsm: wcnss@7 {
+   reg = <7>;
+   interrupts = <0 144 1>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b4fc9e4d24c6..0e57b60faae8 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -354,6 +354,14 @@ config GPIO_PXA
help
  Say yes here to support the PXA GPIO device
 
+config GPIO_QCOM_SMSM
+   bool "Qualcomm Shared Memory State Machine"
+   depends on QCOM_SMEM
+   help
+ Say yes here to support the Qualcomm Shared Memory State Machine.
+ The state machine is represented by bits in shared memory and is
+  

[PATCH 4/4] gpio: qcom-smp2p: Qualcomm Shared Memory Point to Point

[Bjorn Andersson]

Introduce the Qualcomm Shard Memory Point to Point driver, exposing bits
from the SMP2P protocol as gpio and interrupt controllers.

Signed-off-by: Bjorn Andersson 
---
 drivers/gpio/Kconfig   |   7 +
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-qcom-smp2p.c | 601 +
 3 files changed, 609 insertions(+)
 create mode 100644 drivers/gpio/gpio-qcom-smp2p.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 0e57b60faae8..82c61ce5af8f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -354,6 +354,13 @@ config GPIO_PXA
help
  Say yes here to support the PXA GPIO device
 
+config GPIO_QCOM_SMP2P
+   bool "Qualcomm Shared Memory Point to Point support"
+   depends on QCOM_SMEM
+   help
+ Say yes here to support the Qualcomm Shared Memory Point to Point
+ protocol, exposed to the system as GPIOs.
+
 config GPIO_QCOM_SMSM
bool "Qualcomm Shared Memory State Machine"
depends on QCOM_SMEM
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 0fd213892403..fdab869a7212 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -75,6 +75,7 @@ obj-$(CONFIG_GPIO_PCF857X)+= gpio-pcf857x.o
 obj-$(CONFIG_GPIO_PCH) += gpio-pch.o
 obj-$(CONFIG_GPIO_PL061)   += gpio-pl061.o
 obj-$(CONFIG_GPIO_PXA) += gpio-pxa.o
+obj-$(CONFIG_GPIO_QCOM_SMP2P)  += gpio-qcom-smp2p.o
 obj-$(CONFIG_GPIO_QCOM_SMSM)   += gpio-qcom-smsm.o
 obj-$(CONFIG_GPIO_RC5T583) += gpio-rc5t583.o
 obj-$(CONFIG_GPIO_RDC321X) += gpio-rdc321x.o
diff --git a/drivers/gpio/gpio-qcom-smp2p.c b/drivers/gpio/gpio-qcom-smp2p.c
new file mode 100644
index ..f2eb2f095cc0
--- /dev/null
+++ b/drivers/gpio/gpio-qcom-smp2p.c
@@ -0,0 +1,601 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications AB.
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The Shared Memory Point to Point (SMP2P) protocol facilitates communication
+ * of a single 32-bit value between two processors.  Each value has a single
+ * writer (the local side) and a single reader (the remote side). Values are
+ * uniquely identified in the system by the directed edge (local processor ID
+ * to remote processor ID) and a string identifier.
+ *
+ * Each processor is responsible for creating the outgoing SMEM items and each
+ * item is writable by the local processor and readable by the remote
+ * processor.  By using two separate SMEM items that are single-reader and
+ * single-writer, SMP2P does not require any remote locking mechanisms.
+ *
+ * The driver uses the Linux GPIO and interrupt framework to expose a virtual
+ * GPIO for each outbound entry and a virtual interrupt controller for each
+ * inbound entry.
+ */
+
+#define SMP2P_MAX_ENTRY 16
+#define SMP2P_MAX_ENTRY_NAME 16
+
+#define SMP2P_FEATURE_SSR_ACK 0x1
+
+#define SMP2P_MAGIC 0x504d5324
+
+/**
+ * struct smp2p_smem_item - in memory communication structure
+ * @magic: magic number
+ * @version:   version - must be 1
+ * @features:  features flag - currently unused
+ * @local_pid: processor id of sending end
+ * @remote_pid:processor id of receiving end
+ * @total_entries: number of entries - always SMP2P_MAX_ENTRY
+ * @valid_entries: number of allocated entries
+ * @flags:
+ * @entries:   individual communication entries
+ * @name:  name of the entry
+ * @value: content of the entry
+ */
+struct smp2p_smem_item {
+   u32 magic;
+   u8 version;
+   unsigned features:24;
+   u16 local_pid;
+   u16 remote_pid;
+   u16 total_entries;
+   u16 valid_entries;
+   u32 flags;
+
+   struct {
+   u8 name[SMP2P_MAX_ENTRY_NAME];
+   u32 value;
+   } entries[SMP2P_MAX_ENTRY];
+} __packed;
+
+/**
+ * struct smp2p_entry - driver context matching one entry
+ * @node:  list entry to keep track of allocated entries
+ * @smp2p: reference to the device driver context
+ * @name:  name of the entry, to match against smp2p_smem_item
+ * @value: pointer to smp2p_smem_item entry value
+ * @last_value:last handled value
+ * @domain:irq_domain for inbound entries
+ * @irq_enabled:bitmap to track enabled irq bits
+ * @irq_rising:bitmap to mark irq bits for rising detection
+ * @irq_falling:bitmap 

[PATCH 3/4] dt-binding: gpio: Introduce qcom,smp2p binding documentation

[Bjorn Andersson]

Introduce binding documentation for the Qualcomm Shared Memory Point 2 Point
protocol implemented as gpio and interrupt controllers.

Signed-off-by: Bjorn Andersson 
---
 .../devicetree/bindings/gpio/qcom,smp2p.txt| 112 +
 1 file changed, 112 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smp2p.txt

diff --git a/Documentation/devicetree/bindings/gpio/qcom,smp2p.txt 
b/Documentation/devicetree/bindings/gpio/qcom,smp2p.txt
new file mode 100644
index ..532c7d3ce3d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/qcom,smp2p.txt
@@ -0,0 +1,112 @@
+Qualcomm Shared Memory Point 2 Point binding
+
+The Shared Memory Point to Point (SMP2P) protocol facilitates communication of
+a single 32-bit value between two processors.  Each value has a single writer
+(the local side) and a single reader (the remote side).  Values are uniquely
+identified in the system by the directed edge (local processor ID to remote
+processor ID) and a string identifier. This documents defines the binding for a
+driver that implements and exposes this protocol as a set of GPIO and interrupt
+controllers.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,smp2p"
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: one entry specifying the smp2p notification interrupt
+
+- qcom,ipc:
+   Usage: required
+   Value type: 
+   Definition: three entries specifying the outgoing ipc bit used for
+   signaling the remote end of the smp2p edge:
+   - phandle to a syscon node representing the apcs registers
+   - u32 representing offset to the register within the syscon
+   - u32 representing the ipc bit within the register
+
+- qcom,smem:
+   Usage: required
+   Value type: 
+   Definition: two identifiers of the inbound and outbound smem items used
+   for this edge
+
+- qcom,local-pid:
+   Usage: required
+   Value type: 
+   Definition: specifies the identfier of the local endpoint of this edge
+
+- qcom,remote-pid:
+   Usage: required
+   Value type: 
+   Definition: specifies the identfier of the remote endpoint of this edge
+
+= SUBNODES
+Each SMP2P pair contain a set of inbound and outbound entries, these are
+described in subnodes of the smp2p device node. The node names are not
+important.
+
+- qcom,entry-name:
+   Usage: required
+   Value type: 
+   Definition: specifies the name of this entry, for inbound entries this
+   will be used to match against the remotely allocated entry
+   and for outbound entries this name is used for allocating
+   entries
+
+- interrupt-controller:
+   Usage: required for incoming entries
+   Value type: 
+   Definition: marks the entry as inbound; the node should be specified
+   as a two cell interrupt-controller as defined in 
+   "../interrupt-controller/interrupts.txt"
+
+- #interrupt-cells:
+   Usage: required for incoming entries
+   Value type: 
+   Definition: must be 2 - denoting the bit in the entry and IRQ flags
+
+- gpio-controller:
+   Usage: required for outgoing entries
+   Value type: 
+   Definition: marks the entry as outbound; the node should be specified
+   as a two cell gpio-controller as defined in "gpio.txt"
+
+- #gpio-cells:
+   Usage: required for outgoing entries
+   Value type: 
+   Definition: must be 2 - denoting the bit in the entry and GPIO flags
+
+= EXAMPLE
+The following example shows the SMP2P setup with the wireless processor,
+defined from the 8974 apps processor's point-of-view. It encompasses one
+inbound and one outbound entry:
+
+wcnss-smp2p {
+   compatible = "qcom,smp2p";
+   qcom,smem = <431>, <451>;
+
+   interrupts = <0 143 1>;
+
+   qcom,ipc = <&apcs 8 18>;
+
+   qcom,local-pid = <0>;
+   qcom,remote-pid = <4>;
+
+   wcnss_smp2p_out: master-kernel {
+   qcom,entry-name = "master-kernel";
+
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   wcnss_smp2p_in: slave-kernel {
+   qcom,entry-name = "slave-kernel";
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+};
-- 
1.8.2.2

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

[PATCH 2/4] gpio: qcom-smsm: Add driver for Qualcomm SMSM

[Bjorn Andersson]

This driver exposed the Qualcomm Shared Memory State Machine bits as
GPIOs to the system.

Signed-off-by: Bjorn Andersson 
---
 drivers/gpio/gpio-qcom-smsm.c | 631 ++
 1 file changed, 631 insertions(+)
 create mode 100644 drivers/gpio/gpio-qcom-smsm.c

diff --git a/drivers/gpio/gpio-qcom-smsm.c b/drivers/gpio/gpio-qcom-smsm.c
new file mode 100644
index ..4b3f28c469b6
--- /dev/null
+++ b/drivers/gpio/gpio-qcom-smsm.c
@@ -0,0 +1,631 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications Inc.
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * This driver implements the Qualcomm Shared Memory State Machine, a mechanism
+ * for communicating single bit state information to remote processors.
+ *
+ * The implementation is based on two sections of shared memory; the first
+ * holding the state bits and the second holding a matrix of subscription bits.
+ *
+ * The state bits are structured in entries of 32 bits, each belonging to one
+ * system in the SoC. The entry belonging to the local system is considered
+ * read-write, while the rest should be considered read-only.
+ *
+ * The subscription matrix consists of N bitmaps per entry, denoting interest
+ * in updates of the entry for each of the N hosts. Upon updating a state bit
+ * each host's subscription bitmap should be queried and the remote system
+ * should be interrupted if they request so.
+ *
+ * The subscription matrix is laid out in entry-major order:
+ * entry0: [host0 ... hostN]
+ * .
+ * .
+ * entryM: [host0 ... hostN]
+ *
+ * A third, optional, shared memory region might contain information regarding
+ * the number of entries in the state bitmap as well as number of columns in
+ * the subscription matrix.
+ */
+
+/*
+ * Shared memory identifiers, used to acquire handles to respective memory
+ * region.
+ */
+#define SMEM_SMSM_SHARED_STATE 85
+#define SMEM_SMSM_CPU_INTR_MASK333
+#define SMEM_SMSM_SIZE_INFO419
+
+/*
+ * Default sizes, in case SMEM_SMSM_SIZE_INFO is not found.
+ */
+#define SMSM_DEFAULT_NUM_ENTRIES   8
+#define SMSM_DEFAULT_NUM_HOSTS 3
+
+struct smsm_entry;
+struct smsm_host;
+
+/**
+ * struct qcom_smsm - smsm driver context
+ * @dev:   smsm device pointer
+ * @local_host:column in the subscription matrix representing this 
system
+ * @num_hosts: number of columns in the subscription matrix
+ * @num_entries: number of entries in the state map and rows in the 
subscription
+ * matrix
+ * @local_state: pointer to the local processor's state bits
+ * @subscription: pointer to local processor's row in subscription matrix
+ * @chip:  gpio_chip for interfacing the state bits
+ * @entries:   context for each of the entries
+ * @hosts: context for each of the hosts
+ */
+struct qcom_smsm {
+   struct device *dev;
+
+   u32 local_host;
+
+   u32 num_hosts;
+   u32 num_entries;
+
+   u32 *local_state;
+   u32 *subscription;
+   struct gpio_chip chip;
+
+   struct smsm_entry *entries;
+   struct smsm_host *hosts;
+};
+
+/**
+ * struct smsm_entry - per remote processor entry context
+ * @smsm:  back-reference to driver context
+ * @domain:IRQ domain for this entry, if representing a remote system
+ * @irq_enabled: bitmap of which state bits IRQs are enabled
+ * @irq_rising:bitmap tracking if rising bits should be propagated
+ * @irq_falling: bitmap tracking if falling bits should be propagated
+ * @last_value:snapshot of state bits last time the interrupts where 
propagated
+ * @remote_state: pointer to this entry's state bits
+ * @subscription: pointer to a row in the subscription matrix representing this
+ * entry
+ */
+struct smsm_entry {
+   struct qcom_smsm *smsm;
+
+   struct irq_domain *domain;
+   DECLARE_BITMAP(irq_enabled, 32);
+   DECLARE_BITMAP(irq_rising, 32);
+   DECLARE_BITMAP(irq_falling, 32);
+   u32 last_value;
+
+   u32 *remote_state;
+   u32 *subscription;
+};
+
+/**
+ * struct smsm_host - representation of a remote host
+ * @ipc_regmap:regmap for outgoing interrupt
+ * @ipc_offset:offset in @ipc_regmap for outgoing interrupt
+ * @ipc_bit:   bit in @ipc_regmap + @ipc_offset for outgoing interrupt
+ */
+struct smsm_host {
+   struct regmap *ipc_regmap;
+   int ipc_offset;
+  

[PATCH 0/4] Qualcomm Shared Memory State Machines

[Bjorn Andersson]

This series implements the two different mechanisms for propagating single bit
state information, used on the various Qualcomm platforms.

The system was traditionally used by the modem and application processor to
convey information about boot progress, power states, error handling and so on.
This was implemented as SMSM, with status bits representing a single local
state.

As the complexity of the SoC grew the state bits array grew and the need for
targeting specific state information at specific remote processors appeared.
SMP2P solves this by having separate shared memory regions per processor-pair.

This state information is e.g. used to convey progress and status of remote
firmware loading. Individual bits maps to various stages of the boot and error
states.

As some of these states on some platforms are passed as physical signals
instead, the two drivers are modelled as gpio- and interrupt-controllers -
providing a nice abstraction both in device tree sense and Linux implementation
sense.

Bjorn Andersson (4):
  dt-binding: gpio: Add Qualcomm SMSM device tree documentation
  gpio: qcom-smsm: Add driver for Qualcomm SMSM
  dt-binding: gpio: Introduce qcom,smp2p binding documentation
  gpio: qcom-smp2p: Qualcomm Shared Memory Point to Point

 .../devicetree/bindings/gpio/qcom,smp2p.txt| 112 
 .../devicetree/bindings/gpio/qcom,smsm.txt | 114 
 drivers/gpio/Kconfig   |  15 +
 drivers/gpio/Makefile  |   2 +
 drivers/gpio/gpio-qcom-smp2p.c | 601 
 drivers/gpio/gpio-qcom-smsm.c  | 631 +
 6 files changed, 1475 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smp2p.txt
 create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smsm.txt
 create mode 100644 drivers/gpio/gpio-qcom-smp2p.c
 create mode 100644 drivers/gpio/gpio-qcom-smsm.c

-- 
1.8.2.2

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

Re: [PATCH v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

[Stefan Agner]

On 2015-08-27 09:34, Brian Norris wrote:
> On Wed, Aug 26, 2015 at 06:02:31PM -0700, Stefan Agner wrote:
>> On 2015-08-25 13:16, Brian Norris wrote:
>> > On Mon, Aug 03, 2015 at 11:27:26AM +0200, Stefan Agner wrote:
>> >> diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
>> >> new file mode 100644
>> >> index 000..5c8dfe8
>> >> --- /dev/null
>> >> +++ b/drivers/mtd/nand/vf610_nfc.c
>> >> @@ -0,0 +1,645 @@
>> >
>> > ...
>> >
>> >> +/*
>> >> + * This function supports Vybrid only (MPC5125 would have full RB and 
>> >> four CS)
>> >> + */
>> >> +static void vf610_nfc_select_chip(struct mtd_info *mtd, int chip)
>> >> +{
>> >> +#ifdef CONFIG_SOC_VF610
>> >
>> > Why the #ifdef? I don't see anything compile-time specific to SOC_VF610.
>> >
>> > If this is trying to handle the comment above ("This function supports
>> > Vybrid only (MPC5125 would have full RB and four CS)") then that's the
>> > wrong way of doing it, as you need to support multiplatform kernels.
>> > You'll need to have a way to differentiate the different platform
>> > support at runtime, not compile time.
>>
>> Yes it is trying to handle the comment above. Well, the other two
>> platforms I am aware of are also different architectures... (PowerPC and
>> ColdFire). I think we won't have a multi-architecture kernel anytime
>> soon,
> 
> Ha, right. Sorry, I don't really know this particular IP.
> 
>> hence I think removing the code at compile time is the right thing
>> todo.
> 
> I don't believe that conclusion follows though.
> 
>> However, probably CONFIG_SOC_VF610 is the wrong symbol then, I could
>> just use CONFIG_ARM and add a comment that this might be different on
>> another other ARM SoC than VF610.
>>
>> Just checked CodingStyle, and I see that IS_ENABLED is the preferred way
>> for conditional compiling.
>>
>> So my suggestion:
>>
>> static void vf610_nfc_select_chip(struct mtd_info *mtd, int chip)
>> {
>>  struct vf610_nfc *nfc = mtd_to_nfc(mtd);
>>  u32 tmp = vf610_nfc_read(nfc, NFC_ROW_ADDR);
>>
>>  if (!IS_ENABLED(CONFIG_ARM))
>>  return;
>>
>>  /*
>>   * This code is only tested on the ARM platform VF610
>>   * PowerPC based MPC5125 would have full RB and four CS
>>   */
>> 
>>
>> With that the compiler should be able to remove this (currently) ARM
>> VF610 specific code on the other supported architectures...
>>
>> What do you think?
> 
> The code structure isn't bad, and yes, IS_ENABLED() would be preferable,
> as it removes some of the problems with #ifdef, but I still don't think
> the processor architecture has much to do with the version of the IP.

Well yes, the processor architecture has probably not much to do with
the IP version.

However, that particular problem, the wiring up of the CS/RB signals, is
probably more SoC (as a whole) specific, and how that is done might have
some relation which architecture is in use...

I do not have a strong opinion on this, so we might as well go with the
run-time distinction using compatible. If there are different IP
variants within one architecture, we anyway would need to do that.

> The canonical way of distiguishing per-IP revisions is to key on the
> compatible property. So you'd have some kind of enum, which would
> currently only have an entry for VF610. i.e.:
> 
>   /* MPC5125 not yet supported */
>   if (nfc->revision != NAND_VFC610)
>   return;
> 

Ok, just checked, I can use the data field of the of table to assign
specific data to a compatible string, similar to how pxa3xx_nand.c does
it.

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

Re: [PATCH 1/2] drm/layerscape: Add HDMI support for DCU DRM driver

[Rob Herring]

On Wed, Aug 26, 2015 at 11:19 PM, Jianwei Wang
 wrote:
> Some Freescale SoCs, there has an DVI/HDMI controller and a PHY,
> attached to one of their display controller unit's LCDC interfaces.
> This patch adds a driver for SiI902x. The SiI902x is a HDMI
> transmitter It supports resolutions from standard definition
> 480i/p and 576i/p all the way to high-definition 720p, 1080i,
> and 1080p, the highest resolution supported by HDTVs today.
>
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 
> ---
>  .../devicetree/bindings/video/SiI902x.txt  |  17 +
>  drivers/gpu/drm/fsl-dcu/Makefile   |   1 +
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c | 639 
> +

This is a separate chip. It should not be part of the FSL DCU driver.

>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c  |  10 +
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h   |  10 +
>  5 files changed, 677 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/SiI902x.txt
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c
>
> diff --git a/Documentation/devicetree/bindings/video/SiI902x.txt 
> b/Documentation/devicetree/bindings/video/SiI902x.txt
> new file mode 100644
> index 000..d304499
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/SiI902x.txt
> @@ -0,0 +1,17 @@
> +Device-Tree bindings for the SiI902x hdmi transmitter.
> +
> +Required properties:
> +- compatible:  Should be "sii902x".

This should have the vendor prefix sil. It should also be specific to
which chip number. There is already a binding for the 9022 in
vexpress-v2m.dtsi, so we should use the same binding although it is
not documented. I'm not too sure about the -tpi and -cpi parts of the
binding though. It appears the device has multiple i2c addresses which
is fairly common. I would not do multiple nodes like was done. If the
secondary addresses are known or programmable thru the primary
address, we can just hardcode them in the driver (ADV7511 is an
example). If we don't know the addresses, then we can just put
multiple addresses in the reg property.

Rob

> +- reg: The I2C address of the device.
> +- interrupts:  Interrupt number to the cpu.
> +
> +Example:
> +
> +&i2c1 {
> +   status = "okay";
> +   hdmi: sii9022a@39 {
> + compatible = "sii902x";
> + reg = <0x39>;
> + interrupts = ;
> +   };

You should be using the OF graph to describe the connection to the DCU output.

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

Re: [PATCH v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

[Brian Norris]

On Wed, Aug 26, 2015 at 06:10:05PM -0700, Stefan Agner wrote:
> On 2015-08-25 13:34, Brian Norris wrote:
> > One more thing...
> > 
> > On Mon, Aug 03, 2015 at 11:27:26AM +0200, Stefan Agner wrote:
> >> --- /dev/null
> >> +++ b/drivers/mtd/nand/vf610_nfc.c
> >> @@ -0,0 +1,645 @@
> > ...
> >> +struct vf610_nfc {
> >> +  struct mtd_info mtd;
> >> +  struct nand_chip chip;
> >> +  struct device *dev;
> >> +  void __iomem *regs;
> >> +  struct completion cmd_done;
> >> +  uint buf_offset;
> >> +  int page_sz;
> > 
> > AFAICT (even with the 2nd patch), you never really use this field. You
> > just set it/increment it, but don't use it for anything. Kill it?
> 
> It is used in the write path, I think I meant to use it for subpage
> writes, when I thought it would just mean to transfer only parts of the
> page to the controller.

Ah, you're right. Sorry, I missed that. I got mixed up seeing most of
your uses of 'page_sz' were for a local variable of the same name, not
this field.

> However, as the subpage discussion basically concluded in not using it
> for now on this controller, we can as well transfer the complete page
> (page_sz). Or is there another case in which vf610_nfc_write_buf could
> be called with less than page_sz?

I'll leave that up to you. I'm perfectly fine leaving it in, now that I
see its proper use. Just in case things change in the future, I think it
does help to clarify the flow of information a little. Although, I might
recommend a change in naming, since it could get confused with the
actual page size -- which is normally constant -- whereas this field
changes dynamically depending on the command-in-flight.

Perhaps the struct could have 'write_len' (to help represent an action)
and the local variable in vf610_nfc_command() could be 'tfr_len' (to
distinguish how it isn't necessarily identical to 'write_len')? Just
throwing (likely bad) ideas out there.

Regards,
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 v1 3/3] arm64: dts: add Hi6220 mailbox node

[Mark Rutland]

> > Option 2:
> > 
> > memory@0 {
> > device_type = "memory";
> > reg = <0x0 0x0 0x0 0x4000>;
> > };
> > 
> > reserved-memory {
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
> > 
> > mcu_reserved: mcu_reserved@06dff000 {
> > no-map;
> > reg = <0x0 0x06dff000 0x0 0x1000>,  /* MCU mailbox 
> > buffer */
> >   <0x0 0x05e0 0x0 0x0010>,  /* MCU firmware 
> > buffer */
> >   <0x0 0x0740f000 0x0 0x1000>;  /* MCU firmware 
> > section */
> > };
> > };
> > 
> > [...]
> > 
> > mailbox: mailbox@f751 {
> > #mbox-cells = <1>;
> > compatible = "hisilicon,hi6220-mbox";
> > reg = <0x0 0xf751 0x0 0x1000>; /* IPC_S */
> > memory-region = <&mcu_reserved>;   /* Mailbox buffer */
> > interrupts = ;
> > };
> 
> I prefer the second one. From my view, memory node should only describe
> the hardware information of memory.

That doesn't align with the spec. Per ePAPR, in the description of a
memory node:

The client program may access memory not covered by any memory
reservations (see section 8.3) using any storage attributes it
chooses. However, before changing the storage attributes used to
access a real page, the client program is responsible for
performing actions required by the architecture and
implementation, possibly including flushing the real page from
the caches.

Note that in this context, memory reservation applies to /memreserve/.
We can only expect other software to handle /memreserve/, and not
reserved-memory, as the latter was introduced by Linux and has not
existed for anywhere near as long.

Additionally, the OS is permitted to map reserved memory with cacheable
attributes.

So the memory nodes have never been about the raw hardware layout, but
rather the regions that the OS may map. If (outside of the driver
responsible for the region) the OS should not map a region of memory,
that region should not appear in any memory node.

As mentioned in my other reply, for a region that the OS could map but
cannot use, I don't see much point in listing that memory in any memory
node.

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 v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

[Brian Norris]

On Wed, Aug 26, 2015 at 06:02:31PM -0700, Stefan Agner wrote:
> On 2015-08-25 13:16, Brian Norris wrote:
> > On Mon, Aug 03, 2015 at 11:27:26AM +0200, Stefan Agner wrote:
> >> diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
> >> new file mode 100644
> >> index 000..5c8dfe8
> >> --- /dev/null
> >> +++ b/drivers/mtd/nand/vf610_nfc.c
> >> @@ -0,0 +1,645 @@
> > 
> > ...
> > 
> >> +/*
> >> + * This function supports Vybrid only (MPC5125 would have full RB and 
> >> four CS)
> >> + */
> >> +static void vf610_nfc_select_chip(struct mtd_info *mtd, int chip)
> >> +{
> >> +#ifdef CONFIG_SOC_VF610
> > 
> > Why the #ifdef? I don't see anything compile-time specific to SOC_VF610.
> > 
> > If this is trying to handle the comment above ("This function supports
> > Vybrid only (MPC5125 would have full RB and four CS)") then that's the
> > wrong way of doing it, as you need to support multiplatform kernels.
> > You'll need to have a way to differentiate the different platform
> > support at runtime, not compile time.
> 
> Yes it is trying to handle the comment above. Well, the other two
> platforms I am aware of are also different architectures... (PowerPC and
> ColdFire). I think we won't have a multi-architecture kernel anytime
> soon,

Ha, right. Sorry, I don't really know this particular IP.

> hence I think removing the code at compile time is the right thing
> todo.

I don't believe that conclusion follows though.

> However, probably CONFIG_SOC_VF610 is the wrong symbol then, I could
> just use CONFIG_ARM and add a comment that this might be different on
> another other ARM SoC than VF610.
> 
> Just checked CodingStyle, and I see that IS_ENABLED is the preferred way
> for conditional compiling.
> 
> So my suggestion:
> 
> static void vf610_nfc_select_chip(struct mtd_info *mtd, int chip)
> {
>   struct vf610_nfc *nfc = mtd_to_nfc(mtd);
>   u32 tmp = vf610_nfc_read(nfc, NFC_ROW_ADDR);
> 
>   if (!IS_ENABLED(CONFIG_ARM))
>   return;
> 
>   /*
>* This code is only tested on the ARM platform VF610
>* PowerPC based MPC5125 would have full RB and four CS
>*/
> 
> 
> With that the compiler should be able to remove this (currently) ARM
> VF610 specific code on the other supported architectures...
> 
> What do you think?

The code structure isn't bad, and yes, IS_ENABLED() would be preferable,
as it removes some of the problems with #ifdef, but I still don't think
the processor architecture has much to do with the version of the IP.
The canonical way of distiguishing per-IP revisions is to key on the
compatible property. So you'd have some kind of enum, which would
currently only have an entry for VF610. i.e.:

/* MPC5125 not yet supported */
if (nfc->revision != NAND_VFC610)
return;

> >> +  struct vf610_nfc *nfc = mtd_to_nfc(mtd);
> >> +  u32 tmp = vf610_nfc_read(nfc, NFC_ROW_ADDR);
> >> +
> >> +  tmp &= ~(ROW_ADDR_CHIP_SEL_RB_MASK | ROW_ADDR_CHIP_SEL_MASK);
> >> +  tmp |= 1 << ROW_ADDR_CHIP_SEL_RB_SHIFT;
> >> +
> >> +  if (chip == 0)
> >> +  tmp |= 1 << ROW_ADDR_CHIP_SEL_SHIFT;
> >> +  else if (chip == 1)
> >> +  tmp |= 2 << ROW_ADDR_CHIP_SEL_SHIFT;
> > 
> > else ... ?
> > 
> > Maybe you can write this as a formulaic pattern (e.g.:
> > 
> > tmp |= (chip + 1) << ROW_ADDR_CHIP_SEL_SHIFT;
> > 
> > ) and just do the "max # of chips" checks on a per-platform basis in the
> > probe(). Then I'm guessing this same function can apply to both
> > platforms. (I'm not looking at HW datasheets for this, BTW, just
> > guessing based on the context here.)
> 
> It seems that MCP5125 is different than VF610. MCP5125 has 4 chip
> selects and 4 R/B signals, whereas VF610 has only 2 chip selects and
> just 1 R/B signals...

OK I don't presume to know what the different IP versions look like. And
if you just note they are unsupported/untested, you're fine.

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 v1 3/3] arm64: dts: add Hi6220 mailbox node

[Mark Rutland]

On Wed, Aug 26, 2015 at 07:59:50AM +0100, Leo Yan wrote:
> Hi Haojian,
> 
> On Wed, Aug 26, 2015 at 09:25:41AM +0800, Haojian Zhuang wrote:
> > On Wed, 2015-08-26 at 00:00 +0800, Leo Yan wrote:
> > > On Tue, Aug 25, 2015 at 09:43:14PM +0800, Haojian Zhuang wrote:
> > > > On Tue, 2015-08-25 at 11:42 +0100, Mark Rutland wrote:
> > > > > > > Are you then going to hack GRUB, release a special HiKey version 
> > > > > > > of
> > > > > > > GRUB, not support any other versions, and still can your firmware
> > > > > > > UEFI?
> > > > > > 
> > > > > > I don't need to hack GRUB at all.
> > > > > 
> > > > > Then it is working for you by pure chance alone.
> > > > > 
> > > > > Please listen to the advice you are being given here; we're trying to
> > > > > ensure that your platform functions (and continues to function) as 
> > > > > best
> > > > > it can.
> > > > 
> > > > Since we discussed a lot on this, let's make a conclusion on it.
> > > > 
> > > > 1. UEFI could append the reserved buffer in it's memory mapping.
> > > > 2. These reserved buffer must be declared in DT, since we also need to
> > > >support non-UEFI (uboot) at the same time.
> > > > 3. Mailbox node should reference reserved buffer by phandle in DT. Then
> > > >map the buffer as non-cacheable in driver.
> > > > 4. These reserved buffer must use "no-map" property since it should be
> > > >non-cacheable in driver.
> > > 
> > > For more specific discussion for DTS, i list two options at here;
> > > 
> > > - Option 1: just simply reserve memory regions through memory node,
> > >   and mailbox node will directly use the buffer through reg ranges;
> > > 
> > > - Option 2: use reserved-memory and mailbox node will refer phandle
> > >   of reserved-memory;
> > > 
> > > These two options both can work well with UEFI and Uboot, but option 1
> > > is more simple and straightforward; so i personally prefer it. But
> > > look forwarding your guys' suggestion.
> > > 
> > > Option 1:
> > > 
> > >   memory@0 {
> > >   device_type = "memory";
> > >   reg = <0x 0x 0x 0x05e0>,
> > > <0x 0x05f0 0x 0x00eff000>,
> > > <0x 0x06e0 0x 0x0060f000>,
> > > <0x 0x0741 0x 0x38bf>;
> > >   };
> > > 
> > > [...]
> > > 
> > >   mailbox: mailbox@f751 {
> > >   #mbox-cells = <1>;
> > >   compatible = "hisilicon,hi6220-mbox";
> > >   reg = <0x0 0xf751 0x0 0x1000>, /* IPC_S */
> > > <0x0 0x06dff800 0x0 0x0800>; /* Mailbox buffer */
> > >   interrupts = ;
> > >   };
> > > 
> > > Option 2:
> > > 
> > >   memory@0 {
> > >   device_type = "memory";
> > >   reg = <0x0 0x0 0x0 0x4000>;
> > >   };
> > > 
> > >   reserved-memory {
> > >   #address-cells = <2>;
> > >   #size-cells = <2>;
> > >   ranges;
> > > 
> > >   mcu_reserved: mcu_reserved@06dff000 {
> > >   no-map;
> > >   reg = <0x0 0x06dff000 0x0 0x1000>,  /* MCU mailbox 
> > > buffer */
> > > <0x0 0x05e0 0x0 0x0010>,  /* MCU firmware 
> > > buffer */
> > > <0x0 0x0740f000 0x0 0x1000>;  /* MCU firmware 
> > > section */
> > >   };
> > >   };
> > > 
> > > [...]
> > > 
> > >   mailbox: mailbox@f751 {
> > >   #mbox-cells = <1>;
> > >   compatible = "hisilicon,hi6220-mbox";
> > >   reg = <0x0 0xf751 0x0 0x1000>; /* IPC_S */
> > >   memory-region = <&mcu_reserved>;   /* Mailbox buffer */
> > >   interrupts = ;
> > >   };
> > 
> > I prefer the second one. From my view, memory node should only describe
> > the hardware information of memory.
> 
> Yes, option 2 will be more simple for memory node.
> 
> But option 2 also will introduce complexity for mailbox node, due mailbox
> driver need use property "reg" and "memory-region" to sepeately depict
> the regions for mailbox's ipc and slots. If later mailbox is designed to
> use SRAM for both ipc and slots, then it will no matter with DDR anymore,
> in this case option 1 will easily switch to support it.
> 
> Another question is a general question: for Linux kernel, which is the
> best method to reserve memory regions? According to previous discussion,
> we can use /memory/ node or /reseved-memory/ node to reserve memory
> regions.

If the memory is truly reserved for a purpose and cannot be used for
anything else, I don't think it should be in the memory node at all, and
should be carved out. That aligns with what you'd do in UEFI (either not
listing the region in the memory map, or listing it with attributes such
that it may not be mapped and/or used).

I don't see much of a reason for /memreserve/, as it can cause issues
(by allowing the OS to map the region with cacheable attributes), and is
not as rigorously specified for ARM as it is for Power in ePAPR.

I un

Re: [RFC PATCH] arm/arm64: build all dtbs for CONPILE_TEST

[Olof Johansson]

On Thu, Aug 27, 2015 at 8:56 AM, Rob Herring  wrote:
> Enable building all dtb files when COMPILE_TEST is enabled. The dtbs are
> not really dependent on a platform being enabled or any other kernel
> config, so for testing coverage it is convenient to build all of the
> dtbs.
>
> This builds all dts files in the tree, not just targets listed. This
> is simpler for arm64 which has a bunch of sub-dirs.
>
> Signed-off-by: Rob Herring 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> ---
> I've had this on my todo list for a while. RFC for now as I want to do
> the rest of the arches as well. I was originally thinking a new target
> for this, but thanks to Olof for the COMPILE_TEST suggestion.
>
> Rob
>
>  arch/arm/boot/dts/Makefile   | 4 
>  arch/arm64/boot/dts/Makefile | 6 ++
>  2 files changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 246473a..4968442a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -712,5 +712,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
>  dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
>  endif
>
> +dtstree:= $(srctree)/$(src)
> +
> +dtb-$(CONFIG_COMPILE_TEST) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
> $(dtstree)/*.dts))
> +
>  always := $(dtb-y)
>  clean-files:= *.dtb
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index 38913be..9f19390 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -11,3 +11,9 @@ dts-dirs += sprd
>  dts-dirs += xilinx
>
>  subdir-y   := $(dts-dirs)
> +
> +dtstree:= $(srctree)/$(src)
> +
> +dtb-$(CONFIG_COMPILE_TEST) := $(patsubst $(dtstree)/%.dts,%.dtb, $(foreach 
> d,$(dts-dirs), $(wildcard $(dtstree)/$(d)/*.dts)))

I think it would be more appropriate to build dtb-n  here instead of
_any_ file ending in dts.

It would be useful to build all files, but it's not the behavior that
COMPILE_TEST usually has.


-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

[PATCH v2] dmaengine: vdma: Add 64 bit addressing support to the driver

[Anurag Kumar Vulisha]

This VDMA  is a soft ip, which can be programmed to support
32 bit addressing or greater than 32 bit addressing.

When the VDMA ip is configured for 32 bit address space the
transfer start address is specified by a single register.

When the  VDMA core is configured for an address space greater
than 32 then each start address is specified by a combination
of two registers. The first register specifies the LSB 32 bits
of address, while the next register specifies the MSB 32 bits
of address.For example,5Ch will specify the LSB 32 bits while
60h will specify the MSB 32 bits of the first start address.So
we need to program two registers at a time.

This patch adds the 64 bit addressing support to the vdma driver.

Signed-off-by: Anurag Kumar Vulisha 
---
  Changes in v2:
  1. Added dma-ranges property in device tree as suggested by Arnd Bergmann.
  2. Added device tree property(xlnx,addrwidth) for an identification of whether
 the IP block itself is configured in 64-bit or 32-bit mode as suggested by
 Laurent Pinchart.
  3. Modified the driver code based on the xlnx,addrwidth.
---
 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt |4 +
 drivers/dma/Kconfig|2 +-
 drivers/dma/xilinx/xilinx_vdma.c   |   81 +---
 3 files changed, 76 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index e4c4d47..434d380 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -8,6 +8,8 @@ Required properties:
 - #dma-cells: Should be <1>, see "dmas" property below
 - reg: Should contain VDMA registers location and length.
 - xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
+- xlnx,addrwidth: Should be the vdma addressing size in bits(ex: 32 bits).
+- dma-ranges: Should be as the following 
 - dma-channel child node: Should have at least one channel and can have up to
two channels per device. This node specifies the properties of each
DMA channel (see child node properties below).
@@ -41,8 +43,10 @@ axi_vdma_0: axivdma@4003 {
compatible = "xlnx,axi-vdma-1.00.a";
#dma_cells = <1>;
reg = < 0x4003 0x1 >;
+   dma-ranges = <0x 0x 0x4000>;
xlnx,num-fstores = <0x8>;
xlnx,flush-fsync = <0x1>;
+   xlnx,addrwidth = <0x20>;
dma-channel@4003 {
compatible = "xlnx,axi-vdma-mm2s-channel";
interrupts = < 0 54 4 >;
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index bda2cb0..a7cd0a8 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -398,7 +398,7 @@ config FSL_EDMA
 
 config XILINX_VDMA
tristate "Xilinx AXI VDMA Engine"
-   depends on (ARCH_ZYNQ || MICROBLAZE)
+   depends on (ARCH_ZYNQ || MICROBLAZE || ARM64)
select DMA_ENGINE
help
  Enable support for Xilinx AXI VDMA Soft IP.
diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index d8434d4..d4eebc9 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -98,6 +98,8 @@
 #define XILINX_VDMA_FRMDLY_STRIDE_FRMDLY_SHIFT 24
 #define XILINX_VDMA_FRMDLY_STRIDE_STRIDE_SHIFT 0
 
+#define XILINX_VDMA_REG_START_ADDRESS_64(n)(0x000c + 8 * (n))
+
 #define XILINX_VDMA_REG_START_ADDRESS(n)   (0x000c + 4 * (n))
 
 /* HW specific definitions */
@@ -143,16 +145,18 @@
  * @next_desc: Next Descriptor Pointer @0x00
  * @pad1: Reserved @0x04
  * @buf_addr: Buffer address @0x08
- * @pad2: Reserved @0x0C
- * @vsize: Vertical Size @0x10
- * @hsize: Horizontal Size @0x14
+ * @buf_addr_msb: Buffer msb address @0x0c
+ * @pad2: Reserved @0x10
+ * @vsize: Vertical Size @0x14
+ * @hsize: Horizontal Size @0x18
  * @stride: Number of bytes between the first
- * pixels of each horizontal line @0x18
+ * pixels of each horizontal line @0x1C
  */
 struct xilinx_vdma_desc_hw {
u32 next_desc;
u32 pad1;
u32 buf_addr;
+   u32 buf_addr_msb;
u32 pad2;
u32 vsize;
u32 hsize;
@@ -206,6 +210,7 @@ struct xilinx_vdma_tx_descriptor {
  * @tasklet: Cleanup work after irq
  * @config: Device configuration info
  * @flush_on_fsync: Flush on Frame sync
+ * @ext_addr: Indicates 64 bit addressing is supported by dma channel
  */
 struct xilinx_vdma_chan {
struct xilinx_vdma_device *xdev;
@@ -229,6 +234,7 @@ struct xilinx_vdma_chan {
struct tasklet_struct tasklet;
struct xilinx_vdma_config config;
bool flush_on_fsync;
+   bool ext_addr;
 };
 
 /**
@@ -239,6 +245,7 @@ struct xilinx_vdma_chan {
  * @chan: Driver specific VDMA channel
  * @has_sg: Specifies whether Scatter-Gather is present or not
  * @flush_on_fsync: Flush on frame sync
+ * @ext_addr: Indicates 64 bit addressing

[RFC PATCH] arm/arm64: build all dtbs for CONPILE_TEST

[Rob Herring]

Enable building all dtb files when COMPILE_TEST is enabled. The dtbs are
not really dependent on a platform being enabled or any other kernel
config, so for testing coverage it is convenient to build all of the
dtbs.

This builds all dts files in the tree, not just targets listed. This
is simpler for arm64 which has a bunch of sub-dirs.

Signed-off-by: Rob Herring 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
I've had this on my todo list for a while. RFC for now as I want to do 
the rest of the arches as well. I was originally thinking a new target 
for this, but thanks to Olof for the COMPILE_TEST suggestion. 

Rob

 arch/arm/boot/dts/Makefile   | 4 
 arch/arm64/boot/dts/Makefile | 6 ++
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 246473a..4968442a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -712,5 +712,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
 dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
 endif
 
+dtstree:= $(srctree)/$(src)
+
+dtb-$(CONFIG_COMPILE_TEST) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
$(dtstree)/*.dts))
+
 always := $(dtb-y)
 clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 38913be..9f19390 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -11,3 +11,9 @@ dts-dirs += sprd
 dts-dirs += xilinx
 
 subdir-y   := $(dts-dirs)
+
+dtstree:= $(srctree)/$(src)
+
+dtb-$(CONFIG_COMPILE_TEST) := $(patsubst $(dtstree)/%.dts,%.dtb, $(foreach 
d,$(dts-dirs), $(wildcard $(dtstree)/$(d)/*.dts)))
+
+always := $(dtb-y)
-- 
2.1.4

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

Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node

[Daniel Thompson]

On 26/08/15 02:25, Haojian Zhuang wrote:

Option 1:

memory@0 {
device_type = "memory";
reg = <0x 0x 0x 0x05e0>,
  <0x 0x05f0 0x 0x00eff000>,
  <0x 0x06e0 0x 0x0060f000>,
  <0x 0x0741 0x 0x38bf>;
};

[snip]

>>

Option 2:

memory@0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x4000>;
};


>> [snip]
>>


I prefer the second one. From my view, memory node should only describe
the hardware information of memory.


Haven't we already established that, to avoid the risk of UEFI 
applications accessing inappropriate memory locations, a (correct) UEFI 
implementation must use, and pass to the kernel, a memory map that looks 
like option 1?


That being the case why would we want u-boot (or any other similar 
bootloader) to pass a memory map that is gratuitously different to the 
one supplied by UEFI?



Daniel.
--
To unsubscribe from this list: send the line "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 3/6] PCI: designware: Add ARM64 support

[Gabriele Paoloni]

> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-ow...@vger.kernel.org]
> On Behalf Of Gabriel Fernandez
> Sent: 27 August 2015 13:57
> To: Wangzhou (B)
> Cc: Bjorn Helgaas; jingooh...@gmail.com; pratyush.an...@gmail.com; Arnd
> Bergmann; Russell King; thomas.petazz...@free-electrons.com; Gabriele Paoloni;
> lorenzo.pieral...@arm.com; james.mo...@arm.com; Liviu Dudau;
> ja...@lakedaemon.net; r...@kernel.org; devicetree@vger.kernel.org; linux-
> p...@vger.kernel.org; xuwei (O); qiuzhenfa; liudongdong (C); zhangjukuo;
> Liguozhu (Kenneth); qiujiang; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v8 3/6] PCI: designware: Add ARM64 support
> 
> Hi Zhou,
> 
> You can add my Tested-by: Gabriel Fernandez 
> 
> I tested your patchset with a STMicroelectronics PCIe controller.
> This controller is based on designware PCIe driver and works on ARM32.
> 
> Please find my patchset here:
> http://www.spinics.net/lists/kernel/msg2064266.html
> 
> Best Regards.
> 
> Gabriel.

Many Thanks for this Gabriel

Cheers
Gab

> 
> On 25 August 2015 at 11:58, Zhou Wang  wrote:
> > This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
> > function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
> > move related operations to dw_pcie_host_init.
> >
> > This patch also try to use of_pci_get_host_bridge_resources for ARM32 and
> ARM64
> > according to the suggestion for Gabriele[1]
> >
> > Finally this patch reverts commit f4c55c5a3f7f "PCI: designware: Program ATU
> > with untranslated address" based on 1/6 in this series. we delete *_mod_base
> in
> > pcie-designware. This was discussed in [2]
> >
> > I have compiled the driver with multi_v7_defconfig. However, I don't have
> > ARM32 PCIe related board to do test. It will be appreciated if someone could
> > help to test it.
> >
> > Signed-off-by: Zhou Wang 
> > Signed-off-by: Gabriele Paoloni 
> > Signed-off-by: Arnd Bergmann 
> > Tested-By: James Morse 
> >
> > [1] http://www.spinics.net/lists/linux-pci/msg42194.html
> > [2] http://www.spinics.net/lists/arm-kernel/msg436779.html
> > ---
> >  drivers/pci/host/pci-dra7xx.c  |  14 +--
> >  drivers/pci/host/pci-keystone-dw.c |   2 +-
> >  drivers/pci/host/pcie-designware.c | 230 +-
> ---
> >  drivers/pci/host/pcie-designware.h |  14 +--
> >  4 files changed, 90 insertions(+), 170 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> > index 18ae7ff..ac401be 100644
> > --- a/drivers/pci/host/pci-dra7xx.c
> > +++ b/drivers/pci/host/pci-dra7xx.c
> > @@ -141,15 +141,15 @@ static void dra7xx_pcie_host_init(struct pcie_port 
> > *pp)
> >  {
> > dw_pcie_setup_rc(pp);
> >
> > -   if (pp->io_mod_base)
> > -   pp->io_mod_base &= CPU_TO_BUS_ADDR;
> > +   if (pp->io_base)
> > +   pp->io_base &= CPU_TO_BUS_ADDR;
> >
> > -   if (pp->mem_mod_base)
> > -   pp->mem_mod_base &= CPU_TO_BUS_ADDR;
> > +   if (pp->mem_base)
> > +   pp->mem_base &= CPU_TO_BUS_ADDR;
> >
> > -   if (pp->cfg0_mod_base) {
> > -   pp->cfg0_mod_base &= CPU_TO_BUS_ADDR;
> > -   pp->cfg1_mod_base &= CPU_TO_BUS_ADDR;
> > +   if (pp->cfg0_base) {
> > +   pp->cfg0_base &= CPU_TO_BUS_ADDR;
> > +   pp->cfg1_base &= CPU_TO_BUS_ADDR;
> > }
> >
> > dra7xx_pcie_establish_link(pp);
> > diff --git a/drivers/pci/host/pci-keystone-dw.c b/drivers/pci/host/pci-
> keystone-dw.c
> > index f34892e..b1e4135 100644
> > --- a/drivers/pci/host/pci-keystone-dw.c
> > +++ b/drivers/pci/host/pci-keystone-dw.c
> > @@ -327,7 +327,7 @@ static void ks_dw_pcie_clear_dbi_mode(void __iomem
> *reg_virt)
> >  void ks_dw_pcie_setup_rc_app_regs(struct keystone_pcie *ks_pcie)
> >  {
> > struct pcie_port *pp = &ks_pcie->pp;
> > -   u32 start = pp->mem.start, end = pp->mem.end;
> > +   u32 start = pp->mem->start, end = pp->mem->end;
> > int i, tr_size;
> >
> > /* Disable BARs for inbound access */
> > diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-
> designware.c
> > index c5d407c..e2d1898 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -11,6 +11,7 @@
> >   * published by the Free Software Foundation.
> >   */
> >
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -69,16 +70,7 @@
> >  #define PCIE_ATU_FUNC(x)   (((x) & 0x7) << 16)
> >  #define PCIE_ATU_UPPER_TARGET  0x91C
> >
> > -static struct hw_pci dw_pci;
> > -
> > -static unsigned long global_io_offset;
> > -
> > -static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys)
> > -{
> > -   BUG_ON(!sys->private_data);
> > -
> > -   return sys->private_data;
> > -}
> > +static struct pci_ops dw_pcie_ops;
> >
> >  int dw_pcie_cfg_read(void __iomem *addr, int where, int size, u32 *val)
> >  {
> > @@ 

Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data

[Nathan Sullivan]

On Thu, Aug 27, 2015 at 01:11:30PM +0530, punnaiah choudary kalluri wrote:
> Hi,
> 
> On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen  wrote:
> > On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep subbaraya wrote:
> >> Hi,
> >>
> >>
> >> On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan  
> >> wrote:
> >> > The Xilinx Zynq udc does not need the CI_HDRC_DISABLE_STREAMING flag,
> >> > unlike the default platform data.  Add platform data specific to the
> >> > Zynq udc.
> >> >
> >> > Based on a patch by the same name from the Xilinx vendor tree.
> >>
> >> I am that Xilinx guy who sent this patch :). It is in Xilinx tree as
> >> temporary fix and
> >> I did not debug further why UDC works only when streaming is enabled.
> >> Probably this is right time to post my question here.
> >> I was expecting like:
> >> Streaming disabled - both low bandwidth and high bandwidth systems
> >> should work fine
> >> Streaming enabled - only for high bandwidth systems
> >> but this is not the case, Zynq UDC works only when Streaming is enabled.
> >> Please correct me if I am wrong.
> >
> > You are right, stream mode disabled should work at anytime.
> > It is so strange why zynq UDC only works when stream mode is enabled.
> 
> I am referring the section 8.5.2 in Synopsys usb 2.0 HS controllervDoc 2.20a,
>  this is what it says about SDIS (streaming mode disable option)
> 
> Before activating this mode, the user must check if the TX latency
> buffers per endpoint are able to
> accommodate at least one entire maximum size packet. The RX buffer
> size must, at least, double the TX
> buffer size per endpoint. To optimize the stream disable performance,
> system bus burst must be set as high
> as possible.
> When the stream disable mode is used, the burst size (VUSB_HS_RX_BURST
> and VUSB_HS_TX_BURST)
> must be a integer sub-multiple of the latency buffer size
> (VUSB_HS_RX_DEPTH for RX buffer and
> VUSB_HS_TX_CHAN for the TX buffer). If this is not respected the
> controller will not work properly in stream
> disable mode.
> The stream disable mode should just be used in situations where the
> available system bandwidth is low or the
> system bus access latency is high, in order to avoid underruns and
> overruns in the latency buffers. This works
> for all types of endpoints, except for ISO endpoints.
> Such a system can't ensure the real time support that the ISO
> endpoints require, so the ISO endpoints are not
> supported when the SDIS bit is set.
> 
> Definitely we need to root cause why disable streaming mode is not
> working for zynq but from controller spec
> point of view it is possible that controller not work properly in
> stream disable mode.
> 
> Regards,
> Punnaiah
> 

Maybe the burst size isn't set correctly by default?  It does say the controller
won't work correctly with stream disable set and an invalid burst size.  Looks
like TX and RX burst both default to 16, per the Zynq manual.

With the stream disable bit set, the behvior we see on our hardware is
that priming just stops, with an outstanding transfer in memory marked
active in the status field by the controller.  This happens at random, even 
when doing single transfers at a time like with g_ether set to have a queue
size of 1.  With SDIS clear everything works great.  Given that the Zynq is not
bandwidth constrained, it seems like SDIS clear should be the default.

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

Re: [PATCH v7 8/8] clocksource: simplify ACPI code in arm_arch_timer.c

[Fu Wei]

Hi Thomas, Hanjun

On 27 August 2015 at 21:40, Thomas Gleixner  wrote:
> On Thu, 27 Aug 2015, Hanjun Guo wrote:
>> > [1]: https://lkml.org/lkml/2015/7/29/236
>> >
>> > If that is ok with you, we will introduce similar DECLARE_ thing
>> > for clock declare.
>
> Yes.

Thanks

>
>> Or we can drop this patch from this patch set, and clean up this
>> patch when the ACPI_DECLARE() infrastructure is ready for upstream.
>
> Works either way. I just noticed that hard coded init thing and
> decided to rant about it :)

OK, good idea, this patch will be improve by DECLARE_ thing, then upstream.
drop this from this patchset.

Great thanks for your help


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



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "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: Re: [v4,1/6] mmc: dt: add DT binding for big endian controller

[Ulf Hansson]

[...]

>
> What I had in mind is replacing in_be32() with a esdhc_ops->readl() in this 
> function. And the esdhc_ops->readl() would be assigned at the beginning 
> according endian.
>
> static u32 esdhc_readl(struct sdhci_host *host, int reg)
> {
> u32 ret;
>
> ret = in_be32(host->ioaddr + reg);
> /*
>  * The bit of ADMA flag in eSDHC is not compatible with standard
>  * SDHC register, so set fake flag SDHCI_CAN_DO_ADMA2 when ADMA is
>  * supported by eSDHC.
>  * And for many FSL eSDHC controller, the reset value of field
>  * SDHCI_CAN_DO_ADMA1 is one, but some of them can't support ADMA,
>  * only these vendor version is greater than 2.2/0x12 support ADMA.
>  * For FSL eSDHC, must aligned 4-byte, so use 0xFC to read the
>  * the verdor version number, oxFE is SDHCI_HOST_VERSION.
>  */
> if ((reg == SDHCI_CAPABILITIES) && (ret & SDHCI_CAN_DO_ADMA1)) {
> u32 tmp = in_be32(host->ioaddr + SDHCI_SLOT_INT_STATUS);
> tmp = (tmp & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
> if (tmp > VENDOR_V_22)
> ret |= SDHCI_CAN_DO_ADMA2;
> }
>
> return ret;
> }
>
> The LE and BE accessors could be defined in sdhci-esdhc.h for 
> esdhc_ops->readl() as below.
> static u32 esdhc_be32bs_readl(struct sdhci_host *host, int reg)
> {
>return ioread32be(host->ioaddr + reg);
> }
>
> static u32 esdhc_le32bs_readl(struct sdhci_host *host, int reg)
> {
>return ioread32(host->ioaddr + reg);
> }
>
> Do you think it is ok for you?

It becomes a bit "hacky", but currently I can't think of a better solution.

>
>
> Or Maybe there is another method, use conditional compilation. The previous 
> method would delete the MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER to use 
> accessors defined in sdhci-esdhc.h, and add dependency of ARM. This method 
> could use 'select  if ' to compile LE or BE accessors 
> according ARCH.

I don't really follow your suggestion.

Isn't the problem that you need the
MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER for configurations and for
some you don't? More precisely, for those where you don't you would
rather just use the regulator ioread* functions since those will
internally deal with the endianess in runtime?

If you can make these decisions at compile time an depending of the
ARCH - I believe I would be fine with that as well.

[...]

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

Re: [PATCH v7 8/8] clocksource: simplify ACPI code in arm_arch_timer.c

[Thomas Gleixner]

On Thu, 27 Aug 2015, Hanjun Guo wrote:
> > [1]: https://lkml.org/lkml/2015/7/29/236
> > 
> > If that is ok with you, we will introduce similar DECLARE_ thing
> > for clock declare.

Yes.
 
> Or we can drop this patch from this patch set, and clean up this
> patch when the ACPI_DECLARE() infrastructure is ready for upstream.

Works either way. I just noticed that hard coded init thing and
decided to rant about it :)

Thanks,

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

Re: [PATCH v7 8/8] clocksource: simplify ACPI code in arm_arch_timer.c

[Hanjun Guo]

On 08/27/2015 08:28 PM, Hanjun Guo wrote:

On 08/27/2015 08:08 PM, Thomas Gleixner wrote:

On Thu, 27 Aug 2015, Hanjun Guo wrote:

On 08/26/2015 03:17 AM, Thomas Gleixner wrote:

On Wed, 26 Aug 2015, Fu Wei wrote:

   /* Initialize per-processor generic timer */
-static int __init arch_timer_acpi_init(struct acpi_table_header
*table)
+void __init arch_timer_acpi_init(void)
   {


And how is that supposed to work when we have next generation CPUs
which implement a different timer? You break multisystem kernels that
way.


Sorry, I think I missed some context here that I don't understand
why the code here will break multisystem kernels? I'm trying to
understand the problem here and update the code :)



yes, you are right, If there is a  next generation CPUs  which
implement a different timer, (maybe) this driver can not work.
we may need a new timer driver.

But,
(1) for now,  aarch64  core always has the arch timer(this timer is
part of aarch64 architecture).
and the existing code make  ARM64 kernel "select ARM_ARCH_TIMER "
(2) GTDT is designed for generic timer, so in this call "
arch_timer_acpi_init"  we  parse the gtdt info.
(3) once we have a ARM64 CPUs which implement a different timer, we
may need to select a right timer in the config stage.
and this timer may not be described in GTDT.  So we can implement
another arch_timer_acpi_init by that time in new timer driver..
if the new time still uses GTDT(or new version GTDT), we may need to
update gtdt.c for new timer by that time.


That's simply wrong. You want to build kernels which run on both cpus
and the selection of the timer happens at runtime depending on the
ACPI info. We do the same thing with device tree.


I think the code can do that if I understand correctly. The code for
now is that we only support arch timer on ARM64, and this patch set
is adding SBSA watchdog timer support which need same function in
arch timer, so we move that function to common place.

We will load the driver (arch timer, memory mapped timer) when the
ACPI table defines them, which when new timer is coming, that will
defined in the ACPI table and load the driver as needed.

Please correct me if I misse something, thanks.


arch_timer_acpi_init() is called from the architecture boot code. So
how is that supposed to work with different timers?

Are you going to have bla_timer_acpi_init() and foo_timer_acpi_init()
calls as well?

Why not having a something like DT has: DECLARE_

and the arch_timer_acpi_init() using that to figure out which of the
timers to initialize.


Ah, ok, I can fully understand you now, thanks for your patience.

Yes, I agree with you, so this is not a problem for this patch, but
for the code implementation of previous code. Actually we are on the
road to do as you suggested, we introduced something like
#define ACPI_DECLARE(table, name, table_id, subtable, data, fn) [1]
in the GICv3 and GIC self probe patch set, and I said that
infrastructure can be used as clock declare too, we just trying
to not add such dependence on that patch set (it's still on discussion),

[1]: https://lkml.org/lkml/2015/7/29/236

If that is ok with you, we will introduce similar DECLARE_ thing
for clock declare.


Or we can drop this patch from this patch set, and clean up this
patch when the ACPI_DECLARE() infrastructure is ready for upstream.

Thanks
Hanjun
--
To unsubscribe from this list: send the line "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: Re: [v4,1/6] mmc: dt: add DT binding for big endian controller

[Ulf Hansson]

On 27 August 2015 at 15:34, Ulf Hansson  wrote:
> [...]
>
>>
>> What I had in mind is replacing in_be32() with a esdhc_ops->readl() in this 
>> function. And the esdhc_ops->readl() would be assigned at the beginning 
>> according endian.
>>
>> static u32 esdhc_readl(struct sdhci_host *host, int reg)
>> {
>> u32 ret;
>>
>> ret = in_be32(host->ioaddr + reg);
>> /*
>>  * The bit of ADMA flag in eSDHC is not compatible with standard
>>  * SDHC register, so set fake flag SDHCI_CAN_DO_ADMA2 when ADMA is
>>  * supported by eSDHC.
>>  * And for many FSL eSDHC controller, the reset value of field
>>  * SDHCI_CAN_DO_ADMA1 is one, but some of them can't support ADMA,
>>  * only these vendor version is greater than 2.2/0x12 support ADMA.
>>  * For FSL eSDHC, must aligned 4-byte, so use 0xFC to read the
>>  * the verdor version number, oxFE is SDHCI_HOST_VERSION.
>>  */
>> if ((reg == SDHCI_CAPABILITIES) && (ret & SDHCI_CAN_DO_ADMA1)) {
>> u32 tmp = in_be32(host->ioaddr + SDHCI_SLOT_INT_STATUS);
>> tmp = (tmp & SDHCI_VENDOR_VER_MASK) >> 
>> SDHCI_VENDOR_VER_SHIFT;
>> if (tmp > VENDOR_V_22)
>> ret |= SDHCI_CAN_DO_ADMA2;
>> }
>>
>> return ret;
>> }
>>
>> The LE and BE accessors could be defined in sdhci-esdhc.h for 
>> esdhc_ops->readl() as below.
>> static u32 esdhc_be32bs_readl(struct sdhci_host *host, int reg)
>> {
>>return ioread32be(host->ioaddr + reg);
>> }
>>
>> static u32 esdhc_le32bs_readl(struct sdhci_host *host, int reg)
>> {
>>return ioread32(host->ioaddr + reg);
>> }
>>
>> Do you think it is ok for you?
>
> It becomes a bit "hacky", but currently I can't think of a better solution.
>
>>
>>
>> Or Maybe there is another method, use conditional compilation. The previous 
>> method would delete the MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER to use 
>> accessors defined in sdhci-esdhc.h, and add dependency of ARM. This method 
>> could use 'select  if ' to compile LE or BE accessors 
>> according ARCH.
>
> I don't really follow your suggestion.
>
> Isn't the problem that you need the
> MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER for configurations and for
> some you don't? More precisely, for those where you don't you would
> rather just use the regulator ioread* functions since those will

/s/regulator/regular

> internally deal with the endianess in runtime?
>
> If you can make these decisions at compile time an depending of the
> ARCH - I believe I would be fine with that as well.
>
> [...]
>
> Kind regards
> Uffe
--
To unsubscribe from this list: send the line "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] spi: mediatek: fix SPI_CMD_PAUSE_IE macro error

[Leilk Liu]

enable pause interrupt should use SPI_CMD_PAUSE_IE MACRO,
so fix it.

Signed-off-by: Leilk Liu 
---
 drivers/spi/spi-mt65xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index eaadc7e..d882261 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -158,7 +158,7 @@ static void mtk_spi_config(struct mtk_spi *mdata,
 #endif
 
/* set finish and pause interrupt always enable */
-   reg_val |= SPI_CMD_FINISH_IE | SPI_CMD_PAUSE_EN;
+   reg_val |= SPI_CMD_FINISH_IE | SPI_CMD_PAUSE_IE;
 
/* disable dma mode */
reg_val &= ~(SPI_CMD_TX_DMA | SPI_CMD_RX_DMA);
-- 
1.8.1.1.dirty

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

Re: [PATCH v8 3/6] PCI: designware: Add ARM64 support

[Gabriel Fernandez]

Hi Zhou,

You can add my Tested-by: Gabriel Fernandez 

I tested your patchset with a STMicroelectronics PCIe controller.
This controller is based on designware PCIe driver and works on ARM32.

Please find my patchset here:
http://www.spinics.net/lists/kernel/msg2064266.html

Best Regards.

Gabriel.

On 25 August 2015 at 11:58, Zhou Wang  wrote:
> This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
> function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
> move related operations to dw_pcie_host_init.
>
> This patch also try to use of_pci_get_host_bridge_resources for ARM32 and 
> ARM64
> according to the suggestion for Gabriele[1]
>
> Finally this patch reverts commit f4c55c5a3f7f "PCI: designware: Program ATU
> with untranslated address" based on 1/6 in this series. we delete *_mod_base 
> in
> pcie-designware. This was discussed in [2]
>
> I have compiled the driver with multi_v7_defconfig. However, I don't have
> ARM32 PCIe related board to do test. It will be appreciated if someone could
> help to test it.
>
> Signed-off-by: Zhou Wang 
> Signed-off-by: Gabriele Paoloni 
> Signed-off-by: Arnd Bergmann 
> Tested-By: James Morse 
>
> [1] http://www.spinics.net/lists/linux-pci/msg42194.html
> [2] http://www.spinics.net/lists/arm-kernel/msg436779.html
> ---
>  drivers/pci/host/pci-dra7xx.c  |  14 +--
>  drivers/pci/host/pci-keystone-dw.c |   2 +-
>  drivers/pci/host/pcie-designware.c | 230 
> +
>  drivers/pci/host/pcie-designware.h |  14 +--
>  4 files changed, 90 insertions(+), 170 deletions(-)
>
> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> index 18ae7ff..ac401be 100644
> --- a/drivers/pci/host/pci-dra7xx.c
> +++ b/drivers/pci/host/pci-dra7xx.c
> @@ -141,15 +141,15 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
>  {
> dw_pcie_setup_rc(pp);
>
> -   if (pp->io_mod_base)
> -   pp->io_mod_base &= CPU_TO_BUS_ADDR;
> +   if (pp->io_base)
> +   pp->io_base &= CPU_TO_BUS_ADDR;
>
> -   if (pp->mem_mod_base)
> -   pp->mem_mod_base &= CPU_TO_BUS_ADDR;
> +   if (pp->mem_base)
> +   pp->mem_base &= CPU_TO_BUS_ADDR;
>
> -   if (pp->cfg0_mod_base) {
> -   pp->cfg0_mod_base &= CPU_TO_BUS_ADDR;
> -   pp->cfg1_mod_base &= CPU_TO_BUS_ADDR;
> +   if (pp->cfg0_base) {
> +   pp->cfg0_base &= CPU_TO_BUS_ADDR;
> +   pp->cfg1_base &= CPU_TO_BUS_ADDR;
> }
>
> dra7xx_pcie_establish_link(pp);
> diff --git a/drivers/pci/host/pci-keystone-dw.c 
> b/drivers/pci/host/pci-keystone-dw.c
> index f34892e..b1e4135 100644
> --- a/drivers/pci/host/pci-keystone-dw.c
> +++ b/drivers/pci/host/pci-keystone-dw.c
> @@ -327,7 +327,7 @@ static void ks_dw_pcie_clear_dbi_mode(void __iomem 
> *reg_virt)
>  void ks_dw_pcie_setup_rc_app_regs(struct keystone_pcie *ks_pcie)
>  {
> struct pcie_port *pp = &ks_pcie->pp;
> -   u32 start = pp->mem.start, end = pp->mem.end;
> +   u32 start = pp->mem->start, end = pp->mem->end;
> int i, tr_size;
>
> /* Disable BARs for inbound access */
> diff --git a/drivers/pci/host/pcie-designware.c 
> b/drivers/pci/host/pcie-designware.c
> index c5d407c..e2d1898 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -11,6 +11,7 @@
>   * published by the Free Software Foundation.
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -69,16 +70,7 @@
>  #define PCIE_ATU_FUNC(x)   (((x) & 0x7) << 16)
>  #define PCIE_ATU_UPPER_TARGET  0x91C
>
> -static struct hw_pci dw_pci;
> -
> -static unsigned long global_io_offset;
> -
> -static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys)
> -{
> -   BUG_ON(!sys->private_data);
> -
> -   return sys->private_data;
> -}
> +static struct pci_ops dw_pcie_ops;
>
>  int dw_pcie_cfg_read(void __iomem *addr, int where, int size, u32 *val)
>  {
> @@ -255,7 +247,7 @@ static void dw_pcie_msi_set_irq(struct pcie_port *pp, int 
> irq)
>  static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos)
>  {
> int irq, pos0, i;
> -   struct pcie_port *pp = sys_to_pcie(desc->dev->bus->sysdata);
> +   struct pcie_port *pp = desc->dev->bus->sysdata;
>
> pos0 = bitmap_find_free_region(pp->msi_irq_in_use, MAX_MSI_IRQS,
>order_base_2(no_irqs));
> @@ -298,7 +290,7 @@ static int dw_msi_setup_irq(struct msi_controller *chip, 
> struct pci_dev *pdev,
>  {
> int irq, pos;
> struct msi_msg msg;
> -   struct pcie_port *pp = sys_to_pcie(pdev->bus->sysdata);
> +   struct pcie_port *pp = pdev->bus->sysdata;
>
> if (desc->msi_attrib.is_msix)
> return -EINVAL;
> @@ -327,7 +319,7 @@ static void dw_msi_teardown_irq(struct msi_controller 
> *chip, unsigned int irq)
>  {
> struct irq_data *data = irq_get_irq_d

[PATCH v4 1/4] ARM: STi: Kconfig update for PCIe support

[Gabriel Fernandez]

Update Kconfig:
- MIGHT_HAVE_PCI
- PCI_DOMAINS

Signed-off-by: Fabrice Gasnier 
---
 arch/arm/mach-sti/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
index 125865d..5f99e93 100644
--- a/arch/arm/mach-sti/Kconfig
+++ b/arch/arm/mach-sti/Kconfig
@@ -9,6 +9,8 @@ menuconfig ARCH_STI
select ARCH_HAS_RESET_CONTROLLER
select HAVE_ARM_SCU if SMP
select ARCH_REQUIRE_GPIOLIB
+   select PCI_DOMAINS if PCI
+   select MIGHT_HAVE_PCI
select ARM_ERRATA_754322
select ARM_ERRATA_764369 if SMP
select ARM_ERRATA_775420
-- 
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 2/4] PCI: st: Add Device Tree bindings for sti pcie

[Gabriel Fernandez]

sti pcie is built around a Synopsis Designware PCIe IP.

Signed-off-by: Fabrice Gasnier 
Signed-off-by: Gabriel Fernandez 
---
 Documentation/devicetree/bindings/pci/st-pcie.txt | 53 +++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/st-pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/st-pcie.txt 
b/Documentation/devicetree/bindings/pci/st-pcie.txt
new file mode 100644
index 000..25fcab3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/st-pcie.txt
@@ -0,0 +1,53 @@
+STMicroelectronics STi PCIe controller
+
+This PCIe host controller is based on the Synopsis Designware PCIe IP
+and thus inherits all the common properties defined in designware-pcie.txt.
+
+Required properties:
+ - compatible: "st,stih407-pcie"
+ - reg: base address and length of the pcie controller, mem-window address
+   and length available to the controller.
+ - interrupts: A list of interrupt outputs of the controller. Must contain an
+   entry for each entry in the interrupt-names property.
+ - interrupt-names: Should be "msi". STi interrupt that is asserted when an
+   MSI is received.
+ - st,syscfg : should be a phandle of the syscfg node. Also contains syscfg
+   offset for IP configuration.
+ - resets, reset-names: the power-down and soft-reset lines of PCIe IP.
+   Associated names must be "powerdown" and "softreset".
+ - phys, phy-names: the phandle for the PHY device.
+   Associated name must be "pcie"
+
+Optional properties:
+ - reset-gpio: a GPIO spec to define which pin is connected to the bus reset.
+
+Example:
+
+pcie0: pcie@9b0 {
+   compatible = "st,pcie", "snps,dw-pcie";
+   device_type = "pci";
+   reg = <0x09b0 0x4000>,  /* dbi cntrl registers */
+ <0x2fff 0x0001>,  /* configuration space */
+ <0x4000 0x8000>;  /* lmi mem window */
+   reg-names = "dbi", "config", "mem-window";
+   st,syscfg = <&syscfg_core 0xd8 0xe0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   ranges = <0x8200 0 0x2000 0x2000 0 0x0FFF>; /* 
non-prefetchable memory */
+   num-lanes = <1>;
+   interrupts = ;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 7>;
+   interrupt-map = <0 0 0 1 &intc GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>, /* INT 
A */
+   <0 0 0 2 &intc GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>, /* INT 
B */
+   <0 0 0 3 &intc GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>, /* INT 
C */
+   <0 0 0 4 &intc GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>; /* INT 
D */
+
+   resets = <&powerdown STIH407_PCIE0_POWERDOWN>,
+<&softreset STIH407_PCIE0_SOFTRESET>;
+   reset-names = "powerdown",
+ "softreset";
+   phys = <&phy_port0 PHY_TYPE_PCIE>;
+   phy-names = "pcie";
+};
-- 
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 3/4] PCI: st: Provide support for the sti PCIe controller

[Gabriel Fernandez]

sti pcie is built around a Synopsis Designware PCIe IP.

Signed-off-by: Fabrice Gasnier 
Signed-off-by: Gabriel Fernandez 
---
 drivers/pci/host/Kconfig  |   9 +
 drivers/pci/host/Makefile |   1 +
 drivers/pci/host/pci-st.c | 583 ++
 3 files changed, 593 insertions(+)
 create mode 100644 drivers/pci/host/pci-st.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index c132bdd..db56b8f 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -145,4 +145,13 @@ config PCIE_IPROC_BCMA
  Say Y here if you want to use the Broadcom iProc PCIe controller
  through the BCMA bus interface
 
+config PCI_ST
+   bool "ST PCIe controller"
+   depends on ARCH_STI || (ARM && COMPILE_TEST)
+   select PCIE_DW
+   help
+ Enable PCIe controller support on ST Socs. This controller is based
+ on Designware hardware and therefore the driver re-uses the
+ Designware core functions to implement the driver.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..c4024fa 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
 obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
 obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
+obj-$(CONFIG_PCI_ST) += pci-st.o
diff --git a/drivers/pci/host/pci-st.c b/drivers/pci/host/pci-st.c
new file mode 100644
index 000..0e7aaa2
--- /dev/null
+++ b/drivers/pci/host/pci-st.c
@@ -0,0 +1,583 @@
+/*
+ * Copyright (C) 2014 STMicroelectronics
+ *
+ * STMicroelectronics PCI express Driver for sti SoCs.
+ * ST PCIe IPs are built around a Synopsys IP Core.
+ *
+ * Author: Fabrice Gasnier 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pcie-designware.h"
+
+#define TRANSLATION_CONTROL0x900
+/* Controls if area is inclusive or exclusive */
+#define RC_PASS_ADDR_RANGE BIT(1)
+
+/* Base of area reserved for config accesses. Fixed size of 64K. */
+#define CFG_BASE_ADDRESS   0x92c
+#define CFG_REGION_SIZE65536
+#define CFG_SPACE1_OFFSET  0x1000
+
+/* First 4K of config space has this BDF (bus,device,function) */
+#define FUNC0_BDF_NUM  0x930
+
+/* Mem regions */
+#define IN0_MEM_ADDR_START 0x964
+#define IN0_MEM_ADDR_LIMIT 0x968
+#define IN1_MEM_ADDR_START 0x974
+#define IN1_MEM_ADDR_LIMIT 0x978
+
+/* This actually contains the LTSSM state machine state */
+#define PORT_LOGIC_DEBUG_REG_0 0x728
+
+/* LTSSM state machine values  */
+#define DEBUG_REG_0_LTSSM_MASK 0x1f
+#define S_DETECT_QUIET 0x00
+#define S_DETECT_ACT   0x01
+#define S_POLL_ACTIVE  0x02
+#define S_POLL_COMPLIANCE  0x03
+#define S_POLL_CONFIG  0x04
+#define S_PRE_DETECT_QUIET 0x05
+#define S_DETECT_WAIT  0x06
+#define S_CFG_LINKWD_START 0x07
+#define S_CFG_LINKWD_ACEPT 0x08
+#define S_CFG_LANENUM_WAIT 0x09
+#define S_CFG_LANENUM_ACEPT0x0A
+#define S_CFG_COMPLETE 0x0B
+#define S_CFG_IDLE 0x0C
+#define S_RCVRY_LOCK   0x0D
+#define S_RCVRY_SPEED  0x0E
+#define S_RCVRY_RCVRCFG0x0F
+#define S_RCVRY_IDLE   0x10
+#define S_L0   0x11
+#define S_L0S  0x12
+#define S_L123_SEND_EIDLE  0x13
+#define S_L1_IDLE  0x14
+#define S_L2_IDLE  0x15
+#define S_L2_WAKE  0x16
+#define S_DISABLED_ENTRY   0x17
+#define S_DISABLED_IDLE0x18
+#define S_DISABLED 0x19
+#define S_LPBK_ENTRY   0x1A
+#define S_LPBK_ACTIVE  0x1B
+#define S_LPBK_EXIT0x1C
+#define S_LPBK_EXIT_TIMEOUT0x1D
+#define S_HOT_RESET_ENTRY  0x1E
+#define S_HOT_RESET0x1F
+
+/* syscfg bits */
+#define PCIE_SYS_INT   BIT(5)
+#define PCIE_APP_REQ_RETRY_EN  BIT(3)
+#define PCIE_APP_LTSSM_ENABLE  BIT(2)
+#define PCIE_APP_INIT_RST  BIT(1)
+#define PCIE_DEVICE_TYPE   BIT(0)
+#define PCIE_DEFAULT_VAL   PCIE_DEVICE_TYPE
+
+/* Time to wait between testing the link in msecs (hardware poll interval) */
+#define LINK_LOOP_DELAY_MS 1
+/* Total amount of time to wait for the link to come up in msecs */

[PATCH v4 4/4] MAINTAINERS: Add pci-st.c to ARCH/STI architecture

[Gabriel Fernandez]

This patch adds the pci-st.c pci driver found on STMicroelectronics
SoC's into the STI arch section of the maintainers file.

Signed-off-by: Gabriel Fernandez 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8133cef..af5034f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1506,6 +1506,7 @@ F:drivers/clocksource/arm_global_timer.c
 F: drivers/i2c/busses/i2c-st.c
 F: drivers/media/rc/st_rc.c
 F: drivers/mmc/host/sdhci-st.c
+F: drivers/pci/host/pci-st.c
 F: drivers/phy/phy-miphy28lp.c
 F: drivers/phy/phy-miphy365x.c
 F: drivers/phy/phy-stih407-usb.c
-- 
1.9.1

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

[PATCH v4 0/4] PCI: st: provide support for dw pcie

[Gabriel Fernandez]

This patchset is based on v4.2-rc1 and is based on 
[PATCH v8 0/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05
patchset from Zhou Wang.

Changes in v4:
 - Remove pci: designware: remove my pci_common_init_dev() patch and
use [PATCH v8 3/6] PCI: designware: Add ARM64 support instead.
This patch is a good solution for me to disable IO support.
 - add __init to st_pcie_probe() and use module_init() instead
device_initcall() to prevent the probe function from being
deferred and to prevent module unloading.

Changes in v3:
 - Remove power management functions (was not fully tested)
 - Remove configuration space range from dt binding
 - Remove pci_common_init_dev() call in pcie-designware.c to avoid 
   default IO space declaration. 

Changes in v2:
 - comestic corrections in device tree binding
 - add pci-st.c into MAINTAINERS
 - remove st_pcie_ops structure to avoid another level of indirection
 - remove nasty busy-loop
 - remove useless test using virt_to_phys()
 - move disable io support into dw-pcie driver

I don't change the st_pcie_abort_handler() function because abort handling
is masked during boot.


This patch-set introduces a STMicroelectronics PCIe controller.
It's based on designware PCIe driver.

Gabriel Fernandez (4):
  ARM: STi: Kconfig update for PCIe support
  PCI: st: Add Device Tree bindings for sti pcie
  PCI: st: Provide support for the sti PCIe controller
  MAINTAINERS: Add pci-st.c to ARCH/STI architecture

 Documentation/devicetree/bindings/pci/st-pcie.txt |  53 ++
 MAINTAINERS   |   1 +
 arch/arm/mach-sti/Kconfig |   2 +
 drivers/pci/host/Kconfig  |   9 +
 drivers/pci/host/Makefile |   1 +
 drivers/pci/host/pci-st.c | 583 ++
 6 files changed, 649 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/st-pcie.txt
 create mode 100644 drivers/pci/host/pci-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

[PATCH v2 1/5] ARM: DT: STi: stihxxx-b2120: Add pulse-width properties to ssc2 & ssc3

[Peter Griffin]

Adding these properties makes the I2C bus to the demodulators much
more reliable, and we no longer suffer from I2C errors when tuning.

Signed-off-by: Peter Griffin 
---
 arch/arm/boot/dts/stihxxx-b2120.dtsi | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi 
b/arch/arm/boot/dts/stihxxx-b2120.dtsi
index f589fe4..62994ae 100644
--- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
+++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
@@ -27,12 +27,18 @@
};
};
 
-   i2c@9842000 {
+   ssc2: i2c@9842000 {
status = "okay";
+   clock-frequency = <10>;
+   st,i2c-min-scl-pulse-width-us = <0>;
+   st,i2c-min-sda-pulse-width-us = <5>;
};
 
-   i2c@9843000 {
+   ssc3: i2c@9843000 {
status = "okay";
+   clock-frequency = <10>;
+   st,i2c-min-scl-pulse-width-us = <0>;
+   st,i2c-min-sda-pulse-width-us = <5>;
};
 
i2c@9844000 {
-- 
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