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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).