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

[Rob Herring <robh@kernel.org>]

On Wed, Apr 27, 2022 at 04:29:06AM -0500, Dan K wrote:
> 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 for the all the details and I do agree. Can you add some 
description of the h/w from above into the binding description.

Rob