On Feb 11, 2012 3:03 PM, "Felipe Contreras" <felipe.contreras@xxxxxxxxx> wrote: > > On Sat, Feb 11, 2012 at 9:19 PM, Ramirez Luna, Omar <omar.ramirez@xxxxxx> wrote: > > > > On Feb 10, 2012 12:44 PM, "Felipe Contreras" <felipe.contreras@xxxxxxxxx> > > wrote: > >> > >> On Fri, Feb 10, 2012 at 10:35 PM, Dan Carpenter > >> <dan.carpenter@xxxxxxxxxx> wrote: > >> > On Fri, Feb 10, 2012 at 09:42:32PM +0200, Felipe Contreras wrote: > >> >> On Fri, Feb 10, 2012 at 8:00 PM, Dan Carpenter > >> >> <dan.carpenter@xxxxxxxxxx> wrote: > >> >> > On Fri, Feb 10, 2012 at 01:30:48AM +0200, Felipe Contreras wrote: > >> >> >> 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. > >> >> > > >> >> > Perhaps just remove the warning message and handle the condition > >> >> > instead of printing a stack dump? The user should be triggering > >> >> > stack dumps. What on earth? > >> >> > >> >> The warning doesn't come from the driver. > >> > > >> > I'm not sure I understand. Are you saying that because it comes > >> > from the arch/ directory, it can't be fixed? I have good news for > >> > you my friend. :) It's all open source! \o/ > >> > >> The fact that you _can_ remove the warning doesn't mean you should. To > >> me it sounds like a proper warning. > >> > >> > Anyway, I saw in another email that Omar is working on a fix so > >> > probably we can just wait for his patch, yes? > >> > >> He only proposed a solution, I doubt he is working on. And to me, that > >> sounded like a hack rather than a proper fix. > > > > I'm out on travel but will be able to look at it on Monday. > > > > Well, I think it is the right way, you look on the firmware if it has WDT > > you use it if it doesn't then you don't. Rather than guessing if you have > > the feature. It would be like reading a config option in the firmware. > > Yeah, but it's not really firmware, it's an operating system image. I > can be running Linux there, and I might have implemented WDT. How is > that code going to find that out? Tidspbridge loader doesn't support that use case, baseimage and let's say a dsp-linuximg won't have the same layout, hence it won't be able to parse and load the latter. When that case is applicable, we should first modify the loader code or prepare the baseimages to be common so we can get rid of specific loaders and just dump them into memory. WDT could be detected by prepending common symbols into the baseimages or just making the new images to treat all peripherals as resources, that is, the new baseimg should actually request the wdt3 as any other clock. Regards, Omar _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
