[PATCH 1/4] ath79: add MFD driver (NAND and GPIO) for Mikrotik RB91xG

[Sergey Ryazanov]

On Thu, May 6, 2021 at 7:31 PM Denis Kalashnikov <denis281089 at gmail.com> wrote:
> rb91x-ngl (nand-gpio-latch) requests and controls SoC GPIO
> lines that are used for NAND control and data lines multiplexed
> with a latch. Lines of the latch that are not used for NAND
> control lines, are used for power LED and user LED and a Shift
> Register nCS.
>
> Like rb4xx-cpld driver rb91x-ngl provides API for separate
> NAND driver and latch-GPIO driver.
>
> This driver is used in place of the ar71xx gpio-latch driver.

When I thought about porting RB91x code to the ath79 target, I also
had assumed as well as you that the parent MFD device is a good choice
to model the latch functionality. But after reviewing the
implementation of this idea, I would like to discuss another design
option. Maybe we should follow the original Gabor's approach and
implement the latch driver as a GPIO controller, but in a bit more
clean way?

For this board, the MFD type latch driver substitutes the common GPIO
API with a custom GPIO API and still knows too much about NAND lines.

If we model the latch as a GPIO controller, then it will consume 9
GPIO lines and produce 17 new GPIO lines. 8 consumed lines are for the
latch data input and another one line for the latch enabled state
control. 17 produced GPIO lines will be used for: 8 GPIOs for NAND
data + 8 additional GPIOs (4 GPIOs for NAND control + 4 GPIOs for LEDs
and for SSR nCS) + 1 more line to control the latch enabled state from
the rb91x-nand driver. The latch enabling line should be passed
through the latch driver to make the driver aware about the latch chip
state to block access to the latched lines as earlier.

So DTS will looks like this:

--------------------------8<---------------------------

latch_gpio: gpio_latch {
    compatible = "gpio-latch";
    gpio-controller;
    data-gpios = <&soc_gpio 0 ...>,
                 <&soc_gpio 1 ...>,
                 ...
                 <&soc_gpio 15 ...>;
    le-gpios = <&soc_gpio 11 ...>;
};

nand {
    compatible = "mikrotik,rb91x-nand";
    data-gpios = <&latch_gpio 0 ...>,
                 <&latch_gpio 1 ...>,
                 ...
                 <&latch_gpio 7 ...>;
    ctrl-gpios = <&latch_gpio 12 ...>, /* NAND RDY */
                 <&latch_gpio 13 ...>, /* NAND nCE */
                 <&latch_gpio 15 ...>, /* NAND ALE */
                 <&latch_gpio 14 ...>, /* NAND CLE */
                 <&soc_gpio 12 ...>,   /* NAND nRW */
                 <&latch_gpio 11 ...>; /* NAND Read */
    ctrl-latch-gpios = <&latch_gpio 16 ...>;
    ...
};

&spi {
    ...
    cs-gpios = <0>, <&latch_gpio 8 ...>;
    ...
};

...

    led_power {
        gpios = <&latch_gpio 9 ...>;
    };
    led_user {
        gpios = <&latch_gpio 10 ...>;
    };

--------------------------8<---------------------------

Using this approach we need one less driver (no need for MFD). But we
lose the clear indication of the latch enabled state change operation
and return to the hook in the output value set handler of the latch
GPIO driver. Also the NAND controller node became a sibling of the
latch node in the DTS, so we partially loose hierarchy information.

Any thoughts?

-- 
Sergey