Thanks for taking the time for a thorough reply! On Tue, Apr 26, 2022 at 7:47 PM Rob Herring <robh@xxxxxxxxxx> 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
