On Thu, Mar 14, 2013 at 03:29:21PM -0600, Jason Gunthorpe wrote:
> On Thu, Mar 14, 2013 at 10:09:26PM +0100, Thierry Reding wrote:
>
> > > ranges = <0x8200 0 0x8000 0x8000 0 0x1000 /* port 0
> > > registers */
> > > 0x8200 0 0x80001000 0x80001000 0 0x1000 /* po
On Thu, Mar 14, 2013 at 10:09:26PM +0100, Thierry Reding wrote:
> > ranges = <0x8200 0 0x8000 0x8000 0 0x1000 /* port 0
> > registers */
> > 0x8200 0 0x80001000 0x80001000 0 0x1000 /* port 1
> > registers */
> > 0x8100 0 0 0x8200 0 0
On Thu, Mar 14, 2013 at 11:25:55AM -0600, Jason Gunthorpe wrote:
[...]
> I'm assuming 0x8000, 0xa000 and 0xb000 are real CPU physical
> addresses?
>
> Then it should probably look like:
>
> ranges = <0x8200 0 0x8000 0x8000 0 0x1000 /* port 0
> registers */
>
On Thu, Mar 14, 2013 at 09:38:58PM +0100, Thierry Reding wrote:
> >pci@1,0 {
> > device_type = "pci";
> > assigned-addresses = <0x8200 0 0x8000 0
> > 0x1000>;
Sorry, I missed this. The b,d,f bits should be set:
On Thu, Mar 14, 2013 at 11:25:55AM -0600, Jason Gunthorpe wrote:
> [trimm'd the cc list]
>
> On Thu, Mar 14, 2013 at 10:01:20AM +0100, Thierry Reding wrote:
>
> > It turns out that this works with the Tegra driver because it uses the
> > new of_pci_process_ranges() function and simply overwrites
[trimm'd the cc list]
On Thu, Mar 14, 2013 at 10:01:20AM +0100, Thierry Reding wrote:
> It turns out that this works with the Tegra driver because it uses the
> new of_pci_process_ranges() function and simply overwrites earlier
> matches by subsequent ones.
>
> ranges = <0x8200 0 0 0x8
On Wed, Mar 13, 2013 at 04:21:02PM -0600, Jason Gunthorpe wrote:
> On Wed, Mar 13, 2013 at 11:02:35PM +0100, Thierry Reding wrote:
>
> > Does that look about correct?
>
> By my reading of the spec the entries in ranges should not
> have the b,d,f bits set..
>
> Although it is not a big stretch
On Wed, Mar 13, 2013 at 12:48:28PM -1000, Mitch Bradley wrote:
> On 3/13/2013 11:33 AM, Thierry Reding wrote:
> > On Wed, Mar 13, 2013 at 10:58:02AM -1000, Mitch Bradley wrote:
> > [...]
> >> In this case, the answer to "what does pcie_controller do?" is "it
> >> implements a PCI bus" below. So 'd
On 03/13/2013 03:33 PM, Thierry Reding wrote:
> On Wed, Mar 13, 2013 at 10:58:02AM -1000, Mitch Bradley wrote:
> [...]
>> In this case, the answer to "what does pcie_controller do?" is
>> "it implements a PCI bus" below. So 'device_type = "pci"' is
>> appropriate.
>
> Alright, that's 2 against 1
On 03/13/2013 05:48 PM, Mitch Bradley wrote:
> On 3/13/2013 11:33 AM, Thierry Reding wrote:
>> On Wed, Mar 13, 2013 at 10:58:02AM -1000, Mitch Bradley wrote:
>> [...]
>>> In this case, the answer to "what does pcie_controller do?" is "it
>>> implements a PCI bus" below. So 'device_type = "pci"' is
On Wed, Mar 13, 2013 at 10:58:02AM -1000, Mitch Bradley wrote:
> port hardware used the common programming model, with real config
> headers and stuff, 3/2 would be good because you could use existing
> drivers. But since you need a special root-port driver anyway, why go
> to the trouble of emul
On Wed, Mar 13, 2013 at 11:02:35PM +0100, Thierry Reding wrote:
> Does that look about correct?
By my reading of the spec the entries in ranges should not
have the b,d,f bits set..
Although it is not a big stretch to include them..
> Now the code will actually match the first entry and assume
On Wed, Mar 13, 2013 at 10:58:02AM -1000, Mitch Bradley wrote:
[...]
> But then you run into the problem that the pci variant of struct of_bus
> uses "assigned-addresses" instead of "reg". So it still doesn't work
> as-is. To make it work, you would need to add an "assigned-addresses"
> property
On Wed, Mar 13, 2013 at 10:58:02AM -1000, Mitch Bradley wrote:
[...]
> In this case, the answer to "what does pcie_controller do?" is "it
> implements a PCI bus" below. So 'device_type = "pci"' is appropriate.
Alright, that's 2 against 1. I don't have much of a choice but to yield.
> Having just
On Wed, Mar 13, 2013 at 01:59:01PM -0600, Jason Gunthorpe wrote:
> On Wed, Mar 13, 2013 at 08:26:28PM +0100, Thierry Reding wrote:
>
> > As Mitch already said there's very little chance that the specification
> > update will be ratified through IEEE, so I think that we might just as
> > well put a
On Wed, Mar 13, 2013 at 08:26:28PM +0100, Thierry Reding wrote:
> As Mitch already said there's very little chance that the specification
> update will be ratified through IEEE, so I think that we might just as
> well put a corresponding text somewhere below Documentation/devicetree.
Sure, I'm fi
On Wed, Mar 13, 2013 at 11:02:05AM -0600, Jason Gunthorpe wrote:
> On Wed, Mar 13, 2013 at 09:18:15AM +0100, Thierry Reding wrote:
>
> > Mitch already answered this. The specification is now almost 15 years
> > old and it couldn't possibly have foreseen all of the future use-cases.
> > If the spec
On Wed, Mar 13, 2013 at 09:18:15AM +0100, Thierry Reding wrote:
> Mitch already answered this. The specification is now almost 15 years
> old and it couldn't possibly have foreseen all of the future use-cases.
> If the specification is too restrictive and Mitch gives his blessing to
> remove some
On Tue, Mar 12, 2013 at 04:08:54PM -0600, Jason Gunthorpe wrote:
> On Tue, Mar 12, 2013 at 10:30:06PM +0100, Thierry Reding wrote:
>
> > > Not going down the of_pci_* code paths for address translation at the
> > > root port bridge nodes is certainly not right.
> >
> > I'm not so sure. Why should
On Tue, Mar 12, 2013 at 10:30:06PM +0100, Thierry Reding wrote:
> > Not going down the of_pci_* code paths for address translation at the
> > root port bridge nodes is certainly not right.
>
> I'm not so sure. Why should the pcie-controller be a PCI device?
The spec is clear on that point as wel
On Tue, Mar 12, 2013 at 03:03:28PM -0600, Jason Gunthorpe wrote:
> On Tue, Mar 12, 2013 at 09:38:19PM +0100, Thierry Reding wrote:
>
> > I've also verified that things actually do work with the binding that I
> > proposed for Tegra, even if I add device_type = "pci" to the root port
> > nodes. The
On Tue, Mar 12, 2013 at 09:38:19PM +0100, Thierry Reding wrote:
> I've also verified that things actually do work with the binding that I
> proposed for Tegra, even if I add device_type = "pci" to the root port
> nodes. The reason is that the OF core looks up the type of the *parent*
> node to fin
On Tue, Mar 12, 2013 at 09:57:49AM -0600, Jason Gunthorpe wrote:
> On Tue, Mar 12, 2013 at 08:08:52AM +0100, Thierry Reding wrote:
>
> > So to recapitulate, we agree that configuration space can be translated
> > through the "ranges" property. That means the only missing link is a new
> > function
On Tue, Mar 12, 2013 at 08:08:52AM +0100, Thierry Reding wrote:
> So to recapitulate, we agree that configuration space can be translated
> through the "ranges" property. That means the only missing link is a new
> function to translate not only "assigned-addresses" but also the "reg"
> property f
On Mon, Mar 11, 2013 at 01:38:38PM -1000, Mitch Bradley wrote:
> On 3/11/2013 1:25 PM, Jason Gunthorpe wrote:
> > On Mon, Mar 11, 2013 at 11:50:19AM -1000, Mitch Bradley wrote:
> >
> >>> However - the driver runs the core in a 'root port bridge mode' where
> >>> the config header register block yo
On 3/11/2013 1:25 PM, Jason Gunthorpe wrote:
> On Mon, Mar 11, 2013 at 11:50:19AM -1000, Mitch Bradley wrote:
>
>>> However - the driver runs the core in a 'root port bridge mode' where
>>> the config header register block you are looking at is inhibited. The
>>> Marvell IP block requires software
On Mon, Mar 11, 2013 at 11:50:19AM -1000, Mitch Bradley wrote:
> > However - the driver runs the core in a 'root port bridge mode' where
> > the config header register block you are looking at is inhibited. The
> > Marvell IP block requires software support to run in bridge mode. So
> > Marvell re
On 3/11/2013 8:15 AM, Jason Gunthorpe wrote:
> On Sun, Mar 10, 2013 at 07:46:04PM -1000, Mitch Bradley wrote:
>
>> So it seems that we are faced with two requirements that are somewhat at
>> odds with one another.
>>
>> 1) Some of the root port bridge registers have to be accessed via config
>> sp
On 3/11/2013 8:23 AM, Jason Gunthorpe wrote:
>> (b) The discovery/enumeration code needs to access config space via
>> pci_ops. The root complex driver implements pci_ops based on a trivial
>> parsing of ranges (omitting irrelevant details):
>>
>> pci_op_read(devfn, pos) {
>>loop_over_ranges_e
> (b) The discovery/enumeration code needs to access config space via
> pci_ops. The root complex driver implements pci_ops based on a trivial
> parsing of ranges (omitting irrelevant details):
>
> pci_op_read(devfn, pos) {
>loop_over_ranges_entries {
> if (to_devfn(ranges_entry.child)
On Sun, Mar 10, 2013 at 07:46:04PM -1000, Mitch Bradley wrote:
> So it seems that we are faced with two requirements that are somewhat at
> odds with one another.
>
> 1) Some of the root port bridge registers have to be accessed via config
> space access functions so common PCI enumeration code w
On 3/10/2013 9:46 PM, Thierry Reding wrote:
> On Sun, Mar 10, 2013 at 07:46:04PM -1000, Mitch Bradley wrote:
>> On 3/9/2013 8:55 PM, Jason Gunthorpe wrote:
>>> On Sat, Mar 09, 2013 at 06:52:13PM -1000, Mitch Bradley wrote:
>>>
Okay, I think I finally get it. The Marvell root port bridge setup
On Sun, Mar 10, 2013 at 04:09:37PM +0100, Thomas Petazzoni wrote:
> Dear Thierry Reding,
>
> On Fri, 8 Mar 2013 21:13:40 +0100, Thierry Reding wrote:
> > On Fri, Mar 08, 2013 at 01:02:46PM -0700, Jason Gunthorpe wrote:
> > > On Fri, Mar 08, 2013 at 09:43:11AM -1000, Mitch Bradley wrote:
> > [...]
On Sun, Mar 10, 2013 at 07:46:04PM -1000, Mitch Bradley wrote:
> On 3/9/2013 8:55 PM, Jason Gunthorpe wrote:
> > On Sat, Mar 09, 2013 at 06:52:13PM -1000, Mitch Bradley wrote:
> >
> >> Okay, I think I finally get it. The Marvell root port bridge setup
> >> registers look like standard config head
On 3/9/2013 8:55 PM, Jason Gunthorpe wrote:
> On Sat, Mar 09, 2013 at 06:52:13PM -1000, Mitch Bradley wrote:
>
>> Okay, I think I finally get it. The Marvell root port bridge setup
>> registers look like standard config headers, even though they aren't
>> really in config space (because you need
On 3/10/2013 5:06 AM, Thomas Petazzoni wrote:
> Dear Mitch Bradley,
>
> On Sat, 09 Mar 2013 19:04:51 -1000, Mitch Bradley wrote:
>
>> As stated in my recent reply to Jason, I thing the correct property is
>> "ranges". "Ranges" translates mappable child address space addresses
>> into parent add
Dear Thierry Reding,
On Fri, 8 Mar 2013 21:13:40 +0100, Thierry Reding wrote:
> On Fri, Mar 08, 2013 at 01:02:46PM -0700, Jason Gunthorpe wrote:
> > On Fri, Mar 08, 2013 at 09:43:11AM -1000, Mitch Bradley wrote:
> [...]
> > > 2) The "@0,0" and "@1,0" suffixes do not correspond to the reg values
>
Dear Mitch Bradley,
On Sat, 09 Mar 2013 19:04:51 -1000, Mitch Bradley wrote:
> As stated in my recent reply to Jason, I thing the correct property is
> "ranges". "Ranges" translates mappable child address space addresses
> into parent addresses, and that is exactly what is going on. A specific
On Sat, Mar 09, 2013 at 06:52:13PM -1000, Mitch Bradley wrote:
> Okay, I think I finally get it. The Marvell root port bridge setup
> registers look like standard config headers, even though they aren't
> really in config space (because you need a different access method for
> them, compared to r
On 3/8/2013 1:12 PM, Rob Herring wrote:
> On 03/08/2013 01:14 AM, Thierry Reding wrote:
>> On Thu, Mar 07, 2013 at 06:05:33PM -0600, Rob Herring wrote:
>>> On 03/07/2013 02:47 PM, Thierry Reding wrote:
>> [...]
In a nutshell (since some of the context isn't quoted anymore) the
problem tha
On 3/8/2013 3:31 PM, Jason Gunthorpe wrote:
> On Fri, Mar 08, 2013 at 01:46:13PM -1000, Mitch Bradley wrote:
>> On 3/8/2013 10:02 AM, Jason Gunthorpe wrote:
>>> On Fri, Mar 08, 2013 at 09:43:11AM -1000, Mitch Bradley wrote:
>>>
>> http://www.spinics.net/lists/arm-kernel/msg228749.html
On Fri, Mar 08, 2013 at 05:12:04PM -0600, Rob Herring wrote:
> On 03/08/2013 01:14 AM, Thierry Reding wrote:
> > On Thu, Mar 07, 2013 at 06:05:33PM -0600, Rob Herring wrote:
> >> On 03/07/2013 02:47 PM, Thierry Reding wrote:
> > [...]
> >>> In a nutshell (since some of the context isn't quoted anym
Dear Thierry Reding,
On Fri, 8 Mar 2013 20:12:27 +0100, Thierry Reding wrote:
> Oh well. I don't like it, but if that's the way it has to be, then so be
> it.
I don't like it too much either, but it's not a big problem either. It
works, and satisfies the DT requirements reasonably.
> Any reason
On Fri, Mar 08, 2013 at 01:46:13PM -1000, Mitch Bradley wrote:
> On 3/8/2013 10:02 AM, Jason Gunthorpe wrote:
> > On Fri, Mar 08, 2013 at 09:43:11AM -1000, Mitch Bradley wrote:
> >
> http://www.spinics.net/lists/arm-kernel/msg228749.html
> >>
> >> The example in that posting looks messed up t
On 3/8/2013 10:02 AM, Jason Gunthorpe wrote:
> On Fri, Mar 08, 2013 at 09:43:11AM -1000, Mitch Bradley wrote:
>
http://www.spinics.net/lists/arm-kernel/msg228749.html
>>
>> The example in that posting looks messed up to me.
>>
>> 1) It has "reg = <0x0800 0 0 0 0>", but 0x0800 0 0 is not a va
On 03/08/2013 01:14 AM, Thierry Reding wrote:
> On Thu, Mar 07, 2013 at 06:05:33PM -0600, Rob Herring wrote:
>> On 03/07/2013 02:47 PM, Thierry Reding wrote:
> [...]
>>> In a nutshell (since some of the context isn't quoted anymore) the
>>> problem that we're trying to solve is that some of the emb
On Fri, Mar 08, 2013 at 01:02:46PM -0700, Jason Gunthorpe wrote:
> On Fri, Mar 08, 2013 at 09:43:11AM -1000, Mitch Bradley wrote:
[...]
> > 2) The "@0,0" and "@1,0" suffixes do not correspond to the reg values
> > <0x0800 0 0 0 0> and <0x1000 0 0 0 0> using any rule that I know.
>
> @0,1,0 (bus,de
On Fri, Mar 08, 2013 at 09:43:11AM -1000, Mitch Bradley wrote:
> >> http://www.spinics.net/lists/arm-kernel/msg228749.html
>
> The example in that posting looks messed up to me.
>
> 1) It has "reg = <0x0800 0 0 0 0>", but 0x0800 0 0 is not a valid
> address in the address space defined by its p
On 3/8/2013 9:12 AM, Thierry Reding wrote:
> On Fri, Mar 08, 2013 at 09:52:28AM -0700, Jason Gunthorpe wrote:
>> On Fri, Mar 08, 2013 at 08:14:44AM +0100, Thierry Reding wrote:
>>> On Thu, Mar 07, 2013 at 06:05:33PM -0600, Rob Herring wrote:
On 03/07/2013 02:47 PM, Thierry Reding wrote:
>>> [.
On Fri, Mar 08, 2013 at 09:52:28AM -0700, Jason Gunthorpe wrote:
> On Fri, Mar 08, 2013 at 08:14:44AM +0100, Thierry Reding wrote:
> > On Thu, Mar 07, 2013 at 06:05:33PM -0600, Rob Herring wrote:
> > > On 03/07/2013 02:47 PM, Thierry Reding wrote:
> > [...]
> > > > In a nutshell (since some of the
On Fri, Mar 08, 2013 at 08:14:44AM +0100, Thierry Reding wrote:
> On Thu, Mar 07, 2013 at 06:05:33PM -0600, Rob Herring wrote:
> > On 03/07/2013 02:47 PM, Thierry Reding wrote:
> [...]
> > > In a nutshell (since some of the context isn't quoted anymore) the
> > > problem that we're trying to solve
On Thu, Mar 07, 2013 at 06:05:33PM -0600, Rob Herring wrote:
> On 03/07/2013 02:47 PM, Thierry Reding wrote:
[...]
> > In a nutshell (since some of the context isn't quoted anymore) the
> > problem that we're trying to solve is that some of the embedded SoCs
> > require per-root-port registers for
On 03/07/2013 02:47 PM, Thierry Reding wrote:
> On Thu, Mar 07, 2013 at 01:02:35PM -0700, Jason Gunthorpe wrote:
>> On Thu, Mar 07, 2013 at 08:48:30PM +0100, Thierry Reding wrote:
>>> On Thu, Mar 07, 2013 at 10:49:55AM -0700, Jason Gunthorpe wrote:
On Thu, Mar 07, 2013 at 09:08:32AM +0100, Thi
On Thu, Mar 07, 2013 at 01:02:35PM -0700, Jason Gunthorpe wrote:
> On Thu, Mar 07, 2013 at 08:48:30PM +0100, Thierry Reding wrote:
> > On Thu, Mar 07, 2013 at 10:49:55AM -0700, Jason Gunthorpe wrote:
> > > On Thu, Mar 07, 2013 at 09:08:32AM +0100, Thierry Reding wrote:
> > [...]
> > > > > Both have
54 matches
Mail list logo
