Hi Finn,
Am 17.11.2018 um 11:49 schrieb Finn Thain:
On Fri, 16 Nov 2018, Russell King - ARM Linux wrote:
The EBSA110 is probably in a similar boat - I don't remember whether it
had 16MB or 32MB as the maximal amount of memory, but memory was getting
tight with some kernels even running a
On Fri, 16 Nov 2018, Russell King - ARM Linux wrote:
>
> The EBSA110 is probably in a similar boat - I don't remember whether it
> had 16MB or 32MB as the maximal amount of memory, but memory was getting
> tight with some kernels even running a minimalist userspace.
>
> So, it's probably time
On Thu, Nov 15, 2018 at 03:12:17PM +1100, Finn Thain wrote:
> The thread went way off-topic when Christoph took the opportunity to
> suggest the removal of RPC and EBSA110. That doesn't interest me.
I suspect that is the right solution - I've been trying to get 4.19
to boot on my RPC and it's
On Wed, 14 Nov 2018, Russell King - ARM Linux wrote:
> However, I now see (having searched mailing lists) what you are trying
> to do - you have _not_ copied me or the mailing lists I'm on with your
> cover message, so I'm *totally* lacking in the context of your patch
> series, particularly
On 14/11/18 8:58 PM, Russell King - ARM Linux wrote:
Are you saying that's not possible on arm, because the current timer rundown
counter can't be read while the timer is running?
If I were to run a second timer at higher rate for clocksource, but keeping
the 10 ms timer as clock event
On Wed, Nov 14, 2018 at 03:58:36PM +0100, Geert Uytterhoeven wrote:
> Hi Russell,
>
> On Wed, Nov 14, 2018 at 3:16 PM Russell King - ARM Linux
> wrote:
> > On Wed, Nov 14, 2018 at 02:17:09PM +1100, Finn Thain wrote:
> > > So, even assuming that you're right about the limitations of single-timer
Hi Russell,
On Wed, Nov 14, 2018 at 3:16 PM Russell King - ARM Linux
wrote:
> On Wed, Nov 14, 2018 at 02:17:09PM +1100, Finn Thain wrote:
> > So, even assuming that you're right about the limitations of single-timer
> > platforms in general, removal of arch_gettimeoffset wouldn't require the
> >
On Wed, Nov 14, 2018 at 02:17:09PM +1100, Finn Thain wrote:
> On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
>
> >
> > A clocksource provides a cycle counter that monotonically changes and
> > does not wrap between clockevent events.
> >
> > A clock event is responsible for providing
On Mon, Nov 12, 2018 at 03:12:39PM +1100, Finn Thain wrote:
> Implementations of arch_gettimeoffset are generally not re-entrant
> and assume that interrupts have been disabled. Unfortunately this
> pre-condition got broken in v2.6.32.
To me, it looks way worse than what you think.
The original
On Wed, Nov 14, 2018 at 02:35:29PM +1300, Michael Schmitz wrote:
> So we'd still have to use jiffies + interpolation from the current timer
> rundown counter as clocksource (since that will be monotonous and won't
> wrap)?
>
> The way Finn did the clocksource for m68k, the clocksource counter
On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
>
> A clocksource provides a cycle counter that monotonically changes and
> does not wrap between clockevent events.
>
> A clock event is responsible for providing events to the system when
> some work is needing to be done, limited by the
On 14/11/18 12:43 PM, Russell King - ARM Linux wrote:
On Wed, Nov 14, 2018 at 08:55:37AM +1100, Finn Thain wrote:
On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
On Tue, Nov 13, 2018 at 02:39:00PM +1100, Finn Thain wrote:
You could remove the old arch_gettimeoffset API without
On Wed, Nov 14, 2018 at 08:55:37AM +1100, Finn Thain wrote:
> On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
>
> > On Tue, Nov 13, 2018 at 02:39:00PM +1100, Finn Thain wrote:
> > >
> > > You could remove the old arch_gettimeoffset API without dropping any
> > > platforms.
> > >
> > > If
On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
> On Tue, Nov 13, 2018 at 02:39:00PM +1100, Finn Thain wrote:
> >
> > You could remove the old arch_gettimeoffset API without dropping any
> > platforms.
> >
> > If no-one converts a given platform to the clocksource API it would mean
> >
On Tue, Nov 13, 2018 at 02:39:00PM +1100, Finn Thain wrote:
> On Mon, 12 Nov 2018, Christoph Hellwig wrote:
>
> > On Mon, Nov 12, 2018 at 03:12:39PM +1100, Finn Thain wrote:
> > > Implementations of arch_gettimeoffset are generally not re-entrant and
> > > assume that interrupts have been
On Mon, 12 Nov 2018, Christoph Hellwig wrote:
> On Mon, Nov 12, 2018 at 03:12:39PM +1100, Finn Thain wrote:
> > Implementations of arch_gettimeoffset are generally not re-entrant and
> > assume that interrupts have been disabled. Unfortunately this
> > pre-condition got broken in v2.6.32.
> >
On Mon, Nov 12, 2018 at 03:12:39PM +1100, Finn Thain wrote:
> Implementations of arch_gettimeoffset are generally not re-entrant
> and assume that interrupts have been disabled. Unfortunately this
> pre-condition got broken in v2.6.32.
>
> Fixes: 5cfc8ee0bb51 ("ARM: convert arm to
Implementations of arch_gettimeoffset are generally not re-entrant
and assume that interrupts have been disabled. Unfortunately this
pre-condition got broken in v2.6.32.
Fixes: 5cfc8ee0bb51 ("ARM: convert arm to arch_gettimeoffset()")
Signed-off-by: Finn Thain
---
arch/arm/mach-ebsa110/core.c |
18 matches
Mail list logo
