> -----Original Message----- > From: Hiroshi DOYU [mailto:Hiroshi.DOYU@xxxxxxxxx] > Sent: Monday, June 07, 2010 10:40 PM > To: ohad@xxxxxxxxxx > Cc: Chitriki Rudramuni, Deepak; Guzman Lugo, Fernando; Ramirez Luna, Omar; > Kanigeri, Hari; linux-omap@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo > > From: ext Ohad Ben-Cohen <ohad@xxxxxxxxxx> > Subject: Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo > Date: Mon, 7 Jun 2010 23:40:34 +0200 > > > Hi Deepak, > > > > On Mon, Jun 7, 2010 at 1:52 PM, Deepak Chitriki <deepak.chitriki@xxxxxx> > wrote: > >> With this patch I observed "inconsistent lock state" warning. > > > > Thanks for the report! > > > >> Kfifo is acccessed in omap_mbox_msg_send() and mbox_tx_tasklet() > >> functions.In order to protect this critical section we need to protect > by > >> using spin_lock_bh() so that the tasklet cannot preempt > >> omap_mobx_msg_send(). > > > > This is actually not the problem: it's ok if mbox_tx_tasklet preempts > > omap_mbox_msg_send. In fact, such a use case is even ok if we don't > > take a spinlock at all: kfifo is designed in a way that if you have > > only 1 consumer and 1 producer, they can both access kfifo > > simultaneously without any locking. That's why we don't take the > > spinlock in the mbox_tx_tasklet. The reason, btw, that we take a > > spinlock in omap_mbox_msg_send is to allow multiple simultaneous > > sending contexts (taking a spinlock there ensures serialization of > > those multiple simultaneous sending contexts). > > > > The problem here lies in the fact (that I've just learnt) that > > dspbridge also sends mbox messages from a tasklet context > > (dpc_tasklet). Lockdep identifies that the spinlock is taken in a > > softirq context (dspbridge's dpc_tasklet) after it was previously > > taken in a softirq-enabled context. Your proposed fix will solve the > > lockdep issue here, but: > > > > Do we really want to have tasklets in dspbridge ? Are we that > > performance critical ? > > Can't a whole contents of bridge_msg_get()/bridge_msg_put() be > replaced with omap mailbox APIs? > > It seems that dspbridge does the same message queueing and deferred > execution as omap mailbox does in the above 2 functions. At least > bridge_msg_put() looks similar to omap_mbox_msg_send(). If this works, > we can reduce the size of dspbridge again;) Yes, it has a pretty similar method to send the messages. However the messages send by bridge_msg_put() is a shared memory message, which has a cmd fiel and 2 arguments fields and the bridge used a mailbox message just to indicate to the DSP that it has some pending shared memory messages. Regards, Fernando. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
