Re: [Question] MFD driver that handles clocks/resets and populates child nodes

[Masahiro Yamada <yamada.masahiro@socionext.com>]

2018-04-03 17:03 GMT+09:00 Lee Jones <lee.jones@linaro.org>:
> On Mon, 02 Apr 2018, Andrew Lunn wrote:
>
>> On Mon, Apr 02, 2018 at 10:21:01PM +0900, Masahiro Yamada wrote:
>> > 2018-04-02 21:04 GMT+09:00 Andrew Lunn <andrew@lunn.ch>:
>> > >> The maintainer of DWC3, Felipe Balbi, requested to
>> > >> split the glue layer driver into small parts such as
>> > >> reset, regulator, phy, etc.
>> > >
>> > > What exactly did Felipe ask for? Did he ask that the patch be split
>> > > up, one patch per reset, regulator, phy etc?
>> >
>> >
>> > Yeah.  That is what we understood from his comments.
>> >
>> >
>> > These are the feed-backs from him.
>> >
>> > https://lkml.org/lkml/2018/1/23/298
>> > https://lkml.org/lkml/2018/1/24/352
>>
>> > > Are all these resources used just by the DWC3? Or is it a true MFD,
>> > > multiple functions?
>> >
>> > I do not think this is a real MFD.
>> >
>> > This is a DWC3 glue layer, i.e.
>> > a collection of misc registers that control
>> > the DWC3 IP.
>> >
>> >
>> > Just splitting it into small pieces
>> > to use PHY, reset, regulator framework in Linux.
>> >
>> > Of course, the price of this approach
>> > is so cluttered Device Tree,
>> > honestly I do not like it much.
>>
>> This however the correct way to do this. You should have a phy driver,
>> and a regulator driver, and a reset driver. The DWC3 then uses
>> phandles to these drivers.
>>
>> How is the IO map area 65b00000 split up. Can you cleanly separate it
>> into sub areas, which do not overlap, so you have a sub-area for the
>> PHY driver, a sub-area for the regulator driver and a sub-area for the
>> reset area? If you can cleanly split it up, you don't need an MFD. If
>> however the registers are in overlapping areas, you do need an
>> MFD. The MFD core provides access to the registers, while its children
>> implement PHY, reset, regulator etc.
>
> This device certainly sounds like an MFD to me.
>
> Can you share the DT you've written please?


This is still under the internal review in Socionext,
but I attached it below FWIW.

(I am not the author of this DT.
 Written by Kunihiko Hayashi,
 and clocks/resets parts were slightly modified by me.)


Just skimming the driver, I guess it will be possible to flatten
the node structure by separating the register space into sub-areas.
If this is success, we do not the MFD driver.


usb@65b00000 {
        compatible = "socionext,uniphier-ld20-usb3-glue",
                     "syscon";
        reg = <0x65b00000 0x1000>;
        clock-names = "usb";
        clocks = <&sys_clk 14>;
        reset-names = "usb";
        resets = <&sys_rst 14>;

        usb_rst: reset {
                compatible = "socionext,uniphier-ld20-usb3-reset";
                #reset-cells = <1>;
        };

        regulators {
                compatible = "socionext,uniphier-ld20-usb3-regulator";

                usb_vbus0: vbus-0 { };
                usb_vbus1: vbus-1 { };
                usb_vbus2: vbus-2 { };
                usb_vbus3: vbus-3 { };
        };

        usb_hsphy: hs-phy {
                compatible = "socionext,uniphier-ld20-usb3-hsphy";
                #address-cells = <1>;
                #size-cells = <0>;
                #phy-cells = <0>;
                clock-names = "phy-clk0", "phy-clk1";
                clocks = <&sys_clk 16>, <&sys_clk 17>;
                reset-names = "phy-rst0", "phy-rst1";
                resets = <&sys_rst 16>, <&sys_rst 17>;
                port0-supply = <&usb_vbus0>;
                port1-supply = <&usb_vbus1>;
                port2-supply = <&usb_vbus2>;
                port3-supply = <&usb_vbus3>;

                port@0 {
                        reg = <0>;
                        nvmem-cell-names = "rterm", "sel_t",
                                           "hs_i";
                        nvmem-cells = <&usb_rterm0>,
                                      <&usb_sel_t0>,
                                      <&usb_hs_i0>;
                };
                port@1 {
                        reg = <1>;
                        nvmem-cell-names = "rterm", "sel_t",
                                           "hs_i";
                        nvmem-cells = <&usb_rterm1>,
                                      <&usb_sel_t1>,
                                      <&usb_hs_i0>;
                };
                port@2 {
                        reg = <2>;
                        nvmem-cell-names = "rterm", "sel_t",
                                           "hs_i";
                        nvmem-cells = <&usb_rterm2>,
                                      <&usb_sel_t2>,
                                      <&usb_hs_i2>;
                };
                port@3 {
                        reg = <3>;
                        nvmem-cell-names = "rterm", "sel_t",
                                           "hs_i";
                        nvmem-cells = <&usb_rterm3>,
                                      <&usb_sel_t3>,
                                      <&usb_hs_i2>;
                };
        };

        usb_ssphy: ss-phy {
                compatible = "socionext,uniphier-ld20-usb3-ssphy";
                #address-cells = <1>;
                #size-cells = <0>;
                #phy-cells = <0>;
                reset-names = "phy-rst0", "phy-rst1";
                resets = <&sys_rst 18>, <&sys_rst 19>;
                port0-supply = <&usb_vbus0>;
                port1-supply = <&usb_vbus1>;

                port@0 {
                        reg = <0>;
                };
                port@1 {
                        reg = <1>;
                };
        };
};






-- 
Best Regards
Masahiro Yamada