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
> d
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
> > > contai
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 b
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 Thu, Mar 16, 2023 at 03:31:22PM +0100, Karol Herbst wrote:
> Users kept complaining about those messages and it's a little spammy on
> prime systems so turn it into a debug print.
>
> Cc: Bjorn Helgaas
> Cc: Lukas Wunner
> Cc: linux-...@vger.kernel.org
> Cc: nou
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 having
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 +-
> drivers/gpu/drm/radeon/ra
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 doe
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 co
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 Thun
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 attribu
On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:
> Can I ask someone with more
> technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm about
> the possible challenges of nouveau taking matters into its own hand rather
> than keeping this PCI quirk around?
It sounds to me
On Mon, Jul 27, 2020 at 03:53:54PM -0500, Daniel Dadap wrote:
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
Nit: Alphabetic ordering.
> +static u64 *get_dod_entries(acpi_handle handle, int *count)
> +{
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 old
//bbs.archlinux.org/viewtopic.php?pid=1865512
Link: https://bugs.freedesktop.org/show_bug.cgi?id=75985#c81
Reported-by: Przemysław Kopa
Reported-by: Rivera Valdez
Signed-off-by: Lukas Wunner
Cc: Daniel Drake
Cc: sta...@vger.kernel.org # v5.3+
---
sound/pci/hda/patch_hdmi.c | 2 ++
1 file changed
On Wed, Jul 31, 2019 at 04:19:27PM -0400, Lyude Paul wrote:
> While this fixes audio for a number of users, this commit has the
> sideaffect of breaking the BIOS workaround that's required to make the
> GPU on the nvidia P50 work, by causing the GPU's PCI device function to
> stop working after it'
Cc: Peter Wu
> > Cc: Ilia Mirkin
> > Cc: Karol Herbst
> > Cc: Maik Freudenberg
> > Signed-off-by: Lukas Wunner
> > Tested-by: Daniel Drake
Daniel, if you submit a v2 to address Ilia's comments, please be sure
to add your Signed-off-by. Th
On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote:
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -934,6 +934,7 @@ struct pci_dev *pci_scan_single_device(struct pci_bus
> *bus, int devfn);
> void pci_device_add(struct pci_dev *dev, struct pci_bus *bus);
> unsigned int pc
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
situation
because rpm_suspend() 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: Luka
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:
> --- a/drivers/gpu/
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
> > > a go
e 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.ke
drm_modeset_backoff+0x8a/0x1b0 [drm]
> [ 246.770839] 1 lock held by dmesg/1038:
> [ 246.771739] 2 locks held by zsh/1172:
> [ 246.772650] #0: 836d0438 (&tty->ldisc_sem){}, at:
> ldsem_down_read+0x37/0x40
> [ 246.773680] #1: 1f4f4d48 (&ldata-&g
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 i
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
> > runtim
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, the PC
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()
> > > ad
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);
>
> drm_fo
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 &atom->state;
> }
>
> +static void
> +nouveau_
[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
> pm_runtime_get/put()
urn code! (ret most
> likely will == 0 here, we want -ENOMEM).
>
> Signed-off-by: Lyude Paul
Reviewed-by: Lukas Wunner
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
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
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, Feb 19, 2018 at 10:38:04AM +0100, Pierre Moreau wrote:
> My bad; I did test suspend/resume, but not unbinding. Shouldn???t that
> happen on shutdown as well, as the driver gets unloaded? I don???t remember
> seeing that issue there though.
Sorry Pierre, I missed this question and am seeing
On Mon, Feb 19, 2018 at 10:38:04AM +0100, Pierre Moreau wrote:
> On 2018-02-17 13:40, Lukas Wunner wrote:
> > Unbinding nouveau on a dual GPU MacBook Pro oopses because we iterate
> > over the bl_connectors list in nouveau_backlight_exit() but skipped
> > initializing it in n
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, Pete
the GPU is runtime
resumed while the HDA controller is probed, rendering this safety
measure obsolete. Remove it.
Cc: Dave Airlie
Cc: Ben Skeggs
Cc: Takashi Iwai
Cc: Peter Wu
Cc: Alex Deucher
Cc: Rafael J. Wysocki
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_
nd or autoresume as it sees fit.
Cc: Dave Airlie
Cc: Ben Skeggs
Cc: Takashi Iwai
Cc: Peter Wu
Cc: Alex Deucher
Signed-off-by: Lukas Wunner
---
drivers/gpu/vga/vga_switcheroo.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gp
Cc: Dave Airlie
Cc: Ben Skeggs
Cc: Peter Wu
Cc: Alex Deucher
Cc: Rafael J. Wysocki
Acked-by: Bjorn Helgaas
Reviewed-by: Takashi Iwai
Tested-by: Mike Lothian
Signed-off-by: Lukas Wunner
---
Changes since v1:
- Drop an unnecessary initialization. (Bjorn)
Rephrase error message on fai
Peter Wu
Cc: Alex Deucher
Cc: Rafael J. Wysocki
Tested-by: Mike Lothian
Signed-off-by: Lukas Wunner
---
drivers/gpu/vga/vga_switcheroo.c | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers
.
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
Acked-by: Bjorn Helgaas
Signed-off-by: Lukas Wunner
---
drivers/pci/pci.c | 8
include/linux/pci.h | 2 ++
2 files changed, 6 inserti
Cc: Takashi Iwai
Cc: Peter Wu
Cc: Alex Deucher
Cc: Bjorn Helgaas
Cc: Rafael J. Wysocki
Tested-by: Mike Lothian
Signed-off-by: Lukas Wunner
---
drivers/gpu/vga/vga_switcheroo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/v
shed code comments for clarity]
Signed-off-by: Lukas Wunner
---
Changes since v1:
- Replace patch to use pci_save_state() / pci_restore_state()
for consistency between runtime PM code path of bound and unbound
devices. (Rafael, Bjorn)
drivers/pci/pci-driver.c | 17 +++--
1 fil
d to perform
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_s
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
> > pci_restore
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
On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> workqueue: Allow retrieval of current task's work struct
> drm: Allow determining if current task is output poll worker
> drm/nouveau: Fix deadlock on runtime suspend
> drm/radeon: Fix deadlock on runtim
On Mon, Feb 19, 2018 at 03:05:53PM +0100, Daniel Vetter wrote:
> On Mon, Feb 19, 2018 at 12:58:17PM +0100, Lukas Wunner wrote:
> > On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote:
> > > Well, userspace expects hotplug events, even when we runtime suspend
> &g
On Mon, Feb 19, 2018 at 12:48:04PM +0100, Daniel Vetter wrote:
> On Thu, Feb 15, 2018 at 06:38:44AM +0100, Lukas Wunner wrote:
> > On Wed, Feb 14, 2018 at 09:58:43AM -0500, Sean Paul wrote:
> > > On Wed, Feb 14, 2018 at 03:43:56PM +0100, Michel Dänzer wrote:
> > > >
On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote:
> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> >
> > DRM drivers poll connectors in 10 sec intervals. The pol
the GPU is runtime
resumed while the HDA controller is probed, rendering this safety
measure obsolete. Remove it.
Cc: Dave Airlie
Cc: Ben Skeggs
Cc: Takashi Iwai
Cc: Peter Wu
Cc: Alex Deucher
Cc: Rafael J. Wysocki
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_
nd or autoresume as it sees fit.
Cc: Dave Airlie
Cc: Ben Skeggs
Cc: Takashi Iwai
Cc: Peter Wu
Cc: Alex Deucher
Signed-off-by: Lukas Wunner
---
drivers/gpu/vga/vga_switcheroo.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gp
rst
Cc: Dave Airlie
Cc: Ben Skeggs
Cc: Takashi Iwai
Cc: Peter Wu
Cc: Alex Deucher
Cc: Bjorn Helgaas
Cc: Rafael J. Wysocki
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 -
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 -
drivers/gpu/drm/
Peter Wu
Cc: Alex Deucher
Cc: Rafael J. Wysocki
Signed-off-by: Lukas Wunner
---
drivers/gpu/vga/vga_switcheroo.c | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
i
Cc: Takashi Iwai
Cc: Peter Wu
Cc: Alex Deucher
Cc: Bjorn Helgaas
Cc: Rafael J. Wysocki
Signed-off-by: Lukas Wunner
---
drivers/gpu/vga/vga_switcheroo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 3cd153c6d271
ze,
let's not inflate the code unnecessarily.
Cc: Bjorn Helgaas
Cc: Rafael J. Wysocki
Signed-off-by: Lukas Wunner
---
drivers/pci/pci-driver.c | 8 ++--
drivers/pci/pci.c| 2 +-
drivers/pci/pci.h| 1 +
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers
.
To this end make pci_wakeup_bus() & pci_bus_set_current_state() public
so PCI drivers don't have to reinvent the wheel.
Cc: Bjorn Helgaas
Cc: Rafael J. Wysocki
Signed-off-by: Lukas Wunner
---
drivers/pci/pci.c | 8
include/linux/pci.h | 2 ++
2 files changed, 6 inserti
00:01:00.0/power/control
Wait for GPU to power off, then rebind it:
echo :01:00.0 > /sys/bus/pci/drivers/{nouveau,amdgpu,radeon}/bind
Check dmesg for errors. If you see any then we may need to perform
further actions in pci_pm_runtime_resume(), see patch [1/7].
Thanks,
Lukas
Luk
o not register interface if Apple GMUX
detected")
Cc: sta...@vger.kernel.org # v4.10+
Cc: Pierre Moreau
Signed-off-by: Lukas Wunner
---
I reviewed the patch causing the oops but unfortunately missed this, sorry!
drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 ++--
1 file changed, 2 insert
On Wed, Feb 14, 2018 at 09:58:43AM -0500, Sean Paul wrote:
> On Wed, Feb 14, 2018 at 03:43:56PM +0100, Michel Dänzer wrote:
> > On 2018-02-14 03:08 PM, Sean Paul wrote:
> > > On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
> > >> Op 14-02-18
On Tue, Feb 13, 2018 at 03:46:08PM +, Liviu Dudau wrote:
> On Tue, Feb 13, 2018 at 12:52:06PM +0100, Lukas Wunner wrote:
> > On Tue, Feb 13, 2018 at 10:55:06AM +, Liviu Dudau wrote:
> > > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > > >
Dear drm-misc maintainers,
On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
This series has been reviewed, consent has been expressed by the most
interested parties, patch [1/5] which touches files
On Mon, Feb 12, 2018 at 12:46:11PM -0500, Lyude Paul wrote:
> On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> > Introduce a helper to determine if the current task is an output poll
> > worker.
> >
> > This allows us to fix a long-standing deadlock in several
oll worker and autosuspend worker as use case. (Lyude)
Cc: Dave Airlie
Cc: Ben Skeggs
Cc: Alex Deucher
Reviewed-by: Lyude Paul
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/drm_probe_helper.c | 20
include/drm/drm_crtc_helper.h | 1 +
2 files changed, 21 insertions(
On Tue, Feb 13, 2018 at 10:55:06AM +, Liviu Dudau wrote:
> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > DRM drivers poll connectors in 10 sec intervals. The poll worker is
> > stopped on ->runtime_suspend with cancel_delayed_work_sync(). However
&
On Mon, Feb 12, 2018 at 01:58:32PM -0500, Alex Deucher wrote:
> On Mon, Feb 12, 2018 at 4:45 AM, Lukas Wunner wrote:
> > On Mon, Feb 12, 2018 at 09:03:26AM +, Mike Lothian wrote:
> >> On 12 February 2018 at 03:39, Lukas Wunner wrote:
> >> > On Mon, Feb 12,
On Mon, Feb 12, 2018 at 05:50:12PM +, Chris Wilson wrote:
> Quoting Lyude Paul (2018-02-12 17:46:11)
> > On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> > > Introduce a helper to determine if the current task is an output poll
> > > worker.
> > >
On Mon, Feb 12, 2018 at 09:03:26AM +, Mike Lothian wrote:
> On 12 February 2018 at 03:39, Lukas Wunner wrote:
> > On Mon, Feb 12, 2018 at 12:35:51AM +, Mike Lothian wrote:
> > > I've not been able to reproduce the original problem you're trying to
> &g
On Mon, Feb 12, 2018 at 12:35:51AM +, Mike Lothian wrote:
> I've not been able to reproduce the original problem you're trying to
> solve on amdgpu thats with or without your patch set and the above
> "trigger" too
>
> Is anything else required to trigger it, I started multiple DRI_PRIME
> glx
On Sun, Feb 11, 2018 at 08:23:14PM +0100, Lukas Wunner wrote:
> On Sun, Feb 11, 2018 at 06:58:11PM +, Mike Lothian wrote:
> > On 11 February 2018 at 09:38, Lukas Wunner wrote:
> > > The patches for radeon and amdgpu are compile-tested only, I only have a
> > > MacBo
On Sun, Feb 11, 2018 at 06:58:11PM +, Mike Lothian wrote:
> On 11 February 2018 at 09:38, Lukas Wunner wrote:
> > The patches for radeon and amdgpu are compile-tested only, I only have a
> > MacBook Pro with an Nvidia GK107 to test. To test the patches, add an
> > &quo
Signed-off-by: Lukas Wunner
---
include/linux/workqueue.h | 1 +
kernel/workqueue.c| 16
2 files changed, 17 insertions(+)
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 4a54ef96aff5..bc0cda180c8b 100644
--- a/include/linux/workqueue.h
+++ b/
ts
for runtime suspend to finish. The ->detect callback is invoked from
multiple call sites and waiting for runtime suspend to finish is the
correct thing to do except if it's executing in the context of the
worker.
Cc: Dave Airlie
Cc: Ben Skeggs
Cc: Alex Deucher
Signed-off-by
allbacks, which seems
questionable. msm however does and would also deadlock if it disabled
the poll worker on runtime suspend. cc += Archit, Liviu, intel-gfx)
Please review. Thanks,
Lukas
Lukas Wunner (5):
workqueue: Allow retrieval of current task's work struct
drm: Allow determi
...@vger.kernel.org # v3.13+: 1234567890ab: workqueue: Allow retrieval
of current task's work struct
Cc: sta...@vger.kernel.org # v3.13+: 1234567890ab: drm: Allow determining if
current task is output poll worker
Cc: Ismo Toijala
Cc: Alex Deucher
Cc: Dave Airlie
Signed-off-by: Lukas Wunner
drm/amdgpu: add core driver (v4)")
Cc: sta...@vger.kernel.org # v4.2+: 1234567890ab: workqueue: Allow retrieval of
current task's work struct
Cc: sta...@vger.kernel.org # v4.2+: 1234567890ab: drm: Allow determining if
current task is output poll worker
Cc: Alex Deucher
Signed-off-by
ut poll worker
Cc: Ben Skeggs
Cc: Dave Airlie
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_conne
On Thu, Mar 09, 2017 at 04:03:47PM +0100, Daniel Vetter wrote:
> On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote:
> > Fix Thunderbolt-related issues in apple-gmux and vga_switcheroo:
> >
> > Patch [1/5] ("Recognize Thunderbolt devices") has already been
On Fri, Feb 24, 2017 at 04:17:24PM -0600, Bjorn Helgaas wrote:
> On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote:
> > Detect on probe whether a PCI device is part of a Thunderbolt controller.
[...]
> > * If an external Thunderbolt GPU is connected to a dual GPU lapto
On Fri, Feb 24, 2017 at 02:59:44PM -0600, Bjorn Helgaas wrote:
> On Fri, Feb 24, 2017 at 1:19 PM, Lukas Wunner wrote:
> > An external Thunderbolt GPU can neither drive the laptop's panel nor be
> > powered off by the platform, so there's no point in registering i
On Fri, Feb 24, 2017 at 04:17:24PM -0600, Bjorn Helgaas wrote:
> On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote:
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -358,6 +358,7 @@ struct pci_dev {
> > unsigned intis_virtfn:1;
>
n
a lockup.
Cc: Ben Skeggs
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_vga.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index eef22c6b9665..c2a7fd606c2e 100644
---
t register external GPUs with vga_switcheroo, which
necessitates a way to recognize if they're on a Thunderbolt daisy
chain.
Cc: Andreas Noever
Cc: Michael Jamet
Cc: Tomas Winkler
Cc: Amir Levy
Signed-off-by: Lukas Wunner
---
drivers/pci/pci.h | 2 ++
drivers/p
t included in
the 4.11 PCI pull for some reason:
http://www.spinics.net/lists/linux-pci/msg58123.html
I've pushed the present series to GitHub in case anyone prefers reviewing
it in a GUI:
https://github.com/l1k/linux/commits/thunderbolt_gpu_v1
Thanks,
Lukas
Lukas Wunner (5):
PCI: Reco
On Fri, Jan 27, 2017 at 04:06:38PM +0100, Peter Wu wrote:
> Also note that many laptops with these card suffer from a problem
> that cause lockups when runpm kicks in.
> See https://bugzilla.kernel.org/show_bug.cgi?id=156341
Peter, I notice you weren't cc'ed on the last few messages of the
'PCI: R
Hi Ben,
On Wed, Dec 14, 2016 at 08:00:16PM +0100, Lukas Wunner wrote:
> On Tue, Nov 08, 2016 at 09:29:38PM +0100, Peter Wu wrote:
> > On Tue, Nov 08, 2016 at 12:57:00PM +0100, Lukas Wunner wrote:
> > > nouveau's ->suspend and ->resume callbacks are currently skipped
Hi Ben,
On Tue, Nov 08, 2016 at 09:29:38PM +0100, Peter Wu wrote:
> On Tue, Nov 08, 2016 at 12:57:00PM +0100, Lukas Wunner wrote:
> > nouveau's ->suspend and ->resume callbacks are currently skipped if the
> > device's status is either DRM_SWITCH_POWER_OFF (po
as pointed out by Lukas Wunner
>
> v3: Add a missing end-of-line character to the printed message
>
> Signed-off-by: Pierre Moreau
Reviewed-by: Lukas Wunner
Thanks,
Lukas
> ---
> drm/nouveau/nouveau_backlight.c | 6 ++
> 1 file changed, 6 inserti
On Tue, Nov 29, 2016 at 05:42:51PM -0500, Evan Foss wrote:
> On Sun, Nov 27, 2016 at 4:13 AM, Lukas Wunner wrote:
> > On Sat, Nov 26, 2016 at 06:09:34AM +, Evan Foss wrote:
> >> I did some other bug reports here a while back. I am back again
> >> because I updat
On Sat, Nov 26, 2016 at 06:09:34AM +, Evan Foss wrote:
> I did some other bug reports here a while back. I am back again
> because I updated my kernel from 3.19.1 to linux-4.8.10-gentoo (if you
> want I can test the mainline too). On boot all my GPU's turn on. If I
> turn them off via
> echo "O
s it prevents from grepping
> it, as pointed out by Lukas Wunner
>
> Signed-off-by: Pierre Moreau
Reviewed-by: Lukas Wunner
Thanks,
Lukas
> ---
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/no
On Sun, Nov 13, 2016 at 08:57:06PM +0100, Pierre Moreau wrote:
> From: Pierre Moreau
>
> Currently, every backlight interface created by Nouveau uses the same name,
> nv_backlight. This leads to a sysfs warning as it tries to create an already
> existing folder. This patch adds a incremented numb
On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote:
> The underlying problem is that we already have a number of other
> symbols that either have "depends on LEDS_CLASS" or
> "select LEDS_CLASS". To clean that up properly, we should either
> make the symbol itself hidden and only select
e process (search for "direct_complete" in
drivers/base/power/main.c).
Consequently the DRM_SWITCH_POWER_DYNAMIC_OFF checks are superfluous.
Drop them.
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
di
On Thu, Oct 20, 2016 at 10:08:28AM +0200, Lukas Wunner wrote:
> On Wed, Oct 19, 2016 at 07:58:06PM +0200, Pierre Moreau wrote:
> > For example, my laptop (which also has an NVAC) has been triggering the
> > no-signal message on external monitors way before Ben???s patch landed,
&
1 - 100 of 155 matches
Mail list logo
