| Message ID | 20220425191602.770932-2-kaehndan@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add generic serial MIDI driver using serial bus API | expand |
On Mon, Apr 25, 2022 at 02:16:02PM -0500, Daniel Kaehn wrote: > Adds dt-binding for snd-serial-generic serial MIDI driver Bindings are for h/w and there's no such thing as generic h/w. There are some exceptions but you'll have to justify why this is special. > Signed-off-by: Daniel Kaehn <kaehndan@gmail.com> > --- > .../devicetree/bindings/sound/serialmidi.yaml | 41 +++++++++++++++++++ > 1 file changed, 41 insertions(+) > create mode 100644 Documentation/devicetree/bindings/sound/serialmidi.yaml > > diff --git a/Documentation/devicetree/bindings/sound/serialmidi.yaml b/Documentation/devicetree/bindings/sound/serialmidi.yaml > new file mode 100644 > index 000000000000..38ef49a0c2f9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/sound/serialmidi.yaml > @@ -0,0 +1,41 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > + > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/sound/serialmidi.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Generic Serial MIDI Device > + > +maintainers: > + - Daniel Kaehn <kaehndan@gmail.com> > + > +description: | Don't need '|' unless there is formatting to preserve. > + Generic MIDI interface using a serial device. Can only be set to use standard speeds > + corresponding to supported baud rates of the underlying serial device. If standard MIDI > + speed of 31.25 kBaud is needed, configure the clocks of the underlying serial device > + so that a requested speed of 38.4 kBaud resuts in the standard MIDI baud rate. > + > +properties: > + compatible: > + const: serialmidi > + > + speed: Not a standard property and we already have 2 of them concerning baud rate. > + maxItems: 1 > + description: | > + Speed to set the serial port to when the MIDI device is opened. > + If not specified, the underlying serial device is allowed to use its configured default speed. > + > +required: > + - compatible > + > +additionalProperties: false > + > +examples: > + - | > + serial { > + midi { > + compatible = "serialmidi"; > + speed = <38400>; > + }; > + }; > -- > 2.33.0 > >
On Mon, Apr 25, 2022 at 5:16 PM Rob Herring <robh@kernel.org> wrote: > > On Mon, Apr 25, 2022 at 02:16:02PM -0500, Daniel Kaehn wrote: > > Adds dt-binding for snd-serial-generic serial MIDI driver > > Bindings are for h/w and there's no such thing as generic h/w. There are > some exceptions but you'll have to justify why this is special. > Thanks for taking the time to look at this! Not entirely sure if you mean that I'll need to justify the existence / need for this binding, or the use of the term 'generic' -- just in case, I'll make sure to respond to both. Note that I'm justifying my reasoning for submitting the binding - but I'm uncertain myself if my reasoning is valid, as someone new to kernel development. The intent of this binding is to signify that a serial port (namely a UART) is connected in hardware to a MIDI decoupling circuit, which then connects to some (any) sort of MIDI device, either directly to an on-board device, or via a jack/connector. In a sense, the MIDI device that this connects to is 'generic', as the identity of the device does not need to be known to interface with it over MIDI for most use cases. 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), but thought this sort of binding might be permissible because of things like the gpio-matrix-keypad binding, which doesn't describe specific switches, just how thoise switches are wired, and what GPIO they use, which is all that is needed to interface with them. Some MIDI devices implement extra low-level features like device multiplexing, but these aren't (to my knowledge) common, and are beyond what this supports. 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. If this comment was directed toward the use of 'generic' in the commit message and binding descriptions: I can reword them to be more specific and to avoid the term. > > > Signed-off-by: Daniel Kaehn <kaehndan@gmail.com> > > --- > > .../devicetree/bindings/sound/serialmidi.yaml | 41 +++++++++++++++++++ > > 1 file changed, 41 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/sound/serialmidi.yaml > > > > diff --git a/Documentation/devicetree/bindings/sound/serialmidi.yaml b/Documentation/devicetree/bindings/sound/serialmidi.yaml > > new file mode 100644 > > index 000000000000..38ef49a0c2f9 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/sound/serialmidi.yaml > > @@ -0,0 +1,41 @@ > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > + > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/sound/serialmidi.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Generic Serial MIDI Device > > + > > +maintainers: > > + - Daniel Kaehn <kaehndan@gmail.com> > > + > > +description: | > > Don't need '|' unless there is formatting to preserve. > Will fix. > > + Generic MIDI interface using a serial device. Can only be set to use standard speeds > > + corresponding to supported baud rates of the underlying serial device. If standard MIDI > > + speed of 31.25 kBaud is needed, configure the clocks of the underlying serial device > > + so that a requested speed of 38.4 kBaud resuts in the standard MIDI baud rate. > > + > > +properties: > > + compatible: > > + const: serialmidi > > + > > + speed: > > Not a standard property and we already have 2 of them concerning baud > rate. > Thanks for the correction - I'll switch this to the existing "baud" property. I somehow missed that there was a fixed list of standard properties to be used, and just chose 'speed' as opposed to 'current-speed' which I saw on serial bindings, since this speed is fixed and can't (and shouldn't need to be) changed. "baud" describes this well enough. > > + maxItems: 1 > > + description: | > > + Speed to set the serial port to when the MIDI device is opened. > > + If not specified, the underlying serial device is allowed to use its configured default speed. > > + > > +required: > > + - compatible > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + serial { > > + midi { > > + compatible = "serialmidi"; > > + speed = <38400>; > > + }; > > + }; > > -- > > 2.33.0 > > > > Thanks, Daneil Kaehn
On Mon, Apr 25, 2022 at 07:49:49PM -0500, Dan K wrote: > On Mon, Apr 25, 2022 at 5:16 PM Rob Herring <robh@kernel.org> wrote: > > > > On Mon, Apr 25, 2022 at 02:16:02PM -0500, Daniel Kaehn wrote: > > > Adds dt-binding for snd-serial-generic serial MIDI driver > > > > Bindings are for h/w and there's no such thing as generic h/w. There are > > some exceptions but you'll have to justify why this is special. > > > > Thanks for taking the time to look at this! > > Not entirely sure if you mean that I'll need to justify the existence > / need for this binding, > or the use of the term 'generic' -- just in case, I'll make sure to > respond to both. Note that > I'm justifying my reasoning for submitting the binding - but I'm > uncertain myself if my reasoning > is valid, as someone new to kernel development. '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. > The intent of this binding is to signify that a serial port (namely a > UART) is connected > in hardware to a MIDI decoupling circuit, which then connects to some > (any) sort of MIDI device, > either directly to an on-board device, or via a jack/connector. In a > sense, the MIDI device that this > connects to is 'generic', as the identity of the device does not need > to be known to interface with it > over MIDI for most use cases. 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. 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. I don't really know anything about what this h/w looks like, so any pointers or examples would help. > 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. > but thought this sort of > binding might be permissible because of things like the > gpio-matrix-keypad binding, which doesn't > describe specific switches, just how thoise switches are wired, and > what GPIO they use, which is all > that is needed to interface with them. Some MIDI devices implement > extra low-level features like device > multiplexing, but these aren't (to my knowledge) common, and are > beyond what this supports. 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. Rob
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
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
Will do, thanks. Daniel Kaehn
diff --git a/Documentation/devicetree/bindings/sound/serialmidi.yaml b/Documentation/devicetree/bindings/sound/serialmidi.yaml new file mode 100644 index 000000000000..38ef49a0c2f9 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/serialmidi.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/serialmidi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic Serial MIDI Device + +maintainers: + - Daniel Kaehn <kaehndan@gmail.com> + +description: | + Generic MIDI interface using a serial device. Can only be set to use standard speeds + corresponding to supported baud rates of the underlying serial device. If standard MIDI + speed of 31.25 kBaud is needed, configure the clocks of the underlying serial device + so that a requested speed of 38.4 kBaud resuts in the standard MIDI baud rate. + +properties: + compatible: + const: serialmidi + + speed: + maxItems: 1 + description: | + Speed to set the serial port to when the MIDI device is opened. + If not specified, the underlying serial device is allowed to use its configured default speed. + +required: + - compatible + +additionalProperties: false + +examples: + - | + serial { + midi { + compatible = "serialmidi"; + speed = <38400>; + }; + };
Adds dt-binding for snd-serial-generic serial MIDI driver Signed-off-by: Daniel Kaehn <kaehndan@gmail.com> --- .../devicetree/bindings/sound/serialmidi.yaml | 41 +++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/serialmidi.yaml