On Monday 02 May 2011 23:27:04 johnlinn at comcast.net wrote:
quoted
Yes we could explain hard coded numbers. Ideally GIC driver would
support
quoted
device tree it seems like to me.
quoted
Seems like the GIC driver could remap it's own memory but maybe that
won't
quoted
work across all platforms and then the platform would need to do
it.
Why not just add a stub in the xilinx platform for now that remaps
the
memory using ioremap and calls the regular GIC initialization?
Seems easy enough assuming we don't need the SCU early for the core count
and can get that from the device tree.
Since the SCU and part of the GIC end up in the same 4K page they need to be
together (unless I'm thinking about that wrong).
SCU 0xF8000000
GIC_CPU 0xF8000100
GIC_DIS 0xF8001000
-- John
That function can then easily be moved to common code when another
platform uses it.
Arnd
From: Russell King - ARM Linux <hidden> Date: 2011-05-02 23:01:43
On Mon, May 02, 2011 at 09:50:11PM +0000, johnlinn at comcast.net wrote:
Seems easy enough assuming we don't need the SCU early for the core count
and can get that from the device tree.
Beware. Things may not be that trivial when you start considering some
of the weirdnesses that some vendors start coming out with.
Since the SCU and part of the GIC end up in the same 4K page they need to be
together (unless I'm thinking about that wrong).
SCU 0xF8000000
GIC_CPU 0xF8000100
GIC_DIS 0xF8001000
It is preferable to use the same mapping, as it ensures that you're not
going to create incompatible aliases.
But, before we get too bogged down with this, please realise that it is
possible to setup early mappings from the device tree for things like the
SCU. Maybe not using ioremap(), but I'm sure we can find some way to use
the iotable_init() stuff to setup some early mappings from DT for this
stuff.
From: Grant Likely <hidden> Date: 2011-05-02 23:36:25
On Mon, May 2, 2011 at 5:01 PM, Russell King - ARM Linux
[off-list ref] wrote:
On Mon, May 02, 2011 at 09:50:11PM +0000, johnlinn at comcast.net wrote:
quoted
Seems easy enough assuming we don't need the SCU early for the core count
and can get that from the device tree.
Beware. ?Things may not be that trivial when you start considering some
of the weirdnesses that some vendors start coming out with.
quoted
Since the SCU and part of the GIC end up in the same 4K page they need to be
together (unless I'm thinking about that wrong).
SCU 0xF8000000
GIC_CPU 0xF8000100
GIC_DIS 0xF8001000
It is preferable to use the same mapping, as it ensures that you're not
going to create incompatible aliases.
But, before we get too bogged down with this, please realise that it is
possible to setup early mappings from the device tree for things like the
SCU. ?Maybe not using ioremap(), but I'm sure we can find some way to use
the iotable_init() stuff to setup some early mappings from DT for this
stuff.
On Tuesday 03 May 2011 01:01:18 Russell King - ARM Linux wrote:
It is preferable to use the same mapping, as it ensures that you're not
going to create incompatible aliases.
Is aliasing a problem for MMIO mappings? I would think that you can
ioremap registers anywhere and as often as you want because they are
never cacheable.
But, before we get too bogged down with this, please realise that it is
possible to setup early mappings from the device tree for things like the
SCU. Maybe not using ioremap(), but I'm sure we can find some way to use
the iotable_init() stuff to setup some early mappings from DT for this
stuff.
Good point. It doesn't really matter how the entries get into the page
table, whether you call it ioremap, iotable_init, create_mapping or
ioremap_early. What matters is that we don't hardcode the physical
address in the board code, because that limits the possible reuse
on other device tree enabled targets.
Arnd
From: Russell King - ARM Linux <hidden> Date: 2011-05-03 08:52:50
On Tue, May 03, 2011 at 09:58:14AM +0200, Arnd Bergmann wrote:
On Tuesday 03 May 2011 01:01:18 Russell King - ARM Linux wrote:
quoted
It is preferable to use the same mapping, as it ensures that you're not
going to create incompatible aliases.
Is aliasing a problem for MMIO mappings? I would think that you can
ioremap registers anywhere and as often as you want because they are
never cacheable.
Provided the type and sharability is identical then there is no problem.
I wasn't referring to multiple ioremap()s of the same region - that
should be fine as the same attributes will be used. If you mix ioremap()
and iotable_init() then you _could_ have problems if you don't use
MT_DEVICE in the iotable.
What I'm basically saying is that mixing the methods of creating these
mappings makes it much easier to get tripped up over these issues.
On Tuesday 03 May 2011, Russell King - ARM Linux wrote:
On Tue, May 03, 2011 at 09:58:14AM +0200, Arnd Bergmann wrote:
quoted
On Tuesday 03 May 2011 01:01:18 Russell King - ARM Linux wrote:
quoted
It is preferable to use the same mapping, as it ensures that you're not
going to create incompatible aliases.
Is aliasing a problem for MMIO mappings? I would think that you can
ioremap registers anywhere and as often as you want because they are
never cacheable.
Provided the type and sharability is identical then there is no problem.
I wasn't referring to multiple ioremap()s of the same region - that
should be fine as the same attributes will be used. If you mix ioremap()
and iotable_init() then you _could_ have problems if you don't use
MT_DEVICE in the iotable.
What I'm basically saying is that mixing the methods of creating these
mappings makes it much easier to get tripped up over these issues.