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=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 45D3FC433ED for ; Sun, 9 May 2021 10:52:03 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 BD38F61400 for ; Sun, 9 May 2021 10:52:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BD38F61400 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Y2Ra8uiGNxB4n6JbYznqdgyvrmUyiKA/3ykqNqbqs7U=; b=VyVqpLqrx/KMG9eSyJ4ikOs9r iAoPE+qojRs3GnRM7iOkxxGlV8AAd8SgwGPiaACIQL1R0y/dB5x3iBscQhSnkimlVRP96+O1yoJx5 GXSBou4Z+rSpmj51ZTAM+aVWu+xAFH6j4LzZQ30Lmhcxks8jxQMsybb2CIfpLUGzl/NJI6b5u3w6L qD1OWYA6XY8yuO78bGPjJ1NQ8OaWCfQ0lcjNx7M/sD3NkqwPOX6vEa7szmsktLdnOGGAgaxg7BwA9 HIA4oBsh+/Ta/1PlKRucVQzYbQasSgfNcgFJ5r1UdreNbLmucjc3vxwqUAnJnmBcZdDKHw9rD0LTk x6T7m+sYA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lfh0T-00BT84-Nj; Sun, 09 May 2021 10:49:53 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lfh0R-00BT7U-8A for linux-arm-kernel@desiato.infradead.org; Sun, 09 May 2021 10:49:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=mQafJtBEfmRTcgozALwkE9M1nF4kym6hXG0iG0sUNgY=; b=q241vs3N6+Jw3+JV8KuQPInxJ4 1UjtzmQ6sokMgIn4dv/nMyOUxqkn2F8C7SLns8AOzQwoPVUdNr+Cj5kj96m0hOoNH+c235B24Creu OHF5Ki+7SB8yENJdWtsCWDnDFmoJQr+2U0RxhLSPkD9ffApuhcEUre0EC470yped/dst6ZodWHbu0 SDIaxqb3q/J9VxvR4+aK7kE0ddX7+LWr53j6Y1VAx/FeD7iiBGpLc2sDObdN1XxwyW+zChRJ+3dhc wviZWw0aMFmAJuZ2Rft/Wv8468aSO9QLjXpBLN9I2+GwUMToNN+wb66Hze2dxi4wtSQqRRvYoWw9J EpZ7BFAg==; Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lfh0O-007wQh-6Z for linux-arm-kernel@lists.infradead.org; Sun, 09 May 2021 10:49:49 +0000 Received: by mail-lj1-x233.google.com with SMTP id o16so17222779ljp.3 for ; Sun, 09 May 2021 03:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mQafJtBEfmRTcgozALwkE9M1nF4kym6hXG0iG0sUNgY=; b=W2SlqBumDyfZmBDebluEBm0aD61vrqdgA+9lfx0m+eDN2ySYr4WoOetQRyABotFRmV ukH8eRgS+44+3xw1sWPdQxS045PpSc74KRsKhyLCwb1Y0nbmZsdvzLEKp/GSwLWNn1Ce Q9WlXY56TT/vi/Qh8or36sgc9agzph6RuzoFWWTrIyxmplxTmPJZh5zMvMymB0CHNMwQ sSZPi07BLZwtndKImXPv6nWBacfC+9wvWKIuHF/IHgL2PujYQGvJRpMR2o7xT/yHx9So et4j0uw2pJveVSzAN2k3dHlFFDwv+/tbUm228lL1gRyoRM52utJ5soaXK1LQqdtR97ws PzqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mQafJtBEfmRTcgozALwkE9M1nF4kym6hXG0iG0sUNgY=; b=iFPYOHHfmxj1WxqFBD8zAzyfWVW5u1p07DqXG12lrMG27oW1Xdtc101apDjTRASi6g eYm8RHJ2E0803tVFyi/SYHHwhPgM/0I4kPOlq+289FTJu8KuMrObuP/9TA4WxGYLjKJ3 sjaDbQ6EaX6G+nYcXYXNHtZxTZenyPPz2MbavwcLzqBGs5jJB391CmhCk8uouFALqgK3 XtlZfZuM1QVco5PQGAlI5Bsms7NTqv0t7dmgXBgn+LWtvrS07RvGdY8P3u4Y2UBTL5QH vggwZKPNBBadWkqnwFb4kJ+Zb9dXVnIj1QwIlqgNfUZunyQkjoZSp9IRhypyzrGrITAS 7gfg== X-Gm-Message-State: AOAM533MNEc5zRNdwGrV7cgxIiTK/bash3AcLB6wmunTPcDlGKo7SL3m 5++T9ar2y7KLmIukuCzRTTriGx2Qjcvwq8+A8S7klw== X-Google-Smtp-Source: ABdhPJw48ytLdN9bKt+Jcnukhvew4xZlQCf6DsNPReSjSfwt96BlLgFJ83xaiLx57shTh2pGawA/4lu8FX6M0NiPqnw= X-Received: by 2002:a2e:889a:: with SMTP id k26mr15716886lji.438.1620557385112; Sun, 09 May 2021 03:49:45 -0700 (PDT) MIME-Version: 1.0 References: <20210508142000.85116-1-kettenis@openbsd.org> <20210508142000.85116-2-kettenis@openbsd.org> In-Reply-To: From: Linus Walleij Date: Sun, 9 May 2021 12:49:33 +0200 Message-ID: Subject: Re: [PATCH 1/2] dt-bindings: pinctrl: Add DT bindings for apple, pinctrl To: Mark Kettenis Cc: kettenis@openbsd.org, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Hector Martin , Rob Herring , Linux ARM , "open list:GPIO SUBSYSTEM" , linux-kernel X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210509_034948_291148_676D2423 X-CRM114-Status: GOOD ( 24.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Mark, I think we settle with this scheme you choose, so the following is just some hints for the future. On Sun, May 9, 2021 at 11:46 AM Mark Kettenis wrote: > Right. So far it seems we don't need to set the electrical config on > any of the pins and I don't think we've identified any bits in the > register that change the electrical configuration. Although there are > some hints in the Apple device tree that there are pins that need some > additional configuration. But I also see some evidence that the Apple > firmware on these devices already sets up most of the pins for us. This is something I think you want to look closer at soon. It will *probably* be necessary to obtain optimal power management for the devices, but I am not sure. What operating systems (especially Android devices under Linux) tend to do is to reconfigure pins at runtime in order to conserve power. When the device goes to deep sleep just waiting for an external interrupt (such as opening the lid on a laptop or pressing the power button on a phone) the OS tend to reconfigure the pins into a low power state for the duration of the sleep. A typical example is to set a bunch of lines as "floating" (tristate) in pin control terminology "bias-high-impedance". In some cases pins may be connected to ground depending on use case, but in each case this is done to avoid leak currents when sleeping. I don't know how noticeable impact this will have on standby times, but the lower micron silicon technology, the bigger the impact. If possible I'd recommend that you try to intercept what MacOS is doing with these registers when the system goes in/out of sleep mode. I think it could be key to some power savings you would otherwise miss. These two modes are standardized in pin control terms as "default" and "sleep" and each affected device driver need to actively put the pin control state to "sleep" when the device is going to sleep, so the philosophy is entirely distributed, in difference from some more sledgehammer-type OS approaches where the OS is just slamming a number of values into the pin registers at sleep (suspend) time. The upside to doing this fine-grained and per device is that the sleep modes can in best case be used at runtime to e.g. save power on an unused USB port that isn't plugged to anything (I don't know if this is a good example). In Linux we have the runtime PM concept to deal with this and there are some drivers actively saving power in this way. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel