[U-Boot] [PATCH v2 3/4] MIPS: mscc: ocelot: add switch reset support

[Daniel Schwierzeck]

Am 16.01.19 um 15:37 schrieb Gregory CLEMENT:
> Hi Daniel,
>  
>  On mer., janv. 16 2019, Daniel Schwierzeck <daniel.schwierzeck at 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 at 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?

-- 
- Daniel