On Wed, Oct 02, 2024 at 02:25:18PM +0100, Lee Jones wrote:
> On Tue, 01 Oct 2024, Lorenzo Bianconi wrote:
>
> > From: Christian Marangi <ansuelsmth@xxxxxxxxx>
> >
> > Support for Airoha EN7581 Multi Function Device that
> > expose PINCTRL functionality and PWM functionality.
>
> The device is a jumble of pinctrl registers, some of which can oscillate.
>
> This is *still* not an MFD.
>
> If you wish to spread this functionality over 2 drivers, use syscon to
> obtain the registers and simple-mfd to automatically probe the drivers.
>
Hi Lee,
let me summarize the situation so it's more clear why
this additional mfd driver.
There were various iteration for these 2 driver (pinctrl and PWM).
Due to the fact that these 2 are placed in the same register block
with the PWM register in the middle, we proposed various .yaml schema
that could better model it.
The first idea was to map the single register used by the 2 driver.
pio: pinctrl@1fa20214 {
compatible = "airoha,en7581-pinctrl";
reg = <0x0 0x1fa20214 0x0 0x30>,
<0x0 0x1fa2027c 0x0 0x8>,
<0x0 0x1fbf0234 0x0 0x4>,
<0x0 0x1fbf0268 0x0 0x4>,
<0x0 0x1fa2001c 0x0 0x50>,
<0x0 0x1fa2018c 0x0 0x4>,
<0x0 0x1fbf0204 0x0 0x4>,
<0x0 0x1fbf0270 0x0 0x4>,
<0x0 0x1fbf0200 0x0 0x4>,
<0x0 0x1fbf0220 0x0 0x4>,
<0x0 0x1fbf0260 0x0 0x4>,
<0x0 0x1fbf0264 0x0 0x4>,
<0x0 0x1fbf0214 0x0 0x4>,
<0x0 0x1fbf0278 0x0 0x4>,
<0x0 0x1fbf0208 0x0 0x4>,
<0x0 0x1fbf027c 0x0 0x4>,
<0x0 0x1fbf0210 0x0 0x4>,
<0x0 0x1fbf028c 0x0 0x4>,
<0x0 0x1fbf0290 0x0 0x4>,
<0x0 0x1fbf0294 0x0 0x4>,
<0x0 0x1fbf020c 0x0 0x4>,
<0x0 0x1fbf0280 0x0 0x4>,
<0x0 0x1fbf0284 0x0 0x4>,
<0x0 0x1fbf0288 0x0 0x4>;
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = <&pio 0 13 47>;
...
};
pwm@1fbf0224 {
compatible = "airoha,en7581-pwm";
reg = <0x1fbf0224 0x10>,
<0x1fbf0238 0x28>,
<0x1fbf0298 0x8>;
#pwm-cells = <3>;
};
This was quickly rejected as it introduced way more complication
to workaround the overlapping addresses. (the device should map the
entire register space)
The second proposal was a parent+child implementation with the
pinctrl parent and the PWM child by referencing a syscon from
the parent.
pio: pinctrl@1fbf0200 {
compatible = "airoha,en7581-pinctrl", "simple-mfd", "syscon";
reg = <0x1fbf0200 0x0 0xbc>;
airoha,chip-scu = <&chip_scu>;
....
pwm {
compatible = "airoha,en7581-pwm";
...
};
};
Also this second proposal was rejected by device tree folks
as the device implement both pinctrl and PWM in the register
space and they are not actually separate devices.
There was also an additional proposal with the entire register
map in a dedicated node with syscon and pwm + pinctrl using it.
This was also rejected by device tree folks. (node that have only
a syscon are a nono)
It was suggested that this is a case of MFD (multi-functional-device)
As suggested we proposed a simple-mfd implementation following
common pattern. Parent node with simple-mfd and syscon compatible
and 2 child nodes, one with pinctrl and the other with PWM with each
his own compatible.
mfd@1fbf0200 {
compatible = "airoha,en7581-gpio-mfd";
reg = <0x0 0x1fbf0200 0x0 0xc0>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
pio: pinctrl {
compatible = "airoha,en7581-pinctrl";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
pwm: pwm {
compatible = "airoha,en7581-pwm";
#pwm-cells = <3>;
status = "disabled";
};
};
Also this was rejected by device tree folks as the property for
pinctrl and pwm needed to be in the MFD node and there should't
be child node with single compatible.
This comes from the fact that DT needs to describe how the HW is
modelled and not how the drivers are implemented.
Finally Rob agreed and added the Reviwed-by on the current
implementation with single MFD node with pinctrl and pwm.
Also Conor and Krzysztof agreed on this solution for the task.
mfd@1fbf0200 {
compatible = "airoha,en7581-gpio-sysctl";
reg = <0x1fbf0200 0xc0>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
#pwm-cells = <3>;
pinctrl {
...
};
};
With the following implementation, the only way to probe the
additional driver is with a specialized mfd driver that probe the
2 driver by name and we can't really use a simple-mfd implementation
as that requires child nodes with compatibles.
Sorry for the long message and I honestly hope we can find together
a common path for this between driver and Documentation.
Is it clear now why we had to ultimely had to implement and model things
this way?
--
Ansuel
