All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Charkov <alchark@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] clocksource/vt8500: Add register R/W functions
Date: Mon, 21 Dec 2015 09:54:36 +0000 (UTC)	[thread overview]
Message-ID: <loom.20151221T103308-220@post.gmane.org> (raw)
In-Reply-To: 1450650492-18996-5-git-send-email-v1ron@mail.ru

Roman Volkov <v1ron <at> mail.ru> writes:

> 
> From: Roman Volkov <rvolkov <at> v1ros.org>
> 
> vt8500 timer requires special synchronization for accessing some of its
> registers. Define special read and write functions to handle this process
> transparently.

Maybe introduce such accessor functions (conditionally) into the PXA driver
and kill this one altogether then?

If I understood you right, this extra bus synchronization is the only thing
that makes vt8500 different from PXA, so merging the two files right away
might be a better long-term option.

> To perform a read from the Timer Count register, user must write a one
> to the Timer Control register and wait for completion flag by polling the
> Timer Read Count Active bit.
> 
> To perform a write to the Count or Match registers, user must poll the
> write completion flag for the corresponding register to ensure that the
> previous write completed and then write the actual value.
> 
> Signed-off-by: Roman Volkov <rvolkov <at> v1ros.org>
> ---
>  drivers/clocksource/vt8500_timer.c | 90
+++++++++++++++++++++++++++-----------
>  1 file changed, 65 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/clocksource/vt8500_timer.c
b/drivers/clocksource/vt8500_timer.c
> index 7649852..4d7513f 100644
> --- a/drivers/clocksource/vt8500_timer.c
> +++ b/drivers/clocksource/vt8500_timer.c
>  <at>  <at>  -38,36 +38,75  <at>  <at> 
> 
>  #define VT8500_TIMER_OFFSET	0x0100
>  #define VT8500_TIMER_HZ		3000000
> -#define TIMER_MATCH_VAL		0x0000
> +#define TIMER_MATCH0_VAL	0
> +#define TIMER_MATCH1_VAL	0x04
> +#define TIMER_MATCH2_VAL	0x08
> +#define TIMER_MATCH3_VAL	0x0c
>  #define TIMER_COUNT_VAL		0x0010
>  #define TIMER_STATUS_VAL	0x0014
>  #define TIMER_IER_VAL		0x001c		/* interrupt enable */
>  #define TIMER_CTRL_VAL		0x0020
>  #define TIMER_AS_VAL		0x0024		/* access status */
> -#define TIMER_COUNT_R_ACTIVE	(1 << 5)	/* not ready for read */
> -#define TIMER_COUNT_W_ACTIVE	(1 << 4)	/* not ready for write */
> -#define TIMER_MATCH_W_ACTIVE	(1 << 0)	/* not ready for write */
> -
> -#define timer_readl(addr)	readl_relaxed(regbase + addr)
> -#define timer_writel(v, addr)	writel_relaxed(v, regbase + addr)
> +/* R/W status flags */
> +#define TIMER_COUNT_R_ACTIVE	(1 << 5)
> +#define TIMER_COUNT_W_ACTIVE	(1 << 4)
> +#define TIMER_MATCH3_W_ACTIVE	(1 << 3)
> +#define TIMER_MATCH2_W_ACTIVE	(1 << 2)
> +#define TIMER_MATCH1_W_ACTIVE	(1 << 1)
> +#define TIMER_MATCH0_W_ACTIVE	(1 << 0)
> +
> +#define vt8500_timer_sync(bit)	{ while (readl_relaxed \
> +				    (regbase + TIMER_AS_VAL) & bit) \
> +					cpu_relax(); }

The whole issue around 'loops' counter in these busy waits basically boils
down to whether we would like a way to try and recover from a potential
hardware misbehavior.

You can of course argue that when the system timer misbehaves you already
have bigger issues to worry about, but does a 10 msec limit that was in the
original version really hurt?

>  #define MIN_OSCR_DELTA		16
> 
>  static void __iomem *regbase;
> 
> -static cycle_t vt8500_timer_read(struct clocksource *cs)
> +static void vt8500_timer_write(unsigned long reg, u32 value)

Maybe define this with 'value' first, 'reg' second - to be in line with the
common prototype of writel and such?

Plus if you could take the same name for the macro above (timer_writel) and
this accessor (vt8500_timer_write) that would somewhat reduce extra
additions/deletions in this patch. Same for the read function.

<skip>

>  <at>  <at>  -75,23 +114,24  <at>  <at>  static struct clocksource
clocksource = {
>  static int vt8500_timer_set_next_event(unsigned long cycles,
>  				    struct clock_event_device *evt)
>  {
> -	cycle_t alarm = clocksource.read(&clocksource) + cycles;
> -	while (timer_readl(TIMER_AS_VAL) & TIMER_MATCH_W_ACTIVE)
> -		cpu_relax();
> -	timer_writel((unsigned long)alarm, TIMER_MATCH_VAL);
> +	unsigned long alarm = vt8500_timer_read(TIMER_COUNT_VAL) + cycles;

I personally like the form above better (via clocksource.read) - even if
just for the fact that it's shorter and reduces the number of places where
we use TIMER_COUNT_VAL definition.

Any specific reasons to rewrite it?

> -	if ((signed)(alarm - clocksource.read(&clocksource)) <= MIN_OSCR_DELTA)
> +	vt8500_timer_write(TIMER_MATCH0_VAL, alarm);
> +	if ((signed)(alarm - vt8500_timer_read(
> +				TIMER_COUNT_VAL)) <= MIN_OSCR_DELTA) {

Same here.

<skip>

Best regards,
Alexey


  reply	other threads:[~2015-12-21 10:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-20 22:28 [PATCH 0/4] clocksource/vt8500: Fix hangs in small delays Roman Volkov
2015-12-20 22:28 ` Roman Volkov
2015-12-20 22:28 ` [PATCH 1/4] clocksource/vt8500: Use [read\write]l_relaxed() Roman Volkov
2015-12-20 22:28   ` Roman Volkov
2015-12-20 22:28 ` [PATCH 2/4] clocksource/vt8500: Remove the 'loops' variable Roman Volkov
2015-12-20 22:28   ` Roman Volkov
2015-12-20 22:28 ` [PATCH 3/4] clocksource/vt8500: Use MIN_OSCR_DELTA from PXA Roman Volkov
2015-12-20 22:28   ` Roman Volkov
2015-12-20 22:28 ` [PATCH 4/4] clocksource/vt8500: Add register R/W functions Roman Volkov
2015-12-20 22:28   ` Roman Volkov
2015-12-21  9:54   ` Alexey Charkov [this message]
2015-12-21  8:29 ` [PATCH 0/4] clocksource/vt8500: Fix hangs in small delays Roman Volkov
2015-12-21  8:29   ` Roman Volkov
2015-12-21 20:33   ` Roman Volkov
2015-12-21 20:33     ` Roman Volkov
2015-12-22  9:09     ` Alexey Charkov
2015-12-22  9:09       ` Alexey Charkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=loom.20151221T103308-220@post.gmane.org \
    --to=alchark@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.