[JUST RFC] ARM: DIGIC: add csrc-dummy

[Alexander Aring]

On Mon, Dec 16, 2013 at 12:40:13AM +0400, Antony Pavlov wrote:
> On Sun, 15 Dec 2013 20:30:16 +0100
> Alexander Aring <alex.aring at gmail.com> wrote:
> 
> > Hi Antony,
> > 
> > On Sun, Dec 15, 2013 at 07:02:05PM +0400, Antony Pavlov wrote:
> > > The clocksource csrc-timer driver that uses DIGIC
> > > hardware TIMER2 perfectrly works on Canon A1100,
> > > but does not works on Canon EOS 600D.
> > > IMHO we need additional timer initialisation.
> > > 
> > > This patch introduces a quick-and-dirty termporary
> > > solution for this situation: a clocksource driver that
> > > does not use any hardware at all.
> > > 
> > > Also this driver is very handy for running barebox
> > > on Magic Lantern EOS qemu-based emulator as
> > > the emulator does not realize timer counter register at all!
> > > 
> > > Signed-off-by: Antony Pavlov <antonynpavlov at gmail.com>
> > > ---
> > >  arch/arm/mach-digic/Kconfig      |  3 +++
> > >  arch/arm/mach-digic/Makefile     |  1 +
> > >  arch/arm/mach-digic/csrc-dummy.c | 49 ++++++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 53 insertions(+)
> > >  create mode 100644 arch/arm/mach-digic/csrc-dummy.c
> > > 
> > > diff --git a/arch/arm/mach-digic/Kconfig b/arch/arm/mach-digic/Kconfig
> > > index 557cad4..d0524bc 100644
> > > --- a/arch/arm/mach-digic/Kconfig
> > > +++ b/arch/arm/mach-digic/Kconfig
> > > @@ -16,4 +16,7 @@ config ARCH_TEXT_BASE
> > >  config DIGIC_CSRC_TIMER
> > >  	bool
> > >  
> > > +config DIGIC_CSRC_DUMMY
> > > +	bool
> > > +
> > >  endif
> > > diff --git a/arch/arm/mach-digic/Makefile b/arch/arm/mach-digic/Makefile
> > > index 1d7cb72..31e5ac1 100644
> > > --- a/arch/arm/mach-digic/Makefile
> > > +++ b/arch/arm/mach-digic/Makefile
> > > @@ -1,2 +1,3 @@
> > >  obj-y += core.o
> > >  obj-$(CONFIG_DIGIC_CSRC_TIMER) += csrc-timer.o
> > > +obj-$(CONFIG_DIGIC_CSRC_DUMMY) += csrc-dummy.o
> > > diff --git a/arch/arm/mach-digic/csrc-dummy.c b/arch/arm/mach-digic/csrc-dummy.c
> > > new file mode 100644
> > > index 0000000..68c68a3
> > > --- /dev/null
> > > +++ b/arch/arm/mach-digic/csrc-dummy.c
> > > @@ -0,0 +1,49 @@
> > > +/*
> > > + * Copyright (C) 2013 Antony Pavlov <antonynpavlov at gmail.com>
> > > + *
> > > + * This file is part of barebox.
> > > + * See file CREDITS for list of people who contributed to this project.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2
> > > + * as published by the Free Software Foundation.
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > + * GNU General Public License for more details.
> > > + *
> > > + */
> > > +
> > > +#include <init.h>
> > > +#include <clock.h>
> > > +
> > > +#include <stdio.h>
> > > +
> > > +static uint64_t dummy_counter;
> > > +
> > > +static uint64_t dummy_cs_read(void)
> > > +{
> > > +	dummy_counter += 2000;
> > > +	return dummy_counter;
> > > +}
> > > +
> > So if I understand it right, you assume here that the instructions to
> > read this value will take 0.02 ms?
> 
> It is not quite. I don't assume initially the time to read this value.
> This value ("2000") was a suboptimal value for __specific board__
> under the __specific circumstances__.
> I have selected this value after several experiments.
>

mhh, I am thinking maybe about some calculation with clock ticks. Maybe
some "nop" operations and inline assembler. In the processor datasheet
should stand how long one "nop" instruction will take. Then you can
increase the dummy_counter intervall and waits longer, that should
deincrease the amount of failure (I think).

The current solution has the smallest clock resolution (because you
don't make any "nops" instructions).

It isn't a quite solution as well and I don't know if this still works
with your qemu emulation. It's just a notice for an alternative and an
idea. It's the same idea like you already have...


Another question:
How do the original firmware do this? I think there are some date/time
information. Is there any additional hardware?

- Alex