In Linux, the Industrial Input/Output subsystem manages devices like Analog to Digital Converters, Light sensors, accelerometers, etc.

On the other hand, the Input subsystem handles keyboards, mice, touchscreens, and any device that has a human interface.

What happens when you have a device that is in a sense ADC, and also a touchscreen? Basically, an ADC (hence an IIO device) that can be connected to a touchscreen (hence an input device), measures the position or the point where you touch with analog-to-digital conversion. The end result, the position itself, is the kind of information that is meaningful for the kernel as user interaction and as user input.

You could think of an MFD, a multi-function device, but this is not really the case. An MFD does two distinct things, unrelated, under the same umbrella. This ADC touchscreen does just one thing, getting touch information through an ADC interface.

The GRTS (generic resistive touchscreen) driver does the bridging between an ADC touchscreen and the input subsystem. What happens is that the ADC device registers channels for the touch position (X/Y coordinates, touch pressure), which are being read by the GRTS as a consumer for the IIO, and then the GRTS registers a touchscreen in the kernel, and reports touch data further on touch events.

GRTS is not a driver for a piece of hardware, but rather a middleman in the kernel, acting as a bridge between two subsystems. In Linux, you should not have an IIO driver that acts as a touchscreen or the other way around. Imagine what would happen if a PMIC driver would start registering a video display driver. Things would easily turn into a mess!

I wrote the GRTS driver in 2018 and I am still listed as an active maintainer for it. It appears it has also been used on imx6 since its inception.