"Beaglebone and the 3.8 Kernel"

Hi Drew,

Thank you for finding this document/ I've read through it, but I'll need to read it a few more times.

I had not realized that that famous Linus rant was concerning this specific topic!

The document compares the old way with the new way, but I was not familiar with the old way either, so for me it's totally new regardless. I wish they wouldn't use 'foo' as an example instead of a concrete example (I feel it makes it harder to understand), although they have a more realistic example at the end (UART). Still, the document appears well-written so maybe I just need to reread several more times.

What I couldn't understand the reasoning of was this:

"Callback functions are impossible in a DT platform".

Does this mean that when a cape is detected, it won't run any specific function that you might want? And will only do pinmuxing (short of a kernel mod)?

As far as I can understand, in a traditional system a .ko file would get called, whereas with a DT-enabled system that won't happen.

For example, I noticed in the /lib/firmware file there is a 'weather cape' .dtbo file (just as a random example).

By converting to a device tree fragment file, I can see it contains a fragment for pinmuxing, but also contains some 'compatible' lines which I'd

originally thought meant that there must be an executable with that name somewhere, which would get called when the fragment is loaded.

I think this is not the case however.

If it won't run any specific function, then does that mean that a query needs to be done at boot time (e.g. using a startup script) that

would check to see if a slot has become populated (by the device tree mechanism) with your particular designed cape, and then use that script to call your executable (which may (say) send some initialization I2C commands or whatever, to get the cape up and running).

Hi Drew,

Thank you for finding this document/ I've read through it, but I'll need to read it a few more times.

I had not realized that that famous Linus rant was concerning this specific topic!

The document compares the old way with the new way, but I was not familiar with the old way either, so for me it's totally new regardless. I wish they wouldn't use 'foo' as an example instead of a concrete example (I feel it makes it harder to understand), although they have a more realistic example at the end (UART). Still, the document appears well-written so maybe I just need to reread several more times.

What I couldn't understand the reasoning of was this:

"Callback functions are impossible in a DT platform".

Does this mean that when a cape is detected, it won't run any specific function that you might want? And will only do pinmuxing (short of a kernel mod)?

As far as I can understand, in a traditional system a .ko file would get called, whereas with a DT-enabled system that won't happen.

For example, I noticed in the /lib/firmware file there is a 'weather cape' .dtbo file (just as a random example).

By converting to a device tree fragment file, I can see it contains a fragment for pinmuxing, but also contains some 'compatible' lines which I'd

originally thought meant that there must be an executable with that name somewhere, which would get called when the fragment is loaded.

I think this is not the case however.

If it won't run any specific function, then does that mean that a query needs to be done at boot time (e.g. using a startup script) that

would check to see if a slot has become populated (by the device tree mechanism) with your particular designed cape, and then use that script to call your executable (which may (say) send some initialization I2C commands or whatever, to get the cape up and running).

Well you didn't really have an 'everything-on-the-cape.ko' scenario before.  In the previous way of doing things you'd have some platform data in a board file and use that to register a driver, it's the drivers 'probe' function that gets called to do the necessary initialisation.

The new method changes things so that what used to be platform data comes from device tree, as the tree is parsed and the drivers loaded then the related drivers probe function will be loaded as normal.

The pinctrl driver is new and it's used to setup the hardware pinmux settings based on what's in devicetree.  So the difference would seem to be that previously the board file could have registered all the needed drivers, and also have done some additional setup for the specific cape. You can't do this second part with devicetree

While generically devicetree is just data and so no callbacks, since they've built the capemgr on top of the generic functionality I'd think that it could do the specific setup for a particular cape - but you still need that bit of initialisation code to be available somewhere.

That doc is probably the best writeup I've seen so far - why this stuff isn't obviously available from beagleboard.org or the circuitco wiki is beyond me though..