mbox series

[v4,0/9] Add Mule MFD support

Message ID 20240618-dev-mule-i2c-mux-v4-0-5462d28354c8@cherry.de
Headers show
Series Add Mule MFD support | expand

Message

Farouk Bouabid June 18, 2024, 4:06 p.m. UTC
Mule is an MCU that emulates a set of I2C devices which are reachable
through an I2C-mux.

The mux and amc6821 combined make the Mule multi-function device (@0x18)

The devices on the mux can be selected by writing the appropriate
device number to an I2C config register (0xff) that is not used by
amc6821 logic.

The selected device on the mux can be accessed for reading and writing
at I2C address 0x6f.

      +--------+----------------+------------------------------+
      |  Mule         (MFD)                                    |
 0x18 |        +----------------+                              |
--------+----->|    amc6821     |                              |
      | |      +----------------+                              |
      | +----->| Mux config reg |-----+                        |
      |        +----------------+     |                        |
      |                               V__          +---------+ |
      |                              |   \-------->| isl1208 | |
      |                              |   |         +---------+ |
 0x6f |                              | M |-------->| dev #1  | |
------------------------------------>| U |         +---------+ |
      |                              | X |-------->| dev #2  | |
      |                              |   |         +---------+ |
      |                              |   /-------->| dev #3  | |
      |                              |__/          +---------+ |
      +--------------------------------------------------------+

This patch-series adds support for the Mule MFD and I2C multiplexer
as part of rk3399-puma, px30-ringneck, rk3588-tiger and rk3588-jaguar
boards.

Signed-off-by: Farouk Bouabid <farouk.bouabid@cherry.de>

Changes in v4:
- Drop the previously added i2c adapter quirks
- Add platform driver probe to amc6821.
- Change mule-i2c-mux driver to a platform driver
- Add dev_probe_err in mule-i2c-mux driver
- Add support for tsd,mule in simple-mfd-i2c
- Add tsd,mule mfd to supported dts

- Link to v3: https://lore.kernel.org/r/20240611-dev-mule-i2c-mux-v3-0-08d26a28e001@cherry.de

Changes in v3:
- Change "i2c" in comments/commit-logs to "I2C"
- Fix long line-length
- Warn when "share_addr_with_children" is set and the Mux is not an I2C device
- Fix/stop propagating "I2C_AQ_SKIP_ADDR_CHECK" flag if "share_addr_with_children"
  is not set.
- Fix "old_fw" variable is used to indicate the reversed meaning.

- Link to v2: https://lore.kernel.org/r/20240506-dev-mule-i2c-mux-v2-0-a91c954f65d7@cherry.de

Changes in v2:
- Add i2c-adapter quirks to skip checking for conflict between the mux core
  and a child device address.
- Rename dt-binding to "tsd,mule-i2c-mux.yaml"
- Add Mule description to kconfig
- Fix indentation
- Move device table after probe

- Link to v1: https://lore.kernel.org/r/20240426-dev-mule-i2c-mux-v1-0-045a482f6ffb@theobroma-systems.com

---
Farouk Bouabid (9):
      hwmon: (amc6821) add platform driver probe
      hwmon: (amc6821) dev_err using amc6821 device struct
      dt-bindings: mfd: add support for mule
      i2c: muxes: add support for mule i2c multiplexer
      mfd: simple-mfd-i2c: Add support for tsd,mule
      arm64: dts: rockchip: add mule mfd (0x18) on rk3588-jaguar
      arm64: dts: rockchip: add mule mfd (0x18) on rk3399-puma
      arm64: dts: rockchip: add mule mfd (0x18) on rk3588-tiger
      arm64: dts: rockchip: add mule mfd (0x18) on px30-ringneck

 .../devicetree/bindings/i2c/tsd,mule-i2c-mux.yaml  |  48 +++++++
 .../devicetree/bindings/mfd/tsd,mule.yaml          |  82 +++++++++++
 arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi    |  33 ++++-
 arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi      |  33 ++++-
 arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts     |  34 ++++-
 arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi     |  32 ++++-
 drivers/hwmon/amc6821.c                            |  88 +++++++-----
 drivers/i2c/muxes/Kconfig                          |  17 +++
 drivers/i2c/muxes/Makefile                         |   1 +
 drivers/i2c/muxes/i2c-mux-mule.c                   | 151 +++++++++++++++++++++
 drivers/mfd/simple-mfd-i2c.c                       |   1 +
 11 files changed, 461 insertions(+), 59 deletions(-)
---
base-commit: 915c5c8d4bc3c72020b9526cb3cbbd8e14318fc4
change-id: 20240404-dev-mule-i2c-mux-9103cde07021

Best regards,

Comments

Farouk Bouabid June 24, 2024, 4:13 p.m. UTC | #1
Hi Guenter,

On 19.06.24 15:31, Guenter Roeck wrote:
> On 6/19/24 00:45, Farouk Bouabid wrote:
>
>>>
>>> If it is properly defined in devicetree, the emulated AMC6821 should be
>>> an i2c device, possibly sitting behind an i2c multiplexer, not a
>>> platform device.
>>
>>
>> The emulated AMC6821 and the Mule I2C mux are both reachable using 
>> I2C address (0x18), and hence the use of MFD as the mux only uses one 
>> I2C register that is not used by AMC6821.
>>
>
> Whatever you do, the amc chip is still an i2c driver and needs to 
> remain one.
> Modeling it as platform driver is simply wrong, and I won't accept 
> those patches.
>

The issue that we have cannot be handled by an I2C mux because in that 
case both the mux and its child would have the same address which is not 
supported in the I2C subsystem:


i2c-mux@18 {

         compatible = "tsd,mule-i2c-mux";

         reg = <0x18>;

         #address-cells = <1>;

         #size-cells = <0>;


         i2c10: i2c@0 {

                 reg = <0x0>;

                 #address-cells = <1>;

                 #size-cells = <0>;


                 fan: fan@18 {

                         compatible = "ti, amc6821";

                         reg = <0x18>;

                 };

         };

};


The I2C maintainer rejected supporting this use case and suggested that 
an MFD could probably be more suitable.


On one hand, the MFD looks indeed more appropriate and a lot of I2C 
devices are modeled through platform sub devices. On the other hand we 
are emulating the amc6821 in our device which requires us to have it 
modeled as platform:


       +--------+----------------+------------------------------+
       |  Mule         (MFD)                                    |
  0x18 |        +----------------+                              |
--------+----->|    amc6821     |                              |
       | |      +----------------+                              |
       | +----->|      Mux       |-----+                        |
       |        +----------------+     |                        |
       |                               V__          +---------+ |
       |                              |   \-------->| isl1208 | |
       |                              |   |         +---------+ |
  0x6f |                              | M |-------->| dev #1  | |
------------------------------------>| U |         +---------+ |
       |                              | X |-------->| dev #2  | |
       |                              |   |         +---------+ |
       |                              |   /-------->| dev #3  | |
       |                              |__/          +---------+ |
       +--------------------------------------------------------+


If we cannot proceed with that then we could add a compatible to the 
amc6821 driver to add the mux device (Basically the "tsd,mule" 
compatible in amc6821 compatible list would be a combo driver with mux 
logic + amc6821). Do you think that is more appropriate ?


Cheers,

Farouk
Rob Herring (Arm) June 27, 2024, 8:52 p.m. UTC | #2
On Tue, Jun 18, 2024 at 06:06:45PM +0200, Farouk Bouabid wrote:
> Mule is an MCU that emulates a set of I2C devices, among which an amc6821
> device and an I2C mux that exposes more emulated devices. These two devices
> share the same I2C address. Only the I2C mux uses register (0xff) as a
> config register.

Everywhere (or the first place in any section (subject, commit msg, 
title, description, etc.) you say 'mule' I think should be preceeded 
with the vendor because 'mule' has no meaning on its own unless we are 
talking animals.

> 
> Add dt-binding support for the Mule I2C multi-function device.
> 
> Signed-off-by: Farouk Bouabid <farouk.bouabid@cherry.de>
> ---
>  .../devicetree/bindings/i2c/tsd,mule-i2c-mux.yaml  | 48 +++++++++++++
>  .../devicetree/bindings/mfd/tsd,mule.yaml          | 82 ++++++++++++++++++++++
>  2 files changed, 130 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/tsd,mule-i2c-mux.yaml b/Documentation/devicetree/bindings/i2c/tsd,mule-i2c-mux.yaml
> new file mode 100644
> index 000000000000..ac9dfc936272
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/tsd,mule-i2c-mux.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/i2c/tsd,mule-i2c-mux.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mule I2C multiplexer
> +
> +maintainers:
> +  - Farouk Bouabid <farouk.bouabid@cherry.de>
> +  - Quentin Schulz <quentin.schulz@cherry.de>
> +
> +description: |
> +  This module is part of the Mule I2C multi-function device. For more
> +  details see ../mfd/tsd,mule.yaml.
> +
> +  Mule I2C-mux configures the active device that can be accessed on address
> +  0x6f through the config register.
> +
> +      +--------------------------------------------------+
> +      | Mule                                             |
> +  0x18|    +---------------+                             |
> +  -------->|Config register|----+                        |
> +      |    +---------------+    |                        |
> +      |                         V_                       |
> +      |                        |  \          +--------+  |
> +      |                        |   \-------->| dev #0 |  |
> +      |                        |   |         +--------+  |
> +  0x6f|                        | M |-------->| dev #1 |  |
> +  ---------------------------->| U |         +--------+  |
> +      |                        | X |-------->| dev #2 |  |
> +      |                        |   |         +--------+  |
> +      |                        |   /-------->| dev #3 |  |
> +      |                        |__/          +--------+  |
> +      +--------------------------------------------------+
> +
> +
> +allOf:
> +  - $ref: /schemas/i2c/i2c-mux.yaml#
> +
> +properties:
> +  compatible:
> +    const: tsd,mule-i2c-mux
> +
> +required:
> +  - compatible
> +
> +unevaluatedProperties: false
> diff --git a/Documentation/devicetree/bindings/mfd/tsd,mule.yaml b/Documentation/devicetree/bindings/mfd/tsd,mule.yaml
> new file mode 100644
> index 000000000000..ab532340a17c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/tsd,mule.yaml
> @@ -0,0 +1,82 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/tsd,mule.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mule I2C multi function device
> +
> +maintainers:
> +  - Farouk Bouabid <farouk.bouabid@cherry.de>
> +  - Quentin Schulz <quentin.schulz@cherry.de>
> +
> +description:
> +  Mule is an MCU that emulates a set of I2C devices, among which an amc6821
> +  device and an I2C mux that exposes more emulated devices. These two devices
> +  share the same I2C address. Only the I2C mux uses register (0xff) as a config
> +  register.
> +
> +properties:
> +  compatible:
> +    const: tsd,mule
> +
> +  reg:
> +    maxItems: 1
> +
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 0
> +
> +patternProperties:
> +  "^fan(@[0-9a-f]+)?$":
> +    $ref: /schemas/trivial-devices.yaml

That doesn't really define which device. You should do something like 
this:

additionalProperties: true
properties:
  compatible:
    contains:
      const: ti,amc6821

If the compatible is correct, then the schema for it will be applied 
separately.

> +
> +  "^i2c-mux(@[0-9a-f]+)?$":
> +    $ref: /schemas/i2c/tsd,mule-i2c-mux.yaml
> +
> +required:
> +  - "#address-cells"
> +  - "#size-cells"
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        mule@18 {
> +            compatible = "tsd,mule";
> +            reg = <0x18>;
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            fan@18 {
> +                compatible = "ti,amc6821";
> +                reg = <0x18>;
> +            };
> +
> +            i2c-mux {
> +                compatible = "tsd,mule-i2c-mux";
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +
> +                i2c@0 {
> +                    reg = <0x0>;
> +                    #address-cells = <1>;
> +                    #size-cells = <0>;
> +
> +                    rtc@6f {
> +                        compatible = "isil,isl1208";
> +                        reg = <0x6f>;
> +                    };
> +                };
> +            };
> +        };
> +    };
> +...
> 
> -- 
> 2.34.1
>
Guenter Roeck June 28, 2024, 12:05 a.m. UTC | #3
On 6/24/24 09:13, Farouk Bouabid wrote:
> Hi Guenter,
> 
> On 19.06.24 15:31, Guenter Roeck wrote:
>> On 6/19/24 00:45, Farouk Bouabid wrote:
>>
>>>>
>>>> If it is properly defined in devicetree, the emulated AMC6821 should be
>>>> an i2c device, possibly sitting behind an i2c multiplexer, not a
>>>> platform device.
>>>
>>>
>>> The emulated AMC6821 and the Mule I2C mux are both reachable using I2C address (0x18), and hence the use of MFD as the mux only uses one I2C register that is not used by AMC6821.
>>>
>>
>> Whatever you do, the amc chip is still an i2c driver and needs to remain one.
>> Modeling it as platform driver is simply wrong, and I won't accept those patches.
>>
> 
> The issue that we have cannot be handled by an I2C mux because in that case both the mux and its child would have the same address which is not supported in the I2C subsystem:
> 
> 
> i2c-mux@18 {
> 
>          compatible = "tsd,mule-i2c-mux";
> 
>          reg = <0x18>;
> 
>          #address-cells = <1>;
> 
>          #size-cells = <0>;
> 
> 
>          i2c10: i2c@0 {
> 
>                  reg = <0x0>;
> 
>                  #address-cells = <1>;
> 
>                  #size-cells = <0>;
> 
> 
>                  fan: fan@18 {
> 
>                          compatible = "ti, amc6821";
> 
>                          reg = <0x18>;
> 
>                  };
> 
>          };
> 
> };
> 
> 
> The I2C maintainer rejected supporting this use case and suggested that an MFD could probably be more suitable.
> 
> 
> On one hand, the MFD looks indeed more appropriate and a lot of I2C devices are modeled through platform sub devices. On the other hand we are emulating the amc6821 in our device which requires us to have it modeled as platform:
> 

The difference is that those other i2c devices are real multi-function
devices.

> 
>        +--------+----------------+------------------------------+
>        |  Mule         (MFD)                                    |
>   0x18 |        +----------------+                              |
> --------+----->|    amc6821     |                              |
>        | |      +----------------+                              |
>        | +----->|      Mux       |-----+                        |
>        |        +----------------+     |                        |
>        |                               V__          +---------+ |
>        |                              |   \-------->| isl1208 | |
>        |                              |   |         +---------+ |
>   0x6f |                              | M |-------->| dev #1  | |
> ------------------------------------>| U |         +---------+ |
>        |                              | X |-------->| dev #2  | |
>        |                              |   |         +---------+ |
>        |                              |   /-------->| dev #3  | |
>        |                              |__/          +---------+ |
>        +--------------------------------------------------------+
> 
> 

It would have been much more appropriate to use a different I2C address for the mux.

> If we cannot proceed with that then we could add a compatible to the amc6821 driver to add the mux device (Basically the "tsd,mule" compatible in amc6821 compatible list would be a combo driver with mux logic + amc6821). Do you think that is more appropriate ?
> 

Implement the mux as part of the amc6821 driver ? No. We could discuss
instantiating the i2c mux driver from the amc6821 driver.

Guenter
Farouk Bouabid June 28, 2024, 9:03 a.m. UTC | #4
Hi Guenter,

On 28.06.24 02:05, Guenter Roeck wrote:
> On 6/24/24 09:13, Farouk Bouabid wrote:
>> Hi Guenter,
>>
>> On 19.06.24 15:31, Guenter Roeck wrote:
>>> On 6/19/24 00:45, Farouk Bouabid wrote:


[...]


>
>> If we cannot proceed with that then we could add a compatible to the 
>> amc6821 driver to add the mux device (Basically the "tsd,mule" 
>> compatible in amc6821 compatible list would be a combo driver with 
>> mux logic + amc6821). Do you think that is more appropriate ?
>>
>
> Implement the mux as part of the amc6821 driver ? No. We could discuss
> instantiating the i2c mux driver from the amc6821 driver.


If I understand correctly we would have the amc6821 for "tsd,mule" 
compatible probe the mule-i2c-mux as platform_device. Possible DT 
representation would be something like:


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

     fan@18 {
         compatible = "tsd,mule", "ti,amc6821";
         reg = <0x18>;

         i2c-mux {
             compatible = "tsd,mule-i2c-mux";
             #address-cells = <1>;
             #size-cells = <0>;

             i2c@0 {
                 reg = <0x0>;
                 #address-cells = <1>;
                 #size-cells = <0>;

                 rtc@6f {
                     compatible = "isil,isl1208";
                     reg = <0x6f>;
                 };

             };
         };
     };
};


Cheers,

Farouk
Guenter Roeck June 28, 2024, 3:05 p.m. UTC | #5
On 6/28/24 02:03, Farouk Bouabid wrote:
> Hi Guenter,
> 
> On 28.06.24 02:05, Guenter Roeck wrote:
>> On 6/24/24 09:13, Farouk Bouabid wrote:
>>> Hi Guenter,
>>>
>>> On 19.06.24 15:31, Guenter Roeck wrote:
>>>> On 6/19/24 00:45, Farouk Bouabid wrote:
> 
> 
> [...]
> 
> 
>>
>>> If we cannot proceed with that then we could add a compatible to the amc6821 driver to add the mux device (Basically the "tsd,mule" compatible in amc6821 compatible list would be a combo driver with mux logic + amc6821). Do you think that is more appropriate ?
>>>
>>
>> Implement the mux as part of the amc6821 driver ? No. We could discuss
>> instantiating the i2c mux driver from the amc6821 driver.
> 
> 
> If I understand correctly we would have the amc6821 for "tsd,mule" compatible probe the mule-i2c-mux as platform_device. Possible DT representation would be something like:
> 

Yes, something like that. I have a patch series ready which converts the amc6821
to use regmap, so the i2c-mux driver might work as-is with that patch series in place.

Thanks,
Guenter