On Thu, Jul 21, 2016 at 2:15 PM, Pantelis Antoniou
[off-list ref] wrote:

Hi Rob,

quoted

On Jul 21, 2016, at 22:09 , Rob Herring [off-list ref] wrote:

On Thu, Jul 21, 2016 at 9:14 AM, Pantelis Antoniou
[off-list ref] wrote:

quoted

Hi David,

quoted

On Jul 21, 2016, at 16:42 , David Gibson [off-list ref] wrote:

On Wed, Jul 20, 2016 at 11:59:44PM +0300, Pantelis Antoniou wrote:

quoted

Hi David,

Spent some time looking at this, and it looks like it’s going to the right direction.

Comments inline.

quoted

On Jul 18, 2016, at 17:20 , David Gibson [off-list ref] 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.

[...]

quoted

quoted

quoted

quoted

           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

quoted

;

                   };

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.

Is interrupt-map enough to cover all our cases? On all the cases that I see it
used is in the context of PCI or some sort of bus.

I think it should be. IIRC, one of the ARM, Ltd. boards uses it in a
non-PCI context.

Is the example above well defined? As far as I can tell interrupt-controller is not
needed.

interrupt-controller should actually be dropped as that is supposed to
be mutually exclusive to interrupt-map, but I think the kernel doesn't
care.

Rob