[U-Boot] [PATCH 5/5] arm: socfpga: implement proper peripheral reset

[Marek Vasut]

On 1/27/19 9:56 AM, Simon Goldschmidt wrote:
> Am 26.01.2019 um 10:00 schrieb Marek Vasut:
>> On 1/25/19 9:30 PM, Simon Goldschmidt wrote:
>>> This commit removes ad-hoc reset handling for peripheral resets from SPL
>>> for socfpga gen5.
>>>
>>> This is done because as U-Boot drivers support reset handling by now.
>>>
>>> For kernels that don't support taking peripherals out of reset that are
>>> not enabled by U-Boot, a new Kconfig option "OLD_SOCFPGA_KERNEL_COMPAT"
>>> is added, which keeps the old behaviour of just enabling all
>>> peripherals.
>>>
>>> This new option is enabled by default for now, as even Linux 4.20 does
>>> not support reset handling on all peripherals.
>>>
>>> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>
>>
>> Well ew, don't we have some pre-linux-boot hook which could just flip
>> the reset register bits in one place ? And also, I'd prefer this to be
>> runtime-configurable, not compile-time configurable.
> 
> 
> And this will be the biggest change for v2. It's also why I needed so
> long to send this series. What I sent in this version is how Tom said
> the same thing is being handled for mach-sunxi (Kconfig
> "OLD_SUNXI_KERNEL_COMPAT").
> 
> So if I remember your last mails about this topic, you'd prefer an
> environment variable with a callback that leads to enabling all
> peripherals just before jumping to Linux (yes, I'll find a hook for that).

Rather, I'd prefer some .remove() code in the SoCFPGA reset driver which
would check an environment variable to determine whether it should
ungate the resets before booting Linux or not.

> I see two problems here:
> - enabling all peripherals will need to be the default for some time,
> until Linux supports reset handling in all drivers. How do you want to
> deal with that?

Set the env variable to default=1 for all socfpga boards ?

> - is this scheme used somewhere else for compatibility? I think it would
> make sense for multiple architectures to use the same way to handle such
> compatibility issues...

I don't think so, however it's better than compile-time setting.

[...]

-- 
Best regards,
Marek Vasut