All of lore.kernel.org
 help / color / mirror / Atom feed
From: oss@buserror.net (Scott Wood)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 3/3] arm64: arch_timer: Work around QorIQ Erratum A-008585
Date: Thu, 07 Jul 2016 12:39:42 -0500	[thread overview]
Message-ID: <1467913182.32358.68.camel@buserror.net> (raw)
In-Reply-To: <577E524F.3030403@huawei.com>

On Thu, 2016-07-07 at 20:59 +0800, Ding Tianhong wrote:
> On 2016/7/7 19:51, Marc Zyngier wrote:
> > 
> > On 07/07/16 12:37, Ding Tianhong wrote:
> > > 
> > > On 2016/7/7 17:49, Marc Zyngier wrote:
> > > > 
> > > > What makes you think that ignoring the two bottom bits is a safe thing
> > > > to do? Talking about performance when the HW has such a dramatic bug
> > > > is
> > > > like putting a bigger engine on a car that has no brakes: you just hit
> > > > the wall quicker.
> > > > 
> > > > Thanks,
> > > > 
> > > I have a chip which has the same problem like Scott's chip, and I
> > > wish to solve this problem in the same way, our chip designer told me
> > > that if you got a wrong value from the cntvct_el0, you would not get
> > > a wrong value until 8 cycles later, so I could ignoring the lowest 3
> > > bits if I reading twice together.
> > Is that CPU cycles? Or timer cycles? What guarantees do you have that
> > the two reads are *always* done in the right timing window?
> > 
> The timer counter only use 56 bits in aarch64, my chip would change one of
> the higher?
> bit(55 to 3) to a wrong value when occur bug, so there will be more than 8
> cycles between
> correct value and wrong value from the timer counter. Maybe Scott's problem
> is not just like
> mine.

It's not like yours. ?Most errors I saw were time going backwards by 1, 3, or
7 cycles (with occasional larger errors).

-Scott

WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
To: Ding Tianhong
	<dingtianhong-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
	Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
	Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	stuart.yoder-3arQi8VN3Tc@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v3 3/3] arm64: arch_timer: Work around QorIQ Erratum A-008585
Date: Thu, 07 Jul 2016 12:39:42 -0500	[thread overview]
Message-ID: <1467913182.32358.68.camel@buserror.net> (raw)
In-Reply-To: <577E524F.3030403-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

On Thu, 2016-07-07 at 20:59 +0800, Ding Tianhong wrote:
> On 2016/7/7 19:51, Marc Zyngier wrote:
> > 
> > On 07/07/16 12:37, Ding Tianhong wrote:
> > > 
> > > On 2016/7/7 17:49, Marc Zyngier wrote:
> > > > 
> > > > What makes you think that ignoring the two bottom bits is a safe thing
> > > > to do? Talking about performance when the HW has such a dramatic bug
> > > > is
> > > > like putting a bigger engine on a car that has no brakes: you just hit
> > > > the wall quicker.
> > > > 
> > > > Thanks,
> > > > 
> > > I have a chip which has the same problem like Scott's chip, and I
> > > wish to solve this problem in the same way, our chip designer told me
> > > that if you got a wrong value from the cntvct_el0, you would not get
> > > a wrong value until 8 cycles later, so I could ignoring the lowest 3
> > > bits if I reading twice together.
> > Is that CPU cycles? Or timer cycles? What guarantees do you have that
> > the two reads are *always* done in the right timing window?
> > 
> The timer counter only use 56 bits in aarch64, my chip would change one of
> the higher 
> bit(55 to 3) to a wrong value when occur bug, so there will be more than 8
> cycles between
> correct value and wrong value from the timer counter. Maybe Scott's problem
> is not just like
> mine.

It's not like yours.  Most errors I saw were time going backwards by 1, 3, or
7 cycles (with occasional larger errors).

-Scott

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2016-07-07 17:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-01 22:41 [PATCH v3 1/3] arm64: arch_timer: Add device tree binding for A-008585 erratum Scott Wood
2016-07-01 22:41 ` Scott Wood
2016-07-01 22:41 ` [PATCH v3 2/3] arm64: dts: Add timer erratum property for LS2080A and LS1043A Scott Wood
2016-07-01 22:41   ` Scott Wood
2016-07-01 22:41 ` [PATCH v3 3/3] arm64: arch_timer: Work around QorIQ Erratum A-008585 Scott Wood
2016-07-01 22:41   ` Scott Wood
2016-07-04  9:58   ` Will Deacon
2016-07-04  9:58     ` Will Deacon
2016-07-07  9:34   ` Ding Tianhong
2016-07-07  9:34     ` Ding Tianhong
2016-07-07  9:49     ` Marc Zyngier
2016-07-07  9:49       ` Marc Zyngier
2016-07-07 11:37       ` Ding Tianhong
2016-07-07 11:37         ` Ding Tianhong
2016-07-07 11:51         ` Marc Zyngier
2016-07-07 11:51           ` Marc Zyngier
2016-07-07 12:59           ` Ding Tianhong
2016-07-07 12:59             ` Ding Tianhong
2016-07-07 17:39             ` Scott Wood [this message]
2016-07-07 17:39               ` Scott Wood
2016-07-08  0:51               ` Ding Tianhong
2016-07-08  0:51                 ` Ding Tianhong
2016-07-05 15:43 ` [PATCH v3 1/3] arm64: arch_timer: Add device tree binding for A-008585 erratum Rob Herring
2016-07-05 15:43   ` Rob Herring

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=1467913182.32358.68.camel@buserror.net \
    --to=oss@buserror.net \
    --cc=linux-arm-kernel@lists.infradead.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.