Thank you for the review. I understand your NACK. But I'd like to just fix the part of smp_call_function() in the next version. You can simply ignore it.
> -----Original Message----- > From: Mark Rutland [mailto:[email protected]] > Sent: Friday, May 11, 2018 7:39 PM > To: ��ȣ�� <[email protected]> > Cc: 'Hoeun Ryu' <[email protected]>; 'Will Deacon' > <[email protected]>; [email protected]; linux- > [email protected] > Subject: Re: [PATCH] armpmu: broadcast overflow irq on multi-core system > having one muxed SPI for PMU. > > On Fri, May 11, 2018 at 08:20:49AM +0900, ��ȣ�� wrote: > > Thank you for the reply. > > > > > -----Original Message----- > > > From: Mark Rutland [mailto:[email protected]] > > > Sent: Thursday, May 10, 2018 7:21 PM > > > To: Hoeun Ryu <[email protected]> > > > Cc: Will Deacon <[email protected]>; Hoeun Ryu <[email protected]>; > > > [email protected]; [email protected] > > > Subject: Re: [PATCH] armpmu: broadcast overflow irq on multi-core > system > > > having one muxed SPI for PMU. > > > > Muxing the PMU IRQs is a really broken system design, and there's no > good > > > way of supporting it. > > > > What we should do for such systems is: > > > > > > * Add a flag to the DT to describe that the IRQs are muxed, as this > > > cannot be probed. > > > > > > * Add hrtimer code to periodically update the counters, to avoid > > > overflow (e.g. as we do in the l2x0 PMU). > > > > > > * Reject sampling for such systems, as this cannot be done reliably or > > > efficiently. > > > > > > NAK to broadcasting the IRQ -- there are a number of issues with the > > > general approach. > > > > The second solution would be good if sampling is necessary even like > those > > systems. > > Please note that I mean *all* of the above. There would be no sampling > on systems with muxed PMU IRQs, since there's no correlation between > overflow events and the hrtimer interrupts -- the results of sampling > would be misleading. > > > Actually I'm working on FIQ available ARM32 system and trying to enable > the > > hard lockup detector by routing the PMU IRQ to FIQ. > > Because of that, I really need the interrupt event if it is a muxed SPI, > > beside I also need to make an dedicated IPI FIQ to broadcast the IRQ in > > this approach. > > What would you do if you were in the same situation ? > > I don't think that this can work with a muxed IRQ, sorry. > > It would be better to use some kind of timer. > > [...] > > > > Futher, If you ever encounter a case where you need to avoid > preemption > > > across enabling IRQs, preemption must be disabled *before* enabling > IRQs. > > > > Ah, OK. > > Enabling IRQs can cause scheduling tasks in the end of exception or > other > > scheduling points, right ? > > Yes. If an IRQ was taken *between* enabling IRQs and disabling > preemption, preemption may occur as part of the exception return. > > Thanks, > Mark.
