linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: heiko@sntech.de (Heiko Stübner)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL 1/3] rockchip soc changes for 4.5
Date: Tue, 08 Mar 2016 01:50:50 +0100	[thread overview]
Message-ID: <3859490.BDucKaOEBr@diego> (raw)
In-Reply-To: <CAD=FV=Wr0f6d=tJCCfQa59pNDe1PEj44hdqCKFKricYdv7D+0w@mail.gmail.com>

Am Montag, 7. M?rz 2016, 16:46:04 schrieb Doug Anderson:
> On Fri, Dec 11, 2015 at 4:57 PM, Heiko St?bner <heiko@sntech.de> wrote:
> > Hi Arnd,
> > 
> > Am Samstag, 12. Dezember 2015, 01:30:17 schrieb Arnd Bergmann:
> >> On Saturday 05 December 2015 01:53:38 Heiko St?bner 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 "just"
> > 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 this.
> > 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 nothing
> > 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 bind
> > to it. So I guess we could do something like:
> > 
> > 
> > timer at 200440a0 {
> > 
> >         compatible = "rockchip,arch-timer-supply";
> >         reg = <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 needed.

So if nobody shouts (and does the needed work), I intend to just let it drop.


Heiko

  reply	other threads:[~2016-03-08  0:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-05  0:53 [GIT PULL 1/3] rockchip soc changes for 4.5 Heiko Stübner
2015-12-05  0:56 ` [GIT PULL 2/3] rockchip dts32 " Heiko Stübner
2015-12-11 23:27   ` Arnd Bergmann
2015-12-05  0:58 ` [GIT PULL 3/3] rockchip dts64 " Heiko Stübner
2015-12-11 23:59   ` Arnd Bergmann
2015-12-12  0:30 ` [GIT PULL 1/3] rockchip soc " Arnd Bergmann
2015-12-12  0:57   ` Heiko Stübner
2016-03-08  0:46     ` Doug Anderson
2016-03-08  0:50       ` Heiko Stübner [this message]
2016-03-08  1:19         ` Doug Anderson
  -- strict thread matches above, loose matches on Subject: below --
2015-12-21  1:21 Heiko Stübner
2015-12-22 21:06 ` Olof Johansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3859490.BDucKaOEBr@diego \
    --to=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).