From: jonsmirl at gmail.com <hidden> Date: 2012-03-20 16:52:58
Is there a helper for building the IO map_desc from the device tree?
For example on Versatile. All of this map_io data is already in the
device tree, it is just repeated here.
DT_MACHINE_START(VERSATILE_PB, "ARM-Versatile (Device Tree Support)")
.map_io = versatile_map_io,
.init_early = versatile_init_early,
....
MACHINE_END
void __init versatile_map_io(void)
{
iotable_init(versatile_io_desc, ARRAY_SIZE(versatile_io_desc));
}
static struct map_desc versatile_io_desc[] __initdata = {
{
.virtual = IO_ADDRESS(VERSATILE_SYS_BASE),
.pfn = __phys_to_pfn(VERSATILE_SYS_BASE),
.length = SZ_4K,
.type = MT_DEVICE
}, {
.virtual = IO_ADDRESS(VERSATILE_SIC_BASE),
.pfn = __phys_to_pfn(VERSATILE_SIC_BASE),
.length = SZ_4K,
.type = MT_DEVICE
}, {
.virtual = IO_ADDRESS(VERSATILE_VIC_BASE),
.pfn = __phys_to_pfn(VERSATILE_VIC_BASE),
.length = SZ_4K,
.type = MT_DEVICE
}, {
...
--
Jon Smirl
jonsmirl at gmail.com
From: Rob Herring <hidden> Date: 2012-03-21 13:09:57
On 03/20/2012 11:52 AM, jonsmirl at gmail.com wrote:
Is there a helper for building the IO map_desc from the device tree?
No. This is one of those things that device tree cannot have knowledge
of what needs to be statically mapped as that's not a h/w description.
We could probably have a list of nodes to map and extract the size and
physical addresses from the DT. There's lots of register defines
typically associated with the static mappings, so you would still have
duplicated information.
For example on Versatile. All of this map_io data is already in the
device tree, it is just repeated here.
DT_MACHINE_START(VERSATILE_PB, "ARM-Versatile (Device Tree Support)")
.map_io = versatile_map_io,
.init_early = versatile_init_early,
....
MACHINE_END
void __init versatile_map_io(void)
{
iotable_init(versatile_io_desc, ARRAY_SIZE(versatile_io_desc));
}
static struct map_desc versatile_io_desc[] __initdata = {
{
.virtual = IO_ADDRESS(VERSATILE_SYS_BASE),
.pfn = __phys_to_pfn(VERSATILE_SYS_BASE),
.length = SZ_4K,
.type = MT_DEVICE
}, {
.virtual = IO_ADDRESS(VERSATILE_SIC_BASE),
.pfn = __phys_to_pfn(VERSATILE_SIC_BASE),
.length = SZ_4K,
.type = MT_DEVICE
}, {
.virtual = IO_ADDRESS(VERSATILE_VIC_BASE),
.pfn = __phys_to_pfn(VERSATILE_VIC_BASE),
.length = SZ_4K,
.type = MT_DEVICE
The SIC and VIC should get converted to ioremap and using of_irq_init.
There's already DT init support for the VIC at least, so the conversion
should be easy. I think Linus W was working on this.
Rob
From: jonsmirl at gmail.com <hidden> Date: 2012-03-21 14:23:15
On Wed, Mar 21, 2012 at 9:09 AM, Rob Herring [off-list ref] wrote:
On 03/20/2012 11:52 AM, jonsmirl at gmail.com wrote:
quoted
Is there a helper for building the IO map_desc from the device tree?
No. This is one of those things that device tree cannot have knowledge
of what needs to be statically mapped as that's not a h/w description.
What's an example of something that is described in the device tree
and is dynamically mapped? Things like PCI cards shouldn't be in the
device tree since they are discoverable.
Nodes have 'status' in them, could this be used to control mapping?
uart1: uart at 02020000 {
compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
reg = <0x02020000 0x4000>;
interrupts = <0 26 0x04>;
status = "disabled";
};
Probably the right solution is that the individual drivers should map
themselves by calling into a helper function with address and range.
The helper would coalesce and merge ranges to reduce the number of
mappings.
This is a piece of a lpc3131 three I am working on. I could add a tiny
driver for the adp node that creates the mapping. Then as the
dependent devices ask for mappings they'd be inside the larger node.
ahb {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
isram0: memory at 11028000 {
reg = <0x11028000 0x18000>;
};
isram1: memory at 11040000 {
reg = <0x11040000 0x18000>;
};
apb0: apb at 13000000 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x13000000 0x13000000 0x8000>;
evtr at 13000000 {
compatible = "nxp,lpc31xx-evtr";
reg = <0x13000000 0x800>;
};
adc at 13002000 {
compatible = "nxp,lpc31xx-adc";
reg = <0x13002000 0x400>;
interrupts = <1>;
};
We could probably have a list of nodes to map and extract the size and
physical addresses from the DT. There's lots of register defines
typically associated with the static mappings, so you would still have
duplicated information.
The SIC and VIC should get converted to ioremap and using of_irq_init.
There's already DT init support for the VIC at least, so the conversion
should be easy. I think Linus W was working on this.
Rob
From: Rob Herring <hidden> Date: 2012-03-21 14:37:25
On 03/21/2012 09:23 AM, jonsmirl at gmail.com wrote:
On Wed, Mar 21, 2012 at 9:09 AM, Rob Herring [off-list ref] wrote:
quoted
On 03/20/2012 11:52 AM, jonsmirl at gmail.com wrote:
quoted
Is there a helper for building the IO map_desc from the device tree?
No. This is one of those things that device tree cannot have knowledge
of what needs to be statically mapped as that's not a h/w description.
What's an example of something that is described in the device tree
and is dynamically mapped? Things like PCI cards shouldn't be in the
device tree since they are discoverable.
I mean mapped into cpu virtual memory. Static mapping is map_desc.
Dynamic mapping is ioremap.
Nodes have 'status' in them, could this be used to control mapping?
uart1: uart at 02020000 {
compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
reg = <0x02020000 0x4000>;
interrupts = <0 26 0x04>;
status = "disabled";
};
Probably the right solution is that the individual drivers should map
themselves by calling into a helper function with address and range.
The helper would coalesce and merge ranges to reduce the number of
mappings.
This is what most drivers do. The static mappings in map_desc are often
special cases where ioremap doesn't work. LL_DEBUG is one example.
This is a piece of a lpc3131 three I am working on. I could add a tiny
driver for the adp node that creates the mapping. Then as the
dependent devices ask for mappings they'd be inside the larger node.
Use ioremap unless there is a reason you can't.
Rob
We could probably have a list of nodes to map and extract the size and
physical addresses from the DT. There's lots of register defines
typically associated with the static mappings, so you would still have
duplicated information.
quoted
For example on Versatile. All of this map_io data is already in the
device tree, it is just repeated here.
DT_MACHINE_START(VERSATILE_PB, "ARM-Versatile (Device Tree Support)")
.map_io = versatile_map_io,
.init_early = versatile_init_early,
....
MACHINE_END
void __init versatile_map_io(void)
{
iotable_init(versatile_io_desc, ARRAY_SIZE(versatile_io_desc));
}
static struct map_desc versatile_io_desc[] __initdata = {
{
.virtual = IO_ADDRESS(VERSATILE_SYS_BASE),
.pfn = __phys_to_pfn(VERSATILE_SYS_BASE),
.length = SZ_4K,
.type = MT_DEVICE
}, {
.virtual = IO_ADDRESS(VERSATILE_SIC_BASE),
.pfn = __phys_to_pfn(VERSATILE_SIC_BASE),
.length = SZ_4K,
.type = MT_DEVICE
}, {
.virtual = IO_ADDRESS(VERSATILE_VIC_BASE),
.pfn = __phys_to_pfn(VERSATILE_VIC_BASE),
.length = SZ_4K,
.type = MT_DEVICE
The SIC and VIC should get converted to ioremap and using of_irq_init.
There's already DT init support for the VIC at least, so the conversion
should be easy. I think Linus W was working on this.
Rob