Am 16.01.19 um 15:37 schrieb Gregory CLEMENT:
Hi Daniel,
On mer., janv. 16 2019, Daniel Schwierzeck daniel.schwierzeck@gmail.com wrote:
Am 16.01.19 um 14:07 schrieb Gregory CLEMENT:
On some ocelots platform a workaround is needed in order to be able to reset the switch without resetting the DDR.
Signed-off-by: Gregory CLEMENT gregory.clement@bootlin.com
board/mscc/ocelot/ocelot.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+)
diff --git a/board/mscc/ocelot/ocelot.c b/board/mscc/ocelot/ocelot.c index 0f7a532158..77ebe8ae26 100644 --- a/board/mscc/ocelot/ocelot.c +++ b/board/mscc/ocelot/ocelot.c @@ -10,6 +10,7 @@ #include <environment.h> #include <spi.h> #include <led.h> +#include <wait_bit.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -18,6 +19,31 @@ enum { BOARD_TYPE_PCB123, };
+void mscc_switch_reset(bool enter) +{
- u32 reg, count = 0;
- /* Nasty workaround to avoid GPIO19 (DDR!) being reset */
- mscc_gpio_set_alternate(19, 2);
- debug("applying SwC reset\n");
- writel(ICPU_RESET_CORE_RST_PROTECT, BASE_CFG + ICPU_RESET);
- writel(PERF_SOFT_RST_SOFT_CHIP_RST, BASE_DEVCPU_GCB + PERF_SOFT_RST);
- if (wait_for_bit_le32(BASE_DEVCPU_GCB + PERF_SOFT_RST,
PERF_SOFT_RST_SOFT_CHIP_RST, false, 5000, false))pr_err("Tiemout while waiting for switch reset\n");- /*
* Reset GPIO19 mode back as regular GPIO, output, high (DDR* not reset) (Order is important)*/- setbits_le32(BASE_DEVCPU_GCB + PERF_GPIO_OE, BIT(19));
- writel(BIT(19), BASE_DEVCPU_GCB + PERF_GPIO_OUT_SET);
- mscc_gpio_set_alternate(19, 0);
have you thought about or maybe planned a reset controller driver?
Actually, here it is not a reset driver, it is just the workaround part of the stop() function in the network driver. It is not about resetting the whole platform, for this feature a driver already has been submited.
understood, there is nothing wrong with the patch. I only imagine that such logic would better fit in a reset controller driver which only exports reset domains (I didn't mean the sysreset driver). But I see that the Linux driver also manually toggles the reset bits but at least the register accesses are wrapped via syscon/regmap. Maybe it makes sense to add a syscon driver for U-Boot too in the future?