From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Dooks Date: Fri, 14 Mar 2014 18:20:10 +0000 Subject: Re: [PATCH] [RFC] ARM: shmobile: koelsch-reference: Work around core clock issues Message-Id: <5323485A.6050606@codethink.co.uk> List-Id: References: <1394720970-4749-1-git-send-email-geert@linux-m68k.org> In-Reply-To: <1394720970-4749-1-git-send-email-geert@linux-m68k.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-sh@vger.kernel.org On 14/03/14 17:55, Ben Dooks wrote: > On 14/03/14 17:33, Ben Dooks wrote: >> On 14/03/14 16:48, Magnus Damm wrote: >>> Hi Ben, >>> >>> That would not surprise me. But it would trigger both for >>> multiplatform and legacy in such case, don't you think? >>> >>> If static enablement using the clock workaround fixes the >>> multiplatform case then it is most likely related to that the driver >>> assumes that Runtime PM controls the clock. Or perhaps some hidden >>> clock dependency that only triggers with CCF? >> >> It seems very sensitive to code (or possibly compiler) in some but >> not all cases we are seeing the system pm the device and then the >> driver does something that requires clocks. >> >> At the moment the depending on how much debug it either works, or >> does not. > > So far I am down to the following being executed > > pm_runtime_enable(&pdev->dev); > pm_runtime_resume(&pdev->dev); > > and by the time it gets to: > > read_mac_address(ndev, pd->mac_addr); > > the ethernet unit's clock has already been disabled. From investigation, the pm is running a work-queue that is causing the clock to be disabled. The only thing I can think is we need to change the > pm_runtime_enable(&pdev->dev); > pm_runtime_resume(&pdev->dev); to include a pm_runtime_get_sync() call. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius