+Joel On Mon, Mar 20, 2017 at 10:52 AM, Maxim Sloyko <max...@google.com> wrote: > > > On Mon, Mar 20, 2017 at 10:30 AM, Tom Rini <tr...@konsulko.com> wrote: >> >> On Mon, Mar 20, 2017 at 10:24:20AM -0700, Maxim Sloyko wrote: >> > On Sun, Mar 19, 2017 at 9:42 AM, Tom Rini <tr...@konsulko.com> wrote: >> > >> > > On Thu, Mar 16, 2017 at 02:36:20PM -0700, Maxim Sloyko wrote: >> > > > Add support for clocks needed by MACs to ast2500 clock driver. >> > > > The clocks are D2-PLL, which is used by both MACs and PCLK_MAC1 and >> > > > PCLK_MAC2 for MAC1 and MAC2 respectively. >> > > > >> > > > The rate of D2-PLL is hardcoded to 250MHz -- the value used in >> > > > Aspeed >> > > > SDK. It is not entirely clear from the datasheet how this clock is >> > > > used >> > > > by MACs, so not clear if the rate would ever need to be different. >> > > > So, >> > > > for now, hardcoding it is probably safer. >> > > > >> > > > The rate of PCLK_MAC{1,2} is chosen based on MAC speed selected >> > > > through >> > > > hardware strapping. >> > > > >> > > > So, the network driver would only need to enable these clocks, no >> > > > need >> > > > to configure the rate. >> > > > >> > > > Signed-off-by: Maxim Sloyko <max...@google.com> >> > > > --- >> > > > >> > > > arch/arm/dts/ast2500-u-boot.dtsi | 8 + >> > > > arch/arm/include/asm/arch-aspeed/scu_ast2500.h | 62 +++++- >> > > > drivers/clk/aspeed/clk_ast2500.c | 265 >> > > ++++++++++++++++++++++--- >> > > > include/dt-bindings/clock/ast2500-scu.h | 2 + >> > > > 4 files changed, 304 insertions(+), 33 deletions(-) >> > > > >> > > > diff --git a/arch/arm/dts/ast2500-u-boot.dtsi >> > > b/arch/arm/dts/ast2500-u-boot.dtsi >> > > > index faeeec1be4..f826646095 100644 >> > > > --- a/arch/arm/dts/ast2500-u-boot.dtsi >> > > > +++ b/arch/arm/dts/ast2500-u-boot.dtsi >> > > > @@ -61,3 +61,11 @@ >> > > > }; >> > > > }; >> > > > }; >> > > > + >> > > > +&mac0 { >> > > > + clocks = <&scu PCLK_MAC1>, <&scu PLL_D2PLL>; >> > > > +}; >> > > > + >> > > > +&mac1 { >> > > > + clocks = <&scu PCLK_MAC2>, <&scu PLL_D2PLL>; >> > > > +}; >> > > >> > > Why is this here and not in the main dts file? The -u-boot.dtsi is >> > > for >> > > stuff that's not appropriate in the upstream dts file. Thanks! >> > >> > There is no clock driver for this part in mainline Linux Kernel yet and >> > I >> > don't know how it will end up being configured. I suspect that they >> > might >> > not use the same bindings though. >> > >> > Should I put this into board specific dts? >> >> So this applies to a lot of parts of the series here. What we don't >> want to do is have places where the DTS here diverges from the Linux >> kernel DTS and we don't reconcile them. If the relevant Linux drivers >> are not in mainline, are they at least in linux-next or otherwise >> submitted to the relevant subtrees? > > > No, as far as I know, maybe Rick (cc'ed) knows what is the plan there. > > I'm not really working on the linux driver and it's outside of my control. >
Looks like the Aspeed SDK version of U-Boot was configuring D2PLL as part of platform_g5.S (https://github.com/openbmc/u-boot/blob/v2016.07-aspeed-openbmc/arch/arm/mach-aspeed/platform_g5.S). OpenBMC kernel doesn't seem to have any clock drivers for these PLLs. I assume that since they were enabled by U-Boot, the ftgmac100 driver doesn't need to do anything for it to work. It should be straightforward to follow the pattern of the other clock drivers in https://github.com/openbmc/linux/blob/dev-4.7/arch/arm/boot/dts/aspeed-g5.dtsi and create a new driver for D2PLL. > I can change network driver, so that it does not use this DT configuration > and either hard code clock config into it, or configure it's clocks in board > specific file -- would that be more acceptable? > >> >> >> -- >> Tom > > > > > -- > Maxim Sloyko _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot