Return-path: Received: from mail-bk0-f46.google.com ([209.85.214.46]:65202 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756213Ab2KALKw (ORCPT ); Thu, 1 Nov 2012 07:10:52 -0400 Received: by mail-bk0-f46.google.com with SMTP id jk13so1012164bkc.19 for ; Thu, 01 Nov 2012 04:10:51 -0700 (PDT) Message-ID: <509258B6.5080104@gmail.com> (sfid-20121101_121105_271769_B55E8A11) Date: Thu, 01 Nov 2012 12:10:46 +0100 From: Daniel Mack MIME-Version: 1.0 To: Andrei Emeltchenko CC: Bing Zhao , "linux-wireless@vger.kernel.org" , Amitkumar Karwar , "Porter, Matt" Subject: Re: mwifiex_sdio problem: firmware fails to be active in time References: <507F4448.2040707@gmail.com> <477F20668A386D41ADCC57781B1F7043083B80E44A@SC-VEXCH1.marvell.com> <50802984.6070203@gmail.com> <508AF992.8070606@gmail.com> <508D53EE.7050405@gmail.com> <20121101094812.GC17693@aemeltch-MOBL1> In-Reply-To: <20121101094812.GC17693@aemeltch-MOBL1> Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 01.11.2012 10:48, Andrei Emeltchenko wrote: > Hi Daniel, > > On Sun, Oct 28, 2012 at 04:49:02PM +0100, Daniel Mack wrote: >> On 26.10.2012 22:58, Daniel Mack wrote: >>> [have to re-open this issue again] >>> >>> On 21.10.2012 16:16, Andrei Emeltchenko wrote: >>>> I have the same board and see this problem sometimes. Reloading modules >>>> might help, if not reboot always works :). >>> >>> I thought I solved this issue, but I can't reproduce the running version >>> anymore unfortunately. It constantly fails with the error I described, >>> even though the clock and all voltages etc are definitely stable. >> >> Ok, following up on my own writings: I solved this issue. It took me >> awhile to figure out that the 88WSD8787 is really picky about the >> clock/power sequencing. It really needs >= 1ms delay in the startup >> phase, otherwise the firmware won't start up. > > So did you put delay in a marvell sdio driver? No, that has to be done by some code that first enables the clock and then asserts the PDN line (assuming that clock is generated by some sort of PLL or CPU). Daniel