On Wed, Mar 26, 2014 at 09:28:42AM -0500, Rob Herring wrote:
> On Wed, Mar 19, 2014 at 6:12 PM, Tanmay Inamdar <[email protected]> wrote:
> > This patch adds the device tree nodes for APM X-Gene PCIe controller and
> > PCIe clock interface. Since X-Gene SOC supports maximum 5 ports, 5 dts
> > nodes are added.
>
> [snip]
>
> > + pcie0: pcie@1f2b0000 {
> > + status = "disabled";
> > + device_type = "pci";
> > + compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie";
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > + reg = < 0x00 0x1f2b0000 0x0 0x00010000 /* Controller registers */
> > + 0xe0 0xd0000000 0x0 0x00200000>; /* PCI config space */
>
Resurecting an old thread as this is relevant to what I'm doing at the moment:
> Where is the right place for config space? This binding has it here
> and others have it in ranges. Given that config space type is defined
> for ranges, I would think that is the right place. But Liviu's patches
> do not process config space entries in ranges. Perhaps we need a
> config space resource populated in the bridge struct.
I have found out that we cannot pasd the config ranges from the DT into the
pci_host_bridge structure as the PCI framework doesn't have a resource type
for config resources. Leaving the translation between range flags and
resource type as is (filtered through the IORESOURCE_TYPE_BITS) will lead
to a resource type of value zero, which is not recognised by any resource
handling API so bridge configuration and bus scanning will barf.
I'm looking for suggestions here, as Jason Gunthorpe suggested that we
should be able to parse config ranges if they conform to the ECAM part
of the PCI standard.
Best regards,
Liviu
>
> Rob
>
>
> > + reg-names = "csr", "cfg";
> > + ranges = <0x01000000 0x00 0x00000000 0xe0 0x00000000 0x00 0x00010000 /* io */
> > + 0x02000000 0x00 0x10000000 0xe0 0x10000000 0x00 0x80000000>; /* mem */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-------------------
.oooO
( )
\ ( Oooo.
\_) ( )
) /
(_/
One small step
for me ...
On Wed, Apr 16, 2014 at 06:05:45PM +0100, Liviu Dudau wrote:
> I have found out that we cannot pasd the config ranges from the DT into the
> pci_host_bridge structure as the PCI framework doesn't have a resource type
> for config resources. Leaving the translation between range flags and
> resource type as is (filtered through the IORESOURCE_TYPE_BITS) will lead
> to a resource type of value zero, which is not recognised by any resource
> handling API so bridge configuration and bus scanning will barf.
>
> I'm looking for suggestions here, as Jason Gunthorpe suggested that we
> should be able to parse config ranges if they conform to the ECAM part
> of the PCI standard.
The thinking here is the ranges should be well defined and general, it
isn't a dumping ground for driver specific stuff.
No spec says you can put config space into the ranges at all, nobody
should be doing that today, obviously some cases were missed during
review..
The comment about ECAM was intended as a general guidance on what
config space in ranges could/should be used for.
Right now config space shouldn't propagate out side any driver, so you
can probably just filter it in your generic code, and make it very hard
and obviously wrong for a driver to parse ranges for config space, so
we don't get more usages.
Jason
On Wed, Apr 16, 2014 at 03:21:04PM -0600, Jason Gunthorpe wrote:
> On Wed, Apr 16, 2014 at 06:05:45PM +0100, Liviu Dudau wrote:
>
> > I have found out that we cannot pasd the config ranges from the DT into the
> > pci_host_bridge structure as the PCI framework doesn't have a resource type
> > for config resources. Leaving the translation between range flags and
> > resource type as is (filtered through the IORESOURCE_TYPE_BITS) will lead
> > to a resource type of value zero, which is not recognised by any resource
> > handling API so bridge configuration and bus scanning will barf.
> >
> > I'm looking for suggestions here, as Jason Gunthorpe suggested that we
> > should be able to parse config ranges if they conform to the ECAM part
> > of the PCI standard.
>
> The thinking here is the ranges should be well defined and general, it
> isn't a dumping ground for driver specific stuff.
>
> No spec says you can put config space into the ranges at all, nobody
> should be doing that today, obviously some cases were missed during
> review..
ePAPR documents allows that when ss == 00.
>
> The comment about ECAM was intended as a general guidance on what
> config space in ranges could/should be used for.
>
> Right now config space shouldn't propagate out side any driver, so you
> can probably just filter it in your generic code, and make it very hard
> and obviously wrong for a driver to parse ranges for config space, so
> we don't get more usages.
OK, this goes slightly against your email from 26th March:
"When we talked about this earlier on the DT bindings list the
consensus seemed to be that configuration MMIO ranges should only be
used if the underlying memory was exactly ECAM, and was not to be used
for random configuration related register blocks.
The rational being that generic code, upon seeing that ranges entry,
could just go ahead and assume ECAM mapping."
What I'm saying is that the only code that will see this ranges entry will
be the parsing code as if we try to create a resource out of the range
and add it to the host bridge structure (not driver) we will confuse the
rest of the pci_host_bridge API. So we cannot do any ECAM accesses (yet?).
Best regards,
Liviu
>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-------------------
.oooO
( )
\ ( Oooo.
\_) ( )
) /
(_/
One small step
for me ...
On Thu, Apr 17, 2014 at 01:20:42AM +0100, Liviu Dudau wrote:
> > No spec says you can put config space into the ranges at all, nobody
> > should be doing that today, obviously some cases were missed during
> > review..
>
> ePAPR documents allows that when ss == 00.
Which do you mean? The 'PCI Bus Binding' spec has fairly specific
language on how ranges should be used and interpreted, and it
precludes doing anything meaningful with config space (like requiring
b,d,f and r to be zeroed when doing compares against ranges, requiring
the ranges to represent the bridge windows, etc).
There is certainly room to invent something (like ECAM mapping) but
nothing is specified in that document.
The ePAPR document I have doesn't talk about PCI..
If you've found a document that defines how it works then that changes
things.. ;)
> > The comment about ECAM was intended as a general guidance on what
> > config space in ranges could/should be used for.
> >
> > Right now config space shouldn't propagate out side any driver, so you
> > can probably just filter it in your generic code, and make it very hard
> > and obviously wrong for a driver to parse ranges for config space, so
> > we don't get more usages.
>
> OK, this goes slightly against your email from 26th March:
>
> "When we talked about this earlier on the DT bindings list the
> consensus seemed to be that configuration MMIO ranges should only be
> used if the underlying memory was exactly ECAM, and was not to be used
> for random configuration related register blocks.
>
> The rational being that generic code, upon seeing that ranges entry,
> could just go ahead and assume ECAM mapping."
>
> What I'm saying is that the only code that will see this ranges entry will
> be the parsing code as if we try to create a resource out of the range
> and add it to the host bridge structure (not driver) we will confuse the
> rest of the pci_host_bridge API. So we cannot do any ECAM accesses (yet?).
Sorry if this seems unclear, what you quoted was from a specification
standpoint - someday defining config space ranges to be the ECAM
window makes the most sense. This is from the direction of precluding
drivers from using it for random purposes.
>From a Linux standpoint, there is simply no infrastructure for generic
config access outside the driver, so config space must remain
contained in the driver, and shouldn't leak into the host bridge or
other core structures.
I think the shared code you are working on should simply ignore config
ss ranges entirely, they have no defined meaning..
Regards,
Jason
On Thu, Apr 17, 2014 at 02:24:34AM +0100, Jason Gunthorpe wrote:
> On Thu, Apr 17, 2014 at 01:20:42AM +0100, Liviu Dudau wrote:
>
> > > No spec says you can put config space into the ranges at all, nobody
> > > should be doing that today, obviously some cases were missed during
> > > review..
> >
> > ePAPR documents allows that when ss == 00.
>
> Which do you mean? The 'PCI Bus Binding' spec has fairly specific
> language on how ranges should be used and interpreted, and it
> precludes doing anything meaningful with config space (like requiring
> b,d,f and r to be zeroed when doing compares against ranges, requiring
> the ranges to represent the bridge windows, etc).
>
> There is certainly room to invent something (like ECAM mapping) but
> nothing is specified in that document.
On more carefull reading of the Power_ePAPR_APPROVED_v1.0.pdf document
that I have I agree, there is no meaningful way of describing one's
config ranges.
>
> The ePAPR document I have doesn't talk about PCI..
>
> If you've found a document that defines how it works then that changes
> things.. ;)
>
> > > The comment about ECAM was intended as a general guidance on what
> > > config space in ranges could/should be used for.
> > >
> > > Right now config space shouldn't propagate out side any driver, so you
> > > can probably just filter it in your generic code, and make it very hard
> > > and obviously wrong for a driver to parse ranges for config space, so
> > > we don't get more usages.
> >
> > OK, this goes slightly against your email from 26th March:
> >
> > "When we talked about this earlier on the DT bindings list the
> > consensus seemed to be that configuration MMIO ranges should only be
> > used if the underlying memory was exactly ECAM, and was not to be used
> > for random configuration related register blocks.
> >
> > The rational being that generic code, upon seeing that ranges entry,
> > could just go ahead and assume ECAM mapping."
> >
> > What I'm saying is that the only code that will see this ranges entry will
> > be the parsing code as if we try to create a resource out of the range
> > and add it to the host bridge structure (not driver) we will confuse the
> > rest of the pci_host_bridge API. So we cannot do any ECAM accesses (yet?).
>
> Sorry if this seems unclear, what you quoted was from a specification
> standpoint - someday defining config space ranges to be the ECAM
> window makes the most sense. This is from the direction of precluding
> drivers from using it for random purposes.
>
> From a Linux standpoint, there is simply no infrastructure for generic
> config access outside the driver, so config space must remain
> contained in the driver, and shouldn't leak into the host bridge or
> other core structures.
>
> I think the shared code you are working on should simply ignore config
> ss ranges entirely, they have no defined meaning..
Agree. Less things to code for is always better!
Best regards,
Liviu
>
> Regards,
> Jason
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯