bcm2835-analog-audio: Is my driver PWM, ALSA or neither

[Michael Zoran]

On Sun, 2017-03-12 at 21:22 +0100, Gottfried Haider wrote:
> Michael,
> 
> I don't have any suggestion to you actual question, but as someone
> who
> builds (user-space) tools that interact with whatever peripheral I
> can
> get my hands on: anything that would keep access to PWM open, and
> make
> arbitration between it and audio more straightforward, would help
> IMHO.
> 
> My most pressing issue with PWM today is that exporting a channel via
> sysfs does not appear to cause events in udev. (At least this was the
> case when I last checked on an 4.4-era kernel.) Because of this,
> there
> is no sensible way of applying more relaxed access permissions to the
> individual channel's sysfs nodes. And having to have root is
> especially tricky to do with desktop applications...
> 
> I don't know much about the device model, but somehow exporting a
> gpio
> pin via sysfs (drivers/gpio/gpiolib-sysfs.c) does create an "add"
> event on udev, whereas the same on pwm (drivers/pwm/sysfs.c) doesn't
> seem to cause one.
> 
> Just in case you stumble upon this area while you hack on the
> alsa-cum-pwm driver :)
> 
> Best,
> 
> Gottfried

How do you think this should work for a user space point of view?  And
yes, I think somehow integrating with udev scripts would make sense.

My current thinking is to have 3 drivers, a PWM driver,an Audio driver,
and a core platform driver.  How these would be mapped to kernel
modules or source files, I don't know. 

The driver model has a concept of a parent driver and by making a
driver be a child of another driver automatically creates a sysfs node
for the child under the parent. So I should be able to generate custom
sysfs properties and events.

Ideally, it would be nice if the kernel had a general device
multiplexer mechanism that's either part of the platform subsystem or
part or driver core, but that's taking thinks a bit farther then I'm
willing to go at the moment.