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