Re: [PATCH v2 1/4] ARM: imx7d: add enet2 clk sel

From: Steffen Trumtrar <s.trumtrar@pengutronix.de>
To: Shawn Guo <shawnguo@kernel.org>
Cc: Fugang Duan <fugang.duan@nxp.com>,
	Rob Herring <robh+dt@kernel.org>,
	NXP Linux Team <linux-imx@nxp.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/4] ARM: imx7d: add enet2 clk sel
Date: Mon, 24 Aug 2020 11:46:47 +0200	[thread overview]
Message-ID: <87tuwsz88o.fsf@pengutronix.de> (raw)
In-Reply-To: <20200817072423.GB16951@dragon>

Hi!

Shawn Guo <shawnguo@kernel.org> writes:

> On Tue, Jul 14, 2020 at 07:11:37AM +0200, Steffen Trumtrar 
> wrote:
>> Add clock source init for the second ethernet port.
>> This changes the clock direction and clock selection in a way 
>> that the
>> ethernet phy reference clock is routed as an output.
>>
>> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
>> ---
>>  arch/arm/mach-imx/mach-imx7d.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/mach-imx/mach-imx7d.c 
>> b/arch/arm/mach-imx/mach-imx7d.c
>> index 879c35929a13..7a203f660721 100644
>> --- a/arch/arm/mach-imx/mach-imx7d.c
>> +++ b/arch/arm/mach-imx/mach-imx7d.c
>> @@ -65,6 +65,9 @@ static void __init imx7d_enet_clk_sel(void)
>>  	if (!IS_ERR(gpr)) {
>>  		regmap_update_bits(gpr, IOMUXC_GPR1, 
>>  IMX7D_GPR1_ENET_TX_CLK_SEL_MASK, 0);
>>  		regmap_update_bits(gpr, IOMUXC_GPR1, 
>>  IMX7D_GPR1_ENET_CLK_DIR_MASK, 0);
>> +		regmap_update_bits(gpr, IOMUXC_GPR1, 
>> IMX7D_GPR1_ENET2_TX_CLK_SEL_MASK, 0);
>> +		regmap_update_bits(gpr, IOMUXC_GPR1, 
>> IMX7D_GPR1_ENET2_CLK_DIR_MASK,
>> +				   IMX7D_GPR1_ENET2_CLK_DIR_MASK);
>
> I would like to see such code get removed from machine code 
> rather than
> added.  Can we deal with these IOMUXC_GPR bits in some driver 
> code?
>

My comment got lost in the v2:

   I know, that this is not a "good solution", but I don't know 
   how we can
   handle this in a better way. Open for suggestions.

Of course, putting it in the machine code is suboptimal. If anyone 
has a good idea where the 4 gpr1 calls should go without producing 
a massive complexity overhead, please share.

Best regards,
Steffen

--
Pengutronix e.K.                | Dipl.-Inform. Steffen Trumtrar |
Steuerwalder Str. 21            | https://www.pengutronix.de/    |
31137 Hildesheim, Germany       | Phone: +49-5121-206917-0       |
Amtsgericht Hildesheim, HRA 2686| Fax:   +49-5121-206917-5555    |

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