"Cousson, Benoit" <b-cousson@xxxxxx> writes: > On 9/30/2010 3:55 PM, Kevin Hilman wrote: >> "Cousson, Benoit"<b-cousson@xxxxxx> writes: >> >>> Hi Charu, >>> >>> On 9/30/2010 10:11 AM, Varadarajan, Charulatha wrote: >>>> With OMAP2PLUS watchdog implemented in hwmod fw way, the >>>> module is reset during init. >>> >>> In that case hwmod fw just highlighted the real behavior that was >>> hidden so far by the X-loader. >>> >>> You should as well add a link to the email thread with Kevin that >>> raised the issue. >>> >>>> After a watchdog timer module reset, the WDTs are enabled. The >>>> default time for a system reset after a watchdog module reset >>>> is ~10s as per the default value of the WDT registers. Hence >>>> the system would be reset after 10s, if watchdog is not disabled >>>> within 10s. >>>> >>>> This patch fixes the above issue by disabling the watchdog timer >>>> after reset during initialization of devices. >>> >>> I'm still wondering as well what is the expected behavior of the >>> watchdog in a real product. If it is started by default at boot time, >>> this is probably for a good reason (or maybe not...). >>> >>> So, disabling it all the time is maybe not the best solution. >> >> I'm not sure what the other options are. If you don't have a watchdog >> driver, and the watchdog is armed, it will reboot the system. >> >> The approach in this patch is just to continue the behavior that all >> bootloaders currently do, but make it explicit in the kernel. > > Yes, because we are not a building a product, and for us watchdog is a > pain. But I'm not sure that a real product will disable that at all > during the boot process. Maybe not. But wouldn't a product just ensure the real watchdog driver is loaded? Or more likely, in addition to the hundreds of other out-of-tree patches, they would just remove $SUBJECT patch. ;) > I think that disabling it should be done only if the CONFIG_OMAP_WDT > is not set. That's not easy either, as the watchdog driver can be built as a module, and may (or may not) be loaded some unknown time from the kernel boot, resulting in a likely Kevin > But since I don't have a clue about a product can use that, it will be > good to have such inputs to understand the usecase. -- 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
