[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
was disabled.

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[0] 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 mailing list