Enabling TIMER4 output on Beaglebone Black

from that error in dmesg, I suspect that either there's something missing in the driver, or that you're missing some relevant attribute in your devicetree.

Documentation/devicetree/bindings/crypto/omap-des.txt contains the only mention of 'fck' that I can see, but that could just mean it's not documented properly as that one appears to be for a different driver.

In the vanilla 3.13 kernel source, I don't see a timer4_fck label in the devicetree files anywhere, so you'll have to dig out that label and see what it refers to before you can look up the binding in the documentation to see how to use it.

There is some stuff related to timer4_fck in arch/arm/mach-omap2/cclock33xx_data.c but I can't tell from that how to properly set it up in devicetree.

Unfortunately when you're using something like yocto you have no idea what they've patched into what sort of mess, but it probably bears little resembelance to either Roberts BBB kernels or to vanilla kernel.org kernels. So you end up very much on your own unless you can find someone else using the same config who wants to enable the same things.

I've had reasonable results enabling stuff in kernel.org kernels on the BBB, but have never tried to setup a timer.

Thanks for the reply Selsinork.

As far as I"ve been able to tell, the "fck" clock device being missing isn't unique to me, but then again, I'm also not certain that it's particularly relevant.

As far as the kernel goes, the reason I chose to go the yocto route is exactly because I was trying to avoid the kernels that have a whole slew of patches. While I know that Robert's kernels or the Angstrom kernels work just fine, the "mess" of patches as you put it is far more prevalent there. I'm using yocto so that I can use the kernel sources that come direct from Texas Instruments through their official meta-ti layer for openembedded/yocto. The rest of the yocto distribution has not a thing to do with the kernel or devicetree and is actually much more simplistic and trimmed down than just about anything else. Once you wrap your head around bitbake (which you have to do for Angstrom anyway), yocto really is pretty nice to deal with and will allows a level of customization and control of the "mess" that I can't get by using a canned distro and kernel.

That being said, there are definitions for timer4_fck in the DT sources from TI in arch/arm/boot/dts/am33xx-clocks.dtsi:

timer4_fck: timer4_fck@44e00510 {

        #clock-cells = <0>;

        compatible = "mux-clock";

        clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>;

        reg = <0x44e00510 0x4>;

        bit-mask = <0x3>;

};

also in arch/arm/boot/dts/am33xx.dtsi:

timer4: timer@48044000 {

        compatible = "ti,am335x-timer";

        reg = <0x48044000 0x400>;

        interrupts = <92>;

        ti,hwmods = "timer4";

        clocks = <&timer4_fck>;

        clock-names = "fck";

        ti,timer-pwm;

};

So, I can tie this back to how it sits in the clk_summary tree (and also to the "fck" name reference) from my post above, and I believe I've got the pin assignment bits correct, but what I'm lacking is the mechanism to take that defined clock and set the "enabled" bit for it in the kernel. Again, I'm still kind of a devicetree newb, so there may be something I'm missing in the definitions above, so any help is appreciated.

Thanks,

-d

Thanks for the reply Selsinork.

As far as I"ve been able to tell, the "fck" clock device being missing isn't unique to me, but then again, I'm also not certain that it's particularly relevant.

As far as the kernel goes, the reason I chose to go the yocto route is exactly because I was trying to avoid the kernels that have a whole slew of patches. While I know that Robert's kernels or the Angstrom kernels work just fine, the "mess" of patches as you put it is far more prevalent there. I'm using yocto so that I can use the kernel sources that come direct from Texas Instruments through their official meta-ti layer for openembedded/yocto. The rest of the yocto distribution has not a thing to do with the kernel or devicetree and is actually much more simplistic and trimmed down than just about anything else. Once you wrap your head around bitbake (which you have to do for Angstrom anyway), yocto really is pretty nice to deal with and will allows a level of customization and control of the "mess" that I can't get by using a canned distro and kernel.

That being said, there are definitions for timer4_fck in the DT sources from TI in arch/arm/boot/dts/am33xx-clocks.dtsi:

timer4_fck: timer4_fck@44e00510 {

        #clock-cells = <0>;

        compatible = "mux-clock";

        clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>;

        reg = <0x44e00510 0x4>;

        bit-mask = <0x3>;

};

also in arch/arm/boot/dts/am33xx.dtsi:

timer4: timer@48044000 {

        compatible = "ti,am335x-timer";

        reg = <0x48044000 0x400>;

        interrupts = <92>;

        ti,hwmods = "timer4";

        clocks = <&timer4_fck>;

        clock-names = "fck";

        ti,timer-pwm;

};

So, I can tie this back to how it sits in the clk_summary tree (and also to the "fck" name reference) from my post above, and I believe I've got the pin assignment bits correct, but what I'm lacking is the mechanism to take that defined clock and set the "enabled" bit for it in the kernel. Again, I'm still kind of a devicetree newb, so there may be something I'm missing in the definitions above, so any help is appreciated.

Thanks,

-d

One other thing that I forgot to mention. For my specific application, I can't really use the more popular bbb kernels because I have need of pins reserved for capemgr, which AFAIK is implemented as patches on top of the mainline kernel, and it would be more of a pain than I would like to deal with to excise the entire capemgr (and would put me right back into custom kernels anyways).

-d

So what to do is lookup 'mux-clock' & 'am335x-timer' in Documentation/devicetree/bindings/* They should both be documented somewhere under that tree and should give you a list of the properties you can use within their sections.

Usually to enable something you add a status = "okay"; line, in this case I think you need to add it to timer4.  I think you probably also want to add the pinmux stuff into timer4, best way to be sure is to find an example in the kernel source where someone has connected a timer to an external pin - ideally with the am335x-timer driver. If you can't find an example, then unfortunately it may come down to trial and error. I've found a few cases where the docs help but don't give you quite enough to join all the dots.

On the whole patched kernel mess, I totally agree. What I was trying to get at is that when you find yourself using something that few others are then help may be hard to find.

There was one example of this on the BBB where angstrom had dt properties off-by-one which gave people lots of problems upgrading as their overlays stopped working. It was easy to fix once you'd worked out what was wrong, but that was harder to do.

I certainly agree that getting rid of capemgr is a good idea. I did that a while ago and learned a lot more about devicetree in the process.  I also discovered that you can largely just use a kernel.org kernel on the BBB without any patches these days.

capemgr itself shouldn't be reserving any pins, it does however come with a load of assumptions, some of which might.

However IMHO, capemgr is an all or nothing proposition, you either buy into it fully or reject it fully and live with the consequences of that decision.

The decision is coulded by things like BB-View which assume you've bought the concept and then don't provide all the pieces (the i2c eeprom is missing) which gives you the worst of both worlds.

Haven't tried it, but theoretically you can use the same kernel as everyone else but just put a status = "disabled"; line into the devicetree in the right place and it won't load capemgr. Or just build your own devicetree that doesn't reference capemgr at all..

There's an effort going on in the mainline kernel that should lead to us being able to build a single kernel that runs across a wide range of boards, all you need is to load the correct dtb for your board and only the required drivers are enabled.  So run that same kernel on a Cubieboard and we need to be able to be able to disable capemgr since the concept isn't valid for the different board. Same applies to something like a network controller that may simply not exist on a different board.