| Message ID | 20210525132354.297468-2-maxime@cerno.tech (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/vc4: hdmi: Enable Channel Mapping, IEC958, HBR Passthrough using hdmi-codec | expand |
On Tue, 25 May 2021 15:23:43 +0200, Maxime Ripard wrote: > > The doc currently mentions that the IEC958 Playback Default should be > exposed on the PCM iface, and the Playback Mask on the mixer iface. > > It's a bit confusing to advise to have two related controls on two > separate ifaces, and it looks like the drivers that currently expose > those controls use any combination of the mixer and PCM ifaces. > > Let's try to clarify the situation a bit, and encourage to at least have > the controls on the same iface. > > Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Takashi Iwai <tiwai@suse.de> thanks, Takashi > --- > .../sound/kernel-api/writing-an-alsa-driver.rst | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst > index e6365836fa8b..01d59b8aea92 100644 > --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst > +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst > @@ -3508,14 +3508,15 @@ field must be set, though). > > “IEC958 Playback Con Mask” is used to return the bit-mask for the IEC958 > status bits of consumer mode. Similarly, “IEC958 Playback Pro Mask” > -returns the bitmask for professional mode. They are read-only controls, > -and are defined as MIXER controls (iface = > -``SNDRV_CTL_ELEM_IFACE_MIXER``). > +returns the bitmask for professional mode. They are read-only controls. > > Meanwhile, “IEC958 Playback Default” control is defined for getting and > -setting the current default IEC958 bits. Note that this one is usually > -defined as a PCM control (iface = ``SNDRV_CTL_ELEM_IFACE_PCM``), > -although in some places it's defined as a MIXER control. > +setting the current default IEC958 bits. > + > +Due to historical reasons, both variants of the Playback Mask and the > +Playback Default controls can be implemented on either a > +``SNDRV_CTL_ELEM_IFACE_PCM`` or a ``SNDRV_CTL_ELEM_IFACE_MIXER`` iface. > +Drivers should expose the mask and default on the same iface though. > > In addition, you can define the control switches to enable/disable or to > set the raw bit mode. The implementation will depend on the chip, but > -- > 2.31.1 >
diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index e6365836fa8b..01d59b8aea92 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -3508,14 +3508,15 @@ field must be set, though). “IEC958 Playback Con Mask” is used to return the bit-mask for the IEC958 status bits of consumer mode. Similarly, “IEC958 Playback Pro Mask” -returns the bitmask for professional mode. They are read-only controls, -and are defined as MIXER controls (iface = -``SNDRV_CTL_ELEM_IFACE_MIXER``). +returns the bitmask for professional mode. They are read-only controls. Meanwhile, “IEC958 Playback Default” control is defined for getting and -setting the current default IEC958 bits. Note that this one is usually -defined as a PCM control (iface = ``SNDRV_CTL_ELEM_IFACE_PCM``), -although in some places it's defined as a MIXER control. +setting the current default IEC958 bits. + +Due to historical reasons, both variants of the Playback Mask and the +Playback Default controls can be implemented on either a +``SNDRV_CTL_ELEM_IFACE_PCM`` or a ``SNDRV_CTL_ELEM_IFACE_MIXER`` iface. +Drivers should expose the mask and default on the same iface though. In addition, you can define the control switches to enable/disable or to set the raw bit mode. The implementation will depend on the chip, but
The doc currently mentions that the IEC958 Playback Default should be exposed on the PCM iface, and the Playback Mask on the mixer iface. It's a bit confusing to advise to have two related controls on two separate ifaces, and it looks like the drivers that currently expose those controls use any combination of the mixer and PCM ifaces. Let's try to clarify the situation a bit, and encourage to at least have the controls on the same iface. Signed-off-by: Maxime Ripard <maxime@cerno.tech> --- .../sound/kernel-api/writing-an-alsa-driver.rst | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)