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
Add clkctrl data for the m_can clocks and register it within the
clkctrl driver
CC: Tero Kristo <[email protected]>
Signed-off-by: Faiz Abbas <[email protected]>
---
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
Add support for the software reset of a target interconnect
module using its sysconfig and sysstatus registers.
Signed-off-by: Faiz Abbas <[email protected]>
---
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
From: Franklin S Cooper Jr <[email protected]>
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 <[email protected]>
---
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
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 <[email protected]>
Signed-off-by: Faiz Abbas <[email protected]>
---
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
From: Lokesh Vutla <[email protected]>
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 <[email protected]>
Signed-off-by: Faiz Abbas <[email protected]>
---
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
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 <[email protected]>
CC: Tony Lindgren <[email protected]>
Signed-off-by: Faiz Abbas <[email protected]>
---
.../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
* Faiz Abbas <[email protected]> [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 <[email protected]> [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
* Faiz Abbas <[email protected]> [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 <[email protected]> [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
* Faiz Abbas <[email protected]> [180607 10:24]:
> Hi,
>
> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
> > * Faiz Abbas <[email protected]> [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
Hi Tony,
On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
> * Faiz Abbas <[email protected]> [180607 10:24]:
>> Hi,
>>
>> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
>>> * Faiz Abbas <[email protected]> [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
* Faiz Abbas <[email protected]> [180611 06:09]:
> Hi Tony,
>
> On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
> > * Faiz Abbas <[email protected]> [180607 10:24]:
> >> Hi,
> >>
> >> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
> >>> * Faiz Abbas <[email protected]> [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
On Monday 11 June 2018 11:39 AM, Tony Lindgren wrote:
> * Faiz Abbas <[email protected]> [180611 06:09]:
>> Hi Tony,
>>
>> On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
>>> * Faiz Abbas <[email protected]> [180607 10:24]:
>>>> Hi,
>>>>
>>>> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
>>>>> * Faiz Abbas <[email protected]> [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
* Faiz Abbas <[email protected]> [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 <[email protected]> [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
* Faiz Abbas <[email protected]> [180611 06:48]:
> Hi,
>
> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> > * Faiz Abbas <[email protected]> [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
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 <[email protected]>
> Signed-off-by: Faiz Abbas <[email protected]>
> ---
> drivers/clk/ti/clk-7xx.c | 1 +
> include/dt-bindings/clock/dra7.h | 1 +
Acked-by: Rob Herring <[email protected]>
> 2 files changed, 2 insertions(+)
>
* Tony Lindgren <[email protected]> [180611 07:06]:
> * Faiz Abbas <[email protected]> [180611 06:48]:
> > Hi,
> >
> > On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> > > * Faiz Abbas <[email protected]> [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
Hi,
On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote:
> * Tony Lindgren <[email protected]> [180611 07:06]:
>> * Faiz Abbas <[email protected]> [180611 06:48]:
>>> Hi,
>>>
>>> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
>>>> * Faiz Abbas <[email protected]> [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
* Faiz Abbas <[email protected]> [180703 07:31]:
> Hi,
>
> On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote:
> > * Tony Lindgren <[email protected]> [180611 07:06]:
> >> * Faiz Abbas <[email protected]> [180611 06:48]:
> >>> Hi,
> >>>
> >>> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> >>>> * Faiz Abbas <[email protected]> [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
Hi,
On Tuesday 03 July 2018 01:01 PM, Tony Lindgren wrote:
> * Faiz Abbas <[email protected]> [180703 07:31]:
>> Hi,
>>
>> On Tuesday 03 July 2018 12:37 PM, Tony Lindgren wrote:
>>> * Tony Lindgren <[email protected]> [180611 07:06]:
>>>> * Faiz Abbas <[email protected]> [180611 06:48]:
>>>>> Hi,
>>>>>
>>>>> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
>>>>>> * Faiz Abbas <[email protected]> [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
* Faiz Abbas <[email protected]> [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 <[email protected]> [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