From: Sven Van Asbroeck <thesve...@gmail.com> > Hi Fabio, Andy, > > On Thu, Jul 2, 2020 at 6:29 PM Fabio Estevam <feste...@gmail.com> wrote: > > > > With the device tree approach, I think that a better place to touch > > GPR5 would be inside the fec driver. > > > > Are we 100% sure this is the best way forward, though? > > All the FEC driver should care about is the FEC logic block inside the SoC. It > should not concern itself with the way a SoC happens to bring a clock (PTP > clock) to the input of the FEC logic block - that is purely a SoC > implementation > detail.
I also agree with that relates to SOC integration. > > It makes sense to add fsl,stop-mode (= a GPR bit) to the FEC driver, as this > bit > is a logic input to the FEC block, which the driver needs to dynamically flip. > > But the PTP clock is different, because it's statically routed by the SoC. > > Maybe this problem needs a clock routing solution? > Isn't there an imx6q plus clock mux we're not modelling? > > enet_ref-o------>ext>---pad_clk--| \ > | |M |----fec_ptp_clk > o-----------------------|_/ > > Where M = mux controlled by GPR5[9] > > The issue here is that pad_clk is routed externally, so its parent could be > any > internal or external clock. I have no idea how to model this in the clock > framework. Don't consider it complex, GPR5[9] just select the rgmii gtx source from PAD or internal Likeļ¼ GPR5[9] is cleared: PAD -> MAC gtx GPR5[9] is set: Pll_enet -> MAC gtx As you said, register one clock mux for the selection, assign the clock parent by board dts file, but now current clock driver doesn't support GPR clock.
