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. 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 > -- *M*axim *S*loyko _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot