Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1851624pxb; Sat, 23 Jan 2021 07:39:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJzxgXM/EeI1su6kEu0MvYXCCnEoa/qs/5AseQXZjxvRnaCqoYyP4oKjKekH5c0jKmo12TmR X-Received: by 2002:aa7:d610:: with SMTP id c16mr138986edr.354.1611416367837; Sat, 23 Jan 2021 07:39:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611416367; cv=none; d=google.com; s=arc-20160816; b=M3Gd58f0rrC3xqxVbzjo8esEuJwEhSmwFhz/n6xSeIvG9LzCBbmPfJhQ5rlibowzo0 NbF2wkLbmDVmclHhCHb2AM+xZzaQk1ADyGS7gbuBMAfzQRhyw+AD+3tDrM8RkLygWcwi mT+y3exp/jKrqzN5IQzXHgu48NZusqlhPduLPHL6a6FlbZCmxb5/ZWjKPpGLBT3JddAF D03E6rMpCHNJ9nyAR+FJfwuAe3E0oU+SsDOeM/Fu5paxmpIH39gqNx2q9hpQiyCBF84j QOBEhZjMfHNaCoklizeHQY9m0/NEuX8AZCUp7hq0Nv5M9mIH3QLhSagBtODAjMy5iJrj OIkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=9kAHCvh6BRDaIeVRvKIpLDQP47Hcm1FpEgxVNC88+Fo=; b=BTk6dWXAIxdpqJAC7wwAXrAc5cozNj2KHmDHWcFVhEpNxwbkJRHng2cxvwpmZe3gzf f7Rk8mSXzS5422fgPefYC+BNCLQc8m8Gz/sPbjLFkoLR7PLBbYfmFY/Dx82kmUWrXYCr EW3YAINFyEQ3fcg9NPAoHkOY3DUQGYuea/8JQe7XMgrzSCXhx3gnHMsoDm4KFhtIC01k SDYS1EUv4va3P5qzMwsRB7elWyYrKg4ddbXq8brglN9G+2/g+GZtQ7jYqVzwEHlPlLW+ u+aVZMMegspRrZM5eDxMNOrOYQQ/1nbPXm71olC3PW06putnPfTaZEaM0L58sZZVv6zR Bkig== ARC-Authentication-Results: i=1; mx.google.com; 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=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c2si5051989edw.234.2021.01.23.07.38.59; Sat, 23 Jan 2021 07:39:27 -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; 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=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725922AbhAWPf5 (ORCPT + 99 others); Sat, 23 Jan 2021 10:35:57 -0500 Received: from mail.kernel.org ([198.145.29.99]:45878 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725778AbhAWPf5 (ORCPT ); Sat, 23 Jan 2021 10:35:57 -0500 Received: from archlinux (cpc108967-cmbg20-2-0-cust86.5-4.cable.virginm.net [81.101.6.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2C5EF23331; Sat, 23 Jan 2021 15:35:15 +0000 (UTC) Date: Sat, 23 Jan 2021 15:35:11 +0000 From: Jonathan Cameron To: Linus Walleij Cc: Mike Looijmans , linux-iio , Dan Robertson , =?UTF-8?B?R2HDq3RhbiBBbmRyw6k=?= , Jonathan Bakker , Lars-Peter Clausen , Peter Meerwald-Stadler , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v6 2/2] iio: accel: Add support for the Bosch-Sensortec BMI088 Message-ID: <20210123153511.1802a15a@archlinux> In-Reply-To: References: <20210119124622.9490-1-mike.looijmans@topic.nl> <20210119124622.9490-2-mike.looijmans@topic.nl> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 22 Jan 2021 23:38:48 +0100 Linus Walleij wrote: > Hi Mike, > > thanks for your patch! > > I have a comment about PM: > > On Tue, Jan 19, 2021 at 1:46 PM Mike Looijmans wrote: > > > The BMI088 is a combined module with both accelerometer and gyroscope. > > This adds the accelerometer driver support for the SPI interface. > > The gyroscope part is already supported by the BMG160 driver. > > > > Signed-off-by: Mike Looijmans > (...) > > > +static int bmi088_accel_set_power_state_on(struct bmi088_accel_data *data) > > +{ > > + struct device *dev = regmap_get_device(data->regmap); > > + int ret; > > + > > + ret = pm_runtime_get_sync(dev); > > + if (ret < 0) { > > + pm_runtime_put_noidle(dev); > > + return ret; > > + } > > + > > + return 0; > > +} > > + > > +static int bmi088_accel_set_power_state_off(struct bmi088_accel_data *data) > > +{ > > + struct device *dev = regmap_get_device(data->regmap); > > + int ret; > > + > > + pm_runtime_mark_last_busy(dev); > > + ret = pm_runtime_put_autosuspend(dev); > > + > > + return ret < 0 ? ret : 0; > > +} > > I'm not sure you should wrap the pm_runtime calls like this. > I think it is better to inline them. > > Next, I think it is better to let suspend/resume, i.e. system PM > reuse runtime PM since you're implementing that. This is why > we invented PM runtime force resume and force suspend. Here the driver is turning more off for full suspend than in the runtime path. If that results in significant extra delay then it's not appropriate to have that in the runtime suspend path. Maybe the simplification of not doing the deeper power saving mode is worth the extra power cost or extra delay, but I'm not yet convinced. I'll hold off on applying v7 though whilst we discuss this. J > > Here are some drivers that I implemented using that model: > drivers/iio/gyro/mpu3050-core.c > drivers/iio/accel/kxsd9.c > drivers/iio/magnetometer/ak8974.c > > The short summary is: > - Only implement runtime suspend/resume. > - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, > pm_runtime_force_resume) > - In probe() enable runtime PM with autosuspend: > pm_runtime_get_noresume(dev); > pm_runtime_set_active(dev); > pm_runtime_enable(dev); > pm_runtime_set_autosuspend_delay(dev, NNNN); > pm_runtime_use_autosuspend(dev); > pm_runtime_put(dev); > - In remove() disable it like this: > pm_runtime_get_sync(dev); > pm_runtime_put_noidle(dev); > pm_runtime_disable(dev); > - Any time the driver needs the hardware, call: > pm_runtime_get_sync(dev); > - As soon as you're done using the hardware call: > pm_runtime_mark_last_busy(dev); > pm_runtime_put_autosuspend(dev); > > The system PM will just hook into the same callbacks and suspend > the hardware using the existing runtime PM hooks. > > This works fine in my drivers and saves some complexity and avoids > bugs. > > Yours, > Linus Walleij