Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp623063pxb; Thu, 19 Nov 2020 09:33:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJzRQco59Qglx966P5bVdmG1J9DJFqf9kPzdakHi1nSBkA9ziEhtKIi7+BJ0Iz1F5rS9MXcx X-Received: by 2002:a05:6402:14cf:: with SMTP id f15mr31119039edx.18.1605807223093; Thu, 19 Nov 2020 09:33:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605807223; cv=none; d=google.com; s=arc-20160816; b=k5+mWSAhQVMdBqXsDUl8g44N/RQB4C9qU4yZTW6SySRgmox+NasP10cXN/kAjg+7mK YXFFkFFIdB+Lr35XYPCc+eS+psbxVjYbEBcCCIX73Jz2qcVOSpZhf0ZOOPV8CeLgUteI owlT5gfRQkn9uKGH9KUhO+JePFLgKROU8CUCPwaJTn/EL9kUlAigRSbjn8LVB8R5MDsh Jx5JGq9V3z+QX2DATSrWYSEAFxD4mPqdSAaTm3DOa4jL3//a8VFWkBCxwTweA1mGfb1F 63P493M3QclVfA0JzF6SJgQYETfHr0NqU8akOcJ3bPyjOlERVmU0Y9geQAm9Pk/JC9Vi drNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=efTE6Si5xSk9WNqWHuHnl+9mK7jZzt5RKrBEPd3Xe+A=; b=gOIaQqzlq/zBuFrAKRUAwlNd7WBsVWbeeUivuJWkioCJTn9DJIR/xBLitJIuGmt08r AGZzzVsSeAMRM3xHEi+kysOGqtOai5rmmZTfX423Yn1+TOkjTrInNCXcAeSgybidjCFu o1i53ZgB5djOQ+WcwFhlbhm+2FUO8StHmTA2RcNIhiGvYOUUO40Op3czIKmLI35juF5W A1mWy4jeOwjsOkFEoYtIEqPzPNyuAHgwu3xCfo7YaGtiKplCkrNa9ZLKOKoDCzxpDIM4 tTcv7VHdhn/ELoQ1o3Dbh0alvN29er3Udr/nzpEckJMTs9LXJFr2PeYWwAbpIZNsGWjS KMdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="WJwO+/QU"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d7si227470ejk.78.2020.11.19.09.33.19; Thu, 19 Nov 2020 09:33:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="WJwO+/QU"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728544AbgKSR3i (ORCPT + 99 others); Thu, 19 Nov 2020 12:29:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727312AbgKSR3i (ORCPT ); Thu, 19 Nov 2020 12:29:38 -0500 Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2AECC0613CF; Thu, 19 Nov 2020 09:29:37 -0800 (PST) Received: by mail-pg1-x541.google.com with SMTP id 81so4857464pgf.0; Thu, 19 Nov 2020 09:29:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=efTE6Si5xSk9WNqWHuHnl+9mK7jZzt5RKrBEPd3Xe+A=; b=WJwO+/QUiAjERoyPRXj7+iobrVKddq/6qTJ1rgHR9n5uq/izOT9mlyLUB3kdPSAo1b I/PrPL8Am7kmJafyeZR8HvJLzzJdVwjXp4u9f/MeRLk9q9J+k86KjiGIxj0ynONz1x6n EmK3G9rbOoxPZN0YiZrS+opf5UBafe8v4wk7LJnSoPe4YPooEsPkA3Xp4PxsYZXNyYPp yPNgbPU6/+pXMsr+i63OFpsjC8gNL/2YOuCAvUaONR0VvNQPRdaMfiu7Dx5Sd1l14MOE vvCToiWqvUST3gNk6PeXFMsJOkzIc08gWoICQDT6WS+SaT1HO2TeMHQ1RJyVagmLGIe4 HFUg== 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=efTE6Si5xSk9WNqWHuHnl+9mK7jZzt5RKrBEPd3Xe+A=; b=dY1e9A3TdAaorDX+hvasxfKLWs29+WTkVX988eabP4iM/se3fW1gjAFi31HiBrT0uW qSNlZPKea93EvOoNS+PnaEcdANIZLuqEIBksVILdSy+PgKFqZPynjXcnypbZtRp6m9mX j2m2INOQRFFCgb/n51ZKqU8QLE0jwVe0vhvruXOF/jPhYuycEFdUmFOZmn4Tl/85LKGO vuwZS+tlX+KjcPyqY3OKjuFajTzRW+ECimwujFZqtFiEUdG8WDJbEiukGcpneswrg28A 0m7zIIhAk+mpMdsvdkBua9pWp71EsT9hS83dGVAOZyBos/U43QXW4HK09csnzrtgLUmk CIFw== X-Gm-Message-State: AOAM531mxAeVLBrguuFND3hPXWHGjFrthFlUgU1B/AKxLN4p01UKpB1p FRJzUf6FPWwSAmhUyB3aEKht9d6IJEE/86XS2hk= X-Received: by 2002:a17:90a:d249:: with SMTP id o9mr5793491pjw.158.1605806977200; Thu, 19 Nov 2020 09:29:37 -0800 (PST) MIME-Version: 1.0 References: <20201118174417.278011-1-clemens.gruber@pqgruber.com> <20201119100005.GA703@workstation.tuxnet> <20201119160013.GA217674@workstation.tuxnet> In-Reply-To: <20201119160013.GA217674@workstation.tuxnet> From: Sven Van Asbroeck Date: Thu, 19 Nov 2020 12:29:26 -0500 Message-ID: Subject: Re: [PATCH 1/3] pwm: pca9685: Switch to atomic API To: Clemens Gruber Cc: linux-pwm@vger.kernel.org, Thierry Reding , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Lee Jones , Linux Kernel Mailing List , Mika Westerberg , David Jander Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 19, 2020 at 11:00 AM Clemens Gruber wrote: > > One thing I noticed: The driver currently assumes that it comes out of > POR in "active" state (comment at end of probe and PM calls). > However, the SLEEP bit is set by default / after POR. Very good point, the comment is probably not correct. It would be wrong to assume that the chip is in any particular state when probe() runs. There is no reset pin, so the CPU running Linux could have reset while manipulating the chip, there could even be leftover state from a bootloader talking to the chip, etc... I remember running into this myself at the time. However, we want to make sure that the runtime pm puts the chip to sleep, no matter its initial state. So the current code is correct, but the comment can be changed to: /* * Chip activity state unknown. Tell the runtime pm that the chip is * active, so pm_runtime_enable() will force it into suspend. * Which is what we want as all outputs are disabled at this point. */ > 2) If !CONFIG_PM: Clear the SLEEP bit in .probe Is anyone likely to use this driver without CONFIG_PM? My kernel won't even build without it... If you personally have no use for it, then I would not bother with the !CONFIG_PM case. Just formalize in Kconfig that the driver needs PM. I think we can add "depends on PM" or "select PM", I am not sure which one to use here. Sven