Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3518825imu; Fri, 18 Jan 2019 11:49:35 -0800 (PST) X-Google-Smtp-Source: ALg8bN5TPFDxSQn6oT5FeSyo+8EU1UHqruZm663fmTOXCnP0xyLGn+kFX/vJWKsrmMAdHQfFOCch X-Received: by 2002:a17:902:201:: with SMTP id 1mr20267301plc.62.1547840975474; Fri, 18 Jan 2019 11:49:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547840975; cv=none; d=google.com; s=arc-20160816; b=oUFJ4U2mOp1CSP69kb5ODq4W44lv9BawUrhWc5nU3ZXa8YjB+1LGC5ADNi+K2hRr8T iGMiKdcL4++ijM+ypoEqV9G/Wk9VApFvJj+TvVP8de8f6/1HjJEfjkL6ZbX8to/pm62H cLfCLFpyL6LgQXnRf6YpahzrX5rQum1bwxy3tlopvMVDj4BJBomkuTv4JuyOpnnTuSui Junym8YUpq93/geWmyxEgEtLFE6Uv2BPciXTSgTRjFNXEcaAtoiOR6XjFG/v1N8atUde /8gmonk4tPCjTjl+5xUmG+3du6Wr9DMPU4r29AiSXPj14RYMh9E3PEN0RDxXePkMyIWj 6vPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=oS6iNa/ShYV0VKiRmqIYXnTGXeUDp/SJgVHF/K1NEPQ=; b=GmObhicWBwUDbMgBwpBUkVKf1uLCywXhuLCK0htPP4Rwk1h+YXameHlm+bzofP6j2N Xw8ShQwNrTsTFveka7phIOWSuoxvX2wcrXix7MhsSTjLdDxCI94gSyrEMlbnBg81yvjr 1oO4sIPZ9jRo7uDhq/gJnuDll1bGLps9VS0mL9beyDS5MnriQ/rrvzpXqx5Q9xCFuqK1 NUAOdqReMV4SljI25ZZTkHUkFDrpsKBzgDSCnq0gire9fJSo1ZhOAynUOD09oFe8lPoq FfnYq0TNBoxk3arBlvptgiW+Fx0sdMc/PdXle1tm0kcjflEF760VWqMoskjZEvDOWdXo 5qug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z14si4819519pgu.525.2019.01.18.11.49.19; Fri, 18 Jan 2019 11:49:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729410AbfARTsH (ORCPT + 99 others); Fri, 18 Jan 2019 14:48:07 -0500 Received: from muru.com ([72.249.23.125]:34284 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729262AbfARTsG (ORCPT ); Fri, 18 Jan 2019 14:48:06 -0500 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 7597E8047; Fri, 18 Jan 2019 19:48:12 +0000 (UTC) Date: Fri, 18 Jan 2019 11:48:02 -0800 From: Tony Lindgren To: Andreas Kemnade Cc: Discussions about the Letux Kernel , paul@pwsan.com, sboyd@kernel.org, mturquette@baylibre.com, linux-kernel@vger.kernel.org, t-kristo@ti.com, bcousson@baylibre.com, linux-omap@vger.kernel.org, linux-clk@vger.kernel.org, Keerthy Subject: Re: [Letux-kernel] [PATCH v3 3/3] arm: omap_hwmod disable ick autoidling when a hwmod requires that Message-ID: <20190118194802.GZ5544@atomide.com> References: <20190116220429.9136-1-andreas@kemnade.info> <20190116220429.9136-4-andreas@kemnade.info> <20190118154807.GV5544@atomide.com> <20190118181827.7163bee4@aktux> <20190118183630.GX5544@atomide.com> <20190118203832.3be7975e@aktux> <20190118204204.44db353f@aktux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190118204204.44db353f@aktux> User-Agent: Mutt/1.11.1 (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andreas Kemnade [190118 19:42]: > On Fri, 18 Jan 2019 20:38:47 +0100 > Andreas Kemnade wrote: > > > Hi, > > > > On Fri, 18 Jan 2019 10:36:30 -0800 > > Tony Lindgren wrote: > > > > [...] > > > til the next workaround. > > > > > > > That flags also causes the iclk being enabled/disabled > > > > manually. > > > > > > Yes but SWSUP_IDLE for the interface clock to me currently > > > just means: > > > > > > "manually enable and disable ocp interface clock" > > > > > well, if we want to manually disable it and not automatically, > > we have to disable autoidle or it will be automatically disabled. > > > > Disabling it manually when it is already auto-disabled (by autoidle) is > > just practically a no-op towards the clock. > > > > > and with your changes it becomes: > > > > > > "manually enable and disable ocp interface clock and block > > > autoidle while in use". > > > > > > So aren't we now changing the way things behave in general > > > for SWSUP_IDLE? > > > > > Yes, we are, so proper testing is needed. But If I read those comments > > it was always intended this way but not fully implemented because it > > appeared to be more work like needing a usecounter (which my patchset > > also adds) for that autoidle flag. > > > and there are quite few hwmods marked by this flag. > And then there are those clocks marked by this flags (on am33xx) which > do not have that autoidle feature at all, so the risk is not too high. Keerthy, can you please test this series on top of the related clock patches with your am335x PM test cases? Regards, Tony