On Mon, Nov 06, 2023 at 12:44:25PM -0600, Mario Limonciello wrote:
> Tangentially related; the link speed is currently symmetric but there are
> two sysfs files. Mika left a comment in drivers/thunderbolt/switch.c it may
> be asymmetric in the future. So we may need to keep that in mind on any
>
On Mon, Nov 06, 2023 at 10:59:13AM -0600, Mario Limonciello wrote:
> On 11/5/2023 11:39, Lukas Wunner wrote:
> > On Fri, Nov 03, 2023 at 02:07:55PM -0500, Mario Limonciello wrote:
> > > The `is_thunderbolt` bit has been used to indicate that a PCIe device
> > > con
On Fri, Nov 03, 2023 at 02:07:57PM -0500, Mario Limonciello wrote:
> The USB4 spec specifies that PCIe ports that are used for tunneling
> PCIe traffic over USB4 fabric will be hardcoded to advertise 2.5GT/s and
> behave as a PCIe Gen1 device. The actual performance of these ports is
> controlled
On Fri, Nov 03, 2023 at 02:07:55PM -0500, Mario Limonciello wrote:
> The `is_thunderbolt` bit has been used to indicate that a PCIe device
> contained the Intel VSEC which is used by various parts of the kernel
> to change behavior. To later allow usage with USB4 controllers as well,
> rename this
On Fri, Feb 03, 2023 at 05:09:09PM -0600, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> This reverts commit 145eed48de278007f646b908fd70ac59d24ed81a.
>
> Zeno Davatz reported that 145eed48de27 ("fbdev: Remove conflicting devices
> on PCI bus") caused a console hang. The machine was actually
On Thu, Jan 12, 2023 at 09:11:56PM +0100, Thomas Zimmermann wrote:
> Several lastclose helpers call vga_switcheroo_process_delayed_switch().
> It's better to call the helper from drm_lastclose() after the kernel
> client's screen has been restored. This way, all drivers can benefit
> without
On Tue, Aug 16, 2022 at 11:06:18AM +0300, Jani Nikula wrote:
> On Tue, 16 Aug 2022, Kai-Heng Feng wrote:
> > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > dGFX so external monitors are routed to dGFX, and more monitors can be
> > supported as result.
> >
> > To
On Mon, Feb 28, 2022 at 04:13:44PM -0600, Bjorn Helgaas wrote:
> On Mon, Feb 28, 2022 at 03:33:13PM +, Limonciello, Mario wrote:
> > > On Fri, Feb 25, 2022 at 11:42:24AM -0600, Bjorn Helgaas wrote:
> > > > That would just leave the "PCI_VSEC_ID_INTEL_TBT implies external-
> > > facing"
> > > >
On Mon, Feb 14, 2022 at 06:01:50PM -0600, Mario Limonciello wrote:
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_vga.c | 4 +-
> drivers/gpu/drm/radeon/radeon_device.c | 4 +-
>
On Mon, Feb 14, 2022 at 09:34:26AM +0200, Mika Westerberg wrote:
> On Fri, Feb 11, 2022 at 03:45:46PM -0600, Bjorn Helgaas wrote:
> > My expectation is that "USB" (like "PCI" and "PCIe") tells me
> > something about how a device is electrically connected and how
> > software can operate it. It
On Sun, Feb 13, 2022 at 10:19:20AM +0100, Lukas Wunner wrote:
> Apple had been using its own scheme to put Thunderbolt controllers
> into D3cold when nothing is plugged in, about a decade before Microsoft
> defined the ACPI property.
I meant to say "half a decade", sorry.
On Fri, Feb 11, 2022 at 01:32:41PM -0600, Mario Limonciello wrote:
> `pci_bridge_d3_possible` currently checks explicitly for a Thunderbolt
> controller to indicate that D3 is possible. As this is used solely
> for older Apple systems, move it into a quirk that enumerates across
> all Intel TBT
On Fri, Feb 11, 2022 at 12:23:51PM +0200, Mika Westerberg wrote:
> On Thu, Feb 10, 2022 at 04:43:23PM -0600, Mario Limonciello wrote:
> > @@ -2955,7 +2955,7 @@ bool pci_bridge_d3_possible(struct pci_dev *bridge)
> > return true;
> >
> > /* Even the oldest 2010
On Fri, Feb 11, 2022 at 01:32:42PM -0600, Mario Limonciello wrote:
> The `is_thunderbolt` attribute is currently a dumping ground for a
> variety of things.
It's not as arbitrary as it may seem. Quite a bit of thought went into
the current design.
> Instead use the driver core removable
g like:
Retry creation of the vga_switcheroo debugfs if a previous
invocation of debugfs_create_dir() returned an error code.
With that addressed,
Reviewed-by: Lukas Wunner
Thanks,
Lukas
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/vga/vga_switcheroo.c | 2 +-
> 1 file ch
On Mon, Oct 11, 2021 at 10:24:29PM +0200, Lukas Wunner wrote:
> On Mon, Oct 11, 2021 at 09:06:07PM +0200, Nirmoy Das wrote:
> > Debugfs APIs returns encoded error on failure so use
> > debugfs_lookup() instead of checking for NULL.
> [...]
> > --- a/drivers/gpu/vga/vg
On Mon, Oct 11, 2021 at 09:06:07PM +0200, Nirmoy Das wrote:
> Debugfs APIs returns encoded error on failure so use
> debugfs_lookup() instead of checking for NULL.
[...]
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -914,7 +914,7 @@ static void
On Sat, May 29, 2021 at 10:16:38AM -0400, Alyssa Rosenzweig wrote:
> Like many free software projects, freedesktop.org issued a non-binding
> recommendation for projects to migrate from OFTC to Freenode [1]. As
> such, freedesktop.org entries in the MAINTAINERS file are out-of-date as
> the
On Sat, May 29, 2021 at 10:16:38AM -0400, Alyssa Rosenzweig wrote:
> Like many free software projects, freedesktop.org issued a non-binding
> recommendation for projects to migrate from OFTC to Freenode [1]. As
^
On Wed, Sep 30, 2020 at 06:03:03AM +0200, Roland Scheidegger (VMware) wrote:
> Sigend-off-by: Roland Scheidegger
^^^
typo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Aug 10, 2020 at 01:44:58PM -0500, Daniel Dadap wrote:
> On 8/10/20 3:37 AM, Lukas Wunner wrote:
> > On Wed, Jul 29, 2020 at 04:05:57PM -0500, Daniel Dadap wrote:
> > > + * Call MXDS with bit 0 set to change the current state.
> > > + * When changing state, clear
On Wed, Jul 29, 2020 at 04:05:57PM -0500, Daniel Dadap wrote:
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This
On Fri, Jul 17, 2020 at 03:04:10PM -0400, Lyude Paul wrote:
> Isn't it possible to tell whether a PCI device is connected through
> thunderbolt or not? We could probably get away with just defaulting
> to 100ms for thunderbolt devices without DLL Link Active specified,
> and then default to the
On Mon, May 11, 2020 at 02:21:57PM +0200, Daniel Vetter wrote:
> On Mon, May 11, 2020 at 1:43 PM Lukas Wunner wrote:
> > On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
> > > - One unfortunate thing with drm_dev_unplug is that the driver core is
> > > v
On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
> - One unfortunate thing with drm_dev_unplug is that the driver core is
> very opinionated and doesn't tell you whether it's a hotunplug or a
> driver unload. In the former case trying to shut down hw just wastes
> time (and
On Thu, Apr 02, 2020 at 12:56:04PM -0500, Daniel Dadap wrote:
> I'll check one of the eDP-based systems I've been experimenting on to see if
> setting the VGA_SWITCHER_NEEDS_EDP_CONFIG capability in the handler is
> sufficient to make i915 avoid poking the AUX channel when it's mux-switched
>
On Thu, Apr 02, 2020 at 03:13:26PM +0200, Daniel Vetter wrote:
> On Thu, Apr 2, 2020 at 2:58 PM Pekka Paalanen wrote:
> > On Thu, 2 Apr 2020 13:39:25 +0200 Lukas Wunner wrote:
> > > Note that vga_switcheroo is currently controlled via debugfs.
> > > That is a histori
On Thu, Apr 02, 2020 at 01:39:25PM +0200, Lukas Wunner wrote:
> First of all, there's DPCD byte 3 bit 6 (NO_AUX_HANDSHAKE_LINK_TRAINING)
> which is documented as follows:
>
> Does not require AUX CH handshake when the link configuration is
> already known. [...] The k
On Fri, Mar 27, 2020 at 04:25:19PM -0500, Daniel Dadap wrote:
> A number of hybrid GPU notebook computer designs with dual (integrated plus
> discrete) GPUs are equipped with multiplexers (muxes) that allow display
> panels to be driven by either the integrated GPU or the discrete GPU.
>
void fbcon_remap_all(int idx)
That comment needs to be removed as well.
Not an expert on fbcon code but this looks sane to me, so in case it helps:
Acked-by: Lukas Wunner
Thanks,
Lukas
ual driver, rather than something that is inflicted
on *all* drivers (midlayer fallacy).
Of course the performance is suboptimal compared to an approach
which transmits the sglist in portions which are < 65535 each,
but we can move to that later.
In cas
On Fri, Apr 12, 2019 at 12:09:34PM +0100, Mark Brown wrote:
> On Fri, Apr 12, 2019 at 12:54:48PM +0200, Lukas Wunner wrote:
> > On Fri, Apr 12, 2019 at 10:47:21AM +0100, Mark Brown wrote:
> > > I *think* we managed to fix all the architectures to at least stub out
> > &g
On Fri, Apr 12, 2019 at 10:47:21AM +0100, Mark Brown wrote:
> On Thu, Apr 11, 2019 at 11:02:26PM +0200, Noralf Trønnes wrote:
> > Den 11.04.2019 20.18, skrev Lukas Wunner:
> > > On Thu, Apr 11, 2019 at 06:42:33PM +0200, Noralf Trønnes wrote:
> > > > @@ -
On Thu, Apr 11, 2019 at 11:02:26PM +0200, Noralf Trønnes wrote:
> Den 11.04.2019 20.18, skrev Lukas Wunner:
> > On Thu, Apr 11, 2019 at 06:42:33PM +0200, Noralf Trønnes wrote:
> >> @@ -1299,6 +1299,11 @@ static void __spi_pump_messages(struct
> >> spi_contro
On Thu, Apr 11, 2019 at 06:42:33PM +0200, Noralf Trønnes wrote:
> @@ -1299,6 +1299,11 @@ static void __spi_pump_messages(struct spi_controller
> *ctlr, bool in_kthread)
>
> trace_spi_message_start(ctlr->cur_msg);
>
> + ret = spi_split_transfers_maxsize(ctlr, ctlr->cur_msg,
>
On Wed, Jan 23, 2019 at 11:21:25PM -0800, Life is hard, and then you die wrote:
> Since the two changes (the change here + the new driver) seem to be
> best submitted through different trees, I'm trying to figure out how
> best to handle this. I suppose I could temporarily change the driver
>
gt; According to the docs, select should only be used for non-visible
> symbols. Furthermore almost all other references to INPUT throughout the
> kernel config are depends, not selects. Hence this change.
>
> CC: Inki Dae
> CC: Andrzej Hajda
> Signed-off-by: Ronald Tschal
On Sun, Dec 23, 2018 at 02:00:15AM +0300, Sinan Kaya wrote:
> On Sat, Dec 22, 2018 at 7:40 PM Lukas Wunner wrote:
> > On Sat, Dec 22, 2018 at 09:07:12AM +, Sinan Kaya wrote:
> > > This driver depends on the PCI infrastructure but the dependency has not
> > >
On Sat, Dec 22, 2018 at 09:07:12AM +, Sinan Kaya wrote:
> This driver depends on the PCI infrastructure but the dependency has not
> been explicitly called out.
>
> Signed-off-by: Sinan Kaya
> Reviewed-by: Lukas Wunner
This series doesn't have a cover letter so it's unclea
On Sat, Dec 22, 2018 at 12:14:44AM +, Sinan Kaya wrote:
> This driver depends on the PCI infrastructure but the dependency has not
> been explicitly called out.
>
> Signed-off-by: Sinan Kaya
Reviewed-by: Lukas Wunner
> ---
> drivers/gpu/vga/Kconfig | 1 +
> 1 file
On Tue, Nov 27, 2018 at 11:39:40PM -0800, Christoph Hellwig wrote:
> > + /*
> > +* dma_sync_sg_*() flush the physical pages, so point
> > +* sg->dma_address to the physical ones for the right behavior.
> > +*/
> > +
On Mon, Nov 05, 2018 at 02:11:06PM +0100, Takashi Iwai wrote:
> On Mon, 05 Nov 2018 13:59:37 +0100, Lukas Wunner wrote:
> > On Mon, Nov 05, 2018 at 01:51:23PM +0100, Takashi Iwai wrote:
> > > On Mon, 05 Nov 2018 12:55:17 +0100, Lukas Wunner wrote:
> > > > On Mon, No
On Mon, Nov 05, 2018 at 01:51:23PM +0100, Takashi Iwai wrote:
> On Mon, 05 Nov 2018 12:55:17 +0100, Lukas Wunner wrote:
> > On Mon, Nov 05, 2018 at 12:02:53PM +0100, Takashi Iwai wrote:
> > > diff --git a/drivers/gpu/vga/vga_switcheroo.c
> > > b/drivers/gpu/vga/v
_info() is called twice for blacklisted
devices in set_default_power_save(). This could be eliminated by
amending the if-condition with "&& vgasr_priv.active". Since this
is only minor, up to you if you want to respin.
Either way,
Reviewed-by: Lukas Wunner
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
idea underlying
the patch and it LGTM. It's somewhat regrettable that we have to
make things more complicated again to properly differentiate between
integrated and discrete GPUs. I wish we could later on come up with
a scheme that is lightweight and easy to follow. Obviously,
On Mon, Aug 06, 2018 at 03:15:31PM -0400, Lyude Paul wrote:
> You did mention in the review of one of my other patches that we should avoid
> disabling polling during runtime suspend, and you're definitely right. I feel
> a bit silly for not remembering that since I was the one who made it so that
spend() doesn't look at the last_busy variable after the
call to rpm_callback(). What's necessary here is that runtime_suspend is
aborted and -EBUSY returned.
Thanks,
Lukas
>
> Signed-off-by: Lyude Paul
> Cc: sta...@vger.kernel.org
> Cc: Lukas Wunner
> Cc: Karol Herbst
&g
On Wed, Aug 01, 2018 at 05:14:52PM -0400, Lyude Paul wrote:
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -592,10 +592,11 @@ nouveau_drm_load(struct drm_device *dev, unsigned long
> flags)
> pm_runtime_allow(dev->dev);
>
Hi Lyude,
thanks a lot for your persistence in attacking these runtime PM
issues in nouveau. v4 of this series looks very good overall.
I only have comments on patches 1, 2 and 8. On this patch 1
it's merely a nit:
On Wed, Aug 01, 2018 at 05:14:51PM -0400, Lyude Paul wrote:
> ---
On Thu, Jul 19, 2018 at 08:08:15PM -0400, Lyude Paul wrote:
> On Thu, 2018-07-19 at 09:49 +0200, Lukas Wunner wrote:
> > On Wed, Jul 18, 2018 at 04:56:39PM -0400, Lyude Paul wrote:
> > > When DP MST hubs get confused, they can occasionally stop responding for
> > >
the duration of the connector probe.
Hm, a runtime PM ref is already acquired in nouveau_connector_detect().
I'm wondering why that's not sufficient?
Thanks,
Lukas
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Karol Herbst
> Cc: Lukas Wunner
> Cc: sta...@vger.kernel.org
> -
9] 2 locks held by zsh/1172:
> [ 246.772650] #0: 836d0438 (>ldisc_sem){}, at:
> ldsem_down_read+0x37/0x40
> [ 246.773680] #1: 1f4f4d48 (>atomic_read_lock){+.+.}, at:
> n_tty_read+0xc1/0x870
>
> [ 246.775522] ==
On Wed, Jul 18, 2018 at 10:25:05AM +0200, Lukas Wunner wrote:
> The GPU contains an i2c subdevice for each connector with DDC lines.
> I believe those are modelled as children of the GPU's PCI device as
> they're accessed via mmio of the PCI device.
>
> The problem here is that whe
On Wed, Jul 18, 2018 at 09:38:41AM +0200, Rafael J. Wysocki wrote:
> On Tue, Jul 17, 2018 at 8:20 PM, Lukas Wunner wrote:
> > Okay, the PCI device is suspending and the nvkm_i2c_aux_acquire()
> > wants it in resumed state, so is waiting forever for the device to
> > run
On Tue, Jul 17, 2018 at 02:34:47PM -0400, Lyude Paul wrote:
> On Tue, 2018-07-17 at 20:32 +0200, Lukas Wunner wrote:
> > On Tue, Jul 17, 2018 at 02:24:31PM -0400, Lyude Paul wrote:
> > > On Tue, 2018-07-17 at 20:20 +0200, Lukas Wunner wrote:
> > > > Okay
On Tue, Jul 17, 2018 at 02:24:31PM -0400, Lyude Paul wrote:
> On Tue, 2018-07-17 at 20:20 +0200, Lukas Wunner wrote:
> > Okay, the PCI device is suspending and the nvkm_i2c_aux_acquire()
> > wants it in resumed state, so is waiting forever for the device to
> > runtime suspe
On Tue, Jul 17, 2018 at 12:53:11PM -0400, Lyude Paul wrote:
> On Tue, 2018-07-17 at 09:16 +0200, Lukas Wunner wrote:
> > On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote:
> > > In order to fix all of the spots that need to have runtime PM get/puts()
> > &g
switcheroo.
>
> if the audio client is not the third registration, audio
> id will set in vga_switcheroo enable function. if the
> audio client is the last registration when vga_switcheroo
> _ready() get true, we should get audio client id from bound
> GPU directly.
>
> Signe
On Thu, Jul 12, 2018 at 01:02:53PM -0400, Lyude Paul wrote:
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1878,7 +1878,7 @@ nv50_disp_atomic_commit(struct drm_device *dev,
> nv50_disp_atomic_commit_tail(state);
>
>
On Mon, Jul 16, 2018 at 07:59:26PM -0400, Lyude Paul wrote:
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -2012,10 +2012,18 @@ nv50_disp_atomic_state_alloc(struct drm_device *dev)
> return >state;
> }
>
> +static void
>
[cc += linux-pm]
Hi Lyude,
First of all, thanks a lot for looking into this.
On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote:
> In order to fix all of the spots that need to have runtime PM get/puts()
> added, we need to ensure that it's possible for us to call
>
On Mon, Jul 16, 2018 at 02:06:35PM +0800, Jim Qu wrote:
> +
> + list_for_each_entry(client, _priv.clients, list) {
> + if (!client_is_audio(client) || client_id(client) !=
> + VGA_SWITCHEROO_UNKNOWN_ID)
Don't you have to check for
client_id(client) !=
On Mon, Jul 16, 2018 at 04:47:11PM +0200, Takashi Iwai wrote:
> On Mon, 16 Jul 2018 16:43:42 +0200,
> Lukas Wunner wrote:
> >
> > On Mon, Jul 16, 2018 at 02:06:35PM +0800, Jim Qu wrote:
> > > +
> > > + list_for_each_entry(client, _priv.clients, list) {
> &g
On Mon, Jul 16, 2018 at 03:52:45PM +0800, Hui Wang wrote:
> On 2018???07???16??? 14:06, Jim Qu wrote:
> >On modern laptop, there are more and more platforms
> >have two GPUs, and each of them maybe have audio codec
> >for HDMP/DP output. For some dGPU which is no output,
> >audio codec usually is
On Sat, Jul 14, 2018 at 02:15:24PM +0800, jimqu wrote:
> ??? 2018/7/13 17:27, Lukas Wunner ??:
> >On Fri, Jul 13, 2018 at 04:06:02PM +0800, Jim Qu wrote:
> >>On modern laptop, there are more and more platforms
> >>have two GPUs, and each of them maybe have audio c
On Fri, Jul 13, 2018 at 04:06:02PM +0800, Jim Qu wrote:
> On modern laptop, there are more and more platforms
> have two GPUs, and each of them maybe have audio codec
> for HDMP/DP output. For some dGPU which is no output,
> audio codec usually is disabled.
>
> In currect HDA audio driver, it
On Fri, Jul 13, 2018 at 04:06:01PM +0800, Jim Qu wrote:
> Signed-off-by: Jim Qu
Empty commit message. Please add an explanation why the change is
necessary so folks browsing the git history understand it's motivation.
I think here the motivation is that the PCI class is sometimes
On Mon, Jul 09, 2018 at 05:52:49PM +0200, Takashi Iwai wrote:
> On Mon, 09 Jul 2018 17:47:34 +0200, Lukas Wunner wrote:
> > Since v4.17, every time the GPU is powered up, the HDA controller is
> > runtime resumed to PCI_D0. (See the call to pci_wakeup_bus() in
> > vga_swit
On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> On Mon, 09 Jul 2018 15:58:51 +0200, Alex Deucher wrote:
> > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim wrote:
> > > > You're saying above that the HDA controller isn't runtime resumed on
> > > > hotplug of a display. Is that necessary
On Mon, Jul 09, 2018 at 08:52:33AM +, Qu, Jim wrote:
> Now, I found the audio device will auto suspend even if the gpu is active,
> and if I plug in a HDMI device it also do not resume back.
>
> 1. Did you encounter similar issue before?
> 2. audio will auto suspend as default at beginning
(ret most
> likely will == 0 here, we want -ENOMEM).
>
> Signed-off-by: Lyude Paul
Reviewed-by: Lukas Wunner
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Jun 29, 2018 at 10:40:50AM +, Qu, Jim wrote:
> > That is no longer the case since v4.17. The HDA controller now runtime
> > suspends autonomously, see commit 07f4f97d7b4b ("vga_switcheroo: Use
> > device link for HDA controller").
> >
> > Your patch appears to be geared towards an
On Fri, Jun 29, 2018 at 08:55:40AM +, Qu, Jim wrote:
> When our dGPU does suspend by runtime pm. amdgpu driver for dgpu will
> also call vgaswtichroo to power off its audio. vgaswitchroo driver will
> find audio codec by vgaswitchroo dgpu client id(VGA_SWITCHEROO_DIS).
That is no longer the
> On Thu, Jun 28, 2018 at 2:22 AM, Jim Qu wrote:
> > On modern laptop, there are more and more platforms
> > have two GPUs, and each of them maybe have audio codec
> > for HDMP/DP output. For some dGPU which is no output,
> > audio codec usually is disabled.
> >
> > In currect HDA audio driver,
[cc += dri-devel, cc -= alsa-devel]
On Wed, Jun 20, 2018 at 10:28:37PM +, p...@cooco.de wrote:
> On Wed, 20 Jun 2018 12:14:32 +0200, Takashi Iwai wrote:
> > I guess it would work with a quirk. The EPSS and CLKSTOP checks are
> > just to assure the modern codec PM, and GPU is always
We've gained a few
> committers in the past who are coming from arm-soc platform work and
> similar areas, to upstream drm drivers for their platform.
FWIW,
Acked-by: Lukas Wunner <lu...@wunner.de>
___
dri-devel mailing list
dri-dev
On Thu, Mar 29, 2018 at 01:46:26PM +0200, Lukas Wunner wrote:
> sound/pci/hda/hda_intel.c:1024:12: warning: 'azx_resume' defined but not used
> [-Wunused-function]
> static int azx_resume(struct device *dev)
> ^~
> sound/pci/hda/hda_intel.c:989:12: warnin
On Thu, Mar 29, 2018 at 01:51:43PM +0200, Takashi Iwai wrote:
> On Thu, 29 Mar 2018 13:46:26 +0200, Lukas Wunner wrote:
> > The system sleep PM ops azx_suspend() and azx_resume() were previously
> > called by vga_switcheroo, but commit 07f4f97d7b4b ("vga_switcheroo: Use
>
condition as the one immediately succeeding it, the two blocks can
be collapsed together, shaving off another two lines.
Fixes: 07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
Cc: Takashi Iwai <ti...@suse.com>
Reported-by: Arnd Bergmann <a...@arndb.de>
Signed-off-b
Dear Stephen,
when rebuilding linux-next you're going to see a merge conflict in:
sound/pci/hda/hda_intel.c
betwen commit:
1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist")
from the sound tree and commit:
07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
from
On Sun, Mar 11, 2018 at 04:55:49PM +0100, Lukas Wunner wrote:
> > On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote:
> > > Modernize vga_switcheroo by using a device link to enforce a runtime PM
> > > dependency from an HDA controller to the GPU
On Mon, Mar 12, 2018 at 05:54:47PM +0100, Daniel Vetter wrote:
> On Sun, Mar 11, 2018 at 04:55:49PM +0100, Lukas Wunner wrote:
> > > On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote:
> > > > Modernize vga_switcheroo by using a device link to enforce a runtime PM
On Tue, Mar 06, 2018 at 11:29:40AM +0100, Daniel Vetter wrote:
> On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote:
> > Modernize vga_switcheroo by using a device link to enforce a runtime PM
> > dependency from an HDA controller to the GPU it's integrated into, v2.
Hi Peter,
thanks a million for the extensive testing and reviewing.
I'll go through the issues you've found below, but it appears to me
that they're all either in the "works as intended" category or are
caused by something unrelated to this series:
On Mon, Mar 05, 2018 at 09:58:31PM +0100,
or autoresume as it sees fit.
Cc: Dave Airlie <airl...@redhat.com>
Cc: Ben Skeggs <bske...@redhat.com>
Cc: Takashi Iwai <ti...@suse.de>
Cc: Peter Wu <pe...@lekensteyn.nl>
Cc: Alex Deucher <alexander.deuc...@amd.com>
Signed-off-by: Lukas Wunner <lu...@wunner.de>
---
her <alexander.deuc...@amd.com>
Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Signed-off-by: Lukas Wunner <lu...@wunner.de>
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 44 ---
drivers/gpu/drm/nouveau/nouveau_drv.h | 1 -
2 files changed, 4
om>
Cc: Takashi Iwai <ti...@suse.de>
Cc: Peter Wu <pe...@lekensteyn.nl>
Cc: Alex Deucher <alexander.deuc...@amd.com>
Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Tested-by: Mike Lothian <m...@fireburn.co.uk>
Signed-off-by: Lukas Wunner <lu...@wu
@redhat.com>
Cc: Ben Skeggs <bske...@redhat.com>
Cc: Peter Wu <pe...@lekensteyn.nl>
Cc: Alex Deucher <alexander.deuc...@amd.com>
Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Bjorn Helgaas <bhelg...@google.com>
Reviewed-by: Takashi Iwai <ti...
.
To this end make pci_wakeup_bus() & pci_bus_set_current_state() public
so PCI drivers don't have to reinvent the wheel.
Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Bjorn Helgaas <bhelg...@google.com>
Signed-off-by: Lukas Wunner <lu...@wunner.de>
---
drivers/pci/pci.c
: Ben Skeggs <bske...@redhat.com>
Cc: Takashi Iwai <ti...@suse.de>
Cc: Peter Wu <pe...@lekensteyn.nl>
Cc: Alex Deucher <alexander.deuc...@amd.com>
Cc: Bjorn Helgaas <bhelg...@google.com>
Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Tested-by: Mike Lothian <m
Wysocki <rafael.j.wyso...@intel.com>
[lukas: add commit message, bikeshed code comments for clarity]
Signed-off-by: Lukas Wunner <lu...@wunner.de>
---
Changes since v1:
- Replace patch to use pci_save_state() / pci_restore_state()
for consistency between runtime PM code path of bound and
further actions in pci_pm_runtime_resume(), see patch [1/7].
Thanks,
Lukas
Lukas Wunner (6):
PCI: Make pci_wakeup_bus() & pci_bus_set_current_state() public
vga_switcheroo: Update PCI current_state on power change
vga_switcheroo: Deduplicate power state tracking
vga_switcheroo: Use
On Wed, Feb 28, 2018 at 01:09:28PM +0200, Jyri Sarha wrote:
> The device_link_del() is still there in drm_panel_detach(), despite
> Lukas Wunner's comment[1]. In the usual (currently all) cases things
> would work perfectly without the call too, because
> device_links_driver_cleanup() will
On Wed, Feb 28, 2018 at 01:09:30PM +0200, Jyri Sarha wrote:
> Add device_link from panel device (supplier) to drm device (consumer)
> with DL_FLAG_AUTOREMOVE when drm_panel_attach() is called. Currently
> the master drm driver is not protected against the attached. The
> device_link with
On Sat, Feb 24, 2018 at 06:16:46PM +, Meghana Madhyastha wrote:
> -Remove chunk splitting in tinydrm_spi_transfer in tinydrm-helpers as The spi
> core will split a buffer into max_dma_len chunks for the
> spi controller driver to handle.
> -Remove automatic byte swapping in
On Sat, Feb 24, 2018 at 06:17:12PM +, Meghana Madhyastha wrote:
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1003,7 +1003,7 @@ static int spi_map_msg(struct spi_controller *ctlr,
> struct spi_message *msg)
> * drivers which implement a transfer_one() operation. It provides
>
[cc += linux-rpi-ker...@lists.infradead.org]
On Sat, Feb 24, 2018 at 06:15:59PM +, Meghana Madhyastha wrote:
> I've added bcm2835_spi_transfer_one_message in spi-bcm2835. This calls
> spi_split_transfers_maxsize to split large chunks for spi dma transfers.
> I then removed chunk splitting in
s
>
> If this patch is not acceptable as such, how about adding this
> behavior behind a new device link flag?
>
> The idea to this patch was gotten from this post by Lucas Wunner:
> https://www.spinics.net/lists/dri-devel/msg166318.html
>
> Part of the code and the description is
On Wed, Feb 21, 2018 at 01:39:34PM +0100, Rafael J. Wysocki wrote:
> On Wednesday, February 21, 2018 10:57:14 AM CET Rafael J. Wysocki wrote:
> > So if pci_pm_runtime_suspend() is modified to call pci_save_state()
> > before returning 0 in the !dev->driver case, we can just move the
> >
On Tue, Feb 20, 2018 at 04:20:59PM -0600, Bjorn Helgaas wrote:
> On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote:
> > The device link is added in a PCI quirk rather than in hda_intel.c.
> > It is therefore legal for the GPU to runtime suspend to D3cold even if
> &g
1 - 100 of 434 matches
Mail list logo
