| Message ID | 1376983966-16490-3-git-send-email-rnayak@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Rajendra Nayak <rnayak@ti.com> [130820 00:41]: > On OMAP we have co-processor IPs, memory controllers, > GPIOs which control regulators and power switches to > PMIC, and SoC internal Bus IPs, some or most of which > should either not be reset or idled or both. Have a > way to pass this information from DT. > (In some cases there are erratas which prevent an IPs > from being reset) > > Also update omap_hwmod to extract this from DT. > > Signed-off-by: Rajendra Nayak <rnayak@ti.com> > --- > .../devicetree/bindings/arm/omap/omap.txt | 3 ++- > arch/arm/mach-omap2/omap_hwmod.c | 22 +++++++++++++------- > 2 files changed, 17 insertions(+), 8 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt > index 6d498c7..a08647e 100644 > --- a/Documentation/devicetree/bindings/arm/omap/omap.txt > +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt > @@ -21,7 +21,8 @@ Required properties: > Optional properties: > - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module > during suspend. > - > +- ti,no-reset: When present, the module should not be reset > +- ti,no-idle: When present, the module should not be idled This naming is a bit confusing as people may think that the hardware has no reset support or no idle support. Let's try to make this to describe the hardware a bit more instead. Then ideally we'd not map individual bits of data to properties, but describe few basic types of hardware instead and build lists of things instead of tagging things. Or maybe we can get this data from the bus hierarchy instead? If these options don't work, and the choice may be board specific, then how about ti,skip-reset-on-init, and ti,skip-idle-on-init? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 21 August 2013 01:15 PM, Tony Lindgren wrote: > * Rajendra Nayak <rnayak@ti.com> [130820 00:41]: >> On OMAP we have co-processor IPs, memory controllers, >> GPIOs which control regulators and power switches to >> PMIC, and SoC internal Bus IPs, some or most of which >> should either not be reset or idled or both. Have a >> way to pass this information from DT. >> (In some cases there are erratas which prevent an IPs >> from being reset) >> >> Also update omap_hwmod to extract this from DT. >> >> Signed-off-by: Rajendra Nayak <rnayak@ti.com> >> --- >> .../devicetree/bindings/arm/omap/omap.txt | 3 ++- >> arch/arm/mach-omap2/omap_hwmod.c | 22 +++++++++++++------- >> 2 files changed, 17 insertions(+), 8 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt >> index 6d498c7..a08647e 100644 >> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt >> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt >> @@ -21,7 +21,8 @@ Required properties: >> Optional properties: >> - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module >> during suspend. >> - >> +- ti,no-reset: When present, the module should not be reset >> +- ti,no-idle: When present, the module should not be idled > > This naming is a bit confusing as people may think that the > hardware has no reset support or no idle support. Let's try > to make this to describe the hardware a bit more instead. > > Then ideally we'd not map individual bits of data to properties, > but describe few basic types of hardware instead and build > lists of things instead of tagging things. Or maybe we > can get this data from the bus hierarchy instead? Yeah, I thought if I could do this without any new bindings. For instance, never reset or idle something which is a "cpu" or an "interrupt-controller" or a "memory-controller" or a "bus". For some like memory-controllers though there are no bindings which describe them as memory-controllers. > > If these options don't work, and the choice may be board > specific, then how about ti,skip-reset-on-init, and > ti,skip-idle-on-init? This looks fine too. > > Regards, > > Tony > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Rajendra Nayak <rnayak@ti.com> [130821 01:54]: > On Wednesday 21 August 2013 01:15 PM, Tony Lindgren wrote: > > * Rajendra Nayak <rnayak@ti.com> [130820 00:41]: > >> On OMAP we have co-processor IPs, memory controllers, > >> GPIOs which control regulators and power switches to > >> PMIC, and SoC internal Bus IPs, some or most of which > >> should either not be reset or idled or both. Have a > >> way to pass this information from DT. > >> (In some cases there are erratas which prevent an IPs > >> from being reset) > >> > >> Also update omap_hwmod to extract this from DT. > >> > >> Signed-off-by: Rajendra Nayak <rnayak@ti.com> > >> --- > >> .../devicetree/bindings/arm/omap/omap.txt | 3 ++- > >> arch/arm/mach-omap2/omap_hwmod.c | 22 +++++++++++++------- > >> 2 files changed, 17 insertions(+), 8 deletions(-) > >> > >> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt > >> index 6d498c7..a08647e 100644 > >> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt > >> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt > >> @@ -21,7 +21,8 @@ Required properties: > >> Optional properties: > >> - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module > >> during suspend. > >> - > >> +- ti,no-reset: When present, the module should not be reset > >> +- ti,no-idle: When present, the module should not be idled > > > > This naming is a bit confusing as people may think that the > > hardware has no reset support or no idle support. Let's try > > to make this to describe the hardware a bit more instead. > > > > Then ideally we'd not map individual bits of data to properties, > > but describe few basic types of hardware instead and build > > lists of things instead of tagging things. Or maybe we > > can get this data from the bus hierarchy instead? > > Yeah, I thought if I could do this without any new bindings. > For instance, never reset or idle something which is a "cpu" or an > "interrupt-controller" or a "memory-controller" or a "bus". > For some like memory-controllers though there are no bindings which > describe them as memory-controllers. > > > > > If these options don't work, and the choice may be board > > specific, then how about ti,skip-reset-on-init, and > > ti,skip-idle-on-init? > > This looks fine too. Or you could also have various bus specific bindings for the ocp with lists of phandles? ocp { reg = <...>; interrupts = <...>; ti,reset-on-init = <&module1, &module2>; ... }; Or something similar. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 21 August 2013 02:23 PM, Tony Lindgren wrote: > * Rajendra Nayak <rnayak@ti.com> [130821 01:54]: >> On Wednesday 21 August 2013 01:15 PM, Tony Lindgren wrote: >>> * Rajendra Nayak <rnayak@ti.com> [130820 00:41]: >>>> On OMAP we have co-processor IPs, memory controllers, >>>> GPIOs which control regulators and power switches to >>>> PMIC, and SoC internal Bus IPs, some or most of which >>>> should either not be reset or idled or both. Have a >>>> way to pass this information from DT. >>>> (In some cases there are erratas which prevent an IPs >>>> from being reset) >>>> >>>> Also update omap_hwmod to extract this from DT. >>>> >>>> Signed-off-by: Rajendra Nayak <rnayak@ti.com> >>>> --- >>>> .../devicetree/bindings/arm/omap/omap.txt | 3 ++- >>>> arch/arm/mach-omap2/omap_hwmod.c | 22 +++++++++++++------- >>>> 2 files changed, 17 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt >>>> index 6d498c7..a08647e 100644 >>>> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt >>>> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt >>>> @@ -21,7 +21,8 @@ Required properties: >>>> Optional properties: >>>> - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module >>>> during suspend. >>>> - >>>> +- ti,no-reset: When present, the module should not be reset >>>> +- ti,no-idle: When present, the module should not be idled >>> >>> This naming is a bit confusing as people may think that the >>> hardware has no reset support or no idle support. Let's try >>> to make this to describe the hardware a bit more instead. >>> >>> Then ideally we'd not map individual bits of data to properties, >>> but describe few basic types of hardware instead and build >>> lists of things instead of tagging things. Or maybe we >>> can get this data from the bus hierarchy instead? >> >> Yeah, I thought if I could do this without any new bindings. >> For instance, never reset or idle something which is a "cpu" or an >> "interrupt-controller" or a "memory-controller" or a "bus". >> For some like memory-controllers though there are no bindings which >> describe them as memory-controllers. >> >>> >>> If these options don't work, and the choice may be board >>> specific, then how about ti,skip-reset-on-init, and >>> ti,skip-idle-on-init? >> >> This looks fine too. > > Or you could also have various bus specific bindings for the ocp > with lists of phandles? > > ocp { > reg = <...>; > interrupts = <...>; > ti,reset-on-init = <&module1, &module2>; > ... > }; > > Or something similar. The only problem I see with this is that some of these modules could be board specific ones and need to be part of the board dts files, like some boards which have PMIC power switch hooked up to some gpio etc. So there could be some SoC specific modules (like emif/gpmc on OMAPs) and some which depend on how the boards are designed. > > Tony > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 21/08/2013 09:45, Tony Lindgren wrote: > * Rajendra Nayak <rnayak@ti.com> [130820 00:41]: >> On OMAP we have co-processor IPs, memory controllers, >> GPIOs which control regulators and power switches to >> PMIC, and SoC internal Bus IPs, some or most of which >> should either not be reset or idled or both. Have a >> way to pass this information from DT. >> (In some cases there are erratas which prevent an IPs >> from being reset) >> >> Also update omap_hwmod to extract this from DT. >> >> Signed-off-by: Rajendra Nayak <rnayak@ti.com> >> --- >> .../devicetree/bindings/arm/omap/omap.txt | 3 ++- >> arch/arm/mach-omap2/omap_hwmod.c | 22 +++++++++++++------- >> 2 files changed, 17 insertions(+), 8 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt >> index 6d498c7..a08647e 100644 >> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt >> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt >> @@ -21,7 +21,8 @@ Required properties: >> Optional properties: >> - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module >> during suspend. >> - >> +- ti,no-reset: When present, the module should not be reset >> +- ti,no-idle: When present, the module should not be idled > > This naming is a bit confusing as people may think that the > hardware has no reset support or no idle support. Let's try > to make this to describe the hardware a bit more instead. Yeah, I do agree here. That should look like a real HW property and nor a configuration. > Then ideally we'd not map individual bits of data to properties, > but describe few basic types of hardware instead and build > lists of things instead of tagging things. Or maybe we > can get this data from the bus hierarchy instead? > > If these options don't work, and the choice may be board > specific, then how about ti,skip-reset-on-init, and > ti,skip-idle-on-init? It looks like a configuration as well :-). I was thinking of something like "ti,do-not-support-reset-on-init", but that a little bit too long. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 21 August 2013 02:59 PM, Benoit Cousson wrote: > On 21/08/2013 09:45, Tony Lindgren wrote: >> * Rajendra Nayak <rnayak@ti.com> [130820 00:41]: >>> On OMAP we have co-processor IPs, memory controllers, >>> GPIOs which control regulators and power switches to >>> PMIC, and SoC internal Bus IPs, some or most of which >>> should either not be reset or idled or both. Have a >>> way to pass this information from DT. >>> (In some cases there are erratas which prevent an IPs >>> from being reset) >>> >>> Also update omap_hwmod to extract this from DT. >>> >>> Signed-off-by: Rajendra Nayak <rnayak@ti.com> >>> --- >>> .../devicetree/bindings/arm/omap/omap.txt | 3 ++- >>> arch/arm/mach-omap2/omap_hwmod.c | 22 +++++++++++++------- >>> 2 files changed, 17 insertions(+), 8 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt >>> index 6d498c7..a08647e 100644 >>> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt >>> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt >>> @@ -21,7 +21,8 @@ Required properties: >>> Optional properties: >>> - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module >>> during suspend. >>> - >>> +- ti,no-reset: When present, the module should not be reset >>> +- ti,no-idle: When present, the module should not be idled >> >> This naming is a bit confusing as people may think that the >> hardware has no reset support or no idle support. Let's try >> to make this to describe the hardware a bit more instead. > > Yeah, I do agree here. That should look like a real HW property and nor a configuration. > >> Then ideally we'd not map individual bits of data to properties, >> but describe few basic types of hardware instead and build >> lists of things instead of tagging things. Or maybe we >> can get this data from the bus hierarchy instead? >> >> If these options don't work, and the choice may be board >> specific, then how about ti,skip-reset-on-init, and >> ti,skip-idle-on-init? > > It looks like a configuration as well :-). > I was thinking of something like "ti,do-not-support-reset-on-init", but that a little bit too long. How about 'ti,no-reset-on-init' :) which is what I had initially which I then moved to 'ti,no-reset' > > Regards, > Benoit > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Rajendra Nayak <rnayak@ti.com> [130821 02:29]: > On Wednesday 21 August 2013 02:23 PM, Tony Lindgren wrote: > > > > Or you could also have various bus specific bindings for the ocp > > with lists of phandles? > > > > ocp { > > reg = <...>; > > interrupts = <...>; > > ti,reset-on-init = <&module1, &module2>; > > ... > > }; > > > > Or something similar. > > The only problem I see with this is that some of these modules could be > board specific ones and need to be part of the board dts files, like > some boards which have PMIC power switch hooked up to some gpio etc. > So there could be some SoC specific modules (like emif/gpmc on OMAPs) > and some which depend on how the boards are designed. You can still override the ocp entry in the board specific .dts file. Would probably be a lot easier than to override each module separately in the board specific .dts file. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 21 August 2013 05:53 PM, Tony Lindgren wrote: > * Rajendra Nayak <rnayak@ti.com> [130821 02:29]: >> On Wednesday 21 August 2013 02:23 PM, Tony Lindgren wrote: >>> >>> Or you could also have various bus specific bindings for the ocp >>> with lists of phandles? >>> >>> ocp { >>> reg = <...>; >>> interrupts = <...>; >>> ti,reset-on-init = <&module1, &module2>; >>> ... >>> }; >>> >>> Or something similar. >> >> The only problem I see with this is that some of these modules could be >> board specific ones and need to be part of the board dts files, like >> some boards which have PMIC power switch hooked up to some gpio etc. >> So there could be some SoC specific modules (like emif/gpmc on OMAPs) >> and some which depend on how the boards are designed. > > You can still override the ocp entry in the board specific .dts file. > Would probably be a lot easier than to override each module separately > in the board specific .dts file. So, If I understand this right we would have the dt entries something like, omap4.dtsi ------ ocp { reg = <...>; interrupts = <...>; ti,no-reset-on-init = <&emif1, &emif2, &gpmc>; ... }; omap4-panda-es.dts ------ ocp { ti,no-reset-on-init = <&emif1, &emif2, &gpmc, &gpio4>; ... }; Is it that, or you suggesting we can _append_ the soc list of modules with board specific modules, which I am not sure if its possible. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > So, If I understand this right we would have the dt entries > something like, > > omap4.dtsi > ------ > ocp { > reg = <...>; > interrupts = <...>; > ti,no-reset-on-init = <&emif1, &emif2, &gpmc>; > ... > }; > > omap4-panda-es.dts > ------ > ocp { This would actually be &ocp { > ti,no-reset-on-init = <&emif1, &emif2, &gpmc, &gpio4>; > ... > }; > > Is it that, or you suggesting we can _append_ the soc list of > modules with board specific modules, which I am not sure if its > possible. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Rajendra Nayak <rnayak@ti.com> [130821 05:46]: > On Wednesday 21 August 2013 05:53 PM, Tony Lindgren wrote: > > * Rajendra Nayak <rnayak@ti.com> [130821 02:29]: > >> On Wednesday 21 August 2013 02:23 PM, Tony Lindgren wrote: > >>> > >>> Or you could also have various bus specific bindings for the ocp > >>> with lists of phandles? > >>> > >>> ocp { > >>> reg = <...>; > >>> interrupts = <...>; > >>> ti,reset-on-init = <&module1, &module2>; > >>> ... > >>> }; > >>> > >>> Or something similar. > >> > >> The only problem I see with this is that some of these modules could be > >> board specific ones and need to be part of the board dts files, like > >> some boards which have PMIC power switch hooked up to some gpio etc. > >> So there could be some SoC specific modules (like emif/gpmc on OMAPs) > >> and some which depend on how the boards are designed. > > > > You can still override the ocp entry in the board specific .dts file. > > Would probably be a lot easier than to override each module separately > > in the board specific .dts file. > > So, If I understand this right we would have the dt entries > something like, > > omap4.dtsi > ------ > ocp { > reg = <...>; > interrupts = <...>; > ti,no-reset-on-init = <&emif1, &emif2, &gpmc>; > ... > }; > > omap4-panda-es.dts > ------ > ocp { > ti,no-reset-on-init = <&emif1, &emif2, &gpmc, &gpio4>; > ... > }; > > Is it that, or you suggesting we can _append_ the soc list of > modules with board specific modules, which I am not sure if its > possible. Yes I think the board specific entry just overrides the .dtsi entry. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 21/08/2013 14:51, Tony Lindgren wrote: > * Rajendra Nayak <rnayak@ti.com> [130821 05:46]: >> On Wednesday 21 August 2013 05:53 PM, Tony Lindgren wrote: >>> * Rajendra Nayak <rnayak@ti.com> [130821 02:29]: >>>> On Wednesday 21 August 2013 02:23 PM, Tony Lindgren wrote: >>>>> >>>>> Or you could also have various bus specific bindings for the ocp >>>>> with lists of phandles? >>>>> >>>>> ocp { >>>>> reg = <...>; >>>>> interrupts = <...>; >>>>> ti,reset-on-init = <&module1, &module2>; >>>>> ... >>>>> }; >>>>> >>>>> Or something similar. >>>> >>>> The only problem I see with this is that some of these modules could be >>>> board specific ones and need to be part of the board dts files, like >>>> some boards which have PMIC power switch hooked up to some gpio etc. >>>> So there could be some SoC specific modules (like emif/gpmc on OMAPs) >>>> and some which depend on how the boards are designed. >>> >>> You can still override the ocp entry in the board specific .dts file. >>> Would probably be a lot easier than to override each module separately >>> in the board specific .dts file. >> >> So, If I understand this right we would have the dt entries >> something like, >> >> omap4.dtsi >> ------ >> ocp { >> reg = <...>; >> interrupts = <...>; >> ti,no-reset-on-init = <&emif1, &emif2, &gpmc>; >> ... >> }; >> >> omap4-panda-es.dts >> ------ >> ocp { >> ti,no-reset-on-init = <&emif1, &emif2, &gpmc, &gpio4>; >> ... >> }; >> >> Is it that, or you suggesting we can _append_ the soc list of >> modules with board specific modules, which I am not sure if its >> possible. > > Yes I think the board specific entry just overrides the .dtsi > entry. That's the issue of using a single attribute with a list. You cannot add or remove an entry. That's why I think it is better to stick to a per device attribute. Moreover, in term of SW, this is managed at device level today. I'm not convince it will make sense to move that to the OCP level for the moment. Even if we consider that in the future an omap-ocp bus driver will handle most of the PM/reset glue managed today by hwmod, it will still be a per device attribute. The bus driver, being the parent of the device, will anyway be able to retrieve the information at device level if needed. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index 6d498c7..a08647e 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -21,7 +21,8 @@ Required properties: Optional properties: - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module during suspend. - +- ti,no-reset: When present, the module should not be reset +- ti,no-idle: When present, the module should not be idled Example: diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 7f4db12..4c66a5e 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -2361,11 +2361,11 @@ static struct device_node *of_dev_hwmod_lookup(struct device_node *np, * are part of the device's address space can be ioremapped properly. * No return value. */ -static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data) +static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data, + struct device_node *np) { struct omap_hwmod_addr_space *mem; void __iomem *va_start = NULL; - struct device_node *np; if (!oh) return; @@ -2381,12 +2381,10 @@ static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data) oh->name); /* Extract the IO space from device tree blob */ - if (!of_have_populated_dt()) + if (!np) return; - np = of_dev_hwmod_lookup(of_find_node_by_name(NULL, "ocp"), oh); - if (np) - va_start = of_iomap(np, oh->mpu_rt_idx); + va_start = of_iomap(np, oh->mpu_rt_idx); } else { va_start = ioremap(mem->pa_start, mem->pa_end - mem->pa_start); } @@ -2418,12 +2416,16 @@ static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data) static int __init _init(struct omap_hwmod *oh, void *data) { int r; + struct device_node *np = NULL; if (oh->_state != _HWMOD_STATE_REGISTERED) return 0; + if (of_have_populated_dt()) + np = of_dev_hwmod_lookup(of_find_node_by_name(NULL, "ocp"), oh); + if (oh->class->sysc) - _init_mpu_rt_base(oh, NULL); + _init_mpu_rt_base(oh, NULL, np); r = _init_clocks(oh, NULL); if (r < 0) { @@ -2431,6 +2433,12 @@ static int __init _init(struct omap_hwmod *oh, void *data) return -EINVAL; } + if (np) + if (of_find_property(np, "ti,no-reset", NULL)) + oh->flags |= HWMOD_INIT_NO_RESET; + if (of_find_property(np, "ti,no-idle", NULL)) + oh->flags |= HWMOD_INIT_NO_IDLE; + oh->_state = _HWMOD_STATE_INITIALIZED; return 0;
On OMAP we have co-processor IPs, memory controllers, GPIOs which control regulators and power switches to PMIC, and SoC internal Bus IPs, some or most of which should either not be reset or idled or both. Have a way to pass this information from DT. (In some cases there are erratas which prevent an IPs from being reset) Also update omap_hwmod to extract this from DT. Signed-off-by: Rajendra Nayak <rnayak@ti.com> --- .../devicetree/bindings/arm/omap/omap.txt | 3 ++- arch/arm/mach-omap2/omap_hwmod.c | 22 +++++++++++++------- 2 files changed, 17 insertions(+), 8 deletions(-)