[alsa-devel] [PATCH v2] ALSA: x86: Select CONFIG_HDMI_LPE_AUDIO as default
Takashi Iwai
tiwai at suse.de
Mon Mar 20 18:57:32 CET 2017
On Mon, 20 Mar 2017 16:12:01 +0100,
Ian W MORRISON wrote:
>
> On 20 March 2017 at 21:04, Takashi Iwai <tiwai at suse.de> wrote:
>
> > On Mon, 20 Mar 2017 10:41:07 +0100,
> > Ian W MORRISON wrote:
> > >
> > > On 20 March 2017 at 19:41, Takashi Iwai <tiwai at suse.de> wrote:
> > >
> > > > On Mon, 20 Mar 2017 09:17:30 +0100,
> > > > Ian W MORRISON wrote:
> > > > >
> > > > > Oops ... forgot to copy alsa-devel and Pierre-Louis.
> > > > >
> > > > > On 20 March 2017 at 18:59, Takashi Iwai <tiwai at suse.de> wrote:
> > > > >
> > > > > > On Mon, 20 Mar 2017 08:42:32 +0100,
> > > > > > Ian W MORRISON wrote:
> > > > > > >
> > > > > > > The upstream kernel builds for distributions such as Ubuntu
> > which now
> > > > > > > includes binary packages for v4.11 mainline kernel release
> > > > candidates are
> > > > > > > promoted as a way of testing upstream kernels to to confirm that
> > > > upstream
> > > > > > > has fixed a specific issue (see https://wiki.ubuntu.com/
> > > > > > > Kernel/MainlineBuilds).
> > > > > > >
> > > > > > > Unfortunately the long awaited patch for providing HDMI audio
> > > > support for
> > > > > > > Bay Trail and Cherry Trail devices does not include this support
> > > > through
> > > > > > a
> > > > > > > module built by default.
> > > > > > >
> > > > > > > Through including by default of the two associated CONFIG
> > settings
> > > > > > (SND_X86
> > > > > > > and HDMI_LPE_AUDIO), upstream kernel builds would automatically
> > > > provide
> > > > > > the
> > > > > > > much desired HDMI audio support by default.
> > > > > > >
> > > > > > > This patch uses a Kconfig 'default' statement to include the
> > driver
> > > > as
> > > > > > > default.
> > > > > > >
> > > > > > > Changes in version 2: CONFIG_SND_X86 now a bool and changed
> > default
> > > > m to
> > > > > > > default y
> > > > > > >
> > > > > > > Signed-off-by: Ian W Morrison <linuxium at linuxium.com.au>
> > > > > > > ---
> > > > > > > sound/x86/Kconfig | 4 +++-
> > > > > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/sound/x86/Kconfig b/sound/x86/Kconfig
> > > > > > > index 84c8f8fc..cac2270 100644
> > > > > > > --- a/sound/x86/Kconfig
> > > > > > > +++ b/sound/x86/Kconfig
> > > > > > > @@ -1,6 +1,7 @@
> > > > > > > menuconfig SND_X86
> > > > > > > - tristate "X86 sound devices"
> > > > > > > + bool "X86 sound devices"
> > > > > > > depends on X86
> > > > > > > + default y
> > > > > >
> > > > > > This one is OK, but ...
> > > > > >
> > > > > > > ---help---
> > > > > > > X86 sound devices that don't fall under SoC or PCI
> > > > categories
> > > > > > >
> > > > > > > @@ -9,6 +10,7 @@ if SND_X86
> > > > > > > config HDMI_LPE_AUDIO
> > > > > > > tristate "HDMI audio without HDaudio on Intel Atom
> > platforms"
> > > > > > > depends on DRM_I915
> > > > > > > + default y
> > > > > >
> > > > > > ... this is wrong. Each driver config itself should be left
> > > > > > unspecified.
> > > > > >
> > > > > > It's distributor's job to choose the right config here.
> > > > > >
> > > > > > Actually this goes back to one of my earlier points: A distributor
> > > > doesn't
> > > > > have to set 'HDMI' as HDMI audio is automatically provided.
> > > >
> > > > Provided by who...?
> > > >
> > >
> > >
> > > I suppose it is provided as a result of the architecture one runs the
> > > primary Makefile on. With 'uname -m' returning 'x86_64' running 'make
> > > defconfig' results in 'CONFIG_HDMI=y' being set so
> > 'drivers/video/Makefile'
> > > automatically makes 'drivers/video/hdmi.c' and as
> > > 'arch/x86/configs/x86_64_defconfig' includes 'CONFIG_DRM=y' and
> > > 'CONFIG_DRM_I915=y' and 'drivers/gpu/drm/i915/Makefile' makes
> > > 'intel_audio.c'.
> >
> > The defconfig stuff supports only the limited device sets that are
> > supposed to be very common. Is HDMI_LPE_AUDIO classified really as
> > such a thing? I don't know...
> >
> >
> In this instance I'd suggest that HDMI_LPE_AUDIO is common as without it
> you do not get HDMI audio on all x86_64 devices. However see my comment
> below.
>
>
> >
> > > > > This is just an
> > > > > extension because by setting 'HDMI_LPE_AUDIO' the missing audio
> > support
> > > > for
> > > > > BYT and CHT SoCs is then provided. Therefore, in this albeit unusual
> > > > > instance, I reason is it appropriate to set HDMI_LPE_AUDIO so that
> > audio
> > > > is
> > > > > automatically provided regardless of distribution. If a distributor
> > > > didn't
> > > > > want to allow audio for BYT and CHT SoC based devices running their
> > > > distro
> > > > > then they could always remove it from their distro specific config.
> > > >
> > > > It's a wrong approach. What we're discussing about is just a
> > > > configuration for a new individual driver, and the same rule should be
> > > > applied to it like others.
> > > >
> > > > Check other drivers. See whether default=y (or =m) is set to
> > > > CONFIG_E1000E, as a random example. With your argument, it should be
> > > > set to y or m as default, since the Ethernet functionality is already
> > > > provided by the network core.
> > > >
> > > > In general, we don't set the default values to the driver configs
> > > > unless there is a VERY specific reason to do so.
> > > >
> > > >
> > > I'm trying to get HDMI audio by default for BYT & CHT SoC but currently
> > > this requires 'CONFIG_HDMI_LPE_AUDIO' set with a value of 'm'. I don't
> > want
> > > to argue a 'special case' or promote a 'wrong approach' but just get HDMI
> > > audio working so is there another way to achieve this?
> >
> > What's wrong with manually setting CONFIG_HDMI_LPE_AUDIO=m or =y?
> > IOW, do all features on your CHT/BYT machines work without adjusting
> > manually after defconfig? If you have to do it in anyway, what makes
> > it special for HDMI_LPD_AUDIO?
> >
> >
> I've just tested various scenarios using a variety of devices with
> v4.11-rc3. Having CONFIG_HDMI_LPE_AUDIO set by default is sufficient to get
> audio on BYT/CHT devices over HDMI.
>
> For example installing Ubuntu 16.04.2 on a BYT/CHT device, then upgrading
> the kernel to v4.11-rc3 using the deb-binary from http://kernel.ubuntu.com/~
> kernel-ppa/mainline/v4.11-rc3/ (an example of a current distro which is
> compiling without setting CONFIG_HDMI_LPE_AUDIO) and there is no audio over
> HDMI. Alternatively downloading v4.11-rc3 source, making defconfig,
> manually setting CONFIG_HDMI_LPE_AUDIO, compiling and installing the
> kernel on the BYT/CHT device will give you audio over HDMI.
>
> If the BYT/CHT device has other sound cards (e.g accessed via a headphone
> jack) then audio without setting CONFIG_HDMI_LPE_AUDIO may be possible
> depending on the codec used and whether it is provided by default in the
> kernel. So for example a Tronsmart Ara (CHT) device has audio over
> headphones using the pre-compiled deb-binary above but no audio over HDMI.
> Whereas with a (1st gen) Intel Compute Stick (BYT) device no audio is
> possible using the pre-compiled deb-binary as the device only has an HDMI
> port. To get sound you must therefore currently use a self-compiled kernel
> with CONFIG_HDMI_LPE_AUDIO set.
>
> Whilst Canonical may set CONFIG_HDMI_LPE_AUDIO to provide audio on BYT/CHT
> devices by when is unknown and there is no guarantee they actually will.
>
> This will be similar for all other distros with the worst case scenario
> that no distributor adds CONFIG_HDMI_LPE_AUDIO to their configs resulting
> in (arguably) little point including HDMI LPE audio support in the kernel.
>
> I've laboured the point about 'BYT/CHT devices audio over HDMI' but to
> answer your question completely there are other BYT/CHT devices (typically
> tablets) that need a whole other bunch of patches to fix this and that.
> They may need specialist kernel configs with specific settings but that is
> a separate issue to the basic functional need of having audio over HDMI.
>
> Does the above explanation justify my current approach or is there an
> alternative that can be considered?
Sorry, no, you've explained how much you love the HDMI audio, but it
doesn't answer my question clearly.
My question is simple: are *all* features the upstream kernel supports
for your device now (e.g. input, network or whatever) enabled by the
pure arch/x86/configs/x86_64_defconfig *without* manually setting the
configs to y or m? I bet you likely have to set some configs there
manually to m or y.
Then, if the manual selection for such missing configs is acceptable,
what makes the HDMI audio so special and it must be set to y/m as
default, while other devices aren't set like that...? That's the
question.
thanks,
Takashi
More information about the Alsa-devel
mailing list