From: Grant Likely <grant.likely@secretlab.ca>
To: James Hogan <james.hogan@imgtec.com>
Cc: linux-next <linux-next@vger.kernel.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
devicetree-discuss <devicetree-discuss@lists.ozlabs.org>,
Rob Herring <rob.herring@calxeda.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Heads up on a device tree change
Date: Sat, 13 Apr 2013 20:26:59 +0100 [thread overview]
Message-ID: <20130413192659.D92973E2249@localhost> (raw)
In-Reply-To: <511382AD.7030804@imgtec.com>
On Thu, 7 Feb 2013 10:32:13 +0000, James Hogan <james.hogan@imgtec.com> wrote:
> On 06/02/13 14:28, Grant Likely wrote:
> > On Wed, Feb 6, 2013 at 1:32 PM, James Hogan <james.hogan@imgtec.com> wrote:
> >> On 06/02/13 13:11, Grant Likely wrote:
> >>> - Resources on platform_devices get registered so they appear in
> >>> /proc/iomem and /proc/ioports and so that device drivers get the added
> >>> protection of request_region. This will cause breakage on device trees
> >>> nodes with partially overlapping memory regions. (ie. 0x100..0x1ff and
> >>> 0x180..0x27f). I also have a workaround for this, but I doubt that it
> >>> will be necessary.
> >>
> >> Hi Grant,
> >>
> >> If I understand you correctly, the non-overlapping memory regions thing
> >> could be a problem for me. We have a Meta based SoC that has various SoC
> >> registers grouped together for doing GPIOs and Pin control things. I'm
> >> still in the process of converting it to device tree, but the way I've
> >> been handling it is to provide overlapping registers to both the gpio
> >> and pinctl DT nodes. Each GPIO bank's registers are also interleaved
> >> with the others, so I've been providing overlapping register ranges
> >> (offset by 4 for each bank) to the DT node for each gpio bank too, so
> >> each bank can function independently and the driver doesn't have to
> >> worry about multiple banks. Does that sound like a reasonable use case?
> >>
> >> I guess I could cheat with the length, or specify each register in it's
> >> own memory resource, but it seems like overkill.
> >
> > Note that overlapping regions are fine /provided/ that they are the
> > same size or one fits nicely inside another. It's partial overlap that
> > is a problem
>
> It still feels a bit artificial to impose that limitation on something
> that is supposed to be implementation independent. Having said that it
> doesn't particularly bother me having to work around it.
I've backed out on this. It broke too much.
g.
prev parent reply other threads:[~2013-04-13 19:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-06 13:11 Heads up on a device tree change Grant Likely
2013-02-06 13:32 ` James Hogan
2013-02-06 14:28 ` Grant Likely
2013-02-07 10:32 ` James Hogan
2013-04-13 19:26 ` Grant Likely [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=20130413192659.D92973E2249@localhost \
--to=grant.likely@secretlab.ca \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=james.hogan@imgtec.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=rob.herring@calxeda.com \
--cc=sfr@canb.auug.org.au \
/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.