Re: [PATCH REPOST] gpio: omap: use raw locks for locking
On Fri, Jun 19, 2015 at 7:42 PM, santosh shilimkar santosh.shilim...@oracle.com wrote: On 6/19/2015 10:06 AM, Sebastian Andrzej Siewior wrote: This patch converts gpio_bank.lock from a spin_lock into a raw_spin_lock. The call path is to access this lock is always under a raw_spin_lock, for instance - __setup_irq() holds desc-lock with irq off + __irq_set_trigger() + omap_gpio_irq_type() - handle_level_irq() (runs with irqs off therefore raw locks) + mask_ack_irq() + omap_gpio_mask_irq() This fixes the obvious backtrace on -RT. However the locking vs context is not and this is not limited to -RT: - omap_gpio_irq_type() is called with IRQ off and has an conditional call to pm_runtime_get_sync() which may sleep. Either it may happen or it may not happen but pm_runtime_get_sync() should not be called with irqs off. - omap_gpio_debounce() is holding the lock with IRQs off. + omap2_set_gpio_debounce() + clk_prepare_enable() + clk_prepare() this one might sleep. The number of users of gpiod_set_debounce() / gpio_set_debounce() looks low but still this is not good. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- Should be safe to do it. Acked-by: Santosh Shilimkar ssant...@kernel.org Answered on the wrong thread, sorry for the noise. Acked-by: Javier Martinez Canillas jav...@dowhile0.org Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in
Re: [PATCH] gpio: omap: use raw locks for locking
Hello Sebastian, On Thu, Feb 12, 2015 at 5:10 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: This patch converts gpio_bank.lock from a spin_lock into a raw_spin_lock. The call path to access this lock is always under a raw_spin_lock, for instance - __setup_irq() holds desc-lock with irq off + __irq_set_trigger() + omap_gpio_irq_type() - handle_level_irq() (runs with irqs off therefore raw locks) + mask_ack_irq() + omap_gpio_mask_irq() This fixes the obvious backtrace on -RT. However I noticed two cases where it looks wrong and this is not limited to -RT: - omap_gpio_irq_type() is called with IRQ off and has an conditional call to pm_runtime_get_sync() which may sleep. Either it may happen or it may not happen but pm_runtime_get_sync() should not be called in an atomic section. - omap_gpio_debounce() is holding the lock with IRQs off. + omap2_set_gpio_debounce() + clk_prepare_enable() + clk_prepare() this one might sleep. The number of users of gpiod_set_debounce() / gpio_set_debounce() looks low but still this is not good. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- I had already acked the first time you posted this [0] but you didn't carry the tag so here goes again: Acked-by: Javier Martinez Canillas jav...@dowhile0.org Best regards, Javier [0]: https://patchwork.ozlabs.org/patch/439249/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in
Re: [PATCH] i2c: omap: improve duty cycle on SCL
On Fri, Jun 19, 2015 at 07:41:49AM +0200, Michael Lawnick wrote: Am 18.06.2015 um 19:24 schrieb Felipe Balbi: On Thu, Jun 18, 2015 at 08:39:11AM +0200, Michael Lawnick wrote: Am 17.06.2015 um 17:38 schrieb Felipe Balbi: Hi, On Wed, Jun 17, 2015 at 01:09:53PM +0200, Michael Lawnick wrote: Am 16.06.2015 um 21:17 schrieb Felipe Balbi: With this patch we try to be as close to 50% duty cycle as possible. The reason for this is that some devices present an erratic behavior with certain duty cycles. One such example is TPS65218 PMIC which fails to change voltages when running @ 400kHz and duty cycle is lower than 34%. The idea of the patch is simple: calculate desired scl_period from requested scl and use 50% for tLow and 50% for tHigh. ... Hmm, and what's about Philips I2C specification 2.1, Jan 2000, Table 5? PARAMETER SYMBOL STANDARD-MODE FAST-MODE UNIT MIN. MAX. MIN. MAX. LOW period of the SCL clock tLOW 4.7 – 1.3 – µs HIGH period of the SCL clocktHIGH 4.0 – 0.6 – µs Your signal is in spec (0.85 µs high, 1,65 low). Maybe your TPS65218 is just buggy or signals are bad? yes, tps is buggy, it's written in the commit log itself. So I think it is unacceptable to change the adapters code violating specification because some buggy device doesn't work properly. read the other thread and you'll see that it's not violating jack This change for your device has chance to blow up many correctly working ones. How ? The answer is so obvious that I'm a bit irritated. Your patch description tells: 'and use 50% for tLow and 50% for tHigh' another one who can't do simple algebra. http://marc.info/?l=linux-i2cm=143456423512634w=2 http://marc.info/?l=linux-i2cm=143456444212698w=2 http://marc.info/?l=linux-omapm=143456762413953w=2 For 400kHz this means 1.25 us for high and low. This clearly violates the specification for minimum low period and will not work with any device that relies on it. In the other thread it is discussed that your patch does effectively not do what you describe but this is something completely independent. Read the comment where the calculation goes, it states that we try to get as close to 50% duty cycle while making sure we're within spec. Also, commit log is saying that we're using 50% of SCL period for tLow and tHigh calculation, not that duty cycle will be 50%, which it isn't. -- balbi signature.asc Description: Digital signature
[PATCH REPOST] gpio: omap: use raw locks for locking
This patch converts gpio_bank.lock from a spin_lock into a
raw_spin_lock. The call path is to access this lock is always under a
raw_spin_lock, for instance
- __setup_irq() holds desc-lock with irq off
+ __irq_set_trigger()
+ omap_gpio_irq_type()
- handle_level_irq() (runs with irqs off therefore raw locks)
+ mask_ack_irq()
+ omap_gpio_mask_irq()
This fixes the obvious backtrace on -RT. However the locking vs context
is not and this is not limited to -RT:
- omap_gpio_irq_type() is called with IRQ off and has an conditional
call to pm_runtime_get_sync() which may sleep. Either it may happen or
it may not happen but pm_runtime_get_sync() should not be called with
irqs off.
- omap_gpio_debounce() is holding the lock with IRQs off.
+ omap2_set_gpio_debounce()
+ clk_prepare_enable()
+ clk_prepare() this one might sleep.
The number of users of gpiod_set_debounce() / gpio_set_debounce()
looks low but still this is not good.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/gpio/gpio-omap.c | 78 +++
1 file changed, 39 insertions(+), 39 deletions(-)
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -57,7 +57,7 @@ struct gpio_bank {
u32 saved_datain;
u32 level_mask;
u32 toggle_mask;
- spinlock_t lock;
+ raw_spinlock_t lock;
struct gpio_chip chip;
struct clk *dbck;
u32 mod_usage;
@@ -498,14 +498,14 @@ static int omap_gpio_irq_type(struct irq
(type (IRQ_TYPE_LEVEL_LOW|IRQ_TYPE_LEVEL_HIGH)))
return -EINVAL;
- spin_lock_irqsave(bank-lock, flags);
+ raw_spin_lock_irqsave(bank-lock, flags);
retval = omap_set_gpio_triggering(bank, offset, type);
omap_gpio_init_irq(bank, offset);
if (!omap_gpio_is_input(bank, offset)) {
- spin_unlock_irqrestore(bank-lock, flags);
+ raw_spin_unlock_irqrestore(bank-lock, flags);
return -EINVAL;
}
- spin_unlock_irqrestore(bank-lock, flags);
+ raw_spin_unlock_irqrestore(bank-lock, flags);
if (type (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH))
__irq_set_handler_locked(d-irq, handle_level_irq);
@@ -626,14 +626,14 @@ static int omap_set_gpio_wakeup(struct g
return -EINVAL;
}
- spin_lock_irqsave(bank-lock, flags);
+ raw_spin_lock_irqsave(bank-lock, flags);
if (enable)
bank-context.wake_en |= gpio_bit;
else
bank-context.wake_en = ~gpio_bit;
writel_relaxed(bank-context.wake_en, bank-base + bank-regs-wkup_en);
- spin_unlock_irqrestore(bank-lock, flags);
+ raw_spin_unlock_irqrestore(bank-lock, flags);
return 0;
}
@@ -668,7 +668,7 @@ static int omap_gpio_request(struct gpio
if (!BANK_USED(bank))
pm_runtime_get_sync(bank-dev);
- spin_lock_irqsave(bank-lock, flags);
+ raw_spin_lock_irqsave(bank-lock, flags);
/* Set trigger to none. You need to enable the desired trigger with
* request_irq() or set_irq_type(). Only do this if the IRQ line has
* not already been requested.
@@ -678,7 +678,7 @@ static int omap_gpio_request(struct gpio
omap_enable_gpio_module(bank, offset);
}
bank-mod_usage |= BIT(offset);
- spin_unlock_irqrestore(bank-lock, flags);
+ raw_spin_unlock_irqrestore(bank-lock, flags);
return 0;
}
@@ -688,11 +688,11 @@ static void omap_gpio_free(struct gpio_c
struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
unsigned long flags;
- spin_lock_irqsave(bank-lock, flags);
+ raw_spin_lock_irqsave(bank-lock, flags);
bank-mod_usage = ~(BIT(offset));
omap_disable_gpio_module(bank, offset);
omap_reset_gpio(bank, offset);
- spin_unlock_irqrestore(bank-lock, flags);
+ raw_spin_unlock_irqrestore(bank-lock, flags);
/*
* If this is the last gpio to be freed in the bank,
@@ -794,9 +794,9 @@ static unsigned int omap_gpio_irq_startu
if (!BANK_USED(bank))
pm_runtime_get_sync(bank-dev);
- spin_lock_irqsave(bank-lock, flags);
+ raw_spin_lock_irqsave(bank-lock, flags);
omap_gpio_init_irq(bank, offset);
- spin_unlock_irqrestore(bank-lock, flags);
+ raw_spin_unlock_irqrestore(bank-lock, flags);
omap_gpio_unmask_irq(d);
return 0;
@@ -808,11 +808,11 @@ static void omap_gpio_irq_shutdown(struc
unsigned long flags;
unsigned offset = d-hwirq;
- spin_lock_irqsave(bank-lock, flags);
+ raw_spin_lock_irqsave(bank-lock, flags);
bank-irq_usage = ~(BIT(offset));
omap_disable_gpio_module(bank, offset);
omap_reset_gpio(bank, offset);
- spin_unlock_irqrestore(bank-lock, flags);
+ raw_spin_unlock_irqrestore(bank-lock, flags);
Re: [PATCH v2] futex: lower the lock contention on the HB lock during wake up
On Wed, Jun 17, 2015 at 1:33 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: wake_futex_pi() wakes the task before releasing the hash bucket lock (HB). The first thing the woken up task usually does is to acquire the lock which requires the HB lock. On SMP Systems this leads to blocking on the HB lock which is released by the owner shortly after. This patch rearranges the unlock path by first releasing the HB lock and then waking up the task. [bigeasy: redo ontop of lockless wake-queues] Signed-off-by: Thomas Gleixner t...@linutronix.de Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- * Davidlohr Bueso | 2015-06-16 12:50:26 [-0700]: I prefer having two separate patches, thus keeping their own changelog for the change justification. okay, here it is on top of #1. A handful of boot test failures on ARM/OMAP were found by kernelci.org in next-20150619[1] and were bisected down to this patch, which hit next-20150619 in the form of commit 881bd58d6e9e (futex: Lower the lock contention on the HB lock during wake up). I confirmed that reverting that patch on top of next-20150619 gets things booting again for the affected platforms. I haven't debugged this any further, but full boot logs are available for the boot failures[2][3] and the linux-omap list and maintainer are Cc'd here to help investigate further if needed. Kevin [1] http://kernelci.org/boot/all/job/next/kernel/next-20150619/ [2] http://storage.kernelci.org/next/next-20150619/arm-multi_v7_defconfig/lab-khilman/boot-omap5-uevm.html [3] http://storage.kernelci.org/next/next-20150619/arm-omap2plus_defconfig/lab-tbaker/boot-omap3-beagle-xm.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in
Re: [PATCH REPOST] gpio: omap: use raw locks for locking
On 6/19/2015 10:06 AM, Sebastian Andrzej Siewior wrote: This patch converts gpio_bank.lock from a spin_lock into a raw_spin_lock. The call path is to access this lock is always under a raw_spin_lock, for instance - __setup_irq() holds desc-lock with irq off + __irq_set_trigger() + omap_gpio_irq_type() - handle_level_irq() (runs with irqs off therefore raw locks) + mask_ack_irq() + omap_gpio_mask_irq() This fixes the obvious backtrace on -RT. However the locking vs context is not and this is not limited to -RT: - omap_gpio_irq_type() is called with IRQ off and has an conditional call to pm_runtime_get_sync() which may sleep. Either it may happen or it may not happen but pm_runtime_get_sync() should not be called with irqs off. - omap_gpio_debounce() is holding the lock with IRQs off. + omap2_set_gpio_debounce() + clk_prepare_enable() + clk_prepare() this one might sleep. The number of users of gpiod_set_debounce() / gpio_set_debounce() looks low but still this is not good. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- Should be safe to do it. Acked-by: Santosh Shilimkar ssant...@kernel.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in
Re: [PATCH v2] futex: lower the lock contention on the HB lock during wake up
Thomas Gleixner t...@linutronix.de writes: On Fri, 19 Jun 2015, Kevin Hilman wrote: On Wed, Jun 17, 2015 at 1:33 AM, Sebastian Andrzej Siewior A handful of boot test failures on ARM/OMAP were found by kernelci.org in next-20150619[1] and were bisected down to this patch, which hit next-20150619 in the form of commit 881bd58d6e9e (futex: Lower the lock contention on the HB lock during wake up). I confirmed that reverting that patch on top of next-20150619 gets things booting again for the affected platforms. I haven't debugged this any further, but full boot logs are available for the boot failures[2][3] and the linux-omap list and maintainer are Cc'd here to help investigate further if needed. Found it. Dunno, how I missed that one. Fix below. Yup, that fix on top of next-20150619 gets the two OMAP platforms booting again. Tested-by: Kevin Hilman khil...@linaro.org Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in
Re: [PATCH v2] futex: lower the lock contention on the HB lock during wake up
On Fri, 19 Jun 2015, Kevin Hilman wrote:
On Wed, Jun 17, 2015 at 1:33 AM, Sebastian Andrzej Siewior
A handful of boot test failures on ARM/OMAP were found by kernelci.org
in next-20150619[1] and were bisected down to this patch, which hit
next-20150619 in the form of commit 881bd58d6e9e (futex: Lower the
lock contention on the HB lock during wake up). I confirmed that
reverting that patch on top of next-20150619 gets things booting again
for the affected platforms.
I haven't debugged this any further, but full boot logs are available
for the boot failures[2][3] and the linux-omap list and maintainer are
Cc'd here to help investigate further if needed.
Found it. Dunno, how I missed that one. Fix below.
Thanks,
tglx
---
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 10dbeb6fe96f..5674b073473c 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1365,9 +1365,14 @@ rt_mutex_fastunlock(struct rt_mutex *lock,
if (likely(rt_mutex_cmpxchg(lock, current, NULL))) {
rt_mutex_deadlock_account_unlock(current);
- } else if (slowfn(lock, wake_q)) {
+ } else {
+ bool deboost = slowfn(lock, wake_q);
+
+ wake_up_q(wake_q);
+
/* Undo pi boosting if necessary: */
- rt_mutex_adjust_prio(current);
+ if (deboost)
+ rt_mutex_adjust_prio(current);
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
