[Letux-kernel] ARM: OMAP2+: reset controller support

H. Nikolaus Schaller hns at goldelico.com
Tue Nov 1 22:38:02 CET 2016


Hi,

>> 
>> 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_LL=y
> CONFIG_DEBUG_OMAP3UART3=y /* assuming your board uses UART3 for serial console */
> CONFIG_EARLY_PRINTK=y
> 
> ... 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,
Nikolaus



More information about the Letux-kernel mailing list