| Message ID | 1397497283-16391-3-git-send-email-ivan.khoronzhuk@ti.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Monday 14 April 2014 20:41:20 Ivan Khoronzhuk wrote: > +Optional properties: > + > +- ti,soft-reset: Boolean option indicating soft reset. > + By default hard reset is used. > + > +- ti,wdt_list: WDT list that can cause SoC reset. > + The list in format: <0>, <2>; > + Begins from 0 to 3, as keystone can contain up > + to 4 SoC reset watchdogs. > This looks like your binding just describes a subset of the watchdog timer registers. If so, don't do a standalone reset driver, but instead do a watchdog driver that can also be used for reset, and have a binding that properly describes the watchdog hardware. It is bad to have overlapping register ranges between logical devices, and it's also generally wrong to describe devices that are not actually there: The hardware contains a watchdog, not a system-reset device, so you should not make one up because it seems easier given the Linux driver model. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/14/2014 09:44 PM, Arnd Bergmann wrote: > On Monday 14 April 2014 20:41:20 Ivan Khoronzhuk wrote: >> +Optional properties: >> + >> +- ti,soft-reset: Boolean option indicating soft reset. >> + By default hard reset is used. >> + >> +- ti,wdt_list: WDT list that can cause SoC reset. >> + The list in format: <0>, <2>; >> + Begins from 0 to 3, as keystone can contain up >> + to 4 SoC reset watchdogs. >> > This looks like your binding just describes a subset of the > watchdog timer registers. If so, don't do a standalone reset The registers are not a subset of watchdog hardware it's SoC specific future controlled by SoC specific registers (bootregs and PLL regs). For watchog IP setup, the Keystone uses the watchdog driver common with other SoCs -- davinci_watchdog that is not depend on other SoC settings like this driver does. The Keystone SoCs have separate registers to tune Keystone2 reset functionality by configuring Reset multiplexer & PLL. And it tunes not only watchdog usage. The keystone SoC can be rebooted in several ways. By external reset pin, by soft and by watchdogs. This driver allows software reset or reset by one of the watchdogs (and other settings) independently on watchdog driver settings. This is job of reset driver. > It's > driver, but instead do a watchdog driver that can also be > used for reset, and have a binding that properly describes > the watchdog hardware. > > It is bad to have overlapping register ranges between logical WDT doesn't overlap with this driver. > devices, and it's also generally wrong to describe devices that > are not actually there: The hardware contains a watchdog, not > a system-reset device, so you should not make one up because > it seems easier given the Linux driver model. > > Arnd
On 04/15/2014 02:25 PM, Ivan Khoronzhuk wrote: > > On 04/14/2014 09:44 PM, Arnd Bergmann wrote: >> On Monday 14 April 2014 20:41:20 Ivan Khoronzhuk wrote: >>> +Optional properties: >>> + >>> +- ti,soft-reset: Boolean option indicating soft reset. >>> + By default hard reset is used. >>> + >>> +- ti,wdt_list: WDT list that can cause SoC reset. >>> + The list in format: <0>, <2>; >>> + Begins from 0 to 3, as keystone can contain up >>> + to 4 SoC reset watchdogs. >>> >> This looks like your binding just describes a subset of the >> watchdog timer registers. If so, don't do a standalone reset > > The registers are not a subset of watchdog hardware it's SoC specific > future > controlled by SoC specific registers (bootregs and PLL regs). > > For watchog IP setup, the Keystone uses the watchdog driver common > with other > SoCs -- davinci_watchdog that is not depend on other SoC settings like > this driver does. > > The Keystone SoCs have separate registers to tune Keystone2 reset > functionality > by configuring Reset multiplexer & PLL. And it tunes not only > watchdog usage. > The keystone SoC can be rebooted in several ways. By external reset > pin, by soft and > by watchdogs. This driver allows software reset or reset by one of the > watchdogs > (and other settings) independently on watchdog driver settings. This > is job of reset driver. > >> It's >> driver, but instead do a watchdog driver that can also be >> used for reset, and have a binding that properly describes >> the watchdog hardware. >> >> It is bad to have overlapping register ranges between logical > > WDT doesn't overlap with this driver. > >> devices, and it's also generally wrong to describe devices that >> are not actually there: The hardware contains a watchdog, not >> a system-reset device, so you should not make one up because >> it seems easier given the Linux driver model. >> >> Arnd Hi Arnd, Could I do smth additional to make bindings explanation more clear? Or this is enough? I can write like the following: Optional properties: - ti,soft-reset: Boolean option indicating soft reset. By default hard reset is used. - ti,wdt_list: WDT list that can cause SoC reset. This is not related to WDT driver, it's just needed to enable a SoC related reset that is triggered by one of watchdogs. The list in format: <0>, <2>; Begins from 0 to 3, as keystone can contain up to 4 SoC reset watchdogs. Can be in random order. That is OK?
diff --git a/Documentation/devicetree/bindings/power/reset/keystone-reset.txt b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt new file mode 100644 index 0000000..5ad5883 --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt @@ -0,0 +1,59 @@ +* Device tree bindings for Texas Instruments keystone reset + +This node is intended to allow SoC reset in case of software reset +of selected watchdogs. + +The Keystone SoCs can contain up to 4 watchdog timers to reset +SoC. Each watchdog timer event input is connected to the Reset Mux +block. The Reset Mux block can be configured to cause reset or not. + +Additionally soft or hard reset can be configured. + +Required properties: + +- compatible: ti,keystone-reset + +- reg: Contains offset/length value for mux registers. + + reg = <0x23100e4 0x10>, + <0x2620328 0x10>; + +-reg-names: Contains two ranges "pllregs" and "muxregs". + "pllregs" - PLL reset control regs: RSTYPE, RSCTRL, + RSCFG, RSISO. + "muxregs" - mux block registers for all watchdogs. + +Optional properties: + +- ti,soft-reset: Boolean option indicating soft reset. + By default hard reset is used. + +- ti,wdt_list: WDT list that can cause SoC reset. + The list in format: <0>, <2>; + Begins from 0 to 3, as keystone can contain up + to 4 SoC reset watchdogs. + +Example 1: +Setup keystone reset so that in case software reset or +WDT1 is triggered it issues hard reset for SoC. + +rstctrl: reset-controller { + compatible = "ti,keystone-reset"; + reg = <0x23100e4 0x10>, + <0x2620328 0x10>; + reg-names = "pllregs", "muxregs"; + ti,wdt_list = <0>; +}; + +Example 2: +Setup keystone reset so that in case of software reset or +WDT1 or WDT3 is triggered it issues soft reset for SoC. + +rstctrl: reset-controller { + compatible = "ti,keystone-reset"; + reg = <0x23100e4 0x10>, + <0x2620328 0x10>; + reg-names = "pllregs", "muxregs"; + ti,wdt_list = <0>, <2>; + ti,soft-reset; +};
This node is intended to allow SoC reset in case of software reset or appropriate watchdogs. The Keystone SoCs can contain up to 4 watchdog timers to reset SoC. Each watchdog timer event input is connected to the Reset Mux block. The Reset Mux block can be configured to cause reset or not. Additionally soft or hard reset can be configured. Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> --- .../bindings/power/reset/keystone-reset.txt | 59 ++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/reset/keystone-reset.txt