On Tue, Feb 14, 2012 at 3:06 AM, Ramirez Luna, Omar <omar.ramirez@xxxxxx> wrote: > 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. I'd say the less workarounds, the better. > 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. I see, but if wdt3 is requested as another clock, the Linux ARM side would still need to know how to threat the WDT. Cheers. -- Felipe Contreras _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
