From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: DT vs ARM static mappings
Date: Wed, 21 Sep 2011 10:59:37 +0100 [thread overview]
Message-ID: <20110921095926.GA2041@arm.com> (raw)
In-Reply-To: <1316598109.4611.613.camel@hornet.cambridge.arm.com>
On Wed, Sep 21, 2011 at 10:41:49AM +0100, Pawel Moll wrote:
> > > 2. Single DT_MACHINE_START matching (the most generic) "arm,vexpress"
> > > and doing (rougly) this in v2m_map_io:
> > >
> > > of_scan_flat_dt(v2m_dt_iotable_init, NULL);
> > >
> > > v2m_dt_iotable_init(...)
> > > {
> > > if (depth != 0)
> > > return 0;
> > > if (of_flat_dt_is_compatible(node, "arm,vexpress-legacy"))
> > > iotable_init(v2m_io_desc_legacy);
> > > else (of_flat_dt_is_compatible(node, "arm,vexpress-rs1"))
> > > iotable_init(v2m_io_desc_rs1);
> > > else
> > > panic();
> > > }
> > >
> > > Neither of them seem particularly appealing... ;-)
> >
> > But I think both ways would be acceptable in the end. It's not a lot
> > of extra code either way. In the second case, I would probably have
> > the legacy case as a special variant of the map_io function and have
> > all others be the default instead of falling back to panic though.
>
> Ok, I'll go (roughly) that way.
>
> > > In my case it's sysreg and sysctl. There are two more users of static
> > > mappings: timer01 and timer23, but they could at some point do ioremap()
> > > on their own (especially with Nico's changes).
> >
> > Well, I think with Nico's cahnges, you /can/ actually do ioremap for
> > areas that have been mapped through the iotable before kmalloc is up.
> > IIRC, omap does this for a number of peripherals.
> >
> > It's a bit of a hack, but I think it's much better than taking hardcoded
> > addresses.
>
> Yes, I was thinking about that last night. If you think it's acceptable
> I'll do this (killing MMIO_P2V on the way ;-)
>
> > With the combination of the points mentioned above, you should be
> > able to do:
> >
> > - map the entire I/O area in map_io(), depending on the board
> > - have an __iomem pointer for the sysreg
> > - populate that pointer using of_iomap from the device tree address
> > before you first access it.
> >
> > Do you think that would work?
>
> Yes, I suppose so. The last bit (getting the offset from DT) will be a
> little ugly, I think, but let's wait till I get some code done.
I won't attempt to modify the rest of the patch yet, but we can roll
changes in when you've decided on a way forward.
Alternatively, the requisite changes can be done as patches on top of
the basic patch -- since the initial patch doesn't attempt to support
multiple core tiles anyway.
Cheers
---Dave
WARNING: multiple messages have this Message-ID (diff)
From: Dave Martin <dave.martin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: DT vs ARM static mappings
Date: Wed, 21 Sep 2011 10:59:37 +0100 [thread overview]
Message-ID: <20110921095926.GA2041@arm.com> (raw)
In-Reply-To: <1316598109.4611.613.camel-okZbbLrgpR/YkXV2EHHjLW3o5bpOHsLO@public.gmane.org>
On Wed, Sep 21, 2011 at 10:41:49AM +0100, Pawel Moll wrote:
> > > 2. Single DT_MACHINE_START matching (the most generic) "arm,vexpress"
> > > and doing (rougly) this in v2m_map_io:
> > >
> > > of_scan_flat_dt(v2m_dt_iotable_init, NULL);
> > >
> > > v2m_dt_iotable_init(...)
> > > {
> > > if (depth != 0)
> > > return 0;
> > > if (of_flat_dt_is_compatible(node, "arm,vexpress-legacy"))
> > > iotable_init(v2m_io_desc_legacy);
> > > else (of_flat_dt_is_compatible(node, "arm,vexpress-rs1"))
> > > iotable_init(v2m_io_desc_rs1);
> > > else
> > > panic();
> > > }
> > >
> > > Neither of them seem particularly appealing... ;-)
> >
> > But I think both ways would be acceptable in the end. It's not a lot
> > of extra code either way. In the second case, I would probably have
> > the legacy case as a special variant of the map_io function and have
> > all others be the default instead of falling back to panic though.
>
> Ok, I'll go (roughly) that way.
>
> > > In my case it's sysreg and sysctl. There are two more users of static
> > > mappings: timer01 and timer23, but they could at some point do ioremap()
> > > on their own (especially with Nico's changes).
> >
> > Well, I think with Nico's cahnges, you /can/ actually do ioremap for
> > areas that have been mapped through the iotable before kmalloc is up.
> > IIRC, omap does this for a number of peripherals.
> >
> > It's a bit of a hack, but I think it's much better than taking hardcoded
> > addresses.
>
> Yes, I was thinking about that last night. If you think it's acceptable
> I'll do this (killing MMIO_P2V on the way ;-)
>
> > With the combination of the points mentioned above, you should be
> > able to do:
> >
> > - map the entire I/O area in map_io(), depending on the board
> > - have an __iomem pointer for the sysreg
> > - populate that pointer using of_iomap from the device tree address
> > before you first access it.
> >
> > Do you think that would work?
>
> Yes, I suppose so. The last bit (getting the offset from DT) will be a
> little ugly, I think, but let's wait till I get some code done.
I won't attempt to modify the rest of the patch yet, but we can roll
changes in when you've decided on a way forward.
Alternatively, the requisite changes can be done as patches on top of
the basic patch -- since the initial patch doesn't attempt to support
multiple core tiles anyway.
Cheers
---Dave
next prev parent reply other threads:[~2011-09-21 9:59 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-20 11:51 DT vs ARM static mappings Pawel Moll
2011-09-20 11:51 ` Pawel Moll
2011-09-20 12:58 ` Rob Herring
2011-09-20 12:58 ` Rob Herring
2011-09-20 14:02 ` Pawel Moll
2011-09-20 14:02 ` Pawel Moll
2011-09-20 14:37 ` Rob Herring
2011-09-20 14:37 ` Rob Herring
2011-09-20 16:16 ` Pawel Moll
2011-09-20 16:16 ` Pawel Moll
2011-09-20 19:28 ` Arnd Bergmann
2011-09-20 19:28 ` Arnd Bergmann
2011-09-21 9:41 ` Pawel Moll
2011-09-21 9:41 ` Pawel Moll
2011-09-21 9:59 ` Dave Martin [this message]
2011-09-21 9:59 ` Dave Martin
2011-09-21 10:02 ` Pawel Moll
2011-09-21 10:02 ` Pawel Moll
2011-09-22 16:23 ` Pawel Moll
2011-09-22 16:23 ` Pawel Moll
2011-09-23 15:45 ` Arnd Bergmann
2011-09-23 15:45 ` Arnd Bergmann
2011-09-21 17:49 ` Nicolas Pitre
2011-09-21 17:49 ` Nicolas Pitre
2011-09-22 13:04 ` Pawel Moll
2011-09-22 13:04 ` Pawel Moll
2011-09-22 13:13 ` Russell King - ARM Linux
2011-09-22 13:13 ` Russell King - ARM Linux
2011-09-22 13:45 ` Pawel Moll
2011-09-22 13:45 ` Pawel Moll
[not found] ` <1316699153.4611.858.camel-okZbbLrgpR/YkXV2EHHjLW3o5bpOHsLO@public.gmane.org>
2011-09-22 13:59 ` Russell King - ARM Linux
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=20110921095926.GA2041@arm.com \
--to=dave.martin@linaro.org \
--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.