Message ID | 20180913113024.3571-1-alexandre.belloni@bootlin.com (mailing list archive) |
---|---|
Headers | show |
Series | clocksource: rework Atmel TCB timer driver | expand |
On 13/09/2018 13:30, Alexandre Belloni wrote: > Hi, > > This series reworks the Atmel TCB drivers. It introduces a new driver to handle > the clocksource and clockevent devices. > > This is necessary because: > - the current tcb_clksrc driver is probed too late to be able to be used at > boot and we now have SoCs that don't have a PIT. They currently are not able > to boot a mainline kernel. > - using the PIT doesn't work well with preempt-rt because its interrupt is > shared (in particular with the UART and their interrupt flags are > incompatible) You say for rt the PIT is not suitable because of the shared irq but in the driver, the interrupt is flagged as shared. > - the current solution is wasting some TCB channels > > The plan is to get this driver upstream, then convert the TCB PWM driver to be > able to get rid of the tcb_clksrc driver along with atmel_tclib now that AVR32 > is gone. > > changes in v7: > - fixed a warning when building on 64 bit platforms > > changes in v6: > - rebased on v4.19-rc1 > - separated the clocksource/clockevent and the single clockevent in two > different patches > - removed struct tc_clkevt_device and simply use struct atmel_tcb_clksrc > - removed struct atmel_tcb_info > - moved tcb_clk_get and tcb_irq_get to users > > changes in v5: > - rebased on v4.18-rc1 > - fixed the clock enabling/disabling in atomic context under preempt-rt > > Changes in v4: > - rebased on top of v4.17-rc1 > - fixed an issue when setting max_delta for clockevents_config_and_register > > Alexandre Belloni (7): > ARM: at91: add TCB registers definitions > clocksource/drivers: Add a new driver for the Atmel ARM TC blocks > clocksource/drivers: timer-atmel-tcb: add clockevent device on > separate channel > clocksource/drivers: atmel-pit: make option silent > ARM: at91: Implement clocksource selection > ARM: configs: at91: use new TCB timer driver > ARM: configs: at91: unselect PIT > > arch/arm/configs/at91_dt_defconfig | 2 +- > arch/arm/configs/sama5_defconfig | 2 +- > arch/arm/mach-at91/Kconfig | 25 ++ > drivers/clocksource/Kconfig | 13 +- > drivers/clocksource/Makefile | 3 +- > drivers/clocksource/timer-atmel-tcb.c | 617 ++++++++++++++++++++++++++ > include/soc/at91/atmel_tcb.h | 183 ++++++++ > 7 files changed, 841 insertions(+), 4 deletions(-) > create mode 100644 drivers/clocksource/timer-atmel-tcb.c > create mode 100644 include/soc/at91/atmel_tcb.h >
On 22/09/2018 13:29:48+0200, Daniel Lezcano wrote: > On 13/09/2018 13:30, Alexandre Belloni wrote: > > Hi, > > > > This series reworks the Atmel TCB drivers. It introduces a new driver to handle > > the clocksource and clockevent devices. > > > > This is necessary because: > > - the current tcb_clksrc driver is probed too late to be able to be used at > > boot and we now have SoCs that don't have a PIT. They currently are not able > > to boot a mainline kernel. > > - using the PIT doesn't work well with preempt-rt because its interrupt is > > shared (in particular with the UART and their interrupt flags are > > incompatible) > > You say for rt the PIT is not suitable because of the shared irq but in > the driver, the interrupt is flagged as shared. > Well, it is not simply sharing the interrupt that is an issue, it is the mismatch between the PIT and the UART interrupt flags and that only happens when using preempt-rt. But still, the TCB is flagged as shared because it may be shared between multiple TCB channels (it is the case for the more recent SoCs). However, what happens is that the DBGU UART is always enabled on the boards so when using the PIT, the interrupt is always shared. But, for the TCB, the only driver currently able to use the interrupt is the clockevent driver so the interrupt as almost no chance to actually be shared.
On 2018-09-25 22:14:56 [+0200], Alexandre Belloni wrote: > On 22/09/2018 13:29:48+0200, Daniel Lezcano wrote: > > You say for rt the PIT is not suitable because of the shared irq but in > > the driver, the interrupt is flagged as shared. > > > > Well, it is not simply sharing the interrupt that is an issue, it is the > mismatch between the PIT and the UART interrupt flags and that only > happens when using preempt-rt. This should also happen on !RT with the threadedirq command line switch. The UART will be threaded and the PIT will not, and this is the problem. So we need to split those or disable the UART. The other important thing for RT is the higher resolution of the clocksource/clockevents device (I don't know if this is part of the series or not…). I'm currently replacing the v6 with this v7 in my RT tree. What is the status of this series upstream wise? Sebastian
On 08/11/2018 13:43:27+0100, Sebastian Andrzej Siewior wrote: > On 2018-09-25 22:14:56 [+0200], Alexandre Belloni wrote: > > On 22/09/2018 13:29:48+0200, Daniel Lezcano wrote: > > > You say for rt the PIT is not suitable because of the shared irq but in > > > the driver, the interrupt is flagged as shared. > > > > > > > Well, it is not simply sharing the interrupt that is an issue, it is the > > mismatch between the PIT and the UART interrupt flags and that only > > happens when using preempt-rt. > > This should also happen on !RT with the threadedirq command line switch. > The UART will be threaded and the PIT will not, and this is the problem. > So we need to split those or disable the UART. The other important thing > for RT is the higher resolution of the clocksource/clockevents device (I > don't know if this is part of the series or not…). > It is not part of that series as I prefer to keep the discussion of how to configure that for later. This has been raised previously without any conclusion and I'd really like to see this rework enter upstream soon. > I'm currently replacing the v6 with this v7 in my RT tree. What is the > status of this series upstream wise? > I'll send v8 sometimes next week.
On 2018-11-08 15:09:35 [+0100], Alexandre Belloni wrote: > It is not part of that series as I prefer to keep the discussion of how > to configure that for later. This has been raised previously without any > conclusion and I'd really like to see this rework enter upstream soon. Okay. Does it make sense to keep the lower resolution? > > I'm currently replacing the v6 with this v7 in my RT tree. What is the > > status of this series upstream wise? > > > > I'll send v8 sometimes next week. Thanks. Sebastian