From: lars@metafoo.de (Lars-Peter Clausen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2] media: i2c: Add ADV761X support
Date: Fri, 29 Nov 2013 21:05:53 +0100 [thread overview]
Message-ID: <5298F3A1.7070503@metafoo.de> (raw)
In-Reply-To: <CACRpkda89fqGd6+ShvFXz-7i56KfG43EggBtjbdKyOCGnJu5Cg@mail.gmail.com>
On 11/29/2013 08:52 PM, Linus Walleij wrote:
> On Fri, Nov 29, 2013 at 2:48 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>> On 11/29/2013 02:42 PM, Linus Walleij wrote:
>>> On Fri, Nov 29, 2013 at 11:45 AM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>>>>
>>>> As far as I understand it this already works more or less with the driver.
>>>> The problem is that the IRQ numbers are dynamically allocated, while the
>>>> GPIO numbers apparently are not. So the board code knows the the GPIO number
>>>> at compile time and can pass this to the diver which then does a gpio_to_irq
>>>> to lookup the IRQ number. This of course isn't really a problem with
>>>> devicetree, but only with platform board code.
>>>
>>> This has been solved *also* for platform board code by the new, fresh
>>> GPIO descriptor mechanism, see Documentation/gpio/*
>>> in Torvalds' git HEAD.
>>
>> This works when the GPIO numbers are dynamically allocated (which are static
>> in this case), but not for IRQ numbers.
>
> Sorry I don't get what you're after here. I'm not the subsystem
> maintainer for IRQ chips ...
I'm trying to explain, that the problem is not about GPIO number lookup, but
rather about IRQ number lookup :)
>
> In the DT boot path for platform or AMBA devices the IRQs
> are automatically resolved to resources and passed with the
> device so that is certainly not the problem, right?
Yep, what I said earlier, this is a problem that's solved by using DT.
>
> I guess you may be referring to the problem of instatiating
> a dynamic IRQ chip in *board code* and then passing the
> obtained dynamic IRQ numbers as resources to the
> devices also created in a board file?
>
Yes.
> That would be like you're asking for a function that would
> return the base of an irq_chip, that needs to be discussed
> with the irq maintainers, so not much I can say, but maybe
> I misunderstood this?
I my opinion the best solution for this problem is to have the same lookup
mechanism we've had for clocks, regulators, etc and now also GPIOs.
- Lars
WARNING: multiple messages have this Message-ID (diff)
From: Lars-Peter Clausen <lars@metafoo.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <acourbot@nvidia.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Valentine <valentine.barshak@cogentembedded.com>,
Hans Verkuil <hansverk@cisco.com>,
Hans Verkuil <hverkuil@xs4all.nl>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
Mauro Carvalho Chehab <m.chehab@samsung.com>,
Hans Verkuil <hans.verkuil@cisco.com>,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
Simon Horman <horms@verge.net.au>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Wolfram Sang <wsa@the-dreams.de>
Subject: Re: [PATCH V2] media: i2c: Add ADV761X support
Date: Fri, 29 Nov 2013 21:05:53 +0100 [thread overview]
Message-ID: <5298F3A1.7070503@metafoo.de> (raw)
In-Reply-To: <CACRpkda89fqGd6+ShvFXz-7i56KfG43EggBtjbdKyOCGnJu5Cg@mail.gmail.com>
On 11/29/2013 08:52 PM, Linus Walleij wrote:
> On Fri, Nov 29, 2013 at 2:48 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>> On 11/29/2013 02:42 PM, Linus Walleij wrote:
>>> On Fri, Nov 29, 2013 at 11:45 AM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>>>>
>>>> As far as I understand it this already works more or less with the driver.
>>>> The problem is that the IRQ numbers are dynamically allocated, while the
>>>> GPIO numbers apparently are not. So the board code knows the the GPIO number
>>>> at compile time and can pass this to the diver which then does a gpio_to_irq
>>>> to lookup the IRQ number. This of course isn't really a problem with
>>>> devicetree, but only with platform board code.
>>>
>>> This has been solved *also* for platform board code by the new, fresh
>>> GPIO descriptor mechanism, see Documentation/gpio/*
>>> in Torvalds' git HEAD.
>>
>> This works when the GPIO numbers are dynamically allocated (which are static
>> in this case), but not for IRQ numbers.
>
> Sorry I don't get what you're after here. I'm not the subsystem
> maintainer for IRQ chips ...
I'm trying to explain, that the problem is not about GPIO number lookup, but
rather about IRQ number lookup :)
>
> In the DT boot path for platform or AMBA devices the IRQs
> are automatically resolved to resources and passed with the
> device so that is certainly not the problem, right?
Yep, what I said earlier, this is a problem that's solved by using DT.
>
> I guess you may be referring to the problem of instatiating
> a dynamic IRQ chip in *board code* and then passing the
> obtained dynamic IRQ numbers as resources to the
> devices also created in a board file?
>
Yes.
> That would be like you're asking for a function that would
> return the base of an irq_chip, that needs to be discussed
> with the irq maintainers, so not much I can say, but maybe
> I misunderstood this?
I my opinion the best solution for this problem is to have the same lookup
mechanism we've had for clocks, regulators, etc and now also GPIOs.
- Lars
next prev parent reply other threads:[~2013-11-29 20:05 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-15 12:54 [PATCH V2] media: i2c: Add ADV761X support Valentine Barshak
2013-11-19 9:50 ` Hans Verkuil
2013-11-20 10:14 ` Valentine
2013-11-20 11:19 ` Hans Verkuil
2013-11-20 12:24 ` Valentine
2013-11-20 15:42 ` Hans Verkuil
2013-11-20 15:53 ` Valentine
2013-11-26 21:28 ` Valentine
2013-11-26 21:43 ` Lars-Peter Clausen
2013-11-26 21:57 ` Valentine
2013-11-26 22:02 ` Lars-Peter Clausen
2013-11-26 22:00 ` Laurent Pinchart
2013-11-26 22:03 ` Lars-Peter Clausen
2013-11-26 22:03 ` Laurent Pinchart
2013-11-26 22:06 ` Lars-Peter Clausen
2013-11-29 20:07 ` Lars-Peter Clausen
2013-11-27 8:21 ` Hans Verkuil
2013-11-27 9:59 ` Lars-Peter Clausen
2013-11-27 11:26 ` Hans Verkuil
2013-11-27 10:29 ` Valentine
2013-11-27 11:18 ` Hans Verkuil
2013-11-27 11:39 ` Laurent Pinchart
2013-11-27 12:14 ` Hans Verkuil
2013-11-27 12:32 ` Valentine
2013-11-27 13:07 ` Lars-Peter Clausen
2013-11-27 13:46 ` Valentine
2013-11-27 16:40 ` Laurent Pinchart
2013-11-27 16:40 ` Laurent Pinchart
2013-11-27 16:48 ` Lars-Peter Clausen
2013-11-27 16:48 ` Lars-Peter Clausen
2013-11-29 10:37 ` Linus Walleij
2013-11-29 10:37 ` Linus Walleij
2013-11-29 10:45 ` Lars-Peter Clausen
2013-11-29 10:45 ` Lars-Peter Clausen
2013-11-29 12:14 ` Valentine
2013-11-29 12:14 ` Valentine
2013-11-29 13:46 ` Linus Walleij
2013-11-29 13:46 ` Linus Walleij
2013-11-29 13:42 ` Linus Walleij
2013-11-29 13:42 ` Linus Walleij
2013-11-29 13:48 ` Lars-Peter Clausen
2013-11-29 13:48 ` Lars-Peter Clausen
2013-11-29 19:52 ` Linus Walleij
2013-11-29 19:52 ` Linus Walleij
2013-11-29 20:03 ` Laurent Pinchart
2013-11-29 20:03 ` Laurent Pinchart
2013-11-29 20:05 ` Lars-Peter Clausen [this message]
2013-11-29 20:05 ` Lars-Peter Clausen
2013-11-29 20:09 ` Linus Walleij
2013-11-29 20:09 ` Linus Walleij
2013-11-27 14:50 ` Lars-Peter Clausen
2013-11-27 16:29 ` Laurent Pinchart
2013-11-27 16:32 ` Laurent Pinchart
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=5298F3A1.7070503@metafoo.de \
--to=lars@metafoo.de \
--cc=linux-arm-kernel@lists.infradead.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.