| Message ID | 20241002-hula-unwashed-1c4ddbadbec2@spud (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Redo PolarFire SoC's mailbox/clock devicestrees and related code | expand |
On 02/10/2024 12:48, Conor Dooley wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > I like this one better than qualcomms and wish to use it for the > PolarFire SoC clock drivers. > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > --- > drivers/clk/Kconfig | 4 ++ > drivers/clk/Makefile | 1 + > drivers/clk/{meson => }/clk-regmap.c | 2 +- > drivers/clk/meson/Kconfig | 46 +++++++++---------- > drivers/clk/meson/Makefile | 1 - > drivers/clk/meson/a1-peripherals.c | 2 +- > drivers/clk/meson/a1-pll.c | 2 +- > drivers/clk/meson/axg-aoclk.c | 2 +- > drivers/clk/meson/axg-audio.c | 2 +- > drivers/clk/meson/axg.c | 2 +- > drivers/clk/meson/c3-peripherals.c | 2 +- > drivers/clk/meson/c3-pll.c | 2 +- > drivers/clk/meson/clk-cpu-dyndiv.c | 2 +- > drivers/clk/meson/clk-dualdiv.c | 2 +- > drivers/clk/meson/clk-mpll.c | 2 +- > drivers/clk/meson/clk-phase.c | 2 +- > drivers/clk/meson/clk-pll.c | 2 +- > drivers/clk/meson/g12a-aoclk.c | 2 +- > drivers/clk/meson/g12a.c | 2 +- > drivers/clk/meson/gxbb-aoclk.c | 2 +- > drivers/clk/meson/gxbb.c | 2 +- > drivers/clk/meson/meson-aoclk.h | 2 +- > drivers/clk/meson/meson-eeclk.c | 2 +- > drivers/clk/meson/meson-eeclk.h | 2 +- > drivers/clk/meson/meson8-ddr.c | 2 +- > drivers/clk/meson/meson8b.c | 2 +- > drivers/clk/meson/s4-peripherals.c | 2 +- > drivers/clk/meson/s4-pll.c | 2 +- > drivers/clk/meson/sclk-div.c | 2 +- > drivers/clk/meson/vclk.h | 2 +- > drivers/clk/meson/vid-pll-div.c | 2 +- > .../meson => include/linux/clk}/clk-regmap.h | 0 > 32 files changed, 53 insertions(+), 53 deletions(-) > rename drivers/clk/{meson => }/clk-regmap.c (99%) > rename {drivers/clk/meson => include/linux/clk}/clk-regmap.h (100%) > <snip> I don't have objections, but I think Stephen didn't like the idea a few years ago, but perhaps it has changed... Anyway, take my: Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Thanks, Neil
On Wed 02 Oct 2024 at 13:20, Neil Armstrong <neil.armstrong@linaro.org> wrote: > On 02/10/2024 12:48, Conor Dooley wrote: >> From: Conor Dooley <conor.dooley@microchip.com> >> I like this one better than qualcomms and wish to use it for the >> PolarFire SoC clock drivers. >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> >> --- >> drivers/clk/Kconfig | 4 ++ >> drivers/clk/Makefile | 1 + >> drivers/clk/{meson => }/clk-regmap.c | 2 +- >> drivers/clk/meson/Kconfig | 46 +++++++++---------- >> drivers/clk/meson/Makefile | 1 - >> drivers/clk/meson/a1-peripherals.c | 2 +- >> drivers/clk/meson/a1-pll.c | 2 +- >> drivers/clk/meson/axg-aoclk.c | 2 +- >> drivers/clk/meson/axg-audio.c | 2 +- >> drivers/clk/meson/axg.c | 2 +- >> drivers/clk/meson/c3-peripherals.c | 2 +- >> drivers/clk/meson/c3-pll.c | 2 +- >> drivers/clk/meson/clk-cpu-dyndiv.c | 2 +- >> drivers/clk/meson/clk-dualdiv.c | 2 +- >> drivers/clk/meson/clk-mpll.c | 2 +- >> drivers/clk/meson/clk-phase.c | 2 +- >> drivers/clk/meson/clk-pll.c | 2 +- >> drivers/clk/meson/g12a-aoclk.c | 2 +- >> drivers/clk/meson/g12a.c | 2 +- >> drivers/clk/meson/gxbb-aoclk.c | 2 +- >> drivers/clk/meson/gxbb.c | 2 +- >> drivers/clk/meson/meson-aoclk.h | 2 +- >> drivers/clk/meson/meson-eeclk.c | 2 +- >> drivers/clk/meson/meson-eeclk.h | 2 +- >> drivers/clk/meson/meson8-ddr.c | 2 +- >> drivers/clk/meson/meson8b.c | 2 +- >> drivers/clk/meson/s4-peripherals.c | 2 +- >> drivers/clk/meson/s4-pll.c | 2 +- >> drivers/clk/meson/sclk-div.c | 2 +- >> drivers/clk/meson/vclk.h | 2 +- >> drivers/clk/meson/vid-pll-div.c | 2 +- >> .../meson => include/linux/clk}/clk-regmap.h | 0 >> 32 files changed, 53 insertions(+), 53 deletions(-) >> rename drivers/clk/{meson => }/clk-regmap.c (99%) >> rename {drivers/clk/meson => include/linux/clk}/clk-regmap.h (100%) >> > <snip> > > I don't have objections, but I think Stephen didn't like the idea > a few years ago, but perhaps it has changed... > > Anyway, take my: > Acked-by: Neil Armstrong <neil.armstrong@linaro.org> We had a similar discussion 3y ago indeed: https://lore.kernel.org/linux-clk/162734682512.2368309.12015873010777083014@swboyd.mtv.corp.google.com/ There are needs for a common regmap backed clocks indeed, but allowing meson flavored regmap clocks to spread in the kernel was not really the prefered way to do it. IIRC, Stephen's idea was more the bring regmap support in clk-gate.c, clk-mux, etc ... I'm not quite sure how make iomem and regmap co-exist in a manageable/maintainable way within those drivers (without adding yet another level of abstraction I mean) ? Silently creating a regmap maybe ? but that's probably a bit heavy. I did not really had time to dig more on this, I guess no one did. I don't really have a preference one way or the other but if it is going to be exposed in 'include/linux', we need to be sure that's how we want to do it. With clocks poping in many driver subsystems, it will difficult to change afterward. > > Thanks, > Neil
On Wed, Oct 02, 2024 at 03:21:16PM +0200, Jerome Brunet wrote: > On Wed 02 Oct 2024 at 13:20, Neil Armstrong <neil.armstrong@linaro.org> wrote: > > > On 02/10/2024 12:48, Conor Dooley wrote: > >> From: Conor Dooley <conor.dooley@microchip.com> > >> I like this one better than qualcomms and wish to use it for the > >> PolarFire SoC clock drivers. > >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > >> --- > >> drivers/clk/Kconfig | 4 ++ > >> drivers/clk/Makefile | 1 + > >> drivers/clk/{meson => }/clk-regmap.c | 2 +- > >> drivers/clk/meson/Kconfig | 46 +++++++++---------- > >> drivers/clk/meson/Makefile | 1 - > >> drivers/clk/meson/a1-peripherals.c | 2 +- > >> drivers/clk/meson/a1-pll.c | 2 +- > >> drivers/clk/meson/axg-aoclk.c | 2 +- > >> drivers/clk/meson/axg-audio.c | 2 +- > >> drivers/clk/meson/axg.c | 2 +- > >> drivers/clk/meson/c3-peripherals.c | 2 +- > >> drivers/clk/meson/c3-pll.c | 2 +- > >> drivers/clk/meson/clk-cpu-dyndiv.c | 2 +- > >> drivers/clk/meson/clk-dualdiv.c | 2 +- > >> drivers/clk/meson/clk-mpll.c | 2 +- > >> drivers/clk/meson/clk-phase.c | 2 +- > >> drivers/clk/meson/clk-pll.c | 2 +- > >> drivers/clk/meson/g12a-aoclk.c | 2 +- > >> drivers/clk/meson/g12a.c | 2 +- > >> drivers/clk/meson/gxbb-aoclk.c | 2 +- > >> drivers/clk/meson/gxbb.c | 2 +- > >> drivers/clk/meson/meson-aoclk.h | 2 +- > >> drivers/clk/meson/meson-eeclk.c | 2 +- > >> drivers/clk/meson/meson-eeclk.h | 2 +- > >> drivers/clk/meson/meson8-ddr.c | 2 +- > >> drivers/clk/meson/meson8b.c | 2 +- > >> drivers/clk/meson/s4-peripherals.c | 2 +- > >> drivers/clk/meson/s4-pll.c | 2 +- > >> drivers/clk/meson/sclk-div.c | 2 +- > >> drivers/clk/meson/vclk.h | 2 +- > >> drivers/clk/meson/vid-pll-div.c | 2 +- > >> .../meson => include/linux/clk}/clk-regmap.h | 0 > >> 32 files changed, 53 insertions(+), 53 deletions(-) > >> rename drivers/clk/{meson => }/clk-regmap.c (99%) > >> rename {drivers/clk/meson => include/linux/clk}/clk-regmap.h (100%) > >> > > <snip> > > > > I don't have objections, but I think Stephen didn't like the idea > > a few years ago, but perhaps it has changed... > > > > Anyway, take my: > > Acked-by: Neil Armstrong <neil.armstrong@linaro.org> > > We had a similar discussion 3y ago indeed: > https://lore.kernel.org/linux-clk/162734682512.2368309.12015873010777083014@swboyd.mtv.corp.google.com/ > > There are needs for a common regmap backed clocks indeed, but allowing > meson flavored regmap clocks to spread in the kernel was not really the > prefered way to do it. Cool, thanks for that link. > IIRC, Stephen's idea was more the bring regmap support in clk-gate.c, > clk-mux, etc ... I'm not quite sure how make iomem and regmap co-exist > in a manageable/maintainable way within those drivers (without adding yet > another level of abstraction I mean) ? Silently creating a regmap maybe > ? but that's probably a bit heavy. I did not really had time to dig more > on this, I guess no one did. I guess I have some motivation to looking into it at the moment. I had my reservations about the Meson approach too, liking it more than Qualcomm's didn't mean I completely liked it. It was already my intention to implement point b of your mail, had the general idea here been acceptable, cos that's a divergence from how the generic clock types (that the driver in question currently uses) work. And on that note, I just noticed I left the mild-annoyance variable name "sigh" in the submitted driver changes, which I had used for the clk_regmap struct that your point b in the link relates to. > I don't really have a preference one way or the other but if it is going > to be exposed in 'include/linux', we need to be sure that's how we want > to do it. With clocks poping in many driver subsystems, it will > difficult to change afterward. Yeah, I agree. I didn't expect this to go in right away, and I also didn't want to surge ahead on some rework of the clock types, were people to hate even the reuse.
Stephen, On Thu, Oct 03, 2024 at 12:33:40PM +0100, Conor Dooley wrote: > On Wed, Oct 02, 2024 at 03:21:16PM +0200, Jerome Brunet wrote: > > On Wed 02 Oct 2024 at 13:20, Neil Armstrong <neil.armstrong@linaro.org> wrote: > > > > > On 02/10/2024 12:48, Conor Dooley wrote: > > >> From: Conor Dooley <conor.dooley@microchip.com> > > >> I like this one better than qualcomms and wish to use it for the > > >> PolarFire SoC clock drivers. > > >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > > >> --- > > >> drivers/clk/Kconfig | 4 ++ > > >> drivers/clk/Makefile | 1 + > > >> drivers/clk/{meson => }/clk-regmap.c | 2 +- > > >> drivers/clk/meson/Kconfig | 46 +++++++++---------- > > >> drivers/clk/meson/Makefile | 1 - > > >> drivers/clk/meson/a1-peripherals.c | 2 +- > > >> drivers/clk/meson/a1-pll.c | 2 +- > > >> drivers/clk/meson/axg-aoclk.c | 2 +- > > >> drivers/clk/meson/axg-audio.c | 2 +- > > >> drivers/clk/meson/axg.c | 2 +- > > >> drivers/clk/meson/c3-peripherals.c | 2 +- > > >> drivers/clk/meson/c3-pll.c | 2 +- > > >> drivers/clk/meson/clk-cpu-dyndiv.c | 2 +- > > >> drivers/clk/meson/clk-dualdiv.c | 2 +- > > >> drivers/clk/meson/clk-mpll.c | 2 +- > > >> drivers/clk/meson/clk-phase.c | 2 +- > > >> drivers/clk/meson/clk-pll.c | 2 +- > > >> drivers/clk/meson/g12a-aoclk.c | 2 +- > > >> drivers/clk/meson/g12a.c | 2 +- > > >> drivers/clk/meson/gxbb-aoclk.c | 2 +- > > >> drivers/clk/meson/gxbb.c | 2 +- > > >> drivers/clk/meson/meson-aoclk.h | 2 +- > > >> drivers/clk/meson/meson-eeclk.c | 2 +- > > >> drivers/clk/meson/meson-eeclk.h | 2 +- > > >> drivers/clk/meson/meson8-ddr.c | 2 +- > > >> drivers/clk/meson/meson8b.c | 2 +- > > >> drivers/clk/meson/s4-peripherals.c | 2 +- > > >> drivers/clk/meson/s4-pll.c | 2 +- > > >> drivers/clk/meson/sclk-div.c | 2 +- > > >> drivers/clk/meson/vclk.h | 2 +- > > >> drivers/clk/meson/vid-pll-div.c | 2 +- > > >> .../meson => include/linux/clk}/clk-regmap.h | 0 > > >> 32 files changed, 53 insertions(+), 53 deletions(-) > > >> rename drivers/clk/{meson => }/clk-regmap.c (99%) > > >> rename {drivers/clk/meson => include/linux/clk}/clk-regmap.h (100%) > > >> > > > <snip> > > > > > > I don't have objections, but I think Stephen didn't like the idea > > > a few years ago, but perhaps it has changed... > > > > > > Anyway, take my: > > > Acked-by: Neil Armstrong <neil.armstrong@linaro.org> > > > > We had a similar discussion 3y ago indeed: > > https://lore.kernel.org/linux-clk/162734682512.2368309.12015873010777083014@swboyd.mtv.corp.google.com/ > > > > There are needs for a common regmap backed clocks indeed, but allowing > > meson flavored regmap clocks to spread in the kernel was not really the > > prefered way to do it. > > Cool, thanks for that link. > > > IIRC, Stephen's idea was more the bring regmap support in clk-gate.c, > > clk-mux, etc ... I'm not quite sure how make iomem and regmap co-exist > > in a manageable/maintainable way within those drivers (without adding yet > > another level of abstraction I mean) ? Silently creating a regmap maybe > > ? but that's probably a bit heavy. I did not really had time to dig more > > on this, I guess no one did. > > I guess I have some motivation to looking into it at the moment. I had > my reservations about the Meson approach too, liking it more than > Qualcomm's didn't mean I completely liked it. > It was already my intention to implement point b of your mail, had the > general idea here been acceptable, cos that's a divergence from how the > generic clock types (that the driver in question currently uses) work. > And on that note, I just noticed I left the mild-annoyance variable name > "sigh" in the submitted driver changes, which I had used for the > clk_regmap struct that your point b in the link relates to. > > > I don't really have a preference one way or the other but if it is going > > to be exposed in 'include/linux', we need to be sure that's how we want > > to do it. With clocks poping in many driver subsystems, it will > > difficult to change afterward. > > Yeah, I agree. I didn't expect this to go in right away, and I also > didn't want to surge ahead on some rework of the clock types, were > people to hate even the reuse. Hmm, so how (in-)complete of a regmap implementation can I get away with? I only need clk-gate and clk-divider for this patchset... Shoving the regmap into the clk structs makes things pretty trivial as I don't need to do anything special in any function other than clk_*_readl()/clk_*_writel() and the registration code. A flag isn't even needed to determine if a clock is a regmap one I don't think, since you can just check if the regmap pointer is non-NULL. My use case doesn't actually need the registration code changes either as, currently, only reg gets set at runtime, but leaving that out is a level of incomplete I'd not let myself away with. Obviously shoving the extra members into the clk structs has the downside of taking up a pointer and a offset worth of memory for each clock of that type registered, but it is substantially easier to support devices with multiple regmaps that way. Probably moot though since the approach you suggested in the thread linked above that implements a clk_hw_get_regmap() has to store a pointer to the regmap's identifier which would take up an identical amount of memory. I don't really care which way you want it done, both are pretty easy to implement if I can get away with just doing so for the two standard clock types that I am using - is it okay to just do those two? Cheers, Conor.
Quoting Conor Dooley (2024-11-06 04:56:25) > On Thu, Oct 03, 2024 at 12:33:40PM +0100, Conor Dooley wrote: > > > IIRC, Stephen's idea was more the bring regmap support in clk-gate.c, > > > clk-mux, etc ... I'm not quite sure how make iomem and regmap co-exist > > > in a manageable/maintainable way within those drivers (without adding yet > > > another level of abstraction I mean) ? Silently creating a regmap maybe > > > ? but that's probably a bit heavy. I did not really had time to dig more > > > on this, I guess no one did. > > > > I guess I have some motivation to looking into it at the moment. I had > > my reservations about the Meson approach too, liking it more than > > Qualcomm's didn't mean I completely liked it. > > It was already my intention to implement point b of your mail, had the > > general idea here been acceptable, cos that's a divergence from how the > > generic clock types (that the driver in question currently uses) work. > > And on that note, I just noticed I left the mild-annoyance variable name > > "sigh" in the submitted driver changes, which I had used for the > > clk_regmap struct that your point b in the link relates to. > > > > > I don't really have a preference one way or the other but if it is going > > > to be exposed in 'include/linux', we need to be sure that's how we want > > > to do it. With clocks poping in many driver subsystems, it will > > > difficult to change afterward. > > > > Yeah, I agree. I didn't expect this to go in right away, and I also > > didn't want to surge ahead on some rework of the clock types, were > > people to hate even the reuse. > > Hmm, so how (in-)complete of a regmap implementation can I get away > with? I only need clk-gate and clk-divider for this patchset... > > Shoving the regmap into the clk structs makes things pretty trivial as I > don't need to do anything special in any function other than > clk_*_readl()/clk_*_writel() and the registration code. A flag isn't > even needed to determine if a clock is a regmap one I don't think, since > you can just check if the regmap pointer is non-NULL. For the basic clk types I think it would be good to leave the old stuff alone. We have already split the logic out into helpers, so I wonder if we can do this better by making kernel modules for the different basic regmap clk types and exposing registration APIs. If we force drivers that use the basic regmap types to 'select' the module then we'll make it so that we don't include code that isn't used anywhere. That's one of the problems with the basic clk types, it's always built. It also lets us avoid making regmap a dependency for the clk framework at large. Doing that would also let us avoid the flag because it will be explicit in any registration API, clk_register_divider() vs. clk_register_regmap_divider(). Yes we duplicate some boiler plate logic around read-only and registration paths, but this is alright as long as we can share most of the code and gain the advantage of removing the code entirely when it isn't used. I wonder if we can even make a regmap on the fly for the iomem pointers so that clk_divider_readl() can always use the regmap API to access the hardware. Sounds wasteful but maybe it would work. > My use case doesn't > actually need the registration code changes either as, currently, only reg > gets set at runtime, but leaving that out is a level of incomplete I'd not > let myself away with. > Obviously shoving the extra members into the clk structs has the downside > of taking up a pointer and a offset worth of memory for each clock of > that type registered, but it is substantially easier to support devices > with multiple regmaps that way. Probably moot though since the approach you > suggested in the thread linked above that implements a clk_hw_get_regmap() > has to store a pointer to the regmap's identifier which would take up an > identical amount of memory. We don't need to store the regmap identifier in the struct clk. We can store it in the 'struct clk_init_data' with some new field, and only do that when/if we actually need to. We would need to pass the init data to the clk_ops::init() callback though. We currently knock that out during registration so that clk_hw->init is NULL. Probably we can just set that to NULL after the init routine runs in __clk_core_init(). Long story short, don't add something to 'struct clk_core', 'struct clk', or 'struct clk_hw' for these details. We can have a 'struct clk_regmap_hw' that everyone else can build upon: struct clk_regmap_hw { struct regmap *regmap; struct clk_hw hw; }; and then set the regmap pointer during registration in clk_hw_init_regmap(). int clk_hw_init_regmap(struct clk_hw *hw) { struct device *dev; struct regmap *regmap; struct clk_regmap_hw *rhw; rhw = clk_hw_to_clk_regmap_hw(hw); dev = clk_hw_get_dev(hw); if (!dev) return -EINVAL; regmap = dev_get_regmap(dev, hw->init->regmap_name); if (!regmap) return -EINVAL; // Print helpful message rhw->regmap = regmap; return 0; } or we can even make it so that there's clk_hw_init_regmap() and clk_hw_init_regmap_name() so that drivers can have multiple functions if the clks need different regmaps. int my_init_regmap(struct clk_hw *hw) { int ret; ret = clk_hw_init_regmap_name(hw, "my_name"); ... } If you don't need the multiple regmap support then it's fine to punt here until later. > > I don't really care which way you want it done, both are pretty easy to > implement if I can get away with just doing so for the two standard > clock types that I am using - is it okay to just do those two? > Of course, doing only what is minimally required is better than changing everything if you're not sure the approach is going to land.
On Thu, Nov 14, 2024 at 05:29:54PM -0800, Stephen Boyd wrote: > Quoting Conor Dooley (2024-11-06 04:56:25) > > My use case doesn't > > actually need the registration code changes either as, currently, only reg > > gets set at runtime, but leaving that out is a level of incomplete I'd not > > let myself away with. > > Obviously shoving the extra members into the clk structs has the downside > > of taking up a pointer and a offset worth of memory for each clock of > > that type registered, but it is substantially easier to support devices > > with multiple regmaps that way. Probably moot though since the approach you > > suggested in the thread linked above that implements a clk_hw_get_regmap() > > has to store a pointer to the regmap's identifier which would take up an > > identical amount of memory. > > We don't need to store the regmap identifier in the struct clk. We can > store it in the 'struct clk_init_data' with some new field, and only do > that when/if we actually need to. We would need to pass the init data to > the clk_ops::init() callback though. We currently knock that out during > registration so that clk_hw->init is NULL. Probably we can just set that > to NULL after the init routine runs in __clk_core_init(). > > Long story short, don't add something to 'struct clk_core', 'struct > clk', or 'struct clk_hw' for these details. We can have a 'struct > clk_regmap_hw' that everyone else can build upon: > > struct clk_regmap_hw { > struct regmap *regmap; > struct clk_hw hw; > }; What's the point of this? I don't understand why you want to do this over what clk_divider et al already do, where clk_hw and the iomem pointer are in the struct itself. > > and then set the regmap pointer during registration in > clk_hw_init_regmap(). > > int clk_hw_init_regmap(struct clk_hw *hw) > { > struct device *dev; > struct regmap *regmap; > struct clk_regmap_hw *rhw; > > rhw = clk_hw_to_clk_regmap_hw(hw); > > dev = clk_hw_get_dev(hw); > if (!dev) > return -EINVAL; > > regmap = dev_get_regmap(dev, hw->init->regmap_name); > if (!regmap) > return -EINVAL; // Print helpful message > rhw->regmap = regmap; > > return 0; > }
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 299bc678ed1b9..85397308a74f4 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -33,6 +33,10 @@ menuconfig COMMON_CLK if COMMON_CLK +config COMMON_CLK_REGMAP + bool + select REGMAP + config COMMON_CLK_WM831X tristate "Clock driver for WM831x/2x PMICs" depends on MFD_WM831X diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index fb8878a5d7d93..bffdbfb932beb 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -14,6 +14,7 @@ obj-$(CONFIG_COMMON_CLK) += clk-gate.o obj-$(CONFIG_CLK_GATE_KUNIT_TEST) += clk-gate_test.o obj-$(CONFIG_COMMON_CLK) += clk-multiplier.o obj-$(CONFIG_COMMON_CLK) += clk-mux.o +obj-$(CONFIG_COMMON_CLK_REGMAP) += clk-regmap.o obj-$(CONFIG_COMMON_CLK) += clk-composite.o obj-$(CONFIG_COMMON_CLK) += clk-fractional-divider.o obj-$(CONFIG_CLK_FD_KUNIT_TEST) += clk-fractional-divider_test.o diff --git a/drivers/clk/meson/clk-regmap.c b/drivers/clk/clk-regmap.c similarity index 99% rename from drivers/clk/meson/clk-regmap.c rename to drivers/clk/clk-regmap.c index 07f7e441b9161..4ec0ed8f72011 100644 --- a/drivers/clk/meson/clk-regmap.c +++ b/drivers/clk/clk-regmap.c @@ -5,7 +5,7 @@ */ #include <linux/module.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> static int clk_regmap_gate_endisable(struct clk_hw *hw, int enable) { diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig index 78f648c9c97dc..ee4599dab7ff7 100644 --- a/drivers/clk/meson/Kconfig +++ b/drivers/clk/meson/Kconfig @@ -2,61 +2,57 @@ menu "Clock support for Amlogic platforms" depends on ARCH_MESON || COMPILE_TEST -config COMMON_CLK_MESON_REGMAP - tristate - select REGMAP - config COMMON_CLK_MESON_DUALDIV tristate - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP config COMMON_CLK_MESON_MPLL tristate - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP config COMMON_CLK_MESON_PHASE tristate - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP config COMMON_CLK_MESON_PLL tristate - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP config COMMON_CLK_MESON_SCLK_DIV tristate - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP config COMMON_CLK_MESON_VID_PLL_DIV tristate - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP config COMMON_CLK_MESON_VCLK tristate - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP config COMMON_CLK_MESON_CLKC_UTILS tristate config COMMON_CLK_MESON_AO_CLKC tristate - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP select COMMON_CLK_MESON_CLKC_UTILS select RESET_CONTROLLER config COMMON_CLK_MESON_EE_CLKC tristate - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP select COMMON_CLK_MESON_CLKC_UTILS config COMMON_CLK_MESON_CPU_DYNDIV tristate - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP config COMMON_CLK_MESON8B bool "Meson8 SoC Clock controller support" depends on ARM default y - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP select COMMON_CLK_MESON_CLKC_UTILS select COMMON_CLK_MESON_MPLL select COMMON_CLK_MESON_PLL @@ -71,7 +67,7 @@ config COMMON_CLK_GXBB tristate "GXBB and GXL SoC clock controllers support" depends on ARM64 default y - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP select COMMON_CLK_MESON_DUALDIV select COMMON_CLK_MESON_VID_PLL_DIV select COMMON_CLK_MESON_MPLL @@ -87,7 +83,7 @@ config COMMON_CLK_AXG tristate "AXG SoC clock controllers support" depends on ARM64 default y - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP select COMMON_CLK_MESON_DUALDIV select COMMON_CLK_MESON_MPLL select COMMON_CLK_MESON_PLL @@ -101,7 +97,7 @@ config COMMON_CLK_AXG config COMMON_CLK_AXG_AUDIO tristate "Meson AXG Audio Clock Controller Driver" depends on ARM64 - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP select COMMON_CLK_MESON_PHASE select COMMON_CLK_MESON_SCLK_DIV select COMMON_CLK_MESON_CLKC_UTILS @@ -113,7 +109,7 @@ config COMMON_CLK_AXG_AUDIO config COMMON_CLK_A1_PLL tristate "Amlogic A1 SoC PLL controller support" depends on ARM64 - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP select COMMON_CLK_MESON_CLKC_UTILS select COMMON_CLK_MESON_PLL help @@ -125,7 +121,7 @@ config COMMON_CLK_A1_PERIPHERALS tristate "Amlogic A1 SoC Peripherals clock controller support" depends on ARM64 select COMMON_CLK_MESON_DUALDIV - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP select COMMON_CLK_MESON_CLKC_UTILS help Support for the Peripherals clock controller on Amlogic A113L based @@ -136,7 +132,7 @@ config COMMON_CLK_C3_PLL tristate "Amlogic C3 PLL clock controller" depends on ARM64 default y - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP select COMMON_CLK_MESON_PLL select COMMON_CLK_MESON_CLKC_UTILS imply COMMON_CLK_SCMI @@ -149,7 +145,7 @@ config COMMON_CLK_C3_PERIPHERALS tristate "Amlogic C3 peripherals clock controller" depends on ARM64 default y - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP select COMMON_CLK_MESON_DUALDIV select COMMON_CLK_MESON_CLKC_UTILS imply COMMON_CLK_SCMI @@ -163,7 +159,7 @@ config COMMON_CLK_G12A tristate "G12 and SM1 SoC clock controllers support" depends on ARM64 default y - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP select COMMON_CLK_MESON_DUALDIV select COMMON_CLK_MESON_MPLL select COMMON_CLK_MESON_PLL @@ -184,7 +180,7 @@ config COMMON_CLK_S4_PLL select COMMON_CLK_MESON_CLKC_UTILS select COMMON_CLK_MESON_MPLL select COMMON_CLK_MESON_PLL - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP help Support for the PLL clock controller on Amlogic S805X2 and S905Y4 devices, AKA S4. Say Y if you want the board to work, because PLLs are the parent of @@ -195,7 +191,7 @@ config COMMON_CLK_S4_PERIPHERALS depends on ARM64 default y select COMMON_CLK_MESON_CLKC_UTILS - select COMMON_CLK_MESON_REGMAP + select COMMON_CLK_REGMAP select COMMON_CLK_MESON_DUALDIV select COMMON_CLK_MESON_VID_PLL_DIV help diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile index bc56a47931c1d..cd870281d82c7 100644 --- a/drivers/clk/meson/Makefile +++ b/drivers/clk/meson/Makefile @@ -9,7 +9,6 @@ obj-$(CONFIG_COMMON_CLK_MESON_EE_CLKC) += meson-eeclk.o obj-$(CONFIG_COMMON_CLK_MESON_MPLL) += clk-mpll.o obj-$(CONFIG_COMMON_CLK_MESON_PHASE) += clk-phase.o obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o -obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o diff --git a/drivers/clk/meson/a1-peripherals.c b/drivers/clk/meson/a1-peripherals.c index 7aa6abb2eb1f2..6178e6a153394 100644 --- a/drivers/clk/meson/a1-peripherals.c +++ b/drivers/clk/meson/a1-peripherals.c @@ -12,7 +12,7 @@ #include <linux/platform_device.h> #include "a1-peripherals.h" #include "clk-dualdiv.h" -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "meson-clkc-utils.h" #include <dt-bindings/clock/amlogic,a1-peripherals-clkc.h> diff --git a/drivers/clk/meson/a1-pll.c b/drivers/clk/meson/a1-pll.c index 8e5a42d1afbbc..48ba3981b22df 100644 --- a/drivers/clk/meson/a1-pll.c +++ b/drivers/clk/meson/a1-pll.c @@ -11,7 +11,7 @@ #include <linux/mod_devicetable.h> #include <linux/platform_device.h> #include "a1-pll.h" -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "meson-clkc-utils.h" #include <dt-bindings/clock/amlogic,a1-pll-clkc.h> diff --git a/drivers/clk/meson/axg-aoclk.c b/drivers/clk/meson/axg-aoclk.c index 1dabc81535a6f..ee89edf05a443 100644 --- a/drivers/clk/meson/axg-aoclk.c +++ b/drivers/clk/meson/axg-aoclk.c @@ -15,7 +15,7 @@ #include <linux/module.h> #include "meson-aoclk.h" -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-dualdiv.h" #include <dt-bindings/clock/axg-aoclkc.h> diff --git a/drivers/clk/meson/axg-audio.c b/drivers/clk/meson/axg-audio.c index beda863493899..06ccf1db63f58 100644 --- a/drivers/clk/meson/axg-audio.c +++ b/drivers/clk/meson/axg-audio.c @@ -17,7 +17,7 @@ #include "meson-clkc-utils.h" #include "axg-audio.h" -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-phase.h" #include "sclk-div.h" diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c index 757c7a28c53de..73a0cad223c9c 100644 --- a/drivers/clk/meson/axg.c +++ b/drivers/clk/meson/axg.c @@ -15,7 +15,7 @@ #include <linux/platform_device.h> #include <linux/module.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-pll.h" #include "clk-mpll.h" #include "axg.h" diff --git a/drivers/clk/meson/c3-peripherals.c b/drivers/clk/meson/c3-peripherals.c index 7dcbf4ebee078..13c13ead6bc66 100644 --- a/drivers/clk/meson/c3-peripherals.c +++ b/drivers/clk/meson/c3-peripherals.c @@ -8,7 +8,7 @@ #include <linux/clk-provider.h> #include <linux/platform_device.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-dualdiv.h" #include "meson-clkc-utils.h" #include <dt-bindings/clock/amlogic,c3-peripherals-clkc.h> diff --git a/drivers/clk/meson/c3-pll.c b/drivers/clk/meson/c3-pll.c index 32bd2ed9d3044..06a7322403b53 100644 --- a/drivers/clk/meson/c3-pll.c +++ b/drivers/clk/meson/c3-pll.c @@ -8,7 +8,7 @@ #include <linux/clk-provider.h> #include <linux/platform_device.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-pll.h" #include "meson-clkc-utils.h" #include <dt-bindings/clock/amlogic,c3-pll-clkc.h> diff --git a/drivers/clk/meson/clk-cpu-dyndiv.c b/drivers/clk/meson/clk-cpu-dyndiv.c index 6c1f58826e24a..d14bb1b5e4337 100644 --- a/drivers/clk/meson/clk-cpu-dyndiv.c +++ b/drivers/clk/meson/clk-cpu-dyndiv.c @@ -7,7 +7,7 @@ #include <linux/clk-provider.h> #include <linux/module.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-cpu-dyndiv.h" static inline struct meson_clk_cpu_dyndiv_data * diff --git a/drivers/clk/meson/clk-dualdiv.c b/drivers/clk/meson/clk-dualdiv.c index 913bf25d3771b..8926f6fc94edf 100644 --- a/drivers/clk/meson/clk-dualdiv.c +++ b/drivers/clk/meson/clk-dualdiv.c @@ -24,7 +24,7 @@ #include <linux/clk-provider.h> #include <linux/module.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-dualdiv.h" static inline struct meson_clk_dualdiv_data * diff --git a/drivers/clk/meson/clk-mpll.c b/drivers/clk/meson/clk-mpll.c index f639d56f0fd3f..cdf5c3cbeda12 100644 --- a/drivers/clk/meson/clk-mpll.c +++ b/drivers/clk/meson/clk-mpll.c @@ -15,7 +15,7 @@ #include <linux/module.h> #include <linux/spinlock.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-mpll.h" #define SDM_DEN 16384 diff --git a/drivers/clk/meson/clk-phase.c b/drivers/clk/meson/clk-phase.c index c1526fbfb6c4c..f48384c190e2f 100644 --- a/drivers/clk/meson/clk-phase.c +++ b/drivers/clk/meson/clk-phase.c @@ -7,7 +7,7 @@ #include <linux/clk-provider.h> #include <linux/module.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-phase.h" #define phase_step(_width) (360 / (1 << (_width))) diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c index bc570a2ff3a3f..44d87c6c3dcaa 100644 --- a/drivers/clk/meson/clk-pll.c +++ b/drivers/clk/meson/clk-pll.c @@ -33,7 +33,7 @@ #include <linux/math64.h> #include <linux/module.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-pll.h" static inline struct meson_clk_pll_data * diff --git a/drivers/clk/meson/g12a-aoclk.c b/drivers/clk/meson/g12a-aoclk.c index f0a18d8c9fc23..25e6f2597407e 100644 --- a/drivers/clk/meson/g12a-aoclk.c +++ b/drivers/clk/meson/g12a-aoclk.c @@ -15,7 +15,7 @@ #include <linux/module.h> #include "meson-aoclk.h" -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-dualdiv.h" #include <dt-bindings/clock/g12a-aoclkc.h> diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c index 02dda57105b10..b88b2519c9150 100644 --- a/drivers/clk/meson/g12a.c +++ b/drivers/clk/meson/g12a.c @@ -19,7 +19,7 @@ #include "clk-mpll.h" #include "clk-pll.h" -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-cpu-dyndiv.h" #include "vid-pll-div.h" #include "vclk.h" diff --git a/drivers/clk/meson/gxbb-aoclk.c b/drivers/clk/meson/gxbb-aoclk.c index 83b034157b353..f6facefc79041 100644 --- a/drivers/clk/meson/gxbb-aoclk.c +++ b/drivers/clk/meson/gxbb-aoclk.c @@ -8,7 +8,7 @@ #include <linux/module.h> #include "meson-aoclk.h" -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-dualdiv.h" #include <dt-bindings/clock/gxbb-aoclkc.h> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c index f071faad1ebb7..a9c5d73ee4bfb 100644 --- a/drivers/clk/meson/gxbb.c +++ b/drivers/clk/meson/gxbb.c @@ -11,7 +11,7 @@ #include <linux/module.h> #include "gxbb.h" -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-pll.h" #include "clk-mpll.h" #include "meson-eeclk.h" diff --git a/drivers/clk/meson/meson-aoclk.h b/drivers/clk/meson/meson-aoclk.h index 308be3e4814a9..099f4d5b55b10 100644 --- a/drivers/clk/meson/meson-aoclk.h +++ b/drivers/clk/meson/meson-aoclk.h @@ -16,7 +16,7 @@ #include <linux/regmap.h> #include <linux/reset-controller.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "meson-clkc-utils.h" struct meson_aoclk_data { diff --git a/drivers/clk/meson/meson-eeclk.c b/drivers/clk/meson/meson-eeclk.c index 66f79e384fe51..bbbaf9743abd5 100644 --- a/drivers/clk/meson/meson-eeclk.c +++ b/drivers/clk/meson/meson-eeclk.c @@ -11,7 +11,7 @@ #include <linux/regmap.h> #include <linux/module.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "meson-eeclk.h" int meson_eeclkc_probe(struct platform_device *pdev) diff --git a/drivers/clk/meson/meson-eeclk.h b/drivers/clk/meson/meson-eeclk.h index 37a48b75c6605..2def0370200a4 100644 --- a/drivers/clk/meson/meson-eeclk.h +++ b/drivers/clk/meson/meson-eeclk.h @@ -8,7 +8,7 @@ #define __MESON_CLKC_H #include <linux/clk-provider.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "meson-clkc-utils.h" struct platform_device; diff --git a/drivers/clk/meson/meson8-ddr.c b/drivers/clk/meson/meson8-ddr.c index 4b73ea244b630..22b1404ed3e1c 100644 --- a/drivers/clk/meson/meson8-ddr.c +++ b/drivers/clk/meson/meson8-ddr.c @@ -10,7 +10,7 @@ #include <linux/clk-provider.h> #include <linux/platform_device.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "clk-pll.h" #define AM_DDR_PLL_CNTL 0x00 diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c index b7417ac262d33..8711c57e84b5c 100644 --- a/drivers/clk/meson/meson8b.c +++ b/drivers/clk/meson/meson8b.c @@ -17,7 +17,7 @@ #include <linux/regmap.h> #include "meson8b.h" -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "meson-clkc-utils.h" #include "clk-pll.h" #include "clk-mpll.h" diff --git a/drivers/clk/meson/s4-peripherals.c b/drivers/clk/meson/s4-peripherals.c index c930cf0614a0f..e780bb0a07895 100644 --- a/drivers/clk/meson/s4-peripherals.c +++ b/drivers/clk/meson/s4-peripherals.c @@ -10,7 +10,7 @@ #include <linux/of_device.h> #include <linux/platform_device.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "vid-pll-div.h" #include "clk-dualdiv.h" #include "s4-peripherals.h" diff --git a/drivers/clk/meson/s4-pll.c b/drivers/clk/meson/s4-pll.c index b0258933fb9d2..e5e71f0a23ebd 100644 --- a/drivers/clk/meson/s4-pll.c +++ b/drivers/clk/meson/s4-pll.c @@ -12,7 +12,7 @@ #include "clk-mpll.h" #include "clk-pll.h" -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "s4-pll.h" #include "meson-clkc-utils.h" #include <dt-bindings/clock/amlogic,s4-pll-clkc.h> diff --git a/drivers/clk/meson/sclk-div.c b/drivers/clk/meson/sclk-div.c index ae03b048182f3..912b5c9b4c296 100644 --- a/drivers/clk/meson/sclk-div.c +++ b/drivers/clk/meson/sclk-div.c @@ -19,7 +19,7 @@ #include <linux/clk-provider.h> #include <linux/module.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "sclk-div.h" static inline struct meson_sclk_div_data * diff --git a/drivers/clk/meson/vclk.h b/drivers/clk/meson/vclk.h index 20b0b181db09d..6f0370b0d3a69 100644 --- a/drivers/clk/meson/vclk.h +++ b/drivers/clk/meson/vclk.h @@ -6,7 +6,7 @@ #ifndef __VCLK_H #define __VCLK_H -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "parm.h" /** diff --git a/drivers/clk/meson/vid-pll-div.c b/drivers/clk/meson/vid-pll-div.c index 486cf68fc97a0..e3558b1a0744c 100644 --- a/drivers/clk/meson/vid-pll-div.c +++ b/drivers/clk/meson/vid-pll-div.c @@ -7,7 +7,7 @@ #include <linux/clk-provider.h> #include <linux/module.h> -#include "clk-regmap.h" +#include <linux/clk/clk-regmap.h> #include "vid-pll-div.h" static inline struct meson_vid_pll_div_data * diff --git a/drivers/clk/meson/clk-regmap.h b/include/linux/clk/clk-regmap.h similarity index 100% rename from drivers/clk/meson/clk-regmap.h rename to include/linux/clk/clk-regmap.h