Re: Support for PWM on RPI3 GPIO

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Tue, Apr 03, 2018 at 11:23:23PM -0700, Jason Thorpe wrote:
> 
> 
> > On Apr 3, 2018, at 8:06 PM, Michael van Elst <mlelstv%serpens.de@localhost> wrote:
> > 
> > thorpej%me.com@localhost (Jason Thorpe) writes:
> > 
> >> I see thereâ??s a â??bcmpwmâ?? driver, but Iâ??m not sure itâ??s what I wantâ?¦ Nothing appears to actually use it, as far as I can tell, and there doesnâ??t seem to be any API *to* use it, nor any obvious documentation on its function.
> > 
> > Since FDT'ization, the driver isn't usuable and you would need the
> > clock driver too that got junked. Both abstract only a little bit
> > from the hardware, you want to read BCM2835-ARM-Peripherals.pdf for
> > the hardware details.
> 
> Ok, I read that document and I think I have my head wrapped around how it works, at least for the basic ?PWM algorithm? mode.  It seems like maybe the best way to use them is with sysctls on the Broadcom gpio driver (to set the PWM parameters for that pin and enable it)

That would be the fastest way.

When I was working on that driver, I intended to have a gpio module
like gpiopwm that would talk to the lower levels. Like with gpiopwm you
could have sysctls. Making a machine specific loadable module was the
major obstacle then as modules would be built for all of evbarm but only
compile for RPI. But a builtin module would be possible.


> > The driver also wasn't exposed to userland and can conflict with
> > the vcaudio driver.
> 
> Can you explain how it can conflict with vcaudio?  It?s not obvious to me at first glance.  Alas, I do also want to use audio in my application (but I don?t need video at all ? console is going to be on the serial port and brought out the back of the enclosure most likely with an Adafruit FTDI Friend).

The analog audio is nothing but the PWM engine fed through some simple
analog filter. So if you tell the firmware to use analog audio, it will
use the PWM output and whatever you configure the PWM engine to do can
be audible. For simple static PWM values that's almost harmless, just
noise. If you intend to feed the PWM engine via DMA (which for example
is used to drive RGB LED chains), then you get a conflict on the DMA channel
as well, which is worse because vcaudio (the firmware behind it) doesn't
release the DMA channel by default.


> >> Anybody have some advice for me?
> > 
> > The GPIO pin (18 left, 19 right) must be set to alternate
> > function 5 to route the PWM engine to the GPIO pin. Unfortunately
> > the GPIO driver works only from userland and doesn't configure
> > alternate functions. I had a patch somewhere?.
> 
> Yah, like I said above, at least in the short term, perhaps the best way to make this work is to add sysctls in the Broadcom gpio driver that allow you to fiddle with these special GPIO pin functions (and when enabled, those pins would be blocked from access by the general GPIO framework).

The gpioctl command still has the options to configure the alternate
functions. Should be simple to restore that part in the driver.


> Can you explain what needs to be done to freshen up the PWM driver for this new FDT universe?  (Sorry, I?ve been away from NetBSD for ? um? ages, and a lot has changed, so I?ve gotta get my head wrapped back around all this stuff?)

The PWM driver and the CM driver attachment code need to be adapted and
you need some overlay DTS file. There is also a new clock driver, but
with some different prurpose. I haven't looked at how this can be
merged.



Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."