Received: by 2002:a05:7412:8d11:b0:fa:4934:9f with SMTP id bj17csp82526rdb; Sun, 14 Jan 2024 07:28:14 -0800 (PST) X-Google-Smtp-Source: AGHT+IFuHP4BcjyMgEjuicikZkP+7DUGh8UxTRfJfWamEXUPe9FNrF/e5E9CezVRty66WXJeg2D7 X-Received: by 2002:a05:6e02:e0e:b0:35f:ccab:360e with SMTP id a14-20020a056e020e0e00b0035fccab360emr5079544ilk.1.1705246094714; Sun, 14 Jan 2024 07:28:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705246094; cv=none; d=google.com; s=arc-20160816; b=lYjXjPMAgGGz5Bqe3Yhtn3tunRFvo+qL73d5/Xsue3hKiNAVGGnbJiET0yCeM9xnXm EZ3AslSJPztzEMbaBUuHpUlLTxwN2LovppuivuDnp8DPyTii+Tgtb997Ur98nDzzBsb8 Je8u45TB8p+/+TxJwDecU7bhyAVTKVtTUKKgIa+MjIaWqpW5ggEP0/Ggt4ksbATNn4g5 Oz9RsKz7aabR4B+FyPJ1PPPzcNoNyjW5RpvokX9N5r/a7+9qffnfGkLFA0L4+qjXswUY IfWo5b527sGOScyvO8qHQr+BG0NpTXPW0A8+IOTJvbdQv1JO8QAgC0YzXAquayX7m0RK uyow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=PP5MfKK4QzmjHSi+1yNmqvv9KSb6RKj3SG4nFRvgbuM=; fh=cdMMJC0yNmwhAhoZ3FXytsMfniIw31833MaQrvMNzcs=; b=Aa/mzSk4DMffSgAYbdtneDcK7ZamDM5e7lOGUL6nq9pf835zg6TEcVIXdlgiffR5ta afZjbjdtzbLYbDPrljT5afvZpVsoxUUJyMM+L+4OX0urPho2z8c/3G0Ejoj09CwYjijm Q5EIw0sSWVLQEsBwThjzUm+rGdk1oUKfXnxsJZpXrR7tbWhbXCPJOBn3fV/ykVImH6MX 11aCQBSfR0DHgsaBdaCmNewj97KTgCu16Kn5gi3tHful3uWAiF2FAtg9w1eJ1ML8l2ES WV8n9ThE423SqAigUrBJ6MvDCMeUrcGdGFUMg7zUBR85ThR+xOAdoV6JhOVHtXaohhsQ yXdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=H+NeV4Mb; spf=pass (google.com: domain of linux-kernel+bounces-25500-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25500-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id ds1-20020a17090b08c100b0028bc0991858si9605343pjb.165.2024.01.14.07.28.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jan 2024 07:28:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-25500-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=H+NeV4Mb; spf=pass (google.com: domain of linux-kernel+bounces-25500-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25500-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 5876A282216 for ; Sun, 14 Jan 2024 15:28:14 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id F404B290B; Sun, 14 Jan 2024 15:28:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="H+NeV4Mb" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D97F23CA; Sun, 14 Jan 2024 15:28:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF684C433C7; Sun, 14 Jan 2024 15:28:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705246085; bh=XqE4zwcpZP6BKmHgnhqMegwV+ZjrEakoNJeSEJ8lkmE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=H+NeV4MbLBHlJrpvQQZIIilEiBFq9JV4Wu5i8d+EdnOp26YkAsBN5g3rLyAlq03Fe RTfyvyxn7VNjR9+aBvK5TS9GZF56w6MTNmTaA7vsREt/8PmlE7mHrLLQ6ud9sGc8lj UEa8hHngUDPPvRfRZNpYXbdCGo+w5O3LxQYbDO7QnXudnZv4F4woYiKkL6lJDEjioZ i8Ug9gaLtxdbvQaQwcDJ6TmWTAM0Ho8pnV1rFiRzbT+VzZl/SYS3tVsmocVljd5lUR jdmh38U9zsAyODkhwhoOPfJgwxydIpxubp38WwEKev+lVUhNvIBPmr0IxQngqMOjkF MerWYTN9eS3Tg== Date: Sun, 14 Jan 2024 15:27:34 +0000 From: Jonathan Cameron To: Petre Rodan Cc: Jonathan Cameron , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, Lars-Peter Clausen , Mark Brown Subject: Re: [PATCH 6/6] iio: pressure: hsc030pa add sleep mode Message-ID: <20240114152734.0ecdd090@jic23-huawei> In-Reply-To: References: <20240110172306.31273-1-petre.rodan@subdimension.ro> <20240110172306.31273-7-petre.rodan@subdimension.ro> <20240112171356.00003e88@Huawei.com> X-Mailer: Claws Mail 4.2.0 (GTK 3.24.39; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 14 Jan 2024 07:17:47 +0200 Petre Rodan wrote: > Hi Jonathan, >=20 > On Fri, Jan 12, 2024 at 05:13:56PM +0000, Jonathan Cameron wrote: > > On Wed, 10 Jan 2024 19:22:41 +0200 > > Petre Rodan wrote: > > =20 > > > Some custom chips from this series require a wakeup sequence before t= he > > > measurement cycle is started. > > > =20 > [..] > > > + if (data->capabilities & HSC_CAP_SLEEP) { > > > + /* > > > + * Send the Full Measurement Request (FMR) command on the CS > > > + * line in order to wake up the sensor as per > > > + * "Sleep Mode for Use with Honeywell Digital Pressure Sensors" > > > + * technical note (consult the datasheet link in the header). > > > + * > > > + * These specifications require a dummy packet comprised only by > > > + * a single byte that contains the 7bit slave address and the > > > + * READ bit followed by a STOP. > > > + * Because the i2c API does not allow packets without a payload, > > > + * the driver sends two bytes in this implementation. > > > + */ > > > + ret =3D i2c_master_recv(client, &buf, 1); > > > + if (ret < 0) > > > + return ret; > > > + } > > > + =20 > [..] > > > diff --git a/drivers/iio/pressure/hsc030pa_spi.c b/drivers/iio/pressu= re/hsc030pa_spi.c > > > index 737197eddff0..1c139cdfe856 100644 > > > --- a/drivers/iio/pressure/hsc030pa_spi.c > > > +++ b/drivers/iio/pressure/hsc030pa_spi.c > > > @@ -25,12 +25,40 @@ static int hsc_spi_recv(struct hsc_data *data) > > > struct spi_device *spi =3D to_spi_device(data->dev); > > > struct spi_transfer xfer =3D { > > > .tx_buf =3D NULL, > > > - .rx_buf =3D data->buffer, > > > - .len =3D HSC_REG_MEASUREMENT_RD_SIZE, > > > + .rx_buf =3D NULL, > > > + .len =3D 0, > > > }; > > > + u16 orig_cs_setup_value; > > > + u8 orig_cs_setup_unit; > > > + > > > + if (data->capabilities & HSC_CAP_SLEEP) { > > > + /* > > > + * Send the Full Measurement Request (FMR) command on the CS > > > + * line in order to wake up the sensor as per > > > + * "Sleep Mode for Use with Honeywell Digital Pressure Sensors" > > > + * technical note (consult the datasheet link in the header). > > > + * > > > + * These specifications require the CS line to be held asserted > > > + * for at least 8=C2=B5s without any payload being generated. > > > + */ > > > + orig_cs_setup_value =3D spi->cs_setup.value; > > > + orig_cs_setup_unit =3D spi->cs_setup.unit; > > > + spi->cs_setup.value =3D 8; > > > + spi->cs_setup.unit =3D SPI_DELAY_UNIT_USECS; > > > + /* > > > + * Send a dummy 0-size packet so that CS gets toggled. > > > + * Trying to manually call spi->controller->set_cs() instead > > > + * does not work as expected during the second call. > > > + */ =20 > > > > Do you have a reference that says the CS must be toggled on 0 length tr= ansfer? > > If that's not specified in the SPI core somewhere then you will need to= send > > something... > > =20 > > > + spi_sync_transfer(spi, &xfer, 1); > > > + spi->cs_setup.value =3D orig_cs_setup_value; > > > + spi->cs_setup.unit =3D orig_cs_setup_unit; > > > + } =20 >=20 > first of all thank you for the review. >=20 > I was afraid that this block will not be taken too well since I'm trying = to > achieve something that the SPI subsystem was not designed for. >=20 > the code does exactly what the datasheet specs require on my SPI controll= er, but > indeed the API might change at some point making the code non-functional. >=20 > by 'sending something' you mean on the SPI bus or are you pushing me towa= rd a > patch to SPI core? Should have said receive 'something' - that means that we'd clock some data whether or not the device had any to provide. >=20 > unfortunately this chip feature is a special request only, there is no wa= y for > me to test what happens if the wakeup sequence also contains a payload (i= n both > i2c and spi cases). the i2c wakeup code was inspired from the abp060mg dr= iver, > but I can't reach its maintainer to ask for details. I also can't seem to= reach > Honeywell. oh well. >=20 +CC Mark. Discussion is about whether a zero length SPI transfer is guaran= teed to pulse the chip select. If this is something we need, I'd prefer to see it as something a given SPI controller would opt in to supporting or some other way of knowing it would actually happen such as some docs that say it will work for an SPI controll= er (which I doubt is the case) Jonathan > best regards, > peter >=20