Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754082AbcKCNa1 (ORCPT ); Thu, 3 Nov 2016 09:30:27 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:55470 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751136AbcKCNa0 (ORCPT ); Thu, 3 Nov 2016 09:30:26 -0400 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org 9AC786145E 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> <20161102175944.GI16026@codeaurora.org> In-Reply-To: <20161102175944.GI16026@codeaurora.org> Subject: RE: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control Date: Thu, 3 Nov 2016 19:00:17 +0530 Message-ID: <000f01d235d6$6e63e680$4b2bb380$@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/wjNgLVaGxUAtCrDBICaxkcaQLM556boJhnebA= Content-Language: en-us Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1596 Lines: 43 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 ? > >I mean the reset value of the hw control signal inside the device >that is inside the GDSC power domain. For example, the hw control >bit inside the video core. > Ok, so the video ip core, has a hw control signal/bit. I checked this by dumping this out that, the moment the gdsc is put to hw control, the video ip's hw control bit also gets asserted/set. so this means that video ip's bit get aligned with the gdsc setting. so this should avoid the glitches, right ? Regards, Sricharan