2018-04-03 17:03 GMT+09:00 Lee Jones <lee.jones@xxxxxxxxxx>: > 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@xxxxxxx>: >> > >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
