[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <04ed7ed8-8a8d-427a-84e1-a326feee5547@sirena.org.uk>
Date: Wed, 19 Jul 2023 13:39:12 +0100
From: Mark Brown <broonie@...nel.org>
To: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
Cc: Takashi Iwai <tiwai@...e.de>,
Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
Alsa-devel <alsa-devel@...a-project.org>,
sound-open-firmware@...a-project.org, linux-kernel@...r.kernel.org,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>,
Cezary Rojewski <cezary.rojewski@...el.com>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
Bard Liao <yung-chuan.liao@...ux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
Daniel Baluta <daniel.baluta@....com>,
Matthew Auld <matthew.auld@...el.com>
Subject: Re: [PATCH] ASoC: SOF: Intel: Remove deferred probe for SOF
On Wed, Jul 19, 2023 at 02:13:59PM +0200, Maarten Lankhorst wrote:
>
> On 2023-07-19 13:06, Takashi Iwai wrote:
> > On Wed, 19 Jul 2023 11:48:06 +0200,
> > Maarten Lankhorst wrote:
> > >
> > > The 60 seconds timeout is a thing "better than complete disablement",
> > > so it's not ideal, either. Maybe we can add something like the
> > > following:
> > > - Check when the deferred probe takes too long, and warn it
> > > - Provide some runtime option to disable the component binding, so
> > > that user can work around it if needed
> > > A module option to snd_hdac_i915_init would probably be the least of all evils
> > > here.
> >
> > Yes, probably it's the easiest option and sufficient.
> >
> >
> > thanks,
> >
> > Takashi
> Hey,
>
> Patch below, can be applied immediately iresspective of the other patches.
>
> ---->8----------
>
> Selecting CONFIG_DRM selects CONFIG_VIDEO_NOMODESET, which exports
> video_firmware_drivers_only(). This can be used as a first approximation
> on whether i915 will be available. It's safe to use as this is only built
Please don't bury new patches in the middle of mails, it just makes it
hard to apply the patch since tooling doesn't understand what's going
on.
Please don't send new patches in reply to old patches or serieses, this
makes it harder for both people and tools to understand what is going
on - it can bury things in mailboxes and make it difficult to keep track
of what current patches are, both for the new patches and the old ones.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists