[Letux-kernel] ARM: OMAP2+: reset controller support
H. Nikolaus Schaller
hns at goldelico.com
Tue Nov 1 22:38:02 CET 2016
>> If possible, I would prefer just to take your reset-controller as
>> a temporary solution, because we don't have a platform driver any
>> more or it will become a really ugly hack.
> Yeah, I think that would most likely work also.
>> What I have tried to so far is:
>> 1. applied to v4.3:
>> - works well (or at least not recognizably different)
>> - device boots
>> 2. rebased to v4.9-rc2:
>> - needed some manual rebase which I hope I have done correctly.
>> - also needs some fixes for "new" SoC which interfere.
>> - But OMAP3 hangs at "Starting kernel...".
> Try enabling following kernel config options:
> CONFIG_DEBUG_OMAP3UART3=y /* assuming your board uses UART3 for serial console */
> ... and append 'earlyprintk' to your kernel command line. This should give you more info of what is happening.
I had thought all this were enabled. But for some reason EARLY_PRINTK
Thanks for reminding to check!
Now I get a better stack trace and that it ends in a kernel panic.
I have worked through the call chain and what fails is that
of_reset_control_get() inside _init_resets() returns -EBUSY.
This triggers the cleanup which leaves the reset thing partially (?)
initialized and makes it finally panic after some steps (NULL pointer
dereference in _setup()).
The reason for -EBUSY is in __reset_control_get() in drivers/reset/core.c.
This code didn't exist in 4.3 and here we have the first answer why it
worked back then and now fails so severely in 4.9-rc2.
To me it appears as if there was added a new refcnt system for reset
controllers and a flag which allows them to be shared or not. If not
shared, an attempt to call __reset_control_get() a second time is
rejected with -EBUSY.
This takes not only into account the rcdev but also the index. So
different indexes may be used.
What is not clear to me is why __reset_control_get() is called twice.
It seems to have something to do with the - also new - rcdev->of_xlate()
called inside __of_reset_control_get(). By default it does some "simple
translation" through of_reset_simple_xlate().
This appears to take the first #reset-cell to distinguish reset controllers
and translate into some index. This seems to fail.
What I don't know yet is how to cure this. Currently I see two approaches.
1. make reset controllers shared to avoid the -EBUSY state (which was
probably the default in 4.3)
This would mean to replace of_reset_control_get()
in your patches by of_reset_control_get_shared().
2. find out why they are tried to be shared at all (which should not
happen if of_reset_control_get() is used). Maybe we must write our
own rcdev->of_xlate to do it better than of_reset_simple_xlate()?
>> What I am also not sure (also in case of platform driver) is which register carries the SGX_RST.
>> TRM mentions it:
>> "Software controls the release of SGX_RST using the PRCM.RM_RSTCTRL_SGX SGX_RST bit."
> Hmm, that seems to be the case. RSTCTRL registers on omap3 are usually at offset 0x50 so my guess is that the register address would be 0x48306b50.
I have cross-checked and at least for the IVA there is a reset register
at 0x50 while the status is at 0x58 (like for SGX). Interestingly other
resets aren't documented as well (e.g. NEON).
BR and thanks,
More information about the Letux-kernel