From: Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Peter De Schrijver
<pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Paul Gortmaker
<paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>,
Daniel Lezcano
<daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 0/3] Use Tegra's microsecond counter for udelay()
Date: Thu, 12 Jun 2014 23:55:54 +0100 [thread overview]
Message-ID: <20140612225553.GO23430@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <539A01B4.3050503-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On Thu, Jun 12, 2014 at 01:38:28PM -0600, Stephen Warren wrote:
> On 06/12/2014 09:58 AM, Peter De Schrijver wrote:
> > This patchset introduces support for Tegra's microsecond counter as the
> > udelay() timer. This is useful on Tegra SoCs which do not have an arch timer
> > such as Tegra20 and Tegra30. Using the microsecond counter instead of a delay
> > based loop avoids potential problems during cpu frequency changes.
> >
> > The set consists of 3 patches:
> >
> > Patch 1 introduces a new call which is used by the ARM architecture delay
> > timer code to prevent changing the delay timer after calibration is finished
> > and thus can be in use.
> >
> > Patch 2 adds logic to choose the delay timer with the highest resolution. This
> > allows the same registration code to be used on all Tegra SoCs and yet use the
> > higher resolution arch timer when available (eg on Tegra114 or Tegra124).
> >
> > Patch 3 adds the actual delay timer code.
> >
> > Patch set has been verified on ventana (Tegra20), beaver (Tegra30),
> > dalmore (Tegra114) and jetson TK1 (Tegra124).
>
> Russell, Paul, do patches 1 and 2 look good to you? If so, if you can
> ack them, I'd be happy to queue this series in the Tegra git tree. If
> that doesn't work for you, please let me know who will apply these
> patches. Thanks.
When I saw them, I did have a question in the back of my mind about
the interlocking - whether we should just mandate that these are
always registered before delay calibration. Then I remember the
mess that platforms made of the sched_clock() stuff.
So, I don't see any other way to ensure that platforms do the right
thing other than providing that kind of stick... so I guess we'll
have to have them.
Acked-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Peter De Schrijver <pdeschrijver@nvidia.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Thierry Reding <thierry.reding@gmail.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH 0/3] Use Tegra's microsecond counter for udelay()
Date: Thu, 12 Jun 2014 23:55:54 +0100 [thread overview]
Message-ID: <20140612225553.GO23430@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <539A01B4.3050503@wwwdotorg.org>
On Thu, Jun 12, 2014 at 01:38:28PM -0600, Stephen Warren wrote:
> On 06/12/2014 09:58 AM, Peter De Schrijver wrote:
> > This patchset introduces support for Tegra's microsecond counter as the
> > udelay() timer. This is useful on Tegra SoCs which do not have an arch timer
> > such as Tegra20 and Tegra30. Using the microsecond counter instead of a delay
> > based loop avoids potential problems during cpu frequency changes.
> >
> > The set consists of 3 patches:
> >
> > Patch 1 introduces a new call which is used by the ARM architecture delay
> > timer code to prevent changing the delay timer after calibration is finished
> > and thus can be in use.
> >
> > Patch 2 adds logic to choose the delay timer with the highest resolution. This
> > allows the same registration code to be used on all Tegra SoCs and yet use the
> > higher resolution arch timer when available (eg on Tegra114 or Tegra124).
> >
> > Patch 3 adds the actual delay timer code.
> >
> > Patch set has been verified on ventana (Tegra20), beaver (Tegra30),
> > dalmore (Tegra114) and jetson TK1 (Tegra124).
>
> Russell, Paul, do patches 1 and 2 look good to you? If so, if you can
> ack them, I'd be happy to queue this series in the Tegra git tree. If
> that doesn't work for you, please let me know who will apply these
> patches. Thanks.
When I saw them, I did have a question in the back of my mind about
the interlocking - whether we should just mandate that these are
always registered before delay calibration. Then I remember the
mess that platforms made of the sched_clock() stuff.
So, I don't see any other way to ensure that platforms do the right
thing other than providing that kind of stick... so I guess we'll
have to have them.
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] Use Tegra's microsecond counter for udelay()
Date: Thu, 12 Jun 2014 23:55:54 +0100 [thread overview]
Message-ID: <20140612225553.GO23430@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <539A01B4.3050503@wwwdotorg.org>
On Thu, Jun 12, 2014 at 01:38:28PM -0600, Stephen Warren wrote:
> On 06/12/2014 09:58 AM, Peter De Schrijver wrote:
> > This patchset introduces support for Tegra's microsecond counter as the
> > udelay() timer. This is useful on Tegra SoCs which do not have an arch timer
> > such as Tegra20 and Tegra30. Using the microsecond counter instead of a delay
> > based loop avoids potential problems during cpu frequency changes.
> >
> > The set consists of 3 patches:
> >
> > Patch 1 introduces a new call which is used by the ARM architecture delay
> > timer code to prevent changing the delay timer after calibration is finished
> > and thus can be in use.
> >
> > Patch 2 adds logic to choose the delay timer with the highest resolution. This
> > allows the same registration code to be used on all Tegra SoCs and yet use the
> > higher resolution arch timer when available (eg on Tegra114 or Tegra124).
> >
> > Patch 3 adds the actual delay timer code.
> >
> > Patch set has been verified on ventana (Tegra20), beaver (Tegra30),
> > dalmore (Tegra114) and jetson TK1 (Tegra124).
>
> Russell, Paul, do patches 1 and 2 look good to you? If so, if you can
> ack them, I'd be happy to queue this series in the Tegra git tree. If
> that doesn't work for you, please let me know who will apply these
> patches. Thanks.
When I saw them, I did have a question in the back of my mind about
the interlocking - whether we should just mandate that these are
always registered before delay calibration. Then I remember the
mess that platforms made of the sched_clock() stuff.
So, I don't see any other way to ensure that platforms do the right
thing other than providing that kind of stick... so I guess we'll
have to have them.
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
next prev parent reply other threads:[~2014-06-12 22:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-12 15:58 [PATCH 0/3] Use Tegra's microsecond counter for udelay() Peter De Schrijver
2014-06-12 15:58 ` Peter De Schrijver
2014-06-12 15:58 ` Peter De Schrijver
2014-06-12 15:58 ` [PATCH v2 1/3] kernel: add calibration_delay_done() Peter De Schrijver
2014-06-12 15:58 ` Peter De Schrijver
2014-06-12 15:58 ` Peter De Schrijver
2014-06-12 15:58 ` [PATCH v2 2/3] ARM: choose highest resolution delay timer Peter De Schrijver
2014-06-12 15:58 ` Peter De Schrijver
2014-06-12 15:58 ` Peter De Schrijver
2014-06-12 15:58 ` [PATCH v2 3/3] clocksource: tegra: Use us counter as " Peter De Schrijver
2014-06-12 15:58 ` Peter De Schrijver
2014-06-12 15:58 ` Peter De Schrijver
[not found] ` <1402588713-18766-1-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-06-12 19:38 ` [PATCH 0/3] Use Tegra's microsecond counter for udelay() Stephen Warren
2014-06-12 19:38 ` Stephen Warren
2014-06-12 19:38 ` Stephen Warren
[not found] ` <539A01B4.3050503-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-12 22:55 ` Russell King - ARM Linux [this message]
2014-06-12 22:55 ` Russell King - ARM Linux
2014-06-12 22:55 ` Russell King - ARM Linux
2014-06-13 7:25 ` Peter De Schrijver
2014-06-13 7:25 ` Peter De Schrijver
2014-06-13 7:25 ` Peter De Schrijver
2014-06-16 18:52 ` Stephen Warren
2014-06-16 18:52 ` Stephen Warren
2014-06-16 18:52 ` Stephen Warren
-- strict thread matches above, loose matches on Subject: below --
2014-05-20 15:36 Peter De Schrijver
2014-05-20 15:36 ` Peter De Schrijver
2014-05-20 15:36 ` Peter De Schrijver
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=20140612225553.GO23430@n2100.arm.linux.org.uk \
--to=linux-lfz/pmaqli7xmaaqvzeohq@public.gmane.org \
--cc=daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org \
--cc=pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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.