[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