From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tero Kristo Subject: Re: [PATCHv6 01/11] omap: prcm: switch to a chained IRQ handler mechanism Date: Fri, 2 Sep 2011 15:15:12 +0300 Message-ID: <1314965712.3035.5.camel@sokoban> References: <1311611771-15093-1-git-send-email-t-kristo@ti.com> <1311611771-15093-2-git-send-email-t-kristo@ti.com> <1314885600.24105.11.camel@sokoban> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Return-path: Received: from devils.ext.ti.com ([198.47.26.153]:59049 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750860Ab1IBMPV convert rfc822-to-8bit (ORCPT ); Fri, 2 Sep 2011 08:15:21 -0400 Content-Class: urn:content-classes:message In-Reply-To: Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Paul Walmsley Cc: linux-omap@vger.kernel.org, Thomas Petazzoni , "Mahadeva, Avinash" , "Hilman, Kevin" , "Cousson, Benoit" , Tony Lindgren , "R, Govindraj" , "Balbi, Felipe" Hi Paul, On Fri, 2011-09-02 at 11:20 +0200, Paul Walmsley wrote: > Hi Tero, > > On Thu, 1 Sep 2011, Tero Kristo wrote: > > > I've been looking at this now and got one question below. Otherwise your > > comments look okay to me and I can work with those. > > Great. As you work on it, please let me know if there's something that > doesn't make sense with this arrangement. I think this will work, and > will move some code out of arch/arm/*omap*, but it's hard to tell, until > someone tries it. > > > On Fri, 2011-08-26 at 11:12 +0200, Paul Walmsley wrote: > > > > > What I'd suggest is to create a short series that: > > > > > > 1. adds PRM hwmod data for OMAP2430+ platforms > > > > How should this be done? It believe all the data in the hwmods should be > > autogenerated somehow... should I just make a temporary hack patch for > > one platform that could be then autogenerated by someone for all omap > > platforms? > > Only OMAP4 is autogenerated, currently. OMAP2 & 3 are still done by hand. > I'd suggest starting with either OMAP4 (because the hwmod data should be > autogeneratable) or OMAP3 (because we know that one pretty well and the > hwmod data should not be too difficult to build). > > If it would help, I'd be happy to do a first draft of the OMAP3430 PRM > hwmod data. If you can do this it would help, as you have much better understanding of the hwmod data than I do. It will probably drop a couple of review rounds away as the hwmod data would be close to what it should be from beginning. If you are busy with other things, I can see what I can craft myself. > > > regards, > > - Paul Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki