From: Grant Likely <grant.likely@secretlab.ca>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: linux-kernel@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org,
Rob Herring <rob.herring@calxeda.com>
Subject: Re: [PATCH] of: Support a PCI device that is compatible with 'simple-bus'
Date: Mon, 04 Mar 2013 10:55:36 +0800 [thread overview]
Message-ID: <20130304025536.4CC7E3E17F8@localhost> (raw)
In-Reply-To: <20121219191800.GA1169@obsidianresearch.com>
On Wed, 19 Dec 2012 12:18:00 -0700, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote:
> On Wed, Dec 19, 2012 at 12:54:51PM +0000, Grant Likely wrote:
> > In both cases, the type of transfer is encoded by the BAR address and
> > does not get exposed to the child device. Exposing the PCI flags into
> > the child bus(es) really isn't a very good idea because they don't make
> > sense in that context. It may seem expedient, but it will be fragile.
>
> Well, it makes as much sense as for a PCI driver - each of the three
> transfer types has different coding requirements in the driver, so
> each of the three type must be kept separate.
>
> I haven't looked super closely at this, but the basic desire is to
> have IORESOURCE_PREFETCH tagged on the struct resource that reaches
> the platform driver. 'get_flags' for a non-PCI addresses scheme always
> returns IORESOURCE_MEM, and translating through a ranges doesn't
> appear to fix that. This is where 3dw is desirable because it uses a
> get_flags that understands the three resource types.
We could possibly change the ranges translation code to pick up
IORESOURCE_PREFETCH when a translation crosses a PREFETCH bar. That
would also ensure that child nodes don't have to keep the flags field
consistent with the ranges mapping.
g.
prev parent reply other threads:[~2013-03-04 2:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-10 21:51 [PATCH] of: Support a PCI device that is compatible with 'simple-bus' Jason Gunthorpe
2012-12-14 20:26 ` Grant Likely
2012-12-14 21:58 ` Jason Gunthorpe
[not found] ` <20121214215814.GA14149-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2012-12-19 12:54 ` Grant Likely
2012-12-19 19:18 ` Jason Gunthorpe
2013-03-04 2:55 ` 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=20130304025536.4CC7E3E17F8@localhost \
--to=grant.likely@secretlab.ca \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rob.herring@calxeda.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).