[alsa-devel] [PATCH v2] ALSA: x86: Select CONFIG_HDMI_LPE_AUDIO as default

Tue Mar 21 06:24:35 CET 2017

On 21 March 2017 at 09:02, Ian W MORRISON <ianwmorrison at gmail.com> wrote:

>
>
> On 21 March 2017 at 04:57, Takashi Iwai <tiwai at suse.de> wrote:
>
>> 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.
>>
>
> Whatever love there was is diminishing rapidly!
>
> Let me set the context: the range of BYT/CHT devices sold as HDMI sticks
> or HDMI boxes which are designed to connect to an HDMI output device (TV or
> monitor) and typically have Windows installed as the OS and are used
> primarily as media PCs, HTPCs or as 'mini' PCs. They become essentially
> useless for their designated purpose when installed with a mainstream Linux
> based OS such as Ubuntu at the moment because there is no audio over HDMI.
>
>
>>
>> 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.
>>
>>
> No. CONFIG_HDMI_LPE_AUDIO is the only config that needs to be manually set
> to get *all* features from the upstream kernel.
>
>
>> 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.
>>
>>
>>
> The requested patch sets CONFIG_HDMI_LPE_AUDIO so mainstream Linux distro
> kernels would automatically provide the new kernel feature of HDMI LPE
> audio support.
>

Further analysis of Canonical's v4.11-rcN build compared with other
available distro builds of v4.11-rcN leads me to conclude that given
CONFIG_HDMI_LPE_AUDIO is not set by default then Canonical's config is at
fault. Consequently I have raised a bug report (
https://bugs.launchpad.net/ubuntu/+bug/1674523) in order to (hopefully)
address the issue. I will additionally submit a further patch that
(arguably) improves the current Kconfig file for the CONFIG_HDMI_LPE_AUDIO
setting by creating a specific menu for the CONFIG_HDMI_LPE_AUDIO setting,
adding additional narrative to further explain the function of the
CONFIG_HDMI_LPE_AUDIO setting and removing the subsequently unnecessary
CONFIG_SND_X86 setting. As a result, this patch ([PATCH v2] ALSA: x86:
Select CONFIG_HDMI_LPE_AUDIO as default) is withdrawn.

>
>
>> thanks,
>>
>> Takashi
>>
>
>