From: Vidhu Sarwal via B4 Relay <devnull+vidhu.linux.gmail.com@kernel.org>
To: "Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Vidhu Sarwal" <vidhu.linux@gmail.com>,
"Jonathan Cameron" <jic23@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org,
Shuah Khan <skhan@linuxfoundation.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Subject: [PATCH v2 0/3] iio: proximity: Add Benewake TF-Luna LiDAR driver
Date: Sat, 31 Oct 2026 00:23:27 +0530 [thread overview]
Message-ID: <20261031-tf-luna-v2-0-ce403579bb8a@gmail.com> (raw)
This series adds support for the Benewake TF-Luna, a single point ToF
LiDAR distance sensor with a range of 0.2 m to 8 m. The
sensor uses either UART or I2C, selected by a strap pin at power-up.
This series covers the I2C interface only.
Patch 1 adds the vendor prefix, patch 2 adds the binding and patch 3 adds the
driver, which reports distance using an IIO_DISTANCE channel.
The driver keeps the sensor in trigger mode and starts a measurement
per read. The manual warns that reads in continuous mode can race with
the sensor updating its result registers unless they are synchronised
to the data ready output, which the driver does not use yet.
Two issues I faced with the hardware that the manual does not mention:
- The sensor silently drops a register write that arrives right after
another one, so probe reads the mode back after setting it.
- The boot time is not documented. I was able to measure 350ms after a
reboot before the registers read back correctly, so probe waits
500 ms after enabling the supply, keeping some buffer.
Later on I plan to add buffered caputure using data ready interrupt and
runtime PM in a follow up series.
This was tested on hardware using Raspberry Pi 4 and with firmware v3.6.0
built out of tree on the 6.18 RPi kernel both via new_device as well as a
DT Overlay.
---
Changes in v2:
- dt-bindings: describe the UART interface as well per Krzysztof
(dropped Reviewed-by as binding has changed)
- Use a local regmap variable in probe and tf_luna_measure() per Joshua
and Andy
- Use msleep() instead of fsleep per Joshua and Andy
- Use FourCC for signature and print it with %p4ch per Andy
- Comment explaining why there is no regmap cache per Andy
- Use a Datasheet: tag, drop unused includes per Andy and Joshua
- Keep the channel array per Jonathan, as buffered support is planned
- Link to v1: https://patch.msgid.link/20261020-tf-luna-v1-0-53a88f93db24@gmail.com
---
Vidhu Sarwal (3):
dt-bindings: vendor-prefixes: Add Benewake
dt-bindings: iio: proximity: Add Benewake TF-Luna
iio: proximity: Add Benewake TF-Luna LiDAR driver
.../bindings/iio/proximity/benewake,tf-luna.yaml | 66 ++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 7 +
drivers/iio/proximity/Kconfig | 11 +
drivers/iio/proximity/Makefile | 1 +
drivers/iio/proximity/tf-luna.c | 260 +++++++++++++++++++++
6 files changed, 347 insertions(+)
---
base-commit: 43ffda3c7f8456bbe641ae8249a077a361b97880
change-id: 20261019-tf-luna-e2685e0570d5
Best regards,
--
Vidhu Sarwal <vidhu.linux@gmail.com>
next reply other threads:[~2026-10-30 18:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 18:53 Vidhu Sarwal via B4 Relay [this message]
2026-10-30 18:53 ` [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add Benewake Vidhu Sarwal via B4 Relay
2026-10-30 18:53 ` [PATCH v2 2/3] dt-bindings: iio: proximity: Add Benewake TF-Luna Vidhu Sarwal via B4 Relay
2026-10-30 18:53 ` [PATCH v2 3/3] iio: proximity: Add Benewake TF-Luna LiDAR driver Vidhu Sarwal via B4 Relay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261031-tf-luna-v2-0-ce403579bb8a@gmail.com \
--to=devnull+vidhu.linux.gmail.com@kernel.org \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=krzysztof.kozlowski@oss.qualcomm.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=vidhu.linux@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox