All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Michal Simek <monstr@monstr.eu>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Ralf Baechle <ralf@linux-mips.org>,
	hpa@zytor.com, Dirk Brandewie <dirk.brandewie@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linuxppc-dev@lists.ozlabs.org,
	devicetree-discuss@lists.ozlabs.org
Subject: Re: [PATCH 4/6] dt: generalize irq_of_create_mapping()
Date: Thu, 05 May 2011 10:43:41 +1000	[thread overview]
Message-ID: <1304556221.2513.395.camel@pasglop> (raw)
In-Reply-To: <20110504160502.GC3317@ponder.secretlab.ca>

On Wed, 2011-05-04 at 10:05 -0600, Grant Likely wrote:
> > I think you are going the wrong way around.
> > 
> > First thing first, is to make the irq domain / mapping API generic
> > without the OF bits.
> > 
> > IE. move the IRQ domain generically, get rid of irq_map by putting
> the
> > domain ptr & hw numbers in the irq desc/data etc...
> > 
> > Then you can move over the OF specific bits which are optional and
> > orthogonal to a large extent.
> 
> As discussed in my other reply, I disagree.  There isn't an immediate
> need for the mapping interface in common code.  It would be useful,
> sure, for some interrupt controllers, but for many of them
> irq_alloc_descs() and an irq_base value is all the functionality that
> is needed, and irq_host doesn't gain anything.

No but the concept of domain is a pre-requisite. Even if it's an opaque
data structure. And I don't want to have it be some "of" specific thing.

> The OF translation on the other hand is needed immediately by several
> architectures and are very much non-optional in that regard.

But it relies on having an underlying mapping. I don't see how you can
do one without the other, even if your mapping in effect is just an
offset.

And it is -not- related to OF.

Whether you obtain that your interrupt you are interested it is
interrupt 5 of your PIC "foo" via the device-tree or any other way (an
arch quirk for example), you need the mechanism to associate them
together, whether it's a simple offset as you propose (I'm ok with that
for simple things, I just didn't think it was the right approach for
powerpc but it's perfectly valid as an option generically) or a more
complex radix-tree style mapping.

Thus sort out the mapping interfaces first. _Then_ layout the
device-tree bits on top.

The basic parsing for the DT is already there. It will return a parent
node and a __be32* pointer.

Cheers,
Ben.

WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Michal Simek <monstr@monstr.eu>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	linux-kernel@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
	hpa@zytor.com, Dirk Brandewie <dirk.brandewie@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	devicetree-discuss@lists.ozlabs.org, x86@kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 4/6] dt: generalize irq_of_create_mapping()
Date: Thu, 05 May 2011 10:43:41 +1000	[thread overview]
Message-ID: <1304556221.2513.395.camel@pasglop> (raw)
In-Reply-To: <20110504160502.GC3317@ponder.secretlab.ca>

On Wed, 2011-05-04 at 10:05 -0600, Grant Likely wrote:
> > I think you are going the wrong way around.
> > 
> > First thing first, is to make the irq domain / mapping API generic
> > without the OF bits.
> > 
> > IE. move the IRQ domain generically, get rid of irq_map by putting
> the
> > domain ptr & hw numbers in the irq desc/data etc...
> > 
> > Then you can move over the OF specific bits which are optional and
> > orthogonal to a large extent.
> 
> As discussed in my other reply, I disagree.  There isn't an immediate
> need for the mapping interface in common code.  It would be useful,
> sure, for some interrupt controllers, but for many of them
> irq_alloc_descs() and an irq_base value is all the functionality that
> is needed, and irq_host doesn't gain anything.

No but the concept of domain is a pre-requisite. Even if it's an opaque
data structure. And I don't want to have it be some "of" specific thing.

> The OF translation on the other hand is needed immediately by several
> architectures and are very much non-optional in that regard.

But it relies on having an underlying mapping. I don't see how you can
do one without the other, even if your mapping in effect is just an
offset.

And it is -not- related to OF.

Whether you obtain that your interrupt you are interested it is
interrupt 5 of your PIC "foo" via the device-tree or any other way (an
arch quirk for example), you need the mechanism to associate them
together, whether it's a simple offset as you propose (I'm ok with that
for simple things, I just didn't think it was the right approach for
powerpc but it's perfectly valid as an option generically) or a more
complex radix-tree style mapping.

Thus sort out the mapping interfaces first. _Then_ layout the
device-tree bits on top.

The basic parsing for the DT is already there. It will return a parent
node and a __be32* pointer.

Cheers,
Ben.


WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Sebastian Andrzej Siewior
	<bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Ralf Baechle <ralf-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>,
	hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Subject: Re: [PATCH 4/6] dt: generalize irq_of_create_mapping()
Date: Thu, 05 May 2011 10:43:41 +1000	[thread overview]
Message-ID: <1304556221.2513.395.camel@pasglop> (raw)
In-Reply-To: <20110504160502.GC3317-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>

On Wed, 2011-05-04 at 10:05 -0600, Grant Likely wrote:
> > I think you are going the wrong way around.
> > 
> > First thing first, is to make the irq domain / mapping API generic
> > without the OF bits.
> > 
> > IE. move the IRQ domain generically, get rid of irq_map by putting
> the
> > domain ptr & hw numbers in the irq desc/data etc...
> > 
> > Then you can move over the OF specific bits which are optional and
> > orthogonal to a large extent.
> 
> As discussed in my other reply, I disagree.  There isn't an immediate
> need for the mapping interface in common code.  It would be useful,
> sure, for some interrupt controllers, but for many of them
> irq_alloc_descs() and an irq_base value is all the functionality that
> is needed, and irq_host doesn't gain anything.

No but the concept of domain is a pre-requisite. Even if it's an opaque
data structure. And I don't want to have it be some "of" specific thing.

> The OF translation on the other hand is needed immediately by several
> architectures and are very much non-optional in that regard.

But it relies on having an underlying mapping. I don't see how you can
do one without the other, even if your mapping in effect is just an
offset.

And it is -not- related to OF.

Whether you obtain that your interrupt you are interested it is
interrupt 5 of your PIC "foo" via the device-tree or any other way (an
arch quirk for example), you need the mechanism to associate them
together, whether it's a simple offset as you propose (I'm ok with that
for simple things, I just didn't think it was the right approach for
powerpc but it's perfectly valid as an option generically) or a more
complex radix-tree style mapping.

Thus sort out the mapping interfaces first. _Then_ layout the
device-tree bits on top.

The basic parsing for the DT is already there. It will return a parent
node and a __be32* pointer.

Cheers,
Ben.

  reply	other threads:[~2011-05-05  0:43 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-28 20:01 [PATCH 0/6] General device tree irq domain infrastructure Grant Likely
2011-04-28 20:01 ` Grant Likely
2011-04-28 20:01 ` [PATCH 1/6] powerpc: stop exporting irq_map Grant Likely
2011-04-28 20:01   ` Grant Likely
2011-05-03  1:44   ` Benjamin Herrenschmidt
2011-05-03  1:44     ` Benjamin Herrenschmidt
2011-05-03  1:44     ` Benjamin Herrenschmidt
2011-04-28 20:01 ` [PATCH 2/6] powerpc: make irq_{alloc, free}_virt private and remove count argument Grant Likely
2011-04-28 20:01   ` Grant Likely
2011-05-03  1:47   ` Benjamin Herrenschmidt
2011-05-03  1:47     ` Benjamin Herrenschmidt
2011-05-03  1:47     ` Benjamin Herrenschmidt
2011-05-04 15:59     ` Grant Likely
2011-05-04 15:59       ` Grant Likely
2011-05-05  0:39       ` Benjamin Herrenschmidt
2011-05-05  0:39         ` Benjamin Herrenschmidt
2011-04-28 20:01 ` [PATCH 3/6] powerpc: Make struct irq_host semi-private by moving into irqhost.h Grant Likely
2011-04-28 20:01   ` Grant Likely
2011-05-03  1:48   ` Benjamin Herrenschmidt
2011-05-03  1:48     ` Benjamin Herrenschmidt
2011-05-03  1:48     ` Benjamin Herrenschmidt
2011-04-28 20:02 ` [PATCH 4/6] dt: generalize irq_of_create_mapping() Grant Likely
2011-04-28 20:02   ` Grant Likely
2011-05-03  1:50   ` Benjamin Herrenschmidt
2011-05-03  1:50     ` Benjamin Herrenschmidt
2011-05-03  1:50     ` Benjamin Herrenschmidt
2011-05-04 16:05     ` Grant Likely
2011-05-04 16:05       ` Grant Likely
2011-05-05  0:43       ` Benjamin Herrenschmidt [this message]
2011-05-05  0:43         ` Benjamin Herrenschmidt
2011-05-05  0:43         ` Benjamin Herrenschmidt
2011-04-28 20:02 ` [PATCH 5/6] powerpc: move irq_alloc_descs_at() call into irq_alloc_virt() Grant Likely
2011-04-28 20:02   ` Grant Likely
2011-04-28 20:02 ` [PATCH 6/6] powerpc: use irq_alloc_desc() to manage irq allocations Grant Likely
2011-04-28 20:02   ` Grant Likely
2011-04-29 16:16 ` [PATCH 0/6] General device tree irq domain infrastructure Sebastian Andrzej Siewior
2011-04-29 16:16   ` Sebastian Andrzej Siewior
2011-04-29 17:43   ` Grant Likely
2011-04-29 17:43     ` Grant Likely
2011-05-03  1:43 ` Benjamin Herrenschmidt
2011-05-03  1:43   ` Benjamin Herrenschmidt
2011-05-03  1:43   ` Benjamin Herrenschmidt
2011-05-04 15:52   ` Grant Likely
2011-05-04 15:52     ` Grant Likely
2011-05-05  0:39     ` Benjamin Herrenschmidt
2011-05-05  0:39       ` Benjamin Herrenschmidt
2011-05-05  0:39       ` Benjamin Herrenschmidt
2011-05-05  8:37       ` Thomas Gleixner
2011-05-05  8:37         ` Thomas Gleixner
2011-05-05 14:07         ` Grant Likely
2011-05-05 14:07           ` Grant Likely
2011-05-05 14:07           ` Grant Likely
2011-05-05 14:14           ` Sebastian Andrzej Siewior
2011-05-05 14:14             ` Sebastian Andrzej Siewior

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=1304556221.2513.395.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=bigeasy@linutronix.de \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=dirk.brandewie@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=monstr@monstr.eu \
    --cc=ralf@linux-mips.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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.