>>>>> "Paul" == Paul Walmsley <paul@xxxxxxxxx> 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! -- Bye, Peter Korsgaard -- 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
