From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Hansson Subject: Re: [PATCH v3 2/7] mmc: mediatek: Add Mediatek MMC driver Date: Mon, 11 May 2015 12:29:42 +0200 Message-ID: References: <1430214525-19198-1-git-send-email-chaotian.jing@mediatek.com> <1430214525-19198-3-git-send-email-chaotian.jing@mediatek.com> <1430895299.15154.9.camel@mhfsdcap03> <1430962956.15154.48.camel@mhfsdcap03> <1431335885.26820.7.camel@mhfsdcap03> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from mail-qk0-f169.google.com ([209.85.220.169]:33317 "EHLO mail-qk0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752713AbbEKK3n (ORCPT ); Mon, 11 May 2015 06:29:43 -0400 Received: by qkx62 with SMTP id 62so83412948qkx.0 for ; Mon, 11 May 2015 03:29:42 -0700 (PDT) In-Reply-To: <1431335885.26820.7.camel@mhfsdcap03> Sender: linux-gpio-owner@vger.kernel.org List-Id: linux-gpio@vger.kernel.org To: Chaotian Jing Cc: Rob Herring , Matthias Brugger , Chris Ball , Mark Rutland , James Liao , srv_heupstream , Arnd Bergmann , "devicetree@vger.kernel.org" , Hongzhou Yang , Catalin Marinas , linux-mmc , Will Deacon , "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" , Sascha Hauer , "Joe.C" , Eddie Huang , =?UTF-8?B?QmluIFpoYW5nICjnq6Dmlowp?= , "linux-arm-kernel@lists.infradead.org" , linux-mediatek On 11 May 2015 at 11:18, Chaotian Jing wrote: > On Fri, 2015-05-08 at 14:12 +0200, Ulf Hansson wrote: >> On 7 May 2015 at 03:42, Chaotian Jing wrote: >> > Dear Ulf, >> > >> > Thanks! >> > Below is my comment: >> > >> > On Wed, 2015-05-06 at 18:31 +0200, Ulf Hansson wrote: >> >> On 6 May 2015 at 08:54, chaotian.jing wrote: >> >> > Dear Ulf, >> >> > >> >> > Thanks for your review. >> >> > I must do a explain of our MMC host: >> >> > Source clock is source clock of the MMC bus, MMC host has a divider to >> >> > get different bus clock frequency. now the runtime suspend is gating >> >> > this clock. >> >> > >> >> > Hclk is the power domain of the MMC host, if Hclk is gated, the MMC host >> >> > cannot work(all registers readout is zero). and, all registers would be >> >> > reset to default value if Hclk is gated/ungated. >> >> > At MT8173, MSDC0 and MSDC2 has independent Hclk, MSDC1 and MSDC3's Hclk >> >> > was controlled by "Infra module". >> > Sorry for mistake, MSDC0 and MSDC3 has independent Hclk, MSDC1 and >> > MSDC2's Hclk was controlled by "Infra module". the Infra module is a >> > "power saving module", when the system go to sleep, Infra module will be >> > set and MSDC1 & MSDC2's Hclk will be gated automatically. >> >> >> >> Thanks for clarifying! >> >> >> >> I don't have enough knowledge about your SoC to understand the detail, >> >> but it seems like we are mixing clocks and power domains. I would >> >> rather keep this separate - if the HW allows it. >> >> >> >> I guess the key question I have is the following: >> >> 1) Is it hardware wise possible to gate the hclk, but without gating >> >> the power domain? >> >> 2) At what level is the reference counting done for each device in the >> >> power domain? In HW or in sofftware? >> >> >> > >> > Actually, Our MMC host do not have power domain, all the control of the >> > host is the Hclk. >> >> Okay, but I am not sure that fully answered my question. >> >> You said that hclk will be gated when the power domain gets gated. And >> the power domain (infra module, right?) will be gated at system PM >> sleep. And when that happens the mmc controller loses register >> context. >> >> But, again, can hclk be gated without gating the power domain? >> >> No matter what, it seems like a good idea to gate the power domain >> when all clients of it are idle. Yes we would need to manage register >> save/restore context, but on the other hand allow you to save more >> power, right? >> > For MSDC0 & MSDC3, it has independent HCLK, do not have power domain. > For MSDC1 & MSDC2, its HCLK was controlled by Infra module(This is a big > power domain for many modules). > So, for msdc0 & msdc3, we can control its Hclk, for msdc1 & msdc2, we > cannot control it. Okay, thanks for the clarification! > > Yes, I will do gate/ungate HCLK & source clock in PM. > In addition, Since the gate/ungate HCLK is done by runtime PM, and all > register operation should work at HCLK is on, so the msdc_init_hw() only > can be called at set_ios(), because in probe(), the HCLK may have not > been enabled. I suggest you to enable HCLK in ->probe() and thus you may also call msdc_init_hw() from there. This should simplify for you, when adding the runtime PM support. Kind regards Uffe