Messages in this thread | | | Subject | Re: [PATCH] Revert "reset: microchip-sparx5: allow building as a module" | From | Steen Hegelund <> | Date | Wed, 13 Jul 2022 11:40:14 +0200 |
| |
Hi Michael,
I am afraid that the exact list of affected modules is not available, so using the RESET_PROT_STAT.SYS_RST_PROT_VCORE bit is the best known way of resetting as much as possible, and still continue execution.
This is what the Sparx5 datasheet has to say about the SYS_RST_PROT_VCORE protect bit:
The device can be soft-reset by writing SOFT_RST.SOFT_CHIP_RST. The VCore system and CPU can be protected from a device soft-reset by writing RESET_PROT_STAT.SYS_RST_PROT_VCORE = 1 before initiating soft-reset.
In this case, a chip-level soft reset is applied to all other blocks except the VCore system and the VCore CPU. When protecting the VCore system and CPU from a soft reset, the frame DMA must be disabled prior to a chip-level soft reset. The SERDES and PLL blocks can be protected from reset by writing to SOFT_RST.SOFT_SWC_RST instead of SOFT_CHIP_RST.
The VCore general purpose registers (CPU::GPR) and GPIO alternate modes (DEVCPU_GCB::GPIO_ALT) are not affected by a soft-reset. These registers are only reset when an external reset is asserted.
BR Steen
On Wed, 2022-07-13 at 11:03 +0200, Michael Walle wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > [+ Claudiu, Kavyasree ] > Am 2022-07-13 10:40, schrieb Philipp Zabel: > > This reverts commit b6b9585876da018bdde2d5f15d206a689c0d70f3. > > > > This breaks MDIO on kswitch-d10, presumably because the global switch > > reset is not released early enough anymore. > > > > Reported-by: Michael Walle <michael@walle.cc> > > Cc: Clément Léger <clement.leger@bootlin.com> > > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> > > Thanks! > > Tested-by: Michael Walle <michael@walle.cc> > > And maybe Microchip can chime in here and tell us what > subsystems in the SoC will actually be reset by this. > I fear this reset will affect almost every part of the > SoC. So it would have to be bound to every single > device? Or maybe adding that reset to the switch driver > was a mistake in the first place? > > I mean, if it wouldn't be for the guard bit, it would > also reset the CPU core.. > > -michael
| |