On 01/18/2016 08:23 PM, Alexandre Belloni wrote:

Hi,

Hi,

quoted

quoted

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.

quoted

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.

quoted

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