"Beaglebone and the 3.8 Kernel"

That's a very concise description of your coverage of the problem space, and covers all my existing questions.

Many thanks!

Pantelis Antoniou wrote:

 

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. 

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/direction so 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!