On Wed, 22 Sep 2021 10:54:32 +0200,
Kai Vehmanen wrote:
(snip)
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -246,7 +246,7 @@ static int try_to_bring_up_master(struct master *master,
> return 0;
> }
>
> - if (!devres_open_group(master->parent, NULL
On Mon, 21 Jun 2021 19:44:15 +0200,
Imre Deak wrote:
>
> Make sure the HDA driver's display power reference is released during
> shutdown/reboot.
>
> During the shutdown/reboot sequence the pci device core calls the
> pm_runtime_resume handler for all devices before calling the driver's
> shutdow
On Tue, 22 Jun 2021 21:58:13 +0200,
Imre Deak wrote:
>
> On Tue, Jun 22, 2021 at 04:18:14PM +0200, Takashi Iwai wrote:
> > On Mon, 21 Jun 2021 19:44:15 +0200,
> > Imre Deak wrote:
> > >
> > > Make sure the HDA driver's display power reference
ing rid of the above WARN.
>
> Tested on HSW.
>
> v2:
> - Fix the build for CONFIG_PM=n (Takashi)
> - s/__azx_runtime_suspend/azx_shutdown_chip/
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3618
> References:
> https://lore.kernel.org/lkml/cea1f9
reported recently.
Add the checks of the contents in the returned values and skip the
values for invalid cases.
BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1184074
Cc:
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/display/intel_acpi.c | 12
1 file changed, 12 insertions
On Fri, 02 Apr 2021 09:47:49 +0200,
Takashi Iwai wrote:
>
> intel_dsm_platform_mux_info() tries to parse the ACPI package data
> from _DSM for the debug information, but it assumes the fixed format
> without checking what values are stored in the elements actually.
> When an unex
reported recently.
Add the checks of the contents in the returned values and skip the
values for invalid cases.
v1->v2: Check the info contents before dereferencing, too
BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1184074
Cc:
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/disp
On Wed, 07 Apr 2021 18:34:46 +0200,
Ville Syrjälä wrote:
>
> On Fri, Apr 02, 2021 at 10:23:17AM +0200, Takashi Iwai wrote:
> > intel_dsm_platform_mux_info() tries to parse the ACPI package data
> > from _DSM for the debug information, but it assumes the fixed format
> &g
On Wed, 07 Apr 2021 23:28:48 +0200,
Ville Syrjälä wrote:
>
> On Wed, Apr 07, 2021 at 06:56:15PM +0200, Takashi Iwai wrote:
> > On Wed, 07 Apr 2021 18:34:46 +0200,
> > Ville Syrjälä wrote:
> > >
> > > On Fri, Apr 02, 2021 at
On Thu, 08 Apr 2021 09:51:18 +0200,
Takashi Iwai wrote:
>
> On Wed, 07 Apr 2021 23:28:48 +0200,
> Ville Syrjälä wrote:
> >
> > Oh, could you ask the bug reporter to attach an acpidump to the
> > bug? Might be good to have that stuff on record somewhere if/when
&g
On Thu, 08 Apr 2021 18:56:06 +0200,
Ville Syrjälä wrote:
>
> On Thu, Apr 08, 2021 at 06:34:06PM +0200, Takashi Iwai wrote:
> > On Thu, 08 Apr 2021 09:51:18 +0200,
> > Takashi Iwai wrote:
> > >
> > > On Wed, 07 Apr 2021 23:28:48 +0200,
> > > Ville Syrj
e the scenario?
thanks,
Takashi
>
> Signed-off-by: Chris Wilson
> Cc: Takashi Iwai
> Cc: Jani Nikula
> ---
> include/sound/hdaudio.h| 1 +
> sound/hda/hdac_component.c | 7 +++
> 2 files changed, 8 insertions(+)
>
> diff --git a/include/sound/hdaudio.h b/
runtime pm leaks.
>
> Signed-off-by: Chris Wilson
> Cc: Takashi Iwai
> Cc: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_audio.c | 10 +-
> include/drm/drm_audio_component.h | 7 +--
> include/sound/hdaudio.h| 4 ++--
> sound/hda/hdac_co
On Mon, 14 Jan 2019 18:51:31 +0100,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-01-14 17:46:57)
> > On Mon, 14 Jan 2019 18:37:53 +0100,
> > Chris Wilson wrote:
> > >
> > > Just in case the audio linkage is swapped between components during the
> >
On Mon, 14 Jan 2019 21:57:15 +0100,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-01-14 18:00:02)
> > On Mon, 14 Jan 2019 18:51:31 +0100,
> > Chris Wilson wrote:
> > >
> > > Quoting Takashi Iwai (2019-01-14 17:46:57)
> > > > On Mon, 14 Jan
On Wed, 16 Jan 2019 18:48:25 +0100,
Pierre-Louis Bossart wrote:
>
> Hi,
>
> I could use some feedback on HDMI audio issues exposed during the 4.21
> merge window. By accident (misleading documentation) we ended up
> enabling the Skylake driver instead of the HDaudio legacy, and broke
> audio on a
On Thu, 17 Jan 2019 20:53:06 +0100,
Pierre-Louis Bossart wrote:
>
>
> > I could use some feedback on HDMI audio issues exposed during the
> > 4.21 merge window. By accident (misleading documentation) we ended
> > up enabling the Skylake driver instead of the HDaudio legacy, and
> > broke audio on
On Thu, 17 Jan 2019 21:47:05 +0100,
Pierre-Louis Bossart wrote:
>
>
> >> I tried to narrow down the issue further and my current understanding
> >> is that the Skylake driver performs link reset operations without the
> >> display power turned on - which does not look like a very smart thing
> >>
* Rebase for RUNTIME_INFO.
>
> v24:
> * Added some headline docs for the uapi usage. (Joonas/Chris)
>
> v25:
> * Renamed class/instance to engine_class/engine_instance to avoid clash
>with C++ keyword. (Tony Ye)
>
> Bugzilla: https://bugs.freedesktop.org/sho
fluous
> AZX_DCAPS_I915_POWERWELL checks")
> Signed-off-by: Chris Wilson
> Cc: Takashi Iwai
> Cc: Imre Deak
> ---
> This appears to fix the glk-dsi as it performs a pm_runtime_suspend in
> the middle of azx_probe_contime(). Hopefully.
> ---
> sound/pci/hda/hda_intel
On Wed, 10 Apr 2019 00:53:31 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-04-09 22:35:28)
> > On Tue, 09 Apr 2019 23:27:41 +0200,
> > Chris Wilson wrote:
> > >
> > > In runtime_resume, we release the local display_power wakeref if we can
> >
On Wed, 10 Apr 2019 09:59:19 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-04-10 06:29:07)
> > On Wed, 10 Apr 2019 00:53:31 +0200,
> > Chris Wilson wrote:
> > >
> > > Quoting Takashi Iwai (2019-04-09 22:35:28)
> > > > On Tue, 09 Apr
t; tracking the display_power_active cookie.
>
> Testcase: igt/i915_pm_rpm/module-reload #glk-dsi
> Signed-off-by: Chris Wilson
> Cc: Takashi Iwai
> Cc: Imre Deak
I rather prefer a more straightforward conversion, e.g. something like
below. Checking the returned cookie as the state flag is
On Wed, 10 Apr 2019 12:24:24 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-04-10 11:09:47)
> > On Wed, 10 Apr 2019 10:17:33 +0200,
> > Chris Wilson wrote:
> > >
> > > While we only allow a single display power reference, the current
> > >
On Wed, 10 Apr 2019 12:44:49 +0200,
Takashi Iwai wrote:
>
> On Wed, 10 Apr 2019 12:24:24 +0200,
> Chris Wilson wrote:
> >
> > Quoting Takashi Iwai (2019-04-10 11:09:47)
> > > On Wed, 10 Apr 2019 10:17:33 +0200,
> > > Chris Wilson wrote:
> > > >
On Wed, 10 Apr 2019 15:07:28 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-04-10 12:03:22)
> > On Wed, 10 Apr 2019 12:44:49 +0200,
> > Takashi Iwai wrote:
> > >
> > > On Wed, 10 Apr 2019 12:24:24 +0200,
> > > Chris Wilson wrote:
> >
On Wed, 03 Aug 2016 04:14:29 +0200,
Dhinakaran Pandiyan wrote:
>
>
> An additional parameter has been added to the API's between i915 and audio
> drivers to identify display devices that can be connected to the same port.
> Currently only the port identity is being shared, but this is not
> suffi
On Wed, 03 Aug 2016 04:14:30 +0200,
Dhinakaran Pandiyan wrote:
>
> DP MST provides the capability to send multiple video and audio streams via
> one single port. This requires the API's between i915 and audio drivers to
> distinguish between audio capable displays connected to a port. This patch
>
On Thu, 04 Aug 2016 19:35:16 +0200,
Ville Syrjälä wrote:
>
> On Thu, Aug 04, 2016 at 10:18:52AM -0700, Jim Bride wrote:
> > On Wed, Aug 03, 2016 at 10:08:12PM +0300, Ville Syrjälä wrote:
> > > On Tue, Aug 02, 2016 at 07:14:30PM -0700, Dhinakaran Pandiyan wrote:
> > > > DP MST provides the capabili
On Thu, 04 Aug 2016 18:44:11 +0200,
Daniel Vetter wrote:
>
> On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote:
> > On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display
> > power well and so the sna-hda audio codec acquires the display power
> > well while it is operation
[dropped stable ML and add a few other relevant people to Cc]
On Thu, 04 Aug 2016 20:05:27 +0200,
Takashi Iwai wrote:
>
> On Thu, 04 Aug 2016 18:44:11 +0200,
> Daniel Vetter wrote:
> >
> > On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote:
> > > On H
Daniel Vetter
> > Signed-off-by: Ramalingam C
> > cc: Greg Kroah-Hartman
> > cc: Russell King
> > cc: Rafael J. Wysocki
> > cc: Jaroslav Kysela
> > cc: Takashi Iwai
> > cc: Rodrigo Vivi
> > cc: Jani Nikula
>
> Takashi, can you pls take
On Mon, 11 Feb 2019 19:25:12 +0100,
Sam Ravnborg wrote:
>
> Hi Daniel.
>
> On Mon, Feb 11, 2019 at 06:15:20PM +0100, Daniel Vetter wrote:
> > Hi all,
> >
> > Here's the typed component topic branch.
> >
> > drm-intel maintainers: Please pull, I need this for the mei hdcp work from
> > Ram.
> >
e runtime pm leaks.
>
> v2: Keep using the power abstraction for local wakeref tracking.
>
> Signed-off-by: Chris Wilson
> Cc: Takashi Iwai
> Cc: Jani Nikula
Feel free to take my ack:
Reviewed-by: Takashi Iwai
Or let me know if you guys want to apply this t
a
> Cc: Emmanuel Jillela
> Cc: Kai Vehmanen
> Cc: Takashi Iwai
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2623
> Fixes: 951894cf30f4 ("ALSA: hda/hdmi: Add Intel silent stream support")
> Signed-off-by: Ville Syrjälä
Thanks, applied now.
Takashi
On Wed, 09 Mar 2022 19:24:39 +0100,
Kai Vehmanen wrote:
>
> If kernel is built with hung task detection enabled and
> CONFIG_DEFAULT_HUNG_TASK_TIMEOUT set to less than 60 seconds,
> snd_hdac_i915_init() will trigger the hung task timeout in case i915 is
> not available and taint the kernel.
>
> U
oo late to the game (just back from vacation), but FWIW:
Reviewed-by: Takashi Iwai
thanks,
Takashi
On Mon, 18 Apr 2022 06:50:32 +0200,
Lucas De Marchi wrote:
>
> On Sun, Apr 17, 2022 at 01:13:49PM +0300, Kai Vehmanen wrote:
> >Hi,
> >
> >On Fri, 15 Apr 2022, Lucas De Marchi wrote:
> >
> >> pci_get_class() will already unref the pci device passed as argument.
> >> So if it's unconditionally unre
On Tue, 19 Apr 2022 08:26:06 +0200,
Lucas De Marchi wrote:
>
> On Tue, Apr 19, 2022 at 07:54:30AM +0200, Takashi Iwai wrote:
> >On Mon, 18 Apr 2022 06:50:32 +0200,
> >Lucas De Marchi wrote:
> >>
> >> On Sun, Apr 17, 2022 at 01:13:49PM +0300, Kai Vehmanen wrot
On Tue, 19 Apr 2022 08:40:01 +0200,
Takashi Iwai wrote:
>
> On Tue, 19 Apr 2022 08:26:06 +0200,
> Lucas De Marchi wrote:
> >
> > On Tue, Apr 19, 2022 at 07:54:30AM +0200, Takashi Iwai wrote:
> > >On Mon, 18 Apr 2022 06:50:32 +0200,
> > >Lucas De Marchi wr
> Cc: Kai Vehmanen
> Cc: Takashi Iwai
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5701
> Fixes: 0dc2696a4623 ("ALSA: hda/i915 - skip acomp init if no matching
> display")
> Signed-off-by: Lucas De Marchi
Thanks, applied now.
But the Fixes commit
On Wed, 10 Nov 2021 22:03:07 +0100,
Kai Vehmanen wrote:
>
> Fix a corner case between PCI device driver remove callback and
> runtime PM idle callback.
>
> Following sequence of events can happen:
> - at azx_create, context is allocated with devm_kzalloc() and
> stored as pci_set_drvdata()
On Wed, 10 Nov 2021 23:15:40 +0100,
Kai Vehmanen wrote:
>
> Hey,
>
> On Wed, 10 Nov 2021, Takashi Iwai wrote:
>
> > On Wed, 10 Nov 2021 22:03:07 +0100, Kai Vehmanen wrote:
> > > Fix a corner case between PCI device driver remove callback and
> > > runti
On Thu, 11 Nov 2021 18:39:36 +0100,
Kai Vehmanen wrote:
>
> Hi,
>
> On Thu, 11 Nov 2021, Takashi Iwai wrote:
>
> > A potential problem with the current code is that it doesn't disable
> > the runtime PM at the release procedure. Could you try the patch
> >
On Fri, 12 Nov 2021 13:27:34 +0100,
Kai Vehmanen wrote:
>
> Hi,
>
> On Fri, 12 Nov 2021, Takashi Iwai wrote:
>
> > On Thu, 11 Nov 2021 18:39:36 +0100, Kai Vehmanen wrote:
> > > And later
> > > [ 54.770701] Enabling runtime PM for inactive device (00
On Thu, 24 Feb 2022 17:34:54 +0100,
Kai Vehmanen wrote:
>
> Hi,
>
> On Thu, 24 Feb 2022, Ramalingam C wrote:
>
> > Split the wait for component binding from i915 in multiples of
> > sysctl_hung_task_timeout_secs. This helps to avoid the possible kworker
> > thread hung detection given below.
>
On Tue, 08 Mar 2022 17:29:21 +0100,
Amadeusz SX2awiX4ski wrote:
>
> On 3/8/2022 3:11 PM, Kai Vehmanen wrote:
> > If kernel is built with hung task detection enabled and
> > CONFIG_DEFAULT_HUNG_TASK_TIMEOUT set to less than 60 seconds,
> > snd_hdac_i915_init() will trigger the hung task timeout in
On Wed, 09 Mar 2022 09:36:54 +0100,
Tvrtko Ursulin wrote:
>
>
> On 08/03/2022 17:27, Kai Vehmanen wrote:
> > If kernel is built with hung task detection enabled and
> > CONFIG_DEFAULT_HUNG_TASK_TIMEOUT set to less than 60 seconds,
> > snd_hdac_i915_init() will trigger the hung task timeout in cas
On Wed, 09 Mar 2022 10:02:13 +0100,
Tvrtko Ursulin wrote:
>
>
> On 09/03/2022 08:39, Kai Vehmanen wrote:
> > Hi,
> >
> > On Wed, 9 Mar 2022, Tvrtko Ursulin wrote:
> >
> >>> - /* 60s timeout */
> >>
> >> Where does this 60s come from and why is the fix to work around
> >> DEFAULT_H
On Wed, 09 Mar 2022 10:48:49 +0100,
Tvrtko Ursulin wrote:
>
>
> On 09/03/2022 09:23, Takashi Iwai wrote:
> > On Wed, 09 Mar 2022 10:02:13 +0100,
> > Tvrtko Ursulin wrote:
> >>
> >>
> >> On 09/03/2022 08:39, Kai Vehmanen wrote:
> >>&
; [ 203.716572] ? kthread_create_worker_on_cpu+0x20/0x20
> [ 203.716574] ret_from_fork+0x2e/0x38
>
> Looks like commit ade49db337a9 ("ALSA: hda/hdmi - Allow audio
> component for AMD/ATI and Nvidia HDMI") introduced pcm_lock
> to generic_hdmi_init().
Indeed, that c
On Wed, 30 Oct 2019 14:50:09 +0100,
Ville Syrjälä wrote:
>
> On Tue, Oct 29, 2019 at 09:52:57PM +0100, Takashi Iwai wrote:
> > On Tue, 29 Oct 2019 20:10:50 +0100,
> > From: Takashi Iwai
> > Subject: [PATCH] ALSA: hda - Fix mutex deadlock in HDMI codec driver
> >
On Mon, 04 Nov 2019 14:10:24 +0100,
Mika Westerberg wrote:
>
> Hi,
>
> On Mon, Nov 04, 2019 at 01:57:54PM +0100, Paul Menzel wrote:
> > Dear Linux folks,
> >
> >
> > On the Dell XPS 13 9380 with Debian Sid/unstable with Linux 5.3.7
> > resuming0with Dell’s Thunderbolt TB16 dock connected, Linux
On Mon, 04 Nov 2019 15:58:25 +0100,
Mika Westerberg wrote:
>
> On Mon, Nov 04, 2019 at 02:19:21PM +0100, Takashi Iwai wrote:
> > On Mon, 04 Nov 2019 14:10:24 +0100,
> > Mika Westerberg wrote:
> > >
> > > Hi,
> > >
> > > On Mon, Nov 04, 201
On Fri, 03 Jan 2020 02:57:03 +0100,
wrote:
>
> Hi Sirs,
> Here is chromebook SW team from Compal.
> As the mail title, we hit issue that the external monitor will flash once
> when play video after hot pluging.
> We can reproduce not only on chromebook but also ubuntu 16.04.
> There has
ave fixed this
> issue?
The first suspect would be
2756d9143aa517b97961e85412882b8ce31371a6
ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips
Takashi
>
> Thanks,
> Nathan
> >
> > Thanks.
> >
> >
> > -Original Message-
> > From: Takashi Iwai
>
n i915 graphics side, or even
thunderbolt or whatever, too...
Takashi
>
> -Original Message-
> From: Takashi Iwai
> Sent: Wednesday, January 8, 2020 2:57 AM
> To: Nathan Ciobanu
> Cc: Kao. Lucien (TPE) ; Cheng. AJ (TPE)
> ; intel-gfx@lists.freedesktop.org;
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +++---
1 file changed, 3
On Wed, 11 Mar 2020 13:16:56 +0100,
Kai Vehmanen wrote:
>
> Hey,
>
> On Tue, 10 Mar 2020, Takashi Iwai wrote:
> > On Tue, 10 Mar 2020 19:25:22 +0100, Ville Syrjälä wrote:
> >> On Tue, Mar 10, 2020 at 07:18:58PM +0200, Kai Vehmanen wrote:
> >>> One probl
On Wed, 11 Mar 2020 18:04:24 +0100,
Kai Vehmanen wrote:
>
> Hey,
>
> On Wed, 11 Mar 2020, Takashi Iwai wrote:
>
> > The remaining question is whether this display_power() call is still
> > needed for the recent chips. Basically it's there for HSW/BDW type
>
> which has the hallmarks of a worker queued from interrupt after it was
> supposedly cancelled (note the POISON_FREE), and I could not see where
> the interrupt would be flushed on shutdown so added the likely suspects.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74
> Signe
in anyway.
If that patch broke anything, it means that something else was already
broken. Oh well, that ICL crap...
Is it about the runtime PM, or S3 or S4? The only case we need to
re-issue this verb is only S4, I suppose, so we may skip that in most
cases.
thanks,
Takashi
>
> Cc: Takashi
On Thu, 25 Jul 2019 10:16:07 +0200,
Takashi Iwai wrote:
>
> On Thu, 25 Jul 2019 10:03:00 +0200,
> Chris Wilson wrote:
> >
> > Just a heads up that icl is consistently showing
> >
> > <4> [315.478830] snd_hda_intel :00:1f.3: azx_get_response timeout,
On Thu, 25 Jul 2019 12:21:11 +0200,
Chris Wilson wrote:
>
> Quoting Chris Wilson (2019-07-25 09:30:25)
> > Quoting Takashi Iwai (2019-07-25 09:26:56)
> > > On Thu, 25 Jul 2019 10:16:07 +0200,
> > > Takashi Iwai wrote:
> > > >
> > > > On Thu,
On Thu, 25 Jul 2019 14:50:18 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-07-25 11:44:08)
> > On Thu, 25 Jul 2019 12:21:11 +0200,
> > Chris Wilson wrote:
> > >
> > > Quoting Chris Wilson (2019-07-25 09:30:25)
> > > > Quoting Takashi
On Thu, 25 Jul 2019 12:49:12 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-07-25 11:44:08)
> > On Thu, 25 Jul 2019 12:21:11 +0200,
> > Chris Wilson wrote:
> > >
> > > Quoting Chris Wilson (2019-07-25 09:30:25)
> > > > Quoting Takashi
On Thu, 25 Jul 2019 15:57:10 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-07-25 14:45:10)
> > On Thu, 25 Jul 2019 12:49:12 +0200,
> > Chris Wilson wrote:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13745/fi-icl-u2/igt@i915_module_l...@reload
ree+0x60/0x90
> <4> [281.912939] pci_device_remove+0x36/0xb0
> <4> [281.912946] device_release_driver_internal+0xd3/0x1b0
> <4> [281.912953] unbind_store+0xc3/0x120
> <4> [281.912962] kernfs_fop_write+0x104/0x190
> <4> [281.912971] vfs_write
.
Revert for now to make everything back to work.
Fixes: ee5f85d9290f ("ALSA: hda: Add codec on bus address table lately")
Reported-by: Chris Wilson
Signed-off-by: Takashi Iwai
---
sound/hda/hdac_device.c | 21 +
1 file changed, 9 insertions(+), 12 deleti
t;
> Without patch
> 2020-02-12T00:55:36.795016-08:00 ERR kernel: [ 125.047502] @@@ cvt_nid power
> state: 1
> 2020-02-12T00:55:36.795026-08:00 ERR kernel: [ 125.047565] @@@ nid power
> state: 0
>
> -Original Message-
> From: Takashi Iwai
> Sent: Wednesd
t it add a code comment about the platform specific maximum
> timeout values.
>
> Reported-by: Takashi Iwai
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166
> Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link
> training")
&
On Tue, 06 Oct 2020 18:17:22 +0200,
Kai Vehmanen wrote:
>
> From: Takashi Iwai
>
> Current hdac_i915 uses a static completion instance to wait
> for i915 driver to complete the component bind.
>
> This design is not safe if multiple HDA controllers are active and
> comm
On Fri, 06 Mar 2020 17:45:44 +0100,
Kai Vehmanen wrote:
>
> Hi folks,
>
> [+Takashi from ALSA]
>
> On Mon, 6 Jan 2020, Matt Roper wrote:
> >>> On Tue, Dec 31, 2019 at 04:00:07PM +0200, Kai Vehmanen wrote:
> Revert changes done in commit f6ec9483091f ("drm/i915: extend audio
> CDCLK>=2*
On Tue, 10 Mar 2020 19:25:22 +0100,
Ville Syrjälä wrote:
>
> On Tue, Mar 10, 2020 at 07:18:58PM +0200, Kai Vehmanen wrote:
> > One problematic scenario that this doesn't cover:
> > - a single display is used (at low cdclk), and
> > - audio block goes to runtime suspend while display stays up.
On Mon, 11 Dec 2017 14:20:23 +0100,
Ville Syrjälä wrote:
>
> On Mon, Dec 11, 2017 at 08:33:33AM +, Anand, Jerome wrote:
> >
> >
> > > -Original Message-
> > > From: Thomas Gleixner [mailto:t...@linutronix.de]
> > > Sent: Saturday, December 9, 2017 4:22 AM
> > > To: Ville Syrjälä
> >
On Tue, 12 Dec 2017 10:26:08 +0100,
Chen, Augustine wrote:
> > > > > > That *looks* more correct to me based on a cursory glance at the
> > > > > > x86 code, but I didn't trawl very deeply.
> > > > >
> > > > > The x86 core cares not at all about interrupt chips which are
> > > > > created in a driv
On Wed, 13 Dec 2017 12:35:54 +0100,
Thomas Gleixner wrote:
>
> > > On Mon, 11 Dec 2017, Anand, Jerome wrote:
> > > > > On Fri, 8 Dec 2017, Ville Syrjälä wrote:
> > > > >
> > > > > > On Fri, Dec 08, 2017 at 05:33:23PM +0800, Augustine.Chen wrote:
> > > > > > > The chip data of HDMI LPE audio is set
On Fri, 27 Apr 2018 10:04:13 +0200,
Jani Nikula wrote:
>
> On Thu, 26 Apr 2018, Imre Deak wrote:
> > On Thu, Apr 26, 2018 at 03:41:57PM +0300, David Weinehall wrote:
> >> On Fri, Mar 23, 2018 at 08:30:48AM +, Chris Wilson wrote:
> >> > As we are careful not to register external interfaces bef
familiar
> with hda and not i915.
Agreed, it's more consistent to have a pair of the same terms
(pipe, port) vs (dev_id, nid).
Except for that, the changes in the audio side look trivial, and it's
probably better to go through drm tree, so feel free to take my ack:
Reviewed-by
Hi,
while debugging our 4.4.x based SLE12-SP2 kernel, we noticed that S4
resume is broken on many machines with i915 gfx, even on the upstream
4.7 kernel. Originally it was reported by Intel about SKL machines,
but later on, we found that it hits on many other older chips (at
least HSW), too.
Th
On Thu, 25 Aug 2016 17:32:41 +0200,
Chris Wilson wrote:
>
> On Thu, Aug 25, 2016 at 03:11:35PM +0200, Takashi Iwai wrote:
> > Hi,
> >
> > while debugging our 4.4.x based SLE12-SP2 kernel, we noticed that S4
> > resume is broken on many machines with i915 gfx, even
On Thu, 25 Aug 2016 18:12:19 +0200,
Chris Wilson wrote:
>
> > Maybe But it's hard to tell exactly whether this is
> > the 100% culprit. As said, there have been multiple S4 bugs, so far.
> > IVY worked without this patch (after x86 fixes), but obviously this
> > had no negative effect, either.
>
On Thu, 25 Aug 2016 18:15:37 +0200,
Takashi Iwai wrote:
>
> On Thu, 25 Aug 2016 18:12:19 +0200,
> Chris Wilson wrote:
> >
> > > Maybe But it's hard to tell exactly whether this is
> > > the 100% culprit. As said, there have been multiple S4 bugs, so fa
On Fri, 26 Aug 2016 11:18:00 +0200,
Takashi Iwai wrote:
>
> On Thu, 25 Aug 2016 18:15:37 +0200,
> Takashi Iwai wrote:
> >
> > On Thu, 25 Aug 2016 18:12:19 +0200,
> > Chris Wilson wrote:
> > >
> > > > Maybe But it's hard to tell exactly whet
t 11:39 +0100, Chris Wilson wrote:
> > > > > On Fri, Aug 26, 2016 at 12:25:01PM +0200, Takashi Iwai wrote:
> > > > > > On Fri, 26 Aug 2016 11:18:00 +0200,
> > > > > > Takashi Iwai wrote:
> > > > > > > I had to modify the intel
broke runtime PM with lpe audio. We can no longer
> > runtime suspend the GPU since the sysfs power/control for the
> > lpe-audio device no longer exists and the device is considered
> > always active. We can fix this by not marking the device as
> > active.
> >
>
On Sun, 09 Apr 2017 22:32:46 +0200,
Hans de Goede wrote:
>
> Hi,
>
> On 27-02-17 23:53, Takashi Iwai wrote:
> > On Mon, 27 Feb 2017 22:27:58 +0100,
> > Rafael J. Wysocki wrote:
> >>
> >> On Mon, Feb 27, 2017 at 3:40 PM, Takashi Iwai wrote:
>
>
ress:
> > [31908.558005] 8801f7788200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > fb fb
> > [31908.558127] ffff8801f7788280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > fb fb
> > [31908.558255] >8801f7788300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb
&
On Tue, 11 Apr 2017 23:27:07 +0200,
Chris Wilson wrote:
>
> On Tue, Apr 11, 2017 at 10:20:56PM +0100, Chris Wilson wrote:
> > On Tue, Apr 11, 2017 at 11:01:57PM +0200, Takashi Iwai wrote:
> > > On Tue, 11 Apr 2017 22:41:12 +0200,
> > > Chris Wilson wrote:
> >
> > fb fb
> > [31908.558374] ^
> > [31908.558467] 8801f7788380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > fb fb
> > [31908.558595] 8801f7788400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > fb fb
&g
fb
> fb fb
> [31908.558374] ^
> [31908.558467] 8801f7788380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> fb fb
> [31908.558595] 8801f7788400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> fb fb
>
> v2: Just leak
I/DP,pcm=2 Jack'
> ; type=BOOLEAN,access=r---,values=1
> : values=on
>
> The ELD controls do show a null set of values for device 1, maybe the
> jack value should be set in accordance with the ELD validity?
> Also I am wondering if the display number could be used for the
On Wed, 26 Apr 2017 09:04:46 +0200,
Takashi Iwai wrote:
>
> On Wed, 26 Apr 2017 03:58:57 +0200,
> Pierre-Louis Bossart wrote:
> >
> > On 04/25/2017 03:27 PM, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > Now that ev
On Tue, 25 Apr 2017 22:27:19 +0200,
ville.syrj...@linux.intel.com wrote:
>
> From: Ville Syrjälä
>
> I was wondering why my VLV no longer runtime suspended, and after some
> thinking I decided it had to be the LPE audio preventing it. Turns out
> I was right, so here's my attempt at fixing it.
>
On Wed, 26 Apr 2017 15:38:53 +0200,
Ville Syrjälä wrote:
>
> On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote:
> > On Tue, 25 Apr 2017 22:27:19 +0200,
> > ville.syrj...@linux.intel.com wrote:
> > >
> > > From: Ville Syrjälä
> > >
>
On Wed, 26 Apr 2017 15:49:06 +0200,
Ville Syrjälä wrote:
>
> On Wed, Apr 26, 2017 at 09:19:21AM +0200, Takashi Iwai wrote:
> > On Wed, 26 Apr 2017 09:04:46 +0200,
> > Takashi Iwai wrote:
> > >
> > > On Wed, 26 Apr 2017 03:58:57 +0200,
> > > Pierre-L
ot being much benefit from
> LPE audio runtime PM. Not allowing runtime PM blocks i915 runtime
> PM, which will also block s0ix, and that could have a measurable
> impact on power consumption.
>
> Cc: Takashi Iwai
> Cc: Pierre-Louis Bossart
> Fixes: 0b6b524f3915 (&qu
.
>
> Cc: Takashi Iwai
> Cc: Pierre-Louis Bossart
> Signed-off-by: Ville Syrjälä
Reviewed-by: Takashi Iwai
This deserves also Cc to stable, IMO.
thanks,
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.fr
, since
historically many drivers have already mixed them up. So it's no
problem :)
> Entire series available here:
> git://github.com/vsyrjala/linux.git lpe_audio_multipipe_2
>
> Cc: Takashi Iwai
> Cc: Pierre-Louis Bossart
All look good, and feel free to take my re
t; On Fri, Apr 28, 2017 at 12:10:31PM -0500, Pierre-Louis Bossart wrote:
> >>>>
> >>>> On 04/28/2017 03:41 AM, Takashi Iwai wrote:
> >>>>> On Thu, 27 Apr 2017 18:02:19 +0200,
> >>>>> ville.syrj...@linux.intel.com wrote:
&
1 - 100 of 615 matches
Mail list logo
