Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1460867 > unrolled thread

Re: Correct modules for Bay Trail MAX98090 soc?

Started byPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
First post2016-08-12 01:40 +0200
Last post2016-08-12 21:30 +0200
Articles 7 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Correct modules for Bay Trail MAX98090 soc? Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> - 2016-08-12 01:40 +0200
    Re: Correct modules for Bay Trail MAX98090 soc? Mark Brown <broonie@kernel.org> - 2016-08-12 12:00 +0200
      Re: Correct modules for Bay Trail MAX98090 soc? Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> - 2016-08-12 13:40 +0200
        Re: Correct modules for Bay Trail MAX98090 soc? Mark Brown <broonie@kernel.org> - 2016-08-12 13:50 +0200
          Re: Correct modules for Bay Trail MAX98090 soc? Laura Abbott <labbott@redhat.com> - 2016-08-12 18:00 +0200
            Re: Correct modules for Bay Trail MAX98090 soc? Mark Brown <broonie@kernel.org> - 2016-08-12 18:20 +0200
              Re: [alsa-devel] Correct modules for Bay Trail MAX98090 soc? Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> - 2016-08-12 21:30 +0200

#1460867 — Re: Correct modules for Bay Trail MAX98090 soc?

FromPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date2016-08-12 01:40 +0200
SubjectRe: Correct modules for Bay Trail MAX98090 soc?
Message-ID<s57JT-2ia-1@gated-at.bofh.it>
On 8/11/16 3:42 PM, Laura Abbott wrote:
> Hi,
>
> Fedora got a bug report[1] that sound was failing on Intel Bay Trail Socs
> that use the MAX98090 module. I found
>
> Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> Date:   Mon Feb 8 10:45:38 2016 +0530
>
>     ASoC: Intel: Load the atom DPCM driver only
>         DPCM driver is recommended for BYT, CHT based platforms, so if
>     CONFIG_SND_SST_IPC_ACPI is selected then don't compile the BYT
>     Device IDs in common ACPI driver to avoid probe conflicts.
>         Signed-off-by: Pierre-Louis Bossart
> <pierre-louis.bossart@linux.intel.com>
>     Acked-by: Jie Yang <yang.jie@intel.com>
>     Signed-off-by: Vinod Koul <vinod.koul@intel.com>
>     Signed-off-by: Mark Brown <broonie@kernel.org>
>
>
> which changed the dependencies for CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH.
> The set of options Fedora selects means that
> CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH
> can't be selected. Is there another driver that's supposed to replace
> CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH on Bay Trail or do the dependencies
> need to be updated? The bugzilla has alsa-info for working and non-
> working cases and the Fedora config is attached.

If you remove support for all other baytrail options this driver should 
still be there and selectable. We just can't support both this driver 
for Chromebooks and the rest for other machines with the same 
distribution at the moment.

[toc] | [next] | [standalone]


#1461051

FromMark Brown <broonie@kernel.org>
Date2016-08-12 12:00 +0200
Message-ID<s5hpU-8r9-35@gated-at.bofh.it>
In reply to#1460867

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 11, 2016 at 06:31:27PM -0500, Pierre-Louis Bossart wrote:
> On 8/11/16 3:42 PM, Laura Abbott wrote:

> > which changed the dependencies for CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH.
> > The set of options Fedora selects means that
> > CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH
> > can't be selected. Is there another driver that's supposed to replace
> > CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH on Bay Trail or do the dependencies
> > need to be updated? The bugzilla has alsa-info for working and non-
> > working cases and the Fedora config is attached.

> If you remove support for all other baytrail options this driver should
> still be there and selectable. We just can't support both this driver for
> Chromebooks and the rest for other machines with the same distribution at
> the moment.

That sounds like a regression, what's the plan to fix it.

[toc] | [prev] | [next] | [standalone]


#1461114

FromPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date2016-08-12 13:40 +0200
Message-ID<s5iYF-12Q-23@gated-at.bofh.it>
In reply to#1461051
On 8/12/16 4:53 AM, Mark Brown wrote:
> On Thu, Aug 11, 2016 at 06:31:27PM -0500, Pierre-Louis Bossart wrote:
>> On 8/11/16 3:42 PM, Laura Abbott wrote:
>
>>> which changed the dependencies for CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH.
>>> The set of options Fedora selects means that
>>> CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH
>>> can't be selected. Is there another driver that's supposed to replace
>>> CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH on Bay Trail or do the dependencies
>>> need to be updated? The bugzilla has alsa-info for working and non-
>>> working cases and the Fedora config is attached.
>
>> If you remove support for all other baytrail options this driver should
>> still be there and selectable. We just can't support both this driver for
>> Chromebooks and the rest for other machines with the same distribution at
>> the moment.
>
> That sounds like a regression, what's the plan to fix it.

The simple fix is easy: disable all other codecs and the
BYT_MAX98090 option will be enabled. BYT_MAX98090 relies on the 'old' 
non-dpcm driver which is used only for Chromebooks with Baytrail, which 
never enable any other codecs, so there was never any issue before.
If there is a need for concurrency, then a new machine driver based on 
the dpcm Atom driver needs to be created. I don't have a Baytrail 
chromebook so don't want to commit on the change.

[toc] | [prev] | [next] | [standalone]


#1461125

FromMark Brown <broonie@kernel.org>
Date2016-08-12 13:50 +0200
Message-ID<s5j8m-16d-29@gated-at.bofh.it>
In reply to#1461114

[Multipart message — attachments visible in raw view] — view raw

On Fri, Aug 12, 2016 at 06:37:11AM -0500, Pierre-Louis Bossart wrote:
> On 8/12/16 4:53 AM, Mark Brown wrote:
> > On Thu, Aug 11, 2016 at 06:31:27PM -0500, Pierre-Louis Bossart wrote:

> > > If you remove support for all other baytrail options this driver should
> > > still be there and selectable. We just can't support both this driver for
> > > Chromebooks and the rest for other machines with the same distribution at
> > > the moment.

> > That sounds like a regression, what's the plan to fix it.

> The simple fix is easy: disable all other codecs and the
> BYT_MAX98090 option will be enabled. BYT_MAX98090 relies on the 'old'
> non-dpcm driver which is used only for Chromebooks with Baytrail, which
> never enable any other codecs, so there was never any issue before.

That's not really that helpful for a distro kernel (this is for Fedora
AIUI).

> If there is a need for concurrency, then a new machine driver based on the
> dpcm Atom driver needs to be created. I don't have a Baytrail chromebook so
> don't want to commit on the change.

Presumably someone at Intel has one (or could get one)?

[toc] | [prev] | [next] | [standalone]


#1461284

FromLaura Abbott <labbott@redhat.com>
Date2016-08-12 18:00 +0200
Message-ID<s5n2i-3z3-7@gated-at.bofh.it>
In reply to#1461125
On 08/12/2016 04:49 AM, Mark Brown wrote:
> On Fri, Aug 12, 2016 at 06:37:11AM -0500, Pierre-Louis Bossart wrote:
>> On 8/12/16 4:53 AM, Mark Brown wrote:
>>> On Thu, Aug 11, 2016 at 06:31:27PM -0500, Pierre-Louis Bossart wrote:
>
>>>> If you remove support for all other baytrail options this driver should
>>>> still be there and selectable. We just can't support both this driver for
>>>> Chromebooks and the rest for other machines with the same distribution at
>>>> the moment.
>
>>> That sounds like a regression, what's the plan to fix it.
>
>> The simple fix is easy: disable all other codecs and the
>> BYT_MAX98090 option will be enabled. BYT_MAX98090 relies on the 'old'
>> non-dpcm driver which is used only for Chromebooks with Baytrail, which
>> never enable any other codecs, so there was never any issue before.
>
> That's not really that helpful for a distro kernel (this is for Fedora
> AIUI).
>

Yes, this is unfortunate as it means that something is going to lose sound
support in Fedora. :( It's probably going to be the Chromebook unless another
group starts screaming louder.

Thanks,
Laura

[toc] | [prev] | [next] | [standalone]


#1461300

FromMark Brown <broonie@kernel.org>
Date2016-08-12 18:20 +0200
Message-ID<s5nlD-3VR-5@gated-at.bofh.it>
In reply to#1461284

[Multipart message — attachments visible in raw view] — view raw

On Fri, Aug 12, 2016 at 08:51:34AM -0700, Laura Abbott wrote:
> On 08/12/2016 04:49 AM, Mark Brown wrote:

> > That's not really that helpful for a distro kernel (this is for Fedora
> > AIUI).

> Yes, this is unfortunate as it means that something is going to lose sound
> support in Fedora. :( It's probably going to be the Chromebook unless another
> group starts screaming louder.

Debian will be in the same boat too, there's another release coming
soon.

[toc] | [prev] | [next] | [standalone]


#1461431 — Re: [alsa-devel] Correct modules for Bay Trail MAX98090 soc?

FromPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date2016-08-12 21:30 +0200
SubjectRe: [alsa-devel] Correct modules for Bay Trail MAX98090 soc?
Message-ID<s5qjB-5Ua-7@gated-at.bofh.it>
In reply to#1461300
On 8/12/16 11:12 AM, Mark Brown wrote:
> On Fri, Aug 12, 2016 at 08:51:34AM -0700, Laura Abbott wrote:
>> On 08/12/2016 04:49 AM, Mark Brown wrote:
>
>>> That's not really that helpful for a distro kernel (this is for Fedora
>>> AIUI).
>
>> Yes, this is unfortunate as it means that something is going to lose sound
>> support in Fedora. :( It's probably going to be the Chromebook unless another
>> group starts screaming louder.
>
> Debian will be in the same boat too, there's another release coming
> soon.

It's not necessarily terribly complicated to enable this codec:
- we could borrow code from the existing code from the 
cht_bsw_max98090_ti machine driver which relies on the dpcm driver.
- the patches developed for Baytrail-Cr will provide support for the 
19.2MHz MCLK needed by this codec, they should land on the alsa-devel 
mailing list this afternoon or early next week.
The main issue is to find hardware and someone with bandwidth to do the 
changes.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web