Kernel driver for controlling PRU pwm

[Mark A. Yoder]

I have a question about building a kernel driver for my PRU software pwm that mimics the hardware pwm sysfs interface.

Background:

I have a simple kernel driver[1] now working with my PRU based pwd code.

Once you have the code running on the PRU you can:

bone$ insmod pwm.ko channel=1

bone$ cd /sys/kernel/pwm/pwm1

bone$ ls

duty_cycle  enable  period

bone$ echo 2000 > period

bone$ echo 1000 > duty_cycle

Now you have a pwm signal on channel 1 with a period of 2000ns and an on time of 1000 ns.

The hardware pwms appear in /sys/class/pwm. You can use them via:

bone$ cd /sys/class/pwm/pwmchip0

bone$ echo 0 > export

bone$ cd pwm0

bone$ echo 2000 > period

bone$ echo 1000 > duty_cycle

The question:

How do I build a kernel module so my software pwms will appear along with the hardware pwms?  That is, I want my software pwms to appear as pwmchipX and then you could:

bone$ cd /sys/class/pwm/pwmchipX

bone$ echo 0 > export

bone$ cd pwm0

bone$ echo 2000 > period

bone$ echo 1000 > duty_cycle

To run the PRU pwms.

Does anyone have pointers to kernel tutorials to do this?

Thanks...

--Mark

[1] https://github.com/MarkAYoder/BeagleBoard-exercises/tree/master/pru/examples/pwm/kernel

[William Hermans]

http://lxr.free-electrons.com/source/drivers/pwm/sysfs.c
https://www.kernel.org/doc/Documentation/pwm.txt
https://lwn.net/Articles/553755/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/b8ef1af3-914f-48cd-b555-22b47dee072f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

One thing I do not understand myself Mark. Is how these drivers get loaded from a device tree file. It could be possible that your drivers can somehow be "hooked" by setting up a proper device tree file, and using the existing sysfs pwm API. How exactly though . . . yeah I have a hard time imaging where to start.

[John Syne]

You should speak to Jason Reeder (author of PRU examples) or Suman Anna (author of RPMSG) and learn how to use the virtualio. In essence, you can create peripherals on the PRU but to Linux they will look like a peripheral on the SOC. I’m currently traveling so I don’t have access to my desktop. I think TI define this as firmware defined peripherals. 

Regards,

John

[ZeekHuge]

You can easily do that by developing a client-rpmsg driver on kernel side and creating an rpmsg-channel on the PRU side. This will also probe the client driver just by loading the PRU firmware.
In that client driver, you can then manage the I/O through sysfs entries.

[ZeekHuge]

Some addition :

On Thursday, 4 August 2016 22:23:23 UTC+5:30, ZeekHuge wrote:

You can easily do that by developing a client-rpmsg driver on kernel side and creating an rpmsg-channel on the PRU side. This will also probe the client driver just by loading the PRU firmware.

 
So this rpmsg-client driver should actually be a pwm driver and should create a class and then register it.