Hi.

2017-09-13 0:44 GMT+09:00 David Daney [off-list ref]:

On 09/12/2017 07:03 AM, Linus Walleij wrote:

quoted

On Thu, Sep 7, 2017 at 1:42 PM, Masahiro Yamada
[off-list ref] wrote:

quoted

This GPIO controller device is used on UniPhier SoCs.

It also serves as an interrupt controller, but interrupt signals are
just delivered to the parent irqchip without any latching or OR'ing.
This is implemented by using hierarchy IRQ domain.

Implementation note:
Unfortunately, the IRQ mapping from this controller to the parent is
random. (48, 49, ..., 63, 154, 155, ...)
If "interrupts" property is used, IRQ resources may be statically
allocated when platform devices are populated from DT.  This can be
a problem for the hierarchy IRQ domain because IRQ allocation must
happen from the outer-most domain up to the root domain in order to
build up the stacked IRQ.  (https://lkml.org/lkml/2017/7/6/758)
Solutions to work around it could be to hard-code parent hwirqs or
to invent a driver-specific DT property.

Here, the new API irq_domain_push_irq() was merged by v4.14-rc1.
It allows to add irq_data to the existing hierarchy.  It will help
to make this driver work whether the parent has already initialized
the hierarchy or not.

Signed-off-by: Masahiro Yamada <redacted>
---

Changes in v4:
   - Add COMPILE_TEST and select IRQ_DOMAIN_HIERARCHY
   - Reimplement irqchip part by using irq_domain_push_irq()

Awesome improvement. There was a build error and I also
would like David Daney to have a look at this so we know we
use things the right way,

It looks correct to me.

I haven't verified it, but I think the OF device-tree probing code for the
platform devices will automatically xlat-and-map all those irqs, so that the
irq_domain_push_irq() is required to get the domain hierarchy properly
configured.  It would be similar to the PCI case where we configure all the
MSI-X and then do the irq_domain_push_irq() in the Cavium ThunderX driver.

If interrupt handling has been verified to work with this driver, I would
say that we are probably using things "the right way".

David.

V4 depends on 5 patches that got negative feedback in irqdomain subsystem.
One more problem for this approach is to virtual IRQs are statically
allocated during the driver probe.
This looks a step backward to me.
Recently, gpio_irqchip migrated to on-the-fly allocation in case some
controllers may have lots of
GPIO lines.


Finally, I came up with another (I think, better) solution.
I think v5 is less controversial,
and works very well in on-the-fly manner.

I am sending it shortly...


-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html