On 1/14/21 6:08 PM, Alexandre TORGUE wrote:

Hi Marek

Hi,

On 1/6/21 9:43 PM, Marek Vasut wrote:

quoted

The implementation of ETH_RX_CLK/ETH_REF_CLK handling currently does not
permit selecting the clock input from SoC pad. To make things worse, the
implementation of this is partly present and is split between the clock
driver and dwmac4 driver. Moreover, the ETHRX clock parent is incorrect.

Sorry but I don't understand which configuration is missing. I think we 
can handle all possible cases for RMII. At the glue layer 
(dwmac-stm32.c) clocks gates and syscfg are set regarding device tree 
binding (see the tab in dwmac-stm32.c). You could have a look here for 
more details: 
https://wiki.st.com/stm32mpu/wiki/Ethernet_device_tree_configuration

Regarding the clock parent, yes it is not at the well frequency if you 
want to select this path. Our current "clock tree" is done to fit with 
our ST reference boards (we have more peripherals than PLL outputs so we 
have to make choices). So yes for customer/partners boards this clock 
tree has to be modified to better fit with the need (either using 
assigned-clock-parent or by modifying bootloader clock tree (tf-a or 
u-boot)).

I don't think you handle all the configuration options, but I might also 
be confused.

See Figure 83. Peripheral clock distribution for Ethernet in the MP1 
datasheet for the below.

The current setup I have needs 50 MHz on SoC pad PA1 to drive the PHY 
clock, and uses eth_clk_fb to supply ETH_RX_CLK. However, the 50 MHz is 
sourced directly from PLL4P, which then has to run at 50 MHz and that in 
turn reduces clock frequency for other blocks connected to PLL4P (e.g. 
SDMMC, where the impact is noticable).

So, what I want to model here is this:

PLL4P = 100 MHz
MCO2 is supplied by PLL4P and set to /2 , so MCO2 = 50 MHz
SoC pad PG2 is set as MCO2 output, thus a source of 50 MHz signal
SoC pad PA1 is set as ETH_RX_CLK and connected to PG2

This works fine in practice, except it cannot be modeled using current 
DT bindings, even though it should be possible to model it.

quoted

First, the ETHRX clock in clk-stm32mp1.c only represents the ETHRXEN 
gate,
however it should represent also ETH_REF_CLK_SEL mux. The problem is that
the ETH_REF_CLK_SEL mux is currently configured in the DWMAC4 driver and
the ETH_REF_CLK_SEL bit is part of SYSCFG block, not the DWMAC4 or the
clock block.

dwmac4-stm32 doesn't contain code for dwmac4 but it contains the glue 
around the dwmac4: syscfg, clocks ...

The problem is that dwmac4-stm32 isn't the right place to configure the 
ETHRX clock mux, that should be in the clock driver. So the stm32 clock 
driver should have SYSCFG handle and configure ETH_REF_CLK_SEL mux. The 
"st,eth-ref-clk-sel" DT prop would then not be needed at all, as the 
reference clock select would be configured using assigned-clocks in DT.

The default assigned-clocks should be eth_clk_fb , but the user can 
override it in the DT and provide another clock source (e.g. in my case, 
that would be PLL4P->MCO2->ETHRX).

quoted

Second, the ETHRX parent clock is either eth_clk_fb (ETHCK_K) or external
ETH_RX_CLK/ETH_REF_CLK_SEL, it is never CK_AXI.

Why CK_AXI ?

See drivers/clk/clk-stm32mp1.c:
   1895          PCLK(ETHRX, "ethrx", "ck_axi", 0, G_ETHRX),

[...]

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