[PATCH v3 0/6] Add MCAN Support for dra76x

[PATCH v3 0/6] Add MCAN Support for dra76x

[Faiz Abbas]

The following patches add dts and sysconfig support
for MCAN on TI's dra76 SOCs

The patches depend on the following series:
https://patchwork.kernel.org/patch/10221105/

Changes in v3:
 1. Added reset functionality to the ti-sysc
    driver. This enables me to drop the hwmod
    data patch as everything is being done in dt.

 2. Dropped ti,hwmods from the dts nodes

 3. Fixed the unit address of target-module
    and mcan

 4. Removed the status="disabled" in dtsi
    followed by status="okay" in dts.

Changes in v2:
 1. Added Support for mcan in the ti-sysc driver
    Also added the target-module node for the same

 2. Added clkctrl data for mcan clocks

Faiz Abbas (4):
  clk: ti: dra7: Add clkctrl clock data for the mcan clocks
  bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x
  bus: ti-sysc: Add support for software reset
  ARM: dts: Add generic interconnect target module node for MCAN

Franklin S Cooper Jr (1):
  ARM: dts: dra76x: Add MCAN node

Lokesh Vutla (1):
  ARM: dts: dra762: Add MCAN clock support

 .../devicetree/bindings/bus/ti-sysc.txt       |  1 +
 arch/arm/boot/dts/dra76-evm.dts               |  6 ++
 arch/arm/boot/dts/dra76x.dtsi                 | 65 +++++++++++++++++++
 drivers/bus/ti-sysc.c                         | 58 +++++++++++++++++
 drivers/clk/ti/clk-7xx.c                      |  1 +
 include/dt-bindings/bus/ti-sysc.h             |  2 +
 include/dt-bindings/clock/dra7.h              |  1 +
 include/linux/platform_data/ti-sysc.h         |  1 +
 8 files changed, 135 insertions(+)

-- 
2.17.0

[PATCH v3 0/6] Add MCAN Support for dra76x

[Faiz Abbas]

The following patches add dts and sysconfig support
for MCAN on TI's dra76 SOCs

The patches depend on the following series:
https://patchwork.kernel.org/patch/10221105/

Changes in v3:
 1. Added reset functionality to the ti-sysc
    driver. This enables me to drop the hwmod
    data patch as everything is being done in dt.

 2. Dropped ti,hwmods from the dts nodes

 3. Fixed the unit address of target-module
    and mcan

 4. Removed the status="disabled" in dtsi
    followed by status="okay" in dts.

Changes in v2:
 1. Added Support for mcan in the ti-sysc driver
    Also added the target-module node for the same

 2. Added clkctrl data for mcan clocks

Faiz Abbas (4):
  clk: ti: dra7: Add clkctrl clock data for the mcan clocks
  bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x
  bus: ti-sysc: Add support for software reset
  ARM: dts: Add generic interconnect target module node for MCAN

Franklin S Cooper Jr (1):
  ARM: dts: dra76x: Add MCAN node

Lokesh Vutla (1):
  ARM: dts: dra762: Add MCAN clock support

 .../devicetree/bindings/bus/ti-sysc.txt       |  1 +
 arch/arm/boot/dts/dra76-evm.dts               |  6 ++
 arch/arm/boot/dts/dra76x.dtsi                 | 65 +++++++++++++++++++
 drivers/bus/ti-sysc.c                         | 58 +++++++++++++++++
 drivers/clk/ti/clk-7xx.c                      |  1 +
 include/dt-bindings/bus/ti-sysc.h             |  2 +
 include/dt-bindings/clock/dra7.h              |  1 +
 include/linux/platform_data/ti-sysc.h         |  1 +
 8 files changed, 135 insertions(+)

-- 
2.17.0

[PATCH v3 0/6] Add MCAN Support for dra76x

[Faiz Abbas]

The following patches add dts and sysconfig support
for MCAN on TI's dra76 SOCs

The patches depend on the following series:
https://patchwork.kernel.org/patch/10221105/

Changes in v3:
 1. Added reset functionality to the ti-sysc
    driver. This enables me to drop the hwmod
    data patch as everything is being done in dt.

 2. Dropped ti,hwmods from the dts nodes

 3. Fixed the unit address of target-module
    and mcan

 4. Removed the status="disabled" in dtsi
    followed by status="okay" in dts.

Changes in v2:
 1. Added Support for mcan in the ti-sysc driver
    Also added the target-module node for the same

 2. Added clkctrl data for mcan clocks

Faiz Abbas (4):
  clk: ti: dra7: Add clkctrl clock data for the mcan clocks
  bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x
  bus: ti-sysc: Add support for software reset
  ARM: dts: Add generic interconnect target module node for MCAN

Franklin S Cooper Jr (1):
  ARM: dts: dra76x: Add MCAN node

Lokesh Vutla (1):
  ARM: dts: dra762: Add MCAN clock support

 .../devicetree/bindings/bus/ti-sysc.txt       |  1 +
 arch/arm/boot/dts/dra76-evm.dts               |  6 ++
 arch/arm/boot/dts/dra76x.dtsi                 | 65 +++++++++++++++++++
 drivers/bus/ti-sysc.c                         | 58 +++++++++++++++++
 drivers/clk/ti/clk-7xx.c                      |  1 +
 include/dt-bindings/bus/ti-sysc.h             |  2 +
 include/dt-bindings/clock/dra7.h              |  1 +
 include/linux/platform_data/ti-sysc.h         |  1 +
 8 files changed, 135 insertions(+)

-- 
2.17.0

[PATCH v3 1/6] ARM: dts: dra762: Add MCAN clock support

[Faiz Abbas]

From: Lokesh Vutla <lokeshvutla@ti.com>

MCAN is clocked by H14 divider of DPLL_GMAC. Unlike other
DPLL dividers this DPLL_GMAC H14 divider is controlled by
control module. Adding support for these clocks.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 arch/arm/boot/dts/dra76x.dtsi | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index 1c88c581ff18..bfc82636999c 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -17,3 +17,36 @@
 &crossbar_mpu {
 	ti,irqs-skip = <10 67 68 133 139 140>;
 };
+
+&scm_conf_clocks {
+	dpll_gmac_h14x2_ctrl_ck: dpll_gmac_h14x2_ctrl_ck@3fc {
+		#clock-cells = <0>;
+		compatible = "ti,divider-clock";
+		clocks = <&dpll_gmac_x2_ck>;
+		ti,max-div = <63>;
+		reg = <0x03fc>;
+		ti,bit-shift=<20>;
+		ti,latch-bit=<26>;
+		assigned-clocks = <&dpll_gmac_h14x2_ctrl_ck>;
+		assigned-clock-rates = <80000000>;
+	};
+
+	dpll_gmac_h14x2_ctrl_mux_ck: dpll_gmac_h14x2_ctrl_mux_ck@3fc {
+		#clock-cells = <0>;
+		compatible = "ti,mux-clock";
+		clocks = <&dpll_gmac_ck>, <&dpll_gmac_h14x2_ctrl_ck>;
+		reg = <0x3fc>;
+		ti,bit-shift = <29>;
+		ti,latch-bit=<26>;
+		assigned-clocks = <&dpll_gmac_h14x2_ctrl_mux_ck>;
+		assigned-clock-parents = <&dpll_gmac_h14x2_ctrl_ck>;
+	};
+
+	mcan_clk: mcan_clk@3fc {
+		#clock-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&dpll_gmac_h14x2_ctrl_mux_ck>;
+		ti,bit-shift = <27>;
+		reg = <0x3fc>;
+	};
+};
-- 
2.17.0

[PATCH v3 1/6] ARM: dts: dra762: Add MCAN clock support

[Faiz Abbas]

From: Lokesh Vutla <lokeshvutla@ti.com>

MCAN is clocked by H14 divider of DPLL_GMAC. Unlike other
DPLL dividers this DPLL_GMAC H14 divider is controlled by
control module. Adding support for these clocks.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 arch/arm/boot/dts/dra76x.dtsi | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index 1c88c581ff18..bfc82636999c 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -17,3 +17,36 @@
 &crossbar_mpu {
 	ti,irqs-skip = <10 67 68 133 139 140>;
 };
+
+&scm_conf_clocks {
+	dpll_gmac_h14x2_ctrl_ck: dpll_gmac_h14x2_ctrl_ck at 3fc {
+		#clock-cells = <0>;
+		compatible = "ti,divider-clock";
+		clocks = <&dpll_gmac_x2_ck>;
+		ti,max-div = <63>;
+		reg = <0x03fc>;
+		ti,bit-shift=<20>;
+		ti,latch-bit=<26>;
+		assigned-clocks = <&dpll_gmac_h14x2_ctrl_ck>;
+		assigned-clock-rates = <80000000>;
+	};
+
+	dpll_gmac_h14x2_ctrl_mux_ck: dpll_gmac_h14x2_ctrl_mux_ck at 3fc {
+		#clock-cells = <0>;
+		compatible = "ti,mux-clock";
+		clocks = <&dpll_gmac_ck>, <&dpll_gmac_h14x2_ctrl_ck>;
+		reg = <0x3fc>;
+		ti,bit-shift = <29>;
+		ti,latch-bit=<26>;
+		assigned-clocks = <&dpll_gmac_h14x2_ctrl_mux_ck>;
+		assigned-clock-parents = <&dpll_gmac_h14x2_ctrl_ck>;
+	};
+
+	mcan_clk: mcan_clk at 3fc {
+		#clock-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&dpll_gmac_h14x2_ctrl_mux_ck>;
+		ti,bit-shift = <27>;
+		reg = <0x3fc>;
+	};
+};
-- 
2.17.0

[PATCH v3 1/6] ARM: dts: dra762: Add MCAN clock support

[Faiz Abbas]

From: Lokesh Vutla <lokeshvutla@ti.com>

MCAN is clocked by H14 divider of DPLL_GMAC. Unlike other
DPLL dividers this DPLL_GMAC H14 divider is controlled by
control module. Adding support for these clocks.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 arch/arm/boot/dts/dra76x.dtsi | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index 1c88c581ff18..bfc82636999c 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -17,3 +17,36 @@
 &crossbar_mpu {
 	ti,irqs-skip = <10 67 68 133 139 140>;
 };
+
+&scm_conf_clocks {
+	dpll_gmac_h14x2_ctrl_ck: dpll_gmac_h14x2_ctrl_ck@3fc {
+		#clock-cells = <0>;
+		compatible = "ti,divider-clock";
+		clocks = <&dpll_gmac_x2_ck>;
+		ti,max-div = <63>;
+		reg = <0x03fc>;
+		ti,bit-shift=<20>;
+		ti,latch-bit=<26>;
+		assigned-clocks = <&dpll_gmac_h14x2_ctrl_ck>;
+		assigned-clock-rates = <80000000>;
+	};
+
+	dpll_gmac_h14x2_ctrl_mux_ck: dpll_gmac_h14x2_ctrl_mux_ck@3fc {
+		#clock-cells = <0>;
+		compatible = "ti,mux-clock";
+		clocks = <&dpll_gmac_ck>, <&dpll_gmac_h14x2_ctrl_ck>;
+		reg = <0x3fc>;
+		ti,bit-shift = <29>;
+		ti,latch-bit=<26>;
+		assigned-clocks = <&dpll_gmac_h14x2_ctrl_mux_ck>;
+		assigned-clock-parents = <&dpll_gmac_h14x2_ctrl_ck>;
+	};
+
+	mcan_clk: mcan_clk@3fc {
+		#clock-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&dpll_gmac_h14x2_ctrl_mux_ck>;
+		ti,bit-shift = <27>;
+		reg = <0x3fc>;
+	};
+};
-- 
2.17.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 1/6] ARM: dts: dra762: Add MCAN clock support

[Faiz Abbas]

From: Lokesh Vutla <lokeshvutla@ti.com>

MCAN is clocked by H14 divider of DPLL_GMAC. Unlike other
DPLL dividers this DPLL_GMAC H14 divider is controlled by
control module. Adding support for these clocks.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 arch/arm/boot/dts/dra76x.dtsi | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index 1c88c581ff18..bfc82636999c 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -17,3 +17,36 @@
 &crossbar_mpu {
 	ti,irqs-skip = <10 67 68 133 139 140>;
 };
+
+&scm_conf_clocks {
+	dpll_gmac_h14x2_ctrl_ck: dpll_gmac_h14x2_ctrl_ck@3fc {
+		#clock-cells = <0>;
+		compatible = "ti,divider-clock";
+		clocks = <&dpll_gmac_x2_ck>;
+		ti,max-div = <63>;
+		reg = <0x03fc>;
+		ti,bit-shift=<20>;
+		ti,latch-bit=<26>;
+		assigned-clocks = <&dpll_gmac_h14x2_ctrl_ck>;
+		assigned-clock-rates = <80000000>;
+	};
+
+	dpll_gmac_h14x2_ctrl_mux_ck: dpll_gmac_h14x2_ctrl_mux_ck@3fc {
+		#clock-cells = <0>;
+		compatible = "ti,mux-clock";
+		clocks = <&dpll_gmac_ck>, <&dpll_gmac_h14x2_ctrl_ck>;
+		reg = <0x3fc>;
+		ti,bit-shift = <29>;
+		ti,latch-bit=<26>;
+		assigned-clocks = <&dpll_gmac_h14x2_ctrl_mux_ck>;
+		assigned-clock-parents = <&dpll_gmac_h14x2_ctrl_ck>;
+	};
+
+	mcan_clk: mcan_clk@3fc {
+		#clock-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&dpll_gmac_h14x2_ctrl_mux_ck>;
+		ti,bit-shift = <27>;
+		reg = <0x3fc>;
+	};
+};
-- 
2.17.0

[PATCH v3 2/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks

[Faiz Abbas]

Add clkctrl data for the m_can clocks and register it within the
clkctrl driver

CC: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 drivers/clk/ti/clk-7xx.c         | 1 +
 include/dt-bindings/clock/dra7.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index fb249a1637a5..71a122b2dc67 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -708,6 +708,7 @@ static const struct omap_clkctrl_reg_data dra7_wkupaon_clkctrl_regs[] __initcons
 	{ DRA7_COUNTER_32K_CLKCTRL, NULL, 0, "wkupaon_iclk_mux" },
 	{ DRA7_UART10_CLKCTRL, dra7_uart10_bit_data, CLKF_SW_SUP, "wkupaon_cm:clk:0060:24" },
 	{ DRA7_DCAN1_CLKCTRL, dra7_dcan1_bit_data, CLKF_SW_SUP, "wkupaon_cm:clk:0068:24" },
+	{ DRA7_ADC_CLKCTRL, NULL, CLKF_SW_SUP, "mcan_clk"},
 	{ 0 },
 };
 
diff --git a/include/dt-bindings/clock/dra7.h b/include/dt-bindings/clock/dra7.h
index 5e1061b15aed..d7549c57cac3 100644
--- a/include/dt-bindings/clock/dra7.h
+++ b/include/dt-bindings/clock/dra7.h
@@ -168,5 +168,6 @@
 #define DRA7_COUNTER_32K_CLKCTRL	DRA7_CLKCTRL_INDEX(0x50)
 #define DRA7_UART10_CLKCTRL	DRA7_CLKCTRL_INDEX(0x80)
 #define DRA7_DCAN1_CLKCTRL	DRA7_CLKCTRL_INDEX(0x88)
+#define DRA7_ADC_CLKCTRL	DRA7_CLKCTRL_INDEX(0xa0)
 
 #endif
-- 
2.17.0

[PATCH v3 2/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks

[Faiz Abbas]

Add clkctrl data for the m_can clocks and register it within the
clkctrl driver

CC: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 drivers/clk/ti/clk-7xx.c         | 1 +
 include/dt-bindings/clock/dra7.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index fb249a1637a5..71a122b2dc67 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -708,6 +708,7 @@ static const struct omap_clkctrl_reg_data dra7_wkupaon_clkctrl_regs[] __initcons
 	{ DRA7_COUNTER_32K_CLKCTRL, NULL, 0, "wkupaon_iclk_mux" },
 	{ DRA7_UART10_CLKCTRL, dra7_uart10_bit_data, CLKF_SW_SUP, "wkupaon_cm:clk:0060:24" },
 	{ DRA7_DCAN1_CLKCTRL, dra7_dcan1_bit_data, CLKF_SW_SUP, "wkupaon_cm:clk:0068:24" },
+	{ DRA7_ADC_CLKCTRL, NULL, CLKF_SW_SUP, "mcan_clk"},
 	{ 0 },
 };
 
diff --git a/include/dt-bindings/clock/dra7.h b/include/dt-bindings/clock/dra7.h
index 5e1061b15aed..d7549c57cac3 100644
--- a/include/dt-bindings/clock/dra7.h
+++ b/include/dt-bindings/clock/dra7.h
@@ -168,5 +168,6 @@
 #define DRA7_COUNTER_32K_CLKCTRL	DRA7_CLKCTRL_INDEX(0x50)
 #define DRA7_UART10_CLKCTRL	DRA7_CLKCTRL_INDEX(0x80)
 #define DRA7_DCAN1_CLKCTRL	DRA7_CLKCTRL_INDEX(0x88)
+#define DRA7_ADC_CLKCTRL	DRA7_CLKCTRL_INDEX(0xa0)
 
 #endif
-- 
2.17.0

[PATCH v3 2/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks

[Faiz Abbas]

Add clkctrl data for the m_can clocks and register it within the
clkctrl driver

CC: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 drivers/clk/ti/clk-7xx.c         | 1 +
 include/dt-bindings/clock/dra7.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index fb249a1637a5..71a122b2dc67 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -708,6 +708,7 @@ static const struct omap_clkctrl_reg_data dra7_wkupaon_clkctrl_regs[] __initcons
 	{ DRA7_COUNTER_32K_CLKCTRL, NULL, 0, "wkupaon_iclk_mux" },
 	{ DRA7_UART10_CLKCTRL, dra7_uart10_bit_data, CLKF_SW_SUP, "wkupaon_cm:clk:0060:24" },
 	{ DRA7_DCAN1_CLKCTRL, dra7_dcan1_bit_data, CLKF_SW_SUP, "wkupaon_cm:clk:0068:24" },
+	{ DRA7_ADC_CLKCTRL, NULL, CLKF_SW_SUP, "mcan_clk"},
 	{ 0 },
 };
 
diff --git a/include/dt-bindings/clock/dra7.h b/include/dt-bindings/clock/dra7.h
index 5e1061b15aed..d7549c57cac3 100644
--- a/include/dt-bindings/clock/dra7.h
+++ b/include/dt-bindings/clock/dra7.h
@@ -168,5 +168,6 @@
 #define DRA7_COUNTER_32K_CLKCTRL	DRA7_CLKCTRL_INDEX(0x50)
 #define DRA7_UART10_CLKCTRL	DRA7_CLKCTRL_INDEX(0x80)
 #define DRA7_DCAN1_CLKCTRL	DRA7_CLKCTRL_INDEX(0x88)
+#define DRA7_ADC_CLKCTRL	DRA7_CLKCTRL_INDEX(0xa0)
 
 #endif
-- 
2.17.0

Re: [PATCH v3 2/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks

[Rob Herring]

On Wed, Jun 06, 2018 at 11:38:22AM +0530, Faiz Abbas wrote:
> Add clkctrl data for the m_can clocks and register it within the
> clkctrl driver
> 
> CC: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> ---
>  drivers/clk/ti/clk-7xx.c         | 1 +
>  include/dt-bindings/clock/dra7.h | 1 +

Acked-by: Rob Herring <robh@kernel.org>

>  2 files changed, 2 insertions(+)
> 

[PATCH v3 2/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks

[Rob Herring]

On Wed, Jun 06, 2018 at 11:38:22AM +0530, Faiz Abbas wrote:
> Add clkctrl data for the m_can clocks and register it within the
> clkctrl driver
> 
> CC: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> ---
>  drivers/clk/ti/clk-7xx.c         | 1 +
>  include/dt-bindings/clock/dra7.h | 1 +

Acked-by: Rob Herring <robh@kernel.org>

>  2 files changed, 2 insertions(+)
> 

[PATCH v3 3/6] bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x

[Faiz Abbas]

The dra76x MCAN generic interconnect module has a its own
format for the bits in the control registers.

Therefore add a new module type, new regbits and new capabilities
specific to the MCAN module.

Acked-by: Rob Herring <robh@kernel.org>
CC: Tony Lindgren <tony@atomide.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 .../devicetree/bindings/bus/ti-sysc.txt        |  1 +
 drivers/bus/ti-sysc.c                          | 18 ++++++++++++++++++
 include/dt-bindings/bus/ti-sysc.h              |  2 ++
 include/linux/platform_data/ti-sysc.h          |  1 +
 4 files changed, 22 insertions(+)

diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.txt b/Documentation/devicetree/bindings/bus/ti-sysc.txt
index 2957a9ae291f..ebbb11144b7b 100644
--- a/Documentation/devicetree/bindings/bus/ti-sysc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-sysc.txt
@@ -36,6 +36,7 @@ Required standard properties:
 		"ti,sysc-omap-aes"
 		"ti,sysc-mcasp"
 		"ti,sysc-usb-host-fs"
+		"ti,sysc-dra7-mcan"
 
 - reg		shall have register areas implemented for the interconnect
 		target module in question such as revision, sysc and syss
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index 7cd2fd04b212..4a2244419b9b 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -1262,6 +1262,23 @@ static const struct sysc_capabilities sysc_omap4_usb_host_fs = {
 	.regbits = &sysc_regbits_omap4_usb_host_fs,
 };
 
+static const struct sysc_regbits sysc_regbits_dra7_mcan = {
+	.dmadisable_shift = -ENODEV,
+	.midle_shift = -ENODEV,
+	.sidle_shift = -ENODEV,
+	.clkact_shift = -ENODEV,
+	.enwkup_shift = 4,
+	.srst_shift = 0,
+	.emufree_shift = -ENODEV,
+	.autoidle_shift = -ENODEV,
+};
+
+static const struct sysc_capabilities sysc_dra7_mcan = {
+	.type = TI_SYSC_DRA7_MCAN,
+	.sysc_mask = SYSC_DRA7_MCAN_ENAWAKEUP | SYSC_OMAP4_SOFTRESET,
+	.regbits = &sysc_regbits_dra7_mcan,
+};
+
 static int sysc_init_pdata(struct sysc *ddata)
 {
 	struct ti_sysc_platform_data *pdata = dev_get_platdata(ddata->dev);
@@ -1441,6 +1458,7 @@ static const struct of_device_id sysc_match[] = {
 	{ .compatible = "ti,sysc-mcasp", .data = &sysc_omap4_mcasp, },
 	{ .compatible = "ti,sysc-usb-host-fs",
 	  .data = &sysc_omap4_usb_host_fs, },
+	{ .compatible = "ti,sysc-dra7-mcan", .data = &sysc_dra7_mcan, },
 	{  },
 };
 MODULE_DEVICE_TABLE(of, sysc_match);
diff --git a/include/dt-bindings/bus/ti-sysc.h b/include/dt-bindings/bus/ti-sysc.h
index 2c005376ac0e..7138384e2ef9 100644
--- a/include/dt-bindings/bus/ti-sysc.h
+++ b/include/dt-bindings/bus/ti-sysc.h
@@ -15,6 +15,8 @@
 /* SmartReflex sysc found on 36xx and later */
 #define SYSC_OMAP3_SR_ENAWAKEUP		(1 << 26)
 
+#define SYSC_DRA7_MCAN_ENAWAKEUP	(1 << 4)
+
 /* SYSCONFIG STANDBYMODE/MIDLEMODE/SIDLEMODE supported by hardware */
 #define SYSC_IDLE_FORCE			0
 #define SYSC_IDLE_NO			1
diff --git a/include/linux/platform_data/ti-sysc.h b/include/linux/platform_data/ti-sysc.h
index 80ce28d40832..1ea3aab972b4 100644
--- a/include/linux/platform_data/ti-sysc.h
+++ b/include/linux/platform_data/ti-sysc.h
@@ -14,6 +14,7 @@ enum ti_sysc_module_type {
 	TI_SYSC_OMAP4_SR,
 	TI_SYSC_OMAP4_MCASP,
 	TI_SYSC_OMAP4_USB_HOST_FS,
+	TI_SYSC_DRA7_MCAN,
 };
 
 struct ti_sysc_cookie {
-- 
2.17.0

[PATCH v3 3/6] bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x

[Faiz Abbas]

The dra76x MCAN generic interconnect module has a its own
format for the bits in the control registers.

Therefore add a new module type, new regbits and new capabilities
specific to the MCAN module.

Acked-by: Rob Herring <robh@kernel.org>
CC: Tony Lindgren <tony@atomide.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 .../devicetree/bindings/bus/ti-sysc.txt        |  1 +
 drivers/bus/ti-sysc.c                          | 18 ++++++++++++++++++
 include/dt-bindings/bus/ti-sysc.h              |  2 ++
 include/linux/platform_data/ti-sysc.h          |  1 +
 4 files changed, 22 insertions(+)

diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.txt b/Documentation/devicetree/bindings/bus/ti-sysc.txt
index 2957a9ae291f..ebbb11144b7b 100644
--- a/Documentation/devicetree/bindings/bus/ti-sysc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-sysc.txt
@@ -36,6 +36,7 @@ Required standard properties:
 		"ti,sysc-omap-aes"
 		"ti,sysc-mcasp"
 		"ti,sysc-usb-host-fs"
+		"ti,sysc-dra7-mcan"
 
 - reg		shall have register areas implemented for the interconnect
 		target module in question such as revision, sysc and syss
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index 7cd2fd04b212..4a2244419b9b 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -1262,6 +1262,23 @@ static const struct sysc_capabilities sysc_omap4_usb_host_fs = {
 	.regbits = &sysc_regbits_omap4_usb_host_fs,
 };
 
+static const struct sysc_regbits sysc_regbits_dra7_mcan = {
+	.dmadisable_shift = -ENODEV,
+	.midle_shift = -ENODEV,
+	.sidle_shift = -ENODEV,
+	.clkact_shift = -ENODEV,
+	.enwkup_shift = 4,
+	.srst_shift = 0,
+	.emufree_shift = -ENODEV,
+	.autoidle_shift = -ENODEV,
+};
+
+static const struct sysc_capabilities sysc_dra7_mcan = {
+	.type = TI_SYSC_DRA7_MCAN,
+	.sysc_mask = SYSC_DRA7_MCAN_ENAWAKEUP | SYSC_OMAP4_SOFTRESET,
+	.regbits = &sysc_regbits_dra7_mcan,
+};
+
 static int sysc_init_pdata(struct sysc *ddata)
 {
 	struct ti_sysc_platform_data *pdata = dev_get_platdata(ddata->dev);
@@ -1441,6 +1458,7 @@ static const struct of_device_id sysc_match[] = {
 	{ .compatible = "ti,sysc-mcasp", .data = &sysc_omap4_mcasp, },
 	{ .compatible = "ti,sysc-usb-host-fs",
 	  .data = &sysc_omap4_usb_host_fs, },
+	{ .compatible = "ti,sysc-dra7-mcan", .data = &sysc_dra7_mcan, },
 	{  },
 };
 MODULE_DEVICE_TABLE(of, sysc_match);
diff --git a/include/dt-bindings/bus/ti-sysc.h b/include/dt-bindings/bus/ti-sysc.h
index 2c005376ac0e..7138384e2ef9 100644
--- a/include/dt-bindings/bus/ti-sysc.h
+++ b/include/dt-bindings/bus/ti-sysc.h
@@ -15,6 +15,8 @@
 /* SmartReflex sysc found on 36xx and later */
 #define SYSC_OMAP3_SR_ENAWAKEUP		(1 << 26)
 
+#define SYSC_DRA7_MCAN_ENAWAKEUP	(1 << 4)
+
 /* SYSCONFIG STANDBYMODE/MIDLEMODE/SIDLEMODE supported by hardware */
 #define SYSC_IDLE_FORCE			0
 #define SYSC_IDLE_NO			1
diff --git a/include/linux/platform_data/ti-sysc.h b/include/linux/platform_data/ti-sysc.h
index 80ce28d40832..1ea3aab972b4 100644
--- a/include/linux/platform_data/ti-sysc.h
+++ b/include/linux/platform_data/ti-sysc.h
@@ -14,6 +14,7 @@ enum ti_sysc_module_type {
 	TI_SYSC_OMAP4_SR,
 	TI_SYSC_OMAP4_MCASP,
 	TI_SYSC_OMAP4_USB_HOST_FS,
+	TI_SYSC_DRA7_MCAN,
 };
 
 struct ti_sysc_cookie {
-- 
2.17.0

[PATCH v3 3/6] bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x

[Faiz Abbas]

The dra76x MCAN generic interconnect module has a its own
format for the bits in the control registers.

Therefore add a new module type, new regbits and new capabilities
specific to the MCAN module.

Acked-by: Rob Herring <robh@kernel.org>
CC: Tony Lindgren <tony@atomide.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 .../devicetree/bindings/bus/ti-sysc.txt        |  1 +
 drivers/bus/ti-sysc.c                          | 18 ++++++++++++++++++
 include/dt-bindings/bus/ti-sysc.h              |  2 ++
 include/linux/platform_data/ti-sysc.h          |  1 +
 4 files changed, 22 insertions(+)

diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.txt b/Documentation/devicetree/bindings/bus/ti-sysc.txt
index 2957a9ae291f..ebbb11144b7b 100644
--- a/Documentation/devicetree/bindings/bus/ti-sysc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-sysc.txt
@@ -36,6 +36,7 @@ Required standard properties:
 		"ti,sysc-omap-aes"
 		"ti,sysc-mcasp"
 		"ti,sysc-usb-host-fs"
+		"ti,sysc-dra7-mcan"
 
 - reg		shall have register areas implemented for the interconnect
 		target module in question such as revision, sysc and syss
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index 7cd2fd04b212..4a2244419b9b 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -1262,6 +1262,23 @@ static const struct sysc_capabilities sysc_omap4_usb_host_fs = {
 	.regbits = &sysc_regbits_omap4_usb_host_fs,
 };
 
+static const struct sysc_regbits sysc_regbits_dra7_mcan = {
+	.dmadisable_shift = -ENODEV,
+	.midle_shift = -ENODEV,
+	.sidle_shift = -ENODEV,
+	.clkact_shift = -ENODEV,
+	.enwkup_shift = 4,
+	.srst_shift = 0,
+	.emufree_shift = -ENODEV,
+	.autoidle_shift = -ENODEV,
+};
+
+static const struct sysc_capabilities sysc_dra7_mcan = {
+	.type = TI_SYSC_DRA7_MCAN,
+	.sysc_mask = SYSC_DRA7_MCAN_ENAWAKEUP | SYSC_OMAP4_SOFTRESET,
+	.regbits = &sysc_regbits_dra7_mcan,
+};
+
 static int sysc_init_pdata(struct sysc *ddata)
 {
 	struct ti_sysc_platform_data *pdata = dev_get_platdata(ddata->dev);
@@ -1441,6 +1458,7 @@ static const struct of_device_id sysc_match[] = {
 	{ .compatible = "ti,sysc-mcasp", .data = &sysc_omap4_mcasp, },
 	{ .compatible = "ti,sysc-usb-host-fs",
 	  .data = &sysc_omap4_usb_host_fs, },
+	{ .compatible = "ti,sysc-dra7-mcan", .data = &sysc_dra7_mcan, },
 	{  },
 };
 MODULE_DEVICE_TABLE(of, sysc_match);
diff --git a/include/dt-bindings/bus/ti-sysc.h b/include/dt-bindings/bus/ti-sysc.h
index 2c005376ac0e..7138384e2ef9 100644
--- a/include/dt-bindings/bus/ti-sysc.h
+++ b/include/dt-bindings/bus/ti-sysc.h
@@ -15,6 +15,8 @@
 /* SmartReflex sysc found on 36xx and later */
 #define SYSC_OMAP3_SR_ENAWAKEUP		(1 << 26)
 
+#define SYSC_DRA7_MCAN_ENAWAKEUP	(1 << 4)
+
 /* SYSCONFIG STANDBYMODE/MIDLEMODE/SIDLEMODE supported by hardware */
 #define SYSC_IDLE_FORCE			0
 #define SYSC_IDLE_NO			1
diff --git a/include/linux/platform_data/ti-sysc.h b/include/linux/platform_data/ti-sysc.h
index 80ce28d40832..1ea3aab972b4 100644
--- a/include/linux/platform_data/ti-sysc.h
+++ b/include/linux/platform_data/ti-sysc.h
@@ -14,6 +14,7 @@ enum ti_sysc_module_type {
 	TI_SYSC_OMAP4_SR,
 	TI_SYSC_OMAP4_MCASP,
 	TI_SYSC_OMAP4_USB_HOST_FS,
+	TI_SYSC_DRA7_MCAN,
 };
 
 struct ti_sysc_cookie {
-- 
2.17.0

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Add support for the software reset of a target interconnect
module using its sysconfig and sysstatus registers.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 drivers/bus/ti-sysc.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index 4a2244419b9b..74d716a7bd6e 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -22,11 +22,14 @@
 #include <linux/of_address.h>
 #include <linux/of_platform.h>
 #include <linux/slab.h>
+#include <linux/iopoll.h>
 
 #include <linux/platform_data/ti-sysc.h>
 
 #include <dt-bindings/bus/ti-sysc.h>
 
+#define MAX_MODULE_SOFTRESET_WAIT		10000
+
 static const char * const reg_names[] = { "rev", "sysc", "syss", };
 
 enum sysc_clocks {
@@ -74,6 +77,11 @@ struct sysc {
 	struct delayed_work idle_work;
 };
 
+void sysc_write(struct sysc *ddata, int offset, u32 value)
+{
+	writel_relaxed(value, ddata->module_va + offset);
+}
+
 static u32 sysc_read(struct sysc *ddata, int offset)
 {
 	if (ddata->cfg.quirks & SYSC_QUIRK_16BIT) {
@@ -700,6 +708,26 @@ static void sysc_init_revision_quirks(struct sysc *ddata)
 	}
 }
 
+static int sysc_reset(struct sysc *ddata)
+{
+	int offset = ddata->offsets[SYSC_SYSCONFIG];
+	int val = sysc_read(ddata, offset);
+
+	val |= (0x1 << ddata->cap->regbits->srst_shift);
+	sysc_write(ddata, offset, val);
+
+	/* Poll on reset status */
+	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
+		offset = ddata->offsets[SYSC_SYSSTATUS];
+
+		return readl_poll_timeout(ddata->module_va + offset, val,
+				(val & ddata->cfg.syss_mask) == 0x0,
+				100, MAX_MODULE_SOFTRESET_WAIT);
+	}
+
+	return 0;
+}
+
 /* At this point the module is configured enough to read the revision */
 static int sysc_init_module(struct sysc *ddata)
 {
@@ -716,6 +744,18 @@ static int sysc_init_module(struct sysc *ddata)
 
 		return 0;
 	}
+
+	if (!(ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT) &&
+	    !ddata->legacy_mode) {
+		error = sysc_reset(ddata);
+		if (error) {
+			dev_err(ddata->dev, "Reset failed with %d\n", error);
+			pm_runtime_put_sync(ddata->dev);
+
+			return error;
+		}
+	}
+
 	ddata->revision = sysc_read_revision(ddata);
 	pm_runtime_put_sync(ddata->dev);
 
-- 
2.17.0

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Add support for the software reset of a target interconnect
module using its sysconfig and sysstatus registers.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 drivers/bus/ti-sysc.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index 4a2244419b9b..74d716a7bd6e 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -22,11 +22,14 @@
 #include <linux/of_address.h>
 #include <linux/of_platform.h>
 #include <linux/slab.h>
+#include <linux/iopoll.h>
 
 #include <linux/platform_data/ti-sysc.h>
 
 #include <dt-bindings/bus/ti-sysc.h>
 
+#define MAX_MODULE_SOFTRESET_WAIT		10000
+
 static const char * const reg_names[] = { "rev", "sysc", "syss", };
 
 enum sysc_clocks {
@@ -74,6 +77,11 @@ struct sysc {
 	struct delayed_work idle_work;
 };
 
+void sysc_write(struct sysc *ddata, int offset, u32 value)
+{
+	writel_relaxed(value, ddata->module_va + offset);
+}
+
 static u32 sysc_read(struct sysc *ddata, int offset)
 {
 	if (ddata->cfg.quirks & SYSC_QUIRK_16BIT) {
@@ -700,6 +708,26 @@ static void sysc_init_revision_quirks(struct sysc *ddata)
 	}
 }
 
+static int sysc_reset(struct sysc *ddata)
+{
+	int offset = ddata->offsets[SYSC_SYSCONFIG];
+	int val = sysc_read(ddata, offset);
+
+	val |= (0x1 << ddata->cap->regbits->srst_shift);
+	sysc_write(ddata, offset, val);
+
+	/* Poll on reset status */
+	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
+		offset = ddata->offsets[SYSC_SYSSTATUS];
+
+		return readl_poll_timeout(ddata->module_va + offset, val,
+				(val & ddata->cfg.syss_mask) == 0x0,
+				100, MAX_MODULE_SOFTRESET_WAIT);
+	}
+
+	return 0;
+}
+
 /* At this point the module is configured enough to read the revision */
 static int sysc_init_module(struct sysc *ddata)
 {
@@ -716,6 +744,18 @@ static int sysc_init_module(struct sysc *ddata)
 
 		return 0;
 	}
+
+	if (!(ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT) &&
+	    !ddata->legacy_mode) {
+		error = sysc_reset(ddata);
+		if (error) {
+			dev_err(ddata->dev, "Reset failed with %d\n", error);
+			pm_runtime_put_sync(ddata->dev);
+
+			return error;
+		}
+	}
+
 	ddata->revision = sysc_read_revision(ddata);
 	pm_runtime_put_sync(ddata->dev);
 
-- 
2.17.0

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Add support for the software reset of a target interconnect
module using its sysconfig and sysstatus registers.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 drivers/bus/ti-sysc.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index 4a2244419b9b..74d716a7bd6e 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -22,11 +22,14 @@
 #include <linux/of_address.h>
 #include <linux/of_platform.h>
 #include <linux/slab.h>
+#include <linux/iopoll.h>
 
 #include <linux/platform_data/ti-sysc.h>
 
 #include <dt-bindings/bus/ti-sysc.h>
 
+#define MAX_MODULE_SOFTRESET_WAIT		10000
+
 static const char * const reg_names[] = { "rev", "sysc", "syss", };
 
 enum sysc_clocks {
@@ -74,6 +77,11 @@ struct sysc {
 	struct delayed_work idle_work;
 };
 
+void sysc_write(struct sysc *ddata, int offset, u32 value)
+{
+	writel_relaxed(value, ddata->module_va + offset);
+}
+
 static u32 sysc_read(struct sysc *ddata, int offset)
 {
 	if (ddata->cfg.quirks & SYSC_QUIRK_16BIT) {
@@ -700,6 +708,26 @@ static void sysc_init_revision_quirks(struct sysc *ddata)
 	}
 }
 
+static int sysc_reset(struct sysc *ddata)
+{
+	int offset = ddata->offsets[SYSC_SYSCONFIG];
+	int val = sysc_read(ddata, offset);
+
+	val |= (0x1 << ddata->cap->regbits->srst_shift);
+	sysc_write(ddata, offset, val);
+
+	/* Poll on reset status */
+	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
+		offset = ddata->offsets[SYSC_SYSSTATUS];
+
+		return readl_poll_timeout(ddata->module_va + offset, val,
+				(val & ddata->cfg.syss_mask) == 0x0,
+				100, MAX_MODULE_SOFTRESET_WAIT);
+	}
+
+	return 0;
+}
+
 /* At this point the module is configured enough to read the revision */
 static int sysc_init_module(struct sysc *ddata)
 {
@@ -716,6 +744,18 @@ static int sysc_init_module(struct sysc *ddata)
 
 		return 0;
 	}
+
+	if (!(ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT) &&
+	    !ddata->legacy_mode) {
+		error = sysc_reset(ddata);
+		if (error) {
+			dev_err(ddata->dev, "Reset failed with %d\n", error);
+			pm_runtime_put_sync(ddata->dev);
+
+			return error;
+		}
+	}
+
 	ddata->revision = sysc_read_revision(ddata);
 	pm_runtime_put_sync(ddata->dev);
 
-- 
2.17.0

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
> +static int sysc_reset(struct sysc *ddata)
> +{
> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
> +	int val = sysc_read(ddata, offset);
> +
> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
> +	sysc_write(ddata, offset, val);
> +
> +	/* Poll on reset status */
> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
> +		offset = ddata->offsets[SYSC_SYSSTATUS];
> +
> +		return readl_poll_timeout(ddata->module_va + offset, val,
> +				(val & ddata->cfg.syss_mask) == 0x0,
> +				100, MAX_MODULE_SOFTRESET_WAIT);
> +	}
> +
> +	return 0;
> +}

I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
addition to SYSC_QUIRK_RESET status to make it easy to
read the right register?

Then we can add support for SYSC_QUIRK_RESET_STATUS later on
when tested and return error for now.

Regards,

Tony

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
> +static int sysc_reset(struct sysc *ddata)
> +{
> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
> +	int val = sysc_read(ddata, offset);
> +
> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
> +	sysc_write(ddata, offset, val);
> +
> +	/* Poll on reset status */
> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
> +		offset = ddata->offsets[SYSC_SYSSTATUS];
> +
> +		return readl_poll_timeout(ddata->module_va + offset, val,
> +				(val & ddata->cfg.syss_mask) == 0x0,
> +				100, MAX_MODULE_SOFTRESET_WAIT);
> +	}
> +
> +	return 0;
> +}

I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
addition to SYSC_QUIRK_RESET status to make it easy to
read the right register?

Then we can add support for SYSC_QUIRK_RESET_STATUS later on
when tested and return error for now.

Regards,

Tony

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
>> +static int sysc_reset(struct sysc *ddata)
>> +{
>> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
>> +	int val = sysc_read(ddata, offset);
>> +
>> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
>> +	sysc_write(ddata, offset, val);
>> +
>> +	/* Poll on reset status */
>> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
>> +		offset = ddata->offsets[SYSC_SYSSTATUS];
>> +
>> +		return readl_poll_timeout(ddata->module_va + offset, val,
>> +				(val & ddata->cfg.syss_mask) == 0x0,
>> +				100, MAX_MODULE_SOFTRESET_WAIT);
>> +	}
>> +
>> +	return 0;
>> +}
> 
> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
> addition to SYSC_QUIRK_RESET status to make it easy to
> read the right register?

I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
the register. Are there layouts in which the reset status bit is in the
sysconfig register rather than the sysstatus register?

Thanks,
Faiz

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
>> +static int sysc_reset(struct sysc *ddata)
>> +{
>> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
>> +	int val = sysc_read(ddata, offset);
>> +
>> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
>> +	sysc_write(ddata, offset, val);
>> +
>> +	/* Poll on reset status */
>> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
>> +		offset = ddata->offsets[SYSC_SYSSTATUS];
>> +
>> +		return readl_poll_timeout(ddata->module_va + offset, val,
>> +				(val & ddata->cfg.syss_mask) == 0x0,
>> +				100, MAX_MODULE_SOFTRESET_WAIT);
>> +	}
>> +
>> +	return 0;
>> +}
> 
> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
> addition to SYSC_QUIRK_RESET status to make it easy to
> read the right register?

I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
the register. Are there layouts in which the reset status bit is in the
sysconfig register rather than the sysstatus register?

Thanks,
Faiz

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
>> +static int sysc_reset(struct sysc *ddata)
>> +{
>> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
>> +	int val = sysc_read(ddata, offset);
>> +
>> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
>> +	sysc_write(ddata, offset, val);
>> +
>> +	/* Poll on reset status */
>> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
>> +		offset = ddata->offsets[SYSC_SYSSTATUS];
>> +
>> +		return readl_poll_timeout(ddata->module_va + offset, val,
>> +				(val & ddata->cfg.syss_mask) == 0x0,
>> +				100, MAX_MODULE_SOFTRESET_WAIT);
>> +	}
>> +
>> +	return 0;
>> +}
> 
> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
> addition to SYSC_QUIRK_RESET status to make it easy to
> read the right register?

I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
the register. Are there layouts in which the reset status bit is in the
sysconfig register rather than the sysstatus register?

Thanks,
Faiz

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
> Hi,
> 
> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
> > * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
> >> +static int sysc_reset(struct sysc *ddata)
> >> +{
> >> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
> >> +	int val = sysc_read(ddata, offset);
> >> +
> >> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
> >> +	sysc_write(ddata, offset, val);
> >> +
> >> +	/* Poll on reset status */
> >> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
> >> +		offset = ddata->offsets[SYSC_SYSSTATUS];
> >> +
> >> +		return readl_poll_timeout(ddata->module_va + offset, val,
> >> +				(val & ddata->cfg.syss_mask) == 0x0,
> >> +				100, MAX_MODULE_SOFTRESET_WAIT);
> >> +	}
> >> +
> >> +	return 0;
> >> +}
> > 
> > I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
> > addition to SYSC_QUIRK_RESET status to make it easy to
> > read the right register?
> 
> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
> the register. Are there layouts in which the reset status bit is in the
> sysconfig register rather than the sysstatus register?

Yes we can have reset status bit in either syss or syssconfig register.
We detect that in sysc_init_syss_mask() but we should also set something
at that point to make it clear which reset to use. But as we don't need
the quirk flag, it's probably set a function pointer after the detection.
So how about let's have two functions sysc_reset() and sysc_syss_reset()
and then we can implement sysc_syss_reset() in a separate patch after
testing it when we have a non-platform data using example for
sysc_syss_reset().

Regards,

Tony

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
> Hi,
> 
> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
> > * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
> >> +static int sysc_reset(struct sysc *ddata)
> >> +{
> >> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
> >> +	int val = sysc_read(ddata, offset);
> >> +
> >> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
> >> +	sysc_write(ddata, offset, val);
> >> +
> >> +	/* Poll on reset status */
> >> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
> >> +		offset = ddata->offsets[SYSC_SYSSTATUS];
> >> +
> >> +		return readl_poll_timeout(ddata->module_va + offset, val,
> >> +				(val & ddata->cfg.syss_mask) == 0x0,
> >> +				100, MAX_MODULE_SOFTRESET_WAIT);
> >> +	}
> >> +
> >> +	return 0;
> >> +}
> > 
> > I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
> > addition to SYSC_QUIRK_RESET status to make it easy to
> > read the right register?
> 
> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
> the register. Are there layouts in which the reset status bit is in the
> sysconfig register rather than the sysstatus register?

Yes we can have reset status bit in either syss or syssconfig register.
We detect that in sysc_init_syss_mask() but we should also set something
at that point to make it clear which reset to use. But as we don't need
the quirk flag, it's probably set a function pointer after the detection.
So how about let's have two functions sysc_reset() and sysc_syss_reset()
and then we can implement sysc_syss_reset() in a separate patch after
testing it when we have a non-platform data using example for
sysc_syss_reset().

Regards,

Tony

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi Tony,

On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
>> Hi,
>>
>> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
>>> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
>>>> +static int sysc_reset(struct sysc *ddata)
>>>> +{
>>>> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
>>>> +	int val = sysc_read(ddata, offset);
>>>> +
>>>> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
>>>> +	sysc_write(ddata, offset, val);
>>>> +
>>>> +	/* Poll on reset status */
>>>> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
>>>> +		offset = ddata->offsets[SYSC_SYSSTATUS];
>>>> +
>>>> +		return readl_poll_timeout(ddata->module_va + offset, val,
>>>> +				(val & ddata->cfg.syss_mask) == 0x0,
>>>> +				100, MAX_MODULE_SOFTRESET_WAIT);
>>>> +	}
>>>> +
>>>> +	return 0;
>>>> +}
>>>
>>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
>>> addition to SYSC_QUIRK_RESET status to make it easy to
>>> read the right register?
>>
>> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
>> the register. Are there layouts in which the reset status bit is in the
>> sysconfig register rather than the sysstatus register?
> 
> Yes we can have reset status bit in either syss or syssconfig register.

You mean sysstatus and sysconfig right?

> We detect that in sysc_init_syss_mask() but we should also set something
> at that point to make it clear which reset to use. But as we don't need
> the quirk flag, it's probably set a function pointer after the detection.
> So how about let's have two functions sysc_reset() and sysc_syss_reset()
> and then we can implement sysc_syss_reset() in a separate patch after
> testing it when we have a non-platform data using example for
> sysc_syss_reset().
> 

Shouldn't the function I add be called sysc_syss_reset()? The reset
status bit is in the sysstatus.

Thanks,
Faiz

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi Tony,

On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
>> Hi,
>>
>> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
>>> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
>>>> +static int sysc_reset(struct sysc *ddata)
>>>> +{
>>>> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
>>>> +	int val = sysc_read(ddata, offset);
>>>> +
>>>> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
>>>> +	sysc_write(ddata, offset, val);
>>>> +
>>>> +	/* Poll on reset status */
>>>> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
>>>> +		offset = ddata->offsets[SYSC_SYSSTATUS];
>>>> +
>>>> +		return readl_poll_timeout(ddata->module_va + offset, val,
>>>> +				(val & ddata->cfg.syss_mask) == 0x0,
>>>> +				100, MAX_MODULE_SOFTRESET_WAIT);
>>>> +	}
>>>> +
>>>> +	return 0;
>>>> +}
>>>
>>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
>>> addition to SYSC_QUIRK_RESET status to make it easy to
>>> read the right register?
>>
>> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
>> the register. Are there layouts in which the reset status bit is in the
>> sysconfig register rather than the sysstatus register?
> 
> Yes we can have reset status bit in either syss or syssconfig register.

You mean sysstatus and sysconfig right?

> We detect that in sysc_init_syss_mask() but we should also set something
> at that point to make it clear which reset to use. But as we don't need
> the quirk flag, it's probably set a function pointer after the detection.
> So how about let's have two functions sysc_reset() and sysc_syss_reset()
> and then we can implement sysc_syss_reset() in a separate patch after
> testing it when we have a non-platform data using example for
> sysc_syss_reset().
> 

Shouldn't the function I add be called sysc_syss_reset()? The reset
status bit is in the sysstatus.

Thanks,
Faiz

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi Tony,

On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
>> Hi,
>>
>> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
>>> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
>>>> +static int sysc_reset(struct sysc *ddata)
>>>> +{
>>>> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
>>>> +	int val = sysc_read(ddata, offset);
>>>> +
>>>> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
>>>> +	sysc_write(ddata, offset, val);
>>>> +
>>>> +	/* Poll on reset status */
>>>> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
>>>> +		offset = ddata->offsets[SYSC_SYSSTATUS];
>>>> +
>>>> +		return readl_poll_timeout(ddata->module_va + offset, val,
>>>> +				(val & ddata->cfg.syss_mask) == 0x0,
>>>> +				100, MAX_MODULE_SOFTRESET_WAIT);
>>>> +	}
>>>> +
>>>> +	return 0;
>>>> +}
>>>
>>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
>>> addition to SYSC_QUIRK_RESET status to make it easy to
>>> read the right register?
>>
>> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
>> the register. Are there layouts in which the reset status bit is in the
>> sysconfig register rather than the sysstatus register?
> 
> Yes we can have reset status bit in either syss or syssconfig register.

You mean sysstatus and sysconfig right?

> We detect that in sysc_init_syss_mask() but we should also set something
> at that point to make it clear which reset to use. But as we don't need
> the quirk flag, it's probably set a function pointer after the detection.
> So how about let's have two functions sysc_reset() and sysc_syss_reset()
> and then we can implement sysc_syss_reset() in a separate patch after
> testing it when we have a non-platform data using example for
> sysc_syss_reset().
> 

Shouldn't the function I add be called sysc_syss_reset()? The reset
status bit is in the sysstatus.

Thanks,
Faiz

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180611 06:09]:
> Hi Tony,
> 
> On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
> > * Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
> >> Hi,
> >>
> >> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
> >>> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
> >>>> +static int sysc_reset(struct sysc *ddata)
> >>>> +{
> >>>> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
> >>>> +	int val = sysc_read(ddata, offset);
> >>>> +
> >>>> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
> >>>> +	sysc_write(ddata, offset, val);
> >>>> +
> >>>> +	/* Poll on reset status */
> >>>> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
> >>>> +		offset = ddata->offsets[SYSC_SYSSTATUS];
> >>>> +
> >>>> +		return readl_poll_timeout(ddata->module_va + offset, val,
> >>>> +				(val & ddata->cfg.syss_mask) == 0x0,
> >>>> +				100, MAX_MODULE_SOFTRESET_WAIT);
> >>>> +	}
> >>>> +
> >>>> +	return 0;
> >>>> +}
> >>>
> >>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
> >>> addition to SYSC_QUIRK_RESET status to make it easy to
> >>> read the right register?
> >>
> >> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
> >> the register. Are there layouts in which the reset status bit is in the
> >> sysconfig register rather than the sysstatus register?
> > 
> > Yes we can have reset status bit in either syss or syssconfig register.
> 
> You mean sysstatus and sysconfig right?

Yup.

> > We detect that in sysc_init_syss_mask() but we should also set something
> > at that point to make it clear which reset to use. But as we don't need
> > the quirk flag, it's probably set a function pointer after the detection.
> > So how about let's have two functions sysc_reset() and sysc_syss_reset()
> > and then we can implement sysc_syss_reset() in a separate patch after
> > testing it when we have a non-platform data using example for
> > sysc_syss_reset().
> > 
> 
> Shouldn't the function I add be called sysc_syss_reset()? The reset
> status bit is in the sysstatus.

Yes

Tony

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180611 06:09]:
> Hi Tony,
> 
> On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
> > * Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
> >> Hi,
> >>
> >> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
> >>> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
> >>>> +static int sysc_reset(struct sysc *ddata)
> >>>> +{
> >>>> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
> >>>> +	int val = sysc_read(ddata, offset);
> >>>> +
> >>>> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
> >>>> +	sysc_write(ddata, offset, val);
> >>>> +
> >>>> +	/* Poll on reset status */
> >>>> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
> >>>> +		offset = ddata->offsets[SYSC_SYSSTATUS];
> >>>> +
> >>>> +		return readl_poll_timeout(ddata->module_va + offset, val,
> >>>> +				(val & ddata->cfg.syss_mask) == 0x0,
> >>>> +				100, MAX_MODULE_SOFTRESET_WAIT);
> >>>> +	}
> >>>> +
> >>>> +	return 0;
> >>>> +}
> >>>
> >>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
> >>> addition to SYSC_QUIRK_RESET status to make it easy to
> >>> read the right register?
> >>
> >> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
> >> the register. Are there layouts in which the reset status bit is in the
> >> sysconfig register rather than the sysstatus register?
> > 
> > Yes we can have reset status bit in either syss or syssconfig register.
> 
> You mean sysstatus and sysconfig right?

Yup.

> > We detect that in sysc_init_syss_mask() but we should also set something
> > at that point to make it clear which reset to use. But as we don't need
> > the quirk flag, it's probably set a function pointer after the detection.
> > So how about let's have two functions sysc_reset() and sysc_syss_reset()
> > and then we can implement sysc_syss_reset() in a separate patch after
> > testing it when we have a non-platform data using example for
> > sysc_syss_reset().
> > 
> 
> Shouldn't the function I add be called sysc_syss_reset()? The reset
> status bit is in the sysstatus.

Yes

Tony

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

On Monday 11 June 2018 11:39 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:09]:
>> Hi Tony,
>>
>> On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
>>> * Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
>>>> Hi,
>>>>
>>>> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
>>>>> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
>>>>>> +static int sysc_reset(struct sysc *ddata)
>>>>>> +{
>>>>>> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
>>>>>> +	int val = sysc_read(ddata, offset);
>>>>>> +
>>>>>> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
>>>>>> +	sysc_write(ddata, offset, val);
>>>>>> +
>>>>>> +	/* Poll on reset status */
>>>>>> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
>>>>>> +		offset = ddata->offsets[SYSC_SYSSTATUS];
>>>>>> +
>>>>>> +		return readl_poll_timeout(ddata->module_va + offset, val,
>>>>>> +				(val & ddata->cfg.syss_mask) == 0x0,
>>>>>> +				100, MAX_MODULE_SOFTRESET_WAIT);
>>>>>> +	}
>>>>>> +
>>>>>> +	return 0;
>>>>>> +}
>>>>>
>>>>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
>>>>> addition to SYSC_QUIRK_RESET status to make it easy to
>>>>> read the right register?
>>>>
>>>> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
>>>> the register. Are there layouts in which the reset status bit is in the
>>>> sysconfig register rather than the sysstatus register?
>>>
>>> Yes we can have reset status bit in either syss or syssconfig register.
>>
>> You mean sysstatus and sysconfig right?
> 
> Yup.
> 
>>> We detect that in sysc_init_syss_mask() but we should also set something
>>> at that point to make it clear which reset to use. But as we don't need
>>> the quirk flag, it's probably set a function pointer after the detection.
>>> So how about let's have two functions sysc_reset() and sysc_syss_reset()
>>> and then we can implement sysc_syss_reset() in a separate patch after
>>> testing it when we have a non-platform data using example for
>>> sysc_syss_reset().
>>>
>>
>> Shouldn't the function I add be called sysc_syss_reset()? The reset
>> status bit is in the sysstatus.
> 
> Yes
> 

Great. I thought I completely misunderstood you. But I don't see what
adding another function will accomplish. A QUIRK flag used in the same
function would work well enough.

Regards,
Faiz

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

On Monday 11 June 2018 11:39 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:09]:
>> Hi Tony,
>>
>> On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
>>> * Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
>>>> Hi,
>>>>
>>>> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
>>>>> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
>>>>>> +static int sysc_reset(struct sysc *ddata)
>>>>>> +{
>>>>>> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
>>>>>> +	int val = sysc_read(ddata, offset);
>>>>>> +
>>>>>> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
>>>>>> +	sysc_write(ddata, offset, val);
>>>>>> +
>>>>>> +	/* Poll on reset status */
>>>>>> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
>>>>>> +		offset = ddata->offsets[SYSC_SYSSTATUS];
>>>>>> +
>>>>>> +		return readl_poll_timeout(ddata->module_va + offset, val,
>>>>>> +				(val & ddata->cfg.syss_mask) == 0x0,
>>>>>> +				100, MAX_MODULE_SOFTRESET_WAIT);
>>>>>> +	}
>>>>>> +
>>>>>> +	return 0;
>>>>>> +}
>>>>>
>>>>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
>>>>> addition to SYSC_QUIRK_RESET status to make it easy to
>>>>> read the right register?
>>>>
>>>> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
>>>> the register. Are there layouts in which the reset status bit is in the
>>>> sysconfig register rather than the sysstatus register?
>>>
>>> Yes we can have reset status bit in either syss or syssconfig register.
>>
>> You mean sysstatus and sysconfig right?
> 
> Yup.
> 
>>> We detect that in sysc_init_syss_mask() but we should also set something
>>> at that point to make it clear which reset to use. But as we don't need
>>> the quirk flag, it's probably set a function pointer after the detection.
>>> So how about let's have two functions sysc_reset() and sysc_syss_reset()
>>> and then we can implement sysc_syss_reset() in a separate patch after
>>> testing it when we have a non-platform data using example for
>>> sysc_syss_reset().
>>>
>>
>> Shouldn't the function I add be called sysc_syss_reset()? The reset
>> status bit is in the sysstatus.
> 
> Yes
> 

Great. I thought I completely misunderstood you. But I don't see what
adding another function will accomplish. A QUIRK flag used in the same
function would work well enough.

Regards,
Faiz

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

On Monday 11 June 2018 11:39 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:09]:
>> Hi Tony,
>>
>> On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
>>> * Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
>>>> Hi,
>>>>
>>>> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
>>>>> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
>>>>>> +static int sysc_reset(struct sysc *ddata)
>>>>>> +{
>>>>>> +	int offset = ddata->offsets[SYSC_SYSCONFIG];
>>>>>> +	int val = sysc_read(ddata, offset);
>>>>>> +
>>>>>> +	val |= (0x1 << ddata->cap->regbits->srst_shift);
>>>>>> +	sysc_write(ddata, offset, val);
>>>>>> +
>>>>>> +	/* Poll on reset status */
>>>>>> +	if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
>>>>>> +		offset = ddata->offsets[SYSC_SYSSTATUS];
>>>>>> +
>>>>>> +		return readl_poll_timeout(ddata->module_va + offset, val,
>>>>>> +				(val & ddata->cfg.syss_mask) == 0x0,
>>>>>> +				100, MAX_MODULE_SOFTRESET_WAIT);
>>>>>> +	}
>>>>>> +
>>>>>> +	return 0;
>>>>>> +}
>>>>>
>>>>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
>>>>> addition to SYSC_QUIRK_RESET status to make it easy to
>>>>> read the right register?
>>>>
>>>> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
>>>> the register. Are there layouts in which the reset status bit is in the
>>>> sysconfig register rather than the sysstatus register?
>>>
>>> Yes we can have reset status bit in either syss or syssconfig register.
>>
>> You mean sysstatus and sysconfig right?
> 
> Yup.
> 
>>> We detect that in sysc_init_syss_mask() but we should also set something
>>> at that point to make it clear which reset to use. But as we don't need
>>> the quirk flag, it's probably set a function pointer after the detection.
>>> So how about let's have two functions sysc_reset() and sysc_syss_reset()
>>> and then we can implement sysc_syss_reset() in a separate patch after
>>> testing it when we have a non-platform data using example for
>>> sysc_syss_reset().
>>>
>>
>> Shouldn't the function I add be called sysc_syss_reset()? The reset
>> status bit is in the sysstatus.
> 
> Yes
> 

Great. I thought I completely misunderstood you. But I don't see what
adding another function will accomplish. A QUIRK flag used in the same
function would work well enough.

Regards,
Faiz

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
> Great. I thought I completely misunderstood you. But I don't see what
> adding another function will accomplish. A QUIRK flag used in the same
> function would work well enough.

Fine with me as long as the function stays simple for both
syss and sysc reset.

Regards,

Tony

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
> Great. I thought I completely misunderstood you. But I don't see what
> adding another function will accomplish. A QUIRK flag used in the same
> function would work well enough.

Fine with me as long as the function stays simple for both
syss and sysc reset.

Regards,

Tony

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
>> Great. I thought I completely misunderstood you. But I don't see what
>> adding another function will accomplish. A QUIRK flag used in the same
>> function would work well enough>
> Fine with me as long as the function stays simple for both
> syss and sysc reset.
>


In general a reset status bit being in sysstatus is the norm and it
being in sysconfig should be the "quirk" for which a flag needs to be
added. What do you think?

As an aside, naming bitshifts by the name of the platform they were
originally added in seems weird. There should be some generic mask
saying "soft reset is the 0th bit". Currently I am using
SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
different sysconfig types we have.

Thanks,
Faiz

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
>> Great. I thought I completely misunderstood you. But I don't see what
>> adding another function will accomplish. A QUIRK flag used in the same
>> function would work well enough>
> Fine with me as long as the function stays simple for both
> syss and sysc reset.
>


In general a reset status bit being in sysstatus is the norm and it
being in sysconfig should be the "quirk" for which a flag needs to be
added. What do you think?

As an aside, naming bitshifts by the name of the platform they were
originally added in seems weird. There should be some generic mask
saying "soft reset is the 0th bit". Currently I am using
SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
different sysconfig types we have.

Thanks,
Faiz

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
>> Great. I thought I completely misunderstood you. But I don't see what
>> adding another function will accomplish. A QUIRK flag used in the same
>> function would work well enough>
> Fine with me as long as the function stays simple for both
> syss and sysc reset.
>


In general a reset status bit being in sysstatus is the norm and it
being in sysconfig should be the "quirk" for which a flag needs to be
added. What do you think?

As an aside, naming bitshifts by the name of the platform they were
originally added in seems weird. There should be some generic mask
saying "soft reset is the 0th bit". Currently I am using
SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
different sysconfig types we have.

Thanks,
Faiz

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180611 06:48]:
> Hi,
> 
> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> > * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
> >> Great. I thought I completely misunderstood you. But I don't see what
> >> adding another function will accomplish. A QUIRK flag used in the same
> >> function would work well enough>
> > Fine with me as long as the function stays simple for both
> > syss and sysc reset.
> >
> 
> 
> In general a reset status bit being in sysstatus is the norm and it
> being in sysconfig should be the "quirk" for which a flag needs to be
> added. What do you think?

Sure makes sense to me.

> As an aside, naming bitshifts by the name of the platform they were
> originally added in seems weird. There should be some generic mask
> saying "soft reset is the 0th bit". Currently I am using
> SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
> different sysconfig types we have.

Sure we could have a macro for that.

Regards,

Tony

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180611 06:48]:
> Hi,
> 
> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> > * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
> >> Great. I thought I completely misunderstood you. But I don't see what
> >> adding another function will accomplish. A QUIRK flag used in the same
> >> function would work well enough>
> > Fine with me as long as the function stays simple for both
> > syss and sysc reset.
> >
> 
> 
> In general a reset status bit being in sysstatus is the norm and it
> being in sysconfig should be the "quirk" for which a flag needs to be
> added. What do you think?

Sure makes sense to me.

> As an aside, naming bitshifts by the name of the platform they were
> originally added in seems weird. There should be some generic mask
> saying "soft reset is the 0th bit". Currently I am using
> SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
> different sysconfig types we have.

Sure we could have a macro for that.

Regards,

Tony

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [180611 07:06]:
> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:48]:
> > Hi,
> > 
> > On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> > > * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
> > >> Great. I thought I completely misunderstood you. But I don't see what
> > >> adding another function will accomplish. A QUIRK flag used in the same
> > >> function would work well enough>
> > > Fine with me as long as the function stays simple for both
> > > syss and sysc reset.
> > >
> > 
> > 
> > In general a reset status bit being in sysstatus is the norm and it
> > being in sysconfig should be the "quirk" for which a flag needs to be
> > added. What do you think?
> 
> Sure makes sense to me.
> 
> > As an aside, naming bitshifts by the name of the platform they were
> > originally added in seems weird. There should be some generic mask
> > saying "soft reset is the 0th bit". Currently I am using
> > SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
> > different sysconfig types we have.
> 
> Sure we could have a macro for that.

So what's the conclusion on this one? Are you going to do one
more version of the ti-sysc driver patch?

Regards,

Tony

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [180611 07:06]:
> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:48]:
> > Hi,
> > 
> > On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> > > * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
> > >> Great. I thought I completely misunderstood you. But I don't see what
> > >> adding another function will accomplish. A QUIRK flag used in the same
> > >> function would work well enough>
> > > Fine with me as long as the function stays simple for both
> > > syss and sysc reset.
> > >
> > 
> > 
> > In general a reset status bit being in sysstatus is the norm and it
> > being in sysconfig should be the "quirk" for which a flag needs to be
> > added. What do you think?
> 
> Sure makes sense to me.
> 
> > As an aside, naming bitshifts by the name of the platform they were
> > originally added in seems weird. There should be some generic mask
> > saying "soft reset is the 0th bit". Currently I am using
> > SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
> > different sysconfig types we have.
> 
> Sure we could have a macro for that.

So what's the conclusion on this one? Are you going to do one
more version of the ti-sysc driver patch?

Regards,

Tony

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [180611 07:06]:
>> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:48]:
>>> Hi,
>>>
>>> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
>>>> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
>>>>> Great. I thought I completely misunderstood you. But I don't see what
>>>>> adding another function will accomplish. A QUIRK flag used in the same
>>>>> function would work well enough>
>>>> Fine with me as long as the function stays simple for both
>>>> syss and sysc reset.
>>>>
>>>
>>>
>>> In general a reset status bit being in sysstatus is the norm and it
>>> being in sysconfig should be the "quirk" for which a flag needs to be
>>> added. What do you think?
>>
>> Sure makes sense to me.
>>
>>> As an aside, naming bitshifts by the name of the platform they were
>>> originally added in seems weird. There should be some generic mask
>>> saying "soft reset is the 0th bit". Currently I am using
>>> SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
>>> different sysconfig types we have.
>>
>> Sure we could have a macro for that.
> 
> So what's the conclusion on this one? Are you going to do one
> more version of the ti-sysc driver patch?
> 

Yes. I have just now been able to get back to this. Will post a v4 by
tomorrow.

Thanks,
Faiz

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [180611 07:06]:
>> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:48]:
>>> Hi,
>>>
>>> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
>>>> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
>>>>> Great. I thought I completely misunderstood you. But I don't see what
>>>>> adding another function will accomplish. A QUIRK flag used in the same
>>>>> function would work well enough>
>>>> Fine with me as long as the function stays simple for both
>>>> syss and sysc reset.
>>>>
>>>
>>>
>>> In general a reset status bit being in sysstatus is the norm and it
>>> being in sysconfig should be the "quirk" for which a flag needs to be
>>> added. What do you think?
>>
>> Sure makes sense to me.
>>
>>> As an aside, naming bitshifts by the name of the platform they were
>>> originally added in seems weird. There should be some generic mask
>>> saying "soft reset is the 0th bit". Currently I am using
>>> SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
>>> different sysconfig types we have.
>>
>> Sure we could have a macro for that.
> 
> So what's the conclusion on this one? Are you going to do one
> more version of the ti-sysc driver patch?
> 

Yes. I have just now been able to get back to this. Will post a v4 by
tomorrow.

Thanks,
Faiz

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [180611 07:06]:
>> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:48]:
>>> Hi,
>>>
>>> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
>>>> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
>>>>> Great. I thought I completely misunderstood you. But I don't see what
>>>>> adding another function will accomplish. A QUIRK flag used in the same
>>>>> function would work well enough>
>>>> Fine with me as long as the function stays simple for both
>>>> syss and sysc reset.
>>>>
>>>
>>>
>>> In general a reset status bit being in sysstatus is the norm and it
>>> being in sysconfig should be the "quirk" for which a flag needs to be
>>> added. What do you think?
>>
>> Sure makes sense to me.
>>
>>> As an aside, naming bitshifts by the name of the platform they were
>>> originally added in seems weird. There should be some generic mask
>>> saying "soft reset is the 0th bit". Currently I am using
>>> SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
>>> different sysconfig types we have.
>>
>> Sure we could have a macro for that.
> 
> So what's the conclusion on this one? Are you going to do one
> more version of the ti-sysc driver patch?
> 

Yes. I have just now been able to get back to this. Will post a v4 by
tomorrow.

Thanks,
Faiz

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180703 07:31]:
> Hi,
> 
> On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [180611 07:06]:
> >> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:48]:
> >>> Hi,
> >>>
> >>> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> >>>> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
> >>>>> Great. I thought I completely misunderstood you. But I don't see what
> >>>>> adding another function will accomplish. A QUIRK flag used in the same
> >>>>> function would work well enough>
> >>>> Fine with me as long as the function stays simple for both
> >>>> syss and sysc reset.
> >>>>
> >>>
> >>>
> >>> In general a reset status bit being in sysstatus is the norm and it
> >>> being in sysconfig should be the "quirk" for which a flag needs to be
> >>> added. What do you think?
> >>
> >> Sure makes sense to me.
> >>
> >>> As an aside, naming bitshifts by the name of the platform they were
> >>> originally added in seems weird. There should be some generic mask
> >>> saying "soft reset is the 0th bit". Currently I am using
> >>> SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
> >>> different sysconfig types we have.
> >>
> >> Sure we could have a macro for that.
> > 
> > So what's the conclusion on this one? Are you going to do one
> > more version of the ti-sysc driver patch?
> > 
> 
> Yes. I have just now been able to get back to this. Will post a v4 by
> tomorrow.

OK thanks!

Tony

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180703 07:31]:
> Hi,
> 
> On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [180611 07:06]:
> >> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:48]:
> >>> Hi,
> >>>
> >>> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> >>>> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
> >>>>> Great. I thought I completely misunderstood you. But I don't see what
> >>>>> adding another function will accomplish. A QUIRK flag used in the same
> >>>>> function would work well enough>
> >>>> Fine with me as long as the function stays simple for both
> >>>> syss and sysc reset.
> >>>>
> >>>
> >>>
> >>> In general a reset status bit being in sysstatus is the norm and it
> >>> being in sysconfig should be the "quirk" for which a flag needs to be
> >>> added. What do you think?
> >>
> >> Sure makes sense to me.
> >>
> >>> As an aside, naming bitshifts by the name of the platform they were
> >>> originally added in seems weird. There should be some generic mask
> >>> saying "soft reset is the 0th bit". Currently I am using
> >>> SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
> >>> different sysconfig types we have.
> >>
> >> Sure we could have a macro for that.
> > 
> > So what's the conclusion on this one? Are you going to do one
> > more version of the ti-sysc driver patch?
> > 
> 
> Yes. I have just now been able to get back to this. Will post a v4 by
> tomorrow.

OK thanks!

Tony

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Tuesday 03 July 2018 01:01 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180703 07:31]:
>> Hi,
>>
>> On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote:
>>> * Tony Lindgren <tony@atomide.com> [180611 07:06]:
>>>> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:48]:
>>>>> Hi,
>>>>>
>>>>> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
>>>>>> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
>>>>>>> Great. I thought I completely misunderstood you. But I don't see what
>>>>>>> adding another function will accomplish. A QUIRK flag used in the same
>>>>>>> function would work well enough>
>>>>>> Fine with me as long as the function stays simple for both
>>>>>> syss and sysc reset.
>>>>>>
>>>>>
>>>>>
>>>>> In general a reset status bit being in sysstatus is the norm and it
>>>>> being in sysconfig should be the "quirk" for which a flag needs to be
>>>>> added. What do you think?
>>>>
>>>> Sure makes sense to me.
>>>>
>>>>> As an aside, naming bitshifts by the name of the platform they were
>>>>> originally added in seems weird. There should be some generic mask
>>>>> saying "soft reset is the 0th bit". Currently I am using
>>>>> SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
>>>>> different sysconfig types we have.
>>>>
>>>> Sure we could have a macro for that.
>>>
>>> So what's the conclusion on this one? Are you going to do one
>>> more version of the ti-sysc driver patch?
>>>
>>
>> Yes. I have just now been able to get back to this. Will post a v4 by
>> tomorrow.
> 
> OK thanks!
> 

After taking a second look at this thread, I don't see anything big to
be modified.

We both agree that "reset status bit in sysconfig register" is the quirk
case which can be added once such an IP is discovered in ti-sysc.

All I need to change is SYSC_OMAP4_SOFTRESET to SYSC_SOFT_RESET_SHIFT_0
for better readability and rebase it to the latest mainline.

Do reply if you differ on the above.

Thanks,
Faiz

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Tuesday 03 July 2018 01:01 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180703 07:31]:
>> Hi,
>>
>> On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote:
>>> * Tony Lindgren <tony@atomide.com> [180611 07:06]:
>>>> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:48]:
>>>>> Hi,
>>>>>
>>>>> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
>>>>>> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
>>>>>>> Great. I thought I completely misunderstood you. But I don't see what
>>>>>>> adding another function will accomplish. A QUIRK flag used in the same
>>>>>>> function would work well enough>
>>>>>> Fine with me as long as the function stays simple for both
>>>>>> syss and sysc reset.
>>>>>>
>>>>>
>>>>>
>>>>> In general a reset status bit being in sysstatus is the norm and it
>>>>> being in sysconfig should be the "quirk" for which a flag needs to be
>>>>> added. What do you think?
>>>>
>>>> Sure makes sense to me.
>>>>
>>>>> As an aside, naming bitshifts by the name of the platform they were
>>>>> originally added in seems weird. There should be some generic mask
>>>>> saying "soft reset is the 0th bit". Currently I am using
>>>>> SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
>>>>> different sysconfig types we have.
>>>>
>>>> Sure we could have a macro for that.
>>>
>>> So what's the conclusion on this one? Are you going to do one
>>> more version of the ti-sysc driver patch?
>>>
>>
>> Yes. I have just now been able to get back to this. Will post a v4 by
>> tomorrow.
> 
> OK thanks!
> 

After taking a second look at this thread, I don't see anything big to
be modified.

We both agree that "reset status bit in sysconfig register" is the quirk
case which can be added once such an IP is discovered in ti-sysc.

All I need to change is SYSC_OMAP4_SOFTRESET to SYSC_SOFT_RESET_SHIFT_0
for better readability and rebase it to the latest mainline.

Do reply if you differ on the above.

Thanks,
Faiz

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Tuesday 03 July 2018 01:01 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180703 07:31]:
>> Hi,
>>
>> On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote:
>>> * Tony Lindgren <tony@atomide.com> [180611 07:06]:
>>>> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:48]:
>>>>> Hi,
>>>>>
>>>>> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
>>>>>> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
>>>>>>> Great. I thought I completely misunderstood you. But I don't see what
>>>>>>> adding another function will accomplish. A QUIRK flag used in the same
>>>>>>> function would work well enough>
>>>>>> Fine with me as long as the function stays simple for both
>>>>>> syss and sysc reset.
>>>>>>
>>>>>
>>>>>
>>>>> In general a reset status bit being in sysstatus is the norm and it
>>>>> being in sysconfig should be the "quirk" for which a flag needs to be
>>>>> added. What do you think?
>>>>
>>>> Sure makes sense to me.
>>>>
>>>>> As an aside, naming bitshifts by the name of the platform they were
>>>>> originally added in seems weird. There should be some generic mask
>>>>> saying "soft reset is the 0th bit". Currently I am using
>>>>> SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
>>>>> different sysconfig types we have.
>>>>
>>>> Sure we could have a macro for that.
>>>
>>> So what's the conclusion on this one? Are you going to do one
>>> more version of the ti-sysc driver patch?
>>>
>>
>> Yes. I have just now been able to get back to this. Will post a v4 by
>> tomorrow.
> 
> OK thanks!
> 

After taking a second look at this thread, I don't see anything big to
be modified.

We both agree that "reset status bit in sysconfig register" is the quirk
case which can be added once such an IP is discovered in ti-sysc.

All I need to change is SYSC_OMAP4_SOFTRESET to SYSC_SOFT_RESET_SHIFT_0
for better readability and rebase it to the latest mainline.

Do reply if you differ on the above.

Thanks,
Faiz

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180704 13:37]:
> After taking a second look at this thread, I don't see anything big to
> be modified.
> 
> We both agree that "reset status bit in sysconfig register" is the quirk
> case which can be added once such an IP is discovered in ti-sysc.

Yes agreed.

> All I need to change is SYSC_OMAP4_SOFTRESET to SYSC_SOFT_RESET_SHIFT_0
> for better readability and rebase it to the latest mainline.

Let's not change SYSC_OMAP4_SOFTRESET as only the ti-sysc
driver needs to know that and it can be set based on the
compatible.

How about replace ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS
test with just ddata->cfg.syss_mask test in your sysc_reset()?

We still need to set SYSC_QUIRK_RESET_STATUS too for pdata
callbacks.

Regards,

Tony

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180704 13:37]:
> After taking a second look at this thread, I don't see anything big to
> be modified.
> 
> We both agree that "reset status bit in sysconfig register" is the quirk
> case which can be added once such an IP is discovered in ti-sysc.

Yes agreed.

> All I need to change is SYSC_OMAP4_SOFTRESET to SYSC_SOFT_RESET_SHIFT_0
> for better readability and rebase it to the latest mainline.

Let's not change SYSC_OMAP4_SOFTRESET as only the ti-sysc
driver needs to know that and it can be set based on the
compatible.

How about replace ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS
test with just ddata->cfg.syss_mask test in your sysc_reset()?

We still need to set SYSC_QUIRK_RESET_STATUS too for pdata
callbacks.

Regards,

Tony

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Thursday 05 July 2018 11:25 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180704 13:37]:
>> After taking a second look at this thread, I don't see anything big to
>> be modified.
>>
>> We both agree that "reset status bit in sysconfig register" is the quirk
>> case which can be added once such an IP is discovered in ti-sysc.
> 
> Yes agreed.
> 
>> All I need to change is SYSC_OMAP4_SOFTRESET to SYSC_SOFT_RESET_SHIFT_0
>> for better readability and rebase it to the latest mainline.
> 
> Let's not change SYSC_OMAP4_SOFTRESET as only the ti-sysc
> driver needs to know that and it can be set based on the
> compatible.

Ok.
> 
> How about replace ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS
> test with just ddata->cfg.syss_mask test in your sysc_reset()?
> 
> We still need to set SYSC_QUIRK_RESET_STATUS too for pdata
> callbacks.

Sure. Do reset in ti-sysc only if dt has the correct syss_mask.

Rebasing and posting v4 soon.

Thanks,
Faiz

[PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Thursday 05 July 2018 11:25 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180704 13:37]:
>> After taking a second look at this thread, I don't see anything big to
>> be modified.
>>
>> We both agree that "reset status bit in sysconfig register" is the quirk
>> case which can be added once such an IP is discovered in ti-sysc.
> 
> Yes agreed.
> 
>> All I need to change is SYSC_OMAP4_SOFTRESET to SYSC_SOFT_RESET_SHIFT_0
>> for better readability and rebase it to the latest mainline.
> 
> Let's not change SYSC_OMAP4_SOFTRESET as only the ti-sysc
> driver needs to know that and it can be set based on the
> compatible.

Ok.
> 
> How about replace ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS
> test with just ddata->cfg.syss_mask test in your sysc_reset()?
> 
> We still need to set SYSC_QUIRK_RESET_STATUS too for pdata
> callbacks.

Sure. Do reset in ti-sysc only if dt has the correct syss_mask.

Rebasing and posting v4 soon.

Thanks,
Faiz

Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset

[Faiz Abbas]

Hi,

On Thursday 05 July 2018 11:25 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180704 13:37]:
>> After taking a second look at this thread, I don't see anything big to
>> be modified.
>>
>> We both agree that "reset status bit in sysconfig register" is the quirk
>> case which can be added once such an IP is discovered in ti-sysc.
> 
> Yes agreed.
> 
>> All I need to change is SYSC_OMAP4_SOFTRESET to SYSC_SOFT_RESET_SHIFT_0
>> for better readability and rebase it to the latest mainline.
> 
> Let's not change SYSC_OMAP4_SOFTRESET as only the ti-sysc
> driver needs to know that and it can be set based on the
> compatible.

Ok.
> 
> How about replace ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS
> test with just ddata->cfg.syss_mask test in your sysc_reset()?
> 
> We still need to set SYSC_QUIRK_RESET_STATUS too for pdata
> callbacks.

Sure. Do reset in ti-sysc only if dt has the correct syss_mask.

Rebasing and posting v4 soon.

Thanks,
Faiz

[PATCH v3 5/6] ARM: dts: Add generic interconnect target module node for MCAN

[Faiz Abbas]

The ti-sysc driver provides support for manipulating the idle modes
and interconnect level resets.

Add the generic interconnect target module node for MCAN to support
the same.

CC: Tony Lindgren <tony@atomide.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 arch/arm/boot/dts/dra76x.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index bfc82636999c..5157cc431574 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -11,6 +11,24 @@
 / {
 	compatible = "ti,dra762", "ti,dra7";
 
+	ocp {
+		target-module@42c01900 {
+			compatible = "ti,sysc-dra7-mcan", "ti,sysc";
+			ranges = <0x0 0x42c00000 0x2000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0x42c01900 0x4>,
+			      <0x42c01904 0x4>,
+			      <0x42c01908 0x4>;
+			reg-names = "rev", "sysc", "syss";
+			ti,sysc-mask = <(SYSC_OMAP4_SOFTRESET |
+					 SYSC_DRA7_MCAN_ENAWAKEUP)>;
+			ti,syss-mask = <1>;
+			clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
+			clock-names = "fck";
+		};
+	};
+
 };
 
 /* MCAN interrupts are hard-wired to irqs 67, 68 */
-- 
2.17.0

[PATCH v3 5/6] ARM: dts: Add generic interconnect target module node for MCAN

[Faiz Abbas]

The ti-sysc driver provides support for manipulating the idle modes
and interconnect level resets.

Add the generic interconnect target module node for MCAN to support
the same.

CC: Tony Lindgren <tony@atomide.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 arch/arm/boot/dts/dra76x.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index bfc82636999c..5157cc431574 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -11,6 +11,24 @@
 / {
 	compatible = "ti,dra762", "ti,dra7";
 
+	ocp {
+		target-module at 42c01900 {
+			compatible = "ti,sysc-dra7-mcan", "ti,sysc";
+			ranges = <0x0 0x42c00000 0x2000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0x42c01900 0x4>,
+			      <0x42c01904 0x4>,
+			      <0x42c01908 0x4>;
+			reg-names = "rev", "sysc", "syss";
+			ti,sysc-mask = <(SYSC_OMAP4_SOFTRESET |
+					 SYSC_DRA7_MCAN_ENAWAKEUP)>;
+			ti,syss-mask = <1>;
+			clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
+			clock-names = "fck";
+		};
+	};
+
 };
 
 /* MCAN interrupts are hard-wired to irqs 67, 68 */
-- 
2.17.0

[PATCH v3 5/6] ARM: dts: Add generic interconnect target module node for MCAN

[Faiz Abbas]

The ti-sysc driver provides support for manipulating the idle modes
and interconnect level resets.

Add the generic interconnect target module node for MCAN to support
the same.

CC: Tony Lindgren <tony@atomide.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 arch/arm/boot/dts/dra76x.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index bfc82636999c..5157cc431574 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -11,6 +11,24 @@
 / {
 	compatible = "ti,dra762", "ti,dra7";
 
+	ocp {
+		target-module@42c01900 {
+			compatible = "ti,sysc-dra7-mcan", "ti,sysc";
+			ranges = <0x0 0x42c00000 0x2000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0x42c01900 0x4>,
+			      <0x42c01904 0x4>,
+			      <0x42c01908 0x4>;
+			reg-names = "rev", "sysc", "syss";
+			ti,sysc-mask = <(SYSC_OMAP4_SOFTRESET |
+					 SYSC_DRA7_MCAN_ENAWAKEUP)>;
+			ti,syss-mask = <1>;
+			clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
+			clock-names = "fck";
+		};
+	};
+
 };
 
 /* MCAN interrupts are hard-wired to irqs 67, 68 */
-- 
2.17.0

[PATCH v3 6/6] ARM: dts: dra76x: Add MCAN node

[Faiz Abbas]

From: Franklin S Cooper Jr <fcooper@ti.com>

Add support for the MCAN peripheral which supports both classic
CAN messages along with the new CAN-FD message.

Add MCAN node to evm and enable it with a maximum datarate of 5 mbps

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 arch/arm/boot/dts/dra76-evm.dts |  6 ++++++
 arch/arm/boot/dts/dra76x.dtsi   | 13 +++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index 2deb96405d06..b6ac2b6ffc6e 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -404,3 +404,9 @@
 	phys = <&pcie1_phy>, <&pcie2_phy>;
 	phy-names = "pcie-phy0", "pcie-phy1";
 };
+
+&m_can0 {
+	can-transceiver {
+		max-bitrate = <5000000>;
+	};
+};
diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index 5157cc431574..613e4dc0ed3e 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -26,6 +26,19 @@
 			ti,syss-mask = <1>;
 			clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
 			clock-names = "fck";
+
+			m_can0: mcan@1a00 {
+				compatible = "bosch,m_can";
+				reg = <0x1a00 0x4000>, <0x0 0x18FC>;
+				reg-names = "m_can", "message_ram";
+				interrupt-parent = <&gic>;
+				interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "int0", "int1";
+				clocks = <&mcan_clk>, <&l3_iclk_div>;
+				clock-names = "cclk", "hclk";
+				bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;
+			};
 		};
 	};
 
-- 
2.17.0

[PATCH v3 6/6] ARM: dts: dra76x: Add MCAN node

[Faiz Abbas]

From: Franklin S Cooper Jr <fcooper@ti.com>

Add support for the MCAN peripheral which supports both classic
CAN messages along with the new CAN-FD message.

Add MCAN node to evm and enable it with a maximum datarate of 5 mbps

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 arch/arm/boot/dts/dra76-evm.dts |  6 ++++++
 arch/arm/boot/dts/dra76x.dtsi   | 13 +++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index 2deb96405d06..b6ac2b6ffc6e 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -404,3 +404,9 @@
 	phys = <&pcie1_phy>, <&pcie2_phy>;
 	phy-names = "pcie-phy0", "pcie-phy1";
 };
+
+&m_can0 {
+	can-transceiver {
+		max-bitrate = <5000000>;
+	};
+};
diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index 5157cc431574..613e4dc0ed3e 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -26,6 +26,19 @@
 			ti,syss-mask = <1>;
 			clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
 			clock-names = "fck";
+
+			m_can0: mcan at 1a00 {
+				compatible = "bosch,m_can";
+				reg = <0x1a00 0x4000>, <0x0 0x18FC>;
+				reg-names = "m_can", "message_ram";
+				interrupt-parent = <&gic>;
+				interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "int0", "int1";
+				clocks = <&mcan_clk>, <&l3_iclk_div>;
+				clock-names = "cclk", "hclk";
+				bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;
+			};
 		};
 	};
 
-- 
2.17.0

[PATCH v3 6/6] ARM: dts: dra76x: Add MCAN node

[Faiz Abbas]

From: Franklin S Cooper Jr <fcooper@ti.com>

Add support for the MCAN peripheral which supports both classic
CAN messages along with the new CAN-FD message.

Add MCAN node to evm and enable it with a maximum datarate of 5 mbps

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
 arch/arm/boot/dts/dra76-evm.dts |  6 ++++++
 arch/arm/boot/dts/dra76x.dtsi   | 13 +++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index 2deb96405d06..b6ac2b6ffc6e 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -404,3 +404,9 @@
 	phys = <&pcie1_phy>, <&pcie2_phy>;
 	phy-names = "pcie-phy0", "pcie-phy1";
 };
+
+&m_can0 {
+	can-transceiver {
+		max-bitrate = <5000000>;
+	};
+};
diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index 5157cc431574..613e4dc0ed3e 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -26,6 +26,19 @@
 			ti,syss-mask = <1>;
 			clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
 			clock-names = "fck";
+
+			m_can0: mcan@1a00 {
+				compatible = "bosch,m_can";
+				reg = <0x1a00 0x4000>, <0x0 0x18FC>;
+				reg-names = "m_can", "message_ram";
+				interrupt-parent = <&gic>;
+				interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-names = "int0", "int1";
+				clocks = <&mcan_clk>, <&l3_iclk_div>;
+				clock-names = "cclk", "hclk";
+				bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;
+			};
 		};
 	};
 
-- 
2.17.0

Re: [PATCH v3 0/6] Add MCAN Support for dra76x

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180606 06:09]:
> The following patches add dts and sysconfig support
> for MCAN on TI's dra76 SOCs
> 
> The patches depend on the following series:
> https://patchwork.kernel.org/patch/10221105/
> 
> Changes in v3:
>  1. Added reset functionality to the ti-sysc
>     driver. This enables me to drop the hwmod
>     data patch as everything is being done in dt.
>
>  2. Dropped ti,hwmods from the dts nodes

Cool good to hear that works :)

>  4. Removed the status="disabled" in dtsi
>     followed by status="okay" in dts.

Hmm okay is the default and is not needed. I did not notice
okay in this set based on a quick glance so maybe you already
dropped it?

Regards,

Tony

[PATCH v3 0/6] Add MCAN Support for dra76x

[Tony Lindgren]

* Faiz Abbas <faiz_abbas@ti.com> [180606 06:09]:
> The following patches add dts and sysconfig support
> for MCAN on TI's dra76 SOCs
> 
> The patches depend on the following series:
> https://patchwork.kernel.org/patch/10221105/
> 
> Changes in v3:
>  1. Added reset functionality to the ti-sysc
>     driver. This enables me to drop the hwmod
>     data patch as everything is being done in dt.
>
>  2. Dropped ti,hwmods from the dts nodes

Cool good to hear that works :)

>  4. Removed the status="disabled" in dtsi
>     followed by status="okay" in dts.

Hmm okay is the default and is not needed. I did not notice
okay in this set based on a quick glance so maybe you already
dropped it?

Regards,

Tony

Re: [PATCH v3 0/6] Add MCAN Support for dra76x

[Faiz Abbas]

Hi,

On Wednesday 06 June 2018 03:39 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:09]:
>> The following patches add dts and sysconfig support
>> for MCAN on TI's dra76 SOCs
>>
>> The patches depend on the following series:
>> https://patchwork.kernel.org/patch/10221105/
>>
>> Changes in v3:
>>  1. Added reset functionality to the ti-sysc
>>     driver. This enables me to drop the hwmod
>>     data patch as everything is being done in dt.
>>
>>  2. Dropped ti,hwmods from the dts nodes
> 
> Cool good to hear that works :)
> 
>>  4. Removed the status="disabled" in dtsi
>>     followed by status="okay" in dts.
> 
> Hmm okay is the default and is not needed. I did not notice
> okay in this set based on a quick glance so maybe you already
> dropped it?

I guess that wasn't clear. I meant to say I have dropped both
status=disabled and status=okay because okay is default.

Thanks,
Faiz

[PATCH v3 0/6] Add MCAN Support for dra76x

[Faiz Abbas]

Hi,

On Wednesday 06 June 2018 03:39 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:09]:
>> The following patches add dts and sysconfig support
>> for MCAN on TI's dra76 SOCs
>>
>> The patches depend on the following series:
>> https://patchwork.kernel.org/patch/10221105/
>>
>> Changes in v3:
>>  1. Added reset functionality to the ti-sysc
>>     driver. This enables me to drop the hwmod
>>     data patch as everything is being done in dt.
>>
>>  2. Dropped ti,hwmods from the dts nodes
> 
> Cool good to hear that works :)
> 
>>  4. Removed the status="disabled" in dtsi
>>     followed by status="okay" in dts.
> 
> Hmm okay is the default and is not needed. I did not notice
> okay in this set based on a quick glance so maybe you already
> dropped it?

I guess that wasn't clear. I meant to say I have dropped both
status=disabled and status=okay because okay is default.

Thanks,
Faiz

Re: [PATCH v3 0/6] Add MCAN Support for dra76x

[Faiz Abbas]

Hi,

On Wednesday 06 June 2018 03:39 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:09]:
>> The following patches add dts and sysconfig support
>> for MCAN on TI's dra76 SOCs
>>
>> The patches depend on the following series:
>> https://patchwork.kernel.org/patch/10221105/
>>
>> Changes in v3:
>>  1. Added reset functionality to the ti-sysc
>>     driver. This enables me to drop the hwmod
>>     data patch as everything is being done in dt.
>>
>>  2. Dropped ti,hwmods from the dts nodes
> 
> Cool good to hear that works :)
> 
>>  4. Removed the status="disabled" in dtsi
>>     followed by status="okay" in dts.
> 
> Hmm okay is the default and is not needed. I did not notice
> okay in this set based on a quick glance so maybe you already
> dropped it?

I guess that wasn't clear. I meant to say I have dropped both
status=disabled and status=okay because okay is default.

Thanks,
Faiz