Thread (1 message) 1 message, 1 author, 2011-12-08

[PATCH 2/2] gpio/tegra: Dynamically allocate IRQ base, and support DT

From: Shawn Guo <hidden>
Date: 2011-12-08 14:15:13
Also in: linux-devicetree, linux-tegra

Hi Thomas,

On Thu, Dec 01, 2011 at 11:05:15PM +0100, Nicolas Ferre wrote:
On 12/01/2011 09:57 PM, Stephen Warren :
quoted
Jamie Iles wrote at Thursday, December 01, 2011 9:55 AM:
quoted
On Thu, Dec 01, 2011 at 08:52:49AM -0800, Stephen Warren wrote:
quoted
Jamie Iles wrote at Thursday, December 01, 2011 7:11 AM:
quoted
On Thu, Dec 01, 2011 at 07:42:57AM -0600, Rob Herring wrote:
quoted
On 11/30/2011 06:45 PM, Stephen Warren wrote:
...
quoted
quoted
quoted
quoted
quoted
+	irq_domain.irq_base = irq_alloc_descs(-1, 0, TEGRA_NR_GPIOS, 0);
+	if (irq_domain.irq_base<  0) {
+		dev_err(&pdev->dev, "Couldn't allocate IRQ numbers\n");
+		return -ENODEV;
+	}
+	irq_domain.nr_irq = TEGRA_NR_GPIOS;
+	irq_domain.ops =&irq_domain_ops;
Why don't you just use irq_domain_simple_ops?
This would need the patch I posted earlier
(https://lkml.org/lkml/2011/12/1/109) so they can work for the
!CONFIG_OF case ;-)
Part of my reasoning was that simple_ops appeared to be intended for
DT-based controllers; is it safe to use those ops for a controller that
wasn't instantiated from DT? I know that right now, the only op in that
structure is dt_translate, and that won't ever be called for the non-DT
case, but is there a guarantee that more functions won't be added to
the simple ops, and that they won't assume DT is in use, and fail if
not?

If these are safe to use in the non-DT case, then yet I could build off
Jamie's patch, although managing the dependencies might be awkward.
Yes, it's absolutely fine to use it just that irq_simple_ops isn't
currently exported unless you have CONFIG_OF_IRQ set so you'd get an
undefined reference for !CONFIG_OF at the moment.
OK, sounds good.

So, I think we have a few options:
1) Merge my change as-is, and simplify it later once your patch is in.
2) Put your change in a branch, and merge it into both its usual place,
and the Tegra/ARM branches, so I can rebase my patch on top of it.
3) Have the usual maintainer ack it (I see Rob already did, but I think
Thomas is the maintainer here right?) and just put both patches into the
Tegra/ARM tree. This of course means non-Tegra branches have to wait for
it rather than the other way around.

(1) seems simplest, but (2) is probably doable. Thomas?
I jump into the discussion to say that I am also interested by
Jamie's patch. I am following the same path as Stephen at the moment
with Atmel AT91... A chance I can read all your comments that are so
valuable for me as well :-)

So, for me (2) will ease things...
I'm sending Jamie's patch as prerequisite of my gpio interrupt
controller cleanup series to Arnd and Olof (arm-soc tree), so that
similar series for tegra and at91 from Stephen and Nicolas can base
on Jamie's patch too.

Please let us know if you do not want this way.

Regards,
Shawn

[1] [PATCH] irqdomain: export irq_domain_simple_ops for !CONFIG_OF
    https://lkml.org/lkml/2011/12/1/109
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help