| Message ID | 1337953588-20696-5-git-send-email-thierry.reding@avionic-design.de |
|---|---|
| State | Accepted |
| Delegated to: | Tom Warren |
| Headers | show |
On 05/25/2012 07:46 AM, Thierry Reding wrote: > The PI4 GPIO is used on Tamonten to reset carrier board peripherals. > Power sequencing hardware on the carrier pulls the reset low before > powering up the Tegra, and the CPU is supposed to signal readiness, > and therefore bring peripherals out of reset by pulling PI4 high. > +void gpio_early_init(void) > +{ > + gpio_request(GPIO_PI4, NULL); > + gpio_direction_output(GPIO_PI4, 1); > + gpio_free(GPIO_PI4); > +} Do you really mean to free the GPIO here? While gpio_free() does not do this at present, it seems perfectly reasonable for someone to modify gpio_free() so that instead of leaving the HW in some random state when free, it actively reprograms the pin to be an input instead, since that's the most conflict-free setting when the pin is actively unused.
* Stephen Warren wrote: > On 05/25/2012 07:46 AM, Thierry Reding wrote: > > The PI4 GPIO is used on Tamonten to reset carrier board peripherals. > > Power sequencing hardware on the carrier pulls the reset low before > > powering up the Tegra, and the CPU is supposed to signal readiness, > > and therefore bring peripherals out of reset by pulling PI4 high. > > > +void gpio_early_init(void) > > +{ > > + gpio_request(GPIO_PI4, NULL); > > + gpio_direction_output(GPIO_PI4, 1); > > + gpio_free(GPIO_PI4); > > +} > > Do you really mean to free the GPIO here? > > While gpio_free() does not do this at present, it seems perfectly > reasonable for someone to modify gpio_free() so that instead of leaving > the HW in some random state when free, it actively reprograms the pin to > be an input instead, since that's the most conflict-free setting when > the pin is actively unused. I believe that even a pulse would be enough for the undelying mechanisms to take effect, but I'll have to check with our hardware engineers to be sure. You're probably right, though, that keeping it requested until control is handed over to the kernel may be safer. I'll update the patch. Thierry
Hi Thierry, On 25.05.2012 19:40, Thierry Reding wrote: > * Stephen Warren wrote: >> On 05/25/2012 07:46 AM, Thierry Reding wrote: >> > The PI4 GPIO is used on Tamonten to reset carrier board peripherals. >> > Power sequencing hardware on the carrier pulls the reset low before >> > powering up the Tegra, and the CPU is supposed to signal readiness, >> > and therefore bring peripherals out of reset by pulling PI4 high. >> >> > +void gpio_early_init(void) >> > +{ >> > + gpio_request(GPIO_PI4, NULL); >> > + gpio_direction_output(GPIO_PI4, 1); >> > + gpio_free(GPIO_PI4); >> > +} >> >> Do you really mean to free the GPIO here? >> >> While gpio_free() does not do this at present, it seems perfectly >> reasonable for someone to modify gpio_free() so that instead of leaving >> the HW in some random state when free, it actively reprograms the pin to >> be an input instead, since that's the most conflict-free setting when >> the pin is actively unused. > > I believe that even a pulse would be enough for the undelying mechanisms to > take effect, but I'll have to check with our hardware engineers to be sure. As an aside: A pulse wont be enough in this specific case as a pull-down on the carrier would lead to the nRST going low thus resetting the baseboard peripherals. Plus there is a status LED on the Tamonten Evaluation carrier that would then indicate the red "system not up". Cheers, Kai
* Kai Poggensee wrote: > > Hi Thierry, > > On 25.05.2012 19:40, Thierry Reding wrote: > > * Stephen Warren wrote: > >> On 05/25/2012 07:46 AM, Thierry Reding wrote: > >> > The PI4 GPIO is used on Tamonten to reset carrier board peripherals. > >> > Power sequencing hardware on the carrier pulls the reset low before > >> > powering up the Tegra, and the CPU is supposed to signal readiness, > >> > and therefore bring peripherals out of reset by pulling PI4 high. > >> > >> > +void gpio_early_init(void) > >> > +{ > >> > + gpio_request(GPIO_PI4, NULL); > >> > + gpio_direction_output(GPIO_PI4, 1); > >> > + gpio_free(GPIO_PI4); > >> > +} > >> > >> Do you really mean to free the GPIO here? > >> > >> While gpio_free() does not do this at present, it seems perfectly > >> reasonable for someone to modify gpio_free() so that instead of leaving > >> the HW in some random state when free, it actively reprograms the pin to > >> be an input instead, since that's the most conflict-free setting when > >> the pin is actively unused. > > > > I believe that even a pulse would be enough for the undelying mechanisms to > > take effect, but I'll have to check with our hardware engineers to be sure. > > As an aside: A pulse wont be enough in this specific case > as a pull-down on the carrier would lead to the nRST going > low thus resetting the baseboard peripherals. > > Plus there is a status LED on the Tamonten Evaluation carrier > that would then indicate the red "system not up". So this means we'll have to hand this over to the kernel somehow. Stephen, I'm not aware of any mechanism to pass static GPIO configuration via the FDT. Are there any plans to add something like it? The problem I see is that the pinmux binding might reconfigure the corresponding pin and therefore reset the peripherals. Thierry
On 05/29/2012 08:57 AM, Thierry Reding wrote: > * Kai Poggensee wrote: >> >> Hi Thierry, >> >> On 25.05.2012 19:40, Thierry Reding wrote: >>> * Stephen Warren wrote: >>>> On 05/25/2012 07:46 AM, Thierry Reding wrote: >>>>> The PI4 GPIO is used on Tamonten to reset carrier board >>>>> peripherals. Power sequencing hardware on the carrier pulls >>>>> the reset low before powering up the Tegra, and the CPU is >>>>> supposed to signal readiness, and therefore bring >>>>> peripherals out of reset by pulling PI4 high. >>>> >>>>> +void gpio_early_init(void) +{ + gpio_request(GPIO_PI4, >>>>> NULL); + gpio_direction_output(GPIO_PI4, 1); + >>>>> gpio_free(GPIO_PI4); +} >>>> >>>> Do you really mean to free the GPIO here? >>>> >>>> While gpio_free() does not do this at present, it seems >>>> perfectly reasonable for someone to modify gpio_free() so >>>> that instead of leaving the HW in some random state when >>>> free, it actively reprograms the pin to be an input instead, >>>> since that's the most conflict-free setting when the pin is >>>> actively unused. >>> >>> I believe that even a pulse would be enough for the undelying >>> mechanisms to take effect, but I'll have to check with our >>> hardware engineers to be sure. >> >> As an aside: A pulse wont be enough in this specific case as a >> pull-down on the carrier would lead to the nRST going low thus >> resetting the baseboard peripherals. >> >> Plus there is a status LED on the Tamonten Evaluation carrier >> that would then indicate the red "system not up". > > So this means we'll have to hand this over to the kernel somehow. > Stephen, I'm not aware of any mechanism to pass static GPIO > configuration via the FDT. Are there any plans to add something > like it? The problem I see is that the pinmux binding might > reconfigure the corresponding pin and therefore reset the > peripherals. The pinctrl and GPIO drivers will only reconfigure groups/pins they're asked to, so I don't believe there will be any problem here, assuming the DT contains tables that are correct.
diff --git a/board/avionic-design/common/tamonten.c b/board/avionic-design/common/tamonten.c index d9ecd23..2b19d1e 100644 --- a/board/avionic-design/common/tamonten.c +++ b/board/avionic-design/common/tamonten.c @@ -49,6 +49,15 @@ void gpio_config_uart(void) { } +#ifdef CONFIG_BOARD_EARLY_INIT_F +void gpio_early_init(void) +{ + gpio_request(GPIO_PI4, NULL); + gpio_direction_output(GPIO_PI4, 1); + gpio_free(GPIO_PI4); +} +#endif + #ifdef CONFIG_TEGRA2_MMC /* * Routine: pin_mux_mmc
The PI4 GPIO is used on Tamonten to reset carrier board peripherals. Power sequencing hardware on the carrier pulls the reset low before powering up the Tegra, and the CPU is supposed to signal readiness, and therefore bring peripherals out of reset by pulling PI4 high. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> --- Changes in v2: - new patch required for TEC support board/avionic-design/common/tamonten.c | 9 +++++++++ 1 file changed, 9 insertions(+)