linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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
>>
>>>       }, {
>>> ...
>>>
>>
> 
> 
> 

      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).