[U-Boot] [PATCH 13/17] aspeed: Add support for Clocks needed by MACs

[Maxim Sloyko]

On Mon, Mar 20, 2017 at 12:48 PM, Tom Rini <trini at konsulko.com> wrote:
>
> On Mon, Mar 20, 2017 at 10:52:12AM -0700, Maxim Sloyko wrote:
> > On Mon, Mar 20, 2017 at 10:30 AM, Tom Rini <trini at 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 <trini at 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 <maxims at 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?
>
> For all the cases where you don't have the DT portion itself upstream
> yet, go with platdata instead for now.  Unless I'm mis-recalling things
> that is.


Sorry, I don't quite follow.

My understanding is that platdata is supposed to be used as a
substitute for DT nodes, but in this case there is a node for MAC
present in upstream linux device tree, it's just that one specific
option that needs to be different. Is there an overwrite mechanism
that is platdata based?

What I was thinking about is changing the driver so that instead of
reading the clock configuration from DT it would use clock ids based
on device's sequence number, i.e. mac0 would use PCLK_MAC0, mac1 would
use PCLK_MAC1. Same for I2C.

>
>
> --
> Tom




-- 
Maxim Sloyko