bcm2835-analog-audio: Is my driver PWM, ALSA or neither
mzoran at crowfest.net
Sun Mar 12 16:26:05 PDT 2017
On Sun, 2017-03-12 at 21:22 +0100, Gottfried Haider wrote:
> I don't have any suggestion to you actual question, but as someone
> builds (user-space) tools that interact with whatever peripheral I
> get my hands on: anything that would keep access to PWM open, and
> arbitration between it and audio more straightforward, would help
> 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,
> 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
> 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 :)
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.
More information about the linux-rpi-kernel