[RFC] iio: adc: support for multi-device aggregation

[Jonathan Santos <jonath4nns@gmail.com>]

Hi all,

We have a request to support multiple devices tied together in a single evaluation
board. The goal is to be able to read them simultaneously via the IIO framework,
while also controlling them individually. Currently we have two ADC devices that
would benefit from this, but there might be more in the future.

This is the scenario:

+---------------+                                                 
|     ADC 0     |                                                 
|               |                                                 
|        SYNC_IN|---+---------------------------+                 
|          DRDY0|---|------------------------+  |                 
|               |   |                        |  |   +------------+
|          SCLK0|---|------+                 |  |   |    HOST    |
|           SDI0|---|------|--+              |  |   |            |
|            CS0|---|------|--|-----------+  |  +-->|ADC_SYNC    |
|          DOUT0|---|------|--|--------+  |  |      |            |
|               |   |      |  |        |  |  |      |            |
+---------------+   |      +--|--------|--|--|----->|SCLK        |
                    |      |  +--------|--|--|----->|MOSI        |
+---------------+   |      |  |        |  |  |      |            |
|     ADC 1     |   |      |  |        |  |  |      |            |
|               |   |      |  |        |  |  +----->|DRDY0       |
|        SYNC_IN|---+      |  |        |  +-------->|CS0         |
|          DRDY1|---|------|--|----+   +----------->|MISO0       |
|               |   |      |  |    |                |            |
|          SCLK1|---|------+  |    |                |            |
|           SDI1|---|------|--+    +--------------->|DRDY1       |
|            CS1|---|------|--|-------------------->|CS1         |
|          DOUT1|---|------|--|-------------------->|MISO1       |
|               |   |      |  |                     |            |
+---------------+   |      |  |                     | .          |
                    |      |  |                     | .          |
       ...          |      |  |                     | .          |
                    |      |  |                     |            |
+---------------+   |      |  |            +------->|DRDYN       |
|     ADC N     |   |      |  |            | +----->|CSN         |
|               |   |      |  |            | | +--->|MISON       |
|        SYNC_IN|---+      |  |            | | |    |            |
|          DRDYN|----------|--|------------+ | |    +------------+
|               |          |  |              | |                  
|          SCLKN|----------+  |              | |                  
|           SDIN|-------------+              | |                  
|            CSN|----------------------------+ |                  
|          DOUTN|------------------------------+                  
|               |                                                 
+---------------+                                                                                                    

To summarize, the devices share SPI pins such as SCLK and MOSI, but have individual
chip-selects and MOSIs (we can consider individual SPI interfaces). The ideia
is to allow users to aggregate these devices so they can be read simultaneously
from the user space.

I found a similar case here involving the AD4880 (ad4080 driver), which consists
of two independent ADC channels, each with its own SPI interface for configuration.
In that instance, the ancillary device feature was used because it was considered
the approach of a single device with independent channels rather than independent
devices connected together. Additionally, the backend handled the buffered data
aggregation.

However, I would like to discuss a more generic approach to support device aggregation
across different drivers. Marcelo suggested a while ago to consider the components
framework. This would allow us to create a virtual device responsible for 
aggregating and controlling the sub-devices in a standard yet flexible manner.

The aggregate driver could either be an extension to the main driver (e.g. ad7768-1.c),
or a separate file (e.g. ad7768-1-agreegator.c). 

Here's an example of how the devicetree would look like: 
(includes the multiple data lanes feature)

spi {
    #address-cells = <1>;
    #size-cells = <0>;

    /* AD7768-1 physical devices */
    adaq7768_1_0: adaq7768-1@0 {
	compatible = "adi,adaq7768-1";
	reg = <0>;  /* CS0 - First physical device */
        spi-tx-lane-map = <0>;
        spi-rx-lane-map = <0>;
	/* other properties */
    };

    adaq7768_1_1: adaq7768-1@1 {
        compatible = "adi,adaq7768-1";
        reg = <1>;  /* CS1 - Second physical device */
        spi-tx-lane-map = <0>;
        spi-rx-lane-map = <1>;
        /* other properties */
    };

    adaq7768_1_2: adaq7768-1@2 {
        compatible = "adi,adaq7768-1";
        reg = <2>;  /* CS2 - Third physical device */
        spi-tx-lane-map = <0>;
        spi-rx-lane-map = <2>;
        /* other properties */
    };

    adaq7768_1_3: adaq7768-1@3 {
        compatible = "adi,adaq7768-1";
        reg = <3>;  /* CS3 */
        spi-tx-lane-map = <0>;
        spi-rx-lane-map = <3>;
        /* other properties */
    };

    /* AD7768-1 aggregator/virtual device */
    quad_adaq7768: ad7768-1-aggregator@4 {
        compatible = "adi,ad7768-1-aggregator";
        reg = <4>; /* ? */

        adaq7768-components = <&adaq7768_1_0>, <&adaq7768_1_1>, <&adaq7768_1_2>, <&adaq7768_1_3>;
        
    };
        
};

Is it ok to proceed with component helper for this purpose or do we have something
better? If yes, I have some following questions:

-> How to read all devices simultaneously in buffer mode given we can't assert 
all CS from the virtual device?

-> Should the physical devices be registered in IIO during probe, or should only
the aggregator be exposed to control attributes and general configuration?

Regards,
Jonathan S.