From: Hans de Goede <hdegoede@redhat.com>
To: Mark Brown <broonie@kernel.org>, Takashi Iwai <tiwai@suse.de>
Cc: Cezary Rojewski <cezary.rojewski@intel.com>,
krzysztof.hejmowski@intel.com, filip.kaczmarski@intel.com,
harshapriya.n@intel.com, lgirdwood@gmail.com,
ppapierkowski@habana.ai, marcin.barlik@intel.com,
zwisler@google.com, alsa-devel@alsa-project.org,
pierre-louis.bossart@linux.intel.com, filip.proborszcz@intel.com,
amadeuszx.slawinski@linux.intel.com, michal.wasko@intel.com,
tiwai@suse.com, andriy.shevchenko@linux.intel.com,
cujomalainey@chromium.org, vamshi.krishna.gopal@intel.com
Subject: Re: [PATCH v2 00/13] ASoC: Intel: Remove obsolete solutions and components
Date: Mon, 12 Oct 2020 13:53:54 +0200 [thread overview]
Message-ID: <bda70fe7-ac16-8215-5506-c4144064bcfd@redhat.com> (raw)
In-Reply-To: <20201012113626.GA4332@sirena.org.uk>
Hi,
On 10/12/20 1:36 PM, Mark Brown wrote:
> On Mon, Oct 12, 2020 at 11:09:04AM +0200, Takashi Iwai wrote:
>> Hans de Goede wrote:
>
>>> replacement and dropping the old code ? I'm not sure if that is such
>>> a great idea, what is the fallback plan if testing does find significant
>>> issues with the new catpt code ?
>
>> I find the action a bit too rushing, too. OTOH, the old code wasn't
>> well maintained, honestly speaking. So, from another perspective,
>> switching to a new code can be seen as a better chance to fix any
>> bugs.
>
> That was my take as well - the old code seemed to be very fragile for
> structural reasons which are hopefully addressed here and Intel seem
> willing to actively work on supporting this version. I have to confess
> I had assumed Hans had seen all this stuff going past, the new driver
> got quite a few rounds of review.
My ASoC interest is 99% Intel Bay Trail / Cherry Trail support, so
I'm not on alsa-devel list since that gets a lot more then just that.
IOW I'm relying on being Cc-ed, which might not be the best tactic
I guess.
Anyways, the Bay Trail / Cherry Trail changes here are 100% ok with me.
I pointed out the Haswell / Broadwell bits since I was taking a look
anyways, I don't really have a strong opinion on those, I've never seen
a Haswell / Broadwell machine actually using the SST/ASoC code,
all those which I have seen use the HDA driver.
And from the sounds of it for those rare Haswell / Broadwell machines
which do use the SST code the new catpt code should be an improvement.
So from my pov everything is good.
Regards,
Hans
next prev parent reply other threads:[~2020-10-12 11:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-06 6:48 [PATCH v2 00/13] ASoC: Intel: Remove obsolete solutions and components Cezary Rojewski
2020-10-06 6:48 ` [PATCH v2 01/13] ASoC: Intel: Remove haswell solution Cezary Rojewski
2020-10-06 6:48 ` [PATCH v2 02/13] ASoC: Intel: Remove max98090 support for baytrail solution Cezary Rojewski
2020-10-06 6:48 ` [PATCH v2 03/13] ASoC: Intel: Remove rt5640 " Cezary Rojewski
2020-10-06 6:48 ` [PATCH v2 04/13] ASoC: Intel: Remove " Cezary Rojewski
2020-10-06 6:48 ` [PATCH v2 05/13] ASoC: Intel: Remove SST ACPI component Cezary Rojewski
2020-10-06 6:49 ` [PATCH v2 06/13] ASoC: Intel: Remove SST firmware components Cezary Rojewski
2020-10-06 6:49 ` [PATCH v2 07/13] ASoC: Intel: Skylake: Unassign ram_read and read_write ops Cezary Rojewski
2020-10-06 6:49 ` [PATCH v2 08/13] ASoC: Intel: Remove unused DSP operations Cezary Rojewski
2020-10-06 6:49 ` [PATCH v2 09/13] ASoC: Intel: Remove unused DSP interface fields Cezary Rojewski
2020-10-06 6:49 ` [PATCH v2 10/13] ASoC: Intel: Remove SST-legacy specific constants Cezary Rojewski
2020-10-06 6:49 ` [PATCH v2 11/13] ASoC: Intel: Make atom components independent of sst-dsp Cezary Rojewski
2020-10-06 6:49 ` [PATCH v2 12/13] ASoC: Intel: Remove sst_pdata structure Cezary Rojewski
2020-10-06 6:49 ` [PATCH v2 13/13] ASoC: Intel: Remove sst_dsp_get_thread_context Cezary Rojewski
2020-10-06 12:22 ` [PATCH v2 00/13] ASoC: Intel: Remove obsolete solutions and components Liam Girdwood
2020-10-06 15:20 ` Pierre-Louis Bossart
2020-10-06 15:20 ` Mark Brown
2020-10-12 8:26 ` Hans de Goede
2020-10-12 9:09 ` Takashi Iwai
2020-10-12 11:36 ` Mark Brown
2020-10-12 11:53 ` Hans de Goede [this message]
2020-10-12 12:19 ` Rojewski, Cezary
2020-10-12 12:39 ` Mark Brown
2020-10-12 9:24 ` Rojewski, Cezary
2020-10-12 9:30 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bda70fe7-ac16-8215-5506-c4144064bcfd@redhat.com \
--to=hdegoede@redhat.com \
--cc=alsa-devel@alsa-project.org \
--cc=amadeuszx.slawinski@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=cujomalainey@chromium.org \
--cc=filip.kaczmarski@intel.com \
--cc=filip.proborszcz@intel.com \
--cc=harshapriya.n@intel.com \
--cc=krzysztof.hejmowski@intel.com \
--cc=lgirdwood@gmail.com \
--cc=marcin.barlik@intel.com \
--cc=michal.wasko@intel.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=ppapierkowski@habana.ai \
--cc=tiwai@suse.com \
--cc=tiwai@suse.de \
--cc=vamshi.krishna.gopal@intel.com \
--cc=zwisler@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).