From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?V=EDctor_M=2E_J=E1quez_L=2E?= Subject: Re: [PATCH] staging: tidspbridge: enable watchdog by default Date: Wed, 15 Feb 2012 10:43:57 +0100 Message-ID: <20120215094357.GA24331@lit.local.igalia.com> References: <20120210180015.GF4141@mwanda> <20120210203537.GG4141@mwanda> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from smtp4.mundo-r.com ([212.51.32.151]:56011 "EHLO smtp4.mundo-r.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755631Ab2BOJoQ (ORCPT ); Wed, 15 Feb 2012 04:44:16 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: "Ramirez Luna, Omar" Cc: Felipe Contreras , linux-omap@vger.kernel.org, Felipe Contreras , "Justin P. Mattock" , "open list:STAGING SUBSYSTEM" , Jiri Kosina , Dan Carpenter , Greg KH 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 > 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >