Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1295704 > unrolled thread

[PATCH 0/4] clocksource/vt8500: Fix hangs in small delays

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/4] clocksource/vt8500: Fix hangs in small delays Roman Volkov <v1ron@mail.ru> - 2015-12-20 23:50 +0100
    Re: [PATCH 0/4] clocksource/vt8500: Fix hangs in small delays Roman Volkov <v1ron@mail.ru> - 2015-12-21 09:40 +0100
      Re: [PATCH 0/4] clocksource/vt8500: Fix hangs in small delays Roman Volkov <v1ron@mail.ru> - 2015-12-21 21:40 +0100
        Re: [PATCH 0/4] clocksource/vt8500: Fix hangs in small delays Alexey Charkov <alchark@gmail.com> - 2015-12-22 10:20 +0100

#1295704 — [PATCH 0/4] clocksource/vt8500: Fix hangs in small delays

From: Roman Volkov <rvolkov@v1ros.org>

vt8500 hangs in nanosleep() function, starting from commit
c6eb3f70d4482806dc2d3e1e3c7736f497b1d418, making the system unusable.
Per investigation, looks like set_next_event() now receives too small
delta and fails with -ETIME.

Google group discussion:
https://groups.google.com/forum/#!topic/vt8500-wm8505-linux-kernel/vDMF_mDOb1k

Roman Volkov (4):
  clocksource/vt8500: Use [read\write]l_relaxed()
  clocksource/vt8500: Remove the 'loops' variable
  clocksource/vt8500: Use MIN_OSCR_DELTA from PXA
  clocksource/vt8500: Add register R/W functions

 drivers/clocksource/vt8500_timer.c | 98 +++++++++++++++++++++++++++-----------
 1 file changed, 69 insertions(+), 29 deletions(-)

-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1295828

On Mon, 21 Dec 2015 01:28:08 +0300
Roman Volkov <v1ron@mail.ru> wrote:

> From: Roman Volkov <rvolkov@v1ros.org>
> 
> vt8500 hangs in nanosleep() function, starting from commit
> c6eb3f70d4482806dc2d3e1e3c7736f497b1d418, making the system unusable.
> Per investigation, looks like set_next_event() now receives too small
> delta and fails with -ETIME.
> 
> Google group discussion:
> https://groups.google.com/forum/#!topic/vt8500-wm8505-linux-kernel/vDMF_mDOb1k
> 
> Roman Volkov (4):
>   clocksource/vt8500: Use [read\write]l_relaxed()
>   clocksource/vt8500: Remove the 'loops' variable
>   clocksource/vt8500: Use MIN_OSCR_DELTA from PXA
>   clocksource/vt8500: Add register R/W functions
> 
>  drivers/clocksource/vt8500_timer.c | 98
> +++++++++++++++++++++++++++----------- 1 file changed, 69
> insertions(+), 29 deletions(-)
> 

Please note that vt8500 maintainer (Tony Prisk) was silent in the last
year. Any suggestions on this?

Regards,
Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296199

> 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?

I don't think maintainers will accept a lot of #ifdefs. I have an idea
to move the common code from the PXA to something like pxa_common.c
(can we give the correct name for it?) and include it from the
vt8500_timer.c and pxa_timer.c.

> 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.

Sure. But lets make the vt8500 working at this step.

> > 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?

If we do the merging work with PXA, this code will go away. Have this
variable already fixed some _real_ problem? Otherwise this is excessive
coding.

> >  #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?

Oh my right-handed habits :)

> 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.

When we perform our merging work, we have to use the following glue:
...
vt8500_timer_read { ... }
#define timer_read(reg)	vt8500_timer_read(reg)
...
#include pxa_common.c

> <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?

To avoid calculation of the 64-bit cycle_t and remove type casts.

> > -	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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296642

2015-12-21 23:33 GMT+03:00 Roman Volkov <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?
>
> I don't think maintainers will accept a lot of #ifdefs. I have an idea
> to move the common code from the PXA to something like pxa_common.c
> (can we give the correct name for it?) and include it from the
> vt8500_timer.c and pxa_timer.c.

Can't this be done via different OF compatible strings, setting some
global 'static bool needs_bus_sync = true' or such for vt8500, and
then checking it in the accessor functions? Then no ifdefs needed, and
the driver can actually work for both variants within the same kernel
image.

<skip>

>> > +#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?
>
> If we do the merging work with PXA, this code will go away. Have this
> variable already fixed some _real_ problem? Otherwise this is excessive
> coding.

Never had any issues without the guarding loop counter. I got that
suggestion as part of feedback to my original submission of the timer
code, and thought it doesn't hurt. Can't say I'm particularly attached
to it, though, so fine for me if you drop it :)

>> >  #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?
>
> Oh my right-handed habits :)
>
>> 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.
>
> When we perform our merging work, we have to use the following glue:
> ...
> vt8500_timer_read { ... }
> #define timer_read(reg) vt8500_timer_read(reg)
> ...
> #include pxa_common.c

...or make it a runtime switch without ifdefs or includes. Anyway,
this only matters for making the patch series more readable - just
reducing the number of insertions/additions that don't have much
semantic meaning.

Best regards,
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web