Re: pci-mvebu driver on km_kirkwood

Re: pci-mvebu driver on km_kirkwood

[Gerlando Falauto]

Hi guys [particularly Jason and Thierry],

sorry for the prolonged silence, here I am back again...

On 08/09/2013 04:01 PM, Thierry Reding wrote:
> On Wed, Jul 31, 2013 at 02:50:34PM -0600, Jason Gunthorpe wrote:
>> On Wed, Jul 31, 2013 at 11:00:45AM +0200, Thomas Petazzoni wrote:
>>
>>>> Actually, the main reason for trying to use this driver was because I
>>>> wanted to model a PCIe *device* within the device tree, so to expose its
>>>> GPIOs and IRQs to be referenced (through phandles) from other device
>>>> tree nodes. The way I understand it, turns out this is not the way to
>>>> go, as PCI/PCIe are essentially enumerated busses, so you're not
>>>> supposed to -and it's not a trivial task to- put any information about
>>>> real devices within the device tree.
>>>> Do you have any suggestion about that?
>>>
>>> Indeed, PCI/PCIe devices are enumerated dynamically, so they are not
>>> listed in the Device Tree, so there's no way to "attach" more
>>> information to them.
>>>
>>> Device Tree people, any suggestion about the above question?
>>
>> No, that isn't true.
>>
>> Device tree can include the discovered PCI devices, you have to use
>> the special reg encoding and all that weirdness, but it does work. The
>> of_node will be attached to the struct pci device automatically.

So you mean that, assuming I knew the topology, I could populate the 
device tree in advance (e.g. statically), so that it already includes 
*devices* which will be further discovered during probing?
Or else you mean the {firmware,u-boot} can do that prior to starting the OS?
If either of the above is true, could you please suggest some example 
(or some way to get one)?
I assume the "reg" property (and the after-"@" node name) will need to 
encode (at least) the device number, is that right?

I tried reading the "PCI Bus Binding to Open Firmware" but I could not 
make complete sense out of it...

>> On server/etc DT platforms the firmware will do PCI discovery and
>> resource assignment then dump all those results into DT for the OS to
>> reference.
>>
>> This is a major reason why we wanted to see the standard PCI DT be
>> used for Marvell/etc, the existing infrastructure for this is
>> valuable.
>>
>> AFAIK, Thierry has tested this on tegra, and I am doing it on Kirkwood
>> (though not yet with the new driver).

Could you please give a pointer to some example of this? I'm not quite 
sure I understand what you guys are talking about.

>>
>> It is useful for exactly the reason stated - you can describe GPIOs,
>> I2C busses, etc, etc in DT and then upon load of the PCI driver engage
>> the DT code to populate and connect all that downstream
>> infrastructure.

I'm not 100% sure I made myself clear though.
What I would like to do is to have *other* parts of the device tree be 
able to reference (i.e., connect to, through phandles) a PCI device 
(because it provides a GPIO, for instance).
Is that also what you mean?

> Obviously this doesn't work in general purpose systems because the PCI
> hierarchy needs to be hardcoded in the DT. If you start adding and
> removing PCI devices that will likely change the hierarchy and break
> this matching of PCI device to DT node.

Yes, I guess in that case (if ever) we would need some other way that 
the device number (is that the same as the physical slot?) to specify a 
particular "hotplug" device (i.e. maybe a serial number or so)?
But that's definitely out of scope here.

>
> It's quite unlikely to have a need to hook up GPIOs or IRQs via DT in a
> general purpose system, though, so I don't really see that being a big
> problem.

Agreed.

>
> Thierry

Thanks again for your patience...

Gerlando

Re: pci-mvebu driver on km_kirkwood

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 4118 bytes --]

On Mon, Aug 26, 2013 at 11:27:06AM +0200, Gerlando Falauto wrote:
> Hi guys [particularly Jason and Thierry],
> 
> sorry for the prolonged silence, here I am back again...
> 
> On 08/09/2013 04:01 PM, Thierry Reding wrote:
> >On Wed, Jul 31, 2013 at 02:50:34PM -0600, Jason Gunthorpe wrote:
> >>On Wed, Jul 31, 2013 at 11:00:45AM +0200, Thomas Petazzoni wrote:
> >>
> >>>>Actually, the main reason for trying to use this driver was because I
> >>>>wanted to model a PCIe *device* within the device tree, so to expose its
> >>>>GPIOs and IRQs to be referenced (through phandles) from other device
> >>>>tree nodes. The way I understand it, turns out this is not the way to
> >>>>go, as PCI/PCIe are essentially enumerated busses, so you're not
> >>>>supposed to -and it's not a trivial task to- put any information about
> >>>>real devices within the device tree.
> >>>>Do you have any suggestion about that?
> >>>
> >>>Indeed, PCI/PCIe devices are enumerated dynamically, so they are not
> >>>listed in the Device Tree, so there's no way to "attach" more
> >>>information to them.
> >>>
> >>>Device Tree people, any suggestion about the above question?
> >>
> >>No, that isn't true.
> >>
> >>Device tree can include the discovered PCI devices, you have to use
> >>the special reg encoding and all that weirdness, but it does work. The
> >>of_node will be attached to the struct pci device automatically.
> 
> So you mean that, assuming I knew the topology, I could populate the
> device tree in advance (e.g. statically), so that it already
> includes *devices* which will be further discovered during probing?
> Or else you mean the {firmware,u-boot} can do that prior to starting the OS?
> If either of the above is true, could you please suggest some
> example (or some way to get one)?
> I assume the "reg" property (and the after-"@" node name) will need
> to encode (at least) the device number, is that right?
> 
> I tried reading the "PCI Bus Binding to Open Firmware" but I could
> not make complete sense out of it...

You can find an example of this here:

	https://gitorious.org/thierryreding/linux/commit/b85c03d73288f6e376fc158ceac30f29680b4192

It's been quite some time that I've actually tested that, but it used to
work properly. What you basically need to do is represent the whole bus
hierarchy within the DT. In the above example there's the top-level root
port (pci@1,0), which provides a bus (1) on which there's a switch named
pci@0,0. That switch provides another bus (2) on which more devices are
listed (pci@[012345],0). Those are all downstream ports providing
separate busses again and have a single device attached to them.

You can pretty much arbitrarily nest nodes that way to represent any
hierarchy you want. The tricky part is to get the node numbering right
but `lspci -t' helps quite a bit with that.

> >>It is useful for exactly the reason stated - you can describe GPIOs,
> >>I2C busses, etc, etc in DT and then upon load of the PCI driver engage
> >>the DT code to populate and connect all that downstream
> >>infrastructure.
> 
> I'm not 100% sure I made myself clear though.
> What I would like to do is to have *other* parts of the device tree
> be able to reference (i.e., connect to, through phandles) a PCI
> device (because it provides a GPIO, for instance).
> Is that also what you mean?

Yes. In the example above you'll see that there's actually a GPIO
controller (pci@1,0/pci@0,0/pci@2,0/pci@0,0), so you could simply
associate a phandle with it, as in:

	gpioext: pci@0,0 {
		...
	};

And then hook up other devices to it using the regular notation:

	foo {
		...
		enable-gpios = <&gpioext 0 0>;
		...
	};

That's not done in this example but I've actually used something very
similar to that on an x86 platform to hook up the reset pin of an I2C
touchscreen controller to a GPIO controller, where both the I2C and
GPIO controllers were on the PCI bus.

I can't find that snippet right now, but I can look more thoroughly if
the above doesn't help you at all.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: pci-mvebu driver on km_kirkwood

[Gerlando Falauto]

Hi Thierry,

On 08/26/2013 02:02 PM, Thierry Reding wrote:
> On Mon, Aug 26, 2013 at 11:27:06AM +0200, Gerlando Falauto wrote:
>> Hi guys [particularly Jason and Thierry],
>>
>> sorry for the prolonged silence, here I am back again...
>>
>> On 08/09/2013 04:01 PM, Thierry Reding wrote:
>>> On Wed, Jul 31, 2013 at 02:50:34PM -0600, Jason Gunthorpe wrote:
>>>> On Wed, Jul 31, 2013 at 11:00:45AM +0200, Thomas Petazzoni wrote:
>>>>
>>>>>> Actually, the main reason for trying to use this driver was because I
>>>>>> wanted to model a PCIe *device* within the device tree, so to expose its
>>>>>> GPIOs and IRQs to be referenced (through phandles) from other device
>>>>>> tree nodes. The way I understand it, turns out this is not the way to
>>>>>> go, as PCI/PCIe are essentially enumerated busses, so you're not
>>>>>> supposed to -and it's not a trivial task to- put any information about
>>>>>> real devices within the device tree.
>>>>>> Do you have any suggestion about that?
>>>>>
>>>>> Indeed, PCI/PCIe devices are enumerated dynamically, so they are not
>>>>> listed in the Device Tree, so there's no way to "attach" more
>>>>> information to them.
>>>>>
>>>>> Device Tree people, any suggestion about the above question?
>>>>
>>>> No, that isn't true.
>>>>
>>>> Device tree can include the discovered PCI devices, you have to use
>>>> the special reg encoding and all that weirdness, but it does work. The
>>>> of_node will be attached to the struct pci device automatically.
>>
>> So you mean that, assuming I knew the topology, I could populate the
>> device tree in advance (e.g. statically), so that it already
>> includes *devices* which will be further discovered during probing?
>> Or else you mean the {firmware,u-boot} can do that prior to starting the OS?
>> If either of the above is true, could you please suggest some
>> example (or some way to get one)?
>> I assume the "reg" property (and the after-"@" node name) will need
>> to encode (at least) the device number, is that right?
>>
>> I tried reading the "PCI Bus Binding to Open Firmware" but I could
>> not make complete sense out of it...
>
> You can find an example of this here:
>
> 	https://gitorious.org/thierryreding/linux/commit/b85c03d73288f6e376fc158ceac30f29680b4192
>

Thanks for your precious feedback. Unfortunately gitorious' servers are 
offline right now... :-(

> It's been quite some time that I've actually tested that, but it used to
> work properly. What you basically need to do is represent the whole bus
> hierarchy within the DT. In the above example there's the top-level root
> port (pci@1,0), which provides a bus (1) on which there's a switch named
> pci@0,0. That switch provides another bus (2) on which more devices are
> listed (pci@[012345],0). Those are all downstream ports providing
> separate busses again and have a single device attached to them.
>
> You can pretty much arbitrarily nest nodes that way to represent any
> hierarchy you want. The tricky part is to get the node numbering right
> but `lspci -t' helps quite a bit with that.

One last question though... what does then the numbering ("@a,b") stand 
for? I assume if the output of a plain (i.e. no params) 'lspci' is

bb:dd.f (bus:device.function)

I should only have a "pci@dd,f" node, with the bus numbering being 
imposed by the hierarchy after an actual probing, right?
So the actual bus number is never listed in the device tree (whereas the 
"@device,function" is). Is that right?

>>>> It is useful for exactly the reason stated - you can describe GPIOs,
>>>> I2C busses, etc, etc in DT and then upon load of the PCI driver engage
>>>> the DT code to populate and connect all that downstream
>>>> infrastructure.
>>
>> I'm not 100% sure I made myself clear though.
>> What I would like to do is to have *other* parts of the device tree
>> be able to reference (i.e., connect to, through phandles) a PCI
>> device (because it provides a GPIO, for instance).
>> Is that also what you mean?
>
> Yes. In the example above you'll see that there's actually a GPIO
> controller (pci@1,0/pci@0,0/pci@2,0/pci@0,0), so you could simply
> associate a phandle with it, as in:
>
> 	gpioext: pci@0,0 {
> 		...
> 	};
>
> And then hook up other devices to it using the regular notation:
>
> 	foo {
> 		...
> 		enable-gpios = <&gpioext 0 0>;
> 		...
> 	};
>
> That's not done in this example but I've actually used something very
> similar to that on an x86 platform to hook up the reset pin of an I2C
> touchscreen controller to a GPIO controller, where both the I2C and
> GPIO controllers were on the PCI bus.
>
> I can't find that snippet right now, but I can look more thoroughly if
> the above doesn't help you at all.
>
> Thierry
>

I guess I'll have to wait until gitorious.org actually does come back 
up... then you'll definitely hear from me again. :-)

Thanks!
Gerlando

Re: pci-mvebu driver on km_kirkwood

[Jason Gunthorpe]

On Mon, Aug 26, 2013 at 04:49:23PM +0200, Gerlando Falauto wrote:

> One last question though... what does then the numbering ("@a,b")
> stand for? I assume if the output of a plain (i.e. no params)
> 'lspci' is

It is device,function, but it is only descriptive and not used by
Linux.
 
> I should only have a "pci@dd,f" node, with the bus numbering being
> imposed by the hierarchy after an actual probing, right?
> So the actual bus number is never listed in the device tree (whereas
> the "@device,function" is). Is that right?

The reg must encode the bus number according to the OF format:

               33222222 22221111 11111100 00000000
               10987654 32109876 54321098 76543210
 phys.hi cell: npt000ss bbbbbbbb dddddfff rrrrrrrr
phys.mid cell: hhhhhhhh hhhhhhhh hhhhhhhh hhhhhhhh
 phys.lo cell: llllllll llllllll llllllll llllllll
 
bbbbbbbb is the 8-bit Bus Number
ddddd is the 5-bit Device Number
fff is the 3-bit Function Number

Others are 0.

Jason

Re: pci-mvebu driver on km_kirkwood

[Gerlando Falauto]

Hi folks,

thank you for your patience...

So, thanks to Thierry's example:

 > 
https://gitorious.org/thierryreding/linux/commit/b85c03d73288f6e376fc158ceac30f29680b4192

and Jason's explanation:

 > The reg must encode the bus number according to the OF format:
 >
 >                 33222222 22221111 11111100 00000000
 >                 10987654 32109876 54321098 76543210
 >   phys.hi cell: npt000ss bbbbbbbb dddddfff rrrrrrrr
 > phys.mid cell: hhhhhhhh hhhhhhhh hhhhhhhh hhhhhhhh
 >   phys.lo cell: llllllll llllllll llllllll llllllll
 >
 > bbbbbbbb is the 8-bit Bus Number
 > ddddd is the 5-bit Device Number
 > fff is the 3-bit Function Number
 >
 > Others are 0.

I'm finally starting to make some sense out of this, and I checked that 
Jason's statement is indeed true, at least on 3.10:

 > Device tree can include the discovered PCI devices, you have to use
 > the special reg encoding and all that weirdness, but it does work. The
 > of_node will be attached to the struct pci device automatically.

[Hi latency was also due to other activities, not just the low 
throughput of my brain cells] ;-)

I have one last question for Thierry though: what's the point of things 
such as

+					pci@0,0 {
+						compatible = "opencores,spi";

(apart from clarity, of course)?
I mean, wouldn't the driver be bound to the device through its PCI 
vendor ID / device ID?
Are we also supposed to register a platform driver based on a compatible 
string instead?

Thanks again guys!
Gerlando
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pci-mvebu driver on km_kirkwood

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]

On Mon, Nov 04, 2013 at 03:49:59PM +0100, Gerlando Falauto wrote:
> Hi folks,
> 
> thank you for your patience...
> 
> So, thanks to Thierry's example:
> 
> > https://gitorious.org/thierryreding/linux/commit/b85c03d73288f6e376fc158ceac30f29680b4192
> 
> and Jason's explanation:
> 
> > The reg must encode the bus number according to the OF format:
> >
> >                 33222222 22221111 11111100 00000000
> >                 10987654 32109876 54321098 76543210
> >   phys.hi cell: npt000ss bbbbbbbb dddddfff rrrrrrrr
> > phys.mid cell: hhhhhhhh hhhhhhhh hhhhhhhh hhhhhhhh
> >   phys.lo cell: llllllll llllllll llllllll llllllll
> >
> > bbbbbbbb is the 8-bit Bus Number
> > ddddd is the 5-bit Device Number
> > fff is the 3-bit Function Number
> >
> > Others are 0.
> 
> I'm finally starting to make some sense out of this, and I checked
> that Jason's statement is indeed true, at least on 3.10:
> 
> > Device tree can include the discovered PCI devices, you have to use
> > the special reg encoding and all that weirdness, but it does work. The
> > of_node will be attached to the struct pci device automatically.
> 
> [Hi latency was also due to other activities, not just the low
> throughput of my brain cells] ;-)
> 
> I have one last question for Thierry though: what's the point of
> things such as
> 
> +					pci@0,0 {
> +						compatible = "opencores,spi";
> 
> (apart from clarity, of course)?
> I mean, wouldn't the driver be bound to the device through its PCI
> vendor ID / device ID?
> Are we also supposed to register a platform driver based on a
> compatible string instead?

I think that compatible property is completely bogus. Or at least the
value is. The primary reason why I included them was for descriptive
purposes.

According to section 2.5 of the PCI Bus Binding to Open Firmware[0] this
should be something like:

	compatible = "pciVVVV,DDDD";

where VVVV is the vendor ID and DDDD is the device ID, both in
hexadecimal. Section 2.5 lists a few more, but I'm not sure exactly
which would really be required.

I'm not even sure that they really are required at all. The drivers will
certainly be able to bind to them via the standard vendor and device ID
matching as you say. And no, no platform driver required.

Thierry

[0]: http://www.openfirmware.org/1275/bindings/pci/pci2_1.pdf

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]