Re: [PATCH v2 2/8] irqchip: Supply new driver for STi based devices

[Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>]

On Thursday 27 November 2014 09:29:01 Lee Jones wrote:
> On Thu, 27 Nov 2014, Arnd Bergmann wrote:
> > On Thursday 27 November 2014 09:02:55 Lee Jones wrote:
> > > On Tue, 25 Nov 2014, Arnd Bergmann wrote:
> > > 
> > > > On Tuesday 25 November 2014 16:24:59 Lee Jones wrote:
> > > > 
> > > > > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> > > > > index b21f12f..e502f15 100644
> > > > > --- a/drivers/irqchip/Kconfig
> > > > > +++ b/drivers/irqchip/Kconfig
> > > > > @@ -93,6 +93,13 @@ config RENESAS_IRQC
> > > > >     bool
> > > > >     select IRQ_DOMAIN
> > > > >  
> > > > > +config ST_IRQCHIP
> > > > > +   bool
> > > > > +   select REGMAP
> > > > > +   select MFD_SYSCON
> > > > > +   help
> > > > > +     Enables SysCfg Controlled IRQs on STi based platforms.
> > > > > +
> > > > 
> > > > I'm confused by the purpose of this code. It's apparently a driver
> > > > in drivers/irqchip, the Kconfig symbol contains the string IRQCHIP,
> > > > yet it doesn't actually register an irq_chip.
> > > > 
> > > > Also, the name is a bit too generic, ST has lots of different irqchips,
> > > > and this apparently isn't even one of them 
> > > 
> > > Hmm... now you're going to ask me to remember who I had the
> > > conversation with that alluded to this as the best location for this
> > > driver.  Unfortunately, I cannot.  Can you think of a better place to
> > > put it then?
> > 
> > I suspect it's in the right place but should actually be an irqchip
> > driver. I'm having trouble understanding what this code actually does,
> > can you you explain the functionality in more detail so we can figure
> > out what to do with it?
> 
> In the simplest terms it's an IRQ unmasker.  A9 Core IRQs are disabled
> on boot; PMU, CTI (CoreSight), PL310_L2 and EXT.  In order for you to
> make use of them they need to be unmasked in SYSCFG.

So you just apply static configuration once, or are there reasons why you
would mask the interrupts again later?

If it's all static, why doesn't the boot loader unmask all interrupts before
starting the kernel?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html