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

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

From: Lokesh Vutla <redacted>

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 <redacted>
Signed-off-by: Faiz Abbas <redacted>
---
 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

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 <redacted>
---
 .../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

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

CC: Tero Kristo <redacted>
Signed-off-by: Faiz Abbas <redacted>
---
 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

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 <redacted>
Signed-off-by: Faiz Abbas <redacted>
---
 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(+)

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

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

Signed-off-by: Faiz Abbas <redacted>
---
 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

* Faiz Abbas [off-list ref] [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

Hi,

On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:

* Faiz Abbas [off-list ref] [180606 06:14]:

quoted

+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

* Faiz Abbas [off-list ref] [180607 10:24]:

Hi,

On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:

quoted

* Faiz Abbas [off-list ref] [180606 06:14]:

quoted

+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

Hi Tony,

On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:

* Faiz Abbas [off-list ref] [180607 10:24]:

quoted

Hi,

On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:

quoted

* Faiz Abbas [off-list ref] [180606 06:14]:

quoted

+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

* Faiz Abbas [off-list ref] [180611 06:09]:

Hi Tony,

On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:

quoted

* Faiz Abbas [off-list ref] [180607 10:24]:

quoted

Hi,

On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:

quoted

* Faiz Abbas [off-list ref] [180606 06:14]:

quoted

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

quoted

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

On Monday 11 June 2018 11:39 AM, Tony Lindgren wrote:

* Faiz Abbas [off-list ref] [180611 06:09]:

quoted

Hi Tony,

On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:

quoted

* Faiz Abbas [off-list ref] [180607 10:24]:

quoted

Hi,

On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:

quoted

* Faiz Abbas [off-list ref] [180606 06:14]:

quoted

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

quoted

quoted

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

* Faiz Abbas [off-list ref] [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

Hi,

On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:

* Faiz Abbas [off-list ref] [180611 06:28]:

quoted

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

* Faiz Abbas [off-list ref] [180611 06:48]:

Hi,

On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:

quoted

* Faiz Abbas [off-list ref] [180611 06:28]:

quoted

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

* Tony Lindgren [off-list ref] [180611 07:06]:

* Faiz Abbas [off-list ref] [180611 06:48]:

quoted

Hi,

On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:

quoted

* Faiz Abbas [off-list ref] [180611 06:28]:

quoted

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.

quoted

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

Hi,

On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote:

* Tony Lindgren [off-list ref] [180611 07:06]:

quoted

* Faiz Abbas [off-list ref] [180611 06:48]:

quoted

Hi,

On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:

quoted

* Faiz Abbas [off-list ref] [180611 06:28]:

quoted

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.

quoted

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

* Faiz Abbas [off-list ref] [180703 07:31]:

Hi,

On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote:

quoted

* Tony Lindgren [off-list ref] [180611 07:06]:

quoted

* Faiz Abbas [off-list ref] [180611 06:48]:

quoted

Hi,

On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:

quoted

* Faiz Abbas [off-list ref] [180611 06:28]:

quoted

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.

quoted

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

Hi,

On Tuesday 03 July 2018 01:01 PM, Tony Lindgren wrote:

* Faiz Abbas [off-list ref] [180703 07:31]:

quoted

Hi,

On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote:

quoted

* Tony Lindgren [off-list ref] [180611 07:06]:

quoted

* Faiz Abbas [off-list ref] [180611 06:48]:

quoted

Hi,

On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:

quoted

* Faiz Abbas [off-list ref] [180611 06:28]:

quoted

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.

quoted

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

* Faiz Abbas [off-list ref] [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

Hi,

On Thursday 05 July 2018 11:25 AM, Tony Lindgren wrote:

* Faiz Abbas [off-list ref] [180704 13:37]:

quoted

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.

quoted

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

From: Franklin S Cooper Jr <redacted>

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

* Faiz Abbas [off-list ref] [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

Hi,

On Wednesday 06 June 2018 03:39 PM, Tony Lindgren wrote:

* Faiz Abbas [off-list ref] [180606 06:09]:

quoted

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

quoted

 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