From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: Device tree and IO map_desc.
Date: Wed, 21 Mar 2012 09:37:25 -0500 [thread overview]
Message-ID: <4F69E7A5.4090101@gmail.com> (raw)
In-Reply-To: <CAKON4OxxmO_Et8FTVp=i7h9uODWAtdjHOmZrFWLtgqYVAjAAGg@mail.gmail.com>
On 03/21/2012 09:23 AM, jonsmirl at gmail.com wrote:
> On Wed, Mar 21, 2012 at 9:09 AM, Rob Herring <robherring2@gmail.com> wrote:
>> 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.
>
> 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
> 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.
>>
>>> 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
>>
>>> }, {
>>> ...
>>>
>>
>
>
>
prev parent reply other threads:[~2012-03-21 14:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-20 16:52 Device tree and IO map_desc jonsmirl at gmail.com
2012-03-21 13:09 ` Rob Herring
2012-03-21 14:23 ` jonsmirl at gmail.com
2012-03-21 14:37 ` Rob Herring [this message]
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=4F69E7A5.4090101@gmail.com \
--to=robherring2@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.