From: thomas.petazzoni@free-electrons•com (Thomas Petazzoni)
To: linux-arm-kernel@lists•infradead.org
Subject: address translation for PCIe-to-localbus bridge
Date: Wed, 6 Nov 2013 20:00:22 +0100 [thread overview]
Message-ID: <20131106200022.0008a8b9@skate> (raw)
In-Reply-To: <20131106182457.GA25879@obsidianresearch.com>
Dear Jason Gunthorpe,
On Wed, 6 Nov 2013 11:24:57 -0700, Jason Gunthorpe wrote:
> > The fact that the bootloader sets this MBus window is more-or-less
> > irrelevant because when the mvebu-mbus driver is initialized, it
> > completely clears *all* existing MBus windows:
>
> Yes, but it is not irrelevent. In my case this same DT is supporting
> 3.10 and 3.12 kernels - 3.10 doesn't even have a MBUS driver or
> dynamic PEX driver and it relies upon the ranges entry matching the
> static bootloader configuration to work properly.
Ok, I understand.
> > I indeed remember some objections, but I'm not sure what they were
> > precisely. Maybe we didn't had a precise use case back at the time, to
> > really make people objecting realize what the problem was?
>
> That is about where I am at too..
So maybe we should revive this direction then?
> > On the other hand, I think the of_*() API is quite limited when it
> > comes to updating the DT. If I remember correctly, you can update some
> > nodes, but you can never reclaim the memory that was used for the
> > previous value of the node. So any change to the in-memory DT
> > representation is basically a memory leak for the entire lifetime of
> > the system (of course, I might be wrong on this, I haven't dived into
> > all the hardcore details of DT manipulation in the kernel).
>
> I'm not clear on that either, but it seems plausible..
>
> > I'm not sure what would be the alternate mechanism to hook into the
> > address translation. of_translate_one(), where all the translation
> > through ranges takes place is really tied to the DT only, adding
> > another mechanism to hook some custom address translation in there
> > seems a bit weird, no?
>
> I agree, some kind of callback scheme would really be needed.. Sort of
> like the xlate callback we have for IRQs?
>
> So the mbus would register an address xlate for its node that is
> called instead of ranges parsing. For the example in my last message
> the FPGA driver would register an xlate that made addresses relative
> to its own BAR0 address.
Interesting. I admit I never had a look how the IRQ ->xlate() stuff was
hooked into the OF code, maybe it's a good starting point. This
discussion is on the DT mailing list, so maybe some DT person will
agree to let us know what they think the good approach is?
> > However, it just works by pure luck: nothing guarantees you that the
> > PCIe 0 memory window will start at 0xe0000000. Of course, since you
>
> Right, the general case is totally borked here - the dynamic changes
> to the address map by MBUS and PCI are not being reflected to the
> of_address machinery, be they from MBUS or from PCI BAR assignment.
Right.
> However, address assignment is very predicatble, so if you have a
> constrained system it can work.
Indeed.
> In the normal DT use case (eg on a SPARC or something) the DT itself
> would be self-consistent with the addresses assigned from the firmware
> and the PCI machinery should try to respect the bootloader addresses
> if they are workable during address assignment.
So ARM isn't a "normal DT use case" ? :-)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2013-11-06 19:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-06 10:27 address translation for PCIe-to-localbus bridge Gerlando Falauto
2013-11-06 12:23 ` Thierry Reding
2013-11-06 12:50 ` Gerlando Falauto
2013-11-06 17:36 ` Jason Gunthorpe
2013-11-06 18:03 ` Thomas Petazzoni
2013-11-06 18:24 ` Jason Gunthorpe
2013-11-06 19:00 ` Thomas Petazzoni [this message]
2013-11-11 15:50 ` Grant Likely
2013-11-12 7:05 ` Thomas Petazzoni
2013-11-12 8:11 ` Gerlando Falauto
2013-11-12 8:16 ` Thomas Petazzoni
2013-11-12 8:26 ` Gerlando Falauto
2013-11-13 6:26 ` Grant Likely
2013-11-12 8:51 ` Grant Likely
2013-11-06 18:33 ` Pantelis Antoniou
2013-11-06 18:56 ` Jason Gunthorpe
2013-11-06 19:16 ` Pantelis Antoniou
2013-11-06 19:50 ` Jason Gunthorpe
2013-11-06 19:38 ` Gerlando Falauto
2013-11-06 20:07 ` Jason Gunthorpe
2013-11-07 9:07 ` Gerlando Falauto
2013-11-07 17:01 ` Jason Gunthorpe
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=20131106200022.0008a8b9@skate \
--to=thomas.petazzoni@free-electrons$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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