From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Andrzej Siewior Subject: Re: rt-mutex usage in i2c Date: Mon, 16 Mar 2015 21:50:56 +0100 Message-ID: <55074230.20307@linutronix.de> References: <54FDA380.8030405@linutronix.de> <20150314112703.GD970@katana> <20150314113237.GE970@katana> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mike Rapoport , Wolfram Sang Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mauro Carvalho Chehab , "linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Mike Galbraith , Jean Delvare List-Id: linux-i2c@vger.kernel.org On 03/15/2015 08:07 AM, Mike Rapoport wrote: > On Sat, Mar 14, 2015 at 1:32 PM, Wolfram Sang wro= te: >> On Sat, Mar 14, 2015 at 12:27:03PM +0100, Wolfram Sang wrote: >>> Hi Sebastian, >>> >>>> - i2c_transfer() has this piece: >>>> 2091 if (in_atomic() || irqs_disabled()) { >>>> 2092 ret =3D i2c_trylock_adapter(adap); >>>> >>>> is this irqs_disabled() is what bothers me and should not be the= re. >>>> pxa does a spin_lock_irq() which would enable interrupts on retu= rn / >>>> too early. >>>> mxs has a wait_for_completion() which needs irqs enabled _and_ m= akes >>>> in_atomic() problematic, too. I have't checked other drivers but= the >>>> commit, that introduced it, does not explain why it is required. >=20 > That was some time ago, but as far as I remember, PIO in i2c_pxa was > required to enable communication with PMIC in interrupt context. Let me add one thing I forgot: the locking is using raw locks which are not irq safe. It usually works. But. If the wait_lock is hold during the unlock's slow path (that means there is no owner but the owner field is not yet NULL) and the interrupt handler gets here with a try_lock attempt then and it will spin forever on the wait_lock. I will try to lookup the threads later=E2=80=A6 Sebastian