Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760163AbcDMLkR (ORCPT ); Wed, 13 Apr 2016 07:40:17 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:35639 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756473AbcDMLkO (ORCPT ); Wed, 13 Apr 2016 07:40:14 -0400 MIME-Version: 1.0 In-Reply-To: <20160411221126.GD14441@codeaurora.org> References: <1459842403-4052-1-git-send-email-ssambang@codeaurora.org> <20160411221126.GD14441@codeaurora.org> Date: Wed, 13 Apr 2016 13:40:12 +0200 Message-ID: Subject: Re: [PATCH] qcom: sdhci-msm: enable the DLL clock From: Ulf Hansson To: Stephen Boyd Cc: Sreedhar Sambangi , Andy Gross , linux-mmc , "linux-arm-msm@vger.kernel.org" , qca-upstream.external@qca.qualcomm.com, Ivan Ivanov , Georgi Djakov , "linux-kernel@vger.kernel.org" , Adrian Hunter Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1633 Lines: 42 On 12 April 2016 at 00:11, Stephen Boyd wrote: > On 04/11, Ulf Hansson wrote: >> + Adrian >> >> On 5 April 2016 at 09:46, Sreedhar Sambangi wrote: >> > The DLL clock has to be enabled until the correct >> > clock frequency is delivered to DLL >> > '1'(default) - DLL clock is disabled >> > '0' - dll clock has legacly clock enable. >> > >> > Signed-off-by: Varadarajan Narayanan >> > Signed-off-by: Sreedhar Sambangi >> >> Adrian Hunter is the maintainer for sdhci, next time make sure to post to him. >> >> As this seems like fairly trivial change I decided to pick it up >> anyway. So applied for next! >> >> Note, that I changed the prefix of the commit message header to "mmc". >> > > I'm not sure this patch is actually right. In the downstream > sources we do quite a few more reads and writes if we need to > poke this second DLL configuration register. Furthermore, on > msm8974 and apq8084 this register doesn't even exist so writing > to it may cause problems if it isn't write ignored (I haven't > checked). > > I think we should follow the downstream kernel design instead. > Namely, reading the major/minor version registers to figure out > if we should be touching this register in the first place, and > then adding a clock property to the DT binding for the XO source > so we can determine the XO frequency. It seems that we need this > frequency to figure out how to program the second DLL > configuration register appropriately. Stephen, Thanks for reviewing. I have dropped this patch for now. Kind regards Uffe