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@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 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
