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=DKIMWL_WL_HIGH,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 C64C1C169C4 for ; Wed, 6 Feb 2019 15:57:09 +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 8E8AF2080D for ; Wed, 6 Feb 2019 15:57:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="UJPFOOJc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E8AF2080D 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=0QzdlUx85YeNZA1DBq2qg1uDePvzTNnv1KAYtrmcZto=; b=UJPFOOJcLshmOT 2xYrf56AxUHg83EM3TpercYkn/pyC4KIzp+KFFm+yz6Vn9Fybva/CaQuRDwX1DWnBmLx/1lMz0uge EcdP058A29bmBDrji8FWkgxsp4uJ8HYHo0uqlMR974ypio656ngX37B9wTjgQ3hI2bogBSaJd9oMq wBC3vH3TBAyAuwCDoSAWlPoJtKvHmn2SFabvXeUftovRzhbWYte38bW+d+G2nuQpJ0A4Nv9fW0kfH CYsxE/gNX3oi9RB62/4L7YX9BpISPe6YQ4pWYKgsYvqdORwdPiwwF9r2wI4ZSfjINp+i3p06Elk1N tqhcn1zibSuTiAOFDfNg==; 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 1grPZP-0003VM-Bj; Wed, 06 Feb 2019 15:57:03 +0000 Received: from muru.com ([72.249.23.125]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1grPZL-0003Uy-Ml for linux-arm-kernel@lists.infradead.org; Wed, 06 Feb 2019 15:57:01 +0000 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 934AA80D4; Wed, 6 Feb 2019 15:57:06 +0000 (UTC) Date: Wed, 6 Feb 2019 07:56:54 -0800 From: Tony Lindgren To: Andreas Kemnade Subject: Re: [PATCH] omap3: give off mode enable a more prominent place Message-ID: <20190206155654.GX5720@atomide.com> References: <20190202055827.12956-1-andreas@kemnade.info> <20190204155604.GH5720@atomide.com> <20190204193311.102a60e6@kemnade.info> <20190204184317.GO5720@atomide.com> <20190206073732.35ad315f@kemnade.info> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190206073732.35ad315f@kemnade.info> User-Agent: Mutt/1.11.2 (2019-01-07) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190206_075659_786831_8C57BE49 X-CRM114-Status: GOOD ( 18.90 ) 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: linux-omap@vger.kernel.org, khilman@kernel.org, linux-kernel@vger.kernel.org, linux@armlinux.org.uk, letux-kernel@openphoenux.org, linux-arm-kernel@lists.infradead.org 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 * Andreas Kemnade [190206 06:38]: > But wait... twl4030-power.c is to a big part about switching regulators > on and off. But how does that connect to hwmods going to ret or off > mode? That is imho slightly another topic. The pmic wiring is what must be configured for the regulators to actually get cut off. And the wiring may or may not be done properly. The SoC powerdomain bit to attempt off mode is a policy type decision and should not be configured in the device tree. > Ok, looking a bit closer, there is the sys_off_mode line > which needs to be used. > So we have to derive that from the devicetree. Yes but that still does not mean it's wired right to the PMIC :) We do have devices where sys_off_mode and sys_clkreq lines are swapped for example. So enabling off mode really should be only allowed if the PMIC is configured right. And we also support devices that do muxing in the bootloader like all the Nokia devices do except for dynamic pins. I guess reading how the sys_clkreq is configured might work, but not necessarily until the PMIC driver has probed depending which device handles the muxing. And it won't work for devices with lines swapped. > > The PMIC is wired and configured for off mode, and those > > properties should not be set unless the system is truly capable > > of entering off mode. If not set, we should not enable off > > idle by default. > > > > Otherwise the boards should be already using just > > "ti,twl4030-power" or "ti,twl4030-power-reset". > > > We have also > ti,twl4030-power-omap3-sdp, > ti,twl4030-power-omap3-ldp, > ti,twl4030-power-omap3-evm > > so we have to maintain a list, especially if we want to allow another > pmic. Oops so it seems. Those are all early devices with their own quirks. Anyways, that list is unlikely to change any longer for twl4030. > But since it is about connecting the soc to the pmic, we could also add a > flag in the dtb on the soc side, so we are prepared if someone uses another > pmic. It feels a bit strange to query something from devicetree for another > device. Well if you have something that actually describes the hardware in mind for the SoC, sure. But let's not start adding any policy flags to the dts. Any other pmics would need their own checks to determine if off mode is configured. It might depend on the firmware on the pmic for example. But I don't think we need to worry about that right now since we don't have any such users in the mainline kernel. > PS: I hope my omap-gta04.dtsi-related patches have made their way into > your review queue and are not starving in a generic lkml fallback folder Yup I should have the thread tagged in my inbox. Regards, Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel