PL310 cache initialization/fixup for BCM63138

Hi Russell, Arnd,

The PL310 cache present on BCM63138 comes up with wrong values out of
reset in particular, I need to at least override the way-size to be
32KiB otherwise.

Right now, I am overriding the auxiliary control register by supplying a
non 0xffffffff aux_ctrl_mask to l2x0_of_init().

Should I rather use a separate compatible string for it and perform the
"fixup" in a separate of_parse() callback, or in a separate fixup()
callback?

Or is it recommended to keep overriding the aux_ctrl_mask as part of the
call to l2x0_of_init()?

Thanks!
--
Florian

On Wed, Aug 13, 2014 at 11:09:19AM -0700, Florian Fainelli wrote:

Hi Russell, Arnd,

The PL310 cache present on BCM63138 comes up with wrong values out of
reset in particular, I need to at least override the way-size to be
32KiB otherwise.

Right now, I am overriding the auxiliary control register by supplying a
non 0xffffffff aux_ctrl_mask to l2x0_of_init().

Should I rather use a separate compatible string for it and perform the
"fixup" in a separate of_parse() callback, or in a separate fixup()
callback?

Or is it recommended to keep overriding the aux_ctrl_mask as part of the
call to l2x0_of_init()?

The correct answer is to research how to specify cache attributes in DT,
and create an appropriate set of properties described by that, and have
the l2x0 OF init code parse those, and create the appropriate aux control
register values from those.

I forget exactly what they are, but I do know that there is a standardised
set of DT properties to describe the geometry of caches - I came across
them about six months back when I worked on the L2 code.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

On 08/13/2014 11:24 AM, Russell King - ARM Linux wrote:

On Wed, Aug 13, 2014 at 11:09:19AM -0700, Florian Fainelli wrote:

quoted

Hi Russell, Arnd,

The PL310 cache present on BCM63138 comes up with wrong values out of
reset in particular, I need to at least override the way-size to be
32KiB otherwise.

Right now, I am overriding the auxiliary control register by supplying a
non 0xffffffff aux_ctrl_mask to l2x0_of_init().

Should I rather use a separate compatible string for it and perform the
"fixup" in a separate of_parse() callback, or in a separate fixup()
callback?

Or is it recommended to keep overriding the aux_ctrl_mask as part of the
call to l2x0_of_init()?

The correct answer is to research how to specify cache attributes in DT,
and create an appropriate set of properties described by that, and have
the l2x0 OF init code parse those, and create the appropriate aux control
register values from those.

I forget exactly what they are, but I do know that there is a standardised
set of DT properties to describe the geometry of caches - I came across
them about six months back when I worked on the L2 code.

Alright, I will take a stab at using the ePAPR cache properties.

How about PL310 specific properties such as instruction prefetc and
non-secure access, would boolean properties work for these?

Thanks!
--
Florian

On Wed, Aug 13, 2014 at 11:41:05AM -0700, Florian Fainelli wrote:

On 08/13/2014 11:24 AM, Russell King - ARM Linux wrote:

quoted

The correct answer is to research how to specify cache attributes in DT,
and create an appropriate set of properties described by that, and have
the l2x0 OF init code parse those, and create the appropriate aux control
register values from those.

I forget exactly what they are, but I do know that there is a standardised
set of DT properties to describe the geometry of caches - I came across
them about six months back when I worked on the L2 code.

Alright, I will take a stab at using the ePAPR cache properties.

How about PL310 specific properties such as instruction prefetc and
non-secure access, would boolean properties work for these?

We always enable non-secure access.  If we're running in secure mode,
enabling non-secure access will be accepted by the hardware, and as
we run in secure mode, has no effect.  If we're running in non-secure
mode, then we need to ask the firmware to enable non-secure access
to things like the unlock registers, and eventually the interrupt
registers anyway.

So it makes no sense for that to be a property.

For instruction prefetch, does it make sense for it to be in DT at
all - is there a reason not to enable it as a matter of course?

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.