On Tue, Feb 14, 2012 at 08:56:11PM -0600, Ramirez Luna, Omar wrote: > 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. Yes! please! and use Ohad's rproc thingy. What would be the steps to unify that common format? I guess we will depend on TI for that... Do we? vmjl > > >> 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 > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
