On Tue, Feb 14, 2012 at 10:23 AM, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: >> 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. If there are ever more base images compatible with the dsp, I would say that unifying them into a common format to be dumped in memory isn't a workaround, and in that process we can get rid of the custom loader code. >> 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. Tidspbridge does know how to treat other clock request from dsp (gpt, mcbsp), it would be a matter of adding the logic in the arm side for any dsp image that is able to do it, however this doesn't apply to the current (latest) base image since it assumes the wdt3 is always controlled by tidspbridge. 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
