From: Mattias Wallin <mattias.wallin@stericsson.com>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>,
Russell King <linux@arm.linux.org.uk>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Saravana Kannan <skannan@codeaurora.org>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCHv5 2/3] ARM: Allow machines to override __delay()
Date: Thu, 7 Apr 2011 09:30:15 +0200 [thread overview]
Message-ID: <4D9D6807.40800@stericsson.com> (raw)
In-Reply-To: <1302047800-26720-3-git-send-email-sboyd@codeaurora.org>
On 04/06/2011 01:56 AM, Stephen Boyd wrote:
> Some machines want to implement their own __delay() routine based
> on fixed rate timers. Expose functionality to set the __delay()
> routine at runtime. This should allow two machines with different
> __delay() routines to happily co-exist within the same kernel
> with minimal overhead.
>
> Russell expressed concern that using a timer based __delay()
> would cause problems when an iomapped device isn't mapped in
> prior to a delay call being made (see
> http://article.gmane.org/gmane.linux.ports.arm.kernel/78543 for
> more info). We can sidestep that issue with this approach since
> the __delay() routine_should_ only be pointed to a timer based
> delay once the timer has been properly mapped. Up until that
> point __delay() and udelay() will use delay_loop() which is
> always safe to call.
>
> This patch is inspired by x86's delay.c
>
Tested-by: Mattias Wallin <mattias.wallin@stericsson.com>
Yours,
Mattias Wallin
WARNING: multiple messages have this Message-ID (diff)
From: mattias.wallin@stericsson.com (Mattias Wallin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv5 2/3] ARM: Allow machines to override __delay()
Date: Thu, 7 Apr 2011 09:30:15 +0200 [thread overview]
Message-ID: <4D9D6807.40800@stericsson.com> (raw)
In-Reply-To: <1302047800-26720-3-git-send-email-sboyd@codeaurora.org>
On 04/06/2011 01:56 AM, Stephen Boyd wrote:
> Some machines want to implement their own __delay() routine based
> on fixed rate timers. Expose functionality to set the __delay()
> routine at runtime. This should allow two machines with different
> __delay() routines to happily co-exist within the same kernel
> with minimal overhead.
>
> Russell expressed concern that using a timer based __delay()
> would cause problems when an iomapped device isn't mapped in
> prior to a delay call being made (see
> http://article.gmane.org/gmane.linux.ports.arm.kernel/78543 for
> more info). We can sidestep that issue with this approach since
> the __delay() routine_should_ only be pointed to a timer based
> delay once the timer has been properly mapped. Up until that
> point __delay() and udelay() will use delay_loop() which is
> always safe to call.
>
> This patch is inspired by x86's delay.c
>
Tested-by: Mattias Wallin <mattias.wallin@stericsson.com>
Yours,
Mattias Wallin
WARNING: multiple messages have this Message-ID (diff)
From: Mattias Wallin <mattias.wallin@stericsson.com>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Russell King <linux@arm.linux.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Saravana Kannan <skannan@codeaurora.org>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCHv5 2/3] ARM: Allow machines to override __delay()
Date: Thu, 7 Apr 2011 09:30:15 +0200 [thread overview]
Message-ID: <4D9D6807.40800@stericsson.com> (raw)
In-Reply-To: <1302047800-26720-3-git-send-email-sboyd@codeaurora.org>
On 04/06/2011 01:56 AM, Stephen Boyd wrote:
> Some machines want to implement their own __delay() routine based
> on fixed rate timers. Expose functionality to set the __delay()
> routine at runtime. This should allow two machines with different
> __delay() routines to happily co-exist within the same kernel
> with minimal overhead.
>
> Russell expressed concern that using a timer based __delay()
> would cause problems when an iomapped device isn't mapped in
> prior to a delay call being made (see
> http://article.gmane.org/gmane.linux.ports.arm.kernel/78543 for
> more info). We can sidestep that issue with this approach since
> the __delay() routine_should_ only be pointed to a timer based
> delay once the timer has been properly mapped. Up until that
> point __delay() and udelay() will use delay_loop() which is
> always safe to call.
>
> This patch is inspired by x86's delay.c
>
Tested-by: Mattias Wallin <mattias.wallin@stericsson.com>
Yours,
Mattias Wallin
next prev parent reply other threads:[~2011-04-07 7:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-05 23:56 [PATCHv5 0/3] Constant udelay() for SMP and non-SMP systems Stephen Boyd
2011-04-05 23:56 ` Stephen Boyd
2011-04-05 23:56 ` [PATCHv5 1/3] ARM: Translate delay.S into (mostly) C Stephen Boyd
2011-04-05 23:56 ` Stephen Boyd
2011-04-06 8:49 ` Mattias Wallin
2011-04-06 8:49 ` Mattias Wallin
2011-04-06 17:34 ` Stephen Boyd
2011-04-06 17:34 ` Stephen Boyd
2011-04-07 1:27 ` Saravana Kannan
2011-04-07 1:27 ` Saravana Kannan
2011-04-07 7:27 ` Mattias Wallin
2011-04-07 7:27 ` Mattias Wallin
2011-04-07 7:27 ` Mattias Wallin
2011-04-07 7:29 ` Mattias Wallin
2011-04-07 7:29 ` Mattias Wallin
2011-04-05 23:56 ` [PATCHv5 2/3] ARM: Allow machines to override __delay() Stephen Boyd
2011-04-05 23:56 ` Stephen Boyd
2011-04-07 7:30 ` Mattias Wallin [this message]
2011-04-07 7:30 ` Mattias Wallin
2011-04-07 7:30 ` Mattias Wallin
2011-04-05 23:56 ` [PATCHv5 3/3] ARM: Implement a timer based __delay() loop Stephen Boyd
2011-04-05 23:56 ` Stephen Boyd
2011-04-07 7:30 ` Mattias Wallin
2011-04-07 7:30 ` Mattias Wallin
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=4D9D6807.40800@stericsson.com \
--to=mattias.wallin@stericsson.com \
--cc=akpm@linux-foundation.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nicolas.pitre@linaro.org \
--cc=sboyd@codeaurora.org \
--cc=skannan@codeaurora.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.