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

H. Nikolaus Schaller hns at goldelico.com
Mon Oct 31 22:03:27 CET 2016


> Am 31.10.2016 um 18:06 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi Tero,
> 
>> Am 31.10.2016 um 13:57 schrieb Tero Kristo <t-kristo at ti.com>:
>> 
>> On 29/10/16 12:30, H. Nikolaus Schaller wrote:
>>> Hi,
>>> I am trying to fix some parts in the OMAP3 SGX drivers for the latest kernels
>>> and came across the problem that the reset framework core is now assuming DT
>>> support. This means we need some reset controller driver for the OMAP3.
>>> 
>>> Then I found your patch series "[PATCH 00/17] ARM: OMAP2+: reset controller support"
>>> from last year and it appears to be the missing piece.
>>> 
>>> I have not found it in linux-next so I wonder what happened to it.
>> 
>> The old reset controller work was abandoned,
> 
> Ah, I see.
> 
> Indeed it makes not much sense to just handle the reset-controller but
> not other hwmods.
> 
>> and it won't be resurrected before we have:
>> 
>> a) hwmod clock driver merged (which is under reviews atm)
>> b) OMAP interconnect driver merged (which is under work by Tony)
> 
> This might take more time than I want to wait.
> 
>> 
>> I believe you need to introduce platform data callbacks for reset handling until this is resolved, and call hwmod reset functionality directly.
> 
> 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.
> 
> 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...".
> 	- bisect shows that "ARM: OMAP2+: hwmod: parse reset information from DT" triggers the problem.
> 	- I can make the kernel boot if I return 0 by _init_resets() - but then of course the resets
> 	  don't work well and report "missing rc".

I have a new finding:

there appears to be no patch to fix arch/arm/mach-omap2/omap_hwmod_3xxx_data.c similar to "ARM: OMAP24xx: hwmod: remove reset data from hwmod database"

The result is that oh->rst_lines is already initialized by static structs and overwritten by potentially conflicting DT contents.

But I have no idea why it works for v4.3 and no longer for v4.9-rc2. It may just be good luck. Or different DT processing sequence.

> 
> 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."
> 
> but does not tell the register address or bit number. But maybe I can locate that in some older
> TI kernel or SGX driver.
> 
> And I think I have to add the proper resets = <&prm ...> values which are not really well
> documented, but I think I understand them.
> 
> Anyways if you want to take a look into my attempt to rebase:
> 
> 	https://github.com/goldelico/gta04-kernel/commits/work/test/omap/reset-cont-v4.9
> 
> BR and thanks,
> Nikolaus
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel



More information about the Letux-kernel mailing list