On Fri, Nov 06, 2020 at 01:52:01PM +1100, Finn Thain wrote:
> On Fri, 23 Oct 2020, Geert Uytterhoeven wrote:
>
> > > > > The arm/rpc timer seems to be roughly in the same category as most
> > > > > of the m68k ones or the i8253 counter on a PC. It's possible that
> > > > > some of them could
On Fri, 30 Oct 2020, Greg Ungerer wrote:
> >
> > > ...
> > > > The other 11 platforms in that category also have 'synthetic'
> > > > clocksources derived from a timer reload interrupt. In 3 cases,
> > > > the clocksource read method does not (or can not) check for a
> > > > pending counter
On Fri, 23 Oct 2020, Geert Uytterhoeven wrote:
> > > > The arm/rpc timer seems to be roughly in the same category as most
> > > > of the m68k ones or the i8253 counter on a PC. It's possible that
> > > > some of them could use the same logic as
> > > > drivers/clocksource/i8253.o as long as
On 30/10/20 10:41 am, Finn Thain wrote:
On Fri, 23 Oct 2020, Arnd Bergmann wrote:
On Sun, Oct 18, 2020 at 2:55 AM Finn Thain wrote:
On Thu, 15 Oct 2020, Arnd Bergmann wrote:
On Thu, Oct 15, 2020 at 3:19 AM Finn Thain wrote:
On Sat, 10 Oct 2020, Arnd Bergmann wrote:
That configuration
On Fri, 23 Oct 2020, Arnd Bergmann wrote:
> On Sun, Oct 18, 2020 at 2:55 AM Finn Thain
> wrote:
> > On Thu, 15 Oct 2020, Arnd Bergmann wrote:
> > > On Thu, Oct 15, 2020 at 3:19 AM Finn Thain
> > > wrote:
> > > > On Sat, 10 Oct 2020, Arnd Bergmann wrote:
> >
> > That configuration still
On Fri, Oct 23, 2020 at 11:24 AM Geert Uytterhoeven
wrote:
> On Fri, Oct 23, 2020 at 9:52 AM Arnd Bergmann wrote:
> > On Sun, Oct 18, 2020 at 2:55 AM Finn Thain
> > wrote:
> > > On Thu, 15 Oct 2020, Arnd Bergmann wrote:
> > > > On Thu, Oct 15, 2020 at 3:19 AM Finn Thain
> > > > wrote:
> > >
Hi Arnd,
On Fri, Oct 23, 2020 at 9:52 AM Arnd Bergmann wrote:
> On Sun, Oct 18, 2020 at 2:55 AM Finn Thain wrote:
> > On Thu, 15 Oct 2020, Arnd Bergmann wrote:
> > > On Thu, Oct 15, 2020 at 3:19 AM Finn Thain
> > > wrote:
> > > > On Sat, 10 Oct 2020, Arnd Bergmann wrote:
> >
> > That
On Thu, 15 Oct 2020, Arnd Bergmann wrote:
> On Thu, Oct 15, 2020 at 3:19 AM Finn Thain wrote:
> >
> > On Sat, 10 Oct 2020, Arnd Bergmann wrote:
> >
> > > > Perhaps patch 13 does not belong in this series (?).
> > > >
> > > > All m68k platforms will need conversion before the TODO can be removed
On Sat, 10 Oct 2020, Arnd Bergmann wrote:
> > Perhaps patch 13 does not belong in this series (?).
> >
> > All m68k platforms will need conversion before the TODO can be removed
> > from Documentation/features/time/clockevents/arch-support.txt.
>
> Yes, correct. I marked this patch as RFC
On Sat, Oct 10, 2020 at 12:21 AM Finn Thain wrote:
>
> Hi Arnd,
>
> Perhaps patch 13 does not belong in this series (?).
>
> All m68k platforms will need conversion before the TODO can be removed
> from Documentation/features/time/clockevents/arch-support.txt.
Yes, correct. I marked this patch
Hi Arnd,
Perhaps patch 13 does not belong in this series (?).
All m68k platforms will need conversion before the TODO can be removed
from Documentation/features/time/clockevents/arch-support.txt.
On m68k, HZ is fixed at 100. Without addressing that, would there be any
benefit from adopting
Now that the infrastructure allows kernels to have both legacy timer
ticks and clockevent drivers in the same image, start by moving one
platform to generic clockevents.
As qemu only supports the q800 platform among the classic m68k, use
that as an example.
I also tried adding oneshot mode,
12 matches
Mail list logo
