| Message ID | 87ehij8lpb.fsf@dell.be.48ers.dk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Peter, On Fri, 21 Dec 2012, Peter Korsgaard wrote: > On a custom am335x board I was surprised to see the kernel resetting > gpio pins not mentioned anywhere in the dts. The original plan with DT was to start by focusing on devices on the board, rather than devices on the SoC. The GPIO is an SoC device, so it's currently managed by the hwmod data. (This will probably change with future kernel releases.) > In this specific case the pin is connected to nCONFIG of a FPGA. The > FPGA is commanded to start configuration from a SPI flash in the > bootloader, so it can happen in parallel with kernel > load/uncompress/startup, but as the kernel resets the gpio during > initialization this doesn't work. > > Digging a bit into it, I see the hwmod of the gpio controller is > configured to reset at startup, and it works correctly (E.G. the pin is > left asserted) if I change it to HWMOD_INIT_NO_RESET: > > --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c > @@ -992,7 +992,7 @@ static struct omap_hwmod am33xx_gpio1_hwmod = { > .name = "gpio2", > .class = &am33xx_gpio_hwmod_class, > .clkdm_name = "l4ls_clkdm", > - .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET, > + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET), > .mpu_irqs = am33xx_gpio1_irqs, > .main_clk = "l4ls_gclk", > .prcm = { > > Now the question is why is this configured like this? This behavior is intended to decouple the kernel from the bootloader, or previously-booted operating system (e.g., the kexec case). The original goal was to place the system in an known safe state as soon as possible after the kernel starts. This is to prevent misconfigured or previously-configured devices from trashing memory or chip power management in the currently-booted kernel. It also avoids adding inadvertent bootloader dependencies in driver code. N.B., the plan is to change this behavior over the next few releases. Devices that have drivers associated with them will be reset when the driver loads. Driverless devices will be reset after drivers load, late in boot. > Should E.G. the gpio controllers be changed to not reset or should it be > configurable in the dts? Probably the DTS is the right place, since this is a board- and bootloader-specific quirk. The original intention was to allow board files to set this HWMOD_INIT_NO_RESET flag themselves - see mach-omap2/ omap_hwmod.c:omap_hwmod_no_setup_reset(). But since we've deprecated the board files, the DT data seems like the right place. It probably shouldn't be a GPIO-specific property. Other devices like DSS will also need some kind of 'no-init-reset' property, since on many commercial devices, it's expected that some kind of splash screen will be presented by the bootloader and stay on during the boot process. However, it is probably safest in the long run if you can change the board design to require the SoC to actively reset the FPGA, rather than making reset the default state. That way, if there's some hardware bug that requires the GPIO block to be reset, or if there's some GPIO glitch during power management, the FPGA won't be inadvertently reset. regards, - Paul -- 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
>>>>> "Paul" == Paul Walmsley <paul@pwsan.com> writes: Hi Paul, Thanks for the detailed explanaition, and sorry for the slow response - I've been away on holidays. >> Now the question is why is this configured like this? Paul> This behavior is intended to decouple the kernel from the Paul> bootloader, or previously-booted operating system (e.g., the Paul> kexec case). The original goal was to place the system in an Paul> known safe state as soon as possible after the kernel starts. Paul> This is to prevent misconfigured or previously-configured devices Paul> from trashing memory or chip power management in the Paul> currently-booted kernel. It also avoids adding inadvertent Paul> bootloader dependencies in driver code. Paul> N.B., the plan is to change this behavior over the next few Paul> releases. Devices that have drivers associated with them will be Paul> reset when the driver loads. Driverless devices will be reset Paul> after drivers load, late in boot. >> Should E.G. the gpio controllers be changed to not reset or should it be >> configurable in the dts? Paul> Probably the DTS is the right place, since this is a board- and Paul> bootloader-specific quirk. The original intention was to allow Paul> board files to set this HWMOD_INIT_NO_RESET flag themselves - see Paul> mach-omap2/ omap_hwmod.c:omap_hwmod_no_setup_reset(). But since Paul> we've deprecated the board files, the DT data seems like the Paul> right place. Paul> It probably shouldn't be a GPIO-specific property. Other devices Paul> like DSS will also need some kind of 'no-init-reset' property, Paul> since on many commercial devices, it's expected that some kind of Paul> splash screen will be presented by the bootloader and stay on Paul> during the boot process. I tried changing omap_device_build_from_dt() to call omap_hwmod_no_setup_reset() on the corresponding hwmod if a ti,no-init-reset was present, but that doesn't work as the hwmod reset happens quite a bit earlier (in omap_hwmod_setup_all()). Do you have idea how I could work around this or is that the future reset change you referred to above? Paul> However, it is probably safest in the long run if you can change Paul> the board design to require the SoC to actively reset the FPGA, Paul> rather than making reset the default state. That way, if there's Paul> some hardware bug that requires the GPIO block to be reset, or if Paul> there's some GPIO glitch during power management, the FPGA won't Paul> be inadvertently reset. Yes, I'll try to get that done for the next board spin. Thanks!
>>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
Hi,
Paul> Probably the DTS is the right place, since this is a board- and
Paul> bootloader-specific quirk. The original intention was to allow
Paul> board files to set this HWMOD_INIT_NO_RESET flag themselves - see
Paul> mach-omap2/ omap_hwmod.c:omap_hwmod_no_setup_reset(). But since
Paul> we've deprecated the board files, the DT data seems like the
Paul> right place.
Paul> It probably shouldn't be a GPIO-specific property. Other devices
Paul> like DSS will also need some kind of 'no-init-reset' property,
Paul> since on many commercial devices, it's expected that some kind of
Paul> splash screen will be presented by the bootloader and stay on
Paul> during the boot process.
Peter> I tried changing omap_device_build_from_dt() to call
Peter> omap_hwmod_no_setup_reset() on the corresponding hwmod if a
Peter> ti,no-init-reset was present, but that doesn't work as the hwmod
Peter> reset happens quite a bit earlier (in
Peter> omap_hwmod_setup_all()). Do you have idea how I could work
Peter> around this or is that the future reset change you referred to
Peter> above?
Paul, any ideas?
Hi, On Sun, Dec 23, 2012 at 08:58:13PM +0000, Paul Walmsley wrote: > > In this specific case the pin is connected to nCONFIG of a FPGA. The > > FPGA is commanded to start configuration from a SPI flash in the > > bootloader, so it can happen in parallel with kernel > > load/uncompress/startup, but as the kernel resets the gpio during > > initialization this doesn't work. > > > > Digging a bit into it, I see the hwmod of the gpio controller is > > configured to reset at startup, and it works correctly (E.G. the pin is > > left asserted) if I change it to HWMOD_INIT_NO_RESET: > > > > --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c > > +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c > > @@ -992,7 +992,7 @@ static struct omap_hwmod am33xx_gpio1_hwmod = { > > .name = "gpio2", > > .class = &am33xx_gpio_hwmod_class, > > .clkdm_name = "l4ls_clkdm", > > - .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET, > > + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET), > > .mpu_irqs = am33xx_gpio1_irqs, > > .main_clk = "l4ls_gclk", > > .prcm = { > > > > Now the question is why is this configured like this? > > This behavior is intended to decouple the kernel from the bootloader, or > previously-booted operating system (e.g., the kexec case). The original > goal was to place the system in an known safe state as soon as possible > after the kernel starts. This is to prevent misconfigured or there is one "issue" with this. At least on AM335x starter kit, GPIO0_7 is used as DDR power pin. If we reset that GPIO bank, DDR looses power and "for obscure reasons" (:-)) the board doesn't boot. In this case, we cannot reset that bank, otherwise Starter Kit will never boot in mainline. Bad PCB design, I know, but it's not something we can change now :-) cheers
>>>>> "Felipe" == Felipe Balbi <balbi@ti.com> writes: Hi, >> > +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c >> > @@ -992,7 +992,7 @@ static struct omap_hwmod am33xx_gpio1_hwmod = { >> > .name = "gpio2", >> > .class = &am33xx_gpio_hwmod_class, >> > .clkdm_name = "l4ls_clkdm", >> > - .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET, >> > + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET), >> > .mpu_irqs = am33xx_gpio1_irqs, >> > .main_clk = "l4ls_gclk", >> > .prcm = { >> > >> > Now the question is why is this configured like this? >> >> This behavior is intended to decouple the kernel from the bootloader, or >> previously-booted operating system (e.g., the kexec case). The original >> goal was to place the system in an known safe state as soon as possible >> after the kernel starts. This is to prevent misconfigured or Felipe> there is one "issue" with this. At least on AM335x starter kit, Felipe> GPIO0_7 is used as DDR power pin. If we reset that GPIO bank, Felipe> DDR looses power and "for obscure reasons" (:-)) the board Felipe> doesn't boot. Heh! Felipe> In this case, we cannot reset that bank, otherwise Starter Kit Felipe> will never boot in mainline. Bad PCB design, I know, but it's Felipe> not something we can change now :-) Indeed. So that's two examples of people designing boards with the assumption that gpios will not toggle between bootloader and running system. Chances are that there will be others.
Felipe Balbi <balbi@ti.com> writes: > Hi, > > On Sun, Dec 23, 2012 at 08:58:13PM +0000, Paul Walmsley wrote: >> > In this specific case the pin is connected to nCONFIG of a FPGA. The >> > FPGA is commanded to start configuration from a SPI flash in the >> > bootloader, so it can happen in parallel with kernel >> > load/uncompress/startup, but as the kernel resets the gpio during >> > initialization this doesn't work. >> > >> > Digging a bit into it, I see the hwmod of the gpio controller is >> > configured to reset at startup, and it works correctly (E.G. the pin is >> > left asserted) if I change it to HWMOD_INIT_NO_RESET: >> > >> > --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c >> > +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c >> > @@ -992,7 +992,7 @@ static struct omap_hwmod am33xx_gpio1_hwmod = { >> > .name = "gpio2", >> > .class = &am33xx_gpio_hwmod_class, >> > .clkdm_name = "l4ls_clkdm", >> > - .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET, >> > + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET), >> > .mpu_irqs = am33xx_gpio1_irqs, >> > .main_clk = "l4ls_gclk", >> > .prcm = { >> > >> > Now the question is why is this configured like this? >> >> This behavior is intended to decouple the kernel from the bootloader, or >> previously-booted operating system (e.g., the kexec case). The original >> goal was to place the system in an known safe state as soon as possible >> after the kernel starts. This is to prevent misconfigured or > > there is one "issue" with this. At least on AM335x starter kit, GPIO0_7 > is used as DDR power pin. If we reset that GPIO bank, DDR looses power > and "for obscure reasons" (:-)) the board doesn't boot. > > In this case, we cannot reset that bank, otherwise Starter Kit will > never boot in mainline. Bad PCB design, I know, but it's not something > we can change now :-) FWIW, we've seen this before (GPIO connected to PMIC reset is a fun one), and this is why we have omap_hwmod_no_setup_reset(). Kevin -- 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
>>>>> "Kevin" == Kevin Hilman <khilman@linaro.org> writes: >> In this case, we cannot reset that bank, otherwise Starter Kit will >> never boot in mainline. Bad PCB design, I know, but it's not something >> we can change now :-) Kevin> FWIW, we've seen this before (GPIO connected to PMIC reset is a Kevin> fun one), and this is why we have omap_hwmod_no_setup_reset(). Yes, but there's no dts bindings for this, and from a quick test the reset handling happens before the device tree is probed.
On 20:10-20130517, Peter Korsgaard wrote: > >>>>> "Kevin" == Kevin Hilman <khilman@linaro.org> writes: > > >> In this case, we cannot reset that bank, otherwise Starter Kit will > >> never boot in mainline. Bad PCB design, I know, but it's not something > >> we can change now :-) > > Kevin> FWIW, we've seen this before (GPIO connected to PMIC reset is a > Kevin> fun one), and this is why we have omap_hwmod_no_setup_reset(). > > Yes, but there's no dts bindings for this, and from a quick test the > reset handling happens before the device tree is probed. I have the same issue with TPS62361 on Palmas -> GPIO controls the voltage register supplying MPU, without any driver setting things up, GPIO gets reset and obviously voltage value switches to an voltage where device does not function. Solution I am working on to solve this is [1]: snippet is part of a patch that I am working on atm. This is the right way to do it IMHO. Will allow the driver to exist when HWMOD will be eventually replaced by some other framework. [1]: http://pastebin.com/XPmAB1Zb
> -----Original Message----- > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > owner@vger.kernel.org] On Behalf Of Menon, Nishanth > Sent: Friday, May 17, 2013 11:49 PM > To: Peter Korsgaard > Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- > omap@vger.kernel.org; Tony Lindgren > Subject: Re: reset handling in am335x hwmod data > > On 20:10-20130517, Peter Korsgaard wrote: > > >>>>> "Kevin" == Kevin Hilman <khilman@linaro.org> writes: > > > > >> In this case, we cannot reset that bank, otherwise Starter Kit > will > > >> never boot in mainline. Bad PCB design, I know, but it's not > something > > >> we can change now :-) > > > > Kevin> FWIW, we've seen this before (GPIO connected to PMIC reset is > a > > Kevin> fun one), and this is why we have > omap_hwmod_no_setup_reset(). > > > > Yes, but there's no dts bindings for this, and from a quick test the > > reset handling happens before the device tree is probed. > I have the same issue with TPS62361 on Palmas -> GPIO controls the > voltage register supplying MPU, without any driver setting things up, > GPIO gets reset and obviously voltage value switches to an voltage > where > device does not function. > > Solution I am working on to solve this is [1]: snippet is part of a > patch that I am working on atm. > > This is the right way to do it IMHO. Will allow the driver to exist > when > HWMOD will be eventually replaced by some other framework. > > > [1]: http://pastebin.com/XPmAB1Zb > > Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot. Ideally, it would have been much better if drivers starts handling Idle, ocp reset and standby on their own (killing dependency on hwmod init layer). But looking at current state, I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to parse It early during hwmod init stage. We should read all DT nodes Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset. Thanks, Vaibhav -- 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
> -----Original Message----- > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > owner@vger.kernel.org] On Behalf Of Hiremath, Vaibhav > Sent: Monday, May 20, 2013 12:09 PM > To: Menon, Nishanth; Peter Korsgaard > Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- > omap@vger.kernel.org; Tony Lindgren > Subject: RE: reset handling in am335x hwmod data > > > > -----Original Message----- > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > > owner@vger.kernel.org] On Behalf Of Menon, Nishanth > > Sent: Friday, May 17, 2013 11:49 PM > > To: Peter Korsgaard > > Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- > > omap@vger.kernel.org; Tony Lindgren > > Subject: Re: reset handling in am335x hwmod data > > > > On 20:10-20130517, Peter Korsgaard wrote: > > > >>>>> "Kevin" == Kevin Hilman <khilman@linaro.org> writes: > > > > > > >> In this case, we cannot reset that bank, otherwise Starter Kit > > will > > > >> never boot in mainline. Bad PCB design, I know, but it's not > > something > > > >> we can change now :-) > > > > > > Kevin> FWIW, we've seen this before (GPIO connected to PMIC reset > is > > a > > > Kevin> fun one), and this is why we have > > omap_hwmod_no_setup_reset(). > > > > > > Yes, but there's no dts bindings for this, and from a quick test > the > > > reset handling happens before the device tree is probed. > > I have the same issue with TPS62361 on Palmas -> GPIO controls the > > voltage register supplying MPU, without any driver setting things up, > > GPIO gets reset and obviously voltage value switches to an voltage > > where > > device does not function. > > > > Solution I am working on to solve this is [1]: snippet is part of a > > patch that I am working on atm. > > > > This is the right way to do it IMHO. Will allow the driver to exist > > when > > HWMOD will be eventually replaced by some other framework. > > > > > > [1]: http://pastebin.com/XPmAB1Zb > > > > > > Both seems to be different to me. What we need is to > Avoid reset of whole GPIO bank during kernel boot. > > Ideally, it would have been much better if drivers starts handling > Idle, ocp reset and standby on their own (killing dependency on hwmod > init layer). > > But looking at current state, > I agree we need to use DT property here, so how about > Adding DT property to GPIO node itself. But we have to parse > It early during hwmod init stage. We should read all DT nodes > Inside function __setup() function, that way can get rid of > HWMOD_INIT_NO_RESET flag completely. Also, this will handle > Both ocp_reset and domain reset. > Forgot to mention, Since this is kernel boot failure issue, I think, By the time we reach to conclusion, another approach is to set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank. Thanks, Vaibhav -- 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 01:55-20130520, Hiremath, Vaibhav wrote: > > > -----Original Message----- > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > > owner@vger.kernel.org] On Behalf Of Hiremath, Vaibhav > > Sent: Monday, May 20, 2013 12:09 PM > > To: Menon, Nishanth; Peter Korsgaard > > Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- > > omap@vger.kernel.org; Tony Lindgren > > Subject: RE: reset handling in am335x hwmod data > > > > > > > -----Original Message----- > > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > > > owner@vger.kernel.org] On Behalf Of Menon, Nishanth > > > Sent: Friday, May 17, 2013 11:49 PM > > > To: Peter Korsgaard > > > Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- > > > omap@vger.kernel.org; Tony Lindgren > > > Subject: Re: reset handling in am335x hwmod data > > > > > > On 20:10-20130517, Peter Korsgaard wrote: > > > > >>>>> "Kevin" == Kevin Hilman <khilman@linaro.org> writes: > > > > > > > > >> In this case, we cannot reset that bank, otherwise Starter Kit > > > will > > > > >> never boot in mainline. Bad PCB design, I know, but it's not > > > something > > > > >> we can change now :-) > > > > > > > > Kevin> FWIW, we've seen this before (GPIO connected to PMIC reset > > is > > > a > > > > Kevin> fun one), and this is why we have > > > omap_hwmod_no_setup_reset(). > > > > > > > > Yes, but there's no dts bindings for this, and from a quick test > > the > > > > reset handling happens before the device tree is probed. > > > I have the same issue with TPS62361 on Palmas -> GPIO controls the > > > voltage register supplying MPU, without any driver setting things up, > > > GPIO gets reset and obviously voltage value switches to an voltage > > > where > > > device does not function. > > > > > > Solution I am working on to solve this is [1]: snippet is part of a > > > patch that I am working on atm. > > > > > > This is the right way to do it IMHO. Will allow the driver to exist > > > when > > > HWMOD will be eventually replaced by some other framework. > > > > > > > > > [1]: http://pastebin.com/XPmAB1Zb > > > > > > > > > > Both seems to be different to me. What we need is to > > Avoid reset of whole GPIO bank during kernel boot. Yes - that is what the above does - as long as the GPIO is requested and set to the right level by the relevant driver, it is not "unused" and hence not reset at late_init. I am a little unclear as to why this needs to have anything to do with the precise under-lying mechanism (hwmod or something else). May be "both seem to be different to me" needs a little further elaboration? Is this because there is no need for an EMIF driver to handle DDR? and reset of the GPIO will occur as EMIF is configured at bootloader and there is no need to do that in kernel, correspondingly there is no "driver" to hold the gpio? > > > > Ideally, it would have been much better if drivers starts handling > > Idle, ocp reset and standby on their own (killing dependency on hwmod > > init layer). > > > > But looking at current state, > > I agree we need to use DT property here, so how about > > Adding DT property to GPIO node itself. But we have to parse I believe you mean at OMAP specific DT property for hwmod? something like ti,hwmod-no-init-reset? > > It early during hwmod init stage. We should read all DT nodes > > Inside function __setup() function, that way can get rid of > > HWMOD_INIT_NO_RESET flag completely. Also, this will handle > > Both ocp_reset and domain reset. > > > > Forgot to mention, > > Since this is kernel boot failure issue, I think, > By the time we reach to conclusion, another approach is to > set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank. a) if the GPIO gets moved over to some other GPIO bank on another platform, this wont work b) for platforms that dont use gpio to hold DDR power, maybe this is not even relevant and the GPIO bank can safely be reset? > > Thanks, > Vaibhav
> -----Original Message----- > From: Menon, Nishanth > Sent: Monday, May 20, 2013 8:36 PM > To: Hiremath, Vaibhav > Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- > omap@vger.kernel.org; Tony Lindgren > Subject: Re: reset handling in am335x hwmod data > > On 01:55-20130520, Hiremath, Vaibhav wrote: > > > > > -----Original Message----- > > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > > > owner@vger.kernel.org] On Behalf Of Hiremath, Vaibhav > > > Sent: Monday, May 20, 2013 12:09 PM > > > To: Menon, Nishanth; Peter Korsgaard > > > Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- > > > omap@vger.kernel.org; Tony Lindgren > > > Subject: RE: reset handling in am335x hwmod data > > > > > > > > > > -----Original Message----- > > > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > > > > owner@vger.kernel.org] On Behalf Of Menon, Nishanth > > > > Sent: Friday, May 17, 2013 11:49 PM > > > > To: Peter Korsgaard > > > > Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- > > > > omap@vger.kernel.org; Tony Lindgren > > > > Subject: Re: reset handling in am335x hwmod data > > > > > > > > On 20:10-20130517, Peter Korsgaard wrote: > > > > > >>>>> "Kevin" == Kevin Hilman <khilman@linaro.org> writes: > > > > > > > > > > >> In this case, we cannot reset that bank, otherwise Starter > Kit > > > > will > > > > > >> never boot in mainline. Bad PCB design, I know, but it's > not > > > > something > > > > > >> we can change now :-) > > > > > > > > > > Kevin> FWIW, we've seen this before (GPIO connected to PMIC > reset > > > is > > > > a > > > > > Kevin> fun one), and this is why we have > > > > omap_hwmod_no_setup_reset(). > > > > > > > > > > Yes, but there's no dts bindings for this, and from a quick > test > > > the > > > > > reset handling happens before the device tree is probed. > > > > I have the same issue with TPS62361 on Palmas -> GPIO controls > the > > > > voltage register supplying MPU, without any driver setting things > up, > > > > GPIO gets reset and obviously voltage value switches to an > voltage > > > > where > > > > device does not function. > > > > > > > > Solution I am working on to solve this is [1]: snippet is part of > a > > > > patch that I am working on atm. > > > > > > > > This is the right way to do it IMHO. Will allow the driver to > exist > > > > when > > > > HWMOD will be eventually replaced by some other framework. > > > > > > > > > > > > [1]: http://pastebin.com/XPmAB1Zb > > > > > > > > > > > > > > Both seems to be different to me. What we need is to > > > Avoid reset of whole GPIO bank during kernel boot. > Yes - that is what the above does - as long as the GPIO is requested > and > set to the right level by the relevant driver, it is not "unused" and > hence not reset at late_init. > May be I am missing something here, Isn't _setup_reset() function asserts ocp_reset? And it is core_initcall. > I am a little unclear as to why this needs to have anything to do with > the precise under-lying mechanism (hwmod or something else). May be > "both seem to be different to me" needs a little further elaboration? > GPIO is connected to the DDR VTT control pin, and we have observed that Due to GPIO bank reset as part of hwmod init during bootup. > Is this because there is no need for an EMIF driver to handle DDR? and > reset of the GPIO will occur as EMIF is configured at bootloader and > there is no need to do that in kernel, correspondingly there is no > "driver" to hold the gpio? > > > > > > Ideally, it would have been much better if drivers starts handling > > > Idle, ocp reset and standby on their own (killing dependency on > hwmod > > > init layer). > > > > > > But looking at current state, > > > I agree we need to use DT property here, so how about > > > Adding DT property to GPIO node itself. But we have to parse > I believe you mean at OMAP specific DT property for hwmod? > something like ti,hwmod-no-init-reset? That’s the idea. > > > It early during hwmod init stage. We should read all DT nodes > > > Inside function __setup() function, that way can get rid of > > > HWMOD_INIT_NO_RESET flag completely. Also, this will handle > > > Both ocp_reset and domain reset. > > > > > > > Forgot to mention, > > > > Since this is kernel boot failure issue, I think, > > By the time we reach to conclusion, another approach is to > > set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank. > a) if the GPIO gets moved over to some other GPIO bank on another > platform, > this wont work Yes that’s true, but such schematic interface is not recommended. And we have not seen any known side-effect of not resetting GPIO0 bank. > b) for platforms that dont use gpio to hold DDR power, maybe this is > not > even relevant and the GPIO bank can safely be reset? > > As I mentioned, there is no known side-effect of not resetting GPIO bank 0. Thanks, Vaibhav -- 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 12:47-20130520, Hiremath, Vaibhav wrote: [...] > > > > > > > > > > On 20:10-20130517, Peter Korsgaard wrote: > > > > > > >>>>> "Kevin" == Kevin Hilman <khilman@linaro.org> writes: > > > > > > > > > > > > >> In this case, we cannot reset that bank, otherwise Starter > > Kit > > > > > will > > > > > > >> never boot in mainline. Bad PCB design, I know, but it's > > not > > > > > something > > > > > > >> we can change now :-) > > > > > > > > > > > > Kevin> FWIW, we've seen this before (GPIO connected to PMIC > > reset > > > > is > > > > > a > > > > > > Kevin> fun one), and this is why we have > > > > > omap_hwmod_no_setup_reset(). > > > > > > > > > > > > Yes, but there's no dts bindings for this, and from a quick > > test > > > > the > > > > > > reset handling happens before the device tree is probed. > > > > > I have the same issue with TPS62361 on Palmas -> GPIO controls > > the > > > > > voltage register supplying MPU, without any driver setting things > > up, > > > > > GPIO gets reset and obviously voltage value switches to an > > voltage > > > > > where > > > > > device does not function. > > > > > > > > > > Solution I am working on to solve this is [1]: snippet is part of > > a > > > > > patch that I am working on atm. > > > > > > > > > > This is the right way to do it IMHO. Will allow the driver to > > exist > > > > > when > > > > > HWMOD will be eventually replaced by some other framework. > > > > > > > > > > > > > > > [1]: http://pastebin.com/XPmAB1Zb > > > > > > > > > > > > > > > > > > Both seems to be different to me. What we need is to > > > > Avoid reset of whole GPIO bank during kernel boot. > > Yes - that is what the above does - as long as the GPIO is requested > > and > > set to the right level by the relevant driver, it is not "unused" and > > hence not reset at late_init. > > > > May be I am missing something here, > > Isn't _setup_reset() function asserts ocp_reset? And it is core_initcall. Hmm.. You are right, I missed that :( > > > I am a little unclear as to why this needs to have anything to do with > > the precise under-lying mechanism (hwmod or something else). May be > > "both seem to be different to me" needs a little further elaboration? > > > > GPIO is connected to the DDR VTT control pin, and we have observed that > Due to GPIO bank reset as part of hwmod init during bootup. > > > Is this because there is no need for an EMIF driver to handle DDR? and > > reset of the GPIO will occur as EMIF is configured at bootloader and > > there is no need to do that in kernel, correspondingly there is no > > "driver" to hold the gpio? > > > > > > > > Ideally, it would have been much better if drivers starts handling > > > > Idle, ocp reset and standby on their own (killing dependency on > > hwmod > > > > init layer). > > > > > > > > But looking at current state, > > > > I agree we need to use DT property here, so how about > > > > Adding DT property to GPIO node itself. But we have to parse > > I believe you mean at OMAP specific DT property for hwmod? > > something like ti,hwmod-no-init-reset? > > That’s the idea. > > > > > It early during hwmod init stage. We should read all DT nodes > > > > Inside function __setup() function, that way can get rid of > > > > HWMOD_INIT_NO_RESET flag completely. Also, this will handle > > > > Both ocp_reset and domain reset. > > > > > > > > > > Forgot to mention, > > > > > > Since this is kernel boot failure issue, I think, > > > By the time we reach to conclusion, another approach is to > > > set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank. > > a) if the GPIO gets moved over to some other GPIO bank on another > > platform, > > this wont work > > Yes that’s true, but such schematic interface is not recommended. > And we have not seen any known side-effect of not resetting GPIO0 bank. unless you mark the GPIO as taken, another driver could in-adverantly take over the GPIO and set it to a wrong level (we had a similar story with LED gpio between Panda Vs Panda-ES). > > > b) for platforms that dont use gpio to hold DDR power, maybe this is > > not > > even relevant and the GPIO bank can safely be reset? > > > > > As I mentioned, there is no known side-effect of not resetting GPIO bank 0. It should depend on the platform. There are other uses for hwmod-no-reset -> Eg. boot logo displayed by bootloader - if there is a reset of DSS block and re-configuration, we'd notice a blank-out, which is not desirable either. There could be a few other usage based on no-reset. In all cases, you'd prefer to make this: a) platform dependent (board dts) b) reserve GPIO as well so that no other driver'd take it - if they attempt ther'd at least be some form of warning.
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1lbm9uLCBOaXNoYW50aA0K PiBTZW50OiBNb25kYXksIE1heSAyMCwgMjAxMyAxMTozNCBQTQ0KPiBUbzogSGlyZW1hdGgsIFZh aWJoYXYNCj4gQ2M6IFBldGVyIEtvcnNnYWFyZDsgS2V2aW4gSGlsbWFuOyBCYWxiaSwgRmVsaXBl OyBQYXVsIFdhbG1zbGV5OyBsaW51eC0NCj4gb21hcEB2Z2VyLmtlcm5lbC5vcmc7IFRvbnkgTGlu ZGdyZW4NCj4gU3ViamVjdDogUmU6IHJlc2V0IGhhbmRsaW5nIGluIGFtMzM1eCBod21vZCBkYXRh DQo+IA0KPiBPbiAxMjo0Ny0yMDEzMDUyMCwgSGlyZW1hdGgsIFZhaWJoYXYgd3JvdGU6DQo+IFsu Li5dDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gT24gMjA6MTAtMjAxMzA1MTcsIFBldGVyIEtv cnNnYWFyZCB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPj4+Pj4gIktldmluIiA9PSBLZXZpbiBIaWxt YW4gPGtoaWxtYW5AbGluYXJvLm9yZz4gd3JpdGVzOg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiAgPj4gSW4gdGhpcyBjYXNlLCB3ZSBjYW5ub3QgcmVzZXQgdGhhdCBiYW5rLCBvdGhlcndp c2UNCj4gU3RhcnRlcg0KPiA+ID4gS2l0DQo+ID4gPiA+ID4gPiB3aWxsDQo+ID4gPiA+ID4gPiA+ ICA+PiBuZXZlciBib290IGluIG1haW5saW5lLiBCYWQgUENCIGRlc2lnbiwgSSBrbm93LCBidXQN Cj4gaXQncw0KPiA+ID4gbm90DQo+ID4gPiA+ID4gPiBzb21ldGhpbmcNCj4gPiA+ID4gPiA+ID4g ID4+IHdlIGNhbiBjaGFuZ2Ugbm93IDotKQ0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAg S2V2aW4+IEZXSVcsIHdlJ3ZlIHNlZW4gdGhpcyBiZWZvcmUgKEdQSU8gY29ubmVjdGVkIHRvDQo+ IFBNSUMNCj4gPiA+IHJlc2V0DQo+ID4gPiA+ID4gaXMNCj4gPiA+ID4gPiA+IGENCj4gPiA+ID4g PiA+ID4gIEtldmluPiBmdW4gb25lKSwgYW5kIHRoaXMgaXMgd2h5IHdlIGhhdmUNCj4gPiA+ID4g PiA+IG9tYXBfaHdtb2Rfbm9fc2V0dXBfcmVzZXQoKS4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+ID4gWWVzLCBidXQgdGhlcmUncyBubyBkdHMgYmluZGluZ3MgZm9yIHRoaXMsIGFuZCBmcm9t IGEgcXVpY2sNCj4gPiA+IHRlc3QNCj4gPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiA+ID4gcmVzZXQg aGFuZGxpbmcgaGFwcGVucyBiZWZvcmUgdGhlIGRldmljZSB0cmVlIGlzIHByb2JlZC4NCj4gPiA+ ID4gPiA+IEkgaGF2ZSB0aGUgc2FtZSBpc3N1ZSB3aXRoIFRQUzYyMzYxIG9uIFBhbG1hcyAtPiBH UElPDQo+IGNvbnRyb2xzDQo+ID4gPiB0aGUNCj4gPiA+ID4gPiA+IHZvbHRhZ2UgcmVnaXN0ZXIg c3VwcGx5aW5nIE1QVSwgd2l0aG91dCBhbnkgZHJpdmVyIHNldHRpbmcNCj4gdGhpbmdzDQo+ID4g PiB1cCwNCj4gPiA+ID4gPiA+IEdQSU8gZ2V0cyByZXNldCBhbmQgb2J2aW91c2x5IHZvbHRhZ2Ug dmFsdWUgc3dpdGNoZXMgdG8gYW4NCj4gPiA+IHZvbHRhZ2UNCj4gPiA+ID4gPiA+IHdoZXJlDQo+ ID4gPiA+ID4gPiBkZXZpY2UgZG9lcyBub3QgZnVuY3Rpb24uDQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gU29sdXRpb24gSSBhbSB3b3JraW5nIG9uIHRvIHNvbHZlIHRoaXMgaXMgWzFdOiBzbmlw cGV0IGlzDQo+IHBhcnQgb2YNCj4gPiA+IGENCj4gPiA+ID4gPiA+IHBhdGNoIHRoYXQgSSBhbSB3 b3JraW5nIG9uIGF0bS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBUaGlzIGlzIHRoZSByaWdo dCB3YXkgdG8gZG8gaXQgSU1ITy4gV2lsbCBhbGxvdyB0aGUgZHJpdmVyIHRvDQo+ID4gPiBleGlz dA0KPiA+ID4gPiA+ID4gd2hlbg0KPiA+ID4gPiA+ID4gSFdNT0Qgd2lsbCBiZSBldmVudHVhbGx5 IHJlcGxhY2VkIGJ5IHNvbWUgb3RoZXIgZnJhbWV3b3JrLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiBbMV06IGh0dHA6Ly9wYXN0ZWJpbi5jb20vWFBtQUIxWmINCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQm90aCBzZWVtcyB0byBi ZSBkaWZmZXJlbnQgdG8gbWUuIFdoYXQgd2UgbmVlZCBpcyB0bw0KPiA+ID4gPiA+IEF2b2lkIHJl c2V0IG9mIHdob2xlIEdQSU8gYmFuayBkdXJpbmcga2VybmVsIGJvb3QuDQo+ID4gPiBZZXMgLSB0 aGF0IGlzIHdoYXQgdGhlIGFib3ZlIGRvZXMgLSBhcyBsb25nIGFzIHRoZSBHUElPIGlzDQo+IHJl cXVlc3RlZA0KPiA+ID4gYW5kDQo+ID4gPiBzZXQgdG8gdGhlIHJpZ2h0IGxldmVsIGJ5IHRoZSBy ZWxldmFudCBkcml2ZXIsIGl0IGlzIG5vdCAidW51c2VkIg0KPiBhbmQNCj4gPiA+IGhlbmNlIG5v dCByZXNldCBhdCBsYXRlX2luaXQuDQo+ID4gPg0KPiA+DQo+ID4gTWF5IGJlIEkgYW0gbWlzc2lu ZyBzb21ldGhpbmcgaGVyZSwNCj4gPg0KPiA+IElzbid0IF9zZXR1cF9yZXNldCgpIGZ1bmN0aW9u IGFzc2VydHMgb2NwX3Jlc2V0PyBBbmQgaXQgaXMNCj4gY29yZV9pbml0Y2FsbC4NCj4gSG1tLi4g WW91IGFyZSByaWdodCwgSSBtaXNzZWQgdGhhdCA6KA0KPiA+DQo+ID4gPiBJIGFtIGEgbGl0dGxl IHVuY2xlYXIgYXMgdG8gd2h5IHRoaXMgbmVlZHMgdG8gaGF2ZSBhbnl0aGluZyB0byBkbw0KPiB3 aXRoDQo+ID4gPiB0aGUgcHJlY2lzZSB1bmRlci1seWluZyBtZWNoYW5pc20gKGh3bW9kIG9yIHNv bWV0aGluZyBlbHNlKS4gTWF5IGJlDQo+ID4gPiAiYm90aCBzZWVtIHRvIGJlIGRpZmZlcmVudCB0 byBtZSIgbmVlZHMgYSBsaXR0bGUgZnVydGhlcg0KPiBlbGFib3JhdGlvbj8NCj4gPiA+DQo+ID4N Cj4gPiBHUElPIGlzIGNvbm5lY3RlZCB0byB0aGUgRERSIFZUVCBjb250cm9sIHBpbiwgYW5kIHdl IGhhdmUgb2JzZXJ2ZWQNCj4gdGhhdA0KPiA+IER1ZSB0byBHUElPIGJhbmsgcmVzZXQgYXMgcGFy dCBvZiBod21vZCBpbml0IGR1cmluZyBib290dXAuDQo+ID4NCj4gPiA+IElzIHRoaXMgYmVjYXVz ZSB0aGVyZSBpcyBubyBuZWVkIGZvciBhbiBFTUlGIGRyaXZlciB0byBoYW5kbGUgRERSPw0KPiBh bmQNCj4gPiA+IHJlc2V0IG9mIHRoZSBHUElPIHdpbGwgb2NjdXIgYXMgRU1JRiBpcyBjb25maWd1 cmVkIGF0IGJvb3Rsb2FkZXINCj4gYW5kDQo+ID4gPiB0aGVyZSBpcyBubyBuZWVkIHRvIGRvIHRo YXQgaW4ga2VybmVsLCBjb3JyZXNwb25kaW5nbHkgdGhlcmUgaXMgbm8NCj4gPiA+ICJkcml2ZXIi IHRvIGhvbGQgdGhlIGdwaW8/DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJZGVhbGx5LCBpdCB3b3Vs ZCBoYXZlIGJlZW4gbXVjaCBiZXR0ZXIgaWYgZHJpdmVycyBzdGFydHMNCj4gaGFuZGxpbmcNCj4g PiA+ID4gPiBJZGxlLCBvY3AgcmVzZXQgYW5kIHN0YW5kYnkgb24gdGhlaXIgb3duIChraWxsaW5n IGRlcGVuZGVuY3kgb24NCj4gPiA+IGh3bW9kDQo+ID4gPiA+ID4gaW5pdCBsYXllcikuDQo+ID4g PiA+ID4NCj4gPiA+ID4gPiBCdXQgbG9va2luZyBhdCBjdXJyZW50IHN0YXRlLA0KPiA+ID4gPiA+ IEkgYWdyZWUgd2UgbmVlZCB0byB1c2UgRFQgcHJvcGVydHkgaGVyZSwgc28gaG93IGFib3V0DQo+ ID4gPiA+ID4gQWRkaW5nIERUIHByb3BlcnR5ICB0byBHUElPIG5vZGUgaXRzZWxmLiBCdXQgd2Ug aGF2ZSB0byBwYXJzZQ0KPiA+ID4gSSBiZWxpZXZlIHlvdSBtZWFuIGF0IE9NQVAgc3BlY2lmaWMg IERUIHByb3BlcnR5IGZvciBod21vZD8NCj4gPiA+IHNvbWV0aGluZyBsaWtlIHRpLGh3bW9kLW5v LWluaXQtcmVzZXQ/DQo+ID4NCj4gPiBUaGF04oCZcyB0aGUgaWRlYS4NCj4gPg0KPiA+ID4gPiA+ IEl0IGVhcmx5IGR1cmluZyBod21vZCBpbml0IHN0YWdlLiBXZSBzaG91bGQgcmVhZCBhbGwgRFQg bm9kZXMNCj4gPiA+ID4gPiBJbnNpZGUgZnVuY3Rpb24gX19zZXR1cCgpIGZ1bmN0aW9uLCB0aGF0 IHdheSBjYW4gZ2V0IHJpZCBvZg0KPiA+ID4gPiA+IEhXTU9EX0lOSVRfTk9fUkVTRVQgZmxhZyBj b21wbGV0ZWx5LiBBbHNvLCB0aGlzIHdpbGwgaGFuZGxlDQo+ID4gPiA+ID4gQm90aCBvY3BfcmVz ZXQgYW5kIGRvbWFpbiByZXNldC4NCj4gPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBGb3Jnb3Qg dG8gbWVudGlvbiwNCj4gPiA+ID4NCj4gPiA+ID4gU2luY2UgdGhpcyBpcyBrZXJuZWwgYm9vdCBm YWlsdXJlIGlzc3VlLCBJIHRoaW5rLA0KPiA+ID4gPiBCeSB0aGUgdGltZSB3ZSByZWFjaCB0byBj b25jbHVzaW9uLCBhbm90aGVyIGFwcHJvYWNoIGlzIHRvDQo+ID4gPiA+IHNldCAiSFdNT0RfSU5J VF9OT19SRVNFVCIgZmxhZyBGb3IgR1BJTzAgYmFuay4NCj4gPiA+IGEpIGlmIHRoZSBHUElPIGdl dHMgbW92ZWQgb3ZlciB0byBzb21lIG90aGVyIEdQSU8gYmFuayBvbiBhbm90aGVyDQo+ID4gPiBw bGF0Zm9ybSwNCj4gPiA+IHRoaXMgd29udCB3b3JrDQo+ID4NCj4gPiBZZXMgdGhhdOKAmXMgdHJ1 ZSwgYnV0IHN1Y2ggc2NoZW1hdGljIGludGVyZmFjZSBpcyBub3QgcmVjb21tZW5kZWQuDQo+ID4g QW5kIHdlIGhhdmUgbm90IHNlZW4gYW55IGtub3duIHNpZGUtZWZmZWN0IG9mIG5vdCByZXNldHRp bmcgR1BJTzANCj4gYmFuay4NCj4gdW5sZXNzIHlvdSBtYXJrIHRoZSBHUElPIGFzIHRha2VuLCBh bm90aGVyIGRyaXZlciBjb3VsZCBpbi1hZHZlcmFudGx5DQo+IHRha2Ugb3ZlciB0aGUgR1BJTyBh bmQgc2V0IGl0IHRvIGEgd3JvbmcgbGV2ZWwgKHdlIGhhZCBhIHNpbWlsYXIgc3RvcnkNCj4gd2l0 aCBMRUQgZ3BpbyBiZXR3ZWVuIFBhbmRhIFZzIFBhbmRhLUVTKS4NCj4gDQo+ID4NCj4gPiA+IGIp IGZvciBwbGF0Zm9ybXMgdGhhdCBkb250IHVzZSBncGlvIHRvIGhvbGQgRERSIHBvd2VyLCBtYXli ZSB0aGlzDQo+IGlzDQo+ID4gPiBub3QNCj4gPiA+IGV2ZW4gcmVsZXZhbnQgYW5kIHRoZSBHUElP IGJhbmsgY2FuIHNhZmVseSBiZSByZXNldD8NCj4gPiA+ID4NCj4gPg0KPiA+IEFzIEkgbWVudGlv bmVkLCB0aGVyZSBpcyBubyBrbm93biBzaWRlLWVmZmVjdCBvZiBub3QgcmVzZXR0aW5nIEdQSU8N Cj4gYmFuayAwLg0KPiBJdCBzaG91bGQgZGVwZW5kIG9uIHRoZSBwbGF0Zm9ybS4NCj4gDQo+IFRo ZXJlIGFyZSBvdGhlciB1c2VzIGZvciBod21vZC1uby1yZXNldCAtPiBFZy4gYm9vdCBsb2dvIGRp c3BsYXllZCBieQ0KPiBib290bG9hZGVyIC0gaWYgdGhlcmUgaXMgYSByZXNldCBvZiBEU1MgYmxv Y2sgYW5kIHJlLWNvbmZpZ3VyYXRpb24sDQo+IHdlJ2QNCj4gbm90aWNlIGEgYmxhbmstb3V0LCB3 aGljaCBpcyBub3QgZGVzaXJhYmxlIGVpdGhlci4gVGhlcmUgY291bGQgYmUgYSBmZXcNCj4gb3Ro ZXIgdXNhZ2UgYmFzZWQgb24gbm8tcmVzZXQuDQo+IA0KPiBJbiBhbGwgY2FzZXMsIHlvdSdkIHBy ZWZlciB0byBtYWtlIHRoaXM6DQo+IGEpIHBsYXRmb3JtIGRlcGVuZGVudCAoYm9hcmQgZHRzKQ0K PiBiKSByZXNlcnZlIEdQSU8gYXMgd2VsbCBzbyB0aGF0IG5vIG90aGVyIGRyaXZlcidkIHRha2Ug aXQgLSBpZiB0aGV5DQo+IGF0dGVtcHQgdGhlcidkIGF0IGxlYXN0IGJlIHNvbWUgZm9ybSBvZiB3 YXJuaW5nLg0KPiANCkNvbXBsZXRlbHkgYWdyZWUgd2l0aCB5b3Ugb24gYm90aCB0aGUgcG9pbnRz LCBhbmQgbXkgcG9pbnQgYW5kIGFsbCBteSBjb21tZW50cw0KV2VyZSBtb3JlIHJlbGF0ZWQgdG8g b3B0aW9uICdhJyBhYm92ZS4NCg0KVGhhbmtzLA0KVmFpYmhhdg0K -- 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
Hi, On Mon, May 20, 2013 at 08:20:29PM +0200, Hiremath, Vaibhav wrote: > > > -----Original Message----- > > From: Menon, Nishanth > > Sent: Monday, May 20, 2013 11:34 PM > > To: Hiremath, Vaibhav > > Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- > > omap@vger.kernel.org; Tony Lindgren > > Subject: Re: reset handling in am335x hwmod data > > > > On 12:47-20130520, Hiremath, Vaibhav wrote: > > [...] > > > > > > > > > > > > > > On 20:10-20130517, Peter Korsgaard wrote: > > > > > > > > >>>>> "Kevin" == Kevin Hilman <khilman@linaro.org> writes: > > > > > > > > > > > > > > > > >> In this case, we cannot reset that bank, otherwise > > Starter > > > > Kit > > > > > > > will > > > > > > > > >> never boot in mainline. Bad PCB design, I know, but > > it's > > > > not > > > > > > > something > > > > > > > > >> we can change now :-) > > > > > > > > > > > > > > > > Kevin> FWIW, we've seen this before (GPIO connected to > > PMIC > > > > reset > > > > > > is > > > > > > > a > > > > > > > > Kevin> fun one), and this is why we have > > > > > > > omap_hwmod_no_setup_reset(). > > > > > > > > > > > > > > > > Yes, but there's no dts bindings for this, and from a quick > > > > test > > > > > > the > > > > > > > > reset handling happens before the device tree is probed. > > > > > > > I have the same issue with TPS62361 on Palmas -> GPIO > > controls > > > > the > > > > > > > voltage register supplying MPU, without any driver setting > > things > > > > up, > > > > > > > GPIO gets reset and obviously voltage value switches to an > > > > voltage > > > > > > > where > > > > > > > device does not function. > > > > > > > > > > > > > > Solution I am working on to solve this is [1]: snippet is > > part of > > > > a > > > > > > > patch that I am working on atm. > > > > > > > > > > > > > > This is the right way to do it IMHO. Will allow the driver to > > > > exist > > > > > > > when > > > > > > > HWMOD will be eventually replaced by some other framework. > > > > > > > > > > > > > > > > > > > > > [1]: http://pastebin.com/XPmAB1Zb > > > > > > > > > > > > > > > > > > > > > > > > > > Both seems to be different to me. What we need is to > > > > > > Avoid reset of whole GPIO bank during kernel boot. > > > > Yes - that is what the above does - as long as the GPIO is > > requested > > > > and > > > > set to the right level by the relevant driver, it is not "unused" > > and > > > > hence not reset at late_init. > > > > > > > > > > May be I am missing something here, > > > > > > Isn't _setup_reset() function asserts ocp_reset? And it is > > core_initcall. > > Hmm.. You are right, I missed that :( > > > > > > > I am a little unclear as to why this needs to have anything to do > > with > > > > the precise under-lying mechanism (hwmod or something else). May be > > > > "both seem to be different to me" needs a little further > > elaboration? > > > > > > > > > > GPIO is connected to the DDR VTT control pin, and we have observed > > that > > > Due to GPIO bank reset as part of hwmod init during bootup. > > > > > > > Is this because there is no need for an EMIF driver to handle DDR? > > and > > > > reset of the GPIO will occur as EMIF is configured at bootloader > > and > > > > there is no need to do that in kernel, correspondingly there is no > > > > "driver" to hold the gpio? > > > > > > > > > > > > Ideally, it would have been much better if drivers starts > > handling > > > > > > Idle, ocp reset and standby on their own (killing dependency on > > > > hwmod > > > > > > init layer). > > > > > > > > > > > > But looking at current state, > > > > > > I agree we need to use DT property here, so how about > > > > > > Adding DT property to GPIO node itself. But we have to parse > > > > I believe you mean at OMAP specific DT property for hwmod? > > > > something like ti,hwmod-no-init-reset? > > > > > > That’s the idea. > > > > > > > > > It early during hwmod init stage. We should read all DT nodes > > > > > > Inside function __setup() function, that way can get rid of > > > > > > HWMOD_INIT_NO_RESET flag completely. Also, this will handle > > > > > > Both ocp_reset and domain reset. > > > > > > > > > > > > > > > > Forgot to mention, > > > > > > > > > > Since this is kernel boot failure issue, I think, > > > > > By the time we reach to conclusion, another approach is to > > > > > set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank. > > > > a) if the GPIO gets moved over to some other GPIO bank on another > > > > platform, > > > > this wont work > > > > > > Yes that’s true, but such schematic interface is not recommended. > > > And we have not seen any known side-effect of not resetting GPIO0 > > bank. > > unless you mark the GPIO as taken, another driver could in-adverantly > > take over the GPIO and set it to a wrong level (we had a similar story > > with LED gpio between Panda Vs Panda-ES). > > > > > > > > > b) for platforms that dont use gpio to hold DDR power, maybe this > > is > > > > not > > > > even relevant and the GPIO bank can safely be reset? > > > > > > > > > > > As I mentioned, there is no known side-effect of not resetting GPIO > > bank 0. > > It should depend on the platform. > > > > There are other uses for hwmod-no-reset -> Eg. boot logo displayed by > > bootloader - if there is a reset of DSS block and re-configuration, > > we'd > > notice a blank-out, which is not desirable either. There could be a few > > other usage based on no-reset. > > > > In all cases, you'd prefer to make this: > > a) platform dependent (board dts) > > b) reserve GPIO as well so that no other driver'd take it - if they > > attempt ther'd at least be some form of warning. > > > Completely agree with you on both the points, and my point and all my comments > Were more related to option 'a' above. so, what happened here ? Will we not have AM335x-SK working in mainline just because of the GPIO block being reset ?
> -----Original Message----- > From: Balbi, Felipe > Sent: Friday, June 28, 2013 4:24 PM > To: Hiremath, Vaibhav > Cc: Menon, Nishanth; Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul > Walmsley; linux-omap@vger.kernel.org; Tony Lindgren; Sebastian Andrzej > Siewior > Subject: Re: reset handling in am335x hwmod data > > Hi, > > On Mon, May 20, 2013 at 08:20:29PM +0200, Hiremath, Vaibhav wrote: > > > > > -----Original Message----- > > > From: Menon, Nishanth > > > Sent: Monday, May 20, 2013 11:34 PM > > > To: Hiremath, Vaibhav > > > Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; > linux- > > > omap@vger.kernel.org; Tony Lindgren > > > Subject: Re: reset handling in am335x hwmod data > > > > > > On 12:47-20130520, Hiremath, Vaibhav wrote: > > > [...] > > > > > > > > > > > > > > > > On 20:10-20130517, Peter Korsgaard wrote: > > > > > > > > > >>>>> "Kevin" == Kevin Hilman <khilman@linaro.org> > writes: > > > > > > > > > > > > > > > > > > >> In this case, we cannot reset that bank, otherwise > > > Starter > > > > > Kit > > > > > > > > will > > > > > > > > > >> never boot in mainline. Bad PCB design, I know, but > > > it's > > > > > not > > > > > > > > something > > > > > > > > > >> we can change now :-) > > > > > > > > > > > > > > > > > > Kevin> FWIW, we've seen this before (GPIO connected to > > > PMIC > > > > > reset > > > > > > > is > > > > > > > > a > > > > > > > > > Kevin> fun one), and this is why we have > > > > > > > > omap_hwmod_no_setup_reset(). > > > > > > > > > > > > > > > > > > Yes, but there's no dts bindings for this, and from a > quick > > > > > test > > > > > > > the > > > > > > > > > reset handling happens before the device tree is > probed. > > > > > > > > I have the same issue with TPS62361 on Palmas -> GPIO > > > controls > > > > > the > > > > > > > > voltage register supplying MPU, without any driver > setting > > > things > > > > > up, > > > > > > > > GPIO gets reset and obviously voltage value switches to > an > > > > > voltage > > > > > > > > where > > > > > > > > device does not function. > > > > > > > > > > > > > > > > Solution I am working on to solve this is [1]: snippet is > > > part of > > > > > a > > > > > > > > patch that I am working on atm. > > > > > > > > > > > > > > > > This is the right way to do it IMHO. Will allow the > driver to > > > > > exist > > > > > > > > when > > > > > > > > HWMOD will be eventually replaced by some other > framework. > > > > > > > > > > > > > > > > > > > > > > > > [1]: http://pastebin.com/XPmAB1Zb > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Both seems to be different to me. What we need is to > > > > > > > Avoid reset of whole GPIO bank during kernel boot. > > > > > Yes - that is what the above does - as long as the GPIO is > > > requested > > > > > and > > > > > set to the right level by the relevant driver, it is not > "unused" > > > and > > > > > hence not reset at late_init. > > > > > > > > > > > > > May be I am missing something here, > > > > > > > > Isn't _setup_reset() function asserts ocp_reset? And it is > > > core_initcall. > > > Hmm.. You are right, I missed that :( > > > > > > > > > I am a little unclear as to why this needs to have anything to > do > > > with > > > > > the precise under-lying mechanism (hwmod or something else). > May be > > > > > "both seem to be different to me" needs a little further > > > elaboration? > > > > > > > > > > > > > GPIO is connected to the DDR VTT control pin, and we have > observed > > > that > > > > Due to GPIO bank reset as part of hwmod init during bootup. > > > > > > > > > Is this because there is no need for an EMIF driver to handle > DDR? > > > and > > > > > reset of the GPIO will occur as EMIF is configured at > bootloader > > > and > > > > > there is no need to do that in kernel, correspondingly there is > no > > > > > "driver" to hold the gpio? > > > > > > > > > > > > > > Ideally, it would have been much better if drivers starts > > > handling > > > > > > > Idle, ocp reset and standby on their own (killing > dependency on > > > > > hwmod > > > > > > > init layer). > > > > > > > > > > > > > > But looking at current state, > > > > > > > I agree we need to use DT property here, so how about > > > > > > > Adding DT property to GPIO node itself. But we have to > parse > > > > > I believe you mean at OMAP specific DT property for hwmod? > > > > > something like ti,hwmod-no-init-reset? > > > > > > > > That’s the idea. > > > > > > > > > > > It early during hwmod init stage. We should read all DT > nodes > > > > > > > Inside function __setup() function, that way can get rid of > > > > > > > HWMOD_INIT_NO_RESET flag completely. Also, this will handle > > > > > > > Both ocp_reset and domain reset. > > > > > > > > > > > > > > > > > > > Forgot to mention, > > > > > > > > > > > > Since this is kernel boot failure issue, I think, > > > > > > By the time we reach to conclusion, another approach is to > > > > > > set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank. > > > > > a) if the GPIO gets moved over to some other GPIO bank on > another > > > > > platform, > > > > > this wont work > > > > > > > > Yes that’s true, but such schematic interface is not recommended. > > > > And we have not seen any known side-effect of not resetting GPIO0 > > > bank. > > > unless you mark the GPIO as taken, another driver could in- > adverantly > > > take over the GPIO and set it to a wrong level (we had a similar > story > > > with LED gpio between Panda Vs Panda-ES). > > > > > > > > > > > > b) for platforms that dont use gpio to hold DDR power, maybe > this > > > is > > > > > not > > > > > even relevant and the GPIO bank can safely be reset? > > > > > > > > > > > > > > As I mentioned, there is no known side-effect of not resetting > GPIO > > > bank 0. > > > It should depend on the platform. > > > > > > There are other uses for hwmod-no-reset -> Eg. boot logo displayed > by > > > bootloader - if there is a reset of DSS block and re-configuration, > > > we'd > > > notice a blank-out, which is not desirable either. There could be a > few > > > other usage based on no-reset. > > > > > > In all cases, you'd prefer to make this: > > > a) platform dependent (board dts) > > > b) reserve GPIO as well so that no other driver'd take it - if they > > > attempt ther'd at least be some form of warning. > > > > > Completely agree with you on both the points, and my point and all my > comments > > Were more related to option 'a' above. > > so, what happened here ? Will we not have AM335x-SK working in mainline > just because of the GPIO block being reset ? > Nishant started implementing on this, not sure what state it is in. Thanks, Vaibhav
On 07/01/2013 11:37 PM, Hiremath, Vaibhav wrote: > >> -----Original Message----- >> From: Balbi, Felipe >> Sent: Friday, June 28, 2013 4:24 PM >> To: Hiremath, Vaibhav >> Cc: Menon, Nishanth; Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul >> Walmsley; linux-omap@vger.kernel.org; Tony Lindgren; Sebastian Andrzej >> Siewior >> Subject: Re: reset handling in am335x hwmod data >> >> Hi, >> >> On Mon, May 20, 2013 at 08:20:29PM +0200, Hiremath, Vaibhav wrote: >>> >>>> -----Original Message----- >>>> From: Menon, Nishanth >>>> Sent: Monday, May 20, 2013 11:34 PM >>>> To: Hiremath, Vaibhav >>>> Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; >> linux- >>>> omap@vger.kernel.org; Tony Lindgren >>>> Subject: Re: reset handling in am335x hwmod data >>>> >>>> On 12:47-20130520, Hiremath, Vaibhav wrote: >>>> [...] >>>>>>>>> >>>>>>>>> On 20:10-20130517, Peter Korsgaard wrote: >>>>>>>>>>>>>>> "Kevin" == Kevin Hilman <khilman@linaro.org> >> writes: >>>>>>>>>> >>>>>>>>>> >> In this case, we cannot reset that bank, otherwise >>>> Starter >>>>>> Kit >>>>>>>>> will >>>>>>>>>> >> never boot in mainline. Bad PCB design, I know, but >>>> it's >>>>>> not >>>>>>>>> something >>>>>>>>>> >> we can change now :-) >>>>>>>>>> >>>>>>>>>> Kevin> FWIW, we've seen this before (GPIO connected to >>>> PMIC >>>>>> reset >>>>>>>> is >>>>>>>>> a >>>>>>>>>> Kevin> fun one), and this is why we have >>>>>>>>> omap_hwmod_no_setup_reset(). >>>>>>>>>> >>>>>>>>>> Yes, but there's no dts bindings for this, and from a >> quick >>>>>> test >>>>>>>> the >>>>>>>>>> reset handling happens before the device tree is >> probed. >>>>>>>>> I have the same issue with TPS62361 on Palmas -> GPIO >>>> controls >>>>>> the >>>>>>>>> voltage register supplying MPU, without any driver >> setting >>>> things >>>>>> up, >>>>>>>>> GPIO gets reset and obviously voltage value switches to >> an >>>>>> voltage >>>>>>>>> where >>>>>>>>> device does not function. >>>>>>>>> >>>>>>>>> Solution I am working on to solve this is [1]: snippet is >>>> part of >>>>>> a >>>>>>>>> patch that I am working on atm. >>>>>>>>> >>>>>>>>> This is the right way to do it IMHO. Will allow the >> driver to >>>>>> exist >>>>>>>>> when >>>>>>>>> HWMOD will be eventually replaced by some other >> framework. >>>>>>>>> >>>>>>>>> >>>>>>>>> [1]: http://pastebin.com/XPmAB1Zb >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Both seems to be different to me. What we need is to >>>>>>>> Avoid reset of whole GPIO bank during kernel boot. >>>>>> Yes - that is what the above does - as long as the GPIO is >>>> requested >>>>>> and >>>>>> set to the right level by the relevant driver, it is not >> "unused" >>>> and >>>>>> hence not reset at late_init. >>>>>> >>>>> >>>>> May be I am missing something here, >>>>> >>>>> Isn't _setup_reset() function asserts ocp_reset? And it is >>>> core_initcall. >>>> Hmm.. You are right, I missed that :( >>>>> >>>>>> I am a little unclear as to why this needs to have anything to >> do >>>> with >>>>>> the precise under-lying mechanism (hwmod or something else). >> May be >>>>>> "both seem to be different to me" needs a little further >>>> elaboration? >>>>>> >>>>> >>>>> GPIO is connected to the DDR VTT control pin, and we have >> observed >>>> that >>>>> Due to GPIO bank reset as part of hwmod init during bootup. >>>>> >>>>>> Is this because there is no need for an EMIF driver to handle >> DDR? >>>> and >>>>>> reset of the GPIO will occur as EMIF is configured at >> bootloader >>>> and >>>>>> there is no need to do that in kernel, correspondingly there is >> no >>>>>> "driver" to hold the gpio? >>>>>>>> >>>>>>>> Ideally, it would have been much better if drivers starts >>>> handling >>>>>>>> Idle, ocp reset and standby on their own (killing >> dependency on >>>>>> hwmod >>>>>>>> init layer). >>>>>>>> >>>>>>>> But looking at current state, >>>>>>>> I agree we need to use DT property here, so how about >>>>>>>> Adding DT property to GPIO node itself. But we have to >> parse >>>>>> I believe you mean at OMAP specific DT property for hwmod? >>>>>> something like ti,hwmod-no-init-reset? >>>>> >>>>> That’s the idea. >>>>> >>>>>>>> It early during hwmod init stage. We should read all DT >> nodes >>>>>>>> Inside function __setup() function, that way can get rid of >>>>>>>> HWMOD_INIT_NO_RESET flag completely. Also, this will handle >>>>>>>> Both ocp_reset and domain reset. >>>>>>>> >>>>>>> >>>>>>> Forgot to mention, >>>>>>> >>>>>>> Since this is kernel boot failure issue, I think, >>>>>>> By the time we reach to conclusion, another approach is to >>>>>>> set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank. >>>>>> a) if the GPIO gets moved over to some other GPIO bank on >> another >>>>>> platform, >>>>>> this wont work >>>>> >>>>> Yes that’s true, but such schematic interface is not recommended. >>>>> And we have not seen any known side-effect of not resetting GPIO0 >>>> bank. >>>> unless you mark the GPIO as taken, another driver could in- >> adverantly >>>> take over the GPIO and set it to a wrong level (we had a similar >> story >>>> with LED gpio between Panda Vs Panda-ES). >>>> >>>>> >>>>>> b) for platforms that dont use gpio to hold DDR power, maybe >> this >>>> is >>>>>> not >>>>>> even relevant and the GPIO bank can safely be reset? >>>>>>> >>>>> >>>>> As I mentioned, there is no known side-effect of not resetting >> GPIO >>>> bank 0. >>>> It should depend on the platform. >>>> >>>> There are other uses for hwmod-no-reset -> Eg. boot logo displayed >> by >>>> bootloader - if there is a reset of DSS block and re-configuration, >>>> we'd >>>> notice a blank-out, which is not desirable either. There could be a >> few >>>> other usage based on no-reset. >>>> >>>> In all cases, you'd prefer to make this: >>>> a) platform dependent (board dts) >>>> b) reserve GPIO as well so that no other driver'd take it - if they >>>> attempt ther'd at least be some form of warning. >>>> >>> Completely agree with you on both the points, and my point and all my >> comments >>> Were more related to option 'a' above. >> >> so, what happened here ? Will we not have AM335x-SK working in mainline >> just because of the GPIO block being reset ? >> > > Nishant started implementing on this, not sure what state it is in. Nope. I am not working on this.
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c @@ -992,7 +992,7 @@ static struct omap_hwmod am33xx_gpio1_hwmod = { .name = "gpio2", .class = &am33xx_gpio_hwmod_class, .clkdm_name = "l4ls_clkdm", - .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET, + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET), .mpu_irqs = am33xx_gpio1_irqs, .main_clk = "l4ls_gclk", .prcm = {