Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755366AbcKBGxx (ORCPT ); Wed, 2 Nov 2016 02:53:53 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:54108 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753023AbcKBGxv (ORCPT ); Wed, 2 Nov 2016 02:53:51 -0400 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org E03B96134D Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=sricharan@codeaurora.org From: "Sricharan" To: "'Stephen Boyd'" Cc: , , , , , References: <1477304297-5248-1-git-send-email-sricharan@codeaurora.org> <1477304297-5248-2-git-send-email-sricharan@codeaurora.org> <20161102001834.GB16026@codeaurora.org> <003c01d234d5$731b19c0$59514d40$@codeaurora.org> In-Reply-To: <003c01d234d5$731b19c0$59514d40$@codeaurora.org> Subject: RE: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control Date: Wed, 2 Nov 2016 12:23:43 +0530 Message-ID: <003e01d234d5$dd3aeab0$97b0c010$@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG+FfkBp35ZYGVHUWKvPRGPq/wjNgLVaGxUAtCrDBICaxkcaaCs9g8Q Content-Language: en-us Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1633 Lines: 47 Hi, >-----Original Message----- >From: linux-arm-msm-owner@vger.kernel.org [mailto:linux-arm-msm-owner@vger.kernel.org] On Behalf Of Sricharan >Sent: Wednesday, November 02, 2016 12:21 PM >To: 'Stephen Boyd' >Cc: mturquette@baylibre.com; linux-clk@vger.kernel.org; linux-arm-msm@vger.kernel.org; linux-kernel@vger.kernel.org; >rnayak@codeaurora.org; stanimir.varbanov@linaro.org >Subject: RE: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control > >Hi Stephen, > >>On 10/24, Sricharan R wrote: >>> @@ -164,6 +171,10 @@ static int gdsc_enable(struct generic_pm_domain *domain) >>> */ >>> udelay(1); >>> >>> + /* Turn on HW trigger mode if supported */ >>> + if (sc->flags & HW_CTRL) >>> + gdsc_hwctrl(sc, true); >>> + >> >>It sounds like this will cause glitches if the hardware isn't >>asserting their hw control bit by default? This has me concerned >>that we can't just throw the hw control enable part into here, >>because that bit doesn't live in the clock controller, instead it >>lives in the hw block that is powered by the power domain? >> >>Or does the power on reset value of that hw control signal >>asserted? If that's true then we should be ok to force it into hw >>control mode by default. >> > >The hw control bit is set by default. Instead its turned 'off' >with the reset value. So it has to not >be turned 'on' at some point >to put the gdsc in hw control if required. This bit is part of the >gdscr register. So i did not quite understand the reason for the >glitch here ? > typo above, i meant it has to be turned 'on' at some point if required. Regards, Sricharan