* [PATCH] clk: tegra: use _clk_pll_disable from _program_pll
From: Mike Turquette @ 2013-01-22 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358188572-13005-1-git-send-email-swarren@wwwdotorg.org>
Quoting Stephen Warren (2013-01-14 10:36:12)
> From: Stephen Warren <swarren@nvidia.com>
>
> _program_pll() was dropping the PLL's lock and calling clk_pll_disable().
> clk_pll_disable() does nothing but acquire the same lock and call
> _clk_pll_disable(). So, remove the lock manipulation code, and just call
> _clk_pll_disable() directly instead.
>
> Reported-by: Sivaram Nair <sivaramn@nvidia.com>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> Mike, this also will need to go through the Tegra tree; just looking for
> any review/ack from you. Thanks.
>
Stephen,
This change looks good to me, but should it not be rolled into the tegra
CCF series? Several patches on top of that series have surfaced; do you
plan on posting a V6?
Regards,
Mike
> drivers/clk/tegra/clk-pll.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
> index 474ce1f..9f9bb73 100644
> --- a/drivers/clk/tegra/clk-pll.c
> +++ b/drivers/clk/tegra/clk-pll.c
> @@ -339,14 +339,8 @@ static int _program_pll(struct clk_hw *hw, struct tegra_clk_pll_freq_table *cfg,
> state = clk_pll_is_enabled(hw);
>
> if (state) {
> - if (pll->lock)
> - spin_unlock_irqrestore(pll->lock, flags);
> -
> - clk_pll_disable(hw);
> + _clk_pll_disable(hw);
> val &= ~(PLL_BASE_BYPASS | PLL_BASE_ENABLE);
> -
> - if (pll->lock)
> - spin_lock_irqsave(pll->lock, flags);
> }
> pll_writel_base(val, pll);
>
> --
> 1.7.10.4
^ permalink raw reply
* [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
From: Tony Lindgren @ 2013-01-22 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FE8C5C.2030409@ti.com>
* Benoit Cousson <b-cousson@ti.com> [130122 04:59]:
> Hi Tony,
>
> On 01/21/2013 07:01 PM, Tony Lindgren wrote:
> > * Santosh Shilimkar <santosh.shilimkar@ti.com> [130121 07:09]:
> >>>
> >> So I looked at this one with help of Rajendra. We can get rid of the
> >> IRQ and DMA data(needs DMA biding updates) easily. The address
> >> space though is needed since hwmod code uses it to setup the
> >> sysconfig registers.
> >
> > OK great. The address space tinkering in hwmod code should be
> > moved to be done in the drivers.
> >
> > As discussed earlier, there should be a driver specific reset
> > function driver_xyz_reset() in the driver header file so the
> > hwmod code can call it too in a late_initcall if no driver is
> > loaded.
> >
> >> Extracting that from DT code seems to be really expensive and
> >> ugly [1]. I am yet to try out DMA lines removal but that seems
> >> to be doable by pulling Vinod'd DMA engine branch and updating
> >> DT file.
> >
> > The overhead here does not matter as it should only happen in a
> > late_initcall and only for some of the drivers. For that to
> > happen we just need to go through the list of modules not yet
> > probed. We also need to have some locking in the driver specific
> > reset function to avoid races with the loadable modules.
>
> Mmm, not really, that address is used by *every* hwmod for sysconfig
> access. So iterating over every DT nodes for every hwmods seems pretty
> ugly and un-optimized.
I think you missed one point. Iterating over all the modules should
only happen for the unused modules. With sysconfig access moved to the
drivers getting the ioaddress is done in the standard way in the driver
probe instead of iterating over all of them.
> That being said, it might worth checking the overhead. That will not
> make the fix nicer anyway, but at least it will allow a smooth
> transition toward a real clean solution. Assuming someone will work on
> that later, which might never happen.
Right, so who is going to do all the work needed?
Regards,
Tony
^ permalink raw reply
* [v3 2/2] ARM: tegra: Skip scu_enable(scu_base) if not Cortex A9
From: Stephen Warren @ 2013-01-22 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358833924-24535-2-git-send-email-hdoyu@nvidia.com>
On 01/21/2013 10:52 PM, Hiroshi Doyu wrote:
> Skip scu_enable(scu_base) if CPU is not Cortex A9 with SCU.
Will, is your for-next/perf branch stable; can I pull it into a branch
destined for arm-soc? Background below:
Uggh.
This patch (2/2) depends on "ARM: tegra: Use DT /cpu node to detect
number of CPU core" from your Tegra114 series, since that patch removes
the other use of scu_base, thus allowing this patch to remove that variable.
Then, that patch depends on "ARM: Define CPU part numbers and
implementors" from Will Deacon's ARM perf tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
That means that in order to put this series into arm-soc, we would have
to pull in Will's perf branch first, then the following Tegra patches,
the latter two of which are already in Tegra's for-next, so I'd have to
pull them out:
0bb7bd9 ARM: tegra: Use DT /cpu node to detect number of CPU core
a8f5f25 ARM: tegra: Add CPU nodes to Tegra30 device tree
9975516 ARM: tegra: Add CPU nodes to Tegra20 device tree
Hiroshi, it would be extremely useful if you could explicitly specify
the dependencies of your series when posting them; it took me a long
time and a lot of searching to track all the dependencies down. :-(
^ permalink raw reply
* [PATCH] clk: tegra: ensure all provided clock values are valid cookies
From: Stephen Warren @ 2013-01-22 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122182934.24671.1867@quantum>
On 01/22/2013 11:29 AM, Mike Turquette wrote:
> Quoting Stephen Warren (2013-01-14 10:16:40)
>> From: Stephen Warren <swarren@nvidia.com>
>>
>> Tegra's clock implementation uses pointers as the clock cookies, and
>> hence chooses to make NULL an invalid clock cookie. However, there are
>> gaps in the assigned device tree clock IDs, and hence the array mapping
>> DT clock ID contains entries with NULL values (uninitialized BSS) unless
>> explicit action is taken. This patch enhances the Tegra clock code to
>> detect this case and explicitly initialize those lookup table entries to
>> an error value. This prevents clk_get() from ever returning NULL. Hence,
>> Tegra's clock APIs don't have to check the clock cookie they're passed
>> for NULL.
>>
>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>> ---
>> Mike, this also will need to go through the Tegra tree; just looking for
>> any review/ack from you. Thanks.
>
> Stephen,
>
> I think this is a bit strange. Will you have gaps in the DT clock id's
> forever or is this a temporary issue?
Forever as far as I know. Since the clock IDs are just arbitrary tokens,
I don't see any particular need for them to be strictly packed.
> Also it is important than any driver using the clock api does not
> dereference the struct clk pointer and assume that a NULL clk is
> invalid. I know that this series doesn't imply any such thing but I
> wanted to state that anyways.
Right. This ensures that clk_get() returns an IS_ERR() pointer, or a
valid cookie that the clock driver is prepared to handle (which doesn't
include NULL).
> Also are you planning to roll this into the existing tegra ccf series?
It's already rolled into the latest version of the series which I posted.
^ permalink raw reply
* [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
From: Tony Lindgren @ 2013-01-22 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FE909B.1020001@ti.com>
* Rajendra Nayak <rnayak@ti.com> [130122 05:17]:
> Hi Tony,
>
> >>So I looked at this one with help of Rajendra. We can get rid of the
> >>IRQ and DMA data(needs DMA biding updates) easily. The address
> >>space though is needed since hwmod code uses it to setup the
> >>sysconfig registers.
> >
> >OK great. The address space tinkering in hwmod code should be
> >moved to be done in the drivers.
> >
> >As discussed earlier, there should be a driver specific reset
> >function driver_xyz_reset() in the driver header file so the
> >hwmod code can call it too in a late_initcall if no driver is
> >loaded.
>
> I am a little confused with what you are saying. The hwmod doing
> reset of modules (and not relying on drivers doing it) was
> mainly for modules which do not have drivers built in (and hence
> run a risk of gating system sleep in case the bootloaders left
> them in a bad state).
Right, but we should not duplicate driver code in the hwmod in
those cases. And that's why those reset functions need to be in
the driver specific headers so they work both for the driver
probe, and hwmod late_initcall.
> But if the drivers aren't built in (or are built as modules) *then*
> hwmod still needs to be able to do reset (maybe in a late_initcall) of
> these modules on its own (because there is no driver code to do it).
Yes that's the idea.
> The other big reason why hwmod would need the address space
> tinkering is because it also controls the various OCP master/slave
> modes of these modules. Quite often these modes are broken and
> need tinkering every time the module is enable/idled and also
> need to be restored back to sane values (smart_idle/smart_standby)
> post reset. All of this is today handled as part of hwmod and
> would defeat the whole purpose of the framework if all this is
> moved into drivers.
It seems that we should have the iospace available in the driver
at that point. And it should be also available to the runtime PM
code in hwmod in the device somewhere?
> So completely getting rid of all address space tinkering in hwmod
> looks really difficult.
We can certainly use common hwmod functions via runtime PM for
doing that. There should not be any need to ioremap things both
in hwmod and in the driver. And there certainly should not be
need to provide duplicate iospace from both DT and hwmod. As the
DT is what we're standardizing on, we really must move over to
use that data.
Regards,
Tony
^ permalink raw reply
* [PATCH] clk: tegra: use _clk_pll_disable from _program_pll
From: Stephen Warren @ 2013-01-22 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122183142.24671.75933@quantum>
On 01/22/2013 11:31 AM, Mike Turquette wrote:
> Quoting Stephen Warren (2013-01-14 10:36:12)
>> From: Stephen Warren <swarren@nvidia.com>
>>
>> _program_pll() was dropping the PLL's lock and calling clk_pll_disable().
>> clk_pll_disable() does nothing but acquire the same lock and call
>> _clk_pll_disable(). So, remove the lock manipulation code, and just call
>> _clk_pll_disable() directly instead.
>>
>> Reported-by: Sivaram Nair <sivaramn@nvidia.com>
>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>> ---
>> Mike, this also will need to go through the Tegra tree; just looking for
>> any review/ack from you. Thanks.
>
> Stephen,
>
> This change looks good to me, but should it not be rolled into the tegra
> CCF series? Several patches on top of that series have surfaced; do you
> plan on posting a V6?
(in order to help you find the patches in the list) I posted v5 on 1/16
1:52pm Mountain time, and I posted v6 on 1/17 3:05pm Mountain time. For
v6, only patch 1/3 had any modifications relative to v5, so I didn't
repost the other 2 patches.
^ permalink raw reply
* [PATCH v5 01/45] percpu_rwlock: Introduce the global reader-writer lock backend
From: Stephen Hemminger @ 2013-01-22 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122073315.13822.27093.stgit@srivatsabhat.in.ibm.com>
On Tue, 22 Jan 2013 13:03:22 +0530
"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com> wrote:
> A straight-forward (and obvious) algorithm to implement Per-CPU Reader-Writer
> locks can also lead to too many deadlock possibilities which can make it very
> hard/impossible to use. This is explained in the example below, which helps
> justify the need for a different algorithm to implement flexible Per-CPU
> Reader-Writer locks.
>
> We can use global rwlocks as shown below safely, without fear of deadlocks:
>
> Readers:
>
> CPU 0 CPU 1
> ------ ------
>
> 1. spin_lock(&random_lock); read_lock(&my_rwlock);
>
>
> 2. read_lock(&my_rwlock); spin_lock(&random_lock);
>
>
> Writer:
>
> CPU 2:
> ------
>
> write_lock(&my_rwlock);
>
>
> We can observe that there is no possibility of deadlocks or circular locking
> dependencies here. Its perfectly safe.
>
> Now consider a blind/straight-forward conversion of global rwlocks to per-CPU
> rwlocks like this:
>
> The reader locks its own per-CPU rwlock for read, and proceeds.
>
> Something like: read_lock(per-cpu rwlock of this cpu);
>
> The writer acquires all per-CPU rwlocks for write and only then proceeds.
>
> Something like:
>
> for_each_online_cpu(cpu)
> write_lock(per-cpu rwlock of 'cpu');
>
>
> Now let's say that for performance reasons, the above scenario (which was
> perfectly safe when using global rwlocks) was converted to use per-CPU rwlocks.
>
>
> CPU 0 CPU 1
> ------ ------
>
> 1. spin_lock(&random_lock); read_lock(my_rwlock of CPU 1);
>
>
> 2. read_lock(my_rwlock of CPU 0); spin_lock(&random_lock);
>
>
> Writer:
>
> CPU 2:
> ------
>
> for_each_online_cpu(cpu)
> write_lock(my_rwlock of 'cpu');
>
>
> Consider what happens if the writer begins his operation in between steps 1
> and 2 at the reader side. It becomes evident that we end up in a (previously
> non-existent) deadlock due to a circular locking dependency between the 3
> entities, like this:
>
>
> (holds Waiting for
> random_lock) CPU 0 -------------> CPU 2 (holds my_rwlock of CPU 0
> for write)
> ^ |
> | |
> Waiting| | Waiting
> for | | for
> | V
> ------ CPU 1 <------
>
> (holds my_rwlock of
> CPU 1 for read)
>
>
>
> So obviously this "straight-forward" way of implementing percpu rwlocks is
> deadlock-prone. One simple measure for (or characteristic of) safe percpu
> rwlock should be that if a user replaces global rwlocks with per-CPU rwlocks
> (for performance reasons), he shouldn't suddenly end up in numerous deadlock
> possibilities which never existed before. The replacement should continue to
> remain safe, and perhaps improve the performance.
>
> Observing the robustness of global rwlocks in providing a fair amount of
> deadlock safety, we implement per-CPU rwlocks as nothing but global rwlocks,
> as a first step.
>
>
> Cc: David Howells <dhowells@redhat.com>
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
We got rid of brlock years ago, do we have to reintroduce it like this?
The problem was that brlock caused starvation.
^ permalink raw reply
* [v3 2/2] ARM: tegra: Skip scu_enable(scu_base) if not Cortex A9
From: Will Deacon @ 2013-01-22 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FEDC0B.7050604@wwwdotorg.org>
Hi Stephan,
On Tue, Jan 22, 2013 at 06:35:55PM +0000, Stephen Warren wrote:
> On 01/21/2013 10:52 PM, Hiroshi Doyu wrote:
> > Skip scu_enable(scu_base) if CPU is not Cortex A9 with SCU.
>
> Will, is your for-next/perf branch stable; can I pull it into a branch
> destined for arm-soc? Background below:
I'm going to send a pull request to Russell tomorrow using my for-rmk/perf
branch, so *that* is stable. You might, however, want to wait for Russell to
push that out because it's also needed for kvm and, as such, will need to
be published anyway.
Sound ok?
Will
^ permalink raw reply
* [v3 2/2] ARM: tegra: Skip scu_enable(scu_base) if not Cortex A9
From: Stephen Warren @ 2013-01-22 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122184633.GI2153@mudshark.cambridge.arm.com>
On 01/22/2013 11:46 AM, Will Deacon wrote:
> Hi Stephan,
>
> On Tue, Jan 22, 2013 at 06:35:55PM +0000, Stephen Warren wrote:
>> On 01/21/2013 10:52 PM, Hiroshi Doyu wrote:
>>> Skip scu_enable(scu_base) if CPU is not Cortex A9 with SCU.
>>
>> Will, is your for-next/perf branch stable; can I pull it into a branch
>> destined for arm-soc? Background below:
>
> I'm going to send a pull request to Russell tomorrow using my for-rmk/perf
> branch, so *that* is stable. You might, however, want to wait for Russell to
> push that out because it's also needed for kvm and, as such, will need to
> be published anyway.
>
> Sound ok?
I'm assuming rmk's branch will be a stable base, so that sounds great,
thanks.
^ permalink raw reply
* [PATCH] clk: tegra: add KBC clock for Tegra20
From: Mike Turquette @ 2013-01-22 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FED9BD.5060907@wwwdotorg.org>
Quoting Stephen Warren (2013-01-22 10:26:05)
> On 01/22/2013 11:23 AM, Mike Turquette wrote:
> > Quoting Stephen Warren (2013-01-11 15:17:42)
> >> From: Stephen Warren <swarren@nvidia.com>
> >>
> >> This clock has been missing from all our upstream clock drivers. Add it
> >> by copying the tegra_clk_periph_gate() call from Tegra30; the data
> >> matches what's in the ChromeOS kernel for this clock.
> >>
> >> Cc: Prashant Gaikwad <pgaikwad@nvidia.com>
> >> Cc: Peter De Schrijver <pdeschrijver@nvidia.com>
> >> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> >> ---
> >> Mike, I'd need to apply this to the Tegra tree as part of the common
> >> clock framework conversion.
> >>
> >
> > Is this patch going to be rolled into patch 6/9 of the larger tegra ccf
> > series?
>
> In the latest Tegra CCF series that I posted, I've rolled all these
> small fixes in already.
Right, I just realized that there is a V6 but it has only the three
patches affecting drivers/clk/* instead of the larger nine patch series.
Scanning my inbox I mistakenly thought those were unrelated series.
Regards,
Mike
^ permalink raw reply
* [PATCH v7 14/15] pinctrl: single: support generic pinconf
From: Tony Lindgren @ 2013-01-22 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6h2NTgw4xvaDJfZrw4U3Q=37W5EgqcXaYKTHbzKb-HqbQvgA@mail.gmail.com>
* Haojian Zhuang <haojian.zhuang@linaro.org> [130121 22:01]:
> On 22 January 2013 01:14, Tony Lindgren <tony@atomide.com> wrote:
> > Hi,
> >
> > * Haojian Zhuang <haojian.zhuang@linaro.org> [130117 23:35]:
> >> +static int pcs_parse_pinconf(struct pcs_device *pcs, struct device_node *np,
> >> + struct pcs_function *func,
> >> + struct pinctrl_map **map)
> >> +
> >> +{
> >> + struct pinctrl_map *m = *map;
> >> + int i = 0, nconfs = 0;
> >> + unsigned long *settings = NULL, *s = NULL;
> >> + struct pcs_conf_vals *conf = NULL;
> >> + struct pcs_conf_type prop2[] = {
> >> + { "pinctrl-single,power-source", PIN_CONFIG_POWER_SOURCE, },
> >> + { "pinctrl-single,slew-rate", PIN_CONFIG_SLEW_RATE, },
> >> + { "pinctrl-single,input-schmitt", PIN_CONFIG_INPUT_SCHMITT, },
> >> + };
> >
> > The PIN_CONFIG_POWER_SOURCE should be split to PIN_CONFIG_POWER_ENABLE
> > and PIN_CONFIG_POWER_SOURCE. If you only have one bit for it, I guess then
> > you can just use PIN_CONFIG_POWER_ENABLE and make PIN_CONFIG_POWER_SOURCE
> > a NOP.
> >
>
> In Hisilicon Hi3620 SoC, 4bits are used for power source. b0000 is
> 2mA, b0001 is 4mA, .... b1111 is 8mA.
> There's no power enable bit. In Marvell silicon, it's also same.
Yeah I figured from your earlier mails. Anyways, from client driver point of
view, PIN_CONFIG_POWER_ENABLE should be just a NOP in your case?
This way the same client device driver can work on other platforms that might
also use ENABLE. It's probably unsafe to attempt to handle any ENABLE bits
automatically as the sequence to change POWER_SOURCE and then ENABLE might be
hardware specific.
Then regarding the various values: We probably need a new pinconf generic
function to set the POWER_SOURCE as it need to be passed a value too?
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: Versatile Express: extend the MPIDR range used for pen release check
From: Lorenzo Pieralisi @ 2013-01-22 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301221324220.6300@xanadu.home>
On Tue, Jan 22, 2013 at 06:25:20PM +0000, Nicolas Pitre wrote:
> On Tue, 22 Jan 2013, Lorenzo Pieralisi wrote:
>
> > In ARM multi-cluster systems the MPIDR affinity level 0 cannot be used as a
> > single cpu identifier, affinity levels 1 and 2 must be taken into account as
> > well.
> > This patch extends the MPIDR usage to affinity levels 1 and 2 in versatile
> > secondary cores start up code in order to compare the passed pen_release
> > value with the full-blown affinity mask.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>
> Note that my b.L series makes this patch obsolete.
This is needed to boot TC2 in the mainline. Agreed, when the power API
BSP support for TC2 is merged this can be removed, but waiting for that to
happen we should fix the current code to enable TC2 in its current state.
Lorenzo
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: John Stultz @ 2013-01-22 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122145113.GK23505@n2100.arm.linux.org.uk>
On 01/22/2013 06:51 AM, Russell King - ARM Linux wrote:
> On Tue, Jan 22, 2013 at 03:44:03PM +0530, Santosh Shilimkar wrote:
>> Sorry for not being clear enough. On OMAP, 32KHz is the only clock which
>> is always running(even during low power states) and hence the clock
>> source and clock event have been clocked using 32KHz clock. As mentioned
>> by RMK, with 32768 Hz clock and HZ = 100, there will be always an
>> error of 0.1 %. This accuracy also impacts the timer tick interval.
>> This was the reason, OMAP has been using the HZ = 128.
> Ok. Let's look at this. As far as time-of-day is concerned, this
> shouldn't really matter with the clocksource/clockevent based system
> that we now have (where *important point* platforms have been converted
> over.)
>
> Any platform providing a clocksource will override the jiffy-based
> clocksource. The measurement of time-of-day passing is now based on
> the difference in values read from the clocksource, not from the actual
> tick rate.
>
> Anything _not_ providing a clock source will be reliant on jiffies
> incrementing, which in turn _requires_ one timer interrupt per jiffies
> at a known rate (which is HZ).
Correct. As long as we have a fine-grained hardware clocksource
installed, HZ error should not affect timekeeping in any major way.
> Now, that's the time of day, what about jiffies? Well, jiffies is
> incremented based on a certain number of nsec having passed since the
> last jiffy update. That means the code copes with dropped ticks and
> the like.
>
> However, if your actual interrupt rate is close to the desired HZ, then
> it can lead to some interesting effects (and noise):
>
> - if the interrupt rate is slightly faster than HZ, then you can end up
> with updates being delayed by 2x interrupt rate.
> - if the interrupt rate is slightly slower than HZ, you can occasionally
> end up with jiffies incrementing by two.
> - if your interrupt rate is dead on HZ, then other system noise can come
> into effect and you may get maybe zero, one or two jiffy increments per
> interrupt.
>
> (You have to think about time passing in NS, where jiffy updates should
> be vs where the timer interrupts happen.) See tick_do_update_jiffies64()
> for the details.
Correct, with HRT, we actually trigger the HZ-frequency timer tick from
an hrtimer (which expires based on the system time driven by the
clocksource). Thus even if there is a theoretical error between the
ideal HZ and what the hardware can do, that error will not propagate
forward.
Instead, you may only see timer jitter on the order of how fine-grained
the timer hardware can be triggered. If that is relatively fine, it
shouldn't be an issue, if its relatively coarse (closer to HZ), then
there may be the noise effects you list above. Although that should be
mostly ok since jiffy timers will always have a few jiffys of jitter due
to the granularity (ie: when setting a jiffies timer, you don't how how
far into the current jiffy you are).
In the case where we don't have HRT, and the timers are triggered by the
HZ periodic interrupt, then there is a mix of possibilities, for
hrtimers you'll still see the behavior you list above (since they are
still time based), but for jiffies timers, the rules are mostly inverted
(if the interrupt rate is fast, jiffies timers will trigger sooner, if
the rate is slow, jiffies timers will trigger later).
And if you are using jiffies for time (and not using the
register_refined_jiffies code), then everything will follow the
interrupt freq. So if interrupts are faster then HZ, time will move
faster, timers will expire early, etc.
> The timer infrastructure is jiffy based - which includes scheduling where
> the scheduler does not use hrtimers. That means a slight discrepency
> between HZ and the actual interrupt rate can cause around 1/HZ jitter.
> That's a matter of fact due to how the code works.
>
> So, actually, I think the accuracy of HZ has much overall effect _provided_
> a platform provides a clocksource to the accuracy of jiffy based timers
> nor timekeeping. For those which don't, the accuracy of the timer
> interrupt to HZ is very important.
I think you're right, but I suspect there are some typos in the above.
So to clarify:
The accuracy of HZ shouldn't have much affect on timekeeping on systems
that use fine-grained clocksources. Though for systems that use
jiffies/arch_gettimeoffset() HZ accuracy is more important. However, the
register_refined_jiffies() call should allow for smaller error on those
systems to be corrected.
The accuracy of HZ may have some affect on systems that do not have a
clockevent driver and do not use hrt mode. It should be relatively bounded
> (This is just based on reading some code and not on practical
> experiments - I'd suggest some research of this is done, trying HZ=100
> on OMAP's 32kHz timers, checking whether there's any drift, checking
> how accurately a single task can be woken from various select/poll/epoll
> delays, and checking whether NTP works.)
Yea, for omap and other more "modern" systems with clocksources and
clockevents, HZ=100 should be ok. Although I'd still like to see the
experiments run, since as always, there may be bugs (I'd be interested
in hearing about).
Even on systems w/o clocksources and clockevents, small HZ error should
be able to be managed via the register_refined_jiffies() and I'd like to
hear if folks have issues with that (there may be bounds limits I've not
run into - so I'd like to get that fixed if so).
The only really problematic cases are systems where there aren't
clocksources nor clockevents, and the hardware has specific limits on
what HZ ranges it can do (ie the EBSA110), but I think we're all ok with
those not being able to be compiled into a multi-platform kernel.
thanks
-john
^ permalink raw reply
* [GIT PULL] omap fixes for v3.8-rc4
From: Tony Lindgren @ 2013-01-22 19:18 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.8-rc4/fixes-signed
for you to fetch changes up to 7662a9c60fee25d7234da4be6d8eab2b2ac88448:
ARM: OMAP2+: omap4-panda: add UART2 muxing for WiLink shared transport (2013-01-21 10:39:53 -0800)
----------------------------------------------------------------
Minimal omap fixes for the -rc series:
- A build fix for recently merged omap DRM changes
- Regression fixes from the common clock framework conversion
for omap4 audio and omap2 reboot
- Regression fix for pandaboard WLAN control UART muxing caused by
u-boot only muxing essential pins nowadays
- Timer iteration fix for CONFIG_OF_DYNAMIC
- A section mismatch fix for ocp2scp init
----------------------------------------------------------------
Jon Hunter (1):
ARM: OMAP2: Fix missing omap2xxx_clkt_vps_late_init function calls
Luciano Coelho (1):
ARM: OMAP2+: omap4-panda: add UART2 muxing for WiLink shared transport
Pantelis Antoniou (1):
ARM: OMAP2+: DT node Timer iteration fix
Peter Ujfalusi (2):
ARM: OMAP4: clock data: Lock ABE DPLL on all revisions
ARM: OMAP4: hwmod_data: Correct IDLEMODE for McPDM
Rob Clark (1):
ARM: OMAP2+: fix build break for omapdrm
Tony Lindgren (2):
Merge tag 'omap-fixes-b-for-v3.8-rc' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.8-rc4/fixes
ARM: OMAP2+: Fix section warning for omap_init_ocp2scp()
arch/arm/mach-omap2/board-omap4panda.c | 6 ++++++
arch/arm/mach-omap2/cclock2420_data.c | 2 ++
arch/arm/mach-omap2/cclock2430_data.c | 2 ++
arch/arm/mach-omap2/cclock44xx_data.c | 13 ++++++-------
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/drm.c | 3 ++-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 6 +++++-
arch/arm/mach-omap2/timer.c | 8 ++------
8 files changed, 26 insertions(+), 16 deletions(-)
^ permalink raw reply
* arm: Kernel failures when several memory banks are used with starting address above 128MB
From: Michal Simek @ 2013-01-22 19:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I have a question regarding to the case where DTS specify one memory bank
for example <0x0 0x40000000> with CONFIG_ARM_PATCH_PHYS_VIRT=y
where the kernel can be loaded at a 16MB boundary.
I was testing it on the 3.8-rc4 on arm zynq.
1. If the kernel is loaded within 0 - 127MB memory then the kernel can
work with the whole
1GB memory. It shows that the memory in front of the kernel is also
available for the kernel.
2. If the kernel is loaded on the higher addresses then it fails by
these error messages.
"Ignoring RAM at 00000000-3fffffff (vmalloc region overlap).
Memory policy: ECC disabled, Data cache writeback
Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below 0x0."
3. If I use several memory banks solution
for example
reg = <0 0x10000000 0x10000000 0x30000000>;
and the kernel is loaded to 0x10008000 then the first memory bank is
ignored and kernel will boot.
"Ignoring RAM at 00000000-0fffffff (vmalloc region overlap)." with
768MB of memory.
4. The next interesting example is description with 3 memory banks.
reg = <0 0x10000000 0x10000000 0x20000000 0x30000000 0x10000000>;
which behaves as point 3. It means the first 128MB is ignored and only
768MB of ram is available.
The real question is how the kernel should behave for these situations.
I would expect that if the kernel is within one memory bank
then it will use this whole bank
Or
I would expect that the memory which is in front of the kernel start address
will be simple ignored and the kernel will find out which memory bank
is used and will use it.
Not just caused kernel panic.
Or
Is there any expectation that you have to run the relocatable kernel
in the first 128MB of the memory
or changing DTS depending on the kernel position where it is loaded?
For me is important to solve the case 2 above which can be easily
solved in mm/mmu.c in sanity_check_meminfo
where bank->start and bank->size will be setup depends on kernel position.
Another interesting case is to enable highmem. Kernel starts from
0x10008000 with one memory bank
reg = <0x10000000 0x30000000>; which works without any problem
But for the same case (enable highmem. Kernel starts from 0x10008000.)
with two memory banks.
reg = <0 0x10000000 0x10000000 0x30000000>; is failing with this error.
"Machine: Xilinx Zynq Platform, model: Zynq ZC702 Development Board
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writeback
Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below 0x0."
Also this is the case which quite weird because kernel with higmem on
wants to use the first memory
bank and then failed. My proposed solution is to ignore all memory
banks which are in front of the kernel
which ensure that these
Thanks for your comments,
Michal
^ permalink raw reply
* [GIT PULL] omap fixes for v3.8-rc4
From: Olof Johansson @ 2013-01-22 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122191801.GQ22517@atomide.com>
On Tue, Jan 22, 2013 at 11:18 AM, Tony Lindgren <tony@atomide.com> wrote:
> The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
>
> Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.8-rc4/fixes-signed
Pulled, thanks.
-Olof
^ permalink raw reply
* [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
From: Jason Gunthorpe @ 2013-01-22 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117162218.GA29016@arm.com>
On Thu, Jan 17, 2013 at 04:22:18PM +0000, Andrew Murray wrote:
> > In either of those cases, does it make sense to use the MSI support
> > outside the scope of the PCI infrastructure? That is, would devices
> > other than PCI devices be able to generate an MSI?
>
> I've come around to your way of thinking. Your approach sounds good for
> registration of MSI ops - let the RC host driver do it (it probably has its
> own), or use a helper for following a phandle to get ops that are not part
> of the driver. MSIs won't be used outside of PCI devices.
Here is a bit of additional info on some MSI stuff..
This can be pretty complex. For instance on hyper transport systems
the PCI to HT bridge has an MSI controller that maps between PCI and
HT MSI formats, that mapping is configurable, so technically each
brige could be considered a MSI controller. Typically the mapping
controllers are all setup the same so there is not much problem with
this. However *native* HT devices can (which are super rare) can use a
different MSI format than PCI devices. From a linux perspective HT is
just a variant of PCI.
On x86 the MSI is delivered to the CPU APIC complex which converts it
into a vectored interrupt - part of the value of MSI is that the MSI
data can vector the interrupt to a specific CPU, or group of CPUs or
whatever.
Presumably SMP ARMs will evolve similar MSI based interrupt vectoring
capabilities, and presumably on-chip, non-PCI peripherals will evolve
options to use MSI as well (ie multi-queue ethernet). So it might be
worth giving some thought to how things could migrate in that
direction someday.
I have a bit hacky MSI driver for Kirkwood, this work you have to
generalize the interface could let me actually upstream it :) The MSI
is built using the Host2CPU doorbell registers, so it is entirely
unrelated to the PCI-E RC driver.
However, my use of the MSI driver on kirkwood is to assign MSIs to a
PCI-E device via non-standard registers, more like an on chip
peripheral. This is because the Host2CPU doorbell doesn't fit 100%
perfectly with the standard PCI MSI stuff, and the hardware has funny
needs.. So an 'allocate a MSI interrupt' API would be snazzy too :)
Jason
^ permalink raw reply
* [PATCH v5 01/45] percpu_rwlock: Introduce the global reader-writer lock backend
From: Steven Rostedt @ 2013-01-22 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122073315.13822.27093.stgit@srivatsabhat.in.ibm.com>
On Tue, 2013-01-22 at 13:03 +0530, Srivatsa S. Bhat wrote:
> A straight-forward (and obvious) algorithm to implement Per-CPU Reader-Writer
> locks can also lead to too many deadlock possibilities which can make it very
> hard/impossible to use. This is explained in the example below, which helps
> justify the need for a different algorithm to implement flexible Per-CPU
> Reader-Writer locks.
>
> We can use global rwlocks as shown below safely, without fear of deadlocks:
>
> Readers:
>
> CPU 0 CPU 1
> ------ ------
>
> 1. spin_lock(&random_lock); read_lock(&my_rwlock);
>
>
> 2. read_lock(&my_rwlock); spin_lock(&random_lock);
>
>
> Writer:
>
> CPU 2:
> ------
>
> write_lock(&my_rwlock);
>
I thought global locks are now fair. That is, a reader will block if a
writer is waiting. Hence, the above should deadlock on the current
rwlock_t types.
We need to fix those locations (or better yet, remove all rwlocks ;-)
-- Steve
^ permalink raw reply
* [PATCH] Dove: activate GPIO interrupts in DT
From: Sebastian Hesselbarth @ 2013-01-22 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122112845.4f7c0f38@armhf>
On 01/22/2013 11:28 AM, Jean-Francois Moine wrote:
> In a DT, the interrupts of an interrupt-controller are not usable when
> #interrupt-cells is missing.
>
> This patch activates the interrupts of the GPIOs 0 and 1 for the Marvell
> Dove SoC.
>
> Signed-off-by: Jean-Fran?ois Moine<moinejf@free.fr>
>
> diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
> index 42eac1f..287fb12 100644
> --- a/arch/arm/boot/dts/dove.dtsi
> +++ b/arch/arm/boot/dts/dove.dtsi
> @@ -93,6 +93,7 @@
> reg =<0xd0400 0x20>;
> ngpios =<32>;
> interrupt-controller;
> + #interrupt-cells =<1>;
> interrupts =<12>,<13>,<14>,<60>;
> };
>
> @@ -103,6 +104,7 @@
> reg =<0xd0420 0x20>;
> ngpios =<32>;
> interrupt-controller;
> + #interrupt-cells =<1>;
> interrupts =<61>;
> };
>
Jean-Francois,
first thanks for sending the patch!
I checked Documentation/devicetree/bindings/gpio/gpio-mvebu.txt and there
#interrupt-cells is specified to be set to two. Further, I checked kirkwood.dtsi
and it is also missing the #interrupt-cells.
Can you please update your patch to have #interrupt-cells set to two? When you
resend v2 of the patch please Cc at least all I added.
I will send another patch fixing kirkwood.dtsi.
Sebastian
^ permalink raw reply
* [PATCH v5 01/45] percpu_rwlock: Introduce the global reader-writer lock backend
From: Srivatsa S. Bhat @ 2013-01-22 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122104506.32b4e581@nehalam.linuxnetplumber.net>
On 01/23/2013 12:15 AM, Stephen Hemminger wrote:
> On Tue, 22 Jan 2013 13:03:22 +0530
> "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>
>> A straight-forward (and obvious) algorithm to implement Per-CPU Reader-Writer
>> locks can also lead to too many deadlock possibilities which can make it very
>> hard/impossible to use. This is explained in the example below, which helps
>> justify the need for a different algorithm to implement flexible Per-CPU
>> Reader-Writer locks.
>>
>> We can use global rwlocks as shown below safely, without fear of deadlocks:
>>
>> Readers:
>>
>> CPU 0 CPU 1
>> ------ ------
>>
>> 1. spin_lock(&random_lock); read_lock(&my_rwlock);
>>
>>
>> 2. read_lock(&my_rwlock); spin_lock(&random_lock);
>>
>>
>> Writer:
>>
>> CPU 2:
>> ------
>>
>> write_lock(&my_rwlock);
>>
>>
>> We can observe that there is no possibility of deadlocks or circular locking
>> dependencies here. Its perfectly safe.
>>
>> Now consider a blind/straight-forward conversion of global rwlocks to per-CPU
>> rwlocks like this:
>>
>> The reader locks its own per-CPU rwlock for read, and proceeds.
>>
>> Something like: read_lock(per-cpu rwlock of this cpu);
>>
>> The writer acquires all per-CPU rwlocks for write and only then proceeds.
>>
>> Something like:
>>
>> for_each_online_cpu(cpu)
>> write_lock(per-cpu rwlock of 'cpu');
>>
>>
>> Now let's say that for performance reasons, the above scenario (which was
>> perfectly safe when using global rwlocks) was converted to use per-CPU rwlocks.
>>
>>
>> CPU 0 CPU 1
>> ------ ------
>>
>> 1. spin_lock(&random_lock); read_lock(my_rwlock of CPU 1);
>>
>>
>> 2. read_lock(my_rwlock of CPU 0); spin_lock(&random_lock);
>>
>>
>> Writer:
>>
>> CPU 2:
>> ------
>>
>> for_each_online_cpu(cpu)
>> write_lock(my_rwlock of 'cpu');
>>
>>
>> Consider what happens if the writer begins his operation in between steps 1
>> and 2 at the reader side. It becomes evident that we end up in a (previously
>> non-existent) deadlock due to a circular locking dependency between the 3
>> entities, like this:
>>
>>
>> (holds Waiting for
>> random_lock) CPU 0 -------------> CPU 2 (holds my_rwlock of CPU 0
>> for write)
>> ^ |
>> | |
>> Waiting| | Waiting
>> for | | for
>> | V
>> ------ CPU 1 <------
>>
>> (holds my_rwlock of
>> CPU 1 for read)
>>
>>
>>
>> So obviously this "straight-forward" way of implementing percpu rwlocks is
>> deadlock-prone. One simple measure for (or characteristic of) safe percpu
>> rwlock should be that if a user replaces global rwlocks with per-CPU rwlocks
>> (for performance reasons), he shouldn't suddenly end up in numerous deadlock
>> possibilities which never existed before. The replacement should continue to
>> remain safe, and perhaps improve the performance.
>>
>> Observing the robustness of global rwlocks in providing a fair amount of
>> deadlock safety, we implement per-CPU rwlocks as nothing but global rwlocks,
>> as a first step.
>>
>>
>> Cc: David Howells <dhowells@redhat.com>
>> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
>
> We got rid of brlock years ago, do we have to reintroduce it like this?
> The problem was that brlock caused starvation.
>
Um? I still see it in include/linux/lglock.h and its users in fs/ directory.
BTW, I'm not advocating that everybody start converting their global reader-writer
locks to per-cpu rwlocks, because such a conversion probably won't make sense
in all scenarios.
The thing is, for CPU hotplug in particular, the "preempt_disable() at the reader;
stop_machine() at the writer" scheme had some very desirable properties at the
reader side (even though people might hate stop_machine() with all their
heart ;-)), namely :
At the reader side:
o No need to hold locks to prevent CPU offline
o Extremely fast/optimized updates (the preempt count)
o No need for heavy memory barriers
o Extremely flexible nesting rules
So this made perfect sense at the reader for CPU hotplug, because it is expected
that CPU hotplug operations are very infrequent, and it is well-known that quite
a few atomic hotplug readers are in very hot paths. The problem was that the
stop_machine() at the writer was not only a little too heavy, but also inflicted
real-time latencies on the system because it needed cooperation from _all_ CPUs
synchronously, to take one CPU down.
So the idea is to get rid of stop_machine() without hurting the reader side.
And this scheme of per-cpu rwlocks comes close to ensuring that. (You can look
at the previous versions of this patchset [links given in cover letter] to see
what other schemes we hashed out before coming to this one).
The only reason I exposed this as a generic locking scheme was because Tejun
pointed out that, complex locking schemes implemented in individual subsystems
is not such a good idea. And also this comes at a time when per-cpu rwsemaphores
have just been introduced in the kernel and Oleg had ideas about converting the
cpu hotplug (sleepable) locking to use them.
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* [PATCH v2 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
From: Ezequiel Garcia @ 2013-01-22 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122182749.GM15361@atomide.com>
On Tue, Jan 22, 2013 at 3:27 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Ezequiel Garcia <elezegarcia@gmail.com> [130122 10:17]:
>> On Mon, Jan 21, 2013 at 10:32 PM, Daniel Mack <zonque@gmail.com> wrote:
>> >
>> > I'm currently far away from my computer and can't prepare a patch for this, sorry. But I think you are right, so please just submit a patch for that, anyone :-)
>> >
>>
>> Ok, I'll try to submit a patch as soon as possible. If anyone wants to
>> do it instead, fine by me.
>
> No please go ahead as it seems that you can easily test it too.
>
No problem.
I now wonder if it's okey to exit upon probe failure.
In particular, the for_each should be like this:
for_each_node_by_name(child, "nand") {
ret = gpmc_probe_nand_child(pdev, child);
if (ret < 0) {
of_node_put(child);
return ret;
}
}
or like this:
for_each_node_by_name(child, "nand") {
ret = gpmc_probe_nand_child(pdev, child);
WARN_ON(ret < 0);
}
Ideas?
--
Ezequiel
^ permalink raw reply
* [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL
From: Matt Sealey @ 2013-01-22 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122095021.89432qdbeu32a4sg@www.dalek.fi>
On Tue, Jan 22, 2013 at 1:50 AM, Jussi Kivilinna
<jussi.kivilinna@mbnet.fi> wrote:
>
>> There is 'tcrypt' module in crypto/ for quick benchmarking. 'modprobe
>> tcrypt mode=500 sec=1' tests AES in various cipher-modes, using different
>> buffer sizes and outputs results to kernel log.
>>
>
> Actually mode=200 might be better, as mode=500 is for asynchronous
> implementations and might use hardware crypto if such device/module is
> available.
Okeydokey I'll start running some tests..
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* [PATCH] ARM: kirkwood: fix missing #interrupt-cells property
From: Sebastian Hesselbarth @ 2013-01-22 19:46 UTC (permalink / raw)
To: linux-arm-kernel
The gpio controller on kirkwood can provide interrupts but is missing
the #interrupt-cells property. This patch just adds it to both gpio
controllers.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Jamie Lentin <jm@lentin.co.uk>
Cc: Jean-Francois Moine <moinejf@free.fr>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
arch/arm/boot/dts/kirkwood.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 110d6cb..d6ab442 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -36,6 +36,7 @@
reg = <0x10100 0x40>;
ngpios = <32>;
interrupt-controller;
+ #interrupt-cells = <2>;
interrupts = <35>, <36>, <37>, <38>;
};
@@ -46,6 +47,7 @@
reg = <0x10140 0x40>;
ngpios = <18>;
interrupt-controller;
+ #interrupt-cells = <2>;
interrupts = <39>, <40>, <41>;
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH v5 01/45] percpu_rwlock: Introduce the global reader-writer lock backend
From: Srivatsa S. Bhat @ 2013-01-22 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358883152.21576.55.camel@gandalf.local.home>
On 01/23/2013 01:02 AM, Steven Rostedt wrote:
> On Tue, 2013-01-22 at 13:03 +0530, Srivatsa S. Bhat wrote:
>> A straight-forward (and obvious) algorithm to implement Per-CPU Reader-Writer
>> locks can also lead to too many deadlock possibilities which can make it very
>> hard/impossible to use. This is explained in the example below, which helps
>> justify the need for a different algorithm to implement flexible Per-CPU
>> Reader-Writer locks.
>>
>> We can use global rwlocks as shown below safely, without fear of deadlocks:
>>
>> Readers:
>>
>> CPU 0 CPU 1
>> ------ ------
>>
>> 1. spin_lock(&random_lock); read_lock(&my_rwlock);
>>
>>
>> 2. read_lock(&my_rwlock); spin_lock(&random_lock);
>>
>>
>> Writer:
>>
>> CPU 2:
>> ------
>>
>> write_lock(&my_rwlock);
>>
>
> I thought global locks are now fair. That is, a reader will block if a
> writer is waiting. Hence, the above should deadlock on the current
> rwlock_t types.
>
Oh is it? Last I checked, lockdep didn't complain about this ABBA scenario!
> We need to fix those locations (or better yet, remove all rwlocks ;-)
>
:-)
The challenge with stop_machine() removal is that the replacement on the
reader side must have the (locking) flexibility comparable to preempt_disable().
Otherwise, that solution most likely won't be viable because we'll hit way
too many locking problems and go crazy by the time we convert them over..(if
we can, that is!)
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* [PATCH] ARM: Versatile Express: extend the MPIDR range used for pen release check
From: Nicolas Pitre @ 2013-01-22 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122185833.GE3959@e102568-lin.cambridge.arm.com>
On Tue, 22 Jan 2013, Lorenzo Pieralisi wrote:
> On Tue, Jan 22, 2013 at 06:25:20PM +0000, Nicolas Pitre wrote:
> > On Tue, 22 Jan 2013, Lorenzo Pieralisi wrote:
> >
> > > In ARM multi-cluster systems the MPIDR affinity level 0 cannot be used as a
> > > single cpu identifier, affinity levels 1 and 2 must be taken into account as
> > > well.
> > > This patch extends the MPIDR usage to affinity levels 1 and 2 in versatile
> > > secondary cores start up code in order to compare the passed pen_release
> > > value with the full-blown affinity mask.
> > >
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> >
> > Note that my b.L series makes this patch obsolete.
>
> This is needed to boot TC2 in the mainline. Agreed, when the power API
> BSP support for TC2 is merged this can be removed, but waiting for that to
> happen we should fix the current code to enable TC2 in its current state.
Sensible.
Acked-by: Nicolas Pitre <nico@linaro.org>
Nicolas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox