On 14 May 2014 03:20, Doug Anderson wrote:
> ...but then I found the true problem shows up when we transition
> between very low frequencies on exynos, like between 200MHz and
> 300MHz. While transitioning between frequencies the system
> temporarily bumps over to the "switcher" PLL running at
On 14 May 2014 03:20, Doug Anderson diand...@chromium.org wrote:
...but then I found the true problem shows up when we transition
between very low frequencies on exynos, like between 200MHz and
300MHz. While transitioning between frequencies the system
temporarily bumps over to the switcher
Hi,
On Tue, May 13, 2014 at 4:29 PM, Nicolas Pitre wrote:
> On Tue, 13 May 2014, Nicolas Pitre wrote:
>
>> On Tue, 13 May 2014, Stephen Warren wrote:
>>
>> > On 05/13/2014 03:50 PM, Doug Anderson wrote:
>> > ...
>> > > ...but then I found the true problem shows up when we transition
>> > >
Hi,
On Tue, May 13, 2014 at 4:29 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Tue, 13 May 2014, Nicolas Pitre wrote:
On Tue, 13 May 2014, Stephen Warren wrote:
On 05/13/2014 03:50 PM, Doug Anderson wrote:
...
...but then I found the true problem shows up when we transition
On Tue, May 13, 2014 at 07:29:52PM -0400, Nicolas Pitre wrote:
> On Tue, 13 May 2014, Nicolas Pitre wrote:
>
> > On Tue, 13 May 2014, Stephen Warren wrote:
> >
> > > On 05/13/2014 03:50 PM, Doug Anderson wrote:
> > > ...
> > > > ...but then I found the true problem shows up when we transition
>
On Tue, 13 May 2014, Nicolas Pitre wrote:
> On Tue, 13 May 2014, Stephen Warren wrote:
>
> > On 05/13/2014 03:50 PM, Doug Anderson wrote:
> > ...
> > > ...but then I found the true problem shows up when we transition
> > > between very low frequencies on exynos, like between 200MHz and
> > >
On Tue, 13 May 2014, Stephen Warren wrote:
> On 05/13/2014 03:50 PM, Doug Anderson wrote:
> ...
> > ...but then I found the true problem shows up when we transition
> > between very low frequencies on exynos, like between 200MHz and
> > 300MHz. While transitioning between frequencies the system
On 05/13/2014 03:50 PM, Doug Anderson wrote:
...
> ...but then I found the true problem shows up when we transition
> between very low frequencies on exynos, like between 200MHz and
> 300MHz. While transitioning between frequencies the system
> temporarily bumps over to the "switcher" PLL running
Hi,
On Mon, May 12, 2014 at 4:51 PM, Doug Anderson wrote:
> Hi,
>
> On Fri, May 9, 2014 at 2:05 PM, Nicolas Pitre
> wrote:
>> On Fri, 9 May 2014, Russell King - ARM Linux wrote:
>>
>>> I'd much prefer just printing a warning at kernel boot time to report
>>> that the kernel is running with
Hi,
On Mon, May 12, 2014 at 4:51 PM, Doug Anderson diand...@chromium.org wrote:
Hi,
On Fri, May 9, 2014 at 2:05 PM, Nicolas Pitre nicolas.pi...@linaro.org
wrote:
On Fri, 9 May 2014, Russell King - ARM Linux wrote:
I'd much prefer just printing a warning at kernel boot time to report
that
On 05/13/2014 03:50 PM, Doug Anderson wrote:
...
...but then I found the true problem shows up when we transition
between very low frequencies on exynos, like between 200MHz and
300MHz. While transitioning between frequencies the system
temporarily bumps over to the switcher PLL running at
On Tue, 13 May 2014, Stephen Warren wrote:
On 05/13/2014 03:50 PM, Doug Anderson wrote:
...
...but then I found the true problem shows up when we transition
between very low frequencies on exynos, like between 200MHz and
300MHz. While transitioning between frequencies the system
On Tue, 13 May 2014, Nicolas Pitre wrote:
On Tue, 13 May 2014, Stephen Warren wrote:
On 05/13/2014 03:50 PM, Doug Anderson wrote:
...
...but then I found the true problem shows up when we transition
between very low frequencies on exynos, like between 200MHz and
300MHz. While
On Tue, May 13, 2014 at 07:29:52PM -0400, Nicolas Pitre wrote:
On Tue, 13 May 2014, Nicolas Pitre wrote:
On Tue, 13 May 2014, Stephen Warren wrote:
On 05/13/2014 03:50 PM, Doug Anderson wrote:
...
...but then I found the true problem shows up when we transition
between very
Hi,
On Fri, May 9, 2014 at 2:05 PM, Nicolas Pitre wrote:
> On Fri, 9 May 2014, Russell King - ARM Linux wrote:
>
>> I'd much prefer just printing a warning at kernel boot time to report
>> that the kernel is running with features which would make udelay() less
>> than accurate.
>
> What if there
Hi,
On Fri, May 9, 2014 at 2:05 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Fri, 9 May 2014, Russell King - ARM Linux wrote:
I'd much prefer just printing a warning at kernel boot time to report
that the kernel is running with features which would make udelay() less
than accurate.
On Fri, 9 May 2014, Russell King - ARM Linux wrote:
> I'd much prefer just printing a warning at kernel boot time to report
> that the kernel is running with features which would make udelay() less
> than accurate.
What if there is simply no timer to rely upon, as in those cases where
On Fri, May 09, 2014 at 02:00:54PM -0400, Nicolas Pitre wrote:
> On Fri, 9 May 2014, Russell King - ARM Linux wrote:
>
> > On Thu, May 08, 2014 at 09:37:15PM -0400, Nicolas Pitre wrote:
> > > On Thu, 8 May 2014, Russell King - ARM Linux wrote:
> > >
> > > > If you're in a preempt or SMP
On Fri, 9 May 2014, Russell King - ARM Linux wrote:
> On Thu, May 08, 2014 at 09:37:15PM -0400, Nicolas Pitre wrote:
> > On Thu, 8 May 2014, Russell King - ARM Linux wrote:
> >
> > > If you're in a preempt or SMP environment, provide a timer for udelay().
> > > IF you're in an environment with
On 8 May 2014 20:55, Doug Anderson wrote:
> On Thu, May 8, 2014 at 3:41 AM, Viresh Kumar wrote:
>> And if that's the case, why don't we get rid of it completely and set
>> global-loop-per-jiffy for the max freq at boot ?
>
> How exactly do you do this in a generic way?
We could have requested
On Thu, May 08, 2014 at 09:37:15PM -0400, Nicolas Pitre wrote:
> On Thu, 8 May 2014, Russell King - ARM Linux wrote:
>
> > If you're in a preempt or SMP environment, provide a timer for udelay().
> > IF you're in an environment with IRQs which can take a long time, use
> > a timer for udelay().
On Thu, May 08, 2014 at 09:37:15PM -0400, Nicolas Pitre wrote:
On Thu, 8 May 2014, Russell King - ARM Linux wrote:
If you're in a preempt or SMP environment, provide a timer for udelay().
IF you're in an environment with IRQs which can take a long time, use
a timer for udelay(). If
On 8 May 2014 20:55, Doug Anderson diand...@chromium.org wrote:
On Thu, May 8, 2014 at 3:41 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
And if that's the case, why don't we get rid of it completely and set
global-loop-per-jiffy for the max freq at boot ?
How exactly do you do this in a
On Fri, 9 May 2014, Russell King - ARM Linux wrote:
On Thu, May 08, 2014 at 09:37:15PM -0400, Nicolas Pitre wrote:
On Thu, 8 May 2014, Russell King - ARM Linux wrote:
If you're in a preempt or SMP environment, provide a timer for udelay().
IF you're in an environment with IRQs which
On Fri, May 09, 2014 at 02:00:54PM -0400, Nicolas Pitre wrote:
On Fri, 9 May 2014, Russell King - ARM Linux wrote:
On Thu, May 08, 2014 at 09:37:15PM -0400, Nicolas Pitre wrote:
On Thu, 8 May 2014, Russell King - ARM Linux wrote:
If you're in a preempt or SMP environment, provide a
On Fri, 9 May 2014, Russell King - ARM Linux wrote:
I'd much prefer just printing a warning at kernel boot time to report
that the kernel is running with features which would make udelay() less
than accurate.
What if there is simply no timer to rely upon, as in those cases where
interrupts
Nicolas,
On Thu, May 8, 2014 at 6:37 PM, Nicolas Pitre wrote:
> On Thu, 8 May 2014, Russell King - ARM Linux wrote:
>
>> If you're in a preempt or SMP environment, provide a timer for udelay().
>> IF you're in an environment with IRQs which can take a long time, use
>> a timer for udelay(). If
Russell,
On Thu, May 8, 2014 at 5:23 PM, Russell King - ARM Linux
wrote:
> On Thu, May 08, 2014 at 05:02:02PM -0700, Doug Anderson wrote:
>> Russel,
>>
>> On Thu, May 8, 2014 at 1:55 PM, Russell King - ARM Linux
>> wrote:
>> > On Thu, May 08, 2014 at 11:06:24AM -0700, Doug Anderson wrote:
>> >>
On Thu, 8 May 2014, Russell King - ARM Linux wrote:
> If you're in a preempt or SMP environment, provide a timer for udelay().
> IF you're in an environment with IRQs which can take a long time, use
> a timer for udelay(). If you're in an environment where the CPU clock
> can change
On Thu, May 08, 2014 at 05:02:02PM -0700, Doug Anderson wrote:
> Russel,
>
> On Thu, May 8, 2014 at 1:55 PM, Russell King - ARM Linux
> wrote:
> > On Thu, May 08, 2014 at 11:06:24AM -0700, Doug Anderson wrote:
> >> I guess I would say that my patch is unhacking the this code. The
> >> code
Russel,
On Thu, May 8, 2014 at 1:55 PM, Russell King - ARM Linux
wrote:
> On Thu, May 08, 2014 at 11:06:24AM -0700, Doug Anderson wrote:
>> I guess I would say that my patch is unhacking the this code. The
>> code after my patch is simpler. I would perhaps argue that (ec971ea
>> ARM: add
On Thu, May 08, 2014 at 11:06:24AM -0700, Doug Anderson wrote:
> I guess I would say that my patch is unhacking the this code. The
> code after my patch is simpler. I would perhaps argue that (ec971ea
> ARM: add cpufreq transiton notifier to adjust loops_per_jiffy for smp)
> should never have
On Thu, May 08, 2014 at 04:12:14PM -0400, Nicolas Pitre wrote:
> On Thu, 8 May 2014, Russell King - ARM Linux wrote:
>
> > Anything which is expecting precise timings from udelay() is broken.
> > Firstly, udelay() does _not_ guarantee to give you a delay of at least
> > the requested period - it
On 05/08/2014 01:12 PM, Nicolas Pitre wrote:
> On Thu, 8 May 2014, Russell King - ARM Linux wrote:
>
>> So, the only /real/ solution if you want proper delays is for udelay()
>> to use a timer or counter, and this is should always the preferred
>> method where it's available. Quite rightly, we're
On Thu, 8 May 2014, Russell King - ARM Linux wrote:
> Anything which is expecting precise timings from udelay() is broken.
> Firstly, udelay() does _not_ guarantee to give you a delay of at least
> the requested period - it tries to give an _approximate_ delay.
>
> The first thing to realise is
On Thu, 8 May 2014, Doug Anderson wrote:
> Nicolas,
>
> On Thu, May 8, 2014 at 10:43 AM, Nicolas Pitre
> wrote:
> > On Thu, 8 May 2014, Doug Anderson wrote:
>
> >> Longer delays aren't very good, but IMHO having some delays of 100 =>
> >> 1000 is better than having delays of 100 => 75. The
On Thu, May 08, 2014 at 01:43:29PM -0400, Nicolas Pitre wrote:
> There might be some cases where precise timing is needed though.
> I thought I came across one such case in the past but I can't remember
> which.
Anything which is expecting precise timings from udelay() is broken.
Firstly,
Nicolas,
On Thu, May 8, 2014 at 10:43 AM, Nicolas Pitre wrote:
> On Thu, 8 May 2014, Doug Anderson wrote:
>> Longer delays aren't very good, but IMHO having some delays of 100 =>
>> 1000 is better than having delays of 100 => 75. The former will cause
>> mostly performance problems and the
On Thu, 8 May 2014, Doug Anderson wrote:
> Nicolas,
>
> On Thu, May 8, 2014 at 9:04 AM, Nicolas Pitre
> wrote:
> > On Thu, 8 May 2014, Doug Anderson wrote:
> >
> >> 1. Initially CPU1 and CPU2 at 200MHz. Pretend loops_per_jiffy is 1000.
> >>
> >> 2. CPU1 starts a delay. It reads global lpj
Nicolas,
On Thu, May 8, 2014 at 9:04 AM, Nicolas Pitre wrote:
> On Thu, 8 May 2014, Doug Anderson wrote:
>
>> 1. Initially CPU1 and CPU2 at 200MHz. Pretend loops_per_jiffy is 1000.
>>
>> 2. CPU1 starts a delay. It reads global lpj (1000) and sets up its
>> local registers up for the loop.
>>
On Thu, 8 May 2014, Doug Anderson wrote:
> 1. Initially CPU1 and CPU2 at 200MHz. Pretend loops_per_jiffy is 1000.
>
> 2. CPU1 starts a delay. It reads global lpj (1000) and sets up its
> local registers up for the loop.
>
> 3. At the same time, CPU2 is transitioning the system to 2000MHz.
>
Viresh,
On Thu, May 8, 2014 at 3:41 AM, Viresh Kumar wrote:
> Fixing Rafael's id.
>
> On Thu, May 8, 2014 at 4:53 AM, Doug Anderson wrote:
>> Downscaling loops_per_jiffy on SMP ARM systems really doesn't work.
>> You could really only do this if:
>>
>> * Each CPU is has independent frequency
Fixing Rafael's id.
On Thu, May 8, 2014 at 4:53 AM, Doug Anderson wrote:
> Downscaling loops_per_jiffy on SMP ARM systems really doesn't work.
> You could really only do this if:
>
> * Each CPU is has independent frequency changes (changing one CPU
> doesn't affect another).
> * We change the
Fixing Rafael's id.
On Thu, May 8, 2014 at 4:53 AM, Doug Anderson diand...@chromium.org wrote:
Downscaling loops_per_jiffy on SMP ARM systems really doesn't work.
You could really only do this if:
* Each CPU is has independent frequency changes (changing one CPU
doesn't affect another).
*
Viresh,
On Thu, May 8, 2014 at 3:41 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
Fixing Rafael's id.
On Thu, May 8, 2014 at 4:53 AM, Doug Anderson diand...@chromium.org wrote:
Downscaling loops_per_jiffy on SMP ARM systems really doesn't work.
You could really only do this if:
* Each
On Thu, 8 May 2014, Doug Anderson wrote:
1. Initially CPU1 and CPU2 at 200MHz. Pretend loops_per_jiffy is 1000.
2. CPU1 starts a delay. It reads global lpj (1000) and sets up its
local registers up for the loop.
3. At the same time, CPU2 is transitioning the system to 2000MHz.
Right
Nicolas,
On Thu, May 8, 2014 at 9:04 AM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Thu, 8 May 2014, Doug Anderson wrote:
1. Initially CPU1 and CPU2 at 200MHz. Pretend loops_per_jiffy is 1000.
2. CPU1 starts a delay. It reads global lpj (1000) and sets up its
local registers up for
On Thu, 8 May 2014, Doug Anderson wrote:
Nicolas,
On Thu, May 8, 2014 at 9:04 AM, Nicolas Pitre nicolas.pi...@linaro.org
wrote:
On Thu, 8 May 2014, Doug Anderson wrote:
1. Initially CPU1 and CPU2 at 200MHz. Pretend loops_per_jiffy is 1000.
2. CPU1 starts a delay. It reads global
Nicolas,
On Thu, May 8, 2014 at 10:43 AM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Thu, 8 May 2014, Doug Anderson wrote:
Longer delays aren't very good, but IMHO having some delays of 100 =
1000 is better than having delays of 100 = 75. The former will cause
mostly performance
On Thu, May 08, 2014 at 01:43:29PM -0400, Nicolas Pitre wrote:
There might be some cases where precise timing is needed though.
I thought I came across one such case in the past but I can't remember
which.
Anything which is expecting precise timings from udelay() is broken.
Firstly, udelay()
On Thu, 8 May 2014, Doug Anderson wrote:
Nicolas,
On Thu, May 8, 2014 at 10:43 AM, Nicolas Pitre nicolas.pi...@linaro.org
wrote:
On Thu, 8 May 2014, Doug Anderson wrote:
Longer delays aren't very good, but IMHO having some delays of 100 =
1000 is better than having delays of 100 =
On Thu, 8 May 2014, Russell King - ARM Linux wrote:
Anything which is expecting precise timings from udelay() is broken.
Firstly, udelay() does _not_ guarantee to give you a delay of at least
the requested period - it tries to give an _approximate_ delay.
The first thing to realise is that
On 05/08/2014 01:12 PM, Nicolas Pitre wrote:
On Thu, 8 May 2014, Russell King - ARM Linux wrote:
So, the only /real/ solution if you want proper delays is for udelay()
to use a timer or counter, and this is should always the preferred
method where it's available. Quite rightly, we're not
On Thu, May 08, 2014 at 04:12:14PM -0400, Nicolas Pitre wrote:
On Thu, 8 May 2014, Russell King - ARM Linux wrote:
Anything which is expecting precise timings from udelay() is broken.
Firstly, udelay() does _not_ guarantee to give you a delay of at least
the requested period - it tries to
On Thu, May 08, 2014 at 11:06:24AM -0700, Doug Anderson wrote:
I guess I would say that my patch is unhacking the this code. The
code after my patch is simpler. I would perhaps argue that (ec971ea
ARM: add cpufreq transiton notifier to adjust loops_per_jiffy for smp)
should never have landed
Russel,
On Thu, May 8, 2014 at 1:55 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, May 08, 2014 at 11:06:24AM -0700, Doug Anderson wrote:
I guess I would say that my patch is unhacking the this code. The
code after my patch is simpler. I would perhaps argue that (ec971ea
On Thu, May 08, 2014 at 05:02:02PM -0700, Doug Anderson wrote:
Russel,
On Thu, May 8, 2014 at 1:55 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, May 08, 2014 at 11:06:24AM -0700, Doug Anderson wrote:
I guess I would say that my patch is unhacking the this code. The
On Thu, 8 May 2014, Russell King - ARM Linux wrote:
If you're in a preempt or SMP environment, provide a timer for udelay().
IF you're in an environment with IRQs which can take a long time, use
a timer for udelay(). If you're in an environment where the CPU clock
can change unexpectedly,
Russell,
On Thu, May 8, 2014 at 5:23 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, May 08, 2014 at 05:02:02PM -0700, Doug Anderson wrote:
Russel,
On Thu, May 8, 2014 at 1:55 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, May 08, 2014 at 11:06:24AM
Nicolas,
On Thu, May 8, 2014 at 6:37 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Thu, 8 May 2014, Russell King - ARM Linux wrote:
If you're in a preempt or SMP environment, provide a timer for udelay().
IF you're in an environment with IRQs which can take a long time, use
a timer
Downscaling loops_per_jiffy on SMP ARM systems really doesn't work.
You could really only do this if:
* Each CPU is has independent frequency changes (changing one CPU
doesn't affect another).
* We change the generic ARM udelay() code to actually look at percpu
loops_per_jiffy.
I don't know
Downscaling loops_per_jiffy on SMP ARM systems really doesn't work.
You could really only do this if:
* Each CPU is has independent frequency changes (changing one CPU
doesn't affect another).
* We change the generic ARM udelay() code to actually look at percpu
loops_per_jiffy.
I don't know
62 matches
Mail list logo
