Felipe Balbi <balbi@xxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
