From: Lorenzo.Pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: Platform data with function pointers
Date: Fri, 18 Jun 2010 15:25:43 +0100 [thread overview]
Message-ID: <000a01cb0ef2$23160030$69420090$@Pieralisi@arm.com> (raw)
In-Reply-To: <20100618131301.GA21333@n2100.arm.linux.org.uk>
Concerning platform_devices ids, sorry I wasn't meant to report an amba primecell binding snippet, I wanted to report here just a
binding for a simple memory mapped platform device (not a primecell one). I was asking that question about platform_device
statically defined structs that use the id for enumeration, and going with FDT the id has to be initialized somehow from the tree
because the struct is allocated dynamically.
Wrt map_desc point taken, I was looking into possible ways of getting rid of platform specific statically defined data, that array
in particular.
Thanks a lot for your feedback,
Lorenzo
-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Friday, June 18, 2010 2:13 PM
To: Lorenzo Pieralisi
Cc: 'Grant Likely'; devicetree-discuss; linux-arm-kernel at lists.infradead.org; Jeremy Kerr; Nicolas Pitre
Subject: Re: Platform data with function pointers
On Fri, Jun 18, 2010 at 01:47:28PM +0100, Lorenzo Pieralisi wrote:
> I think chip-select addressing should be used if that is the way HW handles it. If the device is described through a
memory-mapping,
> ex. snippet follows:
>
> serial at 101f2000 {
> compatible = "arm,pl011";
> reg = <0x101f2000 0x1000 >;
> };
Primecell devices aren't platform devices. They have no 'id' field as
such. Instead, modern implementations have PCI-like IDs.
> struct map_desc {
> unsigned long virtual;
> unsigned long pfn;
> unsigned long length;
> unsigned int type;
> };
>
> static struct map_desc realview_eb_io_desc[] __initdata = {
> {
> .virtual = IO_ADDRESS(REALVIEW_SYS_BASE),
> .pfn = __phys_to_pfn(REALVIEW_SYS_BASE),
> .length = SZ_4K,
> .type = MT_DEVICE,
> }, ...
These mappings are entirely arbitary, and change according to the
implementation of the platform.
Some platforms want to avoid using ioremap() to create 4K page mappings
for their devices, so instead they statically map them and arrange for
ioremap() to know about that static mapping.
Given that PAGE_OFFSET can be changed, it would be absolutely silly to
put this into the device tree.
next prev parent reply other threads:[~2010-06-18 14:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <-71663801230973480@unknownmsgid>
2010-06-14 17:32 ` Platform data with function pointers Grant Likely
2010-06-18 12:47 ` Lorenzo Pieralisi
2010-06-18 13:13 ` Russell King - ARM Linux
2010-06-18 14:25 ` Lorenzo Pieralisi [this message]
[not found] ` <-8400781325900388878@unknownmsgid>
2010-06-18 14:33 ` Eric Miao
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='000a01cb0ef2$23160030$69420090$@Pieralisi@arm.com' \
--to=lorenzo.pieralisi@arm.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).