linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: new IRQ work status
Date: Fri, 30 Jun 2006 08:57:23 +1000	[thread overview]
Message-ID: <1151621843.32016.7.camel@localhost.localdomain> (raw)
In-Reply-To: <200606291525.53254.arnd.bergmann@de.ibm.com>


> >  /* Get an IRQ number from the pending state register of the IIC */
> > -int iic_get_irq(struct pt_regs *regs)
> > +unsigned int iic_get_irq(struct pt_regs *regs)
> 
> Is unsigned the right thing here? NO_IRQ is defined as (-1).

One of the patches changes NO_IRQ to 0 and generally virtual irq numbers
to unsigned int

> I'd prefer to throw out the hardcoded part from the official tree
> completely. It's only needed on the very first FW versions that
> were shipped and those need some other patches that we never merged
> upstream anyway. So better move it to an extra patch that we keep
> external for some time and eventually drop.

Ok, will move it to a separate patch then.

> >  static irqreturn_t iic_ipi_action(int irq, void *dev_id, struct pt_regs
> > *regs) {
> > -	smp_message_recv(iic_irq_to_ipi(irq), regs);
> > +	int ipi = (int)(long)dev_id;
> > +	smp_message_recv(ipi, regs);
> >  	return IRQ_HANDLED;
> >  }
> 
> Nice one. this looks a lot cleaner than looking at the irq number here.

Yeah, I had the calculation wrong at first :) the irq number you get
here is the virtual one. So you 'd need to convert it through the
reverse map. With the above trick, I avoid that.

> Considering that name is know to be rather short and we have a fixed
> number of these, can't we just put the strings into struct iic
> instead of doing the kzalloc?

Good point, I'll look into it.

> >  enum {
> > -	IIC_EXT_OFFSET   = 0x00, /* Start of south bridge IRQs */
> > -	IIC_EXT_CASCADE  = 0x20, /* There is no interrupt 32 on spider */
> > -	IIC_NUM_EXT      = 0x40, /* Number of south bridge IRQs */
> > -	IIC_SPE_OFFSET   = 0x40, /* Start of SPE interrupts */
> > -	IIC_CLASS_STRIDE = 0x10, /* SPE IRQs per class    */
> > -	IIC_IPI_OFFSET   = 0x70, /* Start of IPI IRQs */
> > -	IIC_NUM_IPIS     = 0x10, /* IRQs reserved for IPI */
> > -	IIC_NODE_STRIDE  = 0x80, /* Total IRQs per node   */
> > +	IIC_IRQ_INVALID		= 0xff,
> 
> Where is IIC_IRQ_INVALID used?

Just to give an invalid number to the remapping core. It uses that to
fill up allocated but not-yet mapped slots 

> See above about the hardcoded stuff.

Yup.

> 
> > @@ -664,11 +688,18 @@ static int __init create_spu(struct devi
> >  	if (ret)
> >  		goto out_free;
> >
> > +	/* XXX FIXME: Those node vs. nid things are crap, we need
> > +	 * only one information, but fixing that goes along with fixing
> > +	 * all of the node vs chip vs thread code all over the cell
> > +	 * platform. To do soon hopefully...
> > +	 */
> >  	spu->node = find_spu_node_id(spe);
> >  	spu->nid = of_node_to_nid(spe);
> >  	if (spu->nid == -1)
> >  		spu->nid = 0;
> 
> The idea at some point was to keep the notion of nid (as in address
> on the inter-chip protocol) separate from the NUMA node ID, which
> may in theory be less fine-grained. Defining them to be the same
> at least requires the device tree to be very careful with the numbers
> in ibm,associativity properties to match the bus numbers.

Yeah, I've discussed that with Paul and Anton, I want to do a generic
layer to take care of all these conversions with a 4 level
representation:

 - thread -> match linux CPU numbers
 - core
 - chip
 - node

Anyway, that's the sort of cleanup I'll do later.

> > Index: linux-work-mm/include/asm-powerpc/spu.h
> > ===================================================================
> > --- linux-work-mm.orig/include/asm-powerpc/spu.h	2006-06-23
> > 13:38:19.000000000 +1000 +++
> > linux-work-mm/include/asm-powerpc/spu.h	2006-06-29 16:32:35.000000000 +1000
> > @@ -117,7 +117,7 @@ struct spu {
> >  	struct list_head sched_list;
> >  	int number;
> >  	int nid;
> > -	u32 isrc;
> > +	unsigned int irqs[3];
> >  	u32 node;
> >  	u64 flags;
> >  	u64 dar;
> 
> We've started exporting the isrc property in sysfs recently, so I think
> we need to keep that in here.

Why would we do that ? It makes no sense on HV platforms. Is there
anything that makes use of it ?

Ben.

  parent reply	other threads:[~2006-06-29 22:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-29  8:36 new IRQ work status Benjamin Herrenschmidt
2006-06-29 13:25 ` Arnd Bergmann
2006-06-29 13:41   ` Segher Boessenkool
2006-06-29 22:57   ` Benjamin Herrenschmidt [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-06-30  4:57 Bob Brose
2006-06-30  7:45 ` Benjamin Herrenschmidt

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=1151621843.32016.7.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=arnd.bergmann@de.ibm.com \
    --cc=linuxppc-dev@ozlabs.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 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).