From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrian Hunter Subject: Re: [PATCH v2] mmc: sdhci-of-arasan: Properly set corecfg_clockmultiplier on rk3399 Date: Thu, 1 Sep 2016 15:50:13 +0300 Message-ID: References: <1472201475-7970-1-git-send-email-shawn.lin@rock-chips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1472201475-7970-1-git-send-email-shawn.lin@rock-chips.com> Sender: linux-mmc-owner@vger.kernel.org To: Shawn Lin Cc: Ulf Hansson , linux-mmc@vger.kernel.org, xzy.xu@rock-chips.com, linux-rockchip@lists.infradead.org, Douglas Anderson List-Id: linux-rockchip.vger.kernel.org On 26/08/16 11:51, Shawn Lin wrote: > corecfg_clockmultiplier indicates clock multiplier value of > programmable clock generator which should be the same value > of SDHCI_CAPABILITIES_1. The default value of the register, > corecfg_clockmultiplier, is 0x10. But actually it is a mistake > by designer as our intention was to set it to be zero which > means we don't support programmable clock generator. So we have > to make it to be zero on bootloader which seems work fine until > now. But now we find an issue that when deploying genpd support > for it, the remove callback will trigger the genpd to poweroff the > power domain for sdhci-of-arasan which manage the controller, phy > and corecfg_* stuff. > > So when we do bind/unbind the driver, we have already reinit > the controller and phy, but without doing that for corecfg_*. > Regarding to only the corecfg_clockmultipler is wrong, let's > fix it by explicitly marking it to be zero when probing. With > this change, we could do bind/unbind successfully. > > Reported-by: Ziyuan Xu > Cc: Douglas Anderson > Signed-off-by: Shawn Lin Acked-by: Adrian Hunter