on the topic of of_device resources...

on the topic of of_device resources...

[David Miller]

Since it came to my attention due to the build error fix
I just had to fix, I figured I'd mention some things.

Right now, powerpc and sparc differ in how they resolve
interrupts and resources.

Powerpc uses an on-demand model, whereas Sparc pre-resolves
everything at bootup when parsing the OF tree.

Unfortunately they operate on differing objects too, otherwise I could
provide routines to match the interfaces that powerpc OF drivers want
:-/

Powerpc drivers want device_node objects, whereas sparc roots all
driver usable objects under of_platform_bus using of_device objects
(which point to the device_node if the driver needs that).

Inside of the of_device is where we hang the fully resolved resources
and interrupts.

I'd like to see consolidation in this area, and in return I'll be
compiling all of your PPC_OF devices in my allmodconfig builds on
sparc :-)

Re: on the topic of of_device resources...

[Benjamin Herrenschmidt]

On Mon, 2008-05-05 at 00:59 -0700, David Miller wrote:
> Since it came to my attention due to the build error fix
> I just had to fix, I figured I'd mention some things.
> 
> Right now, powerpc and sparc differ in how they resolve
> interrupts and resources.
> 
> Powerpc uses an on-demand model, whereas Sparc pre-resolves
> everything at bootup when parsing the OF tree.

We used to do that but moved away from that model for various reasons.

> Unfortunately they operate on differing objects too, otherwise I could
> provide routines to match the interfaces that powerpc OF drivers want
> :-/

Yeah, we have more/less "generic" parsers that operate on raw device
nodes. I prefer that because we don't necessarily have of_devices in all
cases (or rather, there's a whole lot of cases where we want to resolve
things without having an of_device).

> Powerpc drivers want device_node objects, whereas sparc roots all
> driver usable objects under of_platform_bus using of_device objects
> (which point to the device_node if the driver needs that).

You should easily be able to use device_node based parsers to fill up
your of_platform_bus objects no ?

> Inside of the of_device is where we hang the fully resolved resources
> and interrupts.
> 
> I'd like to see consolidation in this area, and in return I'll be
> compiling all of your PPC_OF devices in my allmodconfig builds on
> sparc :-)

Heh :-)

Well, we aren't totally clear as to whether we'll use of_device much or
not in the long term. For bus types that already have their own
descendant of struct device (such as PCI, but also i2c, USB, etc...) it
makes little sense to create a "special" version with OF device...

That leaves platform devices, and there, experience has shown that it's
not very practical neither when a driver is shared between powerpc and
some other non-OF arch.

So we are trying to move toward a slightly different approach: Any
device can optionally be linked to a device_node (via dev_archdata), and
we provide "constructors" to build the various kind of struct device
descendants based on the device nodes.

This is in no way something done though. As you may have noticed,
macio_device is still around, though on the other hand, we have code to
build the PCI tree from the ground up straight off the OF nodes (that
you may want to use too at one point ...) though it's not using the
"constructor" approach. Some work hsa been done in the i2c layer to
create i2c devices based on device nodes, and there are other areas like
that.

Note that I haven't done much in that area myself other than
implementing some of the parsers a while ago, this is mostly driven by
others on the list, look around embedded folks and freescale :-)

It would be nice to find a nice generic way to "register" constructors
for devices based on OF nodes, and have them called automagically,
though there are a few pitfalls that may look like details at first but
can be nasty to do that properly. The main one is that the rules to
create a device can depend either on the bus it sits on (ie pci_dev)
rather than properties within the device node itself, or on the contrary
within the device node itself (platform devices typically). We might
need something "special" for a second-pass lookup for platform devices.
In addition, keeping track of parents would be nice to lay things out
properly in sysfs.

Cheers,
Ben.

Re: on the topic of of_device resources...

[David Miller]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Mon, 05 May 2008 18:26:11 +1000

> Well, we aren't totally clear as to whether we'll use of_device much or
> not in the long term. For bus types that already have their own
> descendant of struct device (such as PCI, but also i2c, USB, etc...) it
> makes little sense to create a "special" version with OF device...
> 
> That leaves platform devices, and there, experience has shown that it's
> not very practical neither when a driver is shared between powerpc and
> some other non-OF arch.
> 
> So we are trying to move toward a slightly different approach: Any
> device can optionally be linked to a device_node (via dev_archdata), and
> we provide "constructors" to build the various kind of struct device
> descendants based on the device nodes.

I see, thanks for the info.

> This is in no way something done though. As you may have noticed,
> macio_device is still around, though on the other hand, we have code to
> build the PCI tree from the ground up straight off the OF nodes (that
> you may want to use too at one point ...) though it's not using the
> "constructor" approach. Some work hsa been done in the i2c layer to
> create i2c devices based on device nodes, and there are other areas like
> that.

I already build the PCI device tree on sparc64 strictly using
the OF device tree. :-)

My plan on the sparc side is to remove the SBUS device type and bus
entirely, as well as the EBUS layer I have.  All of it can use
of_device nodes on of_platform_bus.  Even the DMA stuff just falls out
of everything transparently because even that's all done via
dev_archdata.

If you look at the SBUS layer, it's simply replicating OF device
node objects for things that sit underneath SBUS bus nodes.  And
it's like this because 32-bit sparc doesn't do the DMA stuff
transparently like 64-bit sparc does.

The of_platform_bus probing layer is extremely clean and I like
how simple it is to write drivers using it.  The drivers look
like normal PCI device drivers, both in terms of matching
and in terms of resource/irq fetching.

I even use this for the core timeofday clock probing on sparc64.

Re: on the topic of of_device resources...

[Benjamin Herrenschmidt]

On Mon, 2008-05-05 at 01:44 -0700, David Miller wrote:
> 
> My plan on the sparc side is to remove the SBUS device type and bus
> entirely, as well as the EBUS layer I have.  All of it can use
> of_device nodes on of_platform_bus.  Even the DMA stuff just falls out
> of everything transparently because even that's all done via
> dev_archdata.
> 
> If you look at the SBUS layer, it's simply replicating OF device
> node objects for things that sit underneath SBUS bus nodes.  And
> it's like this because 32-bit sparc doesn't do the DMA stuff
> transparently like 64-bit sparc does.
>
> The of_platform_bus probing layer is extremely clean and I like
> how simple it is to write drivers using it.  The drivers look
> like normal PCI device drivers, both in terms of matching
> and in terms of resource/irq fetching.
> 
> I even use this for the core timeofday clock probing on sparc64.

Well, I agree it's nice and sleek for bus types you have complete
control on. The problem is when you start sharing with other
architecture :-) (well, other than powerpc & sparc !).

Which is why I might just stick to macio_device the way it is since
that's a totally local bus type, despite moving toward the different
approach I exposed for other things.

I think we need to continue supporting both approaches in the long run,
but that also means that low level parsers should as much as possible
remain based stictly on device node.

Now regarding using some kind of device for the timeofday clock probing,
well that's a different issue :-) We do need to get rid of our ppc_md.
stuff for that and move toward the new RTC infrastructure, which means
that our TODs will be proved like other devices.

Now, how so will depend on what TOD we have... i2c TODs (very common in
embedded) already have the necessary bits to be probed via the OF/i2c
bindings, creating i2c_device objects. Platform custom things like
PowerMac CUDA or PMU could be of_platform_devices. Etc...

Cheers,
Ben.