From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko =?ISO-8859-1?Q?St=FCbner?= Subject: Re: [GIT PULL 1/3] rockchip soc changes for 4.5 Date: Tue, 08 Mar 2016 01:50:50 +0100 Message-ID: <3859490.BDucKaOEBr@diego> References: <1936935.FVZdWRYuBf@diego> <2125152.VIQO6FufKf@diego> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+glpar-linux-rockchip=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: Doug Anderson Cc: Arnd Bergmann , Xing Zheng , Rob Herring , "open list:ARM/Rockchip SoC..." , arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Caesar Wang List-Id: linux-rockchip.vger.kernel.org Am Montag, 7. M=E4rz 2016, 16:46:04 schrieb Doug Anderson: > On Fri, Dec 11, 2015 at 4:57 PM, Heiko St=FCbner wrote: > > Hi Arnd, > > = > > Am Samstag, 12. Dezember 2015, 01:30:17 schrieb Arnd Bergmann: > >> On Saturday 05 December 2015 01:53:38 Heiko St=FCbner wrote: > >> > SMP special case for the rk3036 and making sure the arch-timer > >> > supply is enabled, similar to the rk3288. > >> = > >> That is a rather ugly hack, I'd prefer if this could be done cleaner > >> rather than duplicated into another place. > > = > > I do agree that it is rather ugly :-) . > > = > > The general opinion seems to be, that firmware is supposed to make sure > > this timer is enabled and at the time when it got introduced the > > consensus was to not hack up the arch-timer to facilitate this and "jus= t" > > put it into the soc code for the affected cpu. > > = > > It seems like the really new rk3228 (quad-core A7 and using psci now) > > actually gets this right now, in having its firmware taking care of thi= s. > > So it looks like this hopefully won't be needed even for future arm32 > > socs. > > = > > I guess I should look at what the new and shiny mainline uboot support > > does > > for this, but I do think it might actually do it right as well. > > = > > So this is really only a hack for flaky vendor-bootloaders. > > = > > = > > Which brings me to ... > > = > >> Sorry for not seeing this earlier. Can you replace the hardcoded > >> RK3036_TIMER_PHYS and RK3288_TIMER6_7_PHYS constants with a DT > >> lookup, to make it somewhat less hacky? > > = > > I'm not really sure how that is supposed to look like. Technically noth= ing > > should ever touch that timer, as it will only make the system hang if it > > gets disabled. > > = > > We do have a binding for the timer ip block (rockchip,rk3288-timer) but= of > > course cannot use that, to make sure the regular timer driver doesn't b= ind > > to it. So I guess we could do something like: > > = > > = > > timer@200440a0 { > > = > > compatible =3D "rockchip,arch-timer-supply"; > > reg =3D <0x200440a0 0x20>; > > = > > }; > > = > > try to find this and enable it, but duplicating the hack and spreading = it > > into the dts as well somehow doesn't feel like an improvement ;-) . > > = > > But I maybe you have a nicer idea on how to do this, than me. > = > In a kernel tree drop from Rockchip I noticed that they're still > carrying around the patch "ARM: rockchip: make sure timer5 is enabled > on rk3036 platforms" as if it made it upstream, but as per this thread > it didn't. > = > Does someone have ownership resolving this? Perhaps everyone has > updated to a bootloader that avoids the need for this patch now? running on kylin, with the provided uboot sources (mainline uboot + some = patches) the rk3036 runs just fine, without that timer enablement being nee= ded. So if nobody shouts (and does the needed work), I intend to just let it dro= p. Heiko