mbox series

[v7,0/7] clocksource: rework Atmel TCB timer driver

Message ID 20180913113024.3571-1-alexandre.belloni@bootlin.com (mailing list archive)
Headers show
Series clocksource: rework Atmel TCB timer driver | expand

Message

Alexandre Belloni Sept. 13, 2018, 11:30 a.m. UTC
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)
 - 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

Comments

Daniel Lezcano Sept. 22, 2018, 11:29 a.m. UTC | #1
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
>
Alexandre Belloni Sept. 25, 2018, 8:14 p.m. UTC | #2
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.
Sebastian Andrzej Siewior Nov. 8, 2018, 12:43 p.m. UTC | #3
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
Alexandre Belloni Nov. 8, 2018, 2:09 p.m. UTC | #4
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.
Sebastian Andrzej Siewior Nov. 8, 2018, 2:30 p.m. UTC | #5
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