Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp227099iob; Mon, 2 May 2022 17:49:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzIbyaL1n+Dk22IaIEu5lVaDLsmFz+uaSG9KPD6O/rMwQcYZerVsTEU1wBXZ67qteSOdwkN X-Received: by 2002:a05:6a00:1695:b0:4f7:decc:506b with SMTP id k21-20020a056a00169500b004f7decc506bmr13716751pfc.7.1651538978774; Mon, 02 May 2022 17:49:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651538978; cv=none; d=google.com; s=arc-20160816; b=qVIH87lT7LSB6w1bmw99ccbt2loMIJqixmQ2NcddFpU8JBO5XlfenIruflNFe/ertr lnUMxiqogkgydO8yrFamwqbbfXsDMTjfz9vz0glP5BGcf+ksJA6THHy0LpnOgfdpp6Rr tJRVf0lTYKbNBNxG3QABg6GXabKWAu/uDke+BVmwFyKybWyeopZqGcLftfBsxkEoU/L6 dnOHKocoRlexhG4104lD+d9NS+omHjEmWk+AOKGCxH2lZ7t1/GU1ttVgOTTJJ4GUSqwG F5BAHO+IiNCZ/5rsfcRvvsWjXCymrVg4rp7qikGxV68ONHZQHvMuO0/Rw0EA/42ehZ6K kJAg== 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 :dkim-signature; bh=/oO0BlIpHXm0dMhVGhPajqjjptNphal7ygiHqmYMAz4=; b=vig/xigXWFIKtZ+cs+vgtnMoRVc0uAoKUJfEOIspVM4tan6OIkMunNWCdh+9/DKGBL 6yZlMrW6a+kpMZShsWrU+SKUKSxOwmNAIqs7RPr27mbf8xSJGA1RjBgNyhRtktIzHW8k hHvphiFTT8UjEoQYdtiS2kwXnoN7aSEBgKiKzhoP069BgNYuAMyF7k9tbpr1szcKEtWG wr0CjHBK7VC7rbHiZ9CjVYnXh8h1bMg741WCFSjrVvBD+3vQleNOf2LPgaMgZ1HroXO0 yZD8mhQbww0FnbaPlC63xGl+E8L0jLqOvvtKVT0ibLGuypl3m10izVUfaetehCV6pn2f QZgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=rSqMEvHk; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id lr12-20020a17090b4b8c00b001cb5ca6d2d2si831431pjb.165.2022.05.02.17.49.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 17:49:38 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=rSqMEvHk; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id BA20E4D9F7; Mon, 2 May 2022 17:37:50 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348887AbiEAQPx (ORCPT + 99 others); Sun, 1 May 2022 12:15:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48530 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237946AbiEAQPt (ORCPT ); Sun, 1 May 2022 12:15:49 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69B43DFEA; Sun, 1 May 2022 09:12:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 21E9BB80E5A; Sun, 1 May 2022 16:12:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 758C0C385AA; Sun, 1 May 2022 16:12:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651421540; bh=+JCdHDwwPGGZ+rAC+3PkQyPI2jD46/M4umIy3xmT3B8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=rSqMEvHkYyQwoShxYhQuXUuPAoEg0dhDviXIPkhPjOAG6JnHhdsjJrMsBmtcowfjn MsBNzCE684Csvxjd9N5JNnVXkFJ+ILsslyv9KZn8JjVQjDuupYgQxDTRSiuJkNJfbK aQB4EzM/Obw6ebxLKVH65iMCcJKcgAsDRVlgN50vb8WRY6oiMOJooT1K1S60rtCKyN NzRLDOLRn/gQtpwrIELuFBAepdRN9MRoRkufY6iIIBQ/4EluuH2jlS7thUWv9I7su2 gYE/kLtX4khiV4RoUYDxA9wEQWoZtidj5eZesgo2TOvjOGg6ytJl3Lvu3vH4mz0vtg o3BzemKWEexdA== Date: Sun, 1 May 2022 17:20:37 +0100 From: Jonathan Cameron To: Andy Shevchenko Cc: Jagath Jog J , Dan Robertson , linux-iio , Linux Kernel Mailing List Subject: Re: [PATCH v4 4/9] iio: accel: bma400: Add triggered buffer support Message-ID: <20220501172037.5f3d446f@jic23-huawei> In-Reply-To: References: <20220420211105.14654-1-jagathjog1996@gmail.com> <20220420211105.14654-5-jagathjog1996@gmail.com> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 27 Apr 2022 14:34:57 +0200 Andy Shevchenko wrote: > On Wed, Apr 20, 2022 at 11:11 PM Jagath Jog J wrote: > > > > Added trigger buffer support to read continuous acceleration > > data from device with data ready interrupt which is mapped > > to INT1 pin. > > LGTM, > Reviewed-by: Andy Shevchenko Agreed. A couple of 'comments' inline but no actual need to change anything. One is contingent on a fix I've not sent out yet for the rest of IIO. The other is potentially a minor improvement for the future. Thanks, Jonathan > > > Signed-off-by: Jagath Jog J > > --- > > drivers/iio/accel/Kconfig | 2 + > > drivers/iio/accel/bma400.h | 10 +- > > drivers/iio/accel/bma400_core.c | 162 +++++++++++++++++++++++++++++++- > > drivers/iio/accel/bma400_i2c.c | 2 +- > > drivers/iio/accel/bma400_spi.c | 2 +- > > 5 files changed, 170 insertions(+), 8 deletions(-) > > > > #include "bma400.h" > > > > @@ -61,6 +66,14 @@ struct bma400_data { > > struct bma400_sample_freq sample_freq; > > int oversampling_ratio; > > int scale; > > + struct iio_trigger *trig; > > + /* Correct time stamp alignment */ > > + struct { > > + __le16 buff[3]; > > + u8 temperature; > > + s64 ts __aligned(8); > > + } buffer ____cacheline_aligned; If you are rolling again, could you change this to __aligned(IIO_ALIGN); See https://lore.kernel.org/linux-iio/20220419121241.00002e42@Huawei.com/ for why. Note that I'll be sending a fix patch out for IIO_ALIGN to define it as ARCH_KMALLOC_ALIGN in next few days. If you'd pref not to get caught up in that, send it as it stands and I'll fix up once that fix is in place. What's one more driver on top of the 80+ I have to do anyway :) > > + __le16 status; > > }; > > > > + > > +static const unsigned long bma400_avail_scan_masks[] = { > > + GENMASK(3, 0), > > + 0 > > +}; > > + > > static const struct iio_info bma400_info = { > > .read_raw = bma400_read_raw, > > .read_avail = bma400_read_avail, > > @@ -814,7 +869,72 @@ static const struct iio_info bma400_info = { > > .write_raw_get_fmt = bma400_write_raw_get_fmt, > > }; > > > > -int bma400_probe(struct device *dev, struct regmap *regmap, const char *name) > > +static const struct iio_trigger_ops bma400_trigger_ops = { > > + .set_trigger_state = &bma400_data_rdy_trigger_set_state, > > + .validate_device = &iio_trigger_validate_own_device, > > +}; > > + > > +static irqreturn_t bma400_trigger_handler(int irq, void *p) > > +{ > > + struct iio_poll_func *pf = p; > > + struct iio_dev *indio_dev = pf->indio_dev; > > + struct bma400_data *data = iio_priv(indio_dev); > > + int ret, temp; > > + > > + /* Lock to protect the data->buffer */ > > + mutex_lock(&data->mutex); > > + > > + /* bulk read six registers, with the base being the LSB register */ > > + ret = regmap_bulk_read(data->regmap, BMA400_X_AXIS_LSB_REG, > > + &data->buffer.buff, sizeof(data->buffer.buff)); > > + if (ret) > > + goto unlock_err; > > + > > + ret = regmap_read(data->regmap, BMA400_TEMP_DATA_REG, &temp); Given the temperature read is a separate action, it seems like you could sensible add another entry to bma400_avail_scan_masks() for just the accelerometer axis and then only perform this read if the temperature is requested. It would be a feature though, so no need to have it in this patch if you prefer not to. > > + if (ret) > > + goto unlock_err; > > + > > + data->buffer.temperature = temp; > > + > > + iio_push_to_buffers_with_timestamp(indio_dev, &data->buffer, > > + iio_get_time_ns(indio_dev)); > > + > > + mutex_unlock(&data->mutex); > > + iio_trigger_notify_done(indio_dev->trig); > > + return IRQ_HANDLED; > > + > > +unlock_err: > > + mutex_unlock(&data->mutex); > > + return IRQ_NONE; > > +}