All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven Van Asbroeck <thesven73@gmail.com>
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>
Subject: Re: [PATCH v5 3/3] ARM: imx6plus: optionally enable internal routing of clk_enet_ref
Date: Sat, 4 Jul 2020 10:08:42 -0400	[thread overview]
Message-ID: <CAGngYiXGXDqCZeJme026uz5FjU56UojmQFFiJ5_CZ_AywdQiEw@mail.gmail.com> (raw)
In-Reply-To: <CAOMZO5DxUeXH8ZYxmKynA7xO3uF6SP_Kt-g=8MPgsF7tqkRvAA@mail.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.

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.

WARNING: multiple messages have this Message-ID (diff)
From: Sven Van Asbroeck <thesven73@gmail.com>
To: Fabio Estevam <festevam@gmail.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>, Fugang Duan <fugang.duan@nxp.com>,
	netdev <netdev@vger.kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	NXP Linux Team <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: [PATCH v5 3/3] ARM: imx6plus: optionally enable internal routing of clk_enet_ref
Date: Sat, 4 Jul 2020 10:08:42 -0400	[thread overview]
Message-ID: <CAGngYiXGXDqCZeJme026uz5FjU56UojmQFFiJ5_CZ_AywdQiEw@mail.gmail.com> (raw)
In-Reply-To: <CAOMZO5DxUeXH8ZYxmKynA7xO3uF6SP_Kt-g=8MPgsF7tqkRvAA@mail.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.

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2020-07-04 14:08 UTC|newest]

Thread overview: 34+ 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 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 2/3] dt-bindings: fec: add fsl, ptpclk-bypass-pad " 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 17:53   ` Sven Van Asbroeck
2020-07-02 22:29   ` Fabio Estevam
2020-07-02 22:29     ` Fabio Estevam
2020-07-03  0:50     ` Sven Van Asbroeck
2020-07-03  0:50       ` Sven Van Asbroeck
2020-07-03  2:01       ` [EXT] " Andy Duan
2020-07-03  2:01         ` Andy Duan
2020-07-04 14:08     ` Sven Van Asbroeck [this message]
2020-07-04 14:08       ` Sven Van Asbroeck
2020-07-05 14:45       ` [EXT] " Andy Duan
2020-07-05 14:45         ` Andy Duan
2020-07-05 15:34         ` Sven Van Asbroeck
2020-07-05 15:34           ` Sven Van Asbroeck
2020-07-06  5:30           ` Andy Duan
2020-07-06  5:30             ` Andy Duan
2020-07-06 13:46             ` Fabio Estevam
2020-07-06 13:46               ` Fabio Estevam
2020-07-06 14:58               ` Sven Van Asbroeck
2020-07-06 14:58                 ` Sven Van Asbroeck
2020-07-06 14:59                 ` Sven Van Asbroeck
2020-07-06 14:59                   ` Sven Van Asbroeck
2020-07-07  3:38                   ` Andy Duan
2020-07-07  3:38                     ` Andy Duan
2020-07-07 15:21                     ` Sven Van Asbroeck
2020-07-07 15:21                       ` Sven Van Asbroeck
2020-07-08  5:16                       ` Andy Duan
2020-07-08  5:16                         ` Andy Duan
2020-07-06 14:53             ` Sven Van Asbroeck
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=CAGngYiXGXDqCZeJme026uz5FjU56UojmQFFiJ5_CZ_AywdQiEw@mail.gmail.com \
    --to=thesven73@gmail.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=fugang.duan@nxp.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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.