On 01/18/2016 08:23 PM, Alexandre Belloni wrote: > Hi, Hi, >>> I'd say that the proper solution would still be to implement the virtual >>> irqchip because this would still hit people not wanting to use the TCB as >>> their clock source. >> >> why wouldn't people not want that? > > Because they may be using the TCBs for something else: PWM, frequency > measure, quadrature decoder... Oh okay. >> For a virtual irqchip you would need a mask/unmask register in order to >> individual disable/enable the irq and you need something to figure out >> which one of the three is active. You don't have all those things, do >> you? >> > > The proposed solution was software only. It mainly consisted in a simple > irq demuxer. Well, if it works properly and does not lead to any new bugs or anything else then nobody will mind I guess. >> All in all, care to forwarded the working pieces from -RT patch set >> upstream? I problem I have here is mostly that I can't the patches on >> actual hardware. Disabling the PIT and running on the other clocksource >> isn't that -RT specific after all :) > > I'd say that the only remaining part is the IRQ freeing/requesting but > as I said, this can't land in mainline as is. I still plan to work on > that later. > I'd say that most people running linux on at91 are already using the tcb > as the clocksource, this is already available in the mainline and is the > default unless the TCBs are used for something else. Wasn't there one of the patches to increase the frequency of the TCB clocksource from the default to something higher? Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
