From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755484AbcHYSYD (ORCPT ); Thu, 25 Aug 2016 14:24:03 -0400 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:59926 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753174AbcHYSYA (ORCPT ); Thu, 25 Aug 2016 14:24:00 -0400 Date: Thu, 25 Aug 2016 13:51:35 -0400 From: Rich Felker To: Mark Rutland Cc: Thomas Gleixner , Daniel Lezcano , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org, Rob Herring , Marc Zyngier Subject: Re: [PATCH v6 2/2] clocksource: add J-Core timer/clocksource driver Message-ID: <20160825175135.GC15995@brightrain.aerifal.cx> References: <57BDCE5D.2050609@linaro.org> <20160824174001.GW15995@brightrain.aerifal.cx> <20160825145650.GA15995@brightrain.aerifal.cx> <20160825163805.GA8524@remoulade> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160825163805.GA8524@remoulade> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 25, 2016 at 05:38:06PM +0100, Mark Rutland wrote: > On Thu, Aug 25, 2016 at 10:56:50AM -0400, Rich Felker wrote: > > On Thu, Aug 25, 2016 at 10:07:08AM +0200, Thomas Gleixner wrote: > > > On Wed, 24 Aug 2016, Rich Felker wrote: > > As for this topic, what happened is that, after the first and second > > time of expressing confusion about how the infrastructure did not make > > sense and whether I should even be using it, I did not get anything > > resembling an explanation of why it's the way it is or why I might be > > wrong in thinking it's a bug, and so I went forward with the > > assumption that is was just a bug. Now that Mark Rutland has explained > > it well (and with your additional explanation below in your email), I > > see what the motivation was, but I still think it could be done in a > > less-confusing and more-consistent way that doesn't assume ARM-like > > irq architecture. > > The fun this is that right until the point you sent this patch, it was > consistent for all hardware that we support and were aware of. For others, it > is your hardware that is the confusing case. ;) > > In future, it's better to state 'this doesn't seem to match my hardware' rather > than 'this is misdesigned'. Ideally, with a description of how your hardware > works, as that's the thing no-one else is familiar with. OK. What I meant is "it's not sufficiently general". I usually come at these things not from a particular preconception of how it is/should-be done on some archs I'm familiar with, but minimizing unnecessary (i.e. not beneficial to performance or correctness or simplicity) assumptions at the subsystem level about how hardware could work. > > > If your particular hardware has the old scheme of seperate interrupt numbers > > > for per cpu interrupts, then you can simply use the normal interrupt scheme > > > and request a seperate interrupt per cpu. > > > > Nominally it uses the same range of hardware interrupt numbers for all > > (presently both) cpus, but some of them get delivered to a specific > > cpu associated with the event (presently, IPI and timer; IPI is on a > > fixed number at synthesis time but timer is runtime configurable) > > while others are conceptually deliverable to either cpu (presently > > only delivered to cpu0, but that's treated as an implementation > > detail). > > Given you say it's delivered to the CPU associated with the event (and you have > different PIT bases per-cpu), it sounds like your timer interrupt is percpu, > it's just that the hwirq number can be chosen by software. It's what I would call percpu in the hardware, but I'm not convinced that the Linux irq subsystem's "percpu" stuff models it in a way that fits the hw, nor that it's in any way necessary. > > It currently works requesting the irq with flags that ensure the > > handler runs on the same cpu it was delivered on, without using any > > other percpu irq framework. If you have concerns about ways this could > > break and want me to make the drivers do something else, I'm open to > > suggestions. > > As I suggested, I don't think that this is right, and you need some mechanism > to describe to the kernel that the interrupt is percpu (e.g. a flag in the > interrupt-specifier in DT). Thomas seemed to think it's okay as-is. Can you describe what you expect could go wrong by using request_irq rather than the ARM-style percpu irq framework? Rich