Dear David, Thanks for reviewing! On Fri, 28 Feb 2025 16:36:31 -0600 David Lechner <dlechner@xxxxxxxxxxxx> wrote: > On 2/27/25 10:28 AM, David Jander wrote: > > Request for comments on: adding the Linux Motion Control subsystem to the > > kernel. > > > > The Linux Motion Control subsystem (LMC) is a new kernel subsystem and > > associated device drivers for hardware devices that control mechanical > > motion. Most often these are different types of motors, but can also be > > linear actuators for example. > > This is something that I played around with when I first got into Linux > kernel hacking as a hobbyist. It's something I've always wanted to see get > upstreamed, so feel free to cc me on any future revisions of this series. > I'm very interested. :-) Cool! Will keep you posted. > We made drivers for basic DC motors driven by an H-bridge both with and without > position feedback and also a driver for hobby-type servo motors. For those > interested, there is code [1] and docs [2]. One thing we would do different > if doing it over again is use a character device instead of sysfs attributes > as the interface for starting/stopping/adjusting actuation. > > [1]: https://github.com/ev3dev/lego-linux-drivers/tree/ev3dev-stretch/motors > [2]: http://docs.ev3dev.org/projects/lego-linux-drivers/en/ev3dev-stretch/motors.html > > > > > This subsystem defines a new UAPI for motion devices on the user-space > > side, as well as common functionality for hardware device drivers on the > > driver side. > > > > The UAPI is based on a ioctl() interface on character devices representing > > a specific hardware device. The hardware device can control one or more > > actuators (motors), which are identified as channels in the UAPI. It is > > possible to execute motions on individual channels, or combined > > affecting several selected (or all) channels simutaneously. Examples of > > coordinated movements of several channels could be the individual axes > > of a 3D printer or CNC machine for example. > > > > On the hardware side, this initial set of patches also includes two drivers > > for two different kinds of motors. One is a stepper motor controller > > device that containes a ramp generator capable of autonomously executing > > controlled motions following a multi-point acceleration profile > > (TMC5240), as well as a simple DC motor controller driver that can control > > DC motors via a half-bridge or full H-bridge driver such as the TI DRV8873 > > for example. > > > > Towards the IIO subsystem, LMC supports generating iio trigger events that > > fire at certain motion events, such as passing a pre-programmed position or > > when reaching the motion target position, depending on the capabilities of > > the hardware device. This enables for example triggering an ADC measurement > > at a certain position during a movement. > > I would expect to be using the counter subsystem for position, at least in > cases where there is something like a quadrature encoder involved. I will have to think about it. Since there are some Linux capable SoC's that have counter inputs able to do quadrature decoding, it might make sense to support that. For now, the TMC5240 controller for example has support for encoders and while in this patch-set support for it is minimal, the idea was that a motion controller that supports an encoder would just offer the option to use the encoder as the authoritative source for position information. So let's say you have a DC motor for example. Without an encoder or any other means for of speed/position feedback, the best one can do is establish a 1:1 relationship between duty-cycle and speed, obviating all inaccuracies of doing so. So a motion controller using a DC motor would just do that if it has no encoder. OTOH, if there is an encoder as a source of position and speed information, the driver could work with more accurate data. It all depends, but in the end the interface towards the user is the same: move with some speed towards some position or for some amount of time. > > In the future, making use of PREEMPT_RT, even dumb STEP/DIR type stepper > > motor controller drivers may be implemented entirely in the kernel, > > depending on some characteristics of the hardware (latency jittter, > > interrupt latency and CPU speed mainly). > > > > The existence of this subsystem may affect other projects, such as > > Linux-CNC and Klipper for example. > > > > This code is already in use controlling machines with up to 16 stepper > > motors and up to 4 DC motors simutaneously. Up to this point the UAPI > > has shown to be adequate and sufficient. Careful thought has gone into > > the UAPI design to make sure it coveres as many use-cases as possible, > > while being versioned and extensible in the future, with backwards > > compatibility in mind. > > > > David Jander (7): > > drivers: Add motion control subsystem > > Would it be too broad to call this an actuation subsystem instead where motion > is just one kind of actuation? I think it is hard enough already to make a UAPI for motion that is general enough to encompass all types of different motors and motion actuators. Generalizing even further without a serious risk of shortcomings seems almost impossible, but I am open to suggestions. Best regards, -- David Jander
