| Age | Commit message (Collapse) | Author |
|---|
|
The sun4i timer can still be ticking when we enable the interrupt.
If another timer is actually used (A7 architected timer, for example),
odds are that the interrupt will eventually fire with the event_handler
pointer being NULL.
The obvious fix it to stop the timer before registering the interrupt.
Observed and tested on sun7i (cubietruck).
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
IRQF_DISABLED is a no-op nowadays, so we can safely remove it.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
We need to wait for at least 2 clock cycles whenever we reprogram our
clockevent timer. Report that the minimum number of ticks we can handle
is 3 ticks, and remove 3 ticks to the interval programmed to reflect
this.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
The interval was firing at was set up at probe time, and only changed in
the set_next_event, and never changed back, which is not really what is
expected.
When enabling the periodic mode, now set an interval to tick every
jiffy.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
The current bring-up code for the timer was overly complicated. The only
thing we need is actually which clock we want to use as source and
that's pretty much all. Let's keep it that way.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
The prescaler is only used when using the internal low frequency
oscillator (at 32kHz). Since we're using the higher frequency oscillator
at 24MHz, we can just remove it.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
The set_next_event and set_mode callbacks share a lot of common code we
can easily factor to avoid duplication and mistakes.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
The next_event logic was setting the next interval to fire in the
current timer value instead of the interval value register, which is
obviously wrong.
Plus, the logic to set the actual value was wrong as well: the interval
register can only be modified when the timer is disabled, and then
enable it back, otherwise, it'll have no effect. Fix this logic as well
since that code couldn't possibly work.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
Even if in our case, this clock was non-gatable, used as a parent clock
for several IPs, it still is a good idea to enable it.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
Use the second timer found on the Allwinner SoCs as a clock source and
sched clock, that were both not used yet on these platforms.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
The name AUTORELOAD was actually pretty bad since it doesn't make the
register reload the previous interval when it expires, but setting this
value pushes the new programmed interval to the internal timer counter.
Rename it to RELOAD instead.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
The macros were not using parenthesis to escape the arguments passed to
them. It is pretty unsafe, so add those parenthesis.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
During the introduction of the Allwinner SoC platforms, sunxi was
initially meant as a generic name for all the variants of the Allwinner
SoC.
It was ok at the time of the support of only the A10 and A13 that
looks pretty much the same, but it's beginning to be troublesome with
the future addition of the Allwinner A31 (sun6i) that is quite
different, and would introduce some weird logic, where sunxi would
actually mean in some case sun4i and sun5i but without sun6i...
Moreover, it makes the compatible strings naming scheme not consistent
with other architectures, where usually for this kind of compability, we
just use the oldest SoC name that has this IP, so let's do just this.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
Marc Zyngier
Maxime Ripard