linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tero Kristo <t-kristo@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: linux-omap@vger.kernel.org,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	"Mahadeva, Avinash" <avinashhm@ti.com>,
	"Hilman, Kevin" <khilman@ti.com>,
	"Cousson, Benoit" <b-cousson@ti.com>,
	Tony Lindgren <tony@atomide.com>,
	"R, Govindraj" <govindraj.raja@ti.com>,
	"Balbi, Felipe" <balbi@ti.com>
Subject: Re: [PATCHv6 01/11] omap: prcm: switch to a chained IRQ handler mechanism
Date: Fri, 2 Sep 2011 15:15:12 +0300	[thread overview]
Message-ID: <1314965712.3035.5.camel@sokoban> (raw)
In-Reply-To: <alpine.DEB.2.00.1109020311050.8762@utopia.booyaka.com>

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
 


  reply	other threads:[~2011-09-02 12:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-25 16:36 [PATCHv7 00/11] PRCM chain handler Tero Kristo
2011-07-25 16:36 ` [PATCHv6 01/11] omap: prcm: switch to a chained IRQ handler mechanism Tero Kristo
2011-07-25 17:03   ` Felipe Balbi
2011-07-26 10:33     ` Tero Kristo
2011-07-26 10:40       ` Felipe Balbi
2011-08-26  9:12   ` Paul Walmsley
2011-09-01 14:00     ` Tero Kristo
2011-09-02  9:20       ` Paul Walmsley
2011-09-02 12:15         ` Tero Kristo [this message]
2011-09-14 12:10           ` Paul Walmsley
2011-09-14 12:33             ` Tero Kristo
2011-07-25 16:36 ` [PATCHv6 02/11] OMAP2+: hwmod: Add API to enable IO ring wakeup Tero Kristo
2011-07-25 16:36 ` [PATCHv6 03/11] OMAP2+: hwmod: Add API to check IO PAD wakeup status Tero Kristo
2011-07-25 16:36 ` [PATCHv6 04/11] OMAP2+: mux: add support for PAD wakeup interrupts Tero Kristo
2011-07-25 16:36 ` [PATCHv6 05/11] TEMP: OMAP3: pm: remove serial resume / idle calls from idle path Tero Kristo
2011-07-25 16:36 ` [PATCHv6 06/11] TEMP: OMAP3: serial: made serial to work properly with PRCM chain handler Tero Kristo
2011-07-25 16:36 ` [PATCHv6 07/11] TEMP: serial: added mux support Tero Kristo
2011-07-25 16:36 ` [PATCHv6 08/11] TEMP: OMAP device: change pr_warnings to pr_debugs Tero Kristo
2011-07-25 16:36 ` [PATCHv6 09/11] TEMP: OMAP: serial: remove padconf hacks Tero Kristo
2011-07-25 16:36 ` [PATCHv6 10/11] TEMP: OMAP3: pm: disable / enable PRCM chain interrupts during wakeup from suspend Tero Kristo
2011-07-25 16:36 ` [PATCHv6 11/11] OMAP3: pm: do not enable PRCM MPU interrupts manually Tero Kristo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1314965712.3035.5.camel@sokoban \
    --to=t-kristo@ti.com \
    --cc=avinashhm@ti.com \
    --cc=b-cousson@ti.com \
    --cc=balbi@ti.com \
    --cc=govindraj.raja@ti.com \
    --cc=khilman@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).