Hi Dave,
 
 
>Maybe try calling might_sleep() instead.
>> Dont know why, might_sleep() is not helping. i put might_sleep in between spin_lock & spin_unlock, it did not work. msleep worked.
>> i found the issue though, as you said they called preempt_disable and forgot to enable it.
>> Thanks for the response.

On Wed, Aug 31, 2011 at 10:53 AM, Dave Hylands <dhylands@gmail.com> wrote:
Hi sandeep,

On Tue, Aug 30, 2011 at 8:40 AM, sandeep kumar
<coolsandyforyou@gmail.com> wrote:
> Hi Dave,
>>>Maybe the device that was added before this one entered the atomic
>>>context and forgot to leave it.
>>>>>by this you mean to say that, the earlier device which was created, in
>>>>> its probe...
> it took some spin_lock and forgot to release the lock?
>
>
>>>You said that you called in_atomic() from msm_bus_fabric_probe and
>>>that it returned zero. Did you do this immediately before the
>>>mutex_lock call that's complaining?
>>>>> yes,i tested the in_atomic() just before the call of clk_get() which
>>>>> inturn
> calls clk_sys_get() which takes the mutex_lock().

Maybe try calling might_sleep() instead.

> My another qn is..
> The message"BUG: sleepin func called ....." is a warning message. it is not
> called by BUG handler.
> So can i neglect it?  i mean it is coming only once while in the probe,
> shall this
> lead to lock up s in future??

It's hard to say. It means that there is a bug somewhere. How
significant  it is depends on exactly  what the bug is.

--
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com



--
With regards,
Sandeep Kumar Anantapalli,