[PATCH v1] clk: microchip: mpfs: don't reset disabled peripherals

Conor.Dooley at microchip.com Conor.Dooley at microchip.com
Fri Apr 8 07:16:42 PDT 2022



On 08/04/2022 13:56, Andrew Lunn wrote:
> On Fri, Apr 08, 2022 at 01:13:53PM +0000, Conor Dooley wrote:
>> The current clock driver for PolarFire SoC puts the hardware behind
>> "periph" clocks into reset if their clock is disabled. CONFIG_PM was
>> recently added to the riscv defconfig and exposed issues caused by this
>> behaviour, where the Cadence GEM was being put into reset between its
>> bringup & the PHY bringup:
>>
>> https://lore.kernel.org/linux-riscv/9f4b057d-1985-5fd3-65c0-f944161c7792@microchip.com/
>>
>> Fix this by removing the reset enable/disable code from the driver &
>> rely (for now) on the bootloader bringing peripherals out of reset
>> during boot.
> 
> Maybe you should keep the clock enable -> disable reset part, and only
> remove the clock disable -> assert reset part. You are making the
> assumption that the bootloader disables reset on everything, when in
> fact it could only disable resets on peripherals it needs, and it
> needs the ethernet for TPTP boot.

Yeah, I made that assumption because everything supported by mainline
currently are taken out of reset by the first stage bootloader.
I will double check & make sure that this is extended to all peripherals.

> What is your long term fix? It seems like you need to add a reset
> controller. The macb already seems to support that:
> 
> macb_main.c:	/* Fully reset GEM controller at hardware level using zynqmp-reset driver,
> macb_main.c:	ret = device_reset_optional(&pdev->dev);
> 
> So once you have it, it should be easy to wire up for this
> peripheral. Once you have them all using the reset controller, you can
> then remove all the reset code from the clock driver.

Yeah, adding a reset controller is the plan.

Thanks,
Conor.


More information about the linux-riscv mailing list