From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH 09/14] bus: ti-sysc: Move rstctrl reset to happen later Date: Wed, 27 Mar 2019 11:37:38 -0700 Message-ID: <20190327183738.GE49658@atomide.com> References: <20190325215849.13182-1-tony@atomide.com> <20190325215849.13182-10-tony@atomide.com> <20190326231306.GC49658@atomide.com> <20190326234022.GD49658@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Suman Anna Cc: linux-omap@vger.kernel.org, Dave Gerlach , Faiz Abbas , Greg Kroah-Hartman , Keerthy , Nishanth Menon , Peter Ujfalusi , Roger Quadros , Tero Kristo , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org List-Id: linux-omap@vger.kernel.org * Suman Anna [190327 16:27]: > On 3/26/19 6:40 PM, Tony Lindgren wrote: > > That's for rstctrl. I just did a quick test with my earlier > > reset-simple patch and I noticed sgx on am33xx produces a > > clock error unless we deassert it's rstrctrl before enabling > > clocks first: > > > > gfx-l3-clkctrl:0004:0: failed to enable > > Yeah, and I see a similar one across the other modules controlled by > RSTCTRL bits for me as well - MMUs, PRUSS etc. This is because you can > only check the module ready status in _omap4_clkctrl_clk_enable() only > both after the clocks are turned on and resets are deasserted. That > check will always fail with rstctrl asserted. The omap_hwmod code does > use the reset status checks for bailing out, but that stuff is not > present in clkctrl code and can only be achieved by adding a > CLKF_NO_IDLEST (somewhat misnamed) to the corresponding clkctrl atm. Sounds like on ti-sysc init we should just deassert the rstctrl if asserted, then enable clocks, and then read the revision. Then if we actually need to toggle rstctrl reset, that can be added with later patches. But with reset driver, the device IP handling device driver(s) should probably manage the rstctrl bits directly. > See [1] for AM33xx SGX. I will be posting some of these once I check the > behavior. Yeah OK sounds like we can avoid those issues by deasserting the module related rstctrl bit before enabling the clocks. Then deal with resets later if needed. > > Note that you probably also want to leave out the struct > > omap_hwmod data from omap_hwmod_*_data.c files with rstctrl > > entries. > > You mean no hwmod entries at all, or hwmod entries with no rstctrl data? Except for the lack of rstctrl reset driver, struct hwmod_data entries should only be needed for the few cases where we're not yet handling some oh->flags quirks. I think most of the remaining unhandled quirks are for omap2 and 3. Regards, Tony > [1] > http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=commitdiff;h=536d660714e98bdb7f96e5990a095283e52e4d8a > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25E08C4360F for ; Wed, 27 Mar 2019 18:37:59 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EA4D92147C for ; Wed, 27 Mar 2019 18:37:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eJFg/bYE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EA4D92147C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atomide.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=lVlf07CgKQiez1cq10yuTIgA7KtLB6lD+UVUXUrrdLE=; b=eJFg/bYEjMs+qi MICoYqJniWZmeu/gTeYXgRmY4H6eBkYZUp9WNsozunNwA8x1u50YiByl6v0mZAVkkItjbFmc0BN/S vvgBYo2Pf1jTr0zWzHYfrqwGLP4AuJKeUPFIFSP97r5glpNokTx/DzQOVbCFZ/IZTOqSjS4bfEzbt uC8qO9PtpH/HBkYLGtku9FIDQNYRI3E4Y0WsET4jenvt33QsIFLM74/5iBBeqlVMXUfysC9DJycle TkqC08POaezRn3mFxiRZZU9YrNZRr0be2g/rMvYyfYaGqLHi5VR77vJY/MFtVd8/W3ciCQVvSAZ6r gegp67J8adieBkIhHh9g==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h9DQu-0002ju-6b; Wed, 27 Mar 2019 18:37:52 +0000 Received: from muru.com ([72.249.23.125]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h9DQo-0002jF-1d for linux-arm-kernel@lists.infradead.org; Wed, 27 Mar 2019 18:37:49 +0000 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id BA5F680BB; Wed, 27 Mar 2019 18:37:55 +0000 (UTC) Date: Wed, 27 Mar 2019 11:37:38 -0700 From: Tony Lindgren To: Suman Anna Subject: Re: [PATCH 09/14] bus: ti-sysc: Move rstctrl reset to happen later Message-ID: <20190327183738.GE49658@atomide.com> References: <20190325215849.13182-1-tony@atomide.com> <20190325215849.13182-10-tony@atomide.com> <20190326231306.GC49658@atomide.com> <20190326234022.GD49658@atomide.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190327_113746_131987_E09D6B44 X-CRM114-Status: GOOD ( 17.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Nishanth Menon , Tero Kristo , Dave Gerlach , Keerthy , linux-kernel@vger.kernel.org, Peter Ujfalusi , Faiz Abbas , Greg Kroah-Hartman , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Roger Quadros Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org * Suman Anna [190327 16:27]: > On 3/26/19 6:40 PM, Tony Lindgren wrote: > > That's for rstctrl. I just did a quick test with my earlier > > reset-simple patch and I noticed sgx on am33xx produces a > > clock error unless we deassert it's rstrctrl before enabling > > clocks first: > > > > gfx-l3-clkctrl:0004:0: failed to enable > > Yeah, and I see a similar one across the other modules controlled by > RSTCTRL bits for me as well - MMUs, PRUSS etc. This is because you can > only check the module ready status in _omap4_clkctrl_clk_enable() only > both after the clocks are turned on and resets are deasserted. That > check will always fail with rstctrl asserted. The omap_hwmod code does > use the reset status checks for bailing out, but that stuff is not > present in clkctrl code and can only be achieved by adding a > CLKF_NO_IDLEST (somewhat misnamed) to the corresponding clkctrl atm. Sounds like on ti-sysc init we should just deassert the rstctrl if asserted, then enable clocks, and then read the revision. Then if we actually need to toggle rstctrl reset, that can be added with later patches. But with reset driver, the device IP handling device driver(s) should probably manage the rstctrl bits directly. > See [1] for AM33xx SGX. I will be posting some of these once I check the > behavior. Yeah OK sounds like we can avoid those issues by deasserting the module related rstctrl bit before enabling the clocks. Then deal with resets later if needed. > > Note that you probably also want to leave out the struct > > omap_hwmod data from omap_hwmod_*_data.c files with rstctrl > > entries. > > You mean no hwmod entries at all, or hwmod entries with no rstctrl data? Except for the lack of rstctrl reset driver, struct hwmod_data entries should only be needed for the few cases where we're not yet handling some oh->flags quirks. I think most of the remaining unhandled quirks are for omap2 and 3. Regards, Tony > [1] > http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=commitdiff;h=536d660714e98bdb7f96e5990a095283e52e4d8a > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel