On Thu, Feb 9, 2012 at 9:18 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Feb 09, 2012 at 04:45:00PM -0800, Ramirez Luna, Omar wrote: >> Hi, >> >> On Thu, Feb 9, 2012 at 3:30 PM, Felipe Contreras >> <felipe.contreras@xxxxxxxxx> wrote: >> >> Again, I'm totally confused as to _WHY_ this needs to be y. What is >> >> causing this oops without it? If an oops is happening, then shouldn't >> >> this be a strict dependancy? Why allow it to be disabled at all if it >> >> can break your box if you don't enable it? >> > >> > It's not an oops, it's a warning, and again, it depends on the >> > firmware being used. We don't have control over that, and we have no >> > way to detect if this feature is there. It's up to the user. >> >> I have been thinking more into it, how about looking for a WDT symbol >> inside the baseimage to decide whether to turn ON/OFF WDT3, this would >> mean that the code is always compiled in, but the decision to turn it >> on/off is made at runtime. > > I totally don't understand, why not just silence the warning properly > then? > > I fail to understand why this warning happens, why it depends on the > firmware, and why you can't detect it at runtime to not do it. And how > it all ties into a kconfig option... Just FTR, the warning comes from an interconnect driver that reports errors. This specific warning occurs because the dsp tries to access wdt3 registers without a clock, hence turning ON the wdt3 (or default y for wdt3 Kconfig) will make the warning to disappear when first loading a base image into the dsp, because now there will be a clock for the registers. It depends on the firmware because the accesses are made from the dsp itself. Regards, Omar -- 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
