From: Tomasz Figa <tomasz.figa@gmail.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Sachin Kamat <sachin.kamat@linaro.org>,
Tomasz Figa <t.figa@samsung.com>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
Kukjin Kim <kgene.kim@samsung.com>,
Tushar Behera <tushar.behera@linaro.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Russell King <rmk+kernel@arm.linux.org.uk>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Gregory CLEMENT <gregory.clement@free-electrons.com>,
Jason Cooper <jason@lakedaemon.net>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>
Subject: Re: [PATCH 1/1] ARM: EXYNOS: Initialize L2x0 cache controller for Exynos4 only
Date: Thu, 14 Nov 2013 01:41:29 +0100 [thread overview]
Message-ID: <2638150.ifpQGYh5Gk@flatron> (raw)
In-Reply-To: <20131025134852.GA10286@mudshark.cambridge.arm.com>
Hi Will,
On Friday 25 of October 2013 14:48:52 Will Deacon wrote:
> On Sat, Oct 19, 2013 at 03:04:22PM +0100, Tomasz Figa wrote:
> > On Saturday 19 of October 2013 18:09:15 Sachin Kamat wrote:
> > > Hi Tomasz,
> > >
> > > On 17 October 2013 18:35, Tomasz Figa <t.figa@samsung.com> wrote:
> > > > Hi Sachin,
> > > >
> > > > On Thursday 17 of October 2013 17:33:12 Sachin Kamat wrote:
> > > >> L2x0 cache controller is present only in Cortex-A9 based Exynos4 SoCs.
> > > >> Thus move this function to Exynos4 early init call to avoid non-Exynos4
> > > >> SoCs from calling this function in multi-platform support.
> > > >
> > > > I believe that at the time .init_early() is called there is no ioremap()
> > > > infrastructure working yet and so L2 cache initialization which needs
> > > > it will cause a kernel panic. This patch worked only because currently
> > > > there is no L2X0 controller defined in device tree sources of Exynos 4.
> > >
> > > It is not clear to me as to why device tree entry is required for this
> > > to work in current form
> > > as we call the L2X0 init function explicitly.
> >
> > L2x0 controller is just another IP block on the SoC. In addition its
> > registers are memory mapped and the driver needs some way to get their
> > location. The function being called explicitly simply scans device tree
> > for applicable node and performs rest of the setup only if it finds one.
> >
> > Ideally there should be no need to call this function explicitly, as it
> > should be called by some code based on presence of applicable device tree
> > node.
>
> It's a nice idea, but you need to be careful if you start deferring this
> stuff. Aside from the potential performance loss during early boot, I'm not
> even sure that the l2x0_init function is safe to run with IRQs enabled.
>
> Will
I just realised that I have not replied to your message, sorry for that.
So, my intention was not deferring this, but rather making this more
generic. In case of Exynos, we call l2x0_of_init() from an early_initcall
which is long time already after enabling interrupts, but still before
SMP is initialized.
My idea was to create a generic early_initcall in arch/arm/mm/cache-l2x0.c
that would scan DT for applicable node, parse aux_val and aux_mask from
such node (if found) and then initialize L2X0 without any need for
having platform-specific code.
However my concern here is whether on some platforms such platform code
wouldn't be needed anyway. Unfortunately I don't really know enough
about L2X0 to be able to answer this myself, at least at the moment.
Best regards,
Tomasz
next prev parent reply other threads:[~2013-11-14 0:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-17 12:03 [PATCH 1/1] ARM: EXYNOS: Initialize L2x0 cache controller for Exynos4 only Sachin Kamat
2013-10-17 12:54 ` Yadwinder Singh Brar
2013-10-17 13:05 ` Tomasz Figa
2013-10-19 12:39 ` Sachin Kamat
2013-10-19 14:04 ` Tomasz Figa
2013-10-25 13:48 ` Will Deacon
2013-11-14 0:41 ` Tomasz Figa [this message]
2013-11-14 0:50 ` Rob Herring
2013-11-14 1:07 ` Tomasz Figa
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=2638150.ifpQGYh5Gk@flatron \
--to=tomasz.figa@gmail.com \
--cc=Catalin.Marinas@arm.com \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=kgene.kim@samsung.com \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=rmk+kernel@arm.linux.org.uk \
--cc=rob.herring@calxeda.com \
--cc=sachin.kamat@linaro.org \
--cc=santosh.shilimkar@ti.com \
--cc=t.figa@samsung.com \
--cc=tushar.behera@linaro.org \
--cc=will.deacon@arm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.