[v2] ALSA: x86: Select CONFIG_HDMI_LPE_AUDIO as default
diff mbox

Message ID CAFXWsS9-pEX0pF5=94_VK8xSF6sXC9991zbrnWByYB+++ve59Q@mail.gmail.com
State New
Headers show

Commit Message

Ian W MORRISON March 20, 2017, 7:42 a.m. UTC
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@linuxium.com.au>
---
 sound/x86/Kconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

Takashi Iwai March 20, 2017, 7:59 a.m. UTC | #1
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@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.


Takashi
Ian W MORRISON March 20, 2017, 8:17 a.m. UTC | #2
Oops ... forgot to copy alsa-devel and Pierre-Louis.

On 20 March 2017 at 18:59, Takashi Iwai <tiwai@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@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. 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.

>
> Takashi
>
Takashi Iwai March 20, 2017, 8:41 a.m. UTC | #3
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@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@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...?

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


Takashi
Ian W MORRISON March 20, 2017, 9:41 a.m. UTC | #4
On 20 March 2017 at 19:41, Takashi Iwai <tiwai@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@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@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'.



> > 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? Would adding
'CONFIG_HDMI_LPE_AUDIO=y' to 'arch/x86/configs/x86_64_defconfig' be another
mistake (assuming 'CONFIG_SND_X86' was set as per the first part of the
revised patch)? Would anyone even accept a patch
to 'arch/x86/configs/x86_64_defconfig' if this was acceptable?


>
> Takashi
>
Takashi Iwai March 20, 2017, 10:04 a.m. UTC | #5
On Mon, 20 Mar 2017 10:41:07 +0100,
Ian W MORRISON wrote:
> 
> On 20 March 2017 at 19:41, Takashi Iwai <tiwai@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@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@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...


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

> Would adding
> 'CONFIG_HDMI_LPE_AUDIO=y' to 'arch/x86/configs/x86_64_defconfig' be another
> mistake (assuming 'CONFIG_SND_X86' was set as per the first part of the
> revised patch)? Would anyone even accept a patch
> to 'arch/x86/configs/x86_64_defconfig' if this was acceptable?

The content in x86_64_defconfig is another story, and it's maintained
by x86 guys, so you can try it, of corse...


Takashi
> 
> 
> >
> > Takashi
> >
Ian W MORRISON March 20, 2017, 3:12 p.m. UTC | #6
On 20 March 2017 at 21:04, Takashi Iwai <tiwai@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@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@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@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?


> > Would adding
> > 'CONFIG_HDMI_LPE_AUDIO=y' to 'arch/x86/configs/x86_64_defconfig' be
> another
> > mistake (assuming 'CONFIG_SND_X86' was set as per the first part of the
> > revised patch)? Would anyone even accept a patch
> > to 'arch/x86/configs/x86_64_defconfig' if this was acceptable?
>
> The content in x86_64_defconfig is another story, and it's maintained
> by x86 guys, so you can try it, of corse...
>
>
>
If I have exhausted the possibilities here I guess I'll have to go knocking
on their door.


> Takashi
> >
> >
> > >
> > > Takashi
> > >
>
Takashi Iwai March 20, 2017, 5:57 p.m. UTC | #7
On Mon, 20 Mar 2017 16:12:01 +0100,
Ian W MORRISON wrote:
> 
> On 20 March 2017 at 21:04, Takashi Iwai <tiwai@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@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@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@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
Ian W MORRISON March 20, 2017, 10:02 p.m. UTC | #8
On 21 March 2017 at 04:57, Takashi Iwai <tiwai@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@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@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@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@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.


> thanks,
>
> Takashi
>
Takashi Iwai March 21, 2017, 5:27 a.m. UTC | #9
On Mon, 20 Mar 2017 23:02:25 +0100,
Ian W MORRISON wrote:
> 
> On 21 March 2017 at 04:57, Takashi Iwai <tiwai@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@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@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@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@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.

Simply because there was no upstream driver.  What does it have to do
with the default configuration issue we're arguing...?

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

On some of your devices, maybe.  But don't you have a machine with a
touchscreen or a WiFi / BT?  How does it work without setting the
config?

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

The feature *is* provided.  The rest you're requesting is something
different, merely a configuration, and this is exactly what distro
needs to take care, not the upstream kernel tree.  We don't set it to
y/m as default unless very specific reason is present.  This argument
was stated by Linus in the past a few times, too.

So, if you really want to make the default config y/m, please state
the very reason why this *must* be enabled as default for *all* x86-64
machines, not only CHT/BYT devices.


Takashi
Ian W MORRISON March 21, 2017, 3:09 p.m. UTC | #10
On 21 March 2017 at 16:27, Takashi Iwai <tiwai@suse.de> wrote:

> On Mon, 20 Mar 2017 23:02:25 +0100,
> Ian W MORRISON wrote:
> >
> > On 21 March 2017 at 04:57, Takashi Iwai <tiwai@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@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@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@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@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.
>
> Simply because there was no upstream driver.  What does it have to do
> with the default configuration issue we're arguing...?
>
> > > 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.
>
> On some of your devices, maybe.  But don't you have a machine with a
> touchscreen or a WiFi / BT?  How does it work without setting the
> config?
>
> > > 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.
>
> The feature *is* provided.  The rest you're requesting is something
> different, merely a configuration, and this is exactly what distro
> needs to take care, not the upstream kernel tree.  We don't set it to
> y/m as default unless very specific reason is present.  This argument
> was stated by Linus in the past a few times, too.
>
> So, if you really want to make the default config y/m, please state
> the very reason why this *must* be enabled as default for *all* x86-64
> machines, not only CHT/BYT devices.
>
>
Earlier Update: 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.

Final Update: The Canonical bug report
(https://bugs.launchpad.net/ubuntu/+bug/1674523) has been closed as
the maintainer has stated a new v4.11 config will be created once the
v4.11 kernel is included in unstable. ETA two weeks. The additional
patch was submitted, discussed and withdrawn.



>
> Takashi
>

Patch
diff mbox

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
        ---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
        select SND_PCM
        help
         Choose this option to support HDMI LPE Audio mode