Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754036AbcKBGuy (ORCPT ); Wed, 2 Nov 2016 02:50:54 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:53566 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751628AbcKBGux (ORCPT ); Wed, 2 Nov 2016 02:50:53 -0400 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org E0BA8615EE 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> In-Reply-To: <20161102001834.GB16026@codeaurora.org> Subject: RE: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control Date: Wed, 2 Nov 2016 12:20:44 +0530 Message-ID: <003c01d234d5$731b19c0$59514d40$@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/wjNgLVaGxUAtCrDBKgwD9j8A== Content-Language: en-us Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1044 Lines: 33 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 ? Regards, Sricharan