lkml.org 
[lkml]   [2014]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3.18-rc3 v9 5/5] arm: smp: Handle ipi_cpu_backtrace() using FIQ (if available)
On 01/12/14 13:54, Tim Sander wrote:
>> Look, in my mind it is very simple. If you are using CONFIG_FIQ on a
>> SMP platform, your life will be very difficult. The FIQ code enabled
>> by that symbol is not designed to be used on SMP systems, *period*.
> Well the only extra thing you had to do is set up the FIQ registers on every
> cpu, but i would not call that very difficult. Other than that i am not aware of
> any problems that are not also present on a uniprocessor system. So i have a
> hard time following your reasoning why SMP is different from UP in regard to
> the CONFIG_FIQ.
>
>> If you decide to enable CONFIG_FIQ, and you use that code on a SMP
>> platform, I'm going to say right now so it's totally clear: if you
>> encounter a problem, I don't want to know about it. The code is not
>> designed for use on that situation.
> Even with using the FIQ on a Linux SMP system you have not heard from me
> before, as i knew that this is not your problem (and that is not to say that
> there where none!). The only interface Linux has been making available is
> set_fiq_handler. So it was clear that the FIQ is its own domain otherwise
> untouched by the kernel. Now the line gets blurried with the linux kernel
> moving to use the FIQ. And with the descicions forthcoming its not only
> grabbing land it also claims a previous public path for its own. So it doesn't
> help that its planting some flowers along the way. So please be nice to the
> natural inhabitants...

Surely only upstream code could claim to be a natural inhabitant.

Whenever I've been working on code that, for whatever reason, cannot be
upstreamed I'd probably best be regarded as a tourist.


> And i really don't get it, that neither ARM nor the kernel community sees fast
> interrupts as a worthwhile usecase. Unfortunatly the interrupt latencies with
> Linux are at least a order of magnitude higher than the pure hardware even
> with longer pipelines can deliver.
>
>> Therefore, as far as I'm concerned, the two facilities are mututally
>> exclusive.
> Well can't have the cake and eat it too.
>
>> I had thought about whether the IPI FIQ should be disabled when a
>> replacement FIQ handler is installed, I deem it not to be a use case
>> that the mainline kernel needs to be concerned about.
> That would be nice.

Just to be clear, this is exactly the dynamic switching that I mentioned
a couple of mails ago.

As I said such code should not especially hard to write but, with the
current mainline kernel, the code would be unreachable and, as a result,
likely also to be more or less untested.


>>> Yes, but if the FIQ handler is also used for IPI, set_fiq_handler gets IPI
>>> interrupts (with the patch starting this thread)? So i think that the
>>> patch
>>> needs to look like:
>>> --- a/arch/arm/kernel/traps.c
>>> +++ b/arch/arm/kernel/traps.c
>>> @@ -483,6 +483,9 @@ asmlinkage void __exception_irq_entry
>>> handle_fiq_as_nmi(struct pt_regs *regs)
>>> +#ifndef CONFIG_FIQ
>>>
>>> #ifdef CONFIG_ARM_GIC
>>>
>>> gic_handle_fiq_ipi();
>>>
>>> #endif
>>>
>>> +#endif
>>
>> No. With a single zImage kernel, you could very well have SMP and FIQ
>> both enabled, but have a non-SMP platform using FIQ, but also support
>> SMP platforms as well. Your change prevents that happening.
> Ah, well i have to get used to this "new" devicetree thingy, where one size
> fits all...
>
> Still if you boot a single process system which has FIQ available and has a
> GIC with such a kernel, then you also reprogramm the IPI's as FIQs. But i
> guess thats not a problem as Linux does not self IPI the kernel as other os'es
> do?


>
> Best regards
> Tim
>



\
 
 \ /
  Last update: 2014-12-01 15:41    [W:1.328 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site