From: Andy Duan <fugang.duan@nxp.com>
To: Sven Van Asbroeck <thesven73@gmail.com>,
Fabio Estevam <festevam@gmail.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, netdev <netdev@vger.kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
linux-kernel <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
dl-linux-imx <linux-imx@nxp.com>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Jakub Kicinski <kuba@kernel.org>, Shawn Guo <shawnguo@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>
Subject: RE: [EXT] Re: [PATCH v5 3/3] ARM: imx6plus: optionally enable internal routing of clk_enet_ref
Date: Sun, 5 Jul 2020 14:45:02 +0000 [thread overview]
Message-ID: <AM6PR0402MB360781DA3F738C2DF445E821FF680@AM6PR0402MB3607.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <CAGngYiXGXDqCZeJme026uz5FjU56UojmQFFiJ5_CZ_AywdQiEw@mail.gmail.com>
From: Sven Van Asbroeck <thesven73@gmail.com>
> 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.
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-07-05 14:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-02 17:53 [PATCH v5 1/3] ARM: imx: mach-imx6q: Search for fsl, imx6q-iomuxc-gpr earlier Sven Van Asbroeck
2020-07-02 17:53 ` [PATCH v5 2/3] dt-bindings: fec: add fsl, ptpclk-bypass-pad boolean property Sven Van Asbroeck
2020-07-02 17:53 ` [PATCH v5 3/3] ARM: imx6plus: optionally enable internal routing of clk_enet_ref Sven Van Asbroeck
2020-07-02 22:29 ` Fabio Estevam
2020-07-03 0:50 ` Sven Van Asbroeck
2020-07-03 2:01 ` [EXT] " Andy Duan
2020-07-04 14:08 ` Sven Van Asbroeck
2020-07-05 14:45 ` Andy Duan [this message]
2020-07-05 15:34 ` [EXT] " Sven Van Asbroeck
2020-07-06 5:30 ` Andy Duan
2020-07-06 13:46 ` Fabio Estevam
2020-07-06 14:58 ` Sven Van Asbroeck
2020-07-06 14:59 ` Sven Van Asbroeck
2020-07-07 3:38 ` Andy Duan
2020-07-07 15:21 ` Sven Van Asbroeck
2020-07-08 5:16 ` Andy Duan
2020-07-06 14:53 ` Sven Van Asbroeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AM6PR0402MB360781DA3F738C2DF445E821FF680@AM6PR0402MB3607.eurprd04.prod.outlook.com \
--to=fugang.duan@nxp.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=thesven73@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).