From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Grant Likely <grant.likely@linaro.org>,
Stanimir Varbanov <svarbanov@mm-sol.com>,
Rob Herring <rob.herring@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>,
Lee Jones <lee.jones@linaro.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] RFC: add function for localbus address
Date: Thu, 23 Oct 2014 00:20:21 +0100 [thread overview]
Message-ID: <20141022232021.GF27405@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <54483746.9060104@codeaurora.org>
On Wed, Oct 22, 2014 at 04:01:26PM -0700, Stephen Boyd wrote:
> Where did this end up? When we talked at Connect I think we settled on
> exploring a driver core specific API like dev_get_localbus_address()
> that calls of_get_localbus_address() for devices with an of_node and in
> the future it could call something like acpi_get_localbus_address() when
> there's an acpi_node. I believe the biggest concern is that we're making
> an API that is OF or platform bus specific when it doesn't need to be.
> Making a driver core specific API avoids this problem by making it bus
> agnostic.
Given how little information there is in the original patch as to exactly
what problem this is addressing, I could be getting the wrong end of the
stick here.
Is this about trying to have a way to obtain the bus local addresses
associated with CPU-view resources?
If so, how about looking towards PCI, which has had this problem for the
last 15+ years, where PCI bus addresses are not necessarily the same as
CPU physical addresses?
There, we don't end up with multiple addresses specified in resources.
We instead have a way to translate between resources and bus-local
addresses, which IMHO is far nicer and less error-prone than having to
specify the same information twice, once with an offset and once without.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2014-10-22 23:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 11:42 use IORESOURCE_REG resource type for non-translatable addresses in DT Stanimir Varbanov
2014-07-29 12:00 ` Arnd Bergmann
2014-07-29 14:06 ` Stanimir Varbanov
2014-07-29 15:29 ` Rob Herring
2014-07-29 23:45 ` Grant Likely
2014-07-30 1:07 ` Stephen Boyd
2014-07-30 2:53 ` Rob Herring
2014-07-30 6:06 ` Stephen Boyd
2014-08-27 16:27 ` Stanimir Varbanov
2014-08-27 18:24 ` Bjorn Andersson
2014-08-27 21:55 ` Stephen Boyd
2014-08-29 4:09 ` Bjorn Andersson
2014-08-28 7:58 ` Stanimir Varbanov
2014-09-02 15:45 ` [PATCH] RFC: add function for localbus address Stanimir Varbanov
2014-09-05 23:29 ` Stephen Boyd
2014-09-08 14:52 ` Grant Likely
2014-09-08 20:22 ` Stephen Boyd
2014-09-08 21:21 ` Mark Brown
2014-09-14 4:46 ` Grant Likely
2014-10-22 23:01 ` Stephen Boyd
2014-10-22 23:20 ` Russell King - ARM Linux [this message]
2014-10-22 23:53 ` Stephen Boyd
2014-10-22 23:51 ` Mark Brown
2014-09-09 15:07 ` Stanimir Varbanov
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=20141022232021.GF27405@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rob.herring@linaro.org \
--cc=sboyd@codeaurora.org \
--cc=svarbanov@mm-sol.com \
/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).