Re: [PATCH v4 1/2] dt-bindings: sound: Add generic serial MIDI device

[Dan K <kaehndan@gmail.com>]

Thanks for taking the time for a thorough reply!

On Tue, Apr 26, 2022 at 7:47 PM Rob Herring <robh@kernel.org> wrote:
>
> 'Generic' is really just a red flag.
>
> We've had generic or simple bindings before. The result tends to be a
> never ending stream of new properties to deal with every new variation
> in devices. These can be quirks for device behavior, timing for power
> control, etc.
>

Makes sense, I see why that's a concern. I think it's probably unlikely
that would happen here (for reasons described below).

>
> Okay, maybe it is appropriate. The key part is 'most use cases'. What
> about ones that don't fit into 'most'? It's possible to do both (generic
> binding and device specific bindings), but we need to define when
> generic bindings are appropriate or not.
>

Sorry about the vague language.

In many/most cases, a raw/serial MIDI device is an independent external
device, and its connection to another MIDI device would be transient and
through an external cable. Usually, this is a device that a user plugs in
at runtime, such as a MIDI keyboard (/piano) that simply sends and receives
bytes using the MIDI protocol, and its identity isn't known at the time of
devicetree compilation (and doesn't need to be known).

This binding is only describing that a serial port is dedicated to MIDI,
and the only hardware it describes is the circuitry and electrical
connections needed to connect to a MIDI device (likely through a jack).
This covers almost all of the use cases for (serial) MIDI (MIDI is now also
often done over USB / network, in case you aren't familiar). As you can
probably imagine from its use of DT in general - this is targeted toward
embedded devices, allowing an off-the-shelf SOC in an audio product to
interface with an external raw MIDI device.

The only exceptions to 'most use cases' I'm aware of are with some
antiquated MIDI interface devices that connect to an RS232 port and have
multiple output ports (selectable via a special MIDI message), enabling
someone to connect multiple MIDI devices to a PC simultaneously. I only
discovered that these exist because of the existing serial MIDI driver in
the kernel, and some research reveals that few devices like these (with
multiplexed I/O) exist. This is also probably well outside of the use case
for an embedded device.


> Do devices ever need power controls or other sideband interfaces?
> Regulators, resets, clocks? If so, you need to describe the specific
> device.
>
> Is a jack/connector in any way standard and have signals other than UART
> (or whatever is the other side of the MIDI decoupling circuit)? We have
> bindings for standard connectors.
>

The standard connector is a DIN5 connector, but only two signal pins are
used, for RX and TX. No sideband interfaces are used - the MIDI device
connected is typically a completely independent system. Neither device for
MIDI will power the other (except for USB MIDI). Really the only parameter
possible for just the serial MIDI interface itself is the baudrate - which
is fixed to 31.25k in the standard, but a device could feasibly be
connected to an onboard / non-transient custom MIDI controller with a
different baudrate (my use case contains this, as well as the earlier use
case for an external MIDI device).


> I don't really know anything about what this h/w looks like, so any
> pointers or examples would help.
>

I hope the above helps to clarify.

> > I see how this is a bit of an oddball, since it's not specifically
> > describing a particular hardware
> > device attached to a UART (like some of the bluetooth modules are),
>
> To follow that comparison, all/most BT modules use a standard/generic
> protocol over the serial port. But we don't have compatibles aligned to
> the protocol because the devices are more than just a serial protocol.
> They have GPIOs, regulators, clocks, etc. Furthermore, the serial
> protocols themselves can have extensions and/or quirks.
>

I think I would contend that for MIDI, the 'device' this binding describes
more or less is just the serial protocol (and hardware to support the
transmission). Any specific handling of special functions of a device would
be done in userspace.

>
> At some point devices become simple enough to model generically.
>
> > The reason that the corresponding driver written has the name
> > 'generic' is for an entirely
> > different reason. A "serial MIDI" driver already exists in the kernel,
> > however, it  interfaces only with
> > u16550-compatible UARTs. This driver uses the serial bus, making it
> > work with 'generic' serial devices.
>
> Bindings are separate from the kernel (though they live in the same
> repository for convenience). A 'generic' binding often appears with a
> 'generic' driver. You can have specific bindings with a generic driver.
> The difference with doing that is the OS can evolve without changing the
> binding (an ABI). Maybe initially you use a generic driver until there's
> extra/custom features of the device you want to support with a custom
> driver.
>

I've seen that sort of 'specific binding - > generic driver' model before -
but I think you'll agree that since the nature of the external device is
typically transient, the generic binding -> generic driver is probably what
would make sense here.

Thanks,
Daniel Kaehn