On 8/27/2023 4:17 AM, Tim Hardisty wrote:
Thanks Gregory. The existing ClassD driver is registered as /dev/audio/pcm0 and is a PCM
device not PWM. It has the "usual" audio ops to configure it,
start/stop/pause/enqueue etc. It is exposed via ioctls so does have a user interface;
that is how buffers of audio are passed to it. Is that an OS-function only, hence your
comments that it should not be exposed to the user and I'm muddling things up?
It is impossible to expose the audio lower-half interface to
applications without trashing the POSIX standard. You could, however,
create a POSIX compliant character driver similar to
drivers/audio/tone.c to interact with it from applications via standard
read/write. When I mentioned tone.c, I was referring to the interface
model of tone.c. It is irrelevant that one is PWM and one is PCM. The
point is that the interface model provides a POSIX application interface
that mediates calls to the lower level interface. In your case
sam_classd.c would contain the lower level interface.
The declaration of the audio_ops_s struct also includes a read and write
function that are typically defined as NULL in these audio drivers. That's what
I was thinking of adding, but perhaps I'm am not understanding that
/dev/audio/pcm0 can't (shouldn't) actually be opened as a character driver?
These read/write methods cannot be called from applications. You cannot
register the driver, you cannot open the driver, you cannot write to it
(unless someone has changed to code in some non-compliant way). But you
can do all of those things via a standard character driver similar to
tone.c that provides struct file_operations, but interfacing to a
different architecture-specific lower half. Maybe audio_op_s could be
that interface? Or maybe a new interface?
Using the buffer interface would be more consistent with other usage of
audio drivers in the system. It would be better to avoid the write
method if possible.
The character driver could also forward IOCTLs from the application to
the audio lower half.
This would all have to be generalized, nothing under drivers can to
tailored for any specific MCU, but must be generic OS code suitable for
any PCM driver.
