Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200702175352.19223-1-TheSven73@gmail.com> <20200702175352.19223-3-TheSven73@gmail.com>
 <CAOMZO5DxUeXH8ZYxmKynA7xO3uF6SP_Kt-g=8MPgsF7tqkRvAA@mail.gmail.com>
In-Reply-To: <CAOMZO5DxUeXH8ZYxmKynA7xO3uF6SP_Kt-g=8MPgsF7tqkRvAA@mail.gmail.com>
From:   Sven Van Asbroeck <thesven73@gmail.com>
Date:   Sat, 4 Jul 2020 10:08:42 -0400
Message-ID: <CAGngYiXGXDqCZeJme026uz5FjU56UojmQFFiJ5_CZ_AywdQiEw@mail.gmail.com>
Subject: Re: [PATCH v5 3/3] ARM: imx6plus: optionally enable internal routing
 of clk_enet_ref
To:     Fabio Estevam <festevam@gmail.com>
Cc:     Shawn Guo <shawnguo@kernel.org>, Fugang Duan <fugang.duan@nxp.com>,
        Rob Herring <robh+dt@kernel.org>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        netdev <netdev@vger.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        NXP Linux Team <linux-imx@nxp.com>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Fabio, Andy,

On Thu, Jul 2, 2020 at 6:29 PM Fabio Estevam <festevam@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.

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.