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..
I'm the author of that document. Glad that you've found it helpful.
As to why it's not available from beagleboard.org and circuitco wiki, it is being rectified right now.
Had to have a few review cycles before it went out.
The problem with working on the cutting edge is that stuff just haven't got around to be documented
thoroughly, so for new comers it sure is indimidating at first.
We're also working on getting some examples of using the standard peripherals on the next release,
which will help people get their designs working much faster.
Don't hesitate to ask for more information, or to point areas that the document needs help.
Welcome to element14! Glad you have you here and I look forward to gleaming insights from you.
Looks like you have a cool community going on here.
That's a wonderful document, shedding light in a complex area that's been taxing a lot of people. And it's not only highly informative but also very clearly written. A great resource, many thanks!
We really do understand just how new this stuff is, so thankyou for the doc. It really helps.
If you have time, I have one question.. Suppose I wanted to access the userspace overlay loading support from something like a Raspberry Pi (or Sabre-Lite, Cubieboard, Wandboard etc), am I able to do that with your current code ?
As far as I can tell it's only exposed through the beaglebone cape manager currently, but I can think of lots of scenarios where I wouldn't have the cape manager (or simply wouldn't want it) but the base overlay loading feature could be really useful.
Prototyping capes generally don't have the eeprom describing the cape, so the expected answer is (probably) that it can be done manually, not just through the cape manager. Other boards don't have capes anyway, and DT is intended as a board- and architecture-independent technology. Also, even in the presence of capes, one would still want the ability to override the cape manager's operation in some cases, for a subset of the capes currently present perhaps.
Confirmation that this is the intended direction of development would be very useful.
All of the use cases you have mentioned are already handled.
1) Prototyping capes can be override-loaded via three methods; kernel command line, base DT file override and runtime loading.
2) A command line option disables automatic loading of matching capes.
3) Virtual capes are already included which provide canned peripheral configuration for various cases, i.e. standard setup for UART/I2C/SPI/ADC and others. There's nothing that ties the cape manager to only the external connectors.
Hope this clear enough.
That's a very concise description of your coverage of the problem space, and covers all my existing questions.
The document describes the mechanism pretty thoroughly.
In a nutshell, the beaglebone cape manager, uses the generally available DT Overlays functionality provided by the kernel.
So the only requirement for any other platform that wants to use it, would be:
a) To be using Device Tree.
b) A platform specific manager to handle the probing of 'capes' or whatever they're called for that platform.
As far as I can tell RPi doesn't support DT yet (but the A13 based ones do, and Sabre Lite do) - I think, I haven't looked all that thorougly.
Now, I have had others asking about making bits of the beaglebone cape manager available as general infrastructure, so we'll
look at that as part of our mainlining effort.
You have to understand that the way things work their way in the kernel tend to go though some stages. The beaglebone is the first
platform which uses DT so extensively, so we keep on hitting things that need fixing in the kernel infrastructure. Parts of what we've
done, could work their way in the kernel for every platform to use. But it won't happen if users don't voice their opinions about which
way it should go.
Pantelis Antoniou wrote:
Fear not, we are fairly good at voicing our opinions here. Fortunately, also quite precise with them, as befits an engineering site.
Pantelis Antoniou wrote:
You have to understand that the way things work their way in the kernel tend to go though some stages.
Some of us have first hand experience of the way it works I can't imagine I'm the only one looking at your code, thinking it looks very useful, and wondering if the mechanism couldn't be made more generic.
I guess what I'm thinking of is something where the mechanism is available regardless of the presence of capemgr, but where capemgr or another platforms equivalent can register with the generic code and then be able to perform everything it does today. So no loss in functionality for BBB, but everyone gains from the generic capability.
I do understand you're implementing this first and that you're doing it specifically for the BBB, so your needs are your first concern. However it's been my experience that the upstream kernel maintainers tend to look beyond the initial use case, see that something will be useful, and ask the developer to change it to make it more generally useful. I fully expect things to evolve as your efforts to mainline the code progress.
Best of luck in your efforts and thanks for taking the time to share your insights here.
We are in sync. In fact you're not the first one that suggested moving stuff around so that's a general service.
All I can tell is that we're working on it; it's going to be fun
I've been making use of DT fragments, currently just to enable the PRU and to set the mode for pins, however I'm having trouble setting GPIO2 pins as inputs. I've seen this on the latest 6/6 build too, as well as the previous build.
The .dts fragment example I'm using is here. It doesn't work, although I can set the pin to input using the
echo in > /sys/class/gpio/gpio65/directionso I have a workaround for now.
However, does it look like a bug, or have I made an error in the dts file?
The fragment is responsible for setting <0x8c 0x2f> which is DIL header P8, pin 18 as seen on the pinmux website, set to input, with no pullup/pulldown. When I load it, and try to verify using
echo $PINS | grep 88c, I see it as 0x27, i.e. unchanged.
I'm guessing I've maybe made a silly error somewhere, but it's quite frustrating having looked at it for days, and not getting anywhere!
FYI - I found this via Google+ (https://plus.google.com/108506657199236487651/posts/UjbtCWXAYGP):
Beaglebone and the 3.8 Kernel