Re: [PATCH 1/1] ARM: EXYNOS: Initialize L2x0 cache controller for Exynos4 only

[Tomasz Figa <tomasz.figa@gmail.com>]

Hi Sachin,

[adding more people on Cc for some discussion]

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.

> 
> > Other than that, it will be required to register firmware operations
> > before L2X0 initialization, because on some boards it is needed to
> > initialize the L2 cache through secure firmware.
> > 
> > Please let me handle this by the way of patches adding firmware based
> > L2X0 initialization.
> 
> Sure, please go ahead. BTW, any rough estimate about when you plan to post
> them?

They might not make it for 3.13, as during next week I'm on LCE/KS/ELCE
in Edinburgh and I will be able to continue my work on this only after
getting back.

If this is something of high priority, then here's my idea:

- the l2x0_of_init() function itself should be an early_initcall, without
  any arguments. It would carry on with appropriate initialization only
  if there is an l2x0 node specified in device tree,
- the aux_val and aux_mask parameters should rather come from device tree,
  if there are no other means of obtaining them automatically.

This is something that still needs a bit more thought, as there are some
more interesting cases (as mach-ux500) which do more things than just
simple call to l2x0_of_init(). I guess this should be discussed with
people responsible for such platforms and l2x0 driver in general.

Best regards,
Tomasz