All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Rob Herring <robherring2@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
	devicetree-discuss@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, marc.zyngier@arm.com,
	thomas.abraham@linaro.org, jamie@jamieiles.com, b-cousson@ti.com,
	shawn.guo@linaro.org
Subject: Re: [PATCH 1/2] ARM: gic: add irq_domain support
Date: Thu, 29 Sep 2011 18:27:51 -0600	[thread overview]
Message-ID: <20110930002751.GA12606@ponder.secretlab.ca> (raw)
In-Reply-To: <4E84DCF4.4020904@gmail.com>

On Thu, Sep 29, 2011 at 04:02:44PM -0500, Rob Herring wrote:
> On 09/29/2011 12:15 PM, Grant Likely wrote:
> > On Wed, Sep 28, 2011 at 10:53:55PM -0500, Rob Herring wrote:
> >> From: Rob Herring <rob.herring@calxeda.com>
> >>
> >> Convert the gic interrupt controller to use irq domains in preparation
> >> for device-tree binding and MULTI_IRQ. This allows for translation between
> >> GIC interrupt IDs and Linux irq numbers.
> >>
> >> The meaning of irq_offset has changed. It now is just the number of skipped
> >> GIC interrupt IDs for the controller. It will be 16 for primary GIC and 32
> >> for secondary GICs.
> > 
> > [...]
> > 
> >>  /*
> >> @@ -81,7 +82,7 @@ static inline unsigned int gic_irq(struct irq_data *d)
> >>   */
> >>  static void gic_mask_irq(struct irq_data *d)
> >>  {
> >> -	u32 mask = 1 << (d->irq % 32);
> >> +	u32 mask = 1 << (gic_irq(d) % 32);
> > 
> > This can probably change simply to d->hwirq if irq_offset is
> > eliminated as I describe below.
> > 
> >>  void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
> >>  	void __iomem *dist_base, void __iomem *cpu_base)
> >>  {
> >>  	struct gic_chip_data *gic;
> >> +	struct irq_domain *domain;
> >> +	int gic_irqs;
> >>  
> >>  	BUG_ON(gic_nr >= MAX_GIC_NR);
> >>  
> >>  	gic = &gic_data[gic_nr];
> >> +	domain = &gic->domain;
> >>  	gic->dist_base = dist_base;
> >>  	gic->cpu_base = cpu_base;
> >> -	gic->irq_offset = (irq_start - 1) & ~31;
> >>  
> >> -	if (gic_nr == 0)
> >> +	/*
> >> +	 * For primary GICs, skip over SGIs.
> >> +	 * For secondary GICs, skip over PPIs, too.
> >> +	 */
> >> +	if (gic_nr == 0) {
> >>  		gic_cpu_base_addr = cpu_base;
> >> +		gic->irq_offset = 16;
> >> +		irq_start = (irq_start & ~31) + 16;
> > 
> > With the switch to irq_domain, there should no longer be any need for
> > a ~31 mask on the irq_start number.  Yes, you'll want to make sure
> > that it doesn't allocate below irq 16, but the driver should
> > completely use the irq_domain to manage the mapping from linux-irq
> > number to hwirq number.  The ~31 mask appears to have been an
> > optimization to quickly calculate hwirq number from the linux one, but
> > that value is now found in irq_data->hwirq.
> 
> I started out exactly this way removing irq_offset. The problem is the
> core irq domain code assumes that hwirq starts at 0, but for the gic it
> starts at 16 or 32.
> 
> It could be fixed in the domain core, but that would effectively mean
> moving irq_offset into the core.

Fix irq_domain.  If it cannot handle this trivial case, then it won't
be able to handle the complex powerpc use cases.

g.

WARNING: multiple messages have this Message-ID (diff)
From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: gic: add irq_domain support
Date: Thu, 29 Sep 2011 18:27:51 -0600	[thread overview]
Message-ID: <20110930002751.GA12606@ponder.secretlab.ca> (raw)
In-Reply-To: <4E84DCF4.4020904@gmail.com>

On Thu, Sep 29, 2011 at 04:02:44PM -0500, Rob Herring wrote:
> On 09/29/2011 12:15 PM, Grant Likely wrote:
> > On Wed, Sep 28, 2011 at 10:53:55PM -0500, Rob Herring wrote:
> >> From: Rob Herring <rob.herring@calxeda.com>
> >>
> >> Convert the gic interrupt controller to use irq domains in preparation
> >> for device-tree binding and MULTI_IRQ. This allows for translation between
> >> GIC interrupt IDs and Linux irq numbers.
> >>
> >> The meaning of irq_offset has changed. It now is just the number of skipped
> >> GIC interrupt IDs for the controller. It will be 16 for primary GIC and 32
> >> for secondary GICs.
> > 
> > [...]
> > 
> >>  /*
> >> @@ -81,7 +82,7 @@ static inline unsigned int gic_irq(struct irq_data *d)
> >>   */
> >>  static void gic_mask_irq(struct irq_data *d)
> >>  {
> >> -	u32 mask = 1 << (d->irq % 32);
> >> +	u32 mask = 1 << (gic_irq(d) % 32);
> > 
> > This can probably change simply to d->hwirq if irq_offset is
> > eliminated as I describe below.
> > 
> >>  void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
> >>  	void __iomem *dist_base, void __iomem *cpu_base)
> >>  {
> >>  	struct gic_chip_data *gic;
> >> +	struct irq_domain *domain;
> >> +	int gic_irqs;
> >>  
> >>  	BUG_ON(gic_nr >= MAX_GIC_NR);
> >>  
> >>  	gic = &gic_data[gic_nr];
> >> +	domain = &gic->domain;
> >>  	gic->dist_base = dist_base;
> >>  	gic->cpu_base = cpu_base;
> >> -	gic->irq_offset = (irq_start - 1) & ~31;
> >>  
> >> -	if (gic_nr == 0)
> >> +	/*
> >> +	 * For primary GICs, skip over SGIs.
> >> +	 * For secondary GICs, skip over PPIs, too.
> >> +	 */
> >> +	if (gic_nr == 0) {
> >>  		gic_cpu_base_addr = cpu_base;
> >> +		gic->irq_offset = 16;
> >> +		irq_start = (irq_start & ~31) + 16;
> > 
> > With the switch to irq_domain, there should no longer be any need for
> > a ~31 mask on the irq_start number.  Yes, you'll want to make sure
> > that it doesn't allocate below irq 16, but the driver should
> > completely use the irq_domain to manage the mapping from linux-irq
> > number to hwirq number.  The ~31 mask appears to have been an
> > optimization to quickly calculate hwirq number from the linux one, but
> > that value is now found in irq_data->hwirq.
> 
> I started out exactly this way removing irq_offset. The problem is the
> core irq domain code assumes that hwirq starts at 0, but for the gic it
> starts at 16 or 32.
> 
> It could be fixed in the domain core, but that would effectively mean
> moving irq_offset into the core.

Fix irq_domain.  If it cannot handle this trivial case, then it won't
be able to handle the complex powerpc use cases.

g.

  reply	other threads:[~2011-09-30  0:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-29  3:53 [PATCH 0/2] GIC OF bindings Rob Herring
2011-09-29  3:53 ` Rob Herring
2011-09-29  3:53 ` [PATCH 1/2] ARM: gic: add irq_domain support Rob Herring
2011-09-29  3:53   ` Rob Herring
2011-09-29  3:53   ` Rob Herring
2011-09-29 17:15   ` Grant Likely
2011-09-29 17:15     ` Grant Likely
2011-09-29 17:15     ` Grant Likely
2011-09-29 21:02     ` Rob Herring
2011-09-29 21:02       ` Rob Herring
2011-09-29 21:02       ` Rob Herring
2011-09-30  0:27       ` Grant Likely [this message]
2011-09-30  0:27         ` Grant Likely
2011-09-29  3:53 ` [PATCH 2/2] ARM: gic: add OF based initialization Rob Herring
2011-09-29  3:53   ` Rob Herring
2011-09-29  3:53   ` Rob Herring
2011-09-29 17:19   ` Grant Likely
2011-09-29 17:19     ` Grant Likely
2011-09-29  9:21 ` [PATCH 0/2] GIC OF bindings Jamie Iles
2011-09-29  9:21   ` Jamie Iles

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=20110930002751.GA12606@ponder.secretlab.ca \
    --to=grant.likely@secretlab.ca \
    --cc=b-cousson@ti.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=jamie@jamieiles.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=robherring2@gmail.com \
    --cc=shawn.guo@linaro.org \
    --cc=thomas.abraham@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.