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>
 <CAGngYiXGXDqCZeJme026uz5FjU56UojmQFFiJ5_CZ_AywdQiEw@mail.gmail.com>
 <AM6PR0402MB360781DA3F738C2DF445E821FF680@AM6PR0402MB3607.eurprd04.prod.outlook.com>
 <CAGngYiWc8rNVEPC-8GK1yH4zXx7tgR9gseYaopu9GWDnSG1oyg@mail.gmail.com>
 <AM6PR0402MB36073F63D2DE2646B4F71081FF690@AM6PR0402MB3607.eurprd04.prod.outlook.com>
 <CAOMZO5ATv9o197pH4O-7DV-ftsP7gGVuF1+r-sGd2j44x+n-Ug@mail.gmail.com>
 <CAGngYiVeNQits4CXiXmN2ZBWyoN32zqUYtaxKCqwtKztm-Ky8A@mail.gmail.com>
 <CAGngYiX9Hx413BX-rgaaUjD9umS9hGg=gMLbM+QmdyEt2Nut5A@mail.gmail.com> <AM6PR0402MB36078DBF3B7737B1C3F032AAFF660@AM6PR0402MB3607.eurprd04.prod.outlook.com>
In-Reply-To: <AM6PR0402MB36078DBF3B7737B1C3F032AAFF660@AM6PR0402MB3607.eurprd04.prod.outlook.com>
From:   Sven Van Asbroeck <thesven73@gmail.com>
Date:   Tue, 7 Jul 2020 11:21:01 -0400
Message-ID: <CAGngYiU7HEyZXYN4GxM=w83g1O-NVsmSwvPrbeY6=UxSUW8vCg@mail.gmail.com>
Subject: Re: [EXT] Re: [PATCH v5 3/3] ARM: imx6plus: optionally enable
 internal routing of clk_enet_ref
To:     Andy Duan <fugang.duan@nxp.com>
Cc:     Fabio Estevam <festevam@gmail.com>,
        Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        dl-linux-imx <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>,
        Michael Turquette <mturquette@baylibre.com>,
        linux-clk@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Andy, Fabio,

Sounds like we now have a solution which makes logical sense, although it
requires changes and additions to drivers/clk/imx/. Before I create a patch,
can you read the plan below and check that it makes sense, please?

Problem
=======
On the imx6q plus, the NXP hw designers introduced an alternative way to clock
the built-in ethernet (FEC). One single customer (archronix) seems to be
currently using this functionality, and would like to add mainline support.

Changing the ethernet (FEC) driver appears illogical, as this change is
unrelated to the FEC itself: fundamentally, it's a clock tree change.

We also need to prevent breaking existing boards with mis-configured FEC
clocking:

Some board designers indicate in the devicetree that ENET_REF_CLK is connected
to the FEC ptp clock, but in reality, they are providing an unrelated external
clock through the pad. This will work in many cases, because the FEC driver
does not really care where its PTP clock comes from, and the enet ref clock is
set up to mirror the external clk frequency by the NXP U-Boot fork.

Proposed changes must not break these cases.

Proposed Solution
=================
On non-plus imx6q there are no changes. On imx6q plus however:

Create two new clocks (mac_gtx and pad) and a new clock mux:

  enet_ref-o--------->pad----->| \
           |                   |  |
           |                   |M1|----mac_gtx --- to FEC
           |                   |  |
           o-------------------|_/

The defaults (indicated with ">") are carefully chosen, so these changes will
not break any existing plus designs.

We then tie the gtx clock to the FEC driver ptp clock, like so:

in imx6qp.dtsi:
&fec {
    clocks = <&clks IMX6QDL_CLK_ENET>,
        <&clks IMX6QDL_CLK_ENET>,
        <&clks IMX6QDL_CLK_MAC_GTX>;
};

Mux M1 is controlled by GPR5[9]. This mux can just write to the GPR5 memory
address. However, the GPR registers are already exposed as a mux controller
compatible = "mmio-mux". This mux does currently not use GPR5.

So we have to make a choice here: write straight to the memory address (easy),
or create a new clock mux type, which uses an underlying mux controller.

When that is done, board designers can choose between:

1. internal clocking (GTX clock routed internally)

&fec {
    assigned-clocks = <&clks IMX6QDL_CLK_MAC_GTX>;
    assigned-clock-parents = <&clks IMX6QDL_CLK_ENET_REF>;
};

2. external clocking (GTX clock from pad, pad connected to enet_ref,
   typically via GPIO_16). This is the default and does not need to be present.

&fec {
    assigned-clocks = <&clks IMX6QDL_CLK_MAC_GTX>;
    assigned-clock-parents = <&clks IMX6QDL_CLK_PAD>;
};


3. external clocking (GTX clock from pad, pad connected to external PHY
   clock or external oscillator).

phy_osc: oscillator {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <50000000>;
};

&fec {
    clocks = <&clks IMX6QDL_CLK_ENET>,
        <&clks IMX6QDL_CLK_ENET>,
        <&phy_osc>;
};