Hi Mehdi,
On 12/22/22 16:06, Mehdi Djait wrote:
Hello Matti,
First of all I apologize for bothering you out of the blue and I hope it
is not a bad time to send you an email with a couple of questions.
No problem. But I suggest you CC the IIO mail list when sending this
kind of questions. It may be the messages where the list is not in CC
are regarded as spam by my mail filters... Besides, others with more
insight to IIO may be able to further help you when the list is CC'd ;)
My name is Mehdi Djait, I am a student living in Germany currently,
REALLY interested in linux kernel development and still trying to find
something to contribute to the kernel. The IIO subsystem seems like a
good place to start for a kernel Newbie and am currently investing my
time in learning the subsystem (reading driver implementations, the
IIO-core, lurking in the mailing list ...) I have been looking lately
everywhere for sensors without a kernel driver and I stumbled upon the
KX132/134-1211 accelerometers and that's why I decided to send you an
email with these questions:
Oh, thanks for contacting me :) So, you have the sensor hardware at your
hands? I think this is mandatory when writing a driver.
- Am I correct in assuming that the accelerometer does not have a kernel
driver ? I looked in the RohmSemiconductor Linux-Kernel-Input-Drivers
and Linux-Kernel-Sensor-Drivers GitHub repos and grepped inside the iio,
staging and linux-next trees
Yes and no :) There is a kernel driver which supports many of the kx*
accelerometers in the ROHM downstream Linux-Kernel-Input-Drivers, and I
believe it also supports the KX132/KX134. Yet, as the name suggests -
these drivers are not exposing the accelerometer using IIO but the INPUT
subsystem. Reason is that quite a few device manufacturers still use the
accelerometers via HAL written on top of the INPUT. Heikki Haikola (in
CC) has authored many of these drivers. The INPUT is not the preferred
subsystem for acceleromerers though - so you're correct when planning to
write an IIO driver for upstream.
- Is anyone working on a driver now ? If not, I am really interested in
trying to write one for some basic functionality. I am fully __AWARE__
how difficult the task is (I did read your LinkedIn posts) but I am
truly motivated and I will use every example I can find as reference:
the drivers under iio/accel, the GitHub repos from RohmSemiconductor and
your KX02AA driver that recently landed in linux-next (Congrats :) )
Upstream support for (ROHM or any other) ICs is very welcome. It enables
more and more people to benefit from the ICs. Companies can rarely
support small customers and open source drivers make it possible for the
people to work without this support :) This work has been on my TODO
list since I added KX022A driver - but it has had low priority and I
seem to always have some other tasks. So, Your work on these ICs is more
than welcome!
I’m eager to receive your feedback! (and sorry for the long text)
It was not too long :)
If you wish to proceed with the driver, then I would have couple of
suggestions to you. As far as I remember the KX132 is not really _that_
different from the KX022A. Sure the resolution is different as may be
the G-ranges. But the logic of the register interface is largely same. I
suggest you to study the possibility of extending the KX022A driver to
support the other variants. I would differentiate the IC types based on
device-tree and fill in the register offsets/required quirks in the
driver private data.
The other suggestion from me is that you could check the IC's logic from
the Linux-Kernel-Input-Drivers. I think there were some minor
differencies in the behaviour for example when the BUFE or PC1 bits are
toggled.
Feel free to ask us if you hit to problems with the work, but please
note that most of us in Finland are having a holiday season right now -
so many of us will be offline until January.
Yours,
-- Matti
Kind regards
Mehdi Djait
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
