Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1460867 > unrolled thread
| Started by | Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> |
|---|---|
| First post | 2016-08-12 01:40 +0200 |
| Last post | 2016-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.
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
| From | Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> |
|---|---|
| Date | 2016-08-12 01:40 +0200 |
| Subject | Re: 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]
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2016-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]
| From | Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> |
|---|---|
| Date | 2016-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]
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2016-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]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2016-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]
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2016-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]
| From | Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> |
|---|---|
| Date | 2016-08-12 21:30 +0200 |
| Subject | Re: [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