Re: DT connectors, thoughts

[Rob Herring]

On Thu, Jul 21, 2016 at 9:14 AM, Pantelis Antoniou
<pantelis.antoniou@xxxxxxxxxxxx> wrote:
> Hi David,
>
>> On Jul 21, 2016, at 16:42 , David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> On Wed, Jul 20, 2016 at 11:59:44PM +0300, Pantelis Antoniou wrote:
>>> Hi David,
>>>
>>> Spent some time looking at this, and it looks like itâs going to the right direction.
>>>
>>> Comments inline.
>>>
>>>> On Jul 18, 2016, at 17:20 , David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Here's some of my thoughts on how a connector format for the DT could
>>>> be done.  Sorry it's taken longer than I hoped - I've been pretty
>>>> swamped in my day job.
>>>>
>>>> This is pretty early thoughts, but gives an outline of the approach I
>>>> prefer.

[...]

>>>>             i2c: i2c@... {
>>>>             };
>>>>             intc: intc@... {
>>>>                     #interrupt-cells = <2>;
>>>>             };
>>>>     };
>>>>
>>>>     connectors {
>>>>             widget1 {
>>>>                     compatible = "foo,widget-socket";
>>>>                     w1_irqs: irqs {
>>>>                             interrupt-controller;
>>>>                             #address-cells = <0>;
>>>>                             #interrupt-cells = <1>;
>>>>                             interrupt-map-mask = <0xffffffff>;
>>>>                             interrupt-map = <
>>>>                                     0 &intc 7 0
>>>>                                     1 &intc 8 0
>>>>                             >;
>>>>                     };
>>>
>>> This is fine. We need an interrupt controller node.
>>
>> Actually I think we only need an interrupt nexus, not an interrupt
>> controller (in IEEE1275 terminology).  (An interrupt controller would
>> generally require it's own driver, to ack/mask irqs, whereas this just
>> demonstrates the routing to an existing interrupt controller).  Which
>> makes that example slightly incorrect (it shouldn't have the
>> interrupt-controller property).
>
> Hmm, as far as I can tell we only have a concept of an interrupt controller
> in the kernel. An interrupt nexus is something new. We should get by without
> a driver but hacking the interrupt lookup path at DT.

Interrupt nexus is the interrupt-map property which is fully
supported. I'd expect we'll end up with a gpio nexus (i.e. gpio-map)
for connector gpios, too.

Rob