Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1443808

Re: [PATCH v3 04/12] of: add J-Core timer bindings

From Rich Felker <dalias@libc.org>
Newsgroups linux.kernel
Subject Re: [PATCH v3 04/12] of: add J-Core timer bindings
Date 2016-07-15 00:20 +0200
Message-ID <rUX98-72G-17@gated-at.bofh.it> (permalink)
References (3 earlier) <rFiAW-3aE-39@gated-at.bofh.it> <rFmXU-6a2-3@gated-at.bofh.it> <rFpM5-7QO-5@gated-at.bofh.it> <rFJB8-3vM-19@gated-at.bofh.it> <rNkcy-7lw-25@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Jun 23, 2016 at 05:16:08PM -0400, Rich Felker wrote:
> On Thu, Jun 02, 2016 at 05:44:25PM -0500, Rob Herring wrote:
> > > > > In theory it would even be possible to just require a DT node per
> > > > > cpulocal timer, but I didn't see a good way to make the bindings
> > > > > represent the relationship to cpus or to make the driver handle irqs
> > > > > correctly for such a setup, so I'd need a viable proposal for how that
> > > > > could be done to even consider such an approach.
> > > > 
> > > > Yeah, there's not really a standard way to map per cpu blocks to cpus.
> > > > We could, but doesn't really seem necessary here.
> > > > 
> > > > For the irqs, percpu irqs doesn't help you?
> > > 
> > > What I mean is that, if there were a separate device node and driver
> > > instance per cpu, they'd all want to register the same irq just to
> > > handle it on their own cpu, so we'd have a lot of spurious handlers
> > > running. The right way to model this, I think, would be as a virtual
> > > irqchip that's the irq parent of all the timer nodes, and that
> > > multiplexes the real irq to one virq per cpu (where the current cpu id
> > > becomes the irq number in its irq domain). But that's a lot of virtual
> > > infrastructure just for the sake of modelling each percpu timer as its
> > > own DT node and I don't think it makes sense to do it that way.
> > 
> > I would have thought your interrupt controller did all this. On the ARM 
> > GIC for example, you have the same irq number but there is a per cpu 
> > interface and really N (== # cpus) physical irq lines.
> 
> I've looked at the ARM GIC code and bindings and I don't see where the
> per-cpu interrupt interfaces are modelled with multiple interrupt
> controller nodes or irq domains. It looks to me like it just uses a
> single interrupt controller/domain with percpu irq. Does that match
> your understanding?

Ping.

I want to submit this again for the upcoming merge window and need to
know whether you still want me to pursue different approaches.

Rich

Back to linux.kernel | Previous | Next | Find similar | Unroll thread


Thread

Re: [PATCH v3 04/12] of: add J-Core timer bindings Rich Felker <dalias@libc.org> - 2016-07-15 00:20 +0200

csiph-web