[PATCH v2] arm64: dts: add all hi6220 i2c nodes

[Xinwei Kong]

This patch adds all I2C nodes for the Hi6220 SoC. This hi6220 Soc
use this I2C IP of Synopsys Designware for HiKey board.

Signed-off-by: Xinwei Kong 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 37 +++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 82d2488..85d4a8b 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -208,5 +208,42 @@
clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
+
+   i2c0: i2c@f710 {
+   compatible = "snps,designware-i2c";
+   reg = <0x0 0xf710 0x0 0x1000>;
+   interrupts = <0 44 4>;
+   clocks = <&sys_ctrl HI6220_I2C0_CLK>;
+   clock-names = "clk_i2c0";
+   i2c-sda-hold-time-ns = <300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c0_pmx_func &i2c0_cfg_func>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@f7101000 {
+   compatible = "snps,designware-i2c";
+   reg = <0x0 0xf7101000 0x0 0x1000>;
+   interrupts = <0 45 4>;
+   clocks = <&sys_ctrl HI6220_I2C1_CLK>;
+   clock-names = "clk_i2c1";
+   i2c-sda-hold-time-ns = <300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c1_pmx_func &i2c1_cfg_func>;
+   status = "disabled";
+   };
+
+   i2c2: i2c@f7102000 {
+   compatible = "snps,designware-i2c";
+   reg = <0x0 0xf7102000 0x0 0x1000>;
+   interrupts = <0 46 4>;
+   clocks = <&sys_ctrl HI6220_I2C2_CLK>;
+   clock-names = "clk_i2c2";
+   i2c-sda-hold-time-ns = <300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c2_pmx_func &i2c2_cfg_func>;
+   status = "disabled";
+   };
+
};
 };
-- 
1.9.1


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

[PATCH v5 06/11] Documentation: dt-bindings: Add bindings for DW MIPI DSI

[Chris Zhong]

From: Liu Ying 

This patch adds device tree bindings for Synopsys DesignWare MIPI DSI
host controller DRM bridge driver.

Signed-off-by: Liu Ying 
Signed-off-by: Chris Zhong 
Acked-by: Rob Herring 

---

Changes in v5: None
Changes in v4:
- remove the cfg clk
- remove gpr property from example, since it is noused now.
- add the description about ports

Changes in v3:
- move the dw_mipi_dsi.txt to Documentation/devicetree/bindings/display/bridge

Changes in v2: None

 .../bindings/display/bridge/dw_mipi_dsi.txt| 74 ++
 1 file changed, 74 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt 
b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
new file mode 100644
index 000..2e1d197
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
@@ -0,0 +1,74 @@
+Device-Tree bindings for Synopsys DesignWare MIPI DSI host controller
+
+The controller is a digital core that implements all protocol functions
+defined in the MIPI DSI specification, providing an interface between
+the system and the MIPI DPHY, and allowing communication with a MIPI DSI
+compliant display.
+
+Required properties:
+ - #address-cells: Should be <1>.
+ - #size-cells: Should be <0>.
+ - compatible: The first compatible string should be "fsl,imx6q-mipi-dsi"
+   for i.MX6q/sdl SoCs.  For other SoCs, please refer to their specific
+   device tree binding documentations.  A common compatible string
+   "snps,dw-mipi-dsi" should be appended for all SoCs.
+ - reg: Represent the physical address range of the controller.
+ - interrupts: Represent the controller's interrupt to the CPU(s).
+ - clocks, clock-names: Phandles to the controller's pll reference
+   clock(ref) and APB clock(pclk), as described in [1].
+ - port@[X]: SoC specific port nodes with endpoint definitions as defined
+   in Documentation/devicetree/bindings/media/video-interfaces.txt,
+   please refer to the SoC specific binding document:
+* 
Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi-rockchip.txt
+
+
+For more required properties, please refer to relevant device tree binding
+documentations which describe the controller embedded in specific SoCs.
+
+Required sub-nodes:
+ - A node to represent a DSI peripheral as described in [2].
+
+For more required sub-nodes, please refer to relevant device tree binding
+documentations which describe the controller embedded in specific SoCs.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+
+example:
+   mipi_dsi: mipi@021e {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi";
+   reg = <0x021e 0x4000>;
+   interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks IMX6QDL_CLK_MIPI_CORE_CFG>,
+<&clks IMX6QDL_CLK_MIPI_IPG>;
+   clock-names = "ref", "pclk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   mipi_mux_0: endpoint {
+   remote-endpoint = <&ipu1_di0_mipi>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   mipi_mux_1: endpoint {
+   remote-endpoint = <&ipu1_di1_mipi>;
+   };
+   };
+   };
+
+   panel {
+   compatible = "truly,tft480800-16-e-dsi";
+   reg = <0>;
+   /* ... */
+   };
+   };
-- 
2.6.3

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

[PATCH v5 11/11] ARM: dts: rockchip: add support mipi panel tv080wum-nl0 for rk3288-evb

[Chris Zhong]

This tv080wum-nl0 panel is a mipi panel, it can use in MIPI_TX socket
of rk3288 evb board.

Signed-off-by: Chris Zhong 

---

Changes in v5:
- add a blank line befor lcd_en

Changes in v4: None
Changes in v3: None
Changes in v2: None

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

diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi 
b/arch/arm/boot/dts/rk3288-evb.dtsi
index f6d2e78..2014992 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -47,7 +47,7 @@
reg = <0x0 0x8000>;
};
 
-   backlight {
+   backlight: backlight {
compatible = "pwm-backlight";
brightness-levels = <
  0   1   2   3   4   5   6   7
@@ -177,6 +177,20 @@
status = "okay";
 };
 
+&mipi_dsi {
+   status = "okay";
+   panel {
+   compatible ="boe,tv080wum-nl0";
+   reg = <0>;
+
+   enable-gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&lcd_en>;
+   backlight = <&backlight>;
+   status = "okay";
+   };
+};
+
 &sdmmc {
bus-width = <4>;
cap-mmc-highspeed;
@@ -247,6 +261,10 @@
bl_en: bl-en {
rockchip,pins = <7 2 RK_FUNC_GPIO &pcfg_pull_none>;
};
+
+   lcd_en: lcd-en {
+   rockchip,pins = <7 3 RK_FUNC_GPIO &pcfg_pull_none>;
+   };
};
 
buttons {
-- 
2.6.3

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

[PATCH v5 09/11] Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver

[Chris Zhong]

add device tree bindings for rk3288 specific Synopsys DW MIPI DSI driver

Signed-off-by: Chris Zhong 
Acked-by: Rob Herring 

---

Changes in v5: None
Changes in v4: None
Changes in v3:
- move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/

Changes in v2: None

 .../display/rockchip/dw_mipi_dsi_rockchip.txt  | 56 ++
 1 file changed, 56 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
new file mode 100644
index 000..acd9ec9
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -0,0 +1,56 @@
+Rockchip specific extensions to the Synopsys Designware MIPI DSI
+
+
+Required properties:
+- compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi".
+- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
+- ports: contain a port node with endpoint definitions as defined in [1].
+  For vopb,set the reg = <0> and set the reg = <1> for vopl.
+
+For more required properties, please refer to [2].
+
+[1] Documentation/devicetree/bindings/media/video-interfaces.txt
+[2] Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
+
+Example:
+   mipi_dsi: mipi@ff96 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi";
+   reg = <0xff96 0x4000>;
+   interrupts = ;
+   clocks = <&cru SCLK_MIPI_24M>, <&cru PCLK_MIPI_DSI0>;
+   clock-names = "ref", "pclk";
+   rockchip,grf = <&grf>;
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mipi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   mipi_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&vopb_out_mipi>;
+   };
+   mipi_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <&vopl_out_mipi>;
+   };
+   };
+   };
+
+   panel {
+   compatible ="boe,tv080wum-nl0";
+   reg = <0>;
+
+   enable-gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&lcd_en>;
+   backlight = <&backlight>;
+   status = "okay";
+   };
+   };
-- 
2.6.3

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

[PATCH v5 10/11] ARM: dts: rockchip: add rk3288 mipi_dsi nodes

[Chris Zhong]

Add a mipi_dsi node, and also add mipi_dsi endpoints to vopb and vopl
output port nodes.

Signed-off-by: Chris Zhong 

---

Changes in v5:
- modify the clk name to SCLK_MIPIDSI_24M

Changes in v4: None
Changes in v3: None
Changes in v2: None

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

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 6a79c9c..c48891e 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -798,6 +798,10 @@
reg = <0>;
remote-endpoint = <&hdmi_in_vopb>;
};
+   vopb_out_mipi: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <&mipi_in_vopb>;
+   };
};
};
 
@@ -831,6 +835,10 @@
reg = <0>;
remote-endpoint = <&hdmi_in_vopl>;
};
+   vopl_out_mipi: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <&mipi_in_vopl>;
+   };
};
};
 
@@ -871,6 +879,37 @@
};
};
 
+   mipi_dsi: mipi@ff96 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi";
+   reg = <0xff96 0x4000>;
+   interrupts = ;
+   clocks = <&cru SCLK_MIPIDSI_24M>, <&cru PCLK_MIPI_DSI0>;
+   clock-names = "ref", "pclk";
+   rockchip,grf = <&grf>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mipi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   mipi_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&vopb_out_mipi>;
+   };
+   mipi_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <&vopl_out_mipi>;
+   };
+   };
+   };
+   };
+
gic: interrupt-controller@ffc01000 {
compatible = "arm,gic-400";
interrupt-controller;
-- 
2.6.3

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

[PATCH v5 01/11] clk: rockchip: add id for mipidsi sclk on rk3288

[Chris Zhong]

Adds a new id for the sclk supplying the mipidsi on rk3288 socs.

Signed-off-by: Chris Zhong 

---

Changes in v5:
- change the mipidsi clk to SCLK_MIPIDSI_24M

Changes in v4: None
Changes in v3: None
Changes in v2:
- add the mipi clk id in a single patch

 include/dt-bindings/clock/rk3288-cru.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/clock/rk3288-cru.h 
b/include/dt-bindings/clock/rk3288-cru.h
index c719aac..14c759c 100644
--- a/include/dt-bindings/clock/rk3288-cru.h
+++ b/include/dt-bindings/clock/rk3288-cru.h
@@ -86,6 +86,7 @@
 #define SCLK_USBPHY480M_SRC122
 #define SCLK_PVTM_CORE 123
 #define SCLK_PVTM_GPU  124
+#define SCLK_MIPIDSI_24M   125
 
 #define SCLK_MAC   151
 #define SCLK_MACREF_OUT152
-- 
2.6.3

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

[PATCH v5 0/11] Add mipi dsi support for rk3288

[Chris Zhong]

The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
IP. This series adds support for a Synopsys DesignWare MIPI DSI host
controller DRM bridge driver and a rockchip MIPI DSI specific DRM
driver.

This series also includes a DRM panel driver for BOE TV080WUM-NL0 panel.
This panel only use the MIPI DSI video mode.

The MIPI DSI feature is tested on rk3288 evb board, backport them to
chrome os kernel v3.14, and it can display normally.

This patchset is base on the patchset from ying@freescale.com.


Changes in v5:
- change the mipidsi clk to SCLK_MIPIDSI_24M
- modify the mipidsi clk name to SCLK_MIPIDSI_24M
Adviced by Thierry
- use hyphens instead of underscore
- use encoder in drm_bridge
- reformatting the dptdin table
- use readx_poll_timeout to check register
- use msleep to wait
- add a comment to explain how to program phy
- change the program code to symbolic names
- check this for validity of find_panel and clk_prepare_enable
- eliminate the configuration clock
- some optimization for coding style
- modify the clk name to SCLK_MIPIDSI_24M
- add a blank line befor lcd_en

Changes in v4:
- use clk_round_rate to check the clock rate in vop_crtc_mode_fixup
- remove the cfg clk
- remove gpr property from example, since it is noused now.
- add the description about ports
- eliminate some warnning

Changes in v3:
- move the dw_mipi_dsi.txt to Documentation/devicetree/bindings/display/bridge
- move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/

Changes in v2:
- add the mipi clk id in a single patch

Chris Zhong (9):
  clk: rockchip: add id for mipidsi sclk on rk3288
  clk: rockchip: add mipidsi clocks on rk3288
  drm/rockchip: return a true clock rate to adjusted_mode
  drm: bridge: allow some funcs to be optional
  drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
  drm: rockchip: Support Synopsys DesignWare MIPI DSI host controller
  Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
  ARM: dts: rockchip: add rk3288 mipi_dsi nodes
  ARM: dts: rockchip: add support mipi panel tv080wum-nl0 for rk3288-evb

Liu Ying (2):
  drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
  Documentation: dt-bindings: Add bindings for DW MIPI DSI

 .../bindings/display/bridge/dw_mipi_dsi.txt|   74 ++
 .../display/rockchip/dw_mipi_dsi_rockchip.txt  |   56 +
 arch/arm/boot/dts/rk3288-evb.dtsi  |   20 +-
 arch/arm/boot/dts/rk3288.dtsi  |   39 +
 drivers/clk/rockchip/clk-rk3288.c  |2 +-
 drivers/gpu/drm/bridge/Kconfig |   10 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/dw-mipi-dsi.c   | 1084 
 drivers/gpu/drm/drm_bridge.c   |6 +-
 drivers/gpu/drm/rockchip/Kconfig   |   10 +
 drivers/gpu/drm/rockchip/Makefile  |1 +
 drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c|  249 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|8 +
 include/drm/bridge/dw_mipi_dsi.h   |   28 +
 include/drm/drm_mipi_dsi.h |   14 +
 include/dt-bindings/clock/rk3288-cru.h |1 +
 16 files changed, 1599 insertions(+), 4 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
 create mode 100644 drivers/gpu/drm/bridge/dw-mipi-dsi.c
 create mode 100644 drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c
 create mode 100644 include/drm/bridge/dw_mipi_dsi.h

-- 
2.6.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 v2 4/4] pinctrl/lantiq: fix up pinmux

[Martin Schiller]

On 11/26/2015 at 8:20 AM, John Crispin wrote:
>
>
> On 26/11/2015 08:15, Martin Schiller wrote:
> > On 11/26/2015 at 8:04 AM, John Crispin wrote:
> >>
> >>
> >> On 26/11/2015 07:40, Martin Schiller wrote:
> >>> On 11/25/2015 at 11:40 AM, Jonas Gorski wrote:
>  Hi
> 
>  On Wed, Nov 25, 2015 at 11:18 AM, Martin Schiller
> 
>  wrote:
> > From: John Crispin 
> >
> > This patch is included in the openwrt patchset for several years
> >> now
>  and needs
> > to go upstream as well. It includes the following changes:
> > 1. Fix up inline function call to xway_mux_apply
> 
>  This really needs an explanation what is being fixed here.
> >>>
> >>> I hope John - as the original author of this patch - can explain
> >>> why this change is necessary.
> >>
> >> what change? why am I in Cc: and not To: if an action is required ?
> >>
> >> John
> >
> > That change is meant:
> >
> ###
> #
> >> diff --git a/drivers/pinctrl/pinctrl-xway.c
> b/drivers/pinctrl/pinctrl-
> >> xway.c
> >> index a064962..f0b1b48 100644
> >> --- a/drivers/pinctrl/pinctrl-xway.c
> >> +++ b/drivers/pinctrl/pinctrl-xway.c
> >> @@ -1496,10 +1496,9 @@ static struct pinctrl_desc xway_pctrl_desc =
> {
> >>  .confops= &xway_pinconf_ops,
> >>  };
> >>
> >> -static inline int xway_mux_apply(struct pinctrl_dev *pctrldev,
> >> +static int mux_apply(struct ltq_pinmux_info *info,
> >>  int pin, int mux)
> >>  {
> >> -struct ltq_pinmux_info *info = pinctrl_dev_get_drvdata(pctrldev);
> >>  int port = PORT(pin);
> >>  u32 alt1_reg = GPIO_ALT1(pin);
> >>
> >> @@ -1519,6 +1518,14 @@ static inline int xway_mux_apply(struct
> >> pinctrl_dev *pctrldev,
> >>  return 0;
> >>  }
> >>
> >> +static inline int xway_mux_apply(struct pinctrl_dev *pctrldev,
> >> +int pin, int mux)
> >> +{
> >> +struct ltq_pinmux_info *info = pinctrl_dev_get_drvdata(pctrldev);
> >> +
> >> +return mux_apply(info, pin, mux);
> >> +}
> >> +
> >>  static const struct ltq_cfg_param xway_cfg_params[] = {
> >>  {"lantiq,pull",LTQ_PINCONF_PARAM_PULL},
> >>  {"lantiq,open-drain",LTQ_PINCONF_PARAM_OPEN_DRAIN},
> >
> ###
> >
>
> ok so you picked up a patch and sent it upstream without looking at
> what
> it really does. the patch is simply not ready for upstream. the problem
> here is copy & paste inconsistency.

Of course I analyzed the whole patch and - as you may have noticed - added
a description for the 3 changes which were made in this patch.

I also know that this first part of the patch changes the scope of the inline
code, but I did not know why this change was done.

>
> however if we want to resolve this we should either keep the inlines
> and
> just stick to the current code pattern used or we could just assume
> that
> the compiler will be smart enough to to know when to inline and remove
> all of them.
>
> i'll leave it up to you to decide and propose your solution as a patch
> with an explanation.
>
> John

So I think it would be the best for now to leave this code as it is and make
two separate patches from the remaining two changes:

- Fix GPIO Setup of GPIO Port3
- Implement gpio_chip.to_irq

Martin

>
>
> >>
> >>>
> 
> > 2. Fix GPIO Setup of GPIO Port3
> 
>  This change looks fine.
> 
> > 3. Implement gpio_chip.to_irq
> 
>  These are three different changes (two fixes, one new feature) and
>  therefore should be split up into three patches.
> >>>
> >>> As I'm not the author of this patch, I decided to leave it as it
> is.
> >>> But per se you are right, it would be better to split it up.
> >>>
> 
> > Signed-off-by: John Crispin 
> > Signed-off-by: Martin Schiller 
> > ---
> 
>  Also please provide a changelog for your patches here.
> >>>
> >>> OK.
> >>>
> 
> >  drivers/pinctrl/pinctrl-xway.c | 28 ++--
> >  1 file changed, 26 insertions(+), 2 deletions(-)
> >
> 
> 
>  Jonas
> >>>
> >>> Martin
> >>>
> >>>
> >
> >

Re: [PATCH V3 net-next 1/5] net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem

[Salil Mehta]

On 11/22/2015 9:19 AM, Yuval Mintz wrote:

+void hns_rcbv2_int_ctrl_hw(struct hnae_queue *q, u32 flag, u32 mask)
+{
+   u32 int_mask_en = !!mask;
+
+   if (flag & RCB_INT_FLAG_TX)
+   dsaf_write_dev(q, RCB_RING_INTMSK_TXWL_REG,
int_mask_en);
+
+   if (flag & RCB_INT_FLAG_RX)
+   dsaf_write_dev(q, RCB_RING_INTMSK_RXWL_REG,
int_mask_en);
+}
+
+void hns_rcbv2_int_clr_hw(struct hnae_queue *q, u32 flag)
+{
+   u32 clr = 1;
+
+   if (flag & RCB_INT_FLAG_TX)
+   dsaf_write_dev(q, RCBV2_TX_RING_INT_STS_REG, clr);
+
+   if (flag & RCB_INT_FLAG_RX)
+   dsaf_write_dev(q, RCBV2_RX_RING_INT_STS_REG, clr);
+}
+

Why do you need the int_mask_en, clr variables? Why not directly use values?
'clr' variable can be avoided and is kind of redundant as it always 
holds the

same value. This chnage is now part of latest floated PATCH V5.

Purpose of the mask is coming from the previous/legacy
SoC Hip05 where operation is done on the basis of RX or TX direction.
This mask does not seem very useful for now but we would like to take
this change in future, if there is not any API's using this kind of 
interface.

-Salil



+static void fill_v2_desc(struct hnae_ring *ring, void *priv,



+   hnae_set_field(bn_pid, 0x7, 0, buf_num - 1);

Magic values?

Changed to macro in PATCH V5. Thanks!
-Salil



+int hns_nic_net_xmit_hw(struct net_device *ndev,
+   struct sk_buff *skb,
+   struct hns_nic_ring_data *ring_data)
+{
-   /* If everything has gone correctly network should be the
+   /**
+* If everything has gone correctly network should be the
 * data section of the packet and will be the end of the header.
 * If not then it probably represents the end of the last recognized
 * header.

What happened to the network style comments?

Fixed this in PATCH V5. Thanks !!
-Salil



  static int hns_nic_poll_rx_skb(struct hns_nic_ring_data *ring_data,
   struct sk_buff **out_skb, int *out_bnum)
+   /**
+* we will be copying header into skb->data in
+* pskb_may_pull so it is in our interest to prefetch
+* it now to avoid a possible cache miss
+*/
+   prefetchw(skb->data);
+

Likewise

Fixed this in PATCH V5. Thanks !!
-Salil





--
To unsubscribe from this list: send the line "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 net-next 2/5] net:hns: Add Hip06 "RSS(Receive Side Scaling)" support to HNS Driver

[Salil Mehta]

On 11/22/2015 9:30 AM, Yuval Mintz wrote:

  static void hns_ppe_init_hw(struct hns_ppe_cb *ppe_cb)  {

...

+   /* Set default RSS key and indrection table*/
+   const u32 rss_key[HNS_PPEV2_RSS_KEY_NUM] = {
+   0x6d5a56da, 0x255b0ec2,
+   0x4167253d, 0x43a38fb0,
+   0xd0ca2bcb, 0xae7b30b4,
+   0x77cb2da3, 0x8030f20c,
+   0x6a42b73b, 0xbeac01fa,
+   };
+
+   /* set default RSS key and remember it */
+   for (i = 0; i < HNS_PPEV2_RSS_KEY_NUM; i++)
+   ppe_cb->rss_key[i]  = rss_key[i];


Is there any reason for the special default key?
Why not use netdev_rss_key_fill()?
Thanks for pointing out this. I have incorported this change in latest 
PATCH V5





--
To unsubscribe from this list: send the line "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/4] pinctrl/lantiq: fix up pinmux

[John Crispin]

On 26/11/2015 08:15, Martin Schiller wrote:
> On 11/26/2015 at 8:04 AM, John Crispin wrote:
>>
>>
>> On 26/11/2015 07:40, Martin Schiller wrote:
>>> On 11/25/2015 at 11:40 AM, Jonas Gorski wrote:
 Hi

 On Wed, Nov 25, 2015 at 11:18 AM, Martin Schiller 
 wrote:
> From: John Crispin 
>
> This patch is included in the openwrt patchset for several years
>> now
 and needs
> to go upstream as well. It includes the following changes:
> 1. Fix up inline function call to xway_mux_apply

 This really needs an explanation what is being fixed here.
>>>
>>> I hope John - as the original author of this patch - can explain
>>> why this change is necessary.
>>
>> what change? why am I in Cc: and not To: if an action is required ?
>>
>> John
> 
> That change is meant:
> 
>> diff --git a/drivers/pinctrl/pinctrl-xway.c b/drivers/pinctrl/pinctrl-
>> xway.c
>> index a064962..f0b1b48 100644
>> --- a/drivers/pinctrl/pinctrl-xway.c
>> +++ b/drivers/pinctrl/pinctrl-xway.c
>> @@ -1496,10 +1496,9 @@ static struct pinctrl_desc xway_pctrl_desc = {
>>  .confops= &xway_pinconf_ops,
>>  };
>>
>> -static inline int xway_mux_apply(struct pinctrl_dev *pctrldev,
>> +static int mux_apply(struct ltq_pinmux_info *info,
>>  int pin, int mux)
>>  {
>> -struct ltq_pinmux_info *info = pinctrl_dev_get_drvdata(pctrldev);
>>  int port = PORT(pin);
>>  u32 alt1_reg = GPIO_ALT1(pin);
>>
>> @@ -1519,6 +1518,14 @@ static inline int xway_mux_apply(struct
>> pinctrl_dev *pctrldev,
>>  return 0;
>>  }
>>
>> +static inline int xway_mux_apply(struct pinctrl_dev *pctrldev,
>> +int pin, int mux)
>> +{
>> +struct ltq_pinmux_info *info = pinctrl_dev_get_drvdata(pctrldev);
>> +
>> +return mux_apply(info, pin, mux);
>> +}
>> +
>>  static const struct ltq_cfg_param xway_cfg_params[] = {
>>  {"lantiq,pull",LTQ_PINCONF_PARAM_PULL},
>>  {"lantiq,open-drain",LTQ_PINCONF_PARAM_OPEN_DRAIN},
> ###
> 

ok so you picked up a patch and sent it upstream without looking at what
it really does. the patch is simply not ready for upstream. the problem
here is copy & paste inconsistency.

however if we want to resolve this we should either keep the inlines and
just stick to the current code pattern used or we could just assume that
the compiler will be smart enough to to know when to inline and remove
all of them.

i'll leave it up to you to decide and propose your solution as a patch
with an explanation.

John


>>
>>>

> 2. Fix GPIO Setup of GPIO Port3

 This change looks fine.

> 3. Implement gpio_chip.to_irq

 These are three different changes (two fixes, one new feature) and
 therefore should be split up into three patches.
>>>
>>> As I'm not the author of this patch, I decided to leave it as it is.
>>> But per se you are right, it would be better to split it up.
>>>

> Signed-off-by: John Crispin 
> Signed-off-by: Martin Schiller 
> ---

 Also please provide a changelog for your patches here.
>>>
>>> OK.
>>>

>  drivers/pinctrl/pinctrl-xway.c | 28 ++--
>  1 file changed, 26 insertions(+), 2 deletions(-)
>


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

[PATCH V5 net-next 5/5] net:hns: Add the init code to disable Hip06 "Hardware VLAN assist"

[Salil Mehta]

This patch adds the initializzation code to disable the hardware
vlan support for VLAN Tag stripping by default for now.

Proper support of "hardware VLAN assitance" feature would
soon come in the next coming patches.

Signed-off-by: Salil Mehta 
---
PATCH V5:
- Minor merge/reject change resolved to application of previous patch

PATCH V4:
- No change over the earlier patches

PATCH V2/V3:
- No change over the initial floated patch

PATCH V1:
- Initial code to disable the hardware VLAN assist for now
---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c |7 +++
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h |1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index b5e4c44..f302ef9 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -176,6 +176,11 @@ static void hns_ppe_cnt_clr_ce(struct hns_ppe_cb *ppe_cb)
 PPE_CNT_CLR_CE_B, 1);
 }
 
+static void hns_ppe_set_vlan_strip(struct hns_ppe_cb *ppe_cb, int en)
+{
+   dsaf_write_dev(ppe_cb, PPEV2_VLAN_STRIP_EN_REG, en);
+}
+
 /**
  * hns_ppe_checksum_hw - set ppe checksum caculate
  * @ppe_device: ppe device
@@ -336,6 +341,8 @@ static void hns_ppe_init_hw(struct hns_ppe_cb *ppe_cb)
hns_ppe_cnt_clr_ce(ppe_cb);
 
if (!AE_IS_VER1(dsaf_dev->dsaf_ver)) {
+   hns_ppe_set_vlan_strip(ppe_cb, 0);
+
/* set default RSS key in h/w */
hns_ppe_set_rss_key(ppe_cb, ppe_cb->rss_key);
 
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index 98c163e..6c18ca9 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -318,6 +318,7 @@
 #define PPE_CFG_PARSE_TAG_REG  0x94
 #define PPE_CFG_PRO_CHECK_EN_REG   0x98
 #define PPEV2_CFG_TSO_EN_REG0xA0
+#define PPEV2_VLAN_STRIP_EN_REG 0xAC
 #define PPE_INTEN_REG  0x100
 #define PPE_RINT_REG   0x104
 #define PPE_INTSTS_REG 0x108
-- 
1.7.9.5


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

[PATCH V5 net-next 1/5] net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem

[Salil Mehta]

This patchset adds support of Hisilicon Hip06 SoC to the existing HNS
ethernet driver.

The changes in the driver are mainly due to changes in the DMA
descriptor provided by the Hip06 ethernet hardware. These changes
need to co-exist with already present Hip05 DMA descriptor and its
operating functions. The decision to choose the correct type of DMA
descriptor is taken dynamically depending upon the version of the
hardware (i.e. V1/hip05 or V2/hip06, see alredy existing
hisilicon-hns-nic.txt binding file for detailed description). other
changes includes in SBM, DSAF and PPE modules as well. Changes
affecting the driver related to the newly added ethernet hardware
features in Hip06 would be added as separate patch over this and
subsequent patches.

Signed-off-by: Salil Mehta 
Signed-off-by: yankejian 
Signed-off-by: huangdaode 
Signed-off-by: lipeng 
Signed-off-by: lisheng 
Signed-off-by: Fengguang Wu 
---

PATCH V5:
- This V5 patch fixes the comments provided by Yuval
  Mintz  and the errors introduce
  during checkpatch.pl script.
  Link: https://lkml.org/lkml/2015/11/22/34

PATCH V4:
No change over PATCH V3

PATCH V3:
- This patch addresses comments floated by David Miller on
  PATCH V2. In summary, changing is_ver1 data-type from 'int' to
  'bool' at different places of the code:
  Link: https://lkml.org/lkml/2015/11/18/656

PATCH V2:
- Fix the comment from "kbuild test robot" from Intel(Fengguang Wu)
  Link: https://lkml.org/lkml/2015/10/20/562
https://lkml.org/lkml/2015/10/20/563
- Fixes the internal review comments from:
  Kenneth Lee 
  huangdaode 

PATCH V1:
- Intial driver Version to support HNS over Hip06 SoC
---
 drivers/net/ethernet/hisilicon/hns/hnae.h  |   51 ++-
 drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c  |   29 ++
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c |  213 +---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h |   25 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c |6 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c  |6 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c  |   76 +++--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h  |8 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h  |   72 +++-
 drivers/net/ethernet/hisilicon/hns/hns_enet.c  |  360 
 drivers/net/ethernet/hisilicon/hns/hns_enet.h  |   12 +
 drivers/net/ethernet/hisilicon/hns/hns_ethtool.c   |2 +-
 12 files changed, 678 insertions(+), 182 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h 
b/drivers/net/ethernet/hisilicon/hns/hnae.h
index cec95ac..6c9a68c 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -35,7 +35,7 @@
 #include 
 #include 
 
-#define HNAE_DRIVER_VERSION "1.3.0"
+#define HNAE_DRIVER_VERSION "2.0"
 #define HNAE_DRIVER_NAME "hns"
 #define HNAE_COPYRIGHT "Copyright(c) 2015 Huawei Corporation."
 #define HNAE_DRIVER_STRING "Hisilicon Network Subsystem Driver"
@@ -63,6 +63,7 @@ do { \
 
 #define AE_VERSION_1 ('6' << 16 | '6' << 8 | '0')
 #define AE_VERSION_2 ('1' << 24 | '6' << 16 | '1' << 8 | '0')
+#define AE_IS_VER1(ver) ((ver) == AE_VERSION_1)
 #define AE_NAME_SIZE 16
 
 /* some said the RX and TX RCB format should not be the same in the future. But
@@ -144,23 +145,61 @@ enum hnae_led_state {
 #define HNS_RXD_ASID_S 24
 #define HNS_RXD_ASID_M (0xff << HNS_RXD_ASID_S)
 
+#define HNSV2_TXD_BUFNUM_S 0
+#define HNSV2_TXD_BUFNUM_M (0x7 << HNSV2_TXD_BUFNUM_S)
+#define HNSV2_TXD_RI_B   1
+#define HNSV2_TXD_L4CS_B   2
+#define HNSV2_TXD_L3CS_B   3
+#define HNSV2_TXD_FE_B   4
+#define HNSV2_TXD_VLD_B  5
+
+#define HNSV2_TXD_TSE_B   0
+#define HNSV2_TXD_VLAN_EN_B   1
+#define HNSV2_TXD_SNAP_B   2
+#define HNSV2_TXD_IPV6_B   3
+#define HNSV2_TXD_SCTP_B   4
+
 /* hardware spec ring buffer format */
 struct __packed hnae_desc {
__le64 addr;
union {
struct {
-   __le16 asid_bufnum_pid;
+   union {
+   __le16 asid_bufnum_pid;
+   __le16 asid;
+   };
__le16 send_size;
-   __le32 flag_ipoffset;
-   __le32 reserved_3[4];
+   union {
+   __le32 flag_ipoffset;
+   struct {
+   __u8 bn_pid;
+   __u8 ra_ri_cs_fe_vld;
+   __u8 ip_offset;
+   __u8 tse_vlan_snap_v6_sctp_nth;
+   };
+   };
+   __le16 mss;
+   __u8 l4_len;
+   __u8 reserved1;
+   __le16 paylen;
+   __u8 vmid;
+   __u8 qid;
+   __le32 reserved2[2];
} tx;
 
 

[PATCH V5 net-next 3/5] net:hns: Add Hip06 "TSO(TCP Segment Offload)" support HNS Driver

[Salil Mehta]

This patch adds the support of "TSO (TCP Segment Offload)" feature
provided by the Hip06 ethernet hardware to the HNS ethernet
driver.

Enabling this feature would help offload the TCP Segmentation
process to the Hip06 ethernet hardware. This eventually would help
in saving precious cpu cycles.

Signed-off-by: Salil Mehta 
Signed-off-by: lisheng 
---
PATCH V5:
Minor styling change

PATCH V4:
No change over the previous patches

PATCH V3/V2:
- No change over the initial floated patch for TSO

PATCH V1:
- Initial support of TSO feature in Hip06 SoC in HNS driver
---
 drivers/net/ethernet/hisilicon/hns/hnae.h |1 +
 drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c |8 ++
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c |5 ++
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h |2 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h |1 +
 drivers/net/ethernet/hisilicon/hns/hns_enet.c |   82 -
 6 files changed, 95 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h 
b/drivers/net/ethernet/hisilicon/hns/hnae.h
index 76dd715..d1f3316 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -474,6 +474,7 @@ struct hnae_ae_ops {
int (*set_mac_addr)(struct hnae_handle *handle, void *p);
int (*set_mc_addr)(struct hnae_handle *handle, void *addr);
int (*set_mtu)(struct hnae_handle *handle, int new_mtu);
+   void (*set_tso_stats)(struct hnae_handle *handle, int enable);
void (*update_stats)(struct hnae_handle *handle,
 struct net_device_stats *net_stats);
void (*get_stats)(struct hnae_handle *handle, u64 *data);
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c 
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index e5a31bc..d02fa58 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -277,6 +277,13 @@ static int hns_ae_set_mtu(struct hnae_handle *handle, int 
new_mtu)
return hns_mac_set_mtu(mac_cb, new_mtu);
 }
 
+static void hns_ae_set_tso_stats(struct hnae_handle *handle, int enable)
+{
+   struct hns_ppe_cb *ppe_cb = hns_get_ppe_cb(handle);
+
+   hns_ppe_set_tso_enable(ppe_cb, enable);
+}
+
 static int hns_ae_start(struct hnae_handle *handle)
 {
int ret;
@@ -824,6 +831,7 @@ static struct hnae_ae_ops hns_dsaf_ops = {
.set_mc_addr = hns_ae_set_multicast_one,
.set_mtu = hns_ae_set_mtu,
.update_stats = hns_ae_update_stats,
+   .set_tso_stats = hns_ae_set_tso_stats,
.get_stats = hns_ae_get_stats,
.get_strings = hns_ae_get_strings,
.get_sset_count = hns_ae_get_sset_count,
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index 7af0858..b5e4c44 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -19,6 +19,11 @@
 
 #include "hns_dsaf_ppe.h"
 
+void hns_ppe_set_tso_enable(struct hns_ppe_cb *ppe_cb, u32 value)
+{
+   dsaf_set_dev_bit(ppe_cb, PPEV2_CFG_TSO_EN_REG, 0, !!value);
+}
+
 void hns_ppe_set_rss_key(struct hns_ppe_cb *ppe_cb,
 const u32 rss_key[HNS_PPEV2_RSS_KEY_NUM])
 {
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h
index dac8532..0f5cb69 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h
@@ -113,7 +113,7 @@ void hns_ppe_get_regs(struct hns_ppe_cb *ppe_cb, void 
*data);
 
 void hns_ppe_get_strings(struct hns_ppe_cb *ppe_cb, int stringset, u8 *data);
 void hns_ppe_get_stats(struct hns_ppe_cb *ppe_cb, u64 *data);
-
+void hns_ppe_set_tso_enable(struct hns_ppe_cb *ppe_cb, u32 value);
 void hns_ppe_set_rss_key(struct hns_ppe_cb *ppe_cb,
 const u32 rss_key[HNS_PPEV2_RSS_KEY_NUM]);
 void hns_ppe_set_indir_table(struct hns_ppe_cb *ppe_cb,
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index b070d57..98c163e 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -317,6 +317,7 @@
 #define PPE_CFG_TAG_GEN_REG0x90
 #define PPE_CFG_PARSE_TAG_REG  0x94
 #define PPE_CFG_PRO_CHECK_EN_REG   0x98
+#define PPEV2_CFG_TSO_EN_REG0xA0
 #define PPE_INTEN_REG  0x100
 #define PPE_RINT_REG   0x104
 #define PPE_INTSTS_REG 0x108
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c 
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 0ca7fa9..c025a71 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -223,6 +223,71 @@ static i

[PATCH V5 net-next 4/5] net:hns: Add support of ethtool TSO set option for Hip06 in HNS

[Salil Mehta]

From: Salil 

This patch adds the support of ethtool TSO option to support
Hip06 SoC to HNS

Signed-off-by: Salil Mehta 
Signed-off-by: lisheng 
---
PATCH V5:
- No change over the previous patch

PATCH V4:
This fixes the comments given by Sergei Shtylyov over the PATCH V3:
 Link: https://lkml.org/lkml/2015/11/20/358

PATCH V3/V2:
- No change over the initial patch

PATCH V1:
- Initial version of Ethtool support of TSO by Lisheng
---
 drivers/net/ethernet/hisilicon/hns/hns_enet.c |   47 +
 1 file changed, 47 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c 
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index c025a71..cad2663 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -1384,6 +1384,51 @@ static int hns_nic_change_mtu(struct net_device *ndev, 
int new_mtu)
return ret;
 }
 
+static int hns_nic_set_features(struct net_device *netdev,
+   netdev_features_t features)
+{
+   struct hns_nic_priv *priv = netdev_priv(netdev);
+   struct hnae_handle *h = priv->ae_handle;
+
+   switch (priv->enet_ver) {
+   case AE_VERSION_1:
+   if (features & (NETIF_F_TSO | NETIF_F_TSO6))
+   netdev_info(netdev, "enet v1 do not support tso!\n");
+   break;
+   default:
+   if (features & (NETIF_F_TSO | NETIF_F_TSO6)) {
+   priv->ops.fill_desc = fill_tso_desc;
+   priv->ops.maybe_stop_tx = hns_nic_maybe_stop_tso;
+   /* The chip only support 7*4096 */
+   netif_set_gso_max_size(netdev, 7 * 4096);
+   h->dev->ops->set_tso_stats(h, 1);
+   } else {
+   priv->ops.fill_desc = fill_v2_desc;
+   priv->ops.maybe_stop_tx = hns_nic_maybe_stop_tx;
+   h->dev->ops->set_tso_stats(h, 0);
+   }
+   break;
+   }
+   netdev->features = features;
+   return 0;
+}
+
+static netdev_features_t hns_nic_fix_features(
+   struct net_device *netdev, netdev_features_t features)
+{
+   struct hns_nic_priv *priv = netdev_priv(netdev);
+
+   switch (priv->enet_ver) {
+   case AE_VERSION_1:
+   features &= ~(NETIF_F_TSO | NETIF_F_TSO6 |
+   NETIF_F_HW_VLAN_CTAG_FILTER);
+   break;
+   default:
+   break;
+   }
+   return features;
+}
+
 /**
  * nic_set_multicast_list - set mutl mac address
  * @netdev: net device
@@ -1479,6 +1524,8 @@ static const struct net_device_ops hns_nic_netdev_ops = {
.ndo_set_mac_address = hns_nic_net_set_mac_address,
.ndo_change_mtu = hns_nic_change_mtu,
.ndo_do_ioctl = hns_nic_do_ioctl,
+   .ndo_set_features = hns_nic_set_features,
+   .ndo_fix_features = hns_nic_fix_features,
.ndo_get_stats64 = hns_nic_get_stats64,
 #ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = hns_nic_poll_controller,
-- 
1.7.9.5


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

[PATCH V5 net-next 2/5] net:hns: Add Hip06 "RSS(Receive Side Scaling)" support to HNS Driver

[Salil Mehta]

This patch adds the support of "RSS (Receive Side Scaling)" feature
provided by the Hip06 ethernet hardware to the HNS ethernet
driver.

This feature helps in distributing the different flows (mapped as
hash by hardware using Toeplitz Hash) to different Queues asssociated
with the processor cores. The mapping of flow-hash values to the
different queues is stored in indirection table (which is per Packet-
parse-Engine/PPE). This patch also provides the changes to re-program
the (flow-hash<->Qid) mapping using the ethtool.

Signed-off-by: Salil Mehta 
Reviewed-by: Kenneth Lee 
---
PATCH V5:
- This V5 patch fixes the comments provided by Yuval
  Mintz  on the RSS Key initialization part.
  Link: https://lkml.org/lkml/2015/11/22/42

PATCH V4/V3:
- No Change over previous patches

PATCH V2:
- Fix for review-comments on PATCH V1 by Yisen.Zhuang(Zhuangyuzeng)
  Link: https://lkml.org/lkml/2015/10/21/1032
- Rework for Internal review comments by Kenneth Lee

PATCH V1:
- Initial version to support RSS and its Ethtool interface on
  Hip06 SoC
---
 drivers/net/ethernet/hisilicon/hns/hnae.h |6 ++
 drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c |   53 +++-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c |   54 +++-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h |   32 +--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h |   14 
 drivers/net/ethernet/hisilicon/hns/hns_ethtool.c  |   93 +
 6 files changed, 242 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h 
b/drivers/net/ethernet/hisilicon/hns/hnae.h
index 6c9a68c..76dd715 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -485,6 +485,12 @@ struct hnae_ae_ops {
  enum hnae_led_state status);
void (*get_regs)(struct hnae_handle *handle, void *data);
int (*get_regs_len)(struct hnae_handle *handle);
+   u32 (*get_rss_key_size)(struct hnae_handle *handle);
+   u32 (*get_rss_indir_size)(struct hnae_handle *handle);
+   int (*get_rss)(struct hnae_handle *handle, u32 *indir, u8 *key,
+  u8 *hfunc);
+   int (*set_rss)(struct hnae_handle *handle, const u32 *indir,
+  const u8 *key, const u8 hfunc);
 };
 
 struct hnae_ae_dev {
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c 
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index c03bc1e..e5a31bc 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -749,6 +749,53 @@ int hns_ae_get_regs_len(struct hnae_handle *handle)
return total_num;
 }
 
+static u32 hns_ae_get_rss_key_size(struct hnae_handle *handle)
+{
+   return HNS_PPEV2_RSS_KEY_SIZE;
+}
+
+static u32 hns_ae_get_rss_indir_size(struct hnae_handle *handle)
+{
+   return HNS_PPEV2_RSS_IND_TBL_SIZE;
+}
+
+static int hns_ae_get_rss(struct hnae_handle *handle, u32 *indir, u8 *key,
+ u8 *hfunc)
+{
+   struct hns_ppe_cb *ppe_cb = hns_get_ppe_cb(handle);
+
+   /* currently we support only one type of hash function i.e. Toep hash */
+   if (hfunc)
+   *hfunc = ETH_RSS_HASH_TOP;
+
+   /* get the RSS Key required by the user */
+   if (key)
+   memcpy(key, ppe_cb->rss_key, HNS_PPEV2_RSS_KEY_SIZE);
+
+   /* update the current hash->queue mappings from the shadow RSS table */
+   memcpy(indir, ppe_cb->rss_indir_table, HNS_PPEV2_RSS_IND_TBL_SIZE);
+
+   return 0;
+}
+
+static int hns_ae_set_rss(struct hnae_handle *handle, const u32 *indir,
+ const u8 *key, const u8 hfunc)
+{
+   struct hns_ppe_cb *ppe_cb = hns_get_ppe_cb(handle);
+
+   /* set the RSS Hash Key if specififed by the user */
+   if (key)
+   hns_ppe_set_rss_key(ppe_cb, (int *)key);
+
+   /* update the shadow RSS table with user specified qids */
+   memcpy(ppe_cb->rss_indir_table, indir, HNS_PPEV2_RSS_IND_TBL_SIZE);
+
+   /* now update the hardware */
+   hns_ppe_set_indir_table(ppe_cb, ppe_cb->rss_indir_table);
+
+   return 0;
+}
+
 static struct hnae_ae_ops hns_dsaf_ops = {
.get_handle = hns_ae_get_handle,
.put_handle = hns_ae_put_handle,
@@ -783,7 +830,11 @@ static struct hnae_ae_ops hns_dsaf_ops = {
.update_led_status = hns_ae_update_led_status,
.set_led_id = hns_ae_cpld_set_led_id,
.get_regs = hns_ae_get_regs,
-   .get_regs_len = hns_ae_get_regs_len
+   .get_regs_len = hns_ae_get_regs_len,
+   .get_rss_key_size = hns_ae_get_rss_key_size,
+   .get_rss_indir_size = hns_ae_get_rss_indir_size,
+   .get_rss = hns_ae_get_rss,
+   .set_rss = hns_ae_set_rss
 };
 
 int hns_dsaf_ae_init(struct dsaf_device *dsaf_dev)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index 9531992..7a

RE: [PATCH v2 4/4] pinctrl/lantiq: fix up pinmux

[Martin Schiller]

On 11/26/2015 at 8:04 AM, John Crispin wrote:
>
>
> On 26/11/2015 07:40, Martin Schiller wrote:
> > On 11/25/2015 at 11:40 AM, Jonas Gorski wrote:
> >> Hi
> >>
> >> On Wed, Nov 25, 2015 at 11:18 AM, Martin Schiller 
> >> wrote:
> >>> From: John Crispin 
> >>>
> >>> This patch is included in the openwrt patchset for several years
> now
> >> and needs
> >>> to go upstream as well. It includes the following changes:
> >>> 1. Fix up inline function call to xway_mux_apply
> >>
> >> This really needs an explanation what is being fixed here.
> >
> > I hope John - as the original author of this patch - can explain
> > why this change is necessary.
>
> what change? why am I in Cc: and not To: if an action is required ?
>
> John

That change is meant:

> diff --git a/drivers/pinctrl/pinctrl-xway.c b/drivers/pinctrl/pinctrl-
> xway.c
> index a064962..f0b1b48 100644
> --- a/drivers/pinctrl/pinctrl-xway.c
> +++ b/drivers/pinctrl/pinctrl-xway.c
> @@ -1496,10 +1496,9 @@ static struct pinctrl_desc xway_pctrl_desc = {
>  .confops= &xway_pinconf_ops,
>  };
>
> -static inline int xway_mux_apply(struct pinctrl_dev *pctrldev,
> +static int mux_apply(struct ltq_pinmux_info *info,
>  int pin, int mux)
>  {
> -struct ltq_pinmux_info *info = pinctrl_dev_get_drvdata(pctrldev);
>  int port = PORT(pin);
>  u32 alt1_reg = GPIO_ALT1(pin);
>
> @@ -1519,6 +1518,14 @@ static inline int xway_mux_apply(struct
> pinctrl_dev *pctrldev,
>  return 0;
>  }
>
> +static inline int xway_mux_apply(struct pinctrl_dev *pctrldev,
> +int pin, int mux)
> +{
> +struct ltq_pinmux_info *info = pinctrl_dev_get_drvdata(pctrldev);
> +
> +return mux_apply(info, pin, mux);
> +}
> +
>  static const struct ltq_cfg_param xway_cfg_params[] = {
>  {"lantiq,pull",LTQ_PINCONF_PARAM_PULL},
>  {"lantiq,open-drain",LTQ_PINCONF_PARAM_OPEN_DRAIN},
###

>
> >
> >>
> >>> 2. Fix GPIO Setup of GPIO Port3
> >>
> >> This change looks fine.
> >>
> >>> 3. Implement gpio_chip.to_irq
> >>
> >> These are three different changes (two fixes, one new feature) and
> >> therefore should be split up into three patches.
> >
> > As I'm not the author of this patch, I decided to leave it as it is.
> > But per se you are right, it would be better to split it up.
> >
> >>
> >>> Signed-off-by: John Crispin 
> >>> Signed-off-by: Martin Schiller 
> >>> ---
> >>
> >> Also please provide a changelog for your patches here.
> >
> > OK.
> >
> >>
> >>>  drivers/pinctrl/pinctrl-xway.c | 28 ++--
> >>>  1 file changed, 26 insertions(+), 2 deletions(-)
> >>>
> >>
> >>
> >> Jonas
> >
> > Martin
> >
> >

[PATCH V5 net-next 0/5] net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem

[Salil Mehta]

This PATCH V5 address the review comments by Yuval Mintz
 . This rework of comments are basically
 related to:
 1) styling of the code,
 2) RSS default Key initiailization related code
 3) redundant code removal 

PATCH V4:
This addresses the review comment provided by 
Sergei Shtylyov. The changelog of every patch has also
been modified.

PATCH V3:
 Addresses the review comment floated by David Miller 

PATCH V2:
1) Bug Fixes and Clean-up: Internally identified
2) Addresses internal review comments by Kenneth Lee and
   by Huang Daode
3) Addresses the review comment from "Yisen.Zhuang(Zhuangyuzeng)"
4) Adds fix from Fengguang Wu for an error generated from 
   "kbuild test robot" from Intel
5) Ethtool support for TSO set option from Lisheng

PATCH V1:
Adds initial support of Hip06 SoC with below changes:  
This patch-set adds support of new Hisilicon Hip06 SoC to the existing
(already part of net-next) HNS ethernet driver for Hip05 SoC. Hip06 is
a multi-core SoC and is a derivative of Hip05 SoC with lots of new
hardware featres supported like RSS, TSO, hardware VLAN assist etc. 

The changes in the driver are mainly due to following:
 1) changes in the DMA descriptor provided by the Hip06 ethernet 
hardware. These changes need to co-exist with already present
Hip05 DMA descriptor and its operating functions. The decision
to choose the correct type of DMA descriptor is taken dynamically
depending upon the version of the hardware (i.e. V1/hip05 or
V2/hip06, see already existing hisilicon-hns-nic.txt binding file
for the detailed description version and naming).
 2) To support new features added to the Hip06 ethernet hardware:
a. RSS (Receive Side Scaling)
b. TSO (TCP Segment Offload)
c. Hardware VLAN support (currently we are initializing hardware
   to not assist in stripping the vlan tag at hardware level.
   Proper support of this feature and ethtool would come after
   these patches have been accepted)

Kindly note that, this patchset has been based on latest net-next.

Salil Mehta (5):
  net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem
  net:hns: Add Hip06 "RSS(Receive Side Scaling)" support to HNS Driver
  net:hns: Add Hip06 "TSO(TCP Segment Offload)" support HNS Driver
  net:hns: Add support of ethtool TSO set option for Hip06 in HNS
  net:hns: Add the init code to disable Hip06 "Hardware VLAN assist"

 drivers/net/ethernet/hisilicon/hns/hnae.h  |   58 ++-
 drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c  |   90 +++-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c |  213 +++--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h |   25 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c |6 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c  |   72 ++-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h  |   32 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c  |   76 ++-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h  |8 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h  |   88 +++-
 drivers/net/ethernet/hisilicon/hns/hns_enet.c  |  483 +---
 drivers/net/ethernet/hisilicon/hns/hns_enet.h  |   12 +
 drivers/net/ethernet/hisilicon/hns/hns_ethtool.c   |   95 +++-
 13 files changed, 1066 insertions(+), 192 deletions(-)

-- 
1.7.9.5


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

Re: [linux-sunxi] Re: [PATCH v3 1/2] phy-sun4i-usb: Use of_match_node to get model specific config data

[LABBE Corentin]

On Thu, Nov 26, 2015 at 12:22:59PM +0800, Chen-Yu Tsai wrote:
> On Thu, Nov 26, 2015 at 12:50 AM, Hans de Goede  wrote:
> > +
> >  static const unsigned int sun4i_usb_phy0_cable[] = {
> > EXTCON_USB,
> > EXTCON_USB_HOST,
> > @@ -511,10 +578,16 @@ static int sun4i_usb_phy_probe(struct platform_device 
> > *pdev)
> > struct device *dev = &pdev->dev;
> > struct device_node *np = dev->of_node;
> > struct phy_provider *phy_provider;
> > -   bool dedicated_clocks;
> > +   const struct of_device_id *match;
> > struct resource *res;
> > int i, ret;
> >
> > +   match = of_match_node(sun4i_usb_phy_of_match, dev->of_node);
> 
> You can use of_device_get_match_data() for slightly less code. This
> will also let you keep the of_device_id table where it was, at the
> bottom.
> 
> > +   if (!match) {
> 
> I'm working on something similar in the axp20x driver. Is there any
> case of_match_node or of_device_get_match_data can fail?
> 
> 

Hello

I am working on some patch for that case and the conclusion was that case is 
possible.
See https://lkml.org/lkml/2015/11/12/97
So it is better to check it.

Regards

--
To unsubscribe from this list: send the line "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/4] pinctrl/lantiq: fix up pinmux

[John Crispin]

On 26/11/2015 07:40, Martin Schiller wrote:
> On 11/25/2015 at 11:40 AM, Jonas Gorski wrote:
>> Hi
>>
>> On Wed, Nov 25, 2015 at 11:18 AM, Martin Schiller 
>> wrote:
>>> From: John Crispin 
>>>
>>> This patch is included in the openwrt patchset for several years now
>> and needs
>>> to go upstream as well. It includes the following changes:
>>> 1. Fix up inline function call to xway_mux_apply
>>
>> This really needs an explanation what is being fixed here.
> 
> I hope John - as the original author of this patch - can explain
> why this change is necessary.

what change? why am I in Cc: and not To: if an action is required ?

John

> 
>>
>>> 2. Fix GPIO Setup of GPIO Port3
>>
>> This change looks fine.
>>
>>> 3. Implement gpio_chip.to_irq
>>
>> These are three different changes (two fixes, one new feature) and
>> therefore should be split up into three patches.
> 
> As I'm not the author of this patch, I decided to leave it as it is.
> But per se you are right, it would be better to split it up.
> 
>>
>>> Signed-off-by: John Crispin 
>>> Signed-off-by: Martin Schiller 
>>> ---
>>
>> Also please provide a changelog for your patches here.
> 
> OK.
> 
>>
>>>  drivers/pinctrl/pinctrl-xway.c | 28 ++--
>>>  1 file changed, 26 insertions(+), 2 deletions(-)
>>>
>>
>>
>> Jonas
> 
> Martin
> 
> 
--
To unsubscribe from this list: send the line "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/9] Documentation: dt-bindings: leds: backlight: add TI LMU backlight binding information

[Milo Kim]

LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697 use common dt-bindings
for describing backlight device.

Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Cc: Lee Jones  
Cc: Jacek Anaszewski 
Cc: Mark Brown 
Cc: linux-l...@vger.kernel.org 
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Milo Kim 
---
 .../bindings/leds/backlight/ti-lmu-backlight.txt   | 65 ++
 1 file changed, 65 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/leds/backlight/ti-lmu-backlight.txt

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/ti-lmu-backlight.txt 
b/Documentation/devicetree/bindings/leds/backlight/ti-lmu-backlight.txt
new file mode 100644
index 000..c2c35b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/ti-lmu-backlight.txt
@@ -0,0 +1,65 @@
+TI LMU backlight device tree bindings
+
+Required property:
+  - compatible: Should be one of:
+"ti,lm3532-backlight"
+"ti,lm3631-backlight"
+"ti,lm3632-backlight"
+"ti,lm3633-backlight"
+"ti,lm3695-backlight"
+"ti,lm3697-backlight"
+
+Optional properties:
+  There are two backlight control mode. One is I2C, the other is PWM mode.
+  Following properties are only specified in PWM mode.
+  Please note that LMU backlight device can have only one PWM channel.
+
+  - pwms: OF device-tree PWM specification.
+  - pwm-names: a list of names for the PWM devices specified in the "pwms"
+   property.
+
+  For the PWM user nodes, please refer to [1].
+
+Child nodes:
+  LMU backlight is represented as sub-nodes of the TI LMU device [2].
+  So, LMU backlight should have more than one backlight child node.
+  Each node exactly matches with backlight control bank configuration.
+  Maximum numbers of child nodes depend on the device.
+  1 = LM3631, LM3632, LM3695
+  2 = LM3633, LM3697
+  3 = LM3532
+
+  Required property of a child node:
+  - led-sources: List of enabled channels from 0 to 2.
+ Please refer to LED binding [3].
+ For output channels, please refer to the datasheets [4].
+
+  Optional properties of a child node:
+  - label: Backlight channel identification.
+   Please refer to LED binding [3].
+  - default-brightness-level: Backlight initial brightness value.
+  Type is . It is set as soon as backlight
+  device is created.
+  0 ~ 2047 = LM3631, LM3632, LM3633, LM3695 and
+ LM3697
+  0 ~ 255  = LM3532
+  - ramp-up-msec, ramp-down-msec: Light dimming effect properties.
+  Type is . Unit is millisecond.
+  0 ~ 65 msec= LM3532
+  0 ~ 4000 msec  = LM3631
+  0 ~ 16000 msec = LM3633 and LM3697
+  - pwm-period: PWM period. Only valid in PWM brightness mode.
+Type is . If this property is missing, then control
+mode is set to I2C by default.
+
+Examples: Please refer to ti-lmu dt-bindings. [2].
+
+[1] ../pwm/pwm.txt
+[2] ../mfd/ti-lmu.txt
+[3] ../leds/common.txt
+[4] LM3532: http://www.ti.com/product/LM3532/datasheet
+LM3631: http://www.ti.com/product/LM3631/datasheet
+LM3632: http://www.ti.com/product/LM3632A/datasheet
+LM3633: http://www.ti.com/product/LM3633/datasheet
+LM3695: Datasheet is not opened yet, but only two strings are used.
+LM3697: http://www.ti.com/product/LM3697/datasheet
-- 
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 9/9] regulator: add LM363X driver

[Milo Kim]

LM363X regulator driver supports LM3631 and LM3632.
LM3631 has 5 regulators. LM3632 provides 3 regulators.
One boost output and LDOs are used for the display module.
Boost voltage is configurable but always on.
Supported operations for LDOs are enabled/disabled and voltage change.

Two LDOs of LM3632 can be controlled by external pins.
Those are configured through the DT properties.

Cc: Mark Brown 
Cc: Lee Jones  
Cc: Jacek Anaszewski 
Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Cc: linux-l...@vger.kernel.org 
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Milo Kim 
---
 drivers/regulator/Kconfig|   9 +
 drivers/regulator/Makefile   |   1 +
 drivers/regulator/lm363x-regulator.c | 309 +++
 3 files changed, 319 insertions(+)
 create mode 100644 drivers/regulator/lm363x-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 3e028d9..971ebfa 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -274,6 +274,15 @@ config REGULATOR_ISL6271A
help
  This driver supports ISL6271A voltage regulator chip.
 
+config REGULATOR_LM363X
+   tristate "TI LM363X voltage regulators"
+   depends on MFD_TI_LMU
+   help
+ This driver supports LM3631 and LM3632 voltage regulators for
+ the LCD bias.
+ One boost output voltage is configurable and always on.
+ Other LDOs are used for the display module.
+
 config REGULATOR_LP3971
tristate "National Semiconductors LP3971 PMIC regulator driver"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 5a963d9..21a3e67 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_REGULATOR_GPIO) += gpio-regulator.o
 obj-$(CONFIG_REGULATOR_HI6421) += hi6421-regulator.o
 obj-$(CONFIG_REGULATOR_ISL6271A) += isl6271a-regulator.o
 obj-$(CONFIG_REGULATOR_ISL9305) += isl9305.o
+obj-$(CONFIG_REGULATOR_LM363X) += lm363x-regulator.o
 obj-$(CONFIG_REGULATOR_LP3971) += lp3971.o
 obj-$(CONFIG_REGULATOR_LP3972) += lp3972.o
 obj-$(CONFIG_REGULATOR_LP872X) += lp872x.o
diff --git a/drivers/regulator/lm363x-regulator.c 
b/drivers/regulator/lm363x-regulator.c
new file mode 100644
index 000..e1b683e
--- /dev/null
+++ b/drivers/regulator/lm363x-regulator.c
@@ -0,0 +1,309 @@
+/*
+ * TI LM363X Regulator Driver
+ *
+ * Copyright 2015 Texas Instruments
+ *
+ * Author: Milo Kim 
+ *
+ * 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 
+
+/* LM3631 */
+#define LM3631_BOOST_VSEL_MAX  0x25
+#define LM3631_LDO_VSEL_MAX0x28
+#define LM3631_CONT_VSEL_MAX   0x03
+#define LM3631_VBOOST_MIN  450
+#define LM3631_VCONT_MIN   180
+#define LM3631_VLDO_MIN400
+#define ENABLE_TIME_USEC   1000
+
+/* LM3632 */
+#define LM3632_BOOST_VSEL_MAX  0x26
+#define LM3632_LDO_VSEL_MAX0x29
+#define LM3632_VBOOST_MIN  450
+#define LM3632_VLDO_MIN400
+
+/* Common */
+#define LM363X_STEP_50mV   5
+#define LM363X_STEP_500mV  50
+
+struct lm363x_regulator {
+   struct regmap *regmap;
+   struct regulator_dev *regulator;
+};
+
+const int ldo_cont_enable_time[] = {
+   0, 2000, 5000, 1, 2, 5, 10, 20,
+};
+
+static int lm363x_regulator_enable_time(struct regulator_dev *rdev)
+{
+   struct lm363x_regulator *lm363x_regulator = rdev_get_drvdata(rdev);
+   enum lm363x_regulator_id id = rdev_get_id(rdev);
+   u8 val, addr, mask;
+
+   switch (id) {
+   case LM3631_LDO_CONT:
+   addr = LM3631_REG_ENTIME_VCONT;
+   mask = LM3631_ENTIME_CONT_MASK;
+   break;
+   case LM3631_LDO_OREF:
+   addr = LM3631_REG_ENTIME_VOREF;
+   mask = LM3631_ENTIME_MASK;
+   break;
+   case LM3631_LDO_POS:
+   addr = LM3631_REG_ENTIME_VPOS;
+   mask = LM3631_ENTIME_MASK;
+   break;
+   case LM3631_LDO_NEG:
+   addr = LM3631_REG_ENTIME_VNEG;
+   mask = LM3631_ENTIME_MASK;
+   break;
+   default:
+   return 0;
+   }
+
+   if (regmap_read(lm363x_regulator->regmap, addr, (unsigned int *)&val))
+   return -EINVAL;
+
+   val = (val & mask) >> LM3631_ENTIME_SHIFT;
+
+   if (id == LM3631_LDO_CONT)
+   return ldo_cont_enable_time[val];
+   else
+   return ENABLE_TIME_USEC * val;
+}
+
+static struct regulator_ops lm363x_boost_voltage_table_ops = {
+   .list_voltage = regulator_list_voltage_li

[PATCH v2 4/9] Documentation: dt-bindings: regulator: add LM363x regulator binding information

[Milo Kim]

This binding describes LM3631 and LM3632 regulator properties.

Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Cc: Lee Jones  
Cc: Jacek Anaszewski 
Cc: Mark Brown 
Cc: linux-l...@vger.kernel.org 
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Milo Kim 
---
 .../bindings/regulator/lm363x-regulator.txt| 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/lm363x-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt 
b/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
new file mode 100644
index 000..8f14df9
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
@@ -0,0 +1,34 @@
+TI LMU LM363x regulator device tree bindings
+
+LM363x regulator driver supports LM3631 and LM3632.
+LM3631 has five regulators and LM3632 supports three regulators.
+
+Required property:
+  - compatible: "ti,lm363x-regulator"
+
+Optional properties:
+  LM3632 has external enable pins for two LDOs.
+  - ti,lcm-en1-gpio: A GPIO specifier for Vpos control pin.
+  - ti,lcm-en2-gpio: A GPIO specifier for Vneg control pin.
+
+Child nodes:
+  LM3631
+  - vboost
+  - vcont
+  - voref
+  - vpos
+  - vneg
+
+  LM3632
+  - vboost
+  - vpos
+  - vneg
+
+  Optional properties of a child node:
+  Each sub-node should contain the constraints and initialization.
+  Please refer to [1].
+
+Examples: Please refer to ti-lmu dt-bindings [2].
+
+[1] ../regulator/regulator.txt
+[2] ../mfd/ti-lmu.txt
-- 
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 7/9] backlight: add TI LMU backlight driver

[Milo Kim]

This is consolidated driver which supports backlight devices below.
  LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.

Structure
-
  It consists of two parts - core and data.

  Core part supports features below.
- Backlight subsystem control
- Channel configuration from DT properties
- Light dimming effect control: ramp up and down.
- LMU fault monitor notifier handling
- PWM brightness control

  Data part describes device specific data.
- Register value configuration for each LMU device
  : initialization, channel configuration, control mode, enable and
brightness.
- PWM action configuration
- Light dimming effect table
- Option for LMU fault monitor support

Macros for register data

  All LMU devices have 8-bit based registers. LMU_BL_REG() creates 24-bit
  register value in data part. It consists of address, mask and value.
  On the other hand, register value should be parsed when the driver
  reads/writes data from/to I2C registers. Driver uses LMU_BL_GET_ADDR(),
  LMU_BL_GET_MASK() and LMU_BL_GET_VAL() for this purpose.

Data structure
--
  ti_lmu_bl: Backlight output channel data
  ti_lmu_bl_chip:Backlight device data. One device can have multiple
 backlight channel data.
  ti_lmu_bl_reg: Backlight device register data
  ti_lmu_bl_cfg: Backlight configuration data for each LMU device

Cc: Lee Jones  
Cc: Jacek Anaszewski 
Cc: Mark Brown 
Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Cc: linux-l...@vger.kernel.org 
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Milo Kim 
---
 drivers/video/backlight/Kconfig |   7 +
 drivers/video/backlight/Makefile|   3 +
 drivers/video/backlight/ti-lmu-backlight-core.c | 649 
 drivers/video/backlight/ti-lmu-backlight-data.c | 287 +++
 include/linux/mfd/ti-lmu-backlight.h| 290 +++
 5 files changed, 1236 insertions(+)
 create mode 100644 drivers/video/backlight/ti-lmu-backlight-core.c
 create mode 100644 drivers/video/backlight/ti-lmu-backlight-data.c
 create mode 100644 include/linux/mfd/ti-lmu-backlight.h

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 5ffa4b4..451d043 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -427,6 +427,13 @@ config BACKLIGHT_SKY81452
  To compile this driver as a module, choose M here: the module will
  be called sky81452-backlight
 
+config BACKLIGHT_TI_LMU
+   tristate "Backlight driver for TI LMU"
+   depends on BACKLIGHT_CLASS_DEVICE && MFD_TI_LMU
+   help
+ Say Y to enable the backlight driver for TI LMU devices.
+ This supports LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.
+
 config BACKLIGHT_TPS65217
tristate "TPS65217 Backlight"
depends on BACKLIGHT_CLASS_DEVICE && MFD_TPS65217
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 16ec534..0f74ce7 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -52,6 +52,9 @@ obj-$(CONFIG_BACKLIGHT_PM8941_WLED)   += pm8941-wled.o
 obj-$(CONFIG_BACKLIGHT_PWM)+= pwm_bl.o
 obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
 obj-$(CONFIG_BACKLIGHT_SKY81452)   += sky81452-backlight.o
+ti-lmu-backlight-objs  := ti-lmu-backlight-core.o \
+  ti-lmu-backlight-data.o
+obj-$(CONFIG_BACKLIGHT_TI_LMU) += ti-lmu-backlight.o
 obj-$(CONFIG_BACKLIGHT_TOSA)   += tosa_bl.o
 obj-$(CONFIG_BACKLIGHT_TPS65217)   += tps65217_bl.o
 obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
diff --git a/drivers/video/backlight/ti-lmu-backlight-core.c 
b/drivers/video/backlight/ti-lmu-backlight-core.c
new file mode 100644
index 000..838e2c2
--- /dev/null
+++ b/drivers/video/backlight/ti-lmu-backlight-core.c
@@ -0,0 +1,649 @@
+/*
+ * TI LMU (Lighting Management Unit) Backlight Driver
+ *
+ * Copyright 2015 Texas Instruments
+ *
+ * Author: Milo Kim 
+ *
+ * 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 
+#include 
+#include 
+
+#define NUM_DUAL_CHANNEL   2
+#define LMU_BACKLIGHT_DUAL_CHANNEL_USED(BIT(0) | BIT(1))
+#define LMU_BACKLIGHT_11BIT_LSB_MASK   (BIT(0) | BIT(1) | BIT(2))
+#define LMU_BACKLIGHT_11BIT_MSB_SHIFT  3
+#define DEFAULT_PWM_NAME   "lmu-backlight"
+
+static int ti_lmu_backlight_enable(struct ti_lmu_bl *lmu_bl, int enable)
+{
+   struct ti_lmu_bl_chip *chip = lmu_bl->chip;
+   struct regmap *regmap = chip->lmu->regmap;
+   unsigned lon

[PATCH v2 3/9] Documentation: dt-bindings: leds: add LM3633 LED binding information

[Milo Kim]

LM3633 LED device is one of TI LMU device list.

Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Cc: Lee Jones  
Cc: Jacek Anaszewski 
Cc: Mark Brown 
Cc: linux-l...@vger.kernel.org 
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Milo Kim 
---
 .../devicetree/bindings/leds/leds-lm3633.txt   | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3633.txt

diff --git a/Documentation/devicetree/bindings/leds/leds-lm3633.txt 
b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
new file mode 100644
index 000..a553894
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
@@ -0,0 +1,24 @@
+TI LMU LM3633 LED device tree bindings
+
+Required properties:
+  - compatible: "ti,lm3633-leds"
+
+Child nodes:
+  Each node matches with LED control bank.
+  Please refer to the datasheet [1].
+
+  Required properties of a child node:
+  - led-sources: List of enabled channels from 0 to 5.
+ Please refer to LED binding [2].
+
+  Optional properties of a child node:
+  - label: LED channel identification. Please refer to LED binding [2].
+  - led-max-microamp: Max current setting. Type is .
+  Unit is microampere. Range is from 5000 to 3.
+  Step is 1000. Please refer to LED binding [2].
+
+Example: Please refer to ti-lmu dt-bindings [3].
+
+[1] http://www.ti.com/product/LM3633/datasheet
+[2] ../leds/common.txt
+[2] ../mfd/ti-lmu.txt
-- 
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 8/9] leds: add LM3633 driver

[Milo Kim]

LM3633 LED driver supports generic LED functions and pattern generation.
Pattern is generated through the sysfs. ABI documentation is also added.

Device creation from device tree

  LED channel name, LED string usage and max current settings are
  configured inside the DT.

LED dimming pattern generation
--
  LM3633 supports programmable dimming pattern generator.
  To enable it, eight attributes are used. Sysfs ABI describes it.
  - Time domain
: 'pattern_time_delay', 'pattern_time_rise', 'pattern_time_high',
  'pattern_time_fall' and 'pattern_time_low'.
  - Level domain
: 'pattern_brightness_low' and 'pattern_brightness_high'.
  - Start or stop
: 'run_pattern'

LMU fault monitor event handling

  As soon as LMU fault monitoring is done, LMU device is reset. So LED
  device should be reinitialized. lm3633_led_fault_monitor_notifier() is
  used for this purpose.

Data structure
--
  ti_lmu_led: LED output channel data.
  ti_lmu_led_chip:LED device data. One LED device can have multiple
  LED channel data.

Cc: Jacek Anaszewski 
Cc: linux-l...@vger.kernel.org 
Cc: Lee Jones  
Cc: Mark Brown 
Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Milo Kim 
---
 Documentation/ABI/testing/sysfs-class-led-lm3633 |  97 +++
 drivers/leds/Kconfig |  10 +
 drivers/leds/Makefile|   1 +
 drivers/leds/leds-lm3633.c   | 840 +++
 4 files changed, 948 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-led-lm3633
 create mode 100644 drivers/leds/leds-lm3633.c

diff --git a/Documentation/ABI/testing/sysfs-class-led-lm3633 
b/Documentation/ABI/testing/sysfs-class-led-lm3633
new file mode 100644
index 000..46217d4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-lm3633
@@ -0,0 +1,97 @@
+LM3633 LED driver generates programmable pattern via the sysfs.
+
+LED Pattern Generator Structure
+
+(3)
+  (a) --->  ___
+   /   \
+  (2) / \ (4)
+  (b) > _/   \_  ...
+   (1)   (5)
+
+ |<-   period   -> |
+
+What:  /sys/class/leds//pattern_time_delay
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+Set pattern startup delay. Please refer to (1).
+Range is from 0 to 9700. Unit is millisecond.
+
+What:  /sys/class/leds//pattern_time_rise
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+Set pattern rising dimming time. Please refer to (2).
+Range is from 0 to 16000. Unit is millisecond.
+
+What:  /sys/class/leds//pattern_time_high
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+Set pattern high level time. Please refer to (3).
+It means how much time stays at high level.
+Range is from 0 to 9700. Unit is millisecond.
+
+What:  /sys/class/leds//pattern_time_fall
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+Set pattern falling dimming time. Please refer to (4).
+Range is from 0 to 16000. Unit is millisecond.
+
+What:  /sys/class/leds//pattern_time_low
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+Set pattern low level time. Please refer to (5).
+It means how much time stays at low level.
+Range is from 0 to 9700. Unit is millisecond.
+
+What:  /sys/class/leds//pattern_brightness_high
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+Set pattern brightness value at high level.
+Please refer to (a). Range is from 0 to max brightness value.
+
+What:  /sys/class/leds//pattern_brightness_low
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+Set pattern brightness value at low level.
+Please refer to (b). Range is from 0 to max brightness value.
+
+What:  /sys/class/leds//run_pattern
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+It is used for activating or deactivating programmed LED
+dimming pattern. Please make sure pattern parameters
+should be written prior to accessing this attribute.
+
+1 : activate programmed pattern
+0 : deactivate th

[PATCH v2 6/9] mfd: add TI LMU hardware fault monitoring driver

[Milo Kim]

LM3633 and LM3697 are TI LMU MFD device.
Those devices have hardware monitoring feature which detects open or
short circuit case.

Debugfs
---
  Two files are created.
open_fault:  check light output channel is open or not.
short_fault: check light output channel is shorted or not.

  The driver checks the status of backlight output channels.
  LM3633 and LM3697 have same sequence to check channels, so common
  functions are used.
  ABI/testing document is also included.

Operations
--
  Two devices have common control flow but register addresses are different.
  The structure, 'ti_lmu_reg' is used for register configuration.

Event notifier
--
  After fault monitoring is done, LMU device is reset. So backlight and
  LED device should be reinitialized. It notifies an event as soon as
  the monitoring is done. Then, LM3633 and LM3697 backlight and LED drivers
  handle this event.

Cc: Lee Jones  
Cc: Jacek Anaszewski 
Cc: Mark Brown 
Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Cc: linux-l...@vger.kernel.org 
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Milo Kim 
---
 .../ABI/testing/debugfs-ti-lmu-fault-monitor   |  32 ++
 drivers/mfd/Kconfig|  10 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/ti-lmu-fault-monitor.c | 405 +
 4 files changed, 448 insertions(+)
 create mode 100644 Documentation/ABI/testing/debugfs-ti-lmu-fault-monitor
 create mode 100644 drivers/mfd/ti-lmu-fault-monitor.c

diff --git a/Documentation/ABI/testing/debugfs-ti-lmu-fault-monitor 
b/Documentation/ABI/testing/debugfs-ti-lmu-fault-monitor
new file mode 100644
index 000..7e39e4a
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-ti-lmu-fault-monitor
@@ -0,0 +1,32 @@
+TI LMU (Lighting Management Unit) Fault Monitoring via the debugfs
+
+LM3633 and LM3697 support hardware fault monitoring which detects
+open or short circuit case.
+
+What:  /sys/kernel/debug/ti-lmu-fault-monitor/open_fault
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   read only
+Check whether light channel works or open circuit is detected.
+
+   Example:
+   cat /sys/kernel/debug/ti-lmu-fault-monitor/open_fault
+
+   Channel 0 works
+   Channel 1 works
+   Channel 2 is open
+
+What:  /sys/kernel/debug/ti-lmu-fault-monitor/short_fault
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   read only
+Check whether light channel works or short circuit is detected.
+
+   Example:
+   cat /sys/kernel/debug/ti-lmu-fault-monitor/short_fault
+
+   Channel 0 is shorted
+   Channel 1 works
+   Channel 2 works
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index a6aab27..e08acba 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1061,6 +1061,16 @@ config MFD_TI_LMU
  It consists of backlight, LED and regulator driver.
  It provides consistent device controls for lighting functions.
 
+config MFD_TI_LMU_FAULT_MONITOR
+   tristate "TI LMU Hardware Fault Monitoring Driver"
+   depends on MFD_TI_LMU && DEBUG_FS
+   help
+ Say Y here to include support for open and short circuit fault
+ detection of TI LMU devices.
+
+ This driver can also be built as a module. If so the module
+ will be called ti-lmu-fault-monitor.
+
 config MFD_OMAP_USB_HOST
bool "TI OMAP USBHS core and TLL driver"
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 10e4bc2..5ddb4e6 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -112,6 +112,7 @@ obj-$(CONFIG_MFD_LP3943)+= lp3943.o
 obj-$(CONFIG_MFD_LP8788)   += lp8788.o lp8788-irq.o
 
 obj-$(CONFIG_MFD_TI_LMU)   += ti-lmu.o
+obj-$(CONFIG_MFD_TI_LMU_FAULT_MONITOR) += ti-lmu-fault-monitor.o
 
 da9055-objs:= da9055-core.o da9055-i2c.o
 obj-$(CONFIG_MFD_DA9055)   += da9055.o
diff --git a/drivers/mfd/ti-lmu-fault-monitor.c 
b/drivers/mfd/ti-lmu-fault-monitor.c
new file mode 100644
index 000..ba65c93
--- /dev/null
+++ b/drivers/mfd/ti-lmu-fault-monitor.c
@@ -0,0 +1,405 @@
+/*
+ * TI LMU (Lighting Management Unit) Hardware Fault Monitoring Driver
+ *
+ * Copyright 2015 Texas Instruments
+ *
+ * Author: Milo Kim 
+ *
+ * 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 
+
+#define LMU_ENABLE_OPEN_MONITORING BIT(0)
+#define LMU_ENABLE_SHORT_MONITORINGBIT(1)
+#define LMU_DEFAULT_BANK  

[PATCH v2 5/9] mfd: add TI LMU driver

[Milo Kim]

TI LMU (Lighting Management Unit) driver supports lighting devices below.

  LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.

LMU devices have common features.
  - I2C interface for accessing device registers
  - Hardware enable pin control
  - Backlight brightness control
  - Notifier for hardware fault monitoring
  - Regulators for LCD display bias

It contains fault monitor, backlight, LED and regulator driver.

LMU fault monitor
-
  LM3633 and LM3697 provide hardware monitoring feature.
  It enables open or short circuit detection.
  After monitoring is done, each device should be re-initialized.
  Notifier is used for this case.
  Please refer to separate patch for 'ti-lmu-fault-monitor'.

Backlight
-
  It's handled by TI LMU backlight consolidated driver and
  chip dependent data. Please refer to separate patches for
  'ti-lmu-backlight'.

LED indicator
-
  LM3633 has 6 indicator LEDs. Programmable dimming pattern is also
  supported. Please refer to separate patch for 'leds-lm3633'.

Regulator
-
  LM3631 has 5 regulators for the display bias.
  LM3632 supports 3 regulators. One consolidated driver enables it.
  Please refer to separate patch for 'lm363x-regulator'.

Cc: Lee Jones  
Cc: Jacek Anaszewski 
Cc: Mark Brown 
Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Cc: linux-l...@vger.kernel.org 
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Milo Kim 
---
 drivers/mfd/Kconfig |  12 ++
 drivers/mfd/Makefile|   2 +
 drivers/mfd/ti-lmu.c| 259 +
 include/linux/mfd/ti-lmu-register.h | 280 
 include/linux/mfd/ti-lmu.h  |  87 +++
 5 files changed, 640 insertions(+)
 create mode 100644 drivers/mfd/ti-lmu.c
 create mode 100644 include/linux/mfd/ti-lmu-register.h
 create mode 100644 include/linux/mfd/ti-lmu.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 4d92df6..a6aab27 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1049,6 +1049,18 @@ config MFD_LP8788
  TI LP8788 PMU supports regulators, battery charger, RTC,
  ADC, backlight driver and current sinks.
 
+config MFD_TI_LMU
+   tristate "TI Lighting Management Unit driver"
+   depends on I2C
+   select MFD_CORE
+   select REGMAP_I2C
+   help
+ Say yes here to enable support for TI LMU chips.
+
+ TI LMU MFD supports LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.
+ It consists of backlight, LED and regulator driver.
+ It provides consistent device controls for lighting functions.
+
 config MFD_OMAP_USB_HOST
bool "TI OMAP USBHS core and TLL driver"
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a8b76b8..10e4bc2 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -111,6 +111,8 @@ obj-$(CONFIG_MFD_AXP20X)+= axp20x.o
 obj-$(CONFIG_MFD_LP3943)   += lp3943.o
 obj-$(CONFIG_MFD_LP8788)   += lp8788.o lp8788-irq.o
 
+obj-$(CONFIG_MFD_TI_LMU)   += ti-lmu.o
+
 da9055-objs:= da9055-core.o da9055-i2c.o
 obj-$(CONFIG_MFD_DA9055)   += da9055.o
 obj-$(CONFIG_MFD_DA9062)   += da9062-core.o
diff --git a/drivers/mfd/ti-lmu.c b/drivers/mfd/ti-lmu.c
new file mode 100644
index 000..aeb1e7d
--- /dev/null
+++ b/drivers/mfd/ti-lmu.c
@@ -0,0 +1,259 @@
+/*
+ * TI LMU (Lighting Management Unit) Core Driver
+ *
+ * Copyright 2015 Texas Instruments
+ *
+ * Author: Milo Kim 
+ *
+ * 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 
+#include 
+
+struct ti_lmu_data {
+   struct mfd_cell *cells;
+   int num_cells;
+   unsigned int max_register;
+};
+
+static int ti_lmu_enable_hw(struct ti_lmu *lmu, enum ti_lmu_id id)
+{
+   int ret;
+
+   if (gpio_is_valid(lmu->en_gpio)) {
+   ret = devm_gpio_request_one(lmu->dev, lmu->en_gpio,
+   GPIOF_OUT_INIT_HIGH, "lmu_hwen");
+   if (ret) {
+   dev_err(lmu->dev, "Can not request enable GPIO: %d\n",
+   ret);
+   return ret;
+   }
+   }
+
+   /* Delay about 1ms after HW enable pin control */
+   usleep_range(1000, 1500);
+
+   /* LM3631 has additional power up sequence - enable LCD_EN bit. */
+   if (id == LM3631) {
+   return regmap_update_bits(lmu->regmap, LM3631_REG_DEVCTRL,
+ LM3631_LCD_EN_MASK,
+ LM3631_LCD_EN_MASK);
+   }
+
+   return 0;
+}
+
+static void ti_lmu_disable_hw(struct t

[PATCH v2 1/9] Documentation: dt-bindings: mfd: add TI LMU device binding information

[Milo Kim]

This patch describes overall binding for TI LMU MFD devices.

Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Cc: Lee Jones  
Cc: Jacek Anaszewski 
Cc: Mark Brown 
Cc: linux-l...@vger.kernel.org 
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Milo Kim 
---
 Documentation/devicetree/bindings/mfd/ti-lmu.txt | 243 +++
 1 file changed, 243 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/ti-lmu.txt

diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt 
b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
new file mode 100644
index 000..c885cf8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
@@ -0,0 +1,243 @@
+TI LMU (Lighting Management Unit) device tree bindings
+
+TI LMU driver supports lighting devices below.
+
+   Name  Child nodes
+  --  -
+  LM3532   Backlight
+  LM3631   Backlight and regulator
+  LM3632   Backlight and regulator
+  LM3633   Backlight, LED and fault monitor
+  LM3695   Backlight
+  LM3697   Backlight and fault monitor
+
+Required properties:
+  - compatible: Should be one of:
+"ti,lm3532"
+"ti,lm3631"
+"ti,lm3632"
+"ti,lm3633"
+"ti,lm3695"
+"ti,lm3697"
+  - reg: I2C slave address.
+ 0x11 for LM3632
+ 0x29 for LM3631
+ 0x36 for LM3633, LM3697
+ 0x38 for LM3532
+ 0x63 for LM3695
+
+Optional property:
+  - enable-gpios: A GPIO specifier for hardware enable pin.
+
+Required node:
+  - backlight: All LMU devices have backlight child nodes.
+   For the properties, please refer to [1].
+
+Optional nodes:
+  - fault-monitor: Hardware fault monitoring driver for LM3633 and LM3697.
+Required properties:
+  - compatible: Should be one of:
+"ti,lm3633-fault-monitor"
+"ti,lm3697-fault-monitor"
+  - leds: LED properties for LM3633. Please refer to [2].
+  - regulators: Regulator properties for LM3631 and LM3632.
+Please refer to [3].
+
+[1] ../leds/backlight/ti-lmu-backlight.txt
+[2] ../leds/leds-lm3633.txt
+[3] ../regulator/lm363x-regulator.txt
+
+lm3532@38 {
+   compatible = "ti,lm3532";
+   reg = <0x38>;
+
+   enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>;
+
+   backlight {
+   compatible = "ti,lm3532-backlight";
+
+   lcd {
+   led-sources = <0 1 2>;
+   ramp-up-msec = <30>;
+   ramp-down-msec = <0>;
+   };
+   };
+};
+
+lm3631@29 {
+   compatible = "ti,lm3631";
+   reg = <0x29>;
+
+   regulators {
+   compatible = "ti,lm363x-regulator";
+
+   vboost {
+   regulator-name = "lcd_boost";
+   regulator-min-microvolt = <450>;
+   regulator-max-microvolt = <635>;
+   regulator-always-on;
+   };
+
+   vcont {
+   regulator-name = "lcd_vcont";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   };
+
+   voref {
+   regulator-name = "lcd_voref";
+   regulator-min-microvolt = <400>;
+   regulator-max-microvolt = <600>;
+   };
+
+   vpos {
+   regulator-name = "lcd_vpos";
+   regulator-min-microvolt = <400>;
+   regulator-max-microvolt = <600>;
+   regulator-boot-on;
+   };
+
+   vneg {
+   regulator-name = "lcd_vneg";
+   regulator-min-microvolt = <400>;
+   regulator-max-microvolt = <600>;
+   regulator-boot-on;
+   };
+   };
+
+   backlight {
+   compatible = "ti,lm3631-backlight";
+
+   lcd_bl {
+   led-sources = <0 1>;
+   ramp-up-msec = <300>;
+   };
+   };
+};
+
+lm3632@11 {
+   compatible = "ti,lm3632";
+   reg = <0x11>;
+
+   enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>; /* PC2 */
+
+   regulators {
+   compatible = "ti,lm363x-regulator";
+
+   ti,lcm-en1-gpio = <&pioC 0 GPIO_ACTIVE_HIGH>; /* PC0 */
+   ti,lcm-en2-gpio = <&pioC 1 GPIO_ACTIVE_HIGH>; /* PC1 */
+
+   vboost {
+   regulator-name = "lcd_boost";
+   regulator-min-microvolt = <450>;
+   regulator-max-microvolt = <640>;
+   regulator-always-on;
+   };
+
+   vpos {
+   regulator-name = "lcd_vpos";
+   regulator-min

[PATCH v2 0/9] Support TI LMU devices

[Milo Kim]

TI Lighting Management Unit drivers support lighting devices below.

 Enable pin  Backlight  HW fault monitoring  LEDs   Regulators
 --  -  ---    
LM3532   o   o   xx x
LM3631   o   o   xx5 regulators
LM3632   o   o   xx3 regulators
LM3633   o   o   oo x
LM3695   o   o   xx x
LM3697   o   o   ox x

This patch-set consists of several parts below.

  DT bindings: Binding information for each module
  LMU MFD: Device registration and HW enable pin control
  LMU fault monitor  : HW fault monitoring for open and short circuit
  LMU backlight  : Consolidated LMU backlight driver
  LM3633 LED : LED subsystem and dimming pattern generation
   supported
  LM363X regulator   : LM3631 and LM3632 regulator driver for the
   display bias

Updates from v1
---
  * DT bindings
mfd   : Describe complete DT properties.
backlight : Move backlight properties into leds/backlight/.
Use common LED properties like 'led-sources' and 'label'.
hwmon : LMU fault monitoring driver is not HWMON any more.
So related properties are moved into 'ti-lmu' binding.
leds  : Use LED common properties like 'led-sources' and 'label'.

  * MFD
Remove LMU helpers for I2C register access. Each driver uses regmap
helpers instead.

  * LMU fault monitoring driver
In v1, it was HWMON driver but HWMON subsystem maintainer suggested
moving it into MFD because it has no sensor data like temperature or
voltage. Device attributes were replaced with debugfs files because
monitoring should be processed for debug purpose only.

  * Backlight
Six separate driver code was consolidated.
Driver control code is implemented in 'ti-lmu-backlight-core.c'.
Device specific data is defined in 'ti-lmu-backlight-data.c'.
194 lines are saved in v2. The text segment is decreased by removing
duplicate instructions.

Lines of code:
  v1: 1420 (8 files)
  v2: 1226 (3 files)

Size:
  v1:
  text  data  bss  filename
 12202   720   40  drivers/video/backlight/built-in.o
  v2:
  text  data  bss  filename
  6883   712   41  drivers/video/backlight/built-in.o

  * LED
Use single device attribute for LED dimming operation.
Max brightness is determined by DT property, 'led-max-microamp'.
Remove brightness workqueue.

  * Regulator
Use 'of_match' in regulator_desc instead of calling of_regulator_match.
Remove unnecessary OF device ID because MFD core registers a platform
device based on the compatible string.

Milo Kim (9):
  Documentation: dt-bindings: mfd: add TI LMU device binding information
  Documentation: dt-bindings: leds: backlight: add TI LMU backlight
binding information
  Documentation: dt-bindings: leds: add LM3633 LED binding information
  Documentation: dt-bindings: regulator: add LM363x regulator binding
information
  mfd: add TI LMU driver
  mfd: add TI LMU hardware fault monitoring driver
  backlight: add TI LMU backlight driver
  leds: add LM3633 driver
  regulator: add LM363X driver

 .../ABI/testing/debugfs-ti-lmu-fault-monitor   |  32 +
 Documentation/ABI/testing/sysfs-class-led-lm3633   |  97 +++
 .../bindings/leds/backlight/ti-lmu-backlight.txt   |  65 ++
 .../devicetree/bindings/leds/leds-lm3633.txt   |  24 +
 Documentation/devicetree/bindings/mfd/ti-lmu.txt   | 243 ++
 .../bindings/regulator/lm363x-regulator.txt|  34 +
 drivers/leds/Kconfig   |  10 +
 drivers/leds/Makefile  |   1 +
 drivers/leds/leds-lm3633.c | 840 +
 drivers/mfd/Kconfig|  22 +
 drivers/mfd/Makefile   |   3 +
 drivers/mfd/ti-lmu-fault-monitor.c | 405 ++
 drivers/mfd/ti-lmu.c   | 259 +++
 drivers/regulator/Kconfig  |   9 +
 drivers/regulator/Makefile |   1 +
 drivers/regulator/lm363x-regulator.c   | 309 
 drivers/video/backlight/Kconfig|   7 +
 drivers/video/backlight/Makefile   |   3 +
 drivers/video/backlight/ti-lmu-backlight-core.c| 649 
 drivers/video/backlight/ti-lmu-backlight-data.c| 287 +++
 include/linux/mfd/ti-lmu-backlight.h   | 290 +++
 include/linux/mfd/ti-lmu-register.h| 280 +++
 include/linux/mfd/ti-lmu.h |  87 +++
 23 files changed, 3957 insertions(+)
 create mode 100644 Documentation/ABI/te

RE: [PATCH v2 4/4] pinctrl/lantiq: fix up pinmux

[Martin Schiller]

On 11/25/2015 at 11:40 AM, Jonas Gorski wrote:
> Hi
>
> On Wed, Nov 25, 2015 at 11:18 AM, Martin Schiller 
> wrote:
> > From: John Crispin 
> >
> > This patch is included in the openwrt patchset for several years now
> and needs
> > to go upstream as well. It includes the following changes:
> > 1. Fix up inline function call to xway_mux_apply
>
> This really needs an explanation what is being fixed here.

I hope John - as the original author of this patch - can explain
why this change is necessary.

>
> > 2. Fix GPIO Setup of GPIO Port3
>
> This change looks fine.
>
> > 3. Implement gpio_chip.to_irq
>
> These are three different changes (two fixes, one new feature) and
> therefore should be split up into three patches.

As I'm not the author of this patch, I decided to leave it as it is.
But per se you are right, it would be better to split it up.

>
> > Signed-off-by: John Crispin 
> > Signed-off-by: Martin Schiller 
> > ---
>
> Also please provide a changelog for your patches here.

OK.

>
> >  drivers/pinctrl/pinctrl-xway.c | 28 ++--
> >  1 file changed, 26 insertions(+), 2 deletions(-)
> >
>
>
> Jonas

Martin

[PATCH V2] cpufreq: qoriq: Register cooling device based on device tree

[Jia Hongtao]

Register the qoriq cpufreq driver as a cooling device, based on the
thermal device tree framework. When temperature crosses the passive trip
point cpufreq is used to throttle CPUs.

Signed-off-by: Jia Hongtao 
---
Changes for V2:
* Using ->ready callback for cpu cooling device registering.

 drivers/cpufreq/qoriq-cpufreq.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/cpufreq/qoriq-cpufreq.c b/drivers/cpufreq/qoriq-cpufreq.c
index 4f53fa2..a39f868 100644
--- a/drivers/cpufreq/qoriq-cpufreq.c
+++ b/drivers/cpufreq/qoriq-cpufreq.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +34,7 @@
 struct cpu_data {
struct clk **pclk;
struct cpufreq_frequency_table *table;
+   struct thermal_cooling_device *cdev;
 };
 
 /*
@@ -260,6 +262,30 @@ static int qoriq_cpufreq_target(struct cpufreq_policy 
*policy,
return clk_set_parent(policy->clk, parent);
 }
 
+
+static void qoriq_cpufreq_ready(struct cpufreq_policy *policy)
+{
+   struct cpu_data *cpud = policy->driver_data;
+   struct device_node *np = of_get_cpu_node(policy->cpu, NULL);
+
+   if (WARN_ON(!np))
+   return;
+
+   if (of_find_property(np, "#cooling-cells", NULL)) {
+   cpud->cdev = of_cpufreq_cooling_register(np,
+policy->related_cpus);
+
+   if (IS_ERR(cpud->cdev)) {
+   pr_err("Failed to register cooling device cpu%d: %ld\n",
+   policy->cpu, PTR_ERR(cpud->cdev));
+
+   cpud->cdev = NULL;
+   }
+   }
+
+   of_node_put(np);
+}
+
 static struct cpufreq_driver qoriq_cpufreq_driver = {
.name   = "qoriq_cpufreq",
.flags  = CPUFREQ_CONST_LOOPS,
@@ -268,6 +294,7 @@ static struct cpufreq_driver qoriq_cpufreq_driver = {
.verify = cpufreq_generic_frequency_table_verify,
.target_index   = qoriq_cpufreq_target,
.get= cpufreq_generic_get,
+   .ready  = qoriq_cpufreq_ready,
.attr   = cpufreq_generic_attr,
 };
 
-- 
2.1.0.27.g96db324

--
To unsubscribe from this list: send the line "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 11/12] clk: mediatek: Add hdmi_ref HDMI PHY PLL reference clock output

[James Liao]

On Wed, 2015-11-18 at 18:34 +0100, Philipp Zabel wrote:
> The configurable hdmi_ref output of the PLL block is derived from
> the tvdpll_594m clock signal via a configurable PLL post-divider.
> It is used as the PLL reference input to the HDMI PHY module.
> 
> Signed-off-by: Philipp Zabel 

Acked-by: James Liao 

> ---
>  drivers/clk/mediatek/clk-mt8173.c  | 5 +
>  include/dt-bindings/clock/mt8173-clk.h | 3 ++-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/mediatek/clk-mt8173.c 
> b/drivers/clk/mediatek/clk-mt8173.c
> index b305fa2..d7eadda 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -1091,6 +1091,11 @@ static void __init mtk_apmixedsys_init(struct 
> device_node *node)
>   clk_data->clks[cku->id] = clk;
>   }
>  
> + clk = clk_register_divider(NULL, "hdmi_ref", "tvdpll_594m", 0,
> +base + 0x40, 16, 3, CLK_DIVIDER_POWER_OF_TWO,
> +NULL);
> + clk_data->clks[CLK_APMIXED_HDMI_REF] = clk;
> +
>   r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
>   if (r)
>   pr_err("%s(): could not register clock provider: %d\n",
> diff --git a/include/dt-bindings/clock/mt8173-clk.h 
> b/include/dt-bindings/clock/mt8173-clk.h
> index 7956ba1..6094bf7 100644
> --- a/include/dt-bindings/clock/mt8173-clk.h
> +++ b/include/dt-bindings/clock/mt8173-clk.h
> @@ -176,7 +176,8 @@
>  #define CLK_APMIXED_LVDSPLL  13
>  #define CLK_APMIXED_MSDCPLL2 14
>  #define CLK_APMIXED_REF2USB_TX   15
> -#define CLK_APMIXED_NR_CLK   16
> +#define CLK_APMIXED_HDMI_REF 16
> +#define CLK_APMIXED_NR_CLK   17
>  
>  /* INFRA_SYS */
>  


--
To unsubscribe from this list: send the line "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 10/12] clk: mediatek: make dpi0_sel and hdmi_sel not propagate rate changes

[James Liao]

On Wed, 2015-11-18 at 18:34 +0100, Philipp Zabel wrote:
> These muxes are supposed to select a fitting divider after the PLL
> is already set to the correct rate.
> 
> Signed-off-by: Philipp Zabel 

Acked-by: James Liao 

> ---
>  drivers/clk/mediatek/clk-mt8173.c | 4 ++--
>  drivers/clk/mediatek/clk-mtk.h| 7 +--
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/mediatek/clk-mt8173.c 
> b/drivers/clk/mediatek/clk-mt8173.c
> index 227e356..b305fa2 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -558,7 +558,7 @@ static const struct mtk_composite top_muxes[] __initconst 
> = {
>   MUX_GATE(CLK_TOP_ATB_SEL, "atb_sel", atb_parents, 0x0090, 16, 2, 23),
>   MUX_GATE(CLK_TOP_VENC_LT_SEL, "venclt_sel", venc_lt_parents, 0x0090, 
> 24, 4, 31),
>   /* CLK_CFG_6 */
> - MUX_GATE(CLK_TOP_DPI0_SEL, "dpi0_sel", dpi0_parents, 0x00a0, 0, 3, 7),
> + MUX_GATE_FLAGS(CLK_TOP_DPI0_SEL, "dpi0_sel", dpi0_parents, 0x00a0, 0, 
> 3, 7, 0),
>   MUX_GATE(CLK_TOP_IRDA_SEL, "irda_sel", irda_parents, 0x00a0, 8, 2, 15),
>   MUX_GATE(CLK_TOP_CCI400_SEL, "cci400_sel", cci400_parents, 0x00a0, 16, 
> 3, 23),
>   MUX_GATE(CLK_TOP_AUD_1_SEL, "aud_1_sel", aud_1_parents, 0x00a0, 24, 2, 
> 31),
> @@ -569,7 +569,7 @@ static const struct mtk_composite top_muxes[] __initconst 
> = {
>   MUX_GATE(CLK_TOP_SCAM_SEL, "scam_sel", scam_parents, 0x00b0, 24, 2, 31),
>   /* CLK_CFG_12 */
>   MUX_GATE(CLK_TOP_SPINFI_IFR_SEL, "spinfi_ifr_sel", spinfi_ifr_parents, 
> 0x00c0, 0, 3, 7),
> - MUX_GATE(CLK_TOP_HDMI_SEL, "hdmi_sel", hdmi_parents, 0x00c0, 8, 2, 15),
> + MUX_GATE_FLAGS(CLK_TOP_HDMI_SEL, "hdmi_sel", hdmi_parents, 0x00c0, 8, 
> 2, 15, 0),
>   MUX_GATE(CLK_TOP_DPILVDS_SEL, "dpilvds_sel", dpilvds_parents, 0x00c0, 
> 24, 3, 31),
>   /* CLK_CFG_13 */
>   MUX_GATE(CLK_TOP_MSDC50_2_H_SEL, "msdc50_2_h_sel", msdc50_2_h_parents, 
> 0x00d0, 0, 3, 7),
> diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
> index 32d2e45..b607996 100644
> --- a/drivers/clk/mediatek/clk-mtk.h
> +++ b/drivers/clk/mediatek/clk-mtk.h
> @@ -83,7 +83,7 @@ struct mtk_composite {
>   signed char num_parents;
>  };
>  
> -#define MUX_GATE(_id, _name, _parents, _reg, _shift, _width, _gate) {
> \
> +#define MUX_GATE_FLAGS(_id, _name, _parents, _reg, _shift, _width, _gate, 
> _flags) {  \
>   .id = _id,  \
>   .name = _name,  \
>   .mux_reg = _reg,\
> @@ -94,9 +94,12 @@ struct mtk_composite {
>   .divider_shift = -1,\
>   .parent_names = _parents,   \
>   .num_parents = ARRAY_SIZE(_parents),\
> - .flags = CLK_SET_RATE_PARENT,   \
> + .flags = _flags,\
>   }
>  
> +#define MUX_GATE(_id, _name, _parents, _reg, _shift, _width, _gate)  \
> + MUX_GATE_FLAGS(_id, _name, _parents, _reg, _shift, _width, _gate, 
> CLK_SET_RATE_PARENT)
> +
>  #define MUX(_id, _name, _parents, _reg, _shift, _width) {\
>   .id = _id,  \
>   .name = _name,  \


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

arm64: dts: qcom: Add apq8096 dragonboard dts skeletons

[Rajendra Nayak]

Add new dtsi and dts files for the apq8096 dragonboards with just
a serial device used as debug console

Signed-off-by: Rajendra Nayak 
---
Patch applies on top of Stephens' patches to add msm8996 dtsi
https://lkml.org/lkml/2015/11/17/955

 arch/arm64/boot/dts/qcom/Makefile |  2 +-
 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts  | 21 
 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi | 30 +++
 3 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts
 create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi

diff --git a/arch/arm64/boot/dts/qcom/Makefile 
b/arch/arm64/boot/dts/qcom/Makefile
index fa1f661..bd992ef 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -1,5 +1,5 @@
 dtb-$(CONFIG_ARCH_QCOM)+= apq8016-sbc.dtb msm8916-mtp.dtb
-dtb-$(CONFIG_ARCH_QCOM)+= msm8996-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= msm8996-mtp.dtb apq8096-dragonboard.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts 
b/arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts
new file mode 100644
index 000..65f4a6a
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts
@@ -0,0 +1,21 @@
+/*
+ * Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+
+#include "apq8096-dragonboard.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. APQ 8096 DragonBoard";
+   compatible = "qcom,apq8096-dragonboard";
+};
diff --git a/arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi 
b/arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi
new file mode 100644
index 000..9bab5c0
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "msm8996.dtsi"
+
+/ {
+   aliases {
+   serial0 = &blsp2_uart1;
+   };
+
+   chosen {
+   stdout-path = "serial0";
+   };
+
+   soc {
+   serial@75b {
+   status = "okay";
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

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

Re: [PATCH 03/14] DEVICETREE: Add PIC32 clock binding documentation

[Joshua Henderson]

Hi Rob,

On 11/22/2015 2:31 PM, Rob Herring wrote:
> On Fri, Nov 20, 2015 at 05:17:15PM -0700, Joshua Henderson wrote:
>> From: Purna Chandra Mandal 
>>
>> Document the devicetree bindings for the clock driver found on Microchip
>> PIC32 class devices.
>>
>> Signed-off-by: Purna Chandra Mandal 
>> Signed-off-by: Joshua Henderson 
>> ---
>>  .../devicetree/bindings/clock/microchip,pic32.txt  |  263 
>> 
>>  1 file changed, 263 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/clock/microchip,pic32.txt
>>
>> diff --git a/Documentation/devicetree/bindings/clock/microchip,pic32.txt 
>> b/Documentation/devicetree/bindings/clock/microchip,pic32.txt
>> new file mode 100644
>> index 000..4cef72d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/microchip,pic32.txt
>> @@ -0,0 +1,263 @@
>> +Binding for a Clock hardware block found on
>> +certain Microchip PIC32 MCU devices.
>> +
>> +Microchip SoC clocks-node consists of few oscillators, PLL, multiplexer
>> +and few divider nodes.
> 
> [...]
> 
>> +Required properties:
>> +- compatible : should have "microchip,pic32-clk".
>> +- reg : A Base address and length of the register set.
>> +- interrupts : source of interrupt.
>> +
>> +Optional properties (for subnodes):
>> +- #clock-cells: From common clock binding, should be 0.
>> +
>> +- microchip,clock-indices: in multiplexer node clock sources always aren't 
>> linear
>> +and contiguous. This property helps define clock-sources with respect to
>> +the mux clock node.
>> +
>> +- microchip,ignore-unused : ignore gate request even if the gated clock is 
>> unused.
> 
> There is some discussion about this upstream with "critical-clocks" 
> binding. Can you use and wait for that?
> 

The way this is going, we might not have to wait. :)  Is there a patch 
available yet to try it out?  

>> +- microchip,status-bit-mask: bitmask for status check. This will be used to 
>> confirm
>> +particular operation by clock sub-node is completed. It is dependent 
>> sub-node.
>> +- microchip,bit-mask: enable mask, similar to microchip,status-bit-mask.
> 
> We've generally decided not to describe clocks at this level of detail 
> in DT. It's fine though for simple clock trees. This one seems to be 
> borderline IMO.
> 

The binding example is the entire clock tree.  These masks are right from the 
datasheet.  For reference, do you have an example of a better alternative?

>> +- microchip,slew-step: enable frequency slewing(stepping) during rate 
>> change;
>> +applicable only to sys-clock subnode.
> 

Thanks,
Josh

--
To unsubscribe from this list: send the line "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 12/14] DEVICETREE: Add bindings for PIC32 SDHC host controller

[Joshua Henderson]

Hi Rob,

On 11/22/2015 2:57 PM, Rob Herring wrote:
> On Fri, Nov 20, 2015 at 05:17:24PM -0700, Joshua Henderson wrote:
>> From: Andrei Pistirica 
>>
>> Document the devicetree bindings for the SDHC peripheral found on
>> Microchip PIC32 class devices.
>>
>> Signed-off-by: Andrei Pistirica 
>> Signed-off-by: Joshua Henderson 
>> ---
>>  .../devicetree/bindings/mmc/sdhci-pic32.txt|   24 
>> 
>>  1 file changed, 24 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-pic32.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pic32.txt 
>> b/Documentation/devicetree/bindings/mmc/sdhci-pic32.txt
>> new file mode 100644
>> index 000..f16388c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-pic32.txt
>> @@ -0,0 +1,24 @@
>> +* Microchip PIC32 SDHCI Controller
>> +
>> +This file documents differences between the core properties in mmc.txt
>> +and the properties used by the sdhci-pic32 driver.
>> +
>> +Required properties:
>> +- compatible: Should be "microchip,pic32-sdhci"
>> +- reg: Should contain registers location and length
>> +- interrupts: Should contain interrupt
>> +- pinctrl: Should contain pinctrl for data and command lines
>> +
>> +Optional properties:
>> +- no-1-8-v: 1.8V voltage selection not supported
> 
> There's a standard property for this one.
> 

Correct.  This is indeed a standard property that should not be here.  There is 
currently discussion to avoid using this property anyway.

>> +- piomode: disable DMA support
> 
> Proably this one too IIRC.
> 

We will be dropping this.  There are other ways to accomplish the same thing 
outside of DT.

Josh


--
To unsubscribe from this list: send the line "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 v9] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Bharat Kumar Gogada]

> Subject: Re: [PATCH v9] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL
> PCIe Host Controller
> 
> On Wed, 25 Nov 2015 05:40:49 +
> Bharat Kumar Gogada  wrote:
> 
> > > On Thu, 19 Nov 2015 11:05:23 +0530
> > > Bharat Kumar Gogada  wrote:
> > >
> > > > Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> > > >
> > > > Signed-off-by: Bharat Kumar Gogada 
> > > > Signed-off-by: Ravi Kiran Gummaluri 
> > > > Acked-by: Rob Herring 
> > > > ---
> > > > +
> > > > +#define MSI_ADDRESS0xDEED
> > >
> > > How did you pick this value? What if it intersect with some actual RAM?
> > > What if a device actually does DMA to that location?
> > >
> > > Wouldn't it make sense to actually pick a real *device* address (hint:
> > > your MSI controller itself) for this purpose, as the device will
> > > never DMA there?
> > >
> > >
> > We have already mentioned in previous patch discussion, we don't have
> > any device address on our SOC for MSI, that's the reason we are
> > allocating a page for MSI in RAM. Since our memory write is consumed
> > by bridge and doesn't write to memory, you suggested to use some
> > random address,  so using some random address.
> 
> This is becoming painful.
> 
> - "write is consumed by bridge and doesn't write to memory": So why are
>   you using something that has a chance of actually being memory??? Are
>   you in the business of corrupting unsuspecting data?
> 
> - "we don't have any device address on our SOC for MSI": You have
>   plenty, and that's the whole of your device space. *All of it*. So
>   just take the base address of your PCIe controller, and be done with
>   it. Or your UART. Anything that cannot be DMA'ed to from a PCIe
>   device, and that is downstream of your PCIe bridge.
> 
Yes, PCIe controller base will be fine, will send next patch addressing this.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/14] DEVICETREE: Add bindings for PIC32 interrupt controller

[Joshua Henderson]

Hi Rob,

On 11/22/2015 2:14 PM, Rob Herring wrote:
> On Fri, Nov 20, 2015 at 05:17:13PM -0700, Joshua Henderson wrote:
>> From: Cristian Birsan 
>>
>> Document the devicetree bindings for the interrupt controller on Microchip
>> PIC32 class devices. This also adds a header defining associated interrupts
>> and related settings.
>>
>> Signed-off-by: Cristian Birsan 
>> Signed-off-by: Joshua Henderson 
>> ---
>>  .../microchip,pic32mz-evic.txt |   65 ++
>>  .../interrupt-controller/microchip,pic32mz-evic.h  |  238 
>> 
>>  2 files changed, 303 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/interrupt-controller/microchip,pic32mz-evic.txt
>>  create mode 100644 
>> include/dt-bindings/interrupt-controller/microchip,pic32mz-evic.h
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/interrupt-controller/microchip,pic32mz-evic.txt
>>  
>> b/Documentation/devicetree/bindings/interrupt-controller/microchip,pic32mz-evic.txt
>> new file mode 100644
>> index 000..12fb91f
>> --- /dev/null
>> +++ 
>> b/Documentation/devicetree/bindings/interrupt-controller/microchip,pic32mz-evic.txt
>> @@ -0,0 +1,65 @@
>> +Microchip PIC32MZ Interrupt Controller
>> +==
>> +
>> +The Microchip PIC32MZ SOC contains an Enhanced Vectored Interrupt Controller
>> +(EVIC) version 2. It handles internal and external interrupts and provides
>> +support for priority, sub-priority, irq type and polarity.
>> +
>> +Required properties
>> +---
>> +
>> +- compatible: Should be "microchip,evic-v2"
> 
> This should be more specific like "microchip,pic32mz-evic". You can keep 
> this one in addition if you like for matching.
> 
> Rob
> 

Agreed.  Due to feedback, we are settling on microchip,pic32mzda-evic and 
similar for all compatible properties in this patch series.  I don't see a need 
to keep a more abstract name around here if you don't.

Josh


--
To unsubscribe from this list: send the line "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 12/14] DEVICETREE: Add bindings for PIC32 SDHC host controller

[Joshua Henderson]

Hi Sergei,

On 11/21/2015 8:19 AM, Sergei Shtylyov wrote:
> Hello.
> 
> On 11/21/2015 3:17 AM, Joshua Henderson wrote:
> 
>> From: Andrei Pistirica 
>>
>> Document the devicetree bindings for the SDHC peripheral found on
>> Microchip PIC32 class devices.
>>
>> Signed-off-by: Andrei Pistirica 
>> Signed-off-by: Joshua Henderson 
>> ---
>>   .../devicetree/bindings/mmc/sdhci-pic32.txt|   24 
>> 
>>   1 file changed, 24 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-pic32.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pic32.txt 
>> b/Documentation/devicetree/bindings/mmc/sdhci-pic32.txt
>> new file mode 100644
>> index 000..f16388c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-pic32.txt
>> @@ -0,0 +1,24 @@
>> +* Microchip PIC32 SDHCI Controller
>> +
>> +This file documents differences between the core properties in mmc.txt
>> +and the properties used by the sdhci-pic32 driver.
>> +
>> +Required properties:
>> +- compatible: Should be "microchip,pic32-sdhci"
>> +- reg: Should contain registers location and length
>> +- interrupts: Should contain interrupt
>> +- pinctrl: Should contain pinctrl for data and command lines
> 
>This is a required prop, yet the example doesn't contain it?
> 

Ack.  Both the required properties and example need to contain pinctrl-names 
and pinctrl-0, not pinctrl.

>> +
>> +Optional properties:
>> +- no-1-8-v: 1.8V voltage selection not supported
>> +- piomode: disable DMA support
>> +
>> +Example:
>> +
>> +sdhci@1f8ec000 {
>> +compatible = "microchip,pic32-sdhci";
>> +reg = <0x1f8ec000 0x100>;
>> +interrupts = ;
>> +clocks = <&REFCLKO4>, <&PBCLK5>;
>> +clock-names = "base_clk", "sys_clk";
> 
>The "clocks" and "clock-names" props are not documented.
> 
> [...]
> 
> MBR, Sergei
> 

Ack.

Thanks for the feedback,
Josh

--
To unsubscribe from this list: send the line "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] phy-sun4i-usb: Use of_match_node to get model specific config data

[Chen-Yu Tsai]

On Thu, Nov 26, 2015 at 12:50 AM, Hans de Goede  wrote:
> Use of_match_node instead of calling of_device_is_compatible a ton of
> times to get model specific config data.
>
> Signed-off-by: Hans de Goede 
> ---
> Changes in v3:
> -New patch in v3 of this patch-set
> ---
>  drivers/phy/phy-sun4i-usb.c | 130 
> +---
>  1 file changed, 85 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index b12964b..1d8f85d 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -88,12 +88,22 @@
>  #define DEBOUNCE_TIME  msecs_to_jiffies(50)
>  #define POLL_TIME  msecs_to_jiffies(250)
>
> +enum sun4i_usb_phy_type {
> +   sun4i_a10_phy,
> +   sun8i_a33_phy,
> +};
> +
> +struct sun4i_usb_phy_cfg {
> +   int num_phys;
> +   u32 disc_thresh;
> +   enum sun4i_usb_phy_type type;
> +   bool dedicated_clocks;
> +};
> +
>  struct sun4i_usb_phy_data {
> void __iomem *base;
> +   const struct sun4i_usb_phy_cfg *cfg;
> struct mutex mutex;
> -   int num_phys;
> -   u32 disc_thresh;
> -   bool has_a33_phyctl;
> struct sun4i_usb_phy {
> struct phy *phy;
> void __iomem *pmu;
> @@ -164,12 +174,15 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy 
> *phy, u32 addr, u32 data,
>
> mutex_lock(&phy_data->mutex);
>
> -   if (phy_data->has_a33_phyctl) {
> +   switch (phy_data->cfg->type) {
> +   case sun4i_a10_phy:
> +   phyctl = phy_data->base + REG_PHYCTL_A10;

Any reason why this offset isn't incorporated into phy_data?

> +   break;
> +   case sun8i_a33_phy:
> phyctl = phy_data->base + REG_PHYCTL_A33;
> /* A33 needs us to set phyctl to 0 explicitly */
> writel(0, phyctl);
> -   } else {
> -   phyctl = phy_data->base + REG_PHYCTL_A10;
> +   break;
> }
>
> for (i = 0; i < len; i++) {
> @@ -249,7 +262,8 @@ static int sun4i_usb_phy_init(struct phy *_phy)
> sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
>
> /* Disconnect threshold adjustment */
> -   sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL, data->disc_thresh, 2);
> +   sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
> +   data->cfg->disc_thresh, 2);
>
> sun4i_usb_phy_passby(phy, 1);
>
> @@ -476,7 +490,7 @@ static struct phy *sun4i_usb_phy_xlate(struct device *dev,
>  {
> struct sun4i_usb_phy_data *data = dev_get_drvdata(dev);
>
> -   if (args->args[0] >= data->num_phys)
> +   if (args->args[0] >= data->cfg->num_phys)
> return ERR_PTR(-ENODEV);
>
> return data->phys[args->args[0]].phy;
> @@ -499,6 +513,59 @@ static int sun4i_usb_phy_remove(struct platform_device 
> *pdev)
> return 0;
>  }
>
> +static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = {
> +   .num_phys = 3,
> +   .disc_thresh = 3,
> +   .type = sun4i_a10_phy,
> +   .dedicated_clocks = false,
> +};
> +
> +static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
> +   .num_phys = 2,
> +   .disc_thresh = 2,
> +   .type = sun4i_a10_phy,
> +   .dedicated_clocks = false,
> +};
> +
> +static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
> +   .num_phys = 3,
> +   .disc_thresh = 3,
> +   .type = sun4i_a10_phy,
> +   .dedicated_clocks = true,
> +};
> +
> +static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
> +   .num_phys = 3,
> +   .disc_thresh = 2,
> +   .type = sun4i_a10_phy,
> +   .dedicated_clocks = false,
> +};
> +
> +static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
> +   .num_phys = 2,
> +   .disc_thresh = 3,
> +   .type = sun4i_a10_phy,
> +   .dedicated_clocks = true,
> +};
> +
> +static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
> +   .num_phys = 2,
> +   .disc_thresh = 3,
> +   .type = sun8i_a33_phy,
> +   .dedicated_clocks = true,
> +};
> +
> +static const struct of_device_id sun4i_usb_phy_of_match[] = {
> +   { .compatible = "allwinner,sun4i-a10-usb-phy", .data = &sun4i_a10_cfg 
> },
> +   { .compatible = "allwinner,sun5i-a13-usb-phy", .data = &sun5i_a13_cfg 
> },
> +   { .compatible = "allwinner,sun6i-a31-usb-phy", .data = &sun6i_a31_cfg 
> },
> +   { .compatible = "allwinner,sun7i-a20-usb-phy", .data = &sun7i_a20_cfg 
> },
> +   { .compatible = "allwinner,sun8i-a23-usb-phy", .data = &sun8i_a23_cfg 
> },
> +   { .compatible = "allwinner,sun8i-a33-usb-phy", .data = &sun8i_a33_cfg 
> },
> +   { },
> +};
> +MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);
> +
>  static const unsigned int sun4i_usb_phy0_cable[] = {
> EXTCON_USB,
> EXTCON_USB_HOST,
> @@ -511,10 +578,16 @@ static int sun4i_usb_phy_probe(struct platform_device 
> *pdev)
> struct device *dev = &pdev->d

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Frank Rowand]

On 11/25/2015 1:03 PM, Tony Lindgren wrote:
> * Arnd Bergmann  [151125 11:50]:
>> On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote:
>>> * Pali Rohár  [151123 06:46]:
 On Sunday 22 November 2015 07:51:46 Pavel Machek wrote:
> On Wed 2015-11-11 17:10:46, Frank Rowand wrote:
>> Adding devicetree list.
>>
>> Thread starts at
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html
>>
>> On 11/5/2015 8:17 AM, Tony Lindgren wrote:
>>> * Pali Rohár  [151105 03:41]:
 On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote:
> On Monday 12 October 2015 13:45:09 Tony Lindgren wrote:
>> * Pali Rohár  [151012 13:29]:
>>> On Monday 12 October 2015 22:16:40 Tony Lindgren wrote:

 Pali, any news on posting an updated series with the comments
 addressed in this thread? It seems that we all pretty much agree
 what needs to be done.
>>
>> I'm not real happy with the concept of patches 4 and 5 in this series.
>> My concern is that those two patches are using the FDT as a transport
>> mechanism for a binary blob (the atags object).
>
> Umm. Ok. Do you have alternative proposal that works for everyone?
>
> I mean. This discussion was going for quite a long time, and it would
> be nice to have some solution... patch proposal... something.
> Pavel

 Yes, discussion is going for a long time! So should I spend time for
 adding documentation to my solution (this is last one thing which is
 missing)? Or my solution is wrong and somebody else will propose new?
 I do not want to spend time on something which will be rejected and
 discarded.
>>>
>>> At least I don't have better solutions in mind.
>>
>> I would be happier if we could restrict this as much as possible to the
>> boards that need it, as an opt-in. That way it doesn't become an ABI

The feature (in whatever form it takes) should be definitely be highly
restricted and marked as deprecated.

>> for people that don't already rely in this information. How about
>> adding a check the code adds the linux,atags property to do it
>> only for a whitelist of board numbers?
> 
> Or populate /proc/atags only for the ones that need it from machine
> specific init_early?

This is circling back to the first comment from Russell King where
he suggested a legacy file for the N900 which calls save_atags():

Are the ATAGs at a fixed address on the N900?  Can that be handled in
some kind of legacy file for the N900 which calls save_atags() on it, so
we don't end up introducing yet more stuff that we have to maintain into
the distant future?  If not, what about copying a known working atag
structure into a legacy file for the N900?

It seems to me that patches 1, 2, 4, and 5 could be replaced by this
approach.

Regards,

Frank
--
To unsubscribe from this list: send the line "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 03/14] DEVICETREE: Add PIC32 clock binding documentation

[Joshua Henderson]

Hi Arnd,

On 11/21/2015 1:49 PM, Arnd Bergmann wrote:
> On Friday 20 November 2015 17:17:15 Joshua Henderson wrote:
>> +/* PIC32 specific clks */
>> +pic32_clktree {
>> +   #address-cells = <1>;
>> +   #size-cells = <1>;
>> +   reg = <0x1f801200 0x200>;
>> +   compatible = "microchip,pic32-clk";
>> +   interrupts = <12>;
>> +   ranges;
>> +
>> +   /* secondary oscillator; external input on SOSCI pin */
>> +   SOSC:sosc_clk {
>> +   #clock-cells = <0>;
>> +   compatible = "microchip,pic32-sosc";
>> +   clock-frequency = <32768>;
>> +   reg = <0x1f801200 0x10   /* enable reg */
>> +   0x1f801390 0x10>; /* status reg */
>> +   microchip,bit-mask = <0x02>; /* enable mask */
>> +   microchip,status-bit-mask = <0x10>; /* status-mask*/
>> +   };
>>
> 
> If you want to use the reg property in this way for each cell,
> at least use a 'ranges' that only translates the actual registers
> like this
> 
>   ranges = <0 0x1f801200 0x200>
> 
>   sosc_clk {
>   ...
>   reg = <0x000 0x10>, <0x190 0x10>;
>   ...
>   };
> 
>   Arnd
> 

This does indeed seem to be the correct way to use ranges in this case.  
Consider it done.

Thanks for the feedback,
Josh


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

Re: [PATCH v5 0/4] ARM: shmobile: r8a7740/sh73a0 DT Cache Handling

[Simon Horman]

On Wed, Nov 25, 2015 at 09:45:20AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Wed, Nov 25, 2015 at 2:50 AM, Simon Horman  wrote:
> > On Mon, Nov 23, 2015 at 02:55:58PM +0100, Geert Uytterhoeven wrote:
> >> This patch series add minimal L1 and L2 cache descriptions to DT for
> >> r8a7740 and sh73a0, and migrates the shmobile DT-based generic r8a7740
> >> platform from calling l2x0_of_init() to the generic l2c OF
> >> initialization.
> >>
> >> Note that the conversion to the generic l2c OF initialization is not
> >> done yet for sh73a0, as this initializes the L2 cache earlier, breaking
> >> the (fragile) sh73a0 secondary CPU bringup code.
> >>
> >> Also note that this conversion should be done on r8a7778, and r8a7779,
> >> too.
> >
> > Based on your work I have prepared a DT patch for the r8a7779.
> 
> Thanks for following up.
> 
> > I don't think that a C patch is necessary, please correct me if I am wrong.
> 
> Yes you do!
> Without machine_desc.l2x_aux_{val,mask}, the information in DT is not used.
> Cfr. arch/arm/mach-shmobile/setup-r8a7740.c

Thanks, I see "ARM: shmobile: r8a7740: Migrate to generic l2c OF
initialization" with new eyes.

> > Regarding the r8a7778: My reading of the documentation is that although a
> > pl310 L2 cache controller is present it is not available for use as there
> > is no L2 cache memory present. For this reason I do not think any patches
> > are required for the r8a7798.
> 
> I agree after consulting the datasheet.
> 
> >> Dependencies:
> >>   - This series applies to renesas-devel-20151123-v4.4-rc2,
> >>   - Patch 3 depends on patch 1,
> >>   - Patch 4 depends on patch 3.
> >>
> >> Given C code changesets depending on DT changesets in the same branch
> >> are frowned upon, you may want to postpone patches 3 and 4 to v4.6.
> >> Of course I'll sleep better if you just apply all 4 of them now ;-)
> >
> > I have queued up the DT changes for v4.5.
> > And tentatively queued up the C changes for v4.6.
> 
> Thank you!
> 
> 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 1/1] arm64: dts: add all hi6220 i2c nodes

[Xinwei Kong]

hi Shawn,

On 2015/11/25 20:24, Shawn Guo wrote:
> On Wed, Nov 25, 2015 at 05:49:02PM +0800, Xinwei Kong wrote:
>> This patch adds all I2C nodes for the Hi6220 SoC. This hi6220 Soc
>> use this I2C IP of Synopsys Designware for HiKey board.
>>
>> Signed-off-by: Xinwei Kong 
>> Signed-off-by: Chen Feng 
>> ---
>>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 37 
>> +++
>>  1 file changed, 37 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
>> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> index 82d2488..6b591a9 100644
>> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> @@ -208,5 +208,42 @@
>>  clock-names = "uartclk", "apb_pclk";
>>  status = "disabled";
>>  };
>> +
>> +i2c0: i2c@f710 {
>> +compatible = "snps,designware-i2c";
>> +reg = <0x0 0xf710 0x0 0x1000>;
>> +interrupts = <0 44 4>;
>> +clocks = <&sys_ctrl HI6220_I2C0_CLK>;
>> +clock-names = "clk_i2c0";
>> +i2c-sda-hold-time-ns = <300>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&i2c0_pmx_func &i2c0_cfg_func>;
>> +status = "ok";
> 
> Shouldn't it be set "disabled" in .dtsi and let .dts enable
> it per board design?
> 
> Shawn

get it.

thank you
xinwei
> 
>> +};
>> +
>> +i2c1: i2c@f7101000 {
>> +compatible = "snps,designware-i2c";
>> +reg = <0x0 0xf7101000 0x0 0x1000>;
>> +interrupts = <0 45 4>;
>> +clocks = <&sys_ctrl HI6220_I2C1_CLK>;
>> +clock-names = "clk_i2c1";
>> +i2c-sda-hold-time-ns = <300>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&i2c1_pmx_func &i2c1_cfg_func>;
>> +status = "ok";
>> +};
>> +
>> +i2c2: i2c@f7102000 {
>> +compatible = "snps,designware-i2c";
>> +reg = <0x0 0xf7102000 0x0 0x1000>;
>> +interrupts = <0 46 4>;
>> +clocks = <&sys_ctrl HI6220_I2C2_CLK>;
>> +clock-names = "clk_i2c2";
>> +i2c-sda-hold-time-ns = <300>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&i2c2_pmx_func &i2c2_cfg_func>;
>> +status = "ok";
>> +};
>> +
>>  };
>>  };
>> -- 
>> 1.9.1
>>
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
> 
> .
> 

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

Re: [PATCH 3/5] dt-bindings: rockchip-thermal: Support the RK3228/RK3399 SoCs compatible

[Caesar Wang]

在 2015年11月25日 22:56, Heiko Stübner 写道:

Am Mittwoch, 25. November 2015, 15:59:35 schrieb Caesar Wang:

This patchset attempts to new compatible for thermal founding
on RK3228/RK3399 SoCs.

Signed-off-by: Caesar Wang 
---

  Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt index
0dfa60d..af5f802 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -2,8 +2,10 @@

  Required properties:
  - compatible : should be "rockchip,-tsadc"
+   "rockchip,rk3228-tsadc": found on RK3228 SoCs
 "rockchip,rk3288-tsadc": found on RK3288 SoCs
 "rockchip,rk3368-tsadc": found on RK3368 SoCs
+   "rockchip,rk3368-tsadc": found on RK3399 SoCs

copy'n'paste error, should proably be
  "rockchip,rk3399-tsadc": found on RK3399 SoCs


Fixed in next version, thanks!

  - reg : physical base address of the controller and length of memory mapped
region.
  - interrupts : The interrupt number to the cpu. The interrupt specifier
format






--
caesar wang | software engineer | w...@rock-chip.com


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

Re: [PATCH v8 2/2] arm64: dts: mt8173: Add nor flash node

[bayi cheng]

On Thu, 2015-11-26 at 09:20 +0800, Daniel Kurtz wrote:
> Hi Bayi, Matthias,
> 
> Sorry for the late review, one comment below...
> 
> On Wed, Nov 18, 2015 at 11:30 AM, Bayi Cheng  wrote:
> > Add Mediatek nor flash node
> >
> > Signed-off-by: Bayi Cheng 
> > Acked-by: Brian Norris 
> > ---
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 18 +-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> > b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > index 4dd5f93..7988656 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > @@ -387,7 +387,23 @@
> > status = "disabled";
> > };
> >
> > -   i2c3: i2c@1101 {
> > +   nor_flash: spi@1100d000 {
> > +   compatible = "mediatek,mt8173-nor";
> > +   reg = <0 0x1100d000 0 0xe0>;
> > +   clocks = <&pericfg CLK_PERI_SPI>,
> > +<&topckgen CLK_TOP_SPINFI_IFR_SEL>;
> > +   clock-names = "spi", "sf";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   status = "disabled";
> > +
> > +   flash@0 {
> > +   compatible = "jedec,spi-nor";
> > +   reg = <0>;
> > +   };
> 
> I think this flash@0 node represents the flash device present on the
> board and should therefore be moved to the board-specific .dts.
> 
> -Dan
> 
Hi Daniel, Thanks for your comments, and I will fixed it in the next
patch.
> > +   };
> > +
> > +   i2c3: i2c3@1101 {
> > compatible = "mediatek,mt8173-i2c";
> > reg = <0 0x1101 0 0x70>,
> >   <0 0x11000280 0 0x80>;
> > --
> > 1.8.1.1.dirty
> >


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

[PATCH V1] ARM: dts: imx6: Change the clock name for spba clock

[Shengjiu Wang]

Audio IP need the spba clock, but original clock name "dma" is not
accurate, so change it to name "spba". The audio driver has been
using the new name "spba", the binding document has been updated.

Signed-off-by: Shengjiu Wang 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 6 +++---
 arch/arm/boot/dts/imx6sl.dtsi  | 2 +-
 arch/arm/boot/dts/imx6sx.dtsi  | 6 +++---
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 2b6cc8b..9ad5a2d 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -227,7 +227,7 @@
  "rxtx1", "rxtx2",
  "rxtx3", "rxtx4",
  "rxtx5", "rxtx6",
- "rxtx7", "dma";
+ "rxtx7", "spba";
status = "disabled";
};
 
@@ -309,7 +309,7 @@
 <&clks IMX6QDL_CLK_ESAI_EXTAL>,
 <&clks IMX6QDL_CLK_ESAI_IPG>,
 <&clks IMX6QDL_CLK_SPBA>;
-   clock-names = "core", "mem", "extal", 
"fsys", "dma";
+   clock-names = "core", "mem", "extal", 
"fsys", "spba";
dmas = <&sdma 23 21 0>, <&sdma 24 21 0>;
dma-names = "rx", "tx";
status = "disabled";
@@ -378,7 +378,7 @@
"asrck_1", "asrck_2", 
"asrck_3", "asrck_4",
"asrck_5", "asrck_6", 
"asrck_7", "asrck_8",
"asrck_9", "asrck_a", 
"asrck_b", "asrck_c",
-   "asrck_d", "asrck_e", 
"asrck_f", "dma";
+   "asrck_d", "asrck_e", 
"asrck_f", "spba";
dmas = <&sdma 17 23 1>, <&sdma 18 23 
1>, <&sdma 19 23 1>,
<&sdma 20 23 1>, <&sdma 21 23 
1>, <&sdma 22 23 1>;
dma-names = "rxa", "rxb", "rxc",
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index d8ba99f..cba6a44 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -151,7 +151,7 @@
"rxtx1", "rxtx2",
"rxtx3", "rxtx4",
"rxtx5", "rxtx6",
-   "rxtx7", "dma";
+   "rxtx7", "spba";
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 167f77b..afc142e 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -222,7 +222,7 @@
  "rxtx1", "rxtx2",
  "rxtx3", "rxtx4",
  "rxtx5", "rxtx6",
- "rxtx7", "dma";
+ "rxtx7", "spba";
status = "disabled";
};
 
@@ -295,7 +295,7 @@
 <&clks IMX6SX_CLK_ESAI_IPG>,
 <&clks IMX6SX_CLK_SPBA>;
clock-names = "core", "mem", "extal",
- "fsys", "dma";
+ "fsys", "spba";
status = "disabled";
};
 
@@ -348,7 +348,7 @@
 <&clks IMX6SX_CLK_ASRC_IPG>,
 <&clks IMX6SX_CLK_SPDIF>,
 <&clks IMX6SX_CLK_SPBA>;
-   clock-names = "mem", "ipg", "asrck", 
"dma";
+   clock-names = "mem", "ipg", "asrck", 
"spba";
dmas = <&sdma 17 20 1>, <&sdma 18 20 1>,
   <&sdma 19 20 1>, <&sdma 20 20 1>,
   <&sdma 21 20 1>, <&sdma 22 20 1>;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to 

[PATCH v2] arm64: dts: uniphier: add PH1-LD10 SoC/board support

[Masahiro Yamada]

This is the first ARMv8 SoC from Socionext Inc.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Split into a single patch

 MAINTAINERS|   1 +
 arch/arm64/boot/dts/Makefile   |   1 +
 arch/arm64/boot/dts/socionext/Makefile |   4 +
 .../boot/dts/socionext/uniphier-ph1-ld10-ref.dts   |  95 +++
 .../boot/dts/socionext/uniphier-ph1-ld10.dtsi  | 280 +
 .../arm64/boot/dts/socionext/uniphier-pinctrl.dtsi |   1 +
 .../boot/dts/socionext/uniphier-support-card.dtsi  |   1 +
 7 files changed, 383 insertions(+)
 create mode 100644 arch/arm64/boot/dts/socionext/Makefile
 create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
 create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
 create mode 12 arch/arm64/boot/dts/socionext/uniphier-pinctrl.dtsi
 create mode 12 arch/arm64/boot/dts/socionext/uniphier-support-card.dtsi

diff --git a/MAINTAINERS b/MAINTAINERS
index 3f92804..99a1424 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1642,6 +1642,7 @@ F:arch/arm/boot/dts/uniphier*
 F: arch/arm/include/asm/hardware/cache-uniphier.h
 F: arch/arm/mach-uniphier/
 F: arch/arm/mm/cache-uniphier.c
+F: arch/arm64/boot/dts/socionext/
 F: drivers/i2c/busses/i2c-uniphier*
 F: drivers/pinctrl/uniphier/
 F: drivers/tty/serial/8250/8250_uniphier.c
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index eb3c42d..6672a96 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -11,6 +11,7 @@ dts-dirs += marvell
 dts-dirs += mediatek
 dts-dirs += qcom
 dts-dirs += rockchip
+dts-dirs += socionext
 dts-dirs += sprd
 dts-dirs += xilinx
 
diff --git a/arch/arm64/boot/dts/socionext/Makefile 
b/arch/arm64/boot/dts/socionext/Makefile
new file mode 100644
index 000..8d72771
--- /dev/null
+++ b/arch/arm64/boot/dts/socionext/Makefile
@@ -0,0 +1,4 @@
+dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld10-ref.dtb
+
+always := $(dtb-y)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
new file mode 100644
index 000..3e53317
--- /dev/null
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
@@ -0,0 +1,95 @@
+/*
+ * Device Tree Source for UniPhier PH1-LD10 Reference Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * 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/ "uniphier-ph1-ld10.dtsi"
+/include/ "uniphier-support-card.dtsi"
+
+/ {
+   model = "UniPhier PH1-LD10 Reference Board";
+   compatible = "socionext,ph1-ld10-ref", "socionext,ph1-ld10";
+
+   memory {
+   device_type = "memory";
+   reg = <0 0x8000 0 0xc000>;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   aliases {
+   serial0 = &serial0;
+   serial1 = &serial1;
+   serial2 = &serial2;
+   seria

Re: [PATCH 0/4] arm, arm64: uniphier: add a new driver, device tree updates

[Masahiro Yamada]

2015-11-24 18:39 GMT+09:00 Masahiro Yamada :
> Hi Arnd, Olof,
>
> Here is another series for UniPhier SoC family:
>
>  - 1/4: add a new driver.  The UniPhier System Bus is an external bus
> where on-board devices are connected to the SoC.
> (please check if the binding specification is OK.)
>
>  - 2/4: device tree updates to use the driver added by 1/4
>
>  - 3/4: trivial rename of device node names
>
>  - 4/4: initial commit for ARMv8 SoC/Board device trees
>
> Please apply 2/4, 3/4/, 4/4 into the same branch because 4/4 depends on 2/4 
> and 3/4.
> (4/4 creates symbolic links to ARM device trees.)


It looks like 1/4 will take longer, so want to postpone it for now.


I will resend 4/4 as a single patch.


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

Re: [PATCH 1/4] bus: uniphier-system-bus: add UniPhier System Bus Controller driver

[Masahiro Yamada]

Hi Mark,

2015-11-25 2:38 GMT+09:00 Mark Rutland :
> Hi,
>
>> >> +UniPhier System Bus Controller
>> >> +--
>> >> +
>> >> +The UniPhier System Bus Controller is a hardware block with registers 
>> >> that
>> >> +controls the System Bus accessing; how each bank is mapped onto the 
>> >> parent bus,
>> >> +various timing parameters of the bus access, etc.
>> >> +
>> >> +Required properties for System Bus Controller:
>> >> +- compatible: should be "socionext,uniphier-system-bus-controller".
>> >> +- reg: offsets and lengths of the register sets for the device.  It 
>> >> should
>> >> +  contain 2 regions: base & control register, misc register, in this 
>> >> order.
>> >
>> > The example also has a system-bus phandle.
>>
>> Actually, I was wondering which is better to describe the relation between
>> the bus and the controller,  phandle or compatible string..
>
> To describe relationships between nodes, use phandles.
>
> Compatible strings alone cannot define relationships -- you cannot
> encode how multiple instances are related.
>
>> > Is the "misc register" part of the bus controller, or is it a shared
>> > system controller?
>>
>> It is a part of the bus controller, but used for another purpose.
>> (i.e. partly this is syscon.  I know this is strange, but it is
>> what the hardware developers designed.)
>
> Ok. What else is going to need to use this in future?
>
>> > Assuming that the controller and bus are 1-1 related, make this a single
>> > node. e.g.
>> >
>> > system-bus {
>> > compatible = "socionext,uniphier-system-bus";
>> > reg = <0x58c0 0x400>, <0x5980 0x2000>;
>> > #address-cells = <2>;
>> > #size-cells = <1>;
>> > ranges = <1 0x 0x4200 0x0200>,
>> >  <5 0x 0x4800 0x0100>;
>> >
>> > ...
>> > child nodes here
>> > ...
>> >
>> > };
>>
>> Hmm, make sense.  But, I prefer to reflect the hardware structure.
>>
>> The range of System Bus is <0x4000 0x1000>.
>>
>> The register of the System Bus Controller is
>> <0x58c0 0x400>  (and <0x5980 0x2000>)
>>
>>
>> The bus and its controller is different.
>
> So? We always describe the programming interface (i.e. the slave
> interface of the device that responds to the CPU).
>
> There's no need for separate nodes. It only makes the driver more
> complicated.
>
>> >> +static int uniphier_sbc_probe(struct platform_device *pdev)
>> >> +{
>> >> + struct device *dev = &pdev->dev;
>> >> + struct uniphier_sbc_priv *priv;
>> >> + struct resource *regs;
>> >> + struct device_node *bus_np;
>> >> + int child_addrc, addrc, sizec, bank;
>> >> + u64 child_addr, addr, size;
>> >> + const __be32 *ranges;
>> >> + int rlen, rone, ret;
>> >> +
>> >> + bus_np = of_find_compatible_node(NULL, NULL,
>> >> +  "socionext,uniphier-system-bus");
>> >
>> > This is broken if you ever have multiple instances.
>> >
>> > Either use a single node, or if there is a more complex relationship
>> > between busses and their controllers, describe that explicitly with
>> > phandles.
>>
>>
>> Probably, I will stick to phandle in v2.
>
> I would prefer a single node unless there's some other complication
> regarding the relationship of the controller and the bus itself.


OK, i will try the single node way.


-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "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 2/2] arm64: dts: mt8173: Add nor flash node

[Daniel Kurtz]

Hi Bayi, Matthias,

Sorry for the late review, one comment below...

On Wed, Nov 18, 2015 at 11:30 AM, Bayi Cheng  wrote:
> Add Mediatek nor flash node
>
> Signed-off-by: Bayi Cheng 
> Acked-by: Brian Norris 
> ---
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 4dd5f93..7988656 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -387,7 +387,23 @@
> status = "disabled";
> };
>
> -   i2c3: i2c@1101 {
> +   nor_flash: spi@1100d000 {
> +   compatible = "mediatek,mt8173-nor";
> +   reg = <0 0x1100d000 0 0xe0>;
> +   clocks = <&pericfg CLK_PERI_SPI>,
> +<&topckgen CLK_TOP_SPINFI_IFR_SEL>;
> +   clock-names = "spi", "sf";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   status = "disabled";
> +
> +   flash@0 {
> +   compatible = "jedec,spi-nor";
> +   reg = <0>;
> +   };

I think this flash@0 node represents the flash device present on the
board and should therefore be moved to the board-specific .dts.

-Dan

> +   };
> +
> +   i2c3: i2c3@1101 {
> compatible = "mediatek,mt8173-i2c";
> reg = <0 0x1101 0 0x70>,
>   <0 0x11000280 0 0x80>;
> --
> 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] ASoC: Atmel: ClassD: add GCK's parent clock in DT binding

[Mark Brown]

On Wed, Nov 25, 2015 at 05:45:24PM -0600, Rob Herring wrote:
> On Mon, Nov 23, 2015 at 05:19:58PM +0800, Songjun Wu wrote:
> > Set GCK's parent as audio clock.

> > Signed-off-by: Songjun Wu 

> Applied, thanks.

I already applied this to the ASoC tree.


signature.asc
Description: PGP signature

Re: [PATCH] ARM: dts: Remove unneeded GPIO include in exynos4412-odroidu3

[Krzysztof Kozlowski]

On 25.11.2015 21:11, Javier Martinez Canillas wrote:
> The  header is already included in the
> exynos4412-odroid-common DTSI so there's no need to do it again
> in the DTS file.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
>  arch/arm/boot/dts/exynos4412-odroidu3.dts | 1 -
>  1 file changed, 1 deletion(-)


Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof


--
To unsubscribe from this list: send the line "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 05/10] Input: synaptics-rmi4: Add device tree support for 2d sensors and F11

[Andrew Duggan]

2D sensors have several parameter which can be set in the platform data.
This patch adds support for getting those values from devicetree.

Signed-off-by: Andrew Duggan 
---
 .../bindings/input/rmi4/rmi_2d_sensor.txt  |  54 +++
 drivers/input/rmi4/rmi_2d_sensor.c | 103 +
 drivers/input/rmi4/rmi_2d_sensor.h |   3 +
 drivers/input/rmi4/rmi_f11.c   |   7 +-
 4 files changed, 166 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt

diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt 
b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
new file mode 100644
index 000..bbff31b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
@@ -0,0 +1,54 @@
+Synaptics RMI4 2D Sensor Device Binding
+
+The Synaptics RMI4 core is able to support RMI4 devices using differnet
+transports and differnet functions. This file describes the device tree
+bindings for devices which contain 2D sensors using Function 11 or
+Function 12. Complete documentation for transports and other functions
+can be found in:
+Documentation/devicetree/bindings/input/rmi4.
+
+RMI4 Function 11 and Function 12 are for 2D touch position sensing.
+Additional documentation for F11 can be found at:
+http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
+
+Optional Properties:
+- syna,swap-axes: Swap X and Y positions when reporting (boolean).
+- syna,flip-x: Reverse the direction of X (boolean).
+- syna,flip-y: Reverse the direction of Y (boolean).
+- syna,clip-x-low: Sets a minimum value for X.
+- syna,clip-y-low: Sets a minimum value for Y.
+- syna,clip-x-high: Sets a maximum value for X.
+- syna,clip-y-high: Sets a maximum value for Y.
+- syna,offset-x: Add an offset to X.
+- syna,offset_y: Add an offset to Y.
+- syna,delta-x-threshold: Set the minimum distance on the X axis required
+   to generate an interrupt in reduced reporting
+   mode.
+- syna,delta-y-threshold: Set the minimum distance on the Y axis required
+   to generate an interrupt in reduced reporting
+   mode.
+- syna,type-a: Report type A multitouch events.
+- syna,sensor-type: Set the sensor type. 1 for touchscreen 2 for touchpad.
+- syna,x-mm: The length in millimeters of the X axis.
+- syna,y-mm: The length in millimeters of the Y axis.
+- syna,disable-report-mask: Mask for disabling posiiton reporting. Used to
+   disable reporing absolute position data.
+- syna,rezero-wait: Time in miliseconds to wait after issuing a rezero
+   command.
+
+
+Example of a RMI4 I2C device with F11:
+Example:
+   &i2c1 {
+   rmi-i2c-dev@2c {
+   compatible = "syna,rmi-i2c";
+
+   ...
+
+   rmi-f11@11 {
+   reg = <0x11>;
+   syna,flip-y;
+   syna,sensor-type = <2>;
+   };
+   };
+   };
diff --git a/drivers/input/rmi4/rmi_2d_sensor.c 
b/drivers/input/rmi4/rmi_2d_sensor.c
index e3c7b7f..427d325 100644
--- a/drivers/input/rmi4/rmi_2d_sensor.c
+++ b/drivers/input/rmi4/rmi_2d_sensor.c
@@ -218,3 +218,106 @@ int rmi_2d_sensor_configure_input(struct rmi_function *fn,
return 0;
 }
 EXPORT_SYMBOL_GPL(rmi_2d_sensor_configure_input);
+
+#ifdef CONFIG_OF
+int rmi_2d_sensor_of_probe(struct device *dev,
+   struct rmi_2d_sensor_platform_data *pdata)
+{
+   int retval;
+
+   pdata->axis_align.swap_axes = of_property_read_bool(dev->of_node,
+   "syna,swap-axes");
+
+   pdata->axis_align.flip_x = of_property_read_bool(dev->of_node,
+   "syna,flip-x");
+
+   pdata->axis_align.flip_y = of_property_read_bool(dev->of_node,
+   "syna,flip-y");
+
+   retval = rmi_of_property_read_u16(dev,
+   &pdata->axis_align.clip_x_low,
+   "syna,clip-x-low", 1);
+   if (retval)
+   return retval;
+
+   retval = rmi_of_property_read_u16(dev,
+   &pdata->axis_align.clip_y_low,
+   "syna,clip-y-low", 1);
+   if (retval)
+   return retval;
+
+   retval = rmi_of_property_read_u16(dev,
+   &pdata->axis_align.clip_x_high,
+   "syna,clip-x-high", 1);
+   if (retval)
+   return retval;
+
+   retval = rmi_of_property_read_u16(dev,
+   &pdata->axis_align.clip_y_high,
+   "syna,clip-y-high", 1);
+   if (retval)
+   return retval;
+
+

[PATCH 03/10] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices

[Andrew Duggan]

Add devicetree binding for I2C devices and add bindings for optional
parameters in the function drivers. Parameters for function drivers are
defined in child nodes for each of the functions.

Signed-off-by: Andrew Duggan 
---
 .../devicetree/bindings/input/rmi4/rmi_f01.txt | 39 
 .../devicetree/bindings/input/rmi4/rmi_i2c.txt | 53 
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 drivers/input/rmi4/rmi_bus.c   | 71 ++
 drivers/input/rmi4/rmi_driver.c| 28 +
 drivers/input/rmi4/rmi_i2c.c   | 12 +++-
 6 files changed, 203 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
 create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt

diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt 
b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
new file mode 100644
index 000..df34dd5
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
@@ -0,0 +1,39 @@
+Synaptics RMI4 F01 Device Binding
+
+The Synaptics RMI4 core is able to support RMI4 devices using differnet
+transports and differnet functions. This file describes the device tree
+bindings for devices which contain Function 1. Complete documentation
+for transports and other functions can be found in:
+Documentation/devicetree/bindings/input/rmi4.
+
+Additional documentation for F01 can be found at:
+http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
+
+Optional Properties:
+- syna,nosleep-mode: If set the device will run at full power without sleeping.
+   nosleep has 3 modes, 0 will not change the default
+   setting, 1 will disable nosleep (allow sleeping),
+   and 2 will enable nosleep (disabling sleep).
+- syna,wakeup-threshold: Defines the amplitude of the disturbance to the
+   background capacitance that will cause the
+   device to wake from dozing.
+- syna,doze-holdoff: The delay to wait after the last finger lift and the
+   first doze cycle (in 0.1 second units).
+- syna,doze-interval: The time period that the device sleeps between finger
+   activity (in 10 ms units).
+
+
+Example of a RMI4 I2C device with F01:
+   Example:
+   &i2c1 {
+   rmi-i2c-dev@2c {
+   compatible = "syna,rmi-i2c";
+
+   ...
+
+   rmi-f01@1 {
+   reg = <0x1>;
+   syna,nosleep-mode = <1>;
+   };
+   };
+   };
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt 
b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
new file mode 100644
index 000..0f4a8e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
@@ -0,0 +1,53 @@
+Synaptics RMI4 I2C Device Binding
+
+The Synaptics RMI4 core is able to support RMI4 devices using differnet
+transports and differnet functions. This file describes the device tree
+bindings for devices using the I2C tranport driver. Complete documentation
+for other transports and functions cen be found ini
+Documentation/devicetree/bindings/input/rmi4.
+
+Required Properties:
+- compatible: syna,rmi-i2c
+- reg: I2C address
+- #address-cells: Set to 1 to indicate that the function child nodes
+   consist of only on uint32 value.
+- #size-cells: Set to 0 to indicate that the function child nodes do not
+   have a size property.
+
+Optional Properties:
+- interrupts: interrupt which the rmi device is connected to.
+- interrupt-parent: The interrupt controller.
+See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+- syna,reset-delay-ms: The number of milliseconds to wait after resetting the
+   device.
+
+Function Parameters:
+Parameters specific to RMI functions are contained in child nodes of the rmi 
device
+ node. Documentation for the parameters of each function can be found in:
+Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt.
+
+
+
+Example:
+   &i2c1 {
+   rmi-i2c-dev@2c {
+   compatible = "syna,rmi-i2c";
+   reg = <0x2c>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupt-parent = <&gpio>;
+   interrupts = <4 2>;
+
+   rmi-f01@1 {
+   reg = <0x1>;
+   syna,nosleep-mode = <1>;
+   };
+
+   rmi-f11@11 {
+   reg = <0x11>;
+   syna,flip-y;
+   syna,sensor-t

[PATCH 09/10] Input: synaptics-rmi4: Add device tree support to the SPI transport driver

[Andrew Duggan]

Add devicetree binding for SPI devices.

Signed-off-by: Andrew Duggan 
---
 .../devicetree/bindings/input/rmi4/rmi_spi.txt | 57 ++
 drivers/input/rmi4/rmi_spi.c   | 44 -
 2 files changed, 100 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt

diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt 
b/Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt
new file mode 100644
index 000..f20366b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt
@@ -0,0 +1,57 @@
+Synaptics RMI4 SPI Device Binding
+
+The Synaptics RMI4 core is able to support RMI4 devices using differnet
+transports and differnet functions. This file describes the device tree
+bindings for devices using the SPI tranport driver. Complete documentation
+for other transports and functions cen be found ini
+Documentation/devicetree/bindings/input/rmi4.
+
+Required Properties:
+- compatible: syna,rmi-spi
+- reg: Chip select address for the device
+- #address-cells: Set to 1 to indicate that the function child nodes
+   consist of only on uint32 value.
+- #size-cells: Set to 0 to indicate that the function child nodes do not
+   have a size property.
+
+Optional Properties:
+- interrupts: interrupt which the rmi device is connected to.
+- interrupt-parent: The interrupt controller.
+See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+- syna,spi-read-delay: millisecond delay between read byte transfers.
+- syna,spi-write-delay: millisecond delay between write byte transfers.
+
+Function Parameters:
+Parameters specific to RMI functions are contained in child nodes of the rmi 
device
+ node. Documentation for the parameters of each function can be found in:
+Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt.
+
+
+
+Example:
+   spi@7000d800 {
+   rmi-spi-dev@0 {
+   compatible = "syna,rmi-spi";
+   reg = <0x0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   spi-max-frequency = <400>;
+   spi-cpha;
+   spi-cpol;
+   interrupt-parent = <&gpio>;
+   interrupts = ;
+   syna,spi-read-delay = <30>;
+
+   rmi-f01@1 {
+   reg = <0x1>;
+   syna,nosleep-mode = <1>;
+   };
+
+   rmi-f11@11 {
+   reg = <0x11>;
+   syna,flip-y;
+   syna,sensor-type = <2>;
+   };
+   };
+   };
diff --git a/drivers/input/rmi4/rmi_spi.c b/drivers/input/rmi4/rmi_spi.c
index 7f9a188..9bdd9cf 100644
--- a/drivers/input/rmi4/rmi_spi.c
+++ b/drivers/input/rmi4/rmi_spi.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "rmi_driver.h"
 
 #define RMI_SPI_DEFAULT_XFER_BUF_SIZE  64
@@ -322,6 +323,41 @@ static const struct rmi_transport_ops rmi_spi_ops = {
.read_block = rmi_spi_read_block,
 };
 
+#ifdef CONFIG_OF
+static int rmi_spi_of_probe(struct spi_device *spi,
+   struct rmi_device_platform_data *pdata)
+{
+   struct device *dev = &spi->dev;
+   int retval;
+
+   retval = rmi_of_property_read_u32(dev,
+   &pdata->spi_data.read_delay_us,
+   "syna,spi-read-delay", 1);
+   if (retval)
+   return retval;
+
+   retval = rmi_of_property_read_u32(dev,
+   &pdata->spi_data.write_delay_us,
+   "syna,spi-write-delay", 1);
+   if (retval)
+   return retval;
+
+   return 0;
+}
+
+static const struct of_device_id rmi_spi_of_match[] = {
+   { .compatible = "syna,rmi-spi" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, rmi_spi_of_match);
+#else
+static inline int rmi_spi_of_probe(struct spi_device *spi,
+   struct rmi_device_platform_data *pdata)
+{
+   return -ENODEV;
+}
+#endif
+
 static int rmi_spi_probe(struct spi_device *spi)
 {
struct rmi_spi_xport *rmi_spi;
@@ -339,8 +375,13 @@ static int rmi_spi_probe(struct spi_device *spi)
 
pdata = &rmi_spi->xport.pdata;
 
-   if (spi_pdata)
+   if (spi->dev.of_node) {
+   retval = rmi_spi_of_probe(spi, pdata);
+   if (retval)
+   return retval;
+   } else if (spi_pdata) {
*pdata = *spi_pdata;
+   }
 
if (pdata->spi_data.bits_per_word)
spi->bits_per_word = pdata->spi_data.bits_per_word;
@@ -407,6 +448,7 @@ static struct spi_driver rmi_spi_driver = {
.driver = {
.owner  = THIS_MODULE,
.name   = "rmi_spi",
+  

Re: [PATCH 2/5] Documentation: devicetree: Add property for controlling power saving mode for the us5182 als sensor

[Rob Herring]

On Wed, Nov 25, 2015 at 11:50:30AM +0200, Adriana Reus wrote:
> 
> 
> On 25.11.2015 02:01, Rob Herring wrote:
> >On Tue, Nov 24, 2015 at 12:59:49PM +0200, Adriana Reus wrote:
> >>Add a property to allow changing the default power-saving mode.
> >>By default, at read raw the chip will activate and provide
> >>one measurent, then it will shut itself down. However, the
> >>chip can also work in "continuous" mode which may be more reliable
> >>but is also more power consuming.
> >>
> >>Signed-off-by: Adriana Reus 
> >>---
> >>  Documentation/devicetree/bindings/iio/light/us5182d.txt | 11 +++
> >>  1 file changed, 11 insertions(+)
> >>
> >>diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt 
> >>b/Documentation/devicetree/bindings/iio/light/us5182d.txt
> >>index 6f0a530..a619799 100644
> >>--- a/Documentation/devicetree/bindings/iio/light/us5182d.txt
> >>+++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
> >>@@ -7,13 +7,24 @@ Required properties:
> >>  Optional properties:
> >>  - upisemi,glass-coef: glass attenuation factor - compensation factor of
> >>resolution 1000 for material transmittance.
> >>+
> >>  - upisemi,dark-ths: array of 8 elements containing 16-bit thresholds (adc
> >>  counts) corresponding to every scale.
> >>+
> >>  - upisemi,upper-dark-gain: 8-bit dark gain compensation factor(4 int and 4
> >> fractional bits - Q4.4) applied when light > 
> >> threshold
> >>+
> >>  - upisemi,lower-dark-gain: 8-bit dark gain compensation factor(4 int and 4
> >> fractional bits - Q4.4) applied when light < 
> >> threshold
> >>
> >>+- upisemi,continuous: This chip has two power modes: one-shot (chip takes 
> >>one
> >>+  measurement and then shuts itself down) and 
> >>continuous (
> >>+  chip takes continuous measurements). The one-shot 
> >>mode is
> >>+  more power-friendly but the continuous mode may be 
> >>more
> >>+  reliable. If this property is specified the 
> >>continuous
> >>+  mode will be used instead of the default one-shot 
> >>one for
> >>+  raw reads.
> >
> >I could imagine an OS may want to decide this on its own or use a
> >mixture of the modes.
> >
> >Rob
> >
> 
> There is no possibility of mixing them up (at the same time), so for example
> proximity cannot work in one mode and als the other.
> 
> The one-shot mode can only be used for raw reads (for example when
> user-space polls in_[proximity|light]_raw). If user-space wants to enable
> events (activate interrupts when certain thresholds are met - patch 5 of the
> series), then the chip has to switch to continuous nonetheless because it
> needs to be active all the time. So one work-flow scenario would be:
> 
> Consumer1 starts polling the raw interface - default_mode
> Consumer2 activates events - continuous mode
> Consumer2 deactivates events - back to default_mode
> 
> The only choice here is the default mode for raw reads, it currently is
> one-shot, this patch allows for continuous to be used if preferred.

Okay, then:

Acked-by: Rob Herring 

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

Re: [PATCH] usb: misc: usb3503: Describe better how to bind clock to the hub

[Rob Herring]

On Sun, Nov 15, 2015 at 11:48:48AM +0100, Michael Trimarchi wrote:
> Signed-off-by: Michael Trimarchi 

Applied, thanks.

Rob

> ---
>  Documentation/devicetree/bindings/usb/usb3503.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt 
> b/Documentation/devicetree/bindings/usb/usb3503.txt
> index 52493b1..c1a0a91 100644
> --- a/Documentation/devicetree/bindings/usb/usb3503.txt
> +++ b/Documentation/devicetree/bindings/usb/usb3503.txt
> @@ -18,7 +18,8 @@ Optional properties:
>  - refclk: Clock used for driving REFCLK signal (optional, if not provided
>   the driver assumes that clock signal is always available, its
>   rate is specified by REF_SEL pins and a value from the primary
> - reference clock frequencies table is used)
> + reference clock frequencies table is used). Use clocks and
> + clock-names in order to assign it
>  - refclk-frequency: Frequency of the REFCLK signal as defined by REF_SEL
>   pins (optional, if not provided, driver will not set rate of the
>   REFCLK signal and assume that a value from the primary reference
> @@ -33,4 +34,6 @@ Examples:
>   intn-gpios = <&gpx3 4 1>;
>   reset-gpios = <&gpx3 5 1>;
>   initial-mode = <1>;
> + clocks = <&clks 80>;
> + clock-names = "refclk";
>   };
> -- 
> 2.6.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] Documentation: fsl-quadspi: Add fsl, ls1021-qspi compatible string

[Rob Herring]

On Wed, Nov 18, 2015 at 05:18:11PM +0800, Yuan Yao wrote:
> new compatible string: "fsl,ls1021-qspi".
> 
> Signed-off-by: Yuan Yao 

Applied, thanks.

Rob

> ---
>  Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt 
> b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
> index 862aa2f..00c587b 100644
> --- a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
> +++ b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
> @@ -2,7 +2,8 @@
>  
>  Required properties:
>- compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
> -  "fsl,imx7d-qspi", "fsl,imx6ul-qspi"
> +  "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
> +  "fsl,ls1021-qspi"
>- reg : the first contains the register location and length,
>the second contains the memory mapping address and length
>- reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
> -- 
> 2.1.0.27.g96db324
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] thermal: rcar: enable to set tripN-temp via DT

[Kuninori Morimoto]

Hi Geert

>  wrote:
> >> Besides, your property is already covered by of-thermal. Please convert
> >> your driver to use of-thermal, this way it will give you the flexibility
> >> to configure thermal data in DT.
> >
> > I see, but we need to keep compatibility for non-DT SoC.
> > (This driver is used from both DT, non-DT SoC)
> 
> Which SoCs with non-DT support use this driver in mainline?

Oops, my bad.
I thought that this driver was used from SH too, but it didn't.

--
To unsubscribe from this list: send the line "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 v3] dt-bindings: Consolidate SRAM bindings from all vendors

[Rob Herring]

On Thu, Nov 19, 2015 at 09:42:49AM +0900, Krzysztof Kozlowski wrote:
> SRAM bindings for various SoCs, using the mmio-sram genalloc
> API, are spread over different places - per SoC vendor. Since all of
> these are quite similar (they depend on mmio-sram) move them to a common
> place.
> 
> Suggested-by: Rob Herring 
> Signed-off-by: Krzysztof Kozlowski 
> Cc: Heiko Stuebner 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: Kukjin Kim 
> Acked-by: Maxime Ripard 
> Acked-by: Heiko Stuebner 

Applied, thanks. I said I would apply for 4.4, but it is not really 
urgent, so I've just applied it for 4.5.

Rob

> 
> ---
> 
> Changes since v2:
> 1. Update paths to sram.txt.
> 
> Changes since v1:
> 1. New patch. Extended suggestion from Rob.
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt  | 2 
> +-
>  .../bindings/{arm/rockchip/pmu-sram.txt => sram/rockchip-pmu-sram.txt}  | 0
>  .../bindings/{arm/rockchip/smp-sram.txt => sram/rockchip-smp-sram.txt}  | 2 
> +-
>  .../bindings/{arm/exynos/smp-sysram.txt => sram/samsung-sram.txt}   | 2 
> +-
>  Documentation/devicetree/bindings/{misc => sram}/sram.txt   | 0
>  .../devicetree/bindings/{soc/sunxi/sram.txt => sram/sunxi-sram.txt} | 2 
> +-
>  6 files changed, 4 insertions(+), 4 deletions(-)
>  rename Documentation/devicetree/bindings/{arm/rockchip/pmu-sram.txt => 
> sram/rockchip-pmu-sram.txt} (100%)
>  rename Documentation/devicetree/bindings/{arm/rockchip/smp-sram.txt => 
> sram/rockchip-smp-sram.txt} (92%)
>  rename Documentation/devicetree/bindings/{arm/exynos/smp-sysram.txt => 
> sram/samsung-sram.txt} (95%)
>  rename Documentation/devicetree/bindings/{misc => sram}/sram.txt (100%)
>  rename Documentation/devicetree/bindings/{soc/sunxi/sram.txt => 
> sram/sunxi-sram.txt} (97%)
> 
> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt 
> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> index 86302de67c2c..313dabdc14f9 100644
> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> @@ -63,7 +63,7 @@ Required properties:
>  - compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
>  
>  The rest of the properties should follow the generic mmio-sram description
> -found in ../../misc/sysram.txt
> +found in ../../sram/sram.txt
>  
>  Each sub-node represents the reserved area for SCPI.
>  
> diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt 
> b/Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
> rename to Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
> diff --git a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt 
> b/Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
> similarity index 92%
> rename from Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
> rename to Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
> index d9416fb8db6f..800701ecffca 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
> +++ b/Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
> @@ -12,7 +12,7 @@ Required sub-node properties:
>  - compatible : should be "rockchip,rk3066-smp-sram"
>  
>  The rest of the properties should follow the generic mmio-sram discription
> -found in ../../misc/sram.txt
> +found in Documentation/devicetree/bindings/sram/sram.txt
>  
>  Example:
>  
> diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt 
> b/Documentation/devicetree/bindings/sram/samsung-sram.txt
> similarity index 95%
> rename from Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
> rename to Documentation/devicetree/bindings/sram/samsung-sram.txt
> index 4a0a4f70a0ce..6bc474b2b885 100644
> --- a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
> +++ b/Documentation/devicetree/bindings/sram/samsung-sram.txt
> @@ -15,7 +15,7 @@ Required sub-node properties:
>   "samsung,exynos4210-sysram-ns" : for Non-secure SYSRAM
>  
>  The rest of the properties should follow the generic mmio-sram discription
> -found in ../../misc/sysram.txt
> +found in Documentation/devicetree/bindings/sram/sram.txt
>  
>  Example:
>  
> diff --git a/Documentation/devicetree/bindings/misc/sram.txt 
> b/Documentation/devicetree/bindings/sram/sram.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/misc/sram.txt
> rename to Documentation/devicetree/bindings/sram/sram.txt
> diff --git a/Documentation/devicetree/bindings/soc/sunxi/sram.txt 
> b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
> similarity index 97%
> rename from Documentation/devicetree/bindings/soc/sunxi/sram.txt
> rename to Documentation/devicetree/bindings/sram/sunxi-sram.txt
> index 067698112f5f..8d5665468fe7 100644
> --- a/Documentation/devicetree/bindings/soc/sunxi/sram.txt
> +++ b/Documentation/devicetree/bindings/sram

Re: [PATCH] DT: add Olimex to vendor prefixes

[Rob Herring]

On Wed, Nov 18, 2015 at 12:20:58PM +, Stefan Wahren wrote:
> This company already provided some products, so add them to the
> vendor prefix list.
> 
> Signed-off-by: Stefan Wahren 

Applied, thanks.

Rob

> ---
>  .../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 55df1d4..a4f20355 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -161,6 +161,7 @@ nuvoton   Nuvoton Technology Corporation
>  nvidia   NVIDIA
>  nxp  NXP Semiconductors
>  okayaOkaya Electric America, Inc.
> +olimex   OLIMEX Ltd.
>  onnn ON Semiconductor Corp.
>  opencoresOpenCores.org
>  option   Option NV
> -- 
> 1.7.9.5
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ASoC: Atmel: ClassD: add GCK's parent clock in DT binding

[Rob Herring]

On Mon, Nov 23, 2015 at 05:19:58PM +0800, Songjun Wu wrote:
> Set GCK's parent as audio clock.
> 
> Signed-off-by: Songjun Wu 

Applied, thanks.

Rob

> ---
> 
>  .../devicetree/bindings/sound/atmel-classd.txt |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/sound/atmel-classd.txt 
> b/Documentation/devicetree/bindings/sound/atmel-classd.txt
> index 0018451..549e701 100644
> --- a/Documentation/devicetree/bindings/sound/atmel-classd.txt
> +++ b/Documentation/devicetree/bindings/sound/atmel-classd.txt
> @@ -16,6 +16,10 @@ Required properties:
>   Required elements: "pclk", "gclk" and "aclk".
>  - clocks
>   Please refer to clock-bindings.txt.
> +- assigned-clocks
> + Should be <&classd_gclk>.
> +- assigned-clock-parents
> + Should be <&audio_pll_pmc>.
>  
>  Optional properties:
>  - pinctrl-names, pinctrl-0
> @@ -43,6 +47,8 @@ classd: classd@fc048000 {
>   dma-names = "tx";
>   clocks = <&classd_clk>, <&classd_gclk>, <&audio_pll_pmc>;
>   clock-names = "pclk", "gclk", "aclk";
> + assigned-clocks = <&classd_gclk>;
> + assigned-clock-parents = <&audio_pll_pmc>;
>  
>   pinctrl-names = "default";
>   pinctrl-0 = <&pinctrl_classd_default>;
> -- 
> 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
--
To unsubscribe from this list: send the line "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] dt-bindings: ARM: add arm,cortex-a72 compatible string

[Rob Herring]

On Tue, Nov 24, 2015 at 08:31:51PM +0900, Masahiro Yamada wrote:
> Signed-off-by: Masahiro Yamada 

Applied, thanks.

Rob

> ---
> 
>  Documentation/devicetree/bindings/arm/cpus.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
> b/Documentation/devicetree/bindings/arm/cpus.txt
> index 3a07a87..58e240d 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -157,6 +157,7 @@ nodes to be present and contain the properties described 
> below.
>   "arm,cortex-a17"
>   "arm,cortex-a53"
>   "arm,cortex-a57"
> + "arm,cortex-a72"
>   "arm,cortex-m0"
>   "arm,cortex-m0+"
>   "arm,cortex-m1"
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] Documentation: dt: Add bindings for Secure-only devices

[Rob Herring]

On Tue, Nov 24, 2015 at 04:06:41PM +, Peter Maydell wrote:
> The existing device tree bindings assume that we are only trying to
> describe a single address space with a device tree (for ARM, either
> the Normal or the Secure world). Some uses for device tree need to
> describe both Normal and Secure worlds in a single device tree. Add
> documentation of how to do this, by adding extra properties which
> describe when a device appears differently in the two worlds or when
> it only appears in one of them.
> 
> The binding describes the general principles for adding new
> properties describing the secure world, but for now we only need a
> single new property, "secure-status", which can be used to annotate
> devices to indicate that they are only visible in one of the two
> worlds.
> 
> The primary expected use of this binding is for a virtual machine
> like QEMU to describe the VM layout to a TrustZone aware firmware
> (which would then use the secure-only devices itself, and pass the DT
> on to a kernel running in the non-secure world, which ignores the
> secure-only devices and uses the rest).
> 
> Signed-off-by: Peter Maydell 
> ---
> This binding doesn't affect the kernel itself, but the kernel
> Documentation/ tree is the de-facto current place where all DT
> bindings are documented, so Grant suggested this was the right
> place to send a doc patch.
> 
> Changes v1->v2:
>  * list all the status/secure-status combinations explicitly
>  * use /* */ comment syntax, not //
> Changes v2->v3:
>  * use secure-foo rather than secure-reg as the example when
>explaining how the prefixing works
>  * say how prefixing a vendor,foo property name works

Applied, thanks.

Rob

> 
>  Documentation/devicetree/bindings/arm/secure.txt | 53 
> 
>  1 file changed, 53 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/secure.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/secure.txt 
> b/Documentation/devicetree/bindings/arm/secure.txt
> new file mode 100644
> index 000..e31303f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/secure.txt
> @@ -0,0 +1,53 @@
> +* ARM Secure world bindings
> +
> +ARM CPUs with TrustZone support have two distinct address spaces,
> +"Normal" and "Secure". Most devicetree consumers (including the Linux
> +kernel) are not TrustZone aware and run entirely in either the Normal
> +world or the Secure world. However some devicetree consumers are
> +TrustZone aware and need to be able to determine whether devices are
> +visible only in the Secure address space, only in the Normal address
> +space, or visible in both. (One example of that situation would be a
> +virtual machine which boots Secure firmware and wants to tell the
> +firmware about the layout of the machine via devicetree.)
> +
> +The general principle of the naming scheme for Secure world bindings
> +is that any property that needs a different value in the Secure world
> +can be supported by prefixing the property name with "secure-". So for
> +instance "secure-foo" would override "foo". For property names with
> +a vendor prefix, the Secure variant of "vendor,foo" would be
> +"vendor,secure-foo". If there is no "secure-" property then the Secure
> +world value is the same as specified for the Normal world by the
> +non-prefixed property. However, only the properties listed below may
> +validly have "secure-" versions; this list will be enlarged on a
> +case-by-case basis.
> +
> +Defining the bindings in this way means that a device tree which has
> +been annotated to indicate the presence of Secure-only devices can
> +still be processed unmodified by existing Non-secure software (and in
> +particular by the kernel).
> +
> +Note that it is still valid for bindings intended for purely Secure
> +world consumers (like kernels that run entirely in Secure) to simply
> +describe the view of Secure world using the standard bindings. These
> +secure- bindings only need to be used where both the Secure and Normal
> +world views need to be described in a single device tree.
> +
> +Valid Secure world properties:
> +
> +- secure-status : specifies whether the device is present and usable
> +  in the secure world. The combination of this with "status" allows
> +  the various possible combinations of device visibility to be
> +  specified. If "secure-status" is not specified it defaults to the
> +  same value as "status"; if "status" is not specified either then
> +  both default to "okay". This means the following combinations are
> +  possible:
> +
> +   /* Neither specified: default to visible in both S and NS */
> +   secure-status = "okay";  /* visible in both */
> +   status = "okay"; /* visible in both */
> +   status = "okay"; secure-status = "okay"; /* visible in both */
> +   secure-status = "disabled";  /* NS-only */
> +   status = "okay"; secure-status = "disabled"; /* NS

Re: [PATCH v9] Documentation: add Device tree bindings for hwmon/nct7802

[Rob Herring]

On Tue, Nov 24, 2015 at 02:09:18AM +0200, Constantine Shulyupin wrote:
> From: Constantine Shulyupin 
> 
> Introduced subnodes sensor, fan and peci with properties.
> 
> Signed-off-by: Constantine Shulyupin 

Acked-by: Rob Herring 

> ---
> Changed in v9:
> - Fixed nuvoton,nct7802-sensor
> - Introduced nuvoton,nct7802-vmon, nuvoton,nct7802-fan-in, 
> nuvoton,nct7802-fan-ctl
> 
> Changed in v8:
> - added senor type "local"
> - Compatible nodes converted to senor types "vcore", "vcc"
> 
> Changed in v7:
> - sensors type (thermistor, thermistor, voltage) and pwm type
> selected with type property instead of compatible property.
> 
> Changed in v6:
> - Removed previous definition.
> - Introduced subnodes sensor, fan and peci with properties.
> 
> Changed in v5:
> - Fixed typos
> 
> Changed in v4:
> - Removed registers initialization by names
> - Added properties nuvoton,sensor*-type
> 
> Changed in v3:
> - Fixed vendor prefix
> - Added short registers description,
>   full registers description is available at
> https://www.nuvoton.com/hq/products/cloud-computing/hardware-monitors/desktop-server-series/nct7802y/
> 
> Changed in v2:
> - Removed nct7802,reg-init
> - Added registers initialization by names
> 
> Introduced in v1:
>  - nct7802,reg-init
> ---
>  .../devicetree/bindings/hwmon/nct7802.txt  | 125 
> +
>  1 file changed, 125 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/nct7802.txt
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/nct7802.txt 
> b/Documentation/devicetree/bindings/hwmon/nct7802.txt
> new file mode 100644
> index 000..cf983b3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/nct7802.txt
> @@ -0,0 +1,125 @@
> +Nuvoton NCT7802Y Hardware Monitoring IC
> +
> +Required node properties:
> +
> + - "compatible": must be "nuvoton,nct7802"
> + - "reg": I2C bus address of the device
> + - #address-cells=<1>;
> + - #size-cells=<0>;
> +
> +Optional subnodes:
> +
> +Sensor subnodes properties:
> + - "compatible", allowed values:
> +  - "nuvoton,nct7802-sensor"
> + - "sensor-type", allowed values:
> + "thermal-diode"
> + "thermistor"
> + "voltage"
> + "local" (only one instance, no "reg" required)
> +For sensors of types "thermal-diode", "thermistor" and "voltage" required
> + - "reg": sensor index in range 0 .. 2
> +
> +Except sensor at address 2 can't be "thermal-diode".
> +
> +Voltage monitor subnodes properties:
> + - "compatible", allowed values:
> +  - "nuvoton,nct7802-vmon"
> + - "vmon-type", allowed values:
> + "vcore"
> + "vcc"
> + - "reg" is not used because there is only one instance of
> + vcore and vcc voltage monitors.
> +
> +Fan subnodes:
> +
> +Fan tachometer subnode (input):
> +
> +Required properties:
> + - "reg" :sensor index of in range 0 .. 2.
> + - "compatible", should be "nuvoton,nct7802-fan-in"
> +
> +Fan PWM (or DC) subnode (output or control):
> +
> +Required properties:
> + - "reg" :sensor index of in range 0 .. 2.
> + - "compatible", should be "nuvoton,nct7802-fan-ctl"
> +Optional boolean properties:
> + - "direct-current" :direct current powered fan instead default PWM
> + - "invert" :inverted polarity
> + - "open-drain" :open-drain output instead push pull
> +
> +Subnode "peci" properties:
> + - "reg" :sensor index in range 0 .. 1
> + - "compatible", should be "nuvoton,nct7802-peci"
> +
> +Not defined sensors, fans and PECI modules will be disabled.
> +
> +Example nct7802 node:
> +
> +nct7802-example@28 {
> + compatible = "nuvoton,nct7802";
> + reg = <0x28>;
> + #address-cells=<1>;
> + #size-cells=<0>;
> + local-sensor {
> + compatible = "nuvoton,nct7802-sensor";
> + sensor-type = "local";
> + };
> + sensor@0 {
> + compatible = "nuvoton,nct7802-sensor";
> + reg = <0>;
> + sensor-type = "thermal-diode";
> + };
> + sensor@1 {
> + compatible = "nuvoton,nct7802-sensor";
> + reg = <1>;
> + sensor-type = "thermistor";
> + };
> + sensor@2 {
> + compatible = "nuvoton,nct7802-sensor";
> + reg = <2>;
> + sensor-type = "voltage";
> + };
> + vcc {
> + compatible = "nuvoton,nct7802-vmon";
> + sensor-type = "vcc";
> + };
> + vcore {
> + compatible = "nuvoton,nct7802-vmon";
> + sensor-type = "vcore";
> + };
> + fan-in@0 {
> + compatible = "nuvoton,nct7802-fan-in";
> + reg = <0>;
> + };
> + fan-in@1 {
> + compatible = "nuvoton,nct7802-fan-in";
> + reg = <1>;
> + };
> + fan-ctl@0 {
> + compatible = "nuvoton,nct7802-fan-ctl";
> + reg = <0>;
> + };
> + dc-fan-ctl@1 {
> + compatible = "nuvoton,nct7802-fan-ctl";
> + reg = <1>;
> + direct-current;
> + open-drain;
> + invert;
> + }

[PATCH (v2) 11/11] watchdog: bcm63xx_wdt: Use brcm,bcm6345-wdt device tree binding

[Simon Arlott]

Add of_match_table for "brcm,bcm6345-wdt".

Use a NULL clock name when not on mach-bcm63xx so that the device tree
clock name does not have to be "periph".

Allow the watchdog to be selected on BMIPS_GENERIC and select the BCM6345
timer interrupt handler.

Signed-off-by: Simon Arlott 
---
Patch 7 split into two patches.

On 25/11/15 02:44, Guenter Roeck wrote:
>> +hw = devm_kzalloc(&pdev->dev, sizeof(*hw), GFP_KERNEL);
>> +wdd = devm_kzalloc(&pdev->dev, sizeof(*wdd), GFP_KERNEL);
> 
> It would be better to allocate wdd as part of struct bcm63xx_wdt_hw.

This altered the context of this patch (was 10/10 now 11/11) because
platform_get_drvdata() is now "hw" instead of "wdd".

 drivers/watchdog/Kconfig   |  3 ++-
 drivers/watchdog/bcm63xx_wdt.c | 14 +-
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 6815b74..0c50add 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1272,8 +1272,9 @@ config OCTEON_WDT
 
 config BCM63XX_WDT
tristate "Broadcom BCM63xx hardware watchdog"
-   depends on BCM63XX
+   depends on BCM63XX || BMIPS_GENERIC
select WATCHDOG_CORE
+   select BCM6345_L2_TIMER_IRQ if BMIPS_GENERIC
help
  Watchdog driver for the built in watchdog hardware in Broadcom
  BCM63xx SoC.
diff --git a/drivers/watchdog/bcm63xx_wdt.c b/drivers/watchdog/bcm63xx_wdt.c
index fa6c28b..4db4145 100644
--- a/drivers/watchdog/bcm63xx_wdt.c
+++ b/drivers/watchdog/bcm63xx_wdt.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,7 +32,11 @@
 
 #define PFX KBUILD_MODNAME
 
-#define WDT_CLK_NAME   "periph"
+#ifdef CONFIG_BCM63XX
+# define WDT_CLK_NAME  "periph"
+#else
+# define WDT_CLK_NAME  NULL
+#endif
 
 struct bcm63xx_wdt_hw {
struct watchdog_device wdd;
@@ -286,12 +291,19 @@ static void bcm63xx_wdt_shutdown(struct platform_device 
*pdev)
bcm63xx_wdt_stop(&hw->wdd);
 }
 
+static const struct of_device_id bcm63xx_wdt_dt_ids[] = {
+   { .compatible = "brcm,bcm6345-wdt" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, bcm63xx_wdt_dt_ids);
+
 static struct platform_driver bcm63xx_wdt_driver = {
.probe  = bcm63xx_wdt_probe,
.remove = bcm63xx_wdt_remove,
.shutdown = bcm63xx_wdt_shutdown,
.driver = {
.name = "bcm63xx-wdt",
+   .of_match_table = bcm63xx_wdt_dt_ids,
}
 };
 
-- 
2.1.4

-- 
Simon Arlott
--
To unsubscribe from this list: send the line "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) 10/11] watchdog: bcm63xx_wdt: Use bcm63xx_timer interrupt directly

[Simon Arlott]

There is only one user of bcm63xx_timer and that is the watchdog.
To allow the watchdog driver to be used on machine types other than
mach-bcm63xx, it needs to use an interrupt instead of a custom register
function.

Modify bcm63xx_timer to only disable the timers (so that they don't
interfere with the watchdog if an interrupt occurs) and remove its
exported functions.

Use the timer interrupt directly in bcm63xx_wdt.

Signed-off-by: Simon Arlott 
---
Patch 7 split into two patches.

There was no change to patch 8/10 which is now 9/11.

On 25/11/15 22:40, Simon Arlott wrote:
> Moved registration of the timer in the probe function to after register
> of the watchdog device because the interrupt handler uses wdd->dev.

This patch (9/10 now 10/11) was affected by this reordering, and an
earlier change to use "hw" instead of "wdd" as the interrupt data.

 arch/mips/bcm63xx/dev-wdt.c|   7 +
 arch/mips/bcm63xx/timer.c  | 181 +
 arch/mips/include/asm/mach-bcm63xx/bcm63xx_timer.h |  11 --
 drivers/watchdog/bcm63xx_wdt.c |  41 +++--
 4 files changed, 36 insertions(+), 204 deletions(-)
 delete mode 100644 arch/mips/include/asm/mach-bcm63xx/bcm63xx_timer.h

diff --git a/arch/mips/bcm63xx/dev-wdt.c b/arch/mips/bcm63xx/dev-wdt.c
index 2a2346a..a7a5497 100644
--- a/arch/mips/bcm63xx/dev-wdt.c
+++ b/arch/mips/bcm63xx/dev-wdt.c
@@ -17,6 +17,11 @@ static struct resource wdt_resources[] = {
.end= -1, /* filled at runtime */
.flags  = IORESOURCE_MEM,
},
+   {
+   .start  = -1, /* filled at runtime */
+   .end= -1, /* filled at runtime */
+   .flags  = IORESOURCE_IRQ,
+   },
 };
 
 static struct platform_device bcm63xx_wdt_device = {
@@ -32,6 +37,8 @@ int __init bcm63xx_wdt_register(void)
wdt_resources[0].end = wdt_resources[0].start;
wdt_resources[0].end += RSET_WDT_SIZE - 1;
 
+   wdt_resources[1].start = bcm63xx_get_irq_number(IRQ_TIMER);
+
return platform_device_register(&bcm63xx_wdt_device);
 }
 arch_initcall(bcm63xx_wdt_register);
diff --git a/arch/mips/bcm63xx/timer.c b/arch/mips/bcm63xx/timer.c
index 2110359..9c7b41a6 100644
--- a/arch/mips/bcm63xx/timer.c
+++ b/arch/mips/bcm63xx/timer.c
@@ -9,196 +9,23 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
-#include 
 #include 
 
-static DEFINE_RAW_SPINLOCK(timer_reg_lock);
-static DEFINE_RAW_SPINLOCK(timer_data_lock);
-static struct clk *periph_clk;
-
-static struct timer_data {
-   void(*cb)(void *);
-   void*data;
-} timer_data[BCM63XX_TIMER_COUNT];
-
-static irqreturn_t timer_interrupt(int irq, void *dev_id)
-{
-   u32 stat;
-   int i;
-
-   raw_spin_lock(&timer_reg_lock);
-   stat = bcm_timer_readl(TIMER_IRQSTAT_REG);
-   bcm_timer_writel(stat, TIMER_IRQSTAT_REG);
-   raw_spin_unlock(&timer_reg_lock);
-
-   for (i = 0; i < BCM63XX_TIMER_COUNT; i++) {
-   if (!(stat & TIMER_IRQSTAT_TIMER_CAUSE(i)))
-   continue;
-
-   raw_spin_lock(&timer_data_lock);
-   if (!timer_data[i].cb) {
-   raw_spin_unlock(&timer_data_lock);
-   continue;
-   }
-
-   timer_data[i].cb(timer_data[i].data);
-   raw_spin_unlock(&timer_data_lock);
-   }
-
-   return IRQ_HANDLED;
-}
-
-int bcm63xx_timer_enable(int id)
-{
-   u32 reg;
-   unsigned long flags;
-
-   if (id >= BCM63XX_TIMER_COUNT)
-   return -EINVAL;
-
-   raw_spin_lock_irqsave(&timer_reg_lock, flags);
-
-   reg = bcm_timer_readl(TIMER_CTLx_REG(id));
-   reg |= TIMER_CTL_ENABLE_MASK;
-   bcm_timer_writel(reg, TIMER_CTLx_REG(id));
-
-   reg = bcm_timer_readl(TIMER_IRQSTAT_REG);
-   reg |= TIMER_IRQSTAT_TIMER_IR_EN(id);
-   bcm_timer_writel(reg, TIMER_IRQSTAT_REG);
-
-   raw_spin_unlock_irqrestore(&timer_reg_lock, flags);
-   return 0;
-}
-
-EXPORT_SYMBOL(bcm63xx_timer_enable);
-
-int bcm63xx_timer_disable(int id)
+static int bcm63xx_timer_init(void)
 {
u32 reg;
-   unsigned long flags;
-
-   if (id >= BCM63XX_TIMER_COUNT)
-   return -EINVAL;
-
-   raw_spin_lock_irqsave(&timer_reg_lock, flags);
-
-   reg = bcm_timer_readl(TIMER_CTLx_REG(id));
-   reg &= ~TIMER_CTL_ENABLE_MASK;
-   bcm_timer_writel(reg, TIMER_CTLx_REG(id));
-
-   reg = bcm_timer_readl(TIMER_IRQSTAT_REG);
-   reg &= ~TIMER_IRQSTAT_TIMER_IR_EN(id);
-   bcm_timer_writel(reg, TIMER_IRQSTAT_REG);
-
-   raw_spin_unlock_irqrestore(&timer_reg_lock, flags);
-   return 0;
-}
-
-EXPORT_SYMBOL(bcm63xx_timer_disable);
-
-int bcm63xx_timer_register(int id, void (*callback)(void *data), void *data)
-{
-   unsigned long flags;
-   int ret;
-
-   if (id >= BCM63XX_TIMER_COUNT || !callback)

Re: [PATCH 01/14] ARM: am437x: cm-t43: dts: add basic support for sbc-t43

[Rob Herring]

On Tue, Nov 24, 2015 at 03:19:02PM +0200, Nikita Kiryanov wrote:
> Add basic support for SBC-T43: a CM-T43 based single board computer.
> CM-T43 is an AM437x based System-on-Module designed to serve as a building
> block in embedded applications. SBC-T43 is composed of CM-T43 module on
> top of the SB-SOM-T43 baseboard.
> Basic support includes UART, GPIO, and I2C.
> 
> Signed-off-by: Nikita Kiryanov 
> Cc: Tony Lindgren 
> Cc: Igor Grinberg 
> Cc: Dmitry Lifshitz 
> Cc: Ian Campbell 

Some minor nits below, otherwise:

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/arm/omap/omap.txt  |  6 ++
>  arch/arm/boot/dts/Makefile |  6 +-
>  arch/arm/boot/dts/am437x-cm-t43.dts| 90 
> ++
>  arch/arm/boot/dts/am437x-sbc-t43.dts   | 57 ++
>  4 files changed, 157 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/boot/dts/am437x-cm-t43.dts
>  create mode 100644 arch/arm/boot/dts/am437x-sbc-t43.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index 9f4e513..da84372 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -141,6 +141,12 @@ Boards:
>  - OMAP5 EVM : Evaluation Module
>compatible = "ti,omap5-evm", "ti,omap5"
>  
> +- AM437x CM-T43
> +  compatible = "compulab,am437x-cm-t43", "ti,am4372", "ti,am43"
> +
> +- AM437x SBC-T43
> +  compatible = 
> "compulab,am437x-sbc-t43","compulab,am437x-cm-t43","ti,am4372","ti,am43"
^
spaces

> +
>  - AM43x EPOS EVM
>compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 30bbc37..dc3b9af 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -478,9 +478,11 @@ dtb-$(CONFIG_ARCH_OMAP4) += \
>   omap4-var-stk-om44.dtb
>  dtb-$(CONFIG_SOC_AM43XX) += \
>   am43x-epos-evm.dtb \
> - am437x-sk-evm.dtb \
> + am437x-cm-t43.dtb \
> + am437x-gp-evm.dtb \
>   am437x-idk-evm.dtb \
> - am437x-gp-evm.dtb
> + am437x-sbc-t43.dtb \
> + am437x-sk-evm.dtb
>  dtb-$(CONFIG_SOC_OMAP5) += \
>   omap5-cm-t54.dtb \
>   omap5-igep0050.dtb \
> diff --git a/arch/arm/boot/dts/am437x-cm-t43.dts 
> b/arch/arm/boot/dts/am437x-cm-t43.dts
> new file mode 100644
> index 000..69887c4
> --- /dev/null
> +++ b/arch/arm/boot/dts/am437x-cm-t43.dts
> @@ -0,0 +1,90 @@
> +/*
> + * Copyright (C) 2015 CompuLab, Ltd. - http://www.compulab.co.il/
> + *
> + * 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.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include 
> +#include "am4372.dtsi"
> +
> +/ {
> + model = "CompuLab CM-T43";
> + compatible = "compulab,am437x-cm-t43","ti,am4372","ti,am43";
  ^
space

[...]

> diff --git a/arch/arm/boot/dts/am437x-sbc-t43.dts 
> b/arch/arm/boot/dts/am437x-sbc-t43.dts
> new file mode 100644
> index 000..f3cd76b
> --- /dev/null
> +++ b/arch/arm/boot/dts/am437x-sbc-t43.dts
> @@ -0,0 +1,57 @@
> +/*
> + * Copyright (C) 2015 CompuLab, Ltd. - http://www.compulab.co.il/
> + *
> + * 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 "am437x-cm-t43.dts"
> +
> +/ {
> + model = "CompuLab CM-T43 on SB-SOM-T43";
> + compatible = 
> "compulab,am437x-sbc-t43","compulab,am437x-cm-t43","ti,am4372","ti,am43";

spaces

--
To unsubscribe from this list: send the line "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 12/14] ARM: sb-som: dts: introduce SB-SOM baseboard

[Rob Herring]

On Tue, Nov 24, 2015 at 03:19:13PM +0200, Nikita Kiryanov wrote:
> CompuLab SB-SOM baseboard is a carrier board for multiple arm-based SoMs.
> It currently supports (with minor adjustments to assembly) CM-T43, CM-T54,
> and CM-QS600 modules. It is a building block in the SBC-T43 single board
> computer, which consists of cm-t43 on top of sb-som-t43.
> 
> Signed-off-by: Nikita Kiryanov 
> Cc: Tony Lindgren 
> Cc: Igor Grinberg 
> Cc: Dmitry Lifshitz 
> Cc: Ian Campbell 
> ---
>  .../devicetree/bindings/arm/compulab-boards.txt|  5 +++
>  .../bindings/display/panel/startek,startek-kd050c  |  4 +++

.txt please.

>  .../devicetree/bindings/vendor-prefixes.txt|  1 +
>  arch/arm/boot/dts/compulab-sb-som.dtsi | 42 
> ++
>  4 files changed, 52 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/compulab-boards.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/startek,startek-kd050c
>  create mode 100644 arch/arm/boot/dts/compulab-sb-som.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/compulab-boards.txt 
> b/Documentation/devicetree/bindings/arm/compulab-boards.txt
> new file mode 100644
> index 000..3e742a5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/compulab-boards.txt
> @@ -0,0 +1,5 @@
> +CompuLab SB-SOM is a multi-module baseboard capable of carrying CM-T43, 
> CM-T54,
> +and QS-600 modules with minor modifications to the SB-SOM assembly.

All these modules have compatible strings?

> +
> +Required root node properties:
> +- compatible = should be "compulab,sb-som"
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c 
> b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c
> new file mode 100644
> index 000..70cd8d1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c
> @@ -0,0 +1,4 @@
> +Startek Electronic Technology Co. KD050C 5.0" WVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "startek,startek-kd050c"
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 55df1d4..409b134 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -218,6 +218,7 @@ sony  Sony Corporation
>  spansion Spansion Inc.
>  sprd Spreadtrum Communications Inc.
>  st   STMicroelectronics
> +startek  Startek
>  ste  ST-Ericsson
>  stericsson   ST-Ericsson
>  synology Synology, Inc.
> diff --git a/arch/arm/boot/dts/compulab-sb-som.dtsi 
> b/arch/arm/boot/dts/compulab-sb-som.dtsi
> new file mode 100644
> index 000..402a143
> --- /dev/null
> +++ b/arch/arm/boot/dts/compulab-sb-som.dtsi
> @@ -0,0 +1,42 @@
> +/*
> + * Copyright (C) 2015 CompuLab, Ltd. - http://www.compulab.co.il/
> + *
> + * 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.
> + */
> +
> +/ {
> + model = "CompuLab SB-SOM";
> + compatible = "compulab,sb-som";

I would expect this to have a more specific.

> + lcd0: display {
> + compatible = "startek,startek-kd050c", "panel-dpi";
> + label = "lcd";

This isn't documented, nor do I think it is needed.

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

[PATCH (v4) 8/11] watchdog: bcm63xx_wdt: Warn if the watchdog is currently running

[Simon Arlott]

Warn when the device is registered if the hardware watchdog is currently
running and report the remaining time left.

Signed-off-by: Simon Arlott 
---
On 25/11/15 02:51, Guenter Roeck wrote:
> This is really two logical changes, isn't it ?

Patch 7 split into two patches.

 drivers/watchdog/bcm63xx_wdt.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/bcm63xx_wdt.c b/drivers/watchdog/bcm63xx_wdt.c
index ab4a794..2312dc2 100644
--- a/drivers/watchdog/bcm63xx_wdt.c
+++ b/drivers/watchdog/bcm63xx_wdt.c
@@ -14,6 +14,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -159,6 +160,8 @@ static int bcm63xx_wdt_probe(struct platform_device *pdev)
struct bcm63xx_wdt_hw *hw;
struct watchdog_device *wdd;
struct resource *r;
+   u32 timeleft1, timeleft2;
+   unsigned int timeleft;
int ret;
 
hw = devm_kzalloc(&pdev->dev, sizeof(*hw), GFP_KERNEL);
@@ -199,7 +202,6 @@ static int bcm63xx_wdt_probe(struct platform_device *pdev)
}
 
raw_spin_lock_init(&hw->lock);
-   hw->running = false;
 
wdd->parent = &pdev->dev;
wdd->ops = &bcm63xx_wdt_ops;
@@ -213,6 +215,23 @@ static int bcm63xx_wdt_probe(struct platform_device *pdev)
watchdog_init_timeout(wdd, 0, &pdev->dev);
watchdog_set_nowayout(wdd, nowayout);
 
+   /* Compare two reads of the time left value, 2 clock ticks apart */
+   rmb();
+   timeleft1 = __raw_readl(hw->regs + WDT_CTL_REG);
+   udelay(DIV_ROUND_UP(100, hw->clock_hz / 2));
+   /* Ensure the register is read twice */
+   rmb();
+   timeleft2 = __raw_readl(hw->regs + WDT_CTL_REG);
+
+   /* If the time left is changing, the watchdog is running */
+   if (timeleft1 != timeleft2) {
+   hw->running = true;
+   timeleft = bcm63xx_wdt_get_timeleft(wdd);
+   } else {
+   hw->running = false;
+   timeleft = 0;
+   }
+
ret = watchdog_register_device(wdd);
if (ret < 0) {
dev_err(&pdev->dev, "failed to register watchdog device\n");
@@ -230,6 +249,8 @@ static int bcm63xx_wdt_probe(struct platform_device *pdev)
dev_name(wdd->dev), hw->regs,
wdd->timeout, wdd->max_timeout);
 
+   if (hw->running)
+   dev_alert(wdd->dev, "running, reboot in %us\n", timeleft);
return 0;
 
 unregister_watchdog:
-- 
2.1.4

-- 
Simon Arlott
--
To unsubscribe from this list: send the line "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) 7/11] watchdog: bcm63xx_wdt: Add get_timeleft function

[Simon Arlott]

Return the remaining time from the hardware control register.

Signed-off-by: Simon Arlott 
---
On 25/11/15 02:51, Guenter Roeck wrote:
> This is really two logical changes, isn't it ?

Patch 7 correctly split into two patches this time.

 drivers/watchdog/bcm63xx_wdt.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/watchdog/bcm63xx_wdt.c b/drivers/watchdog/bcm63xx_wdt.c
index 0a19731..ab4a794 100644
--- a/drivers/watchdog/bcm63xx_wdt.c
+++ b/drivers/watchdog/bcm63xx_wdt.c
@@ -78,6 +78,19 @@ static int bcm63xx_wdt_stop(struct watchdog_device *wdd)
return 0;
 }
 
+static unsigned int bcm63xx_wdt_get_timeleft(struct watchdog_device *wdd)
+{
+   struct bcm63xx_wdt_hw *hw = to_wdt_hw(wdd);
+   unsigned long flags;
+   u32 val;
+
+   raw_spin_lock_irqsave(&hw->lock, flags);
+   val = __raw_readl(hw->regs + WDT_CTL_REG);
+   val /= hw->clock_hz;
+   raw_spin_unlock_irqrestore(&hw->lock, flags);
+   return val;
+}
+
 static int bcm63xx_wdt_set_timeout(struct watchdog_device *wdd,
unsigned int timeout)
 {
@@ -132,6 +145,7 @@ static struct watchdog_ops bcm63xx_wdt_ops = {
.owner = THIS_MODULE,
.start = bcm63xx_wdt_start,
.stop = bcm63xx_wdt_stop,
+   .get_timeleft = bcm63xx_wdt_get_timeleft,
.set_timeout = bcm63xx_wdt_set_timeout,
 };
 
@@ -256,6 +270,7 @@ module_platform_driver(bcm63xx_wdt_driver);
 
 MODULE_AUTHOR("Miguel Gaio ");
 MODULE_AUTHOR("Florian Fainelli ");
+MODULE_AUTHOR("Simon Arlott");
 MODULE_DESCRIPTION("Driver for the Broadcom BCM63xx SoC watchdog");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:bcm63xx-wdt");
-- 
2.1.4

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

[PATCH (v3) 7/11] watchdog: bcm63xx_wdt: Add get_timeleft function

[Simon Arlott]

Return the remaining time from the hardware control register.

Signed-off-by: Simon Arlott 
---
On 25/11/15 02:51, Guenter Roeck wrote:
> This is really two logical changes, isn't it ?

Patch 7 split into two patches.

 drivers/watchdog/bcm63xx_wdt.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/bcm63xx_wdt.c b/drivers/watchdog/bcm63xx_wdt.c
index 0a19731..5615277 100644
--- a/drivers/watchdog/bcm63xx_wdt.c
+++ b/drivers/watchdog/bcm63xx_wdt.c
@@ -14,6 +14,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -78,6 +79,19 @@ static int bcm63xx_wdt_stop(struct watchdog_device *wdd)
return 0;
 }
 
+static unsigned int bcm63xx_wdt_get_timeleft(struct watchdog_device *wdd)
+{
+   struct bcm63xx_wdt_hw *hw = to_wdt_hw(wdd);
+   unsigned long flags;
+   u32 val;
+
+   raw_spin_lock_irqsave(&hw->lock, flags);
+   val = __raw_readl(hw->regs + WDT_CTL_REG);
+   val /= hw->clock_hz;
+   raw_spin_unlock_irqrestore(&hw->lock, flags);
+   return val;
+}
+
 static int bcm63xx_wdt_set_timeout(struct watchdog_device *wdd,
unsigned int timeout)
 {
@@ -132,6 +146,7 @@ static struct watchdog_ops bcm63xx_wdt_ops = {
.owner = THIS_MODULE,
.start = bcm63xx_wdt_start,
.stop = bcm63xx_wdt_stop,
+   .get_timeleft = bcm63xx_wdt_get_timeleft,
.set_timeout = bcm63xx_wdt_set_timeout,
 };
 
@@ -215,7 +230,6 @@ static int bcm63xx_wdt_probe(struct platform_device *pdev)
"%s at MMIO 0x%p (timeout = %us, max_timeout = %us)",
dev_name(wdd->dev), hw->regs,
wdd->timeout, wdd->max_timeout);
-
return 0;
 
 unregister_watchdog:
@@ -256,6 +270,7 @@ module_platform_driver(bcm63xx_wdt_driver);
 
 MODULE_AUTHOR("Miguel Gaio ");
 MODULE_AUTHOR("Florian Fainelli ");
+MODULE_AUTHOR("Simon Arlott");
 MODULE_DESCRIPTION("Driver for the Broadcom BCM63xx SoC watchdog");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:bcm63xx-wdt");
-- 
2.1.4

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

[PATCH (v3) 6/11] watchdog: bcm63xx_wdt: Obtain watchdog clock HZ from "periph" clk

[Simon Arlott]

Instead of using a fixed clock HZ in the driver, obtain it from the
"periph" clk that the watchdog timer uses.

Signed-off-by: Simon Arlott 
---
Patch 7 split into two patches.

On 24/11/15 22:42, Florian Fainelli wrote:
> On 24/11/15 14:12, Simon Arlott wrote:
>> Instead of using a fixed clock HZ in the driver, obtain it from the
>> "periph" clk that the watchdog timer uses.
>> 
>> Signed-off-by: Simon Arlott 
> 
> Reviewed-by: Florian Fainelli 
> 

Changed because of the reordering of timer/watchdog register calls.

 drivers/watchdog/bcm63xx_wdt.c | 36 +++-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/bcm63xx_wdt.c b/drivers/watchdog/bcm63xx_wdt.c
index 2257924..0a19731 100644
--- a/drivers/watchdog/bcm63xx_wdt.c
+++ b/drivers/watchdog/bcm63xx_wdt.c
@@ -13,6 +13,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
+#include 
 #include 
 #include 
 #include 
@@ -32,12 +33,14 @@
 
 #define PFX KBUILD_MODNAME
 
-#define WDT_HZ 5000/* Fclk */
+#define WDT_CLK_NAME   "periph"
 
 struct bcm63xx_wdt_hw {
struct watchdog_device wdd;
raw_spinlock_t lock;
void __iomem *regs;
+   struct clk *clk;
+   unsigned long clock_hz;
bool running;
 };
 
@@ -54,7 +57,7 @@ static int bcm63xx_wdt_start(struct watchdog_device *wdd)
unsigned long flags;
 
raw_spin_lock_irqsave(&hw->lock, flags);
-   bcm_writel(wdd->timeout * WDT_HZ, hw->regs + WDT_DEFVAL_REG);
+   bcm_writel(wdd->timeout * hw->clock_hz, hw->regs + WDT_DEFVAL_REG);
bcm_writel(WDT_START_1, hw->regs + WDT_CTL_REG);
bcm_writel(WDT_START_2, hw->regs + WDT_CTL_REG);
hw->running = true;
@@ -118,7 +121,7 @@ static void bcm63xx_wdt_isr(void *data)
die(PFX ": watchdog timer expired\n", get_irq_regs());
}
 
-   ms = timeleft / (WDT_HZ / 1000);
+   ms = timeleft / (hw->clock_hz / 1000);
dev_alert(hw->wdd.dev,
"warning timer fired, reboot in %ums\n", ms);
}
@@ -162,6 +165,25 @@ static int bcm63xx_wdt_probe(struct platform_device *pdev)
return -ENXIO;
}
 
+   hw->clk = devm_clk_get(&pdev->dev, WDT_CLK_NAME);
+   if (IS_ERR(hw->clk)) {
+   if (PTR_ERR(hw->clk) != -EPROBE_DEFER)
+   dev_err(&pdev->dev, "unable to request clock\n");
+   return PTR_ERR(hw->clk);
+   }
+
+   hw->clock_hz = clk_get_rate(hw->clk);
+   if (!hw->clock_hz) {
+   dev_err(&pdev->dev, "unable to fetch clock rate\n");
+   return -EINVAL;
+   }
+
+   ret = clk_prepare_enable(hw->clk);
+   if (ret) {
+   dev_err(&pdev->dev, "unable to enable clock\n");
+   return ret;
+   }
+
raw_spin_lock_init(&hw->lock);
hw->running = false;
 
@@ -169,7 +191,7 @@ static int bcm63xx_wdt_probe(struct platform_device *pdev)
wdd->ops = &bcm63xx_wdt_ops;
wdd->info = &bcm63xx_wdt_info;
wdd->min_timeout = 1;
-   wdd->max_timeout = 0x / WDT_HZ;
+   wdd->max_timeout = 0x / hw->clock_hz;
wdd->timeout = min(30U, wdd->max_timeout);
 
platform_set_drvdata(pdev, hw);
@@ -180,7 +202,7 @@ static int bcm63xx_wdt_probe(struct platform_device *pdev)
ret = watchdog_register_device(wdd);
if (ret < 0) {
dev_err(&pdev->dev, "failed to register watchdog device\n");
-   return ret;
+   goto disable_clk;
}
 
ret = bcm63xx_timer_register(TIMER_WDT_ID, bcm63xx_wdt_isr, hw);
@@ -198,6 +220,9 @@ static int bcm63xx_wdt_probe(struct platform_device *pdev)
 
 unregister_watchdog:
watchdog_unregister_device(wdd);
+
+disable_clk:
+   clk_disable_unprepare(hw->clk);
return ret;
 }
 
@@ -207,6 +232,7 @@ static int bcm63xx_wdt_remove(struct platform_device *pdev)
 
bcm63xx_timer_unregister(TIMER_WDT_ID);
watchdog_unregister_device(&hw->wdd);
+   clk_disable_unprepare(hw->clk);
return 0;
 }
 
-- 
2.1.4

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

Re: [PATCH 2/3] i2c: at91: add DT property "atmel,twd-hold-cycles" to binding

[Rob Herring]

On Tue, Nov 24, 2015 at 02:47:41PM +0100, Ludovic Desroches wrote:
> From: Wenyou Yang 
> 
> Add a DT property "atmel,twd-hold-cycles" to specify the HOLD
> filed of TWIHS_CWGR register to increase the TWD hold time.
> 
> Signed-off-by: Wenyou Yang 
> Signed-off-by: Ludovic Desroches 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/i2c/i2c-at91.txt | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> index 6e81dc1..c81a0cb 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> @@ -17,6 +17,9 @@ Optional properties:
>  - dma-names: should contain "tx" and "rx".
>  - atmel,fifo-size: maximum number of data the RX and TX FIFOs can store for 
> FIFO
>capable I2C controllers.
> +- atmel,twd-hold-cycles: number of cycles for TWD hold time whose value is
> +  determinated by (atmel,twd-hold-cycles + 3) x t_peripheral_clock,
> +  maximum value is 0x1f.
>  - Child nodes conforming to i2c bus binding
>  
>  Examples :
> @@ -29,6 +32,7 @@ i2c0: i2c@fff84000 {
>   #size-cells = <0>;
>   clocks = <&twi0_clk>;
>   clock-frequency = <40>;
> + atmel,twd-hold-cycles = <2>;
>  
>   24c512@50 {
>   compatible = "24c512";
> -- 
> 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
--
To unsubscribe from this list: send the line "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/6] ARM: OMAP2+: dts: cm-t335: add initial support

[Rob Herring]

On Tue, Nov 24, 2015 at 04:02:08PM +0200, Uri Mashiach wrote:
> From: Ilya Ledvich 
> 
> Add basic support for CompuLab cm-t335 module based on AM335X SoC.
> 
> CM-T335 is a tiny computer-on-module (CoM) / system-on-module (SoM)
> The module is built around the Texas Instruments Sitara AM3352/4
> system-on-chip.
> 
> The CPU is supplemented with up-to 512MB DDR3 and up-to 1GB of on-board
> NAND storage, WiFi connected to SPI, Bluetooth, Analog audio, Gigabit
> Ethernet, CAN bus.
> 
> Current patch adds support:
> UART0 and GPIO LED
> 
> Detailed description can be found at the module site:
> http://www.compulab.co.il/products/computer-on-modules/cm-t335/
> 
> Signed-off-by: Ilya Ledvich 
> [uri.mashi...@compulab.co.il: the default RAM amount reduced to
> 128MB to support also the minimal module configuration]
> Signed-off-by: Uri Mashiach 
> Acked-by: Igor Grinberg 
> ---
> v1 -> v2: integrate AM33XX_IOPAD macro in pinmux definitions

This macro is exactly the kind we should not be doing in DT files which 
are ones that expand to multiple cells. But not really much point in 
doing 1 board differently from the rest, so:

Acked-by: Rob Herring 

Rob

> 
>  .../devicetree/bindings/arm/omap/omap.txt  |  3 ++
>  arch/arm/boot/dts/Makefile |  7 +--
>  arch/arm/boot/dts/am335x-cm-t335.dts   | 63 
> ++
>  3 files changed, 70 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/boot/dts/am335x-cm-t335.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index 9f4e513..2154f97 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -138,6 +138,9 @@ Boards:
>  - AM335X phyBOARD-WEGA: Single Board Computer dev kit
>compatible = "phytec,am335x-wega", "phytec,am335x-phycore-som", "ti,am33xx"
>  
> +- AM335X CM-T335 : System On Module, built around the Sitara AM3352/4
> +  compatible = "compulab,cm-t335", "ti,am33xx"
> +
>  - OMAP5 EVM : Evaluation Module
>compatible = "ti,omap5-evm", "ti,omap5"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index bb8fa02..0e011dc 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -446,13 +446,14 @@ dtb-$(CONFIG_SOC_AM33XX) += \
>   am335x-base0033.dtb \
>   am335x-bone.dtb \
>   am335x-boneblack.dtb \
> - am335x-sl50.dtb \
> + am335x-chiliboard.dtb \
> + am335x-cm-t335.dtb \
>   am335x-evm.dtb \
>   am335x-evmsk.dtb \
> + am335x-lxm.dtb \
>   am335x-nano.dtb \
>   am335x-pepper.dtb \
> - am335x-lxm.dtb \
> - am335x-chiliboard.dtb \
> + am335x-sl50.dtb \
>   am335x-wega-rdk.dtb
>  dtb-$(CONFIG_ARCH_OMAP4) += \
>   omap4-duovero-parlor.dtb \
> diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts 
> b/arch/arm/boot/dts/am335x-cm-t335.dts
> new file mode 100644
> index 000..719658e
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-cm-t335.dts
> @@ -0,0 +1,63 @@
> +/*
> + * am335x-cm-t335.dts - Device Tree file for Compulab CM-T335
> + *
> + * Copyright (C) 2014 - 2015 CompuLab Ltd. - http://www.compulab.co.il/
> + *
> + * 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.
> + */
> +
> +/dts-v1/;
> +
> +#include "am33xx.dtsi"
> +
> +/ {
> + model = "CompuLab CM-T335";
> + compatible = "compulab,cm-t335", "ti,am33xx";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x800>;   /* 128 MB */
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_led_pins>;
> + led@0 {
> + label = "cm_t335:green";
> + gpios = <&gpio2 0 GPIO_ACTIVE_LOW>; /* gpio2_0 */
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +};
> +
> +&am33xx_pinmux {
> + pinctrl-names = "default";
> + pinctrl-0 = <>;
> +
> + gpio_led_pins: pinmux_gpio_led_pins {
> + pinctrl-single,pins = <
> + /* gpmc_csn3.gpio2_0 */
> + AM33XX_IOPAD(0x888, PIN_OUTPUT | MUX_MODE7)
> + >;
> + };
> +
> + uart0_pins: pinmux_uart0_pins {
> + pinctrl-single,pins = <
> + /* uart0_rxd.uart0_rxd */
> + AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0)
> + /* uart0_txd.uart0_txd */
> + AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0)
> + >;
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pins>;
> +
> + status = "okay";
> +};
> +
> -- 
> 2.5.0
> 
--
To unsubscribe from this list: send t

[PATCH (v3) 5/11] watchdog: bcm63xx_wdt: Use WATCHDOG_CORE

[Simon Arlott]

Convert bcm63xx_wdt to use WATCHDOG_CORE.

The default and maximum time constants that are only used once have been
moved to the initialisation of the struct watchdog_device.

Signed-off-by: Simon Arlott 
---
Patch 7 split into two patches.

On 25/11/15 02:44, Guenter Roeck wrote:
> If I see correctly, there is no ping function. In that case, the watchdog core
> will call the start function after updating the timeout, so there is no need
> to do it here.

Fixed.
 
>> +static const struct watchdog_info bcm63xx_wdt_info = {
>> +.options = WDIOC_GETTIMELEFT | WDIOF_SETTIMEOUT |
> 
> Where is the gettimeleft function ? I think you are adding it with a later 
> patch,
> but then you should set the flag there, not here.

Removed WDIOC_GETTIMELEFT completely because it's not a flag.

>> +hw = devm_kzalloc(&pdev->dev, sizeof(*hw), GFP_KERNEL);
>> +wdd = devm_kzalloc(&pdev->dev, sizeof(*wdd), GFP_KERNEL);
> 
> It would be better to allocate wdd as part of struct bcm63xx_wdt_hw.

Fixed.

>> -misc_deregister(&bcm63xx_wdt_miscdev);
>>  bcm63xx_timer_unregister(TIMER_WDT_ID);
>> +watchdog_unregister_device(wdd);
> 
> Shouldn't that come first, before unregistering the timer ?

No, because wdd->dev is used in the interrupt handler. The handler will
not be called after bcm63xx_timer_unregister() is called.

Moved registration of the timer in the probe function to after register
of the watchdog device because the interrupt handler uses wdd->dev.

 drivers/watchdog/Kconfig   |   1 +
 drivers/watchdog/bcm63xx_wdt.c | 259 +
 2 files changed, 79 insertions(+), 181 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 7a8a6c6..6815b74 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1273,6 +1273,7 @@ config OCTEON_WDT
 config BCM63XX_WDT
tristate "Broadcom BCM63xx hardware watchdog"
depends on BCM63XX
+   select WATCHDOG_CORE
help
  Watchdog driver for the built in watchdog hardware in Broadcom
  BCM63xx SoC.
diff --git a/drivers/watchdog/bcm63xx_wdt.c b/drivers/watchdog/bcm63xx_wdt.c
index 3f55cba..2257924 100644
--- a/drivers/watchdog/bcm63xx_wdt.c
+++ b/drivers/watchdog/bcm63xx_wdt.c
@@ -13,20 +13,15 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
-#include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -38,53 +33,59 @@
 #define PFX KBUILD_MODNAME
 
 #define WDT_HZ 5000/* Fclk */
-#define WDT_DEFAULT_TIME   30  /* seconds */
-#define WDT_MAX_TIME   (0x / WDT_HZ)   /* seconds */
 
 struct bcm63xx_wdt_hw {
+   struct watchdog_device wdd;
raw_spinlock_t lock;
void __iomem *regs;
-   unsigned long inuse;
bool running;
 };
-static struct bcm63xx_wdt_hw bcm63xx_wdt_device;
 
-static int expect_close;
+#define to_wdt_hw(x) container_of(x, struct bcm63xx_wdt_hw, wdd)
 
-static int wdt_time = WDT_DEFAULT_TIME;
 static bool nowayout = WATCHDOG_NOWAYOUT;
 module_param(nowayout, bool, 0);
 MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
 
-/* HW functions */
-static void bcm63xx_wdt_hw_start(void)
+static int bcm63xx_wdt_start(struct watchdog_device *wdd)
 {
+   struct bcm63xx_wdt_hw *hw = to_wdt_hw(wdd);
unsigned long flags;
 
-   raw_spin_lock_irqsave(&bcm63xx_wdt_device.lock, flags);
-   bcm_writel(wdt_time * WDT_HZ, bcm63xx_wdt_device.regs + WDT_DEFVAL_REG);
-   bcm_writel(WDT_START_1, bcm63xx_wdt_device.regs + WDT_CTL_REG);
-   bcm_writel(WDT_START_2, bcm63xx_wdt_device.regs + WDT_CTL_REG);
-   bcm63xx_wdt_device.running = true;
-   raw_spin_unlock_irqrestore(&bcm63xx_wdt_device.lock, flags);
+   raw_spin_lock_irqsave(&hw->lock, flags);
+   bcm_writel(wdd->timeout * WDT_HZ, hw->regs + WDT_DEFVAL_REG);
+   bcm_writel(WDT_START_1, hw->regs + WDT_CTL_REG);
+   bcm_writel(WDT_START_2, hw->regs + WDT_CTL_REG);
+   hw->running = true;
+   raw_spin_unlock_irqrestore(&hw->lock, flags);
+   return 0;
 }
 
-static void bcm63xx_wdt_hw_stop(void)
+static int bcm63xx_wdt_stop(struct watchdog_device *wdd)
 {
+   struct bcm63xx_wdt_hw *hw = to_wdt_hw(wdd);
unsigned long flags;
 
-   raw_spin_lock_irqsave(&bcm63xx_wdt_device.lock, flags);
-   bcm_writel(WDT_STOP_1, bcm63xx_wdt_device.regs + WDT_CTL_REG);
-   bcm_writel(WDT_STOP_2, bcm63xx_wdt_device.regs + WDT_CTL_REG);
-   bcm63xx_wdt_device.running = false;
-   raw_spin_unlock_irqrestore(&bcm63xx_wdt_device.lock, flags);
+   raw_spin_lock_irqsave(&hw->lock, flags);
+   bcm_writel(WDT_STOP_1, hw->regs + WDT_CTL_REG);
+   bcm_writel(WDT_STOP_2, hw->regs + WDT_CTL_REG);
+   hw->running = false;
+   raw_spin_un

[PATCH (v2) 4/10] watchdog: bcm63xx_wdt: Handle hardware interrupt and remove software timer

[Simon Arlott]

There is a level triggered interrupt for the watchdog timer as part of
the bcm63xx_timer device. The interrupt occurs when the hardware watchdog
timer reaches 50% of the remaining time.

It is not possible to mask the interrupt within the bcm63xx_timer device.
To get around this limitation, handle the interrupt by restarting the
watchdog with the current remaining time (which will be half the previous
timeout) so that the interrupt occurs again at 1/4th, 1/8th, etc. of the
original timeout value until the watchdog forces a reboot.

The software timer was restarting the hardware watchdog with a 85 second
timeout until the software timer expired, and then causing a panic()
about 42.5 seconds later when the hardware interrupt occurred. The
hardware watchdog would not reboot until a further 42.5 seconds had
passed.

Remove the software timer and rely on the hardware timer directly,
reducing the maximum timeout from 256 seconds to 85 seconds
(2^32 / WDT_HZ).

Signed-off-by: Simon Arlott 
---
Initialise bcm63xx_wdt_device.running to false.

 drivers/watchdog/bcm63xx_wdt.c | 125 -
 1 file changed, 73 insertions(+), 52 deletions(-)

diff --git a/drivers/watchdog/bcm63xx_wdt.c b/drivers/watchdog/bcm63xx_wdt.c
index ab26fd9..3f55cba 100644
--- a/drivers/watchdog/bcm63xx_wdt.c
+++ b/drivers/watchdog/bcm63xx_wdt.c
@@ -3,6 +3,7 @@
  *
  *  Copyright (C) 2007, Miguel Gaio 
  *  Copyright (C) 2008, Florian Fainelli 
+ *  Copyright 2015 Simon Arlott
  *
  *  This program is free software; you can redistribute it and/or
  *  modify it under the terms of the GNU General Public License
@@ -20,11 +21,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -37,16 +37,17 @@
 
 #define PFX KBUILD_MODNAME
 
-#define WDT_HZ 5000 /* Fclk */
-#define WDT_DEFAULT_TIME   30  /* seconds */
-#define WDT_MAX_TIME   256 /* seconds */
+#define WDT_HZ 5000/* Fclk */
+#define WDT_DEFAULT_TIME   30  /* seconds */
+#define WDT_MAX_TIME   (0x / WDT_HZ)   /* seconds */
 
-static struct {
+struct bcm63xx_wdt_hw {
+   raw_spinlock_t lock;
void __iomem *regs;
-   struct timer_list timer;
unsigned long inuse;
-   atomic_t ticks;
-} bcm63xx_wdt_device;
+   bool running;
+};
+static struct bcm63xx_wdt_hw bcm63xx_wdt_device;
 
 static int expect_close;
 
@@ -59,48 +60,67 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once 
started (default="
 /* HW functions */
 static void bcm63xx_wdt_hw_start(void)
 {
-   bcm_writel(0xfffe, bcm63xx_wdt_device.regs + WDT_DEFVAL_REG);
+   unsigned long flags;
+
+   raw_spin_lock_irqsave(&bcm63xx_wdt_device.lock, flags);
+   bcm_writel(wdt_time * WDT_HZ, bcm63xx_wdt_device.regs + WDT_DEFVAL_REG);
bcm_writel(WDT_START_1, bcm63xx_wdt_device.regs + WDT_CTL_REG);
bcm_writel(WDT_START_2, bcm63xx_wdt_device.regs + WDT_CTL_REG);
+   bcm63xx_wdt_device.running = true;
+   raw_spin_unlock_irqrestore(&bcm63xx_wdt_device.lock, flags);
 }
 
 static void bcm63xx_wdt_hw_stop(void)
 {
+   unsigned long flags;
+
+   raw_spin_lock_irqsave(&bcm63xx_wdt_device.lock, flags);
bcm_writel(WDT_STOP_1, bcm63xx_wdt_device.regs + WDT_CTL_REG);
bcm_writel(WDT_STOP_2, bcm63xx_wdt_device.regs + WDT_CTL_REG);
+   bcm63xx_wdt_device.running = false;
+   raw_spin_unlock_irqrestore(&bcm63xx_wdt_device.lock, flags);
 }
 
+/* The watchdog interrupt occurs when half the timeout is remaining */
 static void bcm63xx_wdt_isr(void *data)
 {
-   struct pt_regs *regs = get_irq_regs();
-
-   die(PFX " fire", regs);
-}
-
-static void bcm63xx_timer_tick(unsigned long unused)
-{
-   if (!atomic_dec_and_test(&bcm63xx_wdt_device.ticks)) {
-   bcm63xx_wdt_hw_start();
-   mod_timer(&bcm63xx_wdt_device.timer, jiffies + HZ);
-   } else
-   pr_crit("watchdog will restart system\n");
-}
-
-static void bcm63xx_wdt_pet(void)
-{
-   atomic_set(&bcm63xx_wdt_device.ticks, wdt_time);
-}
-
-static void bcm63xx_wdt_start(void)
-{
-   bcm63xx_wdt_pet();
-   bcm63xx_timer_tick(0);
-}
+   struct bcm63xx_wdt_hw *hw = &bcm63xx_wdt_device;
+   unsigned long flags;
+
+   raw_spin_lock_irqsave(&hw->lock, flags);
+   if (!hw->running) {
+   /* Stop the watchdog as it shouldn't be running */
+   bcm_writel(WDT_STOP_1, hw->regs + WDT_CTL_REG);
+   bcm_writel(WDT_STOP_2, hw->regs + WDT_CTL_REG);
+   } else {
+   u32 timeleft = bcm_readl(hw->regs + WDT_CTL_REG);
+   u32 ms;
+
+   if (timeleft >= 2) {
+   /* The only way to clear this level triggered interrupt
+* without disrupting the normal running of the watchdog
+* is to resta

Re: [PATCH v3 2/2] phy-sun4i-usb: Add support for the host usb-phys found on the H3 SoC

[Rob Herring]

On Wed, Nov 25, 2015 at 05:50:02PM +0100, Hans de Goede wrote:
> From: Reinder de Haan 
> 
> Note this commit only adds support for phys 1-3, phy 0, the otg phy, is
> not yet (fully) supported after this commit.

Shouldn't the OTG phy have a different compatible string?

> 
> Signed-off-by: Reinder de Haan 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Change break; after dev_err() to return, as intended, fixing a compiler
>  warning (the dev_err case should never be reached)
> Changes in v3:
> -Use of_match_node to get model specific config data
> ---
>  .../devicetree/bindings/phy/sun4i-usb-phy.txt  |  1 +
>  drivers/phy/phy-sun4i-usb.c| 46 
> +-
>  2 files changed, 38 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt 
> b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> index 0cebf74..95736d7 100644
> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> @@ -9,6 +9,7 @@ Required properties:
>* allwinner,sun7i-a20-usb-phy
>* allwinner,sun8i-a23-usb-phy
>* allwinner,sun8i-a33-usb-phy
> +  * allwinner,sun8i-h3-usb-phy
>  - reg : a list of offset + length pairs
>  - reg-names :
>* "phy_ctrl"
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index 1d8f85d..2aed482 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -46,6 +46,9 @@
>  #define REG_PHYBIST  0x08
>  #define REG_PHYTUNE  0x0c
>  #define REG_PHYCTL_A33   0x10
> +#define REG_PHY_UNK_H3   0x20
> +
> +#define REG_PMU_UNK_H3   0x10
>  
>  #define PHYCTL_DATA  BIT(7)
>  
> @@ -79,7 +82,7 @@
>  #define PHY_DISCON_TH_SEL0x2a
>  #define PHY_SQUELCH_DETECT   0x3c
>  
> -#define MAX_PHYS 3
> +#define MAX_PHYS 4
>  
>  /*
>   * Note do not raise the debounce time, we must report Vusb high within 100ms
> @@ -91,6 +94,7 @@
>  enum sun4i_usb_phy_type {
>   sun4i_a10_phy,
>   sun8i_a33_phy,
> + sun8i_h3_phy,
>  };
>  
>  struct sun4i_usb_phy_cfg {
> @@ -101,6 +105,7 @@ struct sun4i_usb_phy_cfg {
>  };
>  
>  struct sun4i_usb_phy_data {
> + struct device *dev;
>   void __iomem *base;
>   const struct sun4i_usb_phy_cfg *cfg;
>   struct mutex mutex;
> @@ -183,6 +188,9 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy 
> *phy, u32 addr, u32 data,
>   /* A33 needs us to set phyctl to 0 explicitly */
>   writel(0, phyctl);
>   break;
> + case sun8i_h3_phy:
> + dev_err(phy_data->dev, "H3 usb_phy_write is not supported\n");
> + return;
>   }
>  
>   for (i = 0; i < len; i++) {
> @@ -243,6 +251,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
>   struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
>   int ret;
> + u32 val;
>  
>   ret = clk_prepare_enable(phy->clk);
>   if (ret)
> @@ -254,16 +263,26 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   return ret;
>   }
>  
> - /* Enable USB 45 Ohm resistor calibration */
> - if (phy->index == 0)
> - sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
> + if (data->cfg->type == sun8i_h3_phy) {
> + if (phy->index == 0) {
> + val = readl(data->base + REG_PHY_UNK_H3);
> + writel(val & ~1, data->base + REG_PHY_UNK_H3);
> + }
>  
> - /* Adjust PHY's magnitude and rate */
> - sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
> + val = readl(phy->pmu + REG_PMU_UNK_H3);
> + writel(val & ~2, phy->pmu + REG_PMU_UNK_H3);
> + } else {
> + /* Enable USB 45 Ohm resistor calibration */
> + if (phy->index == 0)
> + sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
>  
> - /* Disconnect threshold adjustment */
> - sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
> - data->cfg->disc_thresh, 2);
> + /* Adjust PHY's magnitude and rate */
> + sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
> +
> + /* Disconnect threshold adjustment */
> + sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
> + data->cfg->disc_thresh, 2);
> + }
>  
>   sun4i_usb_phy_passby(phy, 1);
>  
> @@ -555,6 +574,13 @@ static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
>   .dedicated_clocks = true,
>  };
>  
> +static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
> + .num_phys = 4,
> + .disc_thresh = 3,
> + .type = sun8i_h3_phy,
> + .dedicated_clocks = true,
> +};
> +
>  static const struct of_device_id sun4i_us

Re: [PATCH v6 2/6] mfd: syscon: add a DT property to set value width

[Damien Riegel]

On Wed, Nov 25, 2015 at 02:32:53PM -0600, Rob Herring wrote:
> On Wed, Nov 25, 2015 at 02:25:03PM -0500, Damien Riegel wrote:
> > Currently syscon has a fixed configuration of 32 bits for register and
> > values widths. In some cases, it would be desirable to be able to
> > customize the value width.
> > 
> > For example, certain boards (like the ones manufactured by Technologic
> > Systems) have a FPGA that is memory-mapped, but its registers are only
> > 16-bit wide.
> > 
> > This patch adds an optional "bus-width" DT binding for syscon that
> > allows to change the width for the data bus (i.e. val_bits). If this
> > property is provided, it will also adjust the register stride to
> > bus-width / 8. If not provided, the default configuration is used.
> 
> See the 8250 UART bindings. This problem is already solved and has 
> standard bindings for it.

Okay, I'll change bus-width to reg-io-width. Are you also suggesting to
use reg-shift to parametrize reg_stride?

> Rob
> 
> > 
> > Signed-off-by: Damien Riegel 
> > Acked-by: Arnd Bergmann 
> > Acked-by: Lee Jones 
> > ---
> >  Documentation/devicetree/bindings/mfd/syscon.txt |  3 +++
> >  drivers/mfd/syscon.c | 13 +
> >  2 files changed, 16 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt 
> > b/Documentation/devicetree/bindings/mfd/syscon.txt
> > index fe8150b..4c9d187 100644
> > --- a/Documentation/devicetree/bindings/mfd/syscon.txt
> > +++ b/Documentation/devicetree/bindings/mfd/syscon.txt
> > @@ -13,6 +13,9 @@ Required properties:
> >  - compatible: Should contain "syscon".
> >  - reg: the register region can be accessed from syscon
> >  
> > +Optional property:
> > +- bus-width: width of the data bus. Can be <8>, <16>, <32>, or <64>.
> > +
> >  Examples:
> >  gpr: iomuxc-gpr@020e {
> > compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
> > diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> > index 176bf0f..5a93d80 100644
> > --- a/drivers/mfd/syscon.c
> > +++ b/drivers/mfd/syscon.c
> > @@ -47,6 +47,7 @@ static struct syscon *of_syscon_register(struct 
> > device_node *np)
> > struct syscon *syscon;
> > struct regmap *regmap;
> > void __iomem *base;
> > +   u32 bus_width;
> > int ret;
> > struct regmap_config syscon_config = syscon_regmap_config;
> >  
> > @@ -69,6 +70,18 @@ static struct syscon *of_syscon_register(struct 
> > device_node *np)
> >  else if (of_property_read_bool(np, "little-endian"))
> > syscon_config.val_format_endian = REGMAP_ENDIAN_LITTLE;
> >  
> > +   /*
> > +* search for bus-width property in DT. If it is not provided, default
> > +* to 32-bit. regmap_init_mmio will return an error if syscon_config's
> > +* values are invalid so there is no need to check them here.
> > +*/
> > +   ret = of_property_read_u32(np, "bus-width", &bus_width);
> > +   if (ret)
> > +   bus_width = 32;
> > +
> > +   syscon_config.val_bits = bus_width;
> > +   syscon_config.reg_stride = syscon_config.val_bits / 8;
> > +
> > regmap = regmap_init_mmio(NULL, base, &syscon_config);
> > if (IS_ERR(regmap)) {
> > pr_err("regmap init failed\n");
> > -- 
> > 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

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Pali Rohár]

On Wednesday 25 November 2015 22:51:00 Arnd Bergmann wrote:
> On Wednesday 25 November 2015 22:44:28 Pali Rohár wrote:
> > Arnd, my question about proper solution reminds... Proprietary
> > bootloader which cannot be replaced (e.g. it is signed or do
> > unknown magic) provides information to booted kernel via custom
> > specific ATAGs fields. How userspace could properly read those
> > custom information from bootloader?
> 
> The typical solution for nonstandard bootloaders is to have a boot
> wrapper like the one from
> https://github.com/zonque/pxa-impedance-matcher that translates
> whatever information we have at the bootloader level into DT
> properties.
> 

Ok. So there is no better solution. With some hacks we can use U-Boot as 
3rd stage bootloader. But this is not useful for debugging or 
developing...

Ideal "wrapper" solution would be to compile wrapper and linux zImage 
and then glue them together to one binary. Something like internal linux 
uncompress code which translate atags to dt.

> As I understand, the reason we are not doing that here is that we
> also have proprietary user space that we can't fix to look in a
> different place, i.e. the interface is between the bootloader and
> some user binary, not bootloader to kernel.
> 

Yes, proprietary/closed applications are problems which we cannot fix 
(without rewriting them).

New applications could use new "proper" interface. But without that 
interface we cannot do that.

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


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

Re: [PATCH v6 5/6] of: documentation: add bindings documentation for TS-4800

[Rob Herring]

On Wed, Nov 25, 2015 at 02:25:06PM -0500, Damien Riegel wrote:
> This adds the documentation for the TS-4800 by Technologic Systems.
> 
> Signed-off-by: Damien Riegel 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/arm/technologic.txt | 6 ++
>  1 file changed, 6 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/technologic.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/technologic.txt 
> b/Documentation/devicetree/bindings/arm/technologic.txt
> new file mode 100644
> index 000..8422988
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/technologic.txt
> @@ -0,0 +1,6 @@
> +Technologic Systems Platforms Device Tree Bindings
> +--
> +
> +TS-4800 board
> +Required root node properties:
> + - compatible = "technologic,imx51-ts4800", "fsl,imx51";
> -- 
> 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

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Arnd Bergmann]

On Wednesday 25 November 2015 22:44:28 Pali Rohár wrote:
> 
> Arnd, my question about proper solution reminds... Proprietary 
> bootloader which cannot be replaced (e.g. it is signed or do unknown 
> magic) provides information to booted kernel via custom specific ATAGs 
> fields. How userspace could properly read those custom information from 
> bootloader?

The typical solution for nonstandard bootloaders is to have a boot wrapper
like the one from https://github.com/zonque/pxa-impedance-matcher that
translates whatever information we have at the bootloader level into
DT properties.

As I understand, the reason we are not doing that here is that we also
have proprietary user space that we can't fix to look in a different
place, i.e. the interface is between the bootloader and some user
binary, not bootloader to kernel.

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

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Pali Rohár]

On Wednesday 25 November 2015 22:29:53 Arnd Bergmann wrote:
> On Wednesday 25 November 2015 13:03:10 Tony Lindgren wrote:
> > * Arnd Bergmann  [151125 11:50]:
> > > On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote:
> > > > At least I don't have better solutions in mind.
> > > 
> > > I would be happier if we could restrict this as much as possible
> > > to the boards that need it, as an opt-in. That way it doesn't
> > > become an ABI for people that don't already rely in this
> > > information. How about adding a check the code adds the
> > > linux,atags property to do it only for a whitelist of board
> > > numbers?
> > 
> > Or populate /proc/atags only for the ones that need it from machine
> > specific init_early?
> 
> That would also address my main concern about /proc/atags, but still
> leave the atags in /proc/device-tree/chosen/linux,atags, and it would
> be bad if someone who currently uses /proc/atags changes their code
> to use the other file instead of finding a proper solution.
> 
>   Arnd

Arnd, my question about proper solution reminds... Proprietary 
bootloader which cannot be replaced (e.g. it is signed or do unknown 
magic) provides information to booted kernel via custom specific ATAGs 
fields. How userspace could properly read those custom information from 
bootloader?

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


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

Re: [PATCH 15/18] ARM: am57xx: sbc-am57x: dts: add GPIO extender support

[Nishanth Menon]

On 11/25/2015 12:39 AM, Dmitry Lifshitz wrote:
> Add PCA9555 GPIO extender support (over I2C5 bus).

I think you meant to say "GPIO expander" in commit message and
$subject perhaps?

> 
> Signed-off-by: Dmitry Lifshitz 
> Acked-by: Igor Grinberg 
> ---
>  arch/arm/boot/dts/am57xx-sbc-am57x.dts | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts 
> b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> index 7b65efb..8b7c0b5 100644
> --- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> +++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> @@ -90,4 +90,11 @@
>   reg = <0x50>;
>   pagesize = <16>;
>   };
> +
> + pca9555: pca9555@20 {
> + compatible = "nxp,pca9555";
> + reg = <0x20>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
>  };
> 


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

Re: [PATCH 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support

[Nishanth Menon]

On 11/25/2015 12:39 AM, Dmitry Lifshitz wrote:
[...]

> diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
> b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> new file mode 100644
> index 000..b11d7da
> --- /dev/null
> +++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
[...]

> +/ {
> + model = "CompuLab CL-SOM-AM57x";
> + compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", 
> "ti,dra74", "ti,dra7";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x2000>; /* 512 MB - minimal 
> configuration */

I think if you like to enable LPAE, the format might look a little
different..

> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&leds_pins_default>;
> +
> + led@0 {
> + label = "cl-som-am57x:green";
> + gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + default-state = "off";
> + };
> + };
> +};
> +
> +&dra7_pmx_core {
> + leds_pins_default: leds_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x347c, PIN_OUTPUT | MUX_MODE14)  
> /* gpmc_a15.gpio2_5 */
> + >;
> + };
> +
> + i2c1_pins_default: i2c1_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT_PULLUP | MUX_MODE0) 
> /* i2c1_sda.sda */
> + DRA7XX_CORE_IOPAD(0x3804, PIN_INPUT_PULLUP | MUX_MODE0) 
> /* i2c1_scl.scl */
> + >;
> + };
> +
> + tps659038_pins_default: tps659038_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x3818, PIN_INPUT_PULLUP | 
> MUX_MODE14) /* wakeup0.gpio1_0 */
> + >;
> + };

Generic comment: As per requirements of the SoC -> all pinctrl must be
done in bootloader. this was a recommendation that came in too late
for TI platforms that got introduced in upstream, but that cleanup
should eventually take place as well.

> +};
> +
> +&i2c1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins_default>;
> + clock-frequency = <40>;
> +
> + tps659038: tps659038@58 {
> + compatible = "ti,tps659038";
> + reg = <0x58>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;

Also See: https://patchwork.kernel.org/patch/7596541/ ->
Documentation/devicetree/bindings/i2c/i2c.txt -> since you seem to
have a PMIC with power button, you might be able to get wakeup source
also there.

> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&tps659038_pins_default>;
> +
> + #interrupt-cells = <2>;
> + interrupt-controller;
> +
> + ti,system-power-controller;

Assuming powerhold signal and BOOT0,1 is proper here, else poweroff
will never work.

> +
> + tps659038_pmic {
> + compatible = "ti,tps659038-pmic";
> +
> + regulators {
> + smps12_reg: smps12 {
> + /* VDD_MPU */
> + regulator-name = "smps12";
> + regulator-min-microvolt = < 85>;
> + regulator-max-microvolt = <125>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps3_reg: smps3 {
> + /* VDD_DDR */
> + regulator-name = "smps3";
> + regulator-min-microvolt = <150>;
> + regulator-max-microvolt = <150>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps45_reg: smps45 {
> + /* VDD_DSPEVE */
> + regulator-name = "smps45";
> + regulator-min-microvolt = < 85>;
> + regulator-max-microvolt = <116>;

1.25v if you want to support OPP_HIGH. as per latest data sheet.

> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps6_reg: smps6 {
> + /* VDD_GPU */
> + regulator-name = "smps6";
> + regulator-min-microvolt = < 85>;
> +  

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Arnd Bergmann]

On Wednesday 25 November 2015 13:03:10 Tony Lindgren wrote:
> * Arnd Bergmann  [151125 11:50]:
> > On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote:
> > > At least I don't have better solutions in mind.
> > 
> > I would be happier if we could restrict this as much as possible to the
> > boards that need it, as an opt-in. That way it doesn't become an ABI
> > for people that don't already rely in this information. How about
> > adding a check the code adds the linux,atags property to do it
> > only for a whitelist of board numbers?
> 
> Or populate /proc/atags only for the ones that need it from machine
> specific init_early?

That would also address my main concern about /proc/atags, but still
leave the atags in /proc/device-tree/chosen/linux,atags, and it would
be bad if someone who currently uses /proc/atags changes their code
to use the other file instead of finding a proper solution.

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

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Tony Lindgren]

* Arnd Bergmann  [151125 11:50]:
> On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote:
> > * Pali Rohár  [151123 06:46]:
> > > On Sunday 22 November 2015 07:51:46 Pavel Machek wrote:
> > > > On Wed 2015-11-11 17:10:46, Frank Rowand wrote:
> > > > > Adding devicetree list.
> > > > > 
> > > > > Thread starts at
> > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html
> > > > > 
> > > > > On 11/5/2015 8:17 AM, Tony Lindgren wrote:
> > > > > > * Pali Rohár  [151105 03:41]:
> > > > > >> On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote:
> > > > > >>> On Monday 12 October 2015 13:45:09 Tony Lindgren wrote:
> > > > >  * Pali Rohár  [151012 13:29]:
> > > > > > On Monday 12 October 2015 22:16:40 Tony Lindgren wrote:
> > > > > >>
> > > > > >> Pali, any news on posting an updated series with the comments
> > > > > >> addressed in this thread? It seems that we all pretty much 
> > > > > >> agree
> > > > > >> what needs to be done.
> > > > > 
> > > > > I'm not real happy with the concept of patches 4 and 5 in this series.
> > > > > My concern is that those two patches are using the FDT as a transport
> > > > > mechanism for a binary blob (the atags object).
> > > > 
> > > > Umm. Ok. Do you have alternative proposal that works for everyone?
> > > > 
> > > > I mean. This discussion was going for quite a long time, and it would
> > > > be nice to have some solution... patch proposal... something.
> > > > 
> > > > Pavel
> > > 
> > > Yes, discussion is going for a long time! So should I spend time for
> > > adding documentation to my solution (this is last one thing which is
> > > missing)? Or my solution is wrong and somebody else will propose new?
> > > I do not want to spend time on something which will be rejected and
> > > discarded.
> > 
> > At least I don't have better solutions in mind.
> 
> I would be happier if we could restrict this as much as possible to the
> boards that need it, as an opt-in. That way it doesn't become an ABI
> for people that don't already rely in this information. How about
> adding a check the code adds the linux,atags property to do it
> only for a whitelist of board numbers?

Or populate /proc/atags only for the ones that need it from machine
specific init_early?

Regards,

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

Re: [PATCH v6 3/6] watchdog: ts4800: add driver for TS-4800 watchdog

[Damien Riegel]

On Wed, Nov 25, 2015 at 02:29:56PM -0600, Rob Herring wrote:
> On Wed, Nov 25, 2015 at 02:25:04PM -0500, Damien Riegel wrote:
> > This watchdog is instantiated in a FPGA that is memory mapped. It is
> > made of only one register, called the feed register. Writing to this
> > register will re-arm the watchdog for a given time (and enable it if it
> > was disable). It can be disabled by writing a special value into it.
> > 
> > It is part of a syscon block, and the watchdog register offset in this
> > block varies from board to board. This offset is passed in the syscon
> > property after the phandle to the syscon node.
> > 
> > Signed-off-by: Damien Riegel 
> > Reviewed-by: Guenter Roeck 
> > ---
> >  .../devicetree/bindings/watchdog/ts4800-wdt.txt|  25 +++
> >  drivers/watchdog/Kconfig   |  10 +
> >  drivers/watchdog/Makefile  |   1 +
> >  drivers/watchdog/ts4800_wdt.c  | 215 
> > +
> >  4 files changed, 251 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
> >  create mode 100644 drivers/watchdog/ts4800_wdt.c
> > 
> > diff --git a/Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt 
> > b/Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
> > new file mode 100644
> > index 000..388c60f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
> > @@ -0,0 +1,25 @@
> > +Technologic Systems Watchdog
> > +
> > +Required properties:
> > +- compatible: must be "technologic,ts4800-wdt"
> > +- syscon: phandle / integer array that points to the syscon node which
> > +  describes the FPGA's syscon registers.
> > +  - phandle to FPGA's syscon
> > +  - offset to the watchdog register
> > +
> > +Optional property:
> > +- timeout-sec: contains the watchdog timeout in seconds.
> > +
> > +Example:
> > +
> > +syscon: syscon@b001 {
> > +   compatible = "syscon", "simple-mfd";
> > +   reg = <0xb001 0x3d>;
> > +   bus-width = <16>;
> > +
> > +   wdt@e {
> > +   compatible = "technologic,ts4800-wdt";
> > +   syscon = <&syscon 0xe>;
> 
> If this is single register only for the watchdog, why do you need 
> syscon? You can just use reg.

Because this is a single 16-bit register dedicated to the watchdog in a
60-register syscon.
--
To unsubscribe from this list: send the line "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 2/6] mfd: syscon: add a DT property to set value width

[Rob Herring]

On Wed, Nov 25, 2015 at 02:25:03PM -0500, Damien Riegel wrote:
> Currently syscon has a fixed configuration of 32 bits for register and
> values widths. In some cases, it would be desirable to be able to
> customize the value width.
> 
> For example, certain boards (like the ones manufactured by Technologic
> Systems) have a FPGA that is memory-mapped, but its registers are only
> 16-bit wide.
> 
> This patch adds an optional "bus-width" DT binding for syscon that
> allows to change the width for the data bus (i.e. val_bits). If this
> property is provided, it will also adjust the register stride to
> bus-width / 8. If not provided, the default configuration is used.

See the 8250 UART bindings. This problem is already solved and has 
standard bindings for it.

Rob

> 
> Signed-off-by: Damien Riegel 
> Acked-by: Arnd Bergmann 
> Acked-by: Lee Jones 
> ---
>  Documentation/devicetree/bindings/mfd/syscon.txt |  3 +++
>  drivers/mfd/syscon.c | 13 +
>  2 files changed, 16 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt 
> b/Documentation/devicetree/bindings/mfd/syscon.txt
> index fe8150b..4c9d187 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.txt
> +++ b/Documentation/devicetree/bindings/mfd/syscon.txt
> @@ -13,6 +13,9 @@ Required properties:
>  - compatible: Should contain "syscon".
>  - reg: the register region can be accessed from syscon
>  
> +Optional property:
> +- bus-width: width of the data bus. Can be <8>, <16>, <32>, or <64>.
> +
>  Examples:
>  gpr: iomuxc-gpr@020e {
>   compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index 176bf0f..5a93d80 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -47,6 +47,7 @@ static struct syscon *of_syscon_register(struct device_node 
> *np)
>   struct syscon *syscon;
>   struct regmap *regmap;
>   void __iomem *base;
> + u32 bus_width;
>   int ret;
>   struct regmap_config syscon_config = syscon_regmap_config;
>  
> @@ -69,6 +70,18 @@ static struct syscon *of_syscon_register(struct 
> device_node *np)
>else if (of_property_read_bool(np, "little-endian"))
>   syscon_config.val_format_endian = REGMAP_ENDIAN_LITTLE;
>  
> + /*
> +  * search for bus-width property in DT. If it is not provided, default
> +  * to 32-bit. regmap_init_mmio will return an error if syscon_config's
> +  * values are invalid so there is no need to check them here.
> +  */
> + ret = of_property_read_u32(np, "bus-width", &bus_width);
> + if (ret)
> + bus_width = 32;
> +
> + syscon_config.val_bits = bus_width;
> + syscon_config.reg_stride = syscon_config.val_bits / 8;
> +
>   regmap = regmap_init_mmio(NULL, base, &syscon_config);
>   if (IS_ERR(regmap)) {
>   pr_err("regmap init failed\n");
> -- 
> 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

Re: [PATCH v6 3/6] watchdog: ts4800: add driver for TS-4800 watchdog

[Rob Herring]

On Wed, Nov 25, 2015 at 02:25:04PM -0500, Damien Riegel wrote:
> This watchdog is instantiated in a FPGA that is memory mapped. It is
> made of only one register, called the feed register. Writing to this
> register will re-arm the watchdog for a given time (and enable it if it
> was disable). It can be disabled by writing a special value into it.
> 
> It is part of a syscon block, and the watchdog register offset in this
> block varies from board to board. This offset is passed in the syscon
> property after the phandle to the syscon node.
> 
> Signed-off-by: Damien Riegel 
> Reviewed-by: Guenter Roeck 
> ---
>  .../devicetree/bindings/watchdog/ts4800-wdt.txt|  25 +++
>  drivers/watchdog/Kconfig   |  10 +
>  drivers/watchdog/Makefile  |   1 +
>  drivers/watchdog/ts4800_wdt.c  | 215 
> +
>  4 files changed, 251 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
>  create mode 100644 drivers/watchdog/ts4800_wdt.c
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
> new file mode 100644
> index 000..388c60f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
> @@ -0,0 +1,25 @@
> +Technologic Systems Watchdog
> +
> +Required properties:
> +- compatible: must be "technologic,ts4800-wdt"
> +- syscon: phandle / integer array that points to the syscon node which
> +  describes the FPGA's syscon registers.
> +  - phandle to FPGA's syscon
> +  - offset to the watchdog register
> +
> +Optional property:
> +- timeout-sec: contains the watchdog timeout in seconds.
> +
> +Example:
> +
> +syscon: syscon@b001 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0xb001 0x3d>;
> + bus-width = <16>;
> +
> + wdt@e {
> + compatible = "technologic,ts4800-wdt";
> + syscon = <&syscon 0xe>;

If this is single register only for the watchdog, why do you need 
syscon? You can just use reg.

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 4/10] watchdog: bcm63xx_wdt: Handle hardware interrupt and remove software timer

[Simon Arlott]

On 25/11/15 20:14, Jonas Gorski wrote:
> On Tue, Nov 24, 2015 at 7:21 PM, Guenter Roeck  wrote:
>> On Sun, Nov 22, 2015 at 02:05:16PM +, Simon Arlott wrote:
>>> There is a level triggered interrupt for the watchdog timer as part of
>>> the bcm63xx_timer device. The interrupt occurs when the hardware watchdog
>>> timer reaches 50% of the remaining time.
>>>
>>> It is not possible to mask the interrupt within the bcm63xx_timer device.
>>> To get around this limitation, handle the interrupt by restarting the
>>> watchdog with the current remaining time (which will be half the previous
>>> timeout) so that the interrupt occurs again at 1/4th, 1/8th, etc. of the
>>> original timeout value until the watchdog forces a reboot.
>>>
>>> The software timer was restarting the hardware watchdog with a 85 second
>>> timeout until the software timer expired, and then causing a panic()
>>> about 42.5 seconds later when the hardware interrupt occurred. The
>>> hardware watchdog would not reboot until a further 42.5 seconds had
>>> passed.
>>>
>>> Remove the software timer and rely on the hardware timer directly,
>>> reducing the maximum timeout from 256 seconds to 85 seconds
>>> (2^32 / WDT_HZ).
>>>
>>
>> Florian,
>>
>> can you have a look into this patch and confirm that there is no better
>> way to clear the interrupt status ?
> 
> While the watchdog interrupt can't be masked, it should be able to be
> cleared by writing 1 to the appropriate bit in the timer block's
> interrupt status register. At least the broadcom sources do so.

Not according to the hardware itself:
[6.674626] watchdog watchdog0: warning timer fired, reboot in 7499ms
[6.681212] irq_bcm6345_l2_timer: bcm6345_timer_write_int_status: b083=08
[6.688583] watchdog watchdog0: warning timer fired, reboot in 7486ms
[6.695181] irq_bcm6345_l2_timer: bcm6345_timer_write_int_status: b083=08
[6.702554] watchdog watchdog0: warning timer fired, reboot in 7472ms
[6.709158] irq_bcm6345_l2_timer: bcm6345_timer_write_int_status: b083=08
[6.716529] watchdog watchdog0: warning timer fired, reboot in 7458ms
[6.723135] irq_bcm6345_l2_timer: bcm6345_timer_write_int_status: b083=08
[6.730538] watchdog watchdog0: warning timer fired, reboot in 7444ms
[6.737121] irq_bcm6345_l2_timer: bcm6345_timer_write_int_status: b083=08
[6.744482] watchdog watchdog0: warning timer fired, reboot in 7430ms
[6.751090] irq_bcm6345_l2_timer: bcm6345_timer_write_int_status: b083=08


typedef struct Timer {
uint16unused0;
byte  TimerMask;
#define TIMER0EN0x01
#define TIMER1EN0x02
#define TIMER2EN0x04
byte  TimerInts;
#define TIMER0  0x01
#define TIMER1  0x02
#define TIMER2  0x04
#define WATCHDOG0x08
...

-- 
Simon Arlott
--
To unsubscribe from this list: send the line "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/6] of: add vendor prefix for Technologic Systems

[Rob Herring]

On Wed, Nov 25, 2015 at 02:25:02PM -0500, Damien Riegel wrote:
> Signed-off-by: Damien Riegel 
> Acked-by: Lee Jones 

Acked-by: Rob Herring 

> ---
>  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 82d2ac9..d3a206d 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -215,6 +215,7 @@ stericssonST-Ericsson
>  synology Synology, Inc.
>  tbs  TBS Technologies
>  tcl  Toby Churchill Ltd.
> +technologic  Technologic Systems
>  thineTHine Electronics, Inc.
>  ti   Texas Instruments
>  tlm  Trusted Logic Mobility
> -- 
> 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

Re: [PATCH v2 1/1] platform: goldfish: pipe: add devicetree bindings

[Rob Herring]

On Wed, Nov 25, 2015 at 11:59:37AM -0800, Jin Qian wrote:
> From: Greg Hackmann 
> 
> Signed-off-by: Greg Hackmann 
> (cherry picked from commit 3c56d07eb796066530e93a40e74dea3bc59bf4cf)
> Signed-off-by: Jin Qian 
> ---
>  Documentation/devicetree/bindings/goldfish/pipe.txt | 17 +
>  drivers/platform/goldfish/goldfish_pipe.c   | 10 +-
>  2 files changed, 26 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/goldfish/pipe.txt
> 
> diff --git a/Documentation/devicetree/bindings/goldfish/pipe.txt 
> b/Documentation/devicetree/bindings/goldfish/pipe.txt
> new file mode 100644
> index 000..6d3801e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/goldfish/pipe.txt
> @@ -0,0 +1,17 @@
> +Android Goldfish QEMU Pipe
> +
> +Andorid pipe virtual device generated by android emulator.

The binding may be trivial, but there's a bigger question of whether 
this is the right long term direction. For example is upstream QEMU 
going to take all the Android pipe stuff? Couldn't virtio be used here 
as the transport?

Rob

> +
> +Required properties:
> +
> +- compatible : should contain "generic,android-pipe" to match emulator
> +- reg: 
> +- interrupts : 
> +
> +Example:
> +
> + android_pipe@a01 {
> + compatible = "generic,android-pipe";
> + reg = ;
> + interrupts = <0x12>;
> + };
> diff --git a/drivers/platform/goldfish/goldfish_pipe.c 
> b/drivers/platform/goldfish/goldfish_pipe.c
> index 20a9337..86cc57f 100644
> --- a/drivers/platform/goldfish/goldfish_pipe.c
> +++ b/drivers/platform/goldfish/goldfish_pipe.c
> @@ -624,11 +624,19 @@ static int goldfish_pipe_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +static const struct of_device_id goldfish_pipe_of_match[] = {
> + { .compatible = "generic,android-pipe", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, goldfish_pipe_of_match);
> +
>  static struct platform_driver goldfish_pipe = {
>   .probe = goldfish_pipe_probe,
>   .remove = goldfish_pipe_remove,
>   .driver = {
> - .name = "goldfish_pipe"
> + .name = "goldfish_pipe",
> + .owner = THIS_MODULE,
> + .of_match_table = goldfish_pipe_of_match,
>   }
>  };
>  
> -- 
> 2.6.0.rc2.230.g3dd15c0
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/10] watchdog: bcm63xx_wdt: Handle hardware interrupt and remove software timer

[Jonas Gorski]

On Tue, Nov 24, 2015 at 7:21 PM, Guenter Roeck  wrote:
> On Sun, Nov 22, 2015 at 02:05:16PM +, Simon Arlott wrote:
>> There is a level triggered interrupt for the watchdog timer as part of
>> the bcm63xx_timer device. The interrupt occurs when the hardware watchdog
>> timer reaches 50% of the remaining time.
>>
>> It is not possible to mask the interrupt within the bcm63xx_timer device.
>> To get around this limitation, handle the interrupt by restarting the
>> watchdog with the current remaining time (which will be half the previous
>> timeout) so that the interrupt occurs again at 1/4th, 1/8th, etc. of the
>> original timeout value until the watchdog forces a reboot.
>>
>> The software timer was restarting the hardware watchdog with a 85 second
>> timeout until the software timer expired, and then causing a panic()
>> about 42.5 seconds later when the hardware interrupt occurred. The
>> hardware watchdog would not reboot until a further 42.5 seconds had
>> passed.
>>
>> Remove the software timer and rely on the hardware timer directly,
>> reducing the maximum timeout from 256 seconds to 85 seconds
>> (2^32 / WDT_HZ).
>>
>
> Florian,
>
> can you have a look into this patch and confirm that there is no better
> way to clear the interrupt status ?

While the watchdog interrupt can't be masked, it should be able to be
cleared by writing 1 to the appropriate bit in the timer block's
interrupt status register. At least the broadcom sources do so.


Jonas
--
To unsubscribe from this list: send the line "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 03/10] dt-bindings: document the MPS2 UART bindings

[Rob Herring]

On Wed, Nov 25, 2015 at 10:33:34AM +, Vladimir Murzin wrote:
> This adds documentation of device tree bindings for the
> UART found on ARM MPS2 platform
> 
> Signed-off-by: Vladimir Murzin 

Why did ARM invent a new UART?

Acked-by: Rob Herring  ---
>  .../devicetree/bindings/serial/arm,mps2-uart.txt   |   22 
> 
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
> 
> diff --git a/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt 
> b/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
> new file mode 100644
> index 000..b3f7cb1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
> @@ -0,0 +1,22 @@
> +ARM MPS2 UART
> +
> +Required properties:
> +- compatible : Should be "arm,mps2-uart"
> +- reg: Address and length of the register set
> +- interrupts : Reference to the UART RX, TX and overrun interrupts
> +
> +Required clocking property:
> +- clocks : The input clock of the UART
> +
> +
> +Examples:
> +
> +uart0: serial@40004000 {
> + compatible = "arm,mps2-uart";
> + reg = <0x40004000 0x1000>;
> + interrupts = <0 1 12>;
> + clocks = <&sysclk>;
> +};
> +
> +
> +
> -- 
> 1.7.9.5
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/2] ASoC: da7218: Add bindings documentation for DA7218 audio codec

[Rob Herring]

On Wed, Nov 25, 2015 at 02:24:33PM +, Adam Thomson wrote:
> Signed-off-by: Adam Thomson 
> ---
>  Documentation/devicetree/bindings/sound/da7218.txt | 104 
> +
>  1 file changed, 104 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/da7218.txt

Acked-by: Rob Herring 

> 
> diff --git a/Documentation/devicetree/bindings/sound/da7218.txt 
> b/Documentation/devicetree/bindings/sound/da7218.txt
> new file mode 100644
> index 000..5ca5a70
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/da7218.txt
> @@ -0,0 +1,104 @@
> +Dialog Semiconductor DA7218 Audio Codec bindings
> +
> +DA7218 is an audio codec with HP detect feature.
> +
> +==
> +
> +Required properties:
> +- compatible : Should be "dlg,da7217" or "dlg,da7218"
> +- reg: Specifies the I2C slave address
> +
> +- VDD-supply: VDD power supply for the device
> +- VDDMIC-supply: VDDMIC power supply for the device
> +- VDDIO-supply: VDDIO power supply for the device
> +  (See Documentation/devicetree/bindings/regulator/regulator.txt for further
> +   information relating to regulators)
> +
> +Optional properties:
> +- interrupt-parent: Specifies the phandle of the interrupt controller to 
> which
> +  the IRQs from DA7218 are delivered to.
> +- interrupts: IRQ line info for DA7218 chip.
> +  (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt 
> for
> +   further information relating to interrupt properties)
> +- interrupt-names : Name associated with interrupt line. Should be "wakeup" 
> if
> +  interrupt is to be used to wake system, otherwise "irq" should be used.
> +- wakeup-source: Flag to indicate this device can wake system 
> (suspend/resume).
> +
> +- clocks : phandle and clock specifier for codec MCLK.
> +- clock-names : Clock name string for 'clocks' attribute, should be "mclk".
> +
> +- dlg,micbias1-lvl-millivolt : Voltage (mV) for Mic Bias 1
> + [<1200>, <1600>, <1800>, <2000>, <2200>, <2400>, <2600>, <2800>, <3000>]
> +- dlg,micbias2-lvl-millivolt : Voltage (mV) for Mic Bias 2
> + [<1200>, <1600>, <1800>, <2000>, <2200>, <2400>, <2600>, <2800>, <3000>]
> +- dlg,mic1-amp-in-sel : Mic1 input source type
> + ["diff", "se_p", "se_n"]
> +- dlg,mic2-amp-in-sel : Mic2 input source type
> + ["diff", "se_p", "se_n"]
> +- dlg,dmic1-data-sel : DMIC1 channel select based on clock edge.
> + ["lrise_rfall", "lfall_rrise"]
> +- dlg,dmic1-samplephase : When to sample audio from DMIC1.
> + ["on_clkedge", "between_clkedge"]
> +- dlg,dmic1-clkrate-hz : DMic1 clock frequency (Hz).
> + [<150>, <300>]
> +- dlg,dmic2-data-sel : DMic2 channel select based on clock edge.
> + ["lrise_rfall", "lfall_rrise"]
> +- dlg,dmic2-samplephase : When to sample audio from DMic2.
> + ["on_clkedge", "between_clkedge"]
> +- dlg,dmic2-clkrate-hz : DMic2 clock frequency (Hz).
> + [<150>, <300>]
> +- dlg,hp-diff-single-supply : Boolean flag, use single supply for HP
> +   (DA7217 only)
> +
> +==
> +
> +Optional Child node - 'da7218_hpldet' (DA7218 only):
> +
> +Optional properties:
> +- dlg,jack-rate-us : Time between jack detect measurements (us)
> + [<5>, <10>, <20>, <40>, <80>, <160>, <320>, <640>]
> +- dlg,jack-debounce : Number of debounce measurements taken for jack detect
> + [<0>, <2>, <3>, <4>]
> +- dlg,jack-threshold-pct : Threshold level for jack detection (% of VDD)
> + [<84>, <88>, <92>, <96>]
> +- dlg,comp-inv : Boolean flag, invert comparator output
> +- dlg,hyst : Boolean flag, enable hysteresis
> +- dlg,discharge : Boolean flag, auto discharge of Mic Bias on jack removal
> +
> +==
> +
> +Example:
> +
> + codec: da7218@1a {
> + compatible = "dlg,da7218";
> + reg = <0x1a>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
> + wakeup-source;
> +
> + VDD-supply = <®_audio>;
> + VDDMIC-supply = <®_audio>;
> + VDDIO-supply = <®_audio>;
> +
> + clocks = <&clks 201>;
> + clock-names = "mclk";
> +
> + dlg,micbias1-lvl-millivolt = <2600>;
> + dlg,micbias2-lvl-millivolt = <2600>;
> + dlg,mic1-amp-in-sel = "diff";
> + dlg,mic2-amp-in-sel = "diff";
> +
> + dlg,dmic1-data-sel = "lrise_rfall";
> + dlg,dmic1-samplephase = "on_clkedge";
> + dlg,dmic1-clkrate-hz = <300>;
> + dlg,dmic2-data-sel = "lrise_rfall";
> + dlg,dmic2-samplephase = "on_clkedge";
> + dlg,dmic2-clkrate-hz = <300>;
> +
> + da7218_hpldet {
> + dlg,jack-rate-us = <40>;
> + dlg,jack-debounce = <2>;
> + dlg,jack-threshold-pct = <84>;
> + dlg,hyst;
> + };
> + };
> --
> 1.9.3
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the 

Re: [PATCH 11/18] ARM: am57xx: sbc-am57x: dts: add basic board support

[Rob Herring]

On Wed, Nov 25, 2015 at 08:39:43AM +0200, Dmitry Lifshitz wrote:
> SBC-AM57x is a single board computer designed for industrial and
> embedded applications. It is based on the Texas Instruments Sitara AM57x
> system-on-chip family. SBC-AM57x is implemented with the CL-SOM-AM57x
> computer-on-module providing most of the functions, and SB-SOM-AM57x
> carrier board providing additional peripheral functions and connectors.
> 
> https://www.compulab.co.il/products/sbcs/sbc-am57x-ti-am5728-am5718-single-board-computer/
> 
> https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/
> 
> Add basic board support, including UART3, used as a serial console.
> 
> Signed-off-by: Dmitry Lifshitz 
> Acked-by: Igor Grinberg 

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/arm/omap/omap.txt  |  3 ++
>  arch/arm/boot/dts/Makefile |  1 +
>  arch/arm/boot/dts/am57xx-sbc-am57x.dts | 36 
> ++
>  3 files changed, 40 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am57xx-sbc-am57x.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index dd53c90..42cdad1 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -159,6 +159,9 @@ Boards:
>  - AM57XX CL-SOM-AM57x
>compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", 
> "ti,dra74", "ti,dra7"
>  
> +- AM57XX SBC-AM57x
> +  compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", "ti,am5728", 
> "ti,dra742", "ti,dra74", "ti,dra7"
> +
>  - DRA742 EVM:  Software Development Board for DRA742
>compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 803a020..4c73ab9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -479,6 +479,7 @@ dtb-$(CONFIG_SOC_OMAP5) += \
>  dtb-$(CONFIG_SOC_DRA7XX) += \
>   am57xx-beagle-x15.dtb \
>   am57xx-cl-som-am57x.dtb \
> + am57xx-sbc-am57x.dtb \
>   dra7-evm.dtb \
>   dra72-evm.dtb
>  dtb-$(CONFIG_ARCH_ORION5X) += \
> diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts 
> b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> new file mode 100644
> index 000..804ad72
> --- /dev/null
> +++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> @@ -0,0 +1,36 @@
> +/*
> + * Support for CompuLab SBC-AM57x single board computer
> + *
> + * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
> + * Author: Dmitry Lifshitz 
> + *
> + * 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 "am57xx-cl-som-am57x.dts"
> +#include "compulab-sb-som.dtsi"
> +
> +/ {
> + model = "CompuLab CL-SOM-AM57x on SB-SOM-AM57x";
> + compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", 
> "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7";
> +};
> +
> +&dra7_pmx_core {
> + uart3_pins_default: uart3_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_SLEW | MUX_MODE2)   
> /* uart2_ctsn.uart3_rxd */
> + DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_SLEW | MUX_MODE1)   
> /* uart2_rtsn.uart3_txd */
> + >;
> + };
> +};
> +
> +&uart3 {
> + status = "okay";
> + interrupts-extended = <&crossbar_mpu GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> +   <&dra7_pmx_core 0x3f8>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart3_pins_default>;
> +};
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH (v6) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding

[Rob Herring]

On Tue, Nov 24, 2015 at 08:19:37PM -, Simon Arlott wrote:
> Add device tree binding for NAND on the BCM63268.
> 
> The BCM63268 has a NAND interrupt register with combined status and enable
> registers.
> 
> Signed-off-by: Simon Arlott 

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/mtd/brcm,brcmnand.txt  | 35 
> ++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> index 4ff7128..f2a71c8 100644
> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and 
> associated register resources w
> and enable registers
>   - reg-names: (required) "nand-int-base"
> 
> +   * "brcm,nand-bcm63268"
> + - compatible: should contain "brcm,nand-bcm", "brcm,nand-bcm63268"
> + - reg: (required) the 'NAND_INTR_BASE' register range, with combined 
> status
> +   and enable registers, and boot address registers
> + - reg-names: (required) "nand-intr-base"
> + - clock: (required) reference to the clock for the NAND controller
> + - clock-names: (required) "nand"
> +
> * "brcm,nand-iproc"
>   - reg: (required) the "IDM" register range, for interrupt enable and APB
> bus access endianness configuration, and the "EXT" register range,
> @@ -148,3 +156,30 @@ nand@f0442800 {
>   };
>   };
>  };
> +
> +nand@1200 {
> + compatible = "brcm,nand-bcm63168", "brcm,nand-bcm63268",
> + "brcm,brcmnand-v4.0", "brcm,brcmnand";
> + reg = <0x1200 0x180>,
> +   <0x1600 0x200>,
> +   <0x10b0 0x10>;
> + reg-names = "nand", "nand-cache", "nand-intr-base";
> + interrupt-parent = <&periph_intc>;
> + interrupts = <50>;
> + clocks = <&periph_clk 20>;
> + clock-names = "nand";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + nand0: nandcs@0 {
> + compatible = "brcm,nandcs";
> + reg = <0>;
> + nand-on-flash-bbt;
> + nand-ecc-strength = <1>;
> + nand-ecc-step-size = <512>;
> +
> + #address-cells = <0>;
> + #size-cells = <0>;
> + };
> +};
> -- 
> 2.1.4
> 
> -- 
> Simon Arlott
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html