From: nicolas.ferre@atmel•com (Nicolas Ferre)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 2/2] gpio/tegra: Dynamically allocate IRQ base, and support DT
Date: Thu, 01 Dec 2011 23:05:15 +0100 [thread overview]
Message-ID: <4ED7FA1B.1080109@atmel.com> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF174FDB02BF@HQMAIL01.nvidia.com>
On 12/01/2011 09:57 PM, Stephen Warren :
> Jamie Iles wrote at Thursday, December 01, 2011 9:55 AM:
>> On Thu, Dec 01, 2011 at 08:52:49AM -0800, Stephen Warren wrote:
>>> Jamie Iles wrote at Thursday, December 01, 2011 7:11 AM:
>>>> On Thu, Dec 01, 2011 at 07:42:57AM -0600, Rob Herring wrote:
>>>>> On 11/30/2011 06:45 PM, Stephen Warren wrote:
> ...
>>>>>> + 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...
Best regards,
--
Nicolas Ferre
next prev parent reply other threads:[~2011-12-01 22:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-01 0:45 [PATCH 1/2] arm/tegra: Remove use of TEGRA_GPIO_TO_IRQ Stephen Warren
2011-12-01 0:45 ` [PATCH 2/2] gpio/tegra: Dynamically allocate IRQ base, and support DT Stephen Warren
2011-12-01 13:42 ` Rob Herring
2011-12-01 14:11 ` Jamie Iles
2011-12-01 16:52 ` Stephen Warren
2011-12-01 16:55 ` Jamie Iles
2011-12-01 20:57 ` Stephen Warren
2011-12-01 22:05 ` Nicolas Ferre [this message]
2011-12-08 14:15 ` Shawn Guo
2011-12-05 6:55 ` Shawn Guo
2011-12-05 13:35 ` Rob Herring
2011-12-05 14:44 ` Shawn Guo
2011-12-05 17:19 ` Stephen Warren
-- strict thread matches above, loose matches on Subject: below --
2011-12-05 4:15 [PATCH 0/6] arm/imx: kill macro MXC_GPIO_IRQ_START Shawn Guo
2011-12-05 4:15 ` [PATCH 2/2] gpio/tegra: Dynamically allocate IRQ base, and support DT Shawn Guo
2011-12-05 4:29 ` Shawn Guo
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=4ED7FA1B.1080109@atmel.com \
--to=nicolas.ferre@atmel$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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