[PATCH v2] drm/nouveau: Move irq setup/teardown to pci ctor/dtor

, this probably means we can also just remove the msi rearm call inside nvkm_pci_init(). But since our main focus here is to fix suspend/resume before 4.15, we'll save that for a later patch. Signed-off-by: Lyude Paul Cc: Karol Herbst Cc: Thomas Gleixner Cc: Mike Galbraith Cc: sta

[PATCH] drm/nouveau: Move irq setup/teardown to pci ctor/dtor

, this probably means we can also just remove the msi rearm call inside nvkm_pci_init(). But since our main focus here is to fix suspend/resume before 4.16, we'll save that for a later patch. Signed-off-by: Lyude Paul <ly...@redhat.com> Cc: Karol Herbst <kher...@redhat.com> Cc: Thomas

[PATCH] drm/nouveau: Move irq setup/teardown to pci ctor/dtor

, this probably means we can also just remove the msi rearm call inside nvkm_pci_init(). But since our main focus here is to fix suspend/resume before 4.16, we'll save that for a later patch. Signed-off-by: Lyude Paul Cc: Karol Herbst Cc: Thomas Gleixner Cc: Mike Galbraith Cc: sta

Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

On Thu, 2018-01-25 at 19:46 +0100, Thomas Gleixner wrote: > On Thu, 25 Jan 2018, Lyude Paul wrote: > > > I think you are right, apologies. Glad to know this isn't a regression in > > the > > IRQ handling code :). It looks like our nouveau problems are probably coming &

Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

On Thu, 2018-01-25 at 19:46 +0100, Thomas Gleixner wrote: > On Thu, 25 Jan 2018, Lyude Paul wrote: > > > I think you are right, apologies. Glad to know this isn't a regression in > > the > > IRQ handling code :). It looks like our nouveau problems are probably coming &

Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

Will cc you with some patches in a bit, think I have this problem figured out :) On Thu, 2018-01-25 at 04:29 +0100, Mike Galbraith wrote: > On Wed, 2018-01-24 at 15:02 -0500, Lyude Paul wrote: > > Almost forgot to mention: I came across this patch because reverting it > > locally

Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

Will cc you with some patches in a bit, think I have this problem figured out :) On Thu, 2018-01-25 at 04:29 +0100, Mike Galbraith wrote: > On Wed, 2018-01-24 at 15:02 -0500, Lyude Paul wrote: > > Almost forgot to mention: I came across this patch because reverting it > > locally

Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

. Going to get some patches onto the mailing list for this, thanks for the help! On Thu, 2018-01-25 at 09:54 +0100, Thomas Gleixner wrote: > On Wed, 24 Jan 2018, Lyude Paul wrote: > > Sorry about that! Let me clarify a little bit: this is a problem that shows > > up > > on mainl

Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

. Going to get some patches onto the mailing list for this, thanks for the help! On Thu, 2018-01-25 at 09:54 +0100, Thomas Gleixner wrote: > On Wed, 24 Jan 2018, Lyude Paul wrote: > > Sorry about that! Let me clarify a little bit: this is a problem that shows > > up > > on mainl

Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

On Wed, 2018-01-24 at 14:56 -0500, Lyude Paul wrote: > On Wed, 2018-01-24 at 19:13 +, Ghannam, Yazen wrote: > > > -Original Message- > > > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > > > ow...@vger.kernel.org] On Behalf Of Lyude Paul

Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

On Wed, 2018-01-24 at 14:56 -0500, Lyude Paul wrote: > On Wed, 2018-01-24 at 19:13 +, Ghannam, Yazen wrote: > > > -Original Message- > > > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > > > ow...@vger.kernel.org] On Behalf Of Lyude Paul

Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

On Wed, 2018-01-24 at 19:13 +, Ghannam, Yazen wrote: > > -Original Message- > > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > > ow...@vger.kernel.org] On Behalf Of Lyude Paul > > Sent: Wednesday, January 24, 2018 12:49 PM > > To: Thoma

Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

On Wed, 2018-01-24 at 19:13 +, Ghannam, Yazen wrote: > > -Original Message- > > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > > ow...@vger.kernel.org] On Behalf Of Lyude Paul > > Sent: Wednesday, January 24, 2018 12:49 PM > >

Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

; when nouveau does initialize properly after resume (e.g. after reverting this patch) I see it get assigned a seperate vector from the other devices. On Wed, 2018-01-24 at 13:52 +0100, Thomas Gleixner wrote: > On Tue, 23 Jan 2018, Lyude Paul wrote: > > > JFYI: I confirmed this patch i

Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

; when nouveau does initialize properly after resume (e.g. after reverting this patch) I see it get assigned a seperate vector from the other devices. On Wed, 2018-01-24 at 13:52 +0100, Thomas Gleixner wrote: > On Tue, 23 Jan 2018, Lyude Paul wrote: > > > JFYI: I confirmed this patch i

Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

JFYI: I confirmed this patch is definitely broken. I'm seeing nouveau get assigned the same MSI vector as another device on the system, which would explain why interrupts suddenly stop working. I'll keep looking into it further tomorrow. On Tue, 2018-01-23 at 17:01 -0500, Lyude Paul wrote: >

Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

JFYI: I confirmed this patch is definitely broken. I'm seeing nouveau get assigned the same MSI vector as another device on the system, which would explain why interrupts suddenly stop working. I'll keep looking into it further tomorrow. On Tue, 2018-01-23 at 17:01 -0500, Lyude Paul wrote: >

"irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

Hi! Sorry to be the bearer of bad news, but this patch actually seems to break suspending and resuming with nouveau on my machine: [ 29.694755] PM: suspend entry (deep) [ 29.694773] PM: Syncing filesystems ... done. [ 29.696203] Freezing user space processes ... (elapsed 0.001 seconds)

"irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel

Hi! Sorry to be the bearer of bad news, but this patch actually seems to break suspending and resuming with nouveau on my machine: [ 29.694755] PM: suspend entry (deep) [ 29.694773] PM: Syncing filesystems ... done. [ 29.696203] Freezing user space processes ... (elapsed 0.001 seconds)

Re: [01/12] watchdog: sp5100_tco: Always use SP5100_IO_PM_{INDEX_REG, DATA_REG}

Oh has this patchset already been reviwed and pushed upstream? I checked patchwork beforehand and it looked like it was still pending On Tue, 2018-01-16 at 12:11 -0800, Guenter Roeck wrote: > On Tue, Jan 16, 2018 at 02:34:19PM -0500, Lyude Paul wrote: > > Sorry this review took so long!

Re: [01/12] watchdog: sp5100_tco: Always use SP5100_IO_PM_{INDEX_REG, DATA_REG}

Oh has this patchset already been reviwed and pushed upstream? I checked patchwork beforehand and it looked like it was still pending On Tue, 2018-01-16 at 12:11 -0800, Guenter Roeck wrote: > On Tue, Jan 16, 2018 at 02:34:19PM -0500, Lyude Paul wrote: > > Sorry this review took so long!

Re: [08/12] watchdog: sp5100_tco: Clean up function and variable names

Reviewed-by: Lyude Paul <ly...@redhat.com> On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > Use more common function and variable names. > > Use pdev instead of dev for platform device. > Use sp5100_tco_probe() instead of sp5100_tco_init() for the prob

Re: [08/12] watchdog: sp5100_tco: Clean up function and variable names

Reviewed-by: Lyude Paul On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > Use more common function and variable names. > > Use pdev instead of dev for platform device. > Use sp5100_tco_probe() instead of sp5100_tco_init() for the probe function. > Drop sp5100_tco_clean

Re: [07/12] watchdog: sp5100_tco: Use dev_ print functions where possible

Reviewed-by: Lyude Paul <ly...@redhat.com> On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > Use dev_ instead of pr_ functions where possible. > > Cc: Zoltán Böszörményi <zbos...@pr.hu> > Signed-off-by: Guenter Roeck <li...@roeck-us.net> > --- >

Re: [07/12] watchdog: sp5100_tco: Use dev_ print functions where possible

Reviewed-by: Lyude Paul On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > Use dev_ instead of pr_ functions where possible. > > Cc: Zoltán Böszörményi > Signed-off-by: Guenter Roeck > --- > drivers/watchdog/sp5100_tco.c | 40 +---

Re: [06/12] watchdog: sp5100_tco: Match PCI device early

Reviewed-by: Lyude Paul <ly...@redhat.com> On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > Match PCI device in module init function, not in the probe function. > It is pointless trying to probe if we can determine early that the device > is not supported. > > C

Re: [06/12] watchdog: sp5100_tco: Match PCI device early

Reviewed-by: Lyude Paul On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > Match PCI device in module init function, not in the probe function. > It is pointless trying to probe if we can determine early that the device > is not supported. > > Cc: Zoltán Böszörmény

Re: [05/12] watchdog: sp5100_tco: Clean up sp5100_tco_setupdevice

Thank you for this cleanup, the gotos that were in this code are really confusing to read through! I'd recommend one very small change described below. Assuming you add that in the next version: Reviewed-by: Lyude Paul <ly...@redhat.com> On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck

Re: [05/12] watchdog: sp5100_tco: Clean up sp5100_tco_setupdevice

Thank you for this cleanup, the gotos that were in this code are really confusing to read through! I'd recommend one very small change described below. Assuming you add that in the next version: Reviewed-by: Lyude Paul On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > There are too m

Re: [04/12] watchdog: sp5100_tco: Use standard error codes

On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > By using standard error codes, we can identify and return more than one > error condition. > > Cc: Zoltán Böszörményi <zbos...@pr.hu> > Signed-off-by: Guenter Roeck <li...@roeck-us.net> Reviewed-by: L

Re: [04/12] watchdog: sp5100_tco: Use standard error codes

On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > By using standard error codes, we can identify and return more than one > error condition. > > Cc: Zoltán Böszörményi > Signed-off-by: Guenter Roeck Reviewed-by: Lyude Paul > --- > drivers/watch

Re: [03/12] watchdog: sp5100_tco: Use request_muxed_region where possible

; return ret; > } > > @@ -535,7 +535,6 @@ static void sp5100_tco_cleanup(void) > misc_deregister(_tco_miscdev); > iounmap(tcobase); > release_mem_region(tcobase_phys, SP5100_WDT_MEM_MAP_SIZE); > - release_region(SP5100_IO_PM_INDEX_REG, SP5100_PM_IOPORTS_SIZE); > } > > static int sp5100_tco_remove(struct platform_device *dev) -- Cheers, Lyude Paul

Re: [03/12] watchdog: sp5100_tco: Use request_muxed_region where possible

> } > > @@ -535,7 +535,6 @@ static void sp5100_tco_cleanup(void) > misc_deregister(_tco_miscdev); > iounmap(tcobase); > release_mem_region(tcobase_phys, SP5100_WDT_MEM_MAP_SIZE); > - release_region(SP5100_IO_PM_INDEX_REG, SP5100_PM_IOPORTS_SIZE); > } > > static int sp5100_tco_remove(struct platform_device *dev) -- Cheers, Lyude Paul

Re: [02/12] watchdog: sp5100_tco: Fix watchdog disable bit

t; to enable watchdog address decoding, which is the default setting, but it > still needs to be fixed. Reviewed-by: Lyude Paul <ly...@redhat.com> > > Cc: Zoltán Böszörményi <zbos...@pr.hu> > Signed-off-by: Guenter Roeck <li...@roeck-us.net> > --- > drivers/w

Re: [01/12] watchdog: sp5100_tco: Always use SP5100_IO_PM_{INDEX_REG, DATA_REG}

0xCD6 > #define SP5100_IO_PM_DATA_REG 0xCD7 > > +/* For SP5100/SB7x0 chipset */ > #define SP5100_SB_RESOURCE_MMIO_BASE 0x9C > > #define SP5100_PM_WATCHDOG_CONTROL 0x69 > @@ -44,11 +45,7 @@ > > #define SP5100_DEVNAME "SP5100 TCO" > > - > /* For SB8x0(or later) chipset */ > -#define SB800_IO_PM_INDEX_REG0xCD6 > -#define SB800_IO_PM_DATA_REG 0xCD7 > - IMO I would leave these macro definitions as SB800. For DRM drivers at least, we usually take the route of naming commonly used registers/methods after the first generation they appeared in, not the last. > #define SB800_PM_ACPI_MMIO_EN0x24 > #define SB800_PM_WATCHDOG_CONTROL0x48 > #define SB800_PM_WATCHDOG_BASE 0x48 -- Cheers, Lyude Paul

Re: [02/12] watchdog: sp5100_tco: Fix watchdog disable bit

t; to enable watchdog address decoding, which is the default setting, but it > still needs to be fixed. Reviewed-by: Lyude Paul > > Cc: Zoltán Böszörményi > Signed-off-by: Guenter Roeck > --- > drivers/watchdog/sp5100_tco.h | 2 +- > 1 file changed, 1 insertion(+), 1 dele

Re: [01/12] watchdog: sp5100_tco: Always use SP5100_IO_PM_{INDEX_REG, DATA_REG}

0xCD7 > > +/* For SP5100/SB7x0 chipset */ > #define SP5100_SB_RESOURCE_MMIO_BASE 0x9C > > #define SP5100_PM_WATCHDOG_CONTROL 0x69 > @@ -44,11 +45,7 @@ > > #define SP5100_DEVNAME "SP5100 TCO" > > - > /* For SB8x0(or later) chipset */ > -#define SB800_IO_PM_INDEX_REG0xCD6 > -#define SB800_IO_PM_DATA_REG 0xCD7 > - IMO I would leave these macro definitions as SB800. For DRM drivers at least, we usually take the route of naming commonly used registers/methods after the first generation they appeared in, not the last. > #define SB800_PM_ACPI_MMIO_EN0x24 > #define SB800_PM_WATCHDOG_CONTROL0x48 > #define SB800_PM_WATCHDOG_BASE 0x48 -- Cheers, Lyude Paul

Re: [Nouveau] [RFC 0/4] Implement full clockgating for Kepler1 and 2

mi patch set available somewhere for me to test? > > Thank you > Regards Brock > > > > On 16 Jan. 2018 9:08 am, "Lyude Paul" <ly...@redhat.com> wrote: > > It's here! After a lot of investigation, rewrites, and traces, I present > > the patch series

Re: [Nouveau] [RFC 0/4] Implement full clockgating for Kepler1 and 2

mi patch set available somewhere for me to test? > > Thank you > Regards Brock > > > > On 16 Jan. 2018 9:08 am, "Lyude Paul" wrote: > > It's here! After a lot of investigation, rewrites, and traces, I present > > the patch series to implement all known

[RFC 2/4] drm/nouveau: Add support for BLCG clockgating for Kepler1

since BLCG is mostly the same there as far as we can tell. In the future, it's likely we'll reformat the clkgate_packs for kepler1 so that they share a list of mmio packs with Fermi. Signed-off-by: Lyude Paul <ly...@redhat.com> --- .../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 14 ++ d

[RFC 2/4] drm/nouveau: Add support for BLCG clockgating for Kepler1

since BLCG is mostly the same there as far as we can tell. In the future, it's likely we'll reformat the clkgate_packs for kepler1 so that they share a list of mmio packs with Fermi. Signed-off-by: Lyude Paul --- .../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 14 ++ drivers/gpu/drm/nouveau

[RFC 4/4] drm/nouveau: Add SLCG clockgating for Kepler2

be noted that SLCG was added starting with kepler2, previous generations have no SLCG. SLCG can be enabled with the nouveau config option, NvPmEnableGating=3 Signed-off-by: Lyude Paul <ly...@redhat.com> --- .../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 1 + drivers/gpu/drm/nouvea

[RFC 4/4] drm/nouveau: Add SLCG clockgating for Kepler2

be noted that SLCG was added starting with kepler2, previous generations have no SLCG. SLCG can be enabled with the nouveau config option, NvPmEnableGating=3 Signed-off-by: Lyude Paul --- .../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 1 + drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c

[RFC 3/4] drm/nouveau: Add BLCG clockgating for Kepler2

This is mostly the same as Kepler1, but we save even more power! Signed-off-by: Lyude Paul <ly...@redhat.com> --- drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 + drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +-- drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c

[RFC 3/4] drm/nouveau: Add BLCG clockgating for Kepler2

This is mostly the same as Kepler1, but we save even more power! Signed-off-by: Lyude Paul --- drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 + drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +-- drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c| 68

[RFC 1/4] drm/nouveau: Add support for basic clockgating on Kepler1

Signed-off-by: Lyude Paul <ly...@redhat.com> --- .../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 10 ++ drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 17 +-- drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 72

[RFC 1/4] drm/nouveau: Add support for basic clockgating on Kepler1

Signed-off-by: Lyude Paul --- .../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 10 ++ drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 17 +-- drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 72 +-- drivers/gpu/drm/no

[RFC 0/4] Implement full clockgating for Kepler1 and 2

patchset and let us know how well it works for you! Lyude Paul (4): drm/nouveau: Add support for basic clockgating on Kepler1 drm/nouveau: Add support for BLCG clockgating for Kepler1 drm/nouveau: Add BLCG clockgating for Kepler2 drm/nouveau: Add SLCG clockgating for Kepler2 drivers/gpu

[RFC 0/4] Implement full clockgating for Kepler1 and 2

patchset and let us know how well it works for you! Lyude Paul (4): drm/nouveau: Add support for basic clockgating on Kepler1 drm/nouveau: Add support for BLCG clockgating for Kepler1 drm/nouveau: Add BLCG clockgating for Kepler2 drm/nouveau: Add SLCG clockgating for Kepler2 drivers/gpu

Re: [11/12] watchdog: sp5100-tco: Abort if watchdog is disabled by hardware

Oh fantastic! this works awesome, thank you ♥ On Tue, 2018-01-09 at 16:11 -0800, Guenter Roeck wrote: > On Tue, Jan 09, 2018 at 07:04:25PM -0500, Lyude Paul wrote: > > How exactly did you go about enabling the Super-IO watchdog on your MSI > > board? > > This is an MSI

Re: [11/12] watchdog: sp5100-tco: Abort if watchdog is disabled by hardware

Oh fantastic! this works awesome, thank you ♥ On Tue, 2018-01-09 at 16:11 -0800, Guenter Roeck wrote: > On Tue, Jan 09, 2018 at 07:04:25PM -0500, Lyude Paul wrote: > > How exactly did you go about enabling the Super-IO watchdog on your MSI > > board? > > This is an MSI

Re: [11/12] watchdog: sp5100-tco: Abort if watchdog is disabled by hardware

How exactly did you go about enabling the Super-IO watchdog on your MSI board? This is an MSI A320M that I'm trying to make work here On Tue, 2018-01-09 at 15:37 -0800, Guenter Roeck wrote: > Hi, > > On Tue, Jan 09, 2018 at 05:58:07PM -0500, Lyude Paul wrote: > > Hi! I'm the one

Re: [11/12] watchdog: sp5100-tco: Abort if watchdog is disabled by hardware

How exactly did you go about enabling the Super-IO watchdog on your MSI board? This is an MSI A320M that I'm trying to make work here On Tue, 2018-01-09 at 15:37 -0800, Guenter Roeck wrote: > Hi, > > On Tue, Jan 09, 2018 at 05:58:07PM -0500, Lyude Paul wrote: > > Hi! I'm the one

Re: [11/12] watchdog: sp5100-tco: Abort if watchdog is disabled by hardware

Hi! I'm the one from the Fedora bugzilla who said they'd help review these patches. I might end up responding to this with a real review comment after this message, but first: mind cc'ing me future versions of this patchset and also, is there any way you know of that one could figure out whether

Re: [11/12] watchdog: sp5100-tco: Abort if watchdog is disabled by hardware

Hi! I'm the one from the Fedora bugzilla who said they'd help review these patches. I might end up responding to this with a real review comment after this message, but first: mind cc'ing me future versions of this patchset and also, is there any way you know of that one could figure out whether

[PATCH v3] igb: Free IRQs when device is hotplugged

netdev, we always allow __igb_close() to be called so that IRQs may be freed normally. Additionally, only allow igb_close() to be called from __igb_close() if it hasn't already been called for the given adapter. Signed-off-by: Lyude Paul <ly...@redhat.com> Fixes: 9474933caf21 ("igb: c

[PATCH v3] igb: Free IRQs when device is hotplugged

netdev, we always allow __igb_close() to be called so that IRQs may be freed normally. Additionally, only allow igb_close() to be called from __igb_close() if it hasn't already been called for the given adapter. Signed-off-by: Lyude Paul Fixes: 9474933caf21 ("igb: close/suspend race in netif_de

[PATCH v2] igb: Free IRQs when device is hotplugged

netdev, we always allow __igb_close() to be called so that IRQs may be freed normally. Additionally, only allow igb_close() to be called from __igb_close() if it hasn't already been called for the given adapter. Signed-off-by: Lyude Paul <ly...@redhat.com> Fixes: 9474933caf21 ("igb: c

[PATCH v2] igb: Free IRQs when device is hotplugged

netdev, we always allow __igb_close() to be called so that IRQs may be freed normally. Additionally, only allow igb_close() to be called from __igb_close() if it hasn't already been called for the given adapter. Signed-off-by: Lyude Paul Fixes: 9474933caf21 ("igb: close/suspend race in netif_de

Re: [PATCH] igb: Free IRQs when device is hotplugged

On Mon, 2017-12-11 at 16:34 -0800, Stephen Hemminger wrote: > On Mon, 11 Dec 2017 18:45:02 -0500 > Lyude Paul <ly...@redhat.com> wrote: > > > Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon > > hotplugging my kernel would i

Re: [PATCH] igb: Free IRQs when device is hotplugged

On Mon, 2017-12-11 at 16:34 -0800, Stephen Hemminger wrote: > On Mon, 11 Dec 2017 18:45:02 -0500 > Lyude Paul wrote: > > > Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon > > hotplugging my kernel would immediately crash due to igb: > > &g

[PATCH] igb: Free IRQs when device is hotplugged

hether the PCI device is stale and if so, free it's IRQs and tx/rx resources. Signed-off-by: Lyude Paul <ly...@redhat.com> Fixes: 9474933caf21 ("igb: close/suspend race in netif_device_detach") Cc: Todd Fujinaka <todd.fujin...@intel.com> Cc: sta...@vger.kernel.org --- drivers/net/e

[PATCH] igb: Free IRQs when device is hotplugged

hether the PCI device is stale and if so, free it's IRQs and tx/rx resources. Signed-off-by: Lyude Paul Fixes: 9474933caf21 ("igb: close/suspend race in netif_device_detach") Cc: Todd Fujinaka Cc: sta...@vger.kernel.org --- drivers/net/ethernet/intel/igb/igb_main.c | 10 ++ 1

[PATCH 2/4] dma-buf: make reservation_object_copy_fences rcu save

amd.com> Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1504551766-5093-1-git-send-email-deathsim...@vodafone.de Signed-off-by: Lyude Paul <ly...@redhat.com> --- drivers/dma-buf/reservation.c | 56 +

[PATCH 3/4] drm/amdgpu: reserve root PD while releasing it

d-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Alex Deucher <alexander.deuc...@amd.com> Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> Signed-off-by: Lyude Paul <ly...@redhat.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 13 +++-- 1 file ch

[PATCH 2/4] dma-buf: make reservation_object_copy_fences rcu save

/1504551766-5093-1-git-send-email-deathsim...@vodafone.de Signed-off-by: Lyude Paul --- drivers/dma-buf/reservation.c | 56 --- 1 file changed, 42 insertions(+), 14 deletions(-) diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c

[PATCH 3/4] drm/amdgpu: reserve root PD while releasing it

-by: Alex Deucher Signed-off-by: Lyude Paul --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c index bd20ff018512..591c6dc2c1f7 100644 --- a/drivers

[PATCH 1/4] drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more

eserve it. commit 378e2d5b504fe0231c557751e58b80fcf717cc20 upstream Signed-off-by: Christian König <christian.koe...@amd.com> Acked-by: Chunming Zhou <david1.z...@amd.com> Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> Signed-off-by: Lyude Paul <ly...@redhat.com> ---

[PATCH 1/4] drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more

378e2d5b504fe0231c557751e58b80fcf717cc20 upstream Signed-off-by: Christian König Acked-by: Chunming Zhou Signed-off-by: Alex Deucher Signed-off-by: Lyude Paul --- drivers/gpu/drm/ttm/ttm_bo.c | 32 +--- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm

[PATCH 0/4] Backported amdgpu ttm deadlock fixes for 4.14

I haven't gone to see where it started, but as of late a good number of pretty nasty deadlock issues have appeared with the kernel. Easy reproduction recipe on a laptop with i915/amdgpu prime with lockdep enabled: DRI_PRIME=1 glxinfo Additionally, some more race conditions exist that I've

[PATCH 0/4] Backported amdgpu ttm deadlock fixes for 4.14

I haven't gone to see where it started, but as of late a good number of pretty nasty deadlock issues have appeared with the kernel. Easy reproduction recipe on a laptop with i915/amdgpu prime with lockdep enabled: DRI_PRIME=1 glxinfo Additionally, some more race conditions exist that I've

[PATCH 4/4] drm/ttm: Always and only destroy bo->ttm_resv in ttm_bo_release_list

tian König <christian.koe...@amd.com> Signed-off-by: Michel Dänzer <michel.daen...@amd.com> Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> Signed-off-by: Lyude Paul <ly...@redhat.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 11 --- 1 file changed, 4 insertions(+), 7 deleti

[PATCH 4/4] drm/ttm: Always and only destroy bo->ttm_resv in ttm_bo_release_list

ucher Signed-off-by: Lyude Paul --- drivers/gpu/drm/ttm/ttm_bo.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index bee77d31895b..c088703777e2 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/driver

Re: [PATCHv2] thinkpad_acpi: Implement tablet mode resolving using GMMS method

Looks good to me Reviewed-by: Lyude Paul <ly...@redhat.com> On Tue, 2017-10-10 at 11:12 +0200, Benjamin Berg wrote: > Many thinkpad laptops and convertibles provide the GMMS method to > resolve how far the laptop has been opened and whether it has been > converted into tablet mo

Re: [PATCHv2] thinkpad_acpi: Implement tablet mode resolving using GMMS method

Looks good to me Reviewed-by: Lyude Paul On Tue, 2017-10-10 at 11:12 +0200, Benjamin Berg wrote: > Many thinkpad laptops and convertibles provide the GMMS method to > resolve how far the laptop has been opened and whether it has been > converted into tablet mode. This allows reporti

Re: [PATCH] thinkpad_acpi: Implement tablet mode resolving using GMMS method

Reviewed-by: Lyude Paul <ly...@redhat.com> On Fri, 2017-09-15 at 15:20 +0200, Benjamin Berg wrote: > Many thinkpad laptops and convertibles provide the GMMS method to > resolve how far the laptop has been opened and whether it has been > converted into tablet mode. This allows r

Re: [PATCH] thinkpad_acpi: Implement tablet mode resolving using GMMS method

Reviewed-by: Lyude Paul On Fri, 2017-09-15 at 15:20 +0200, Benjamin Berg wrote: > Many thinkpad laptops and convertibles provide the GMMS method to > resolve how far the laptop has been opened and whether it has been > converted into tablet mode. This allows reporting a more preci

Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder

On Sat, 2017-08-12 at 13:15 +0200, Wolfram Sang wrote: > On Mon, Jun 26, 2017 at 04:40:08PM -0400, Lyude wrote: > > There's quite a number of machines on the market, mainly Lenovo > > ThinkPads, that make the horrible mistake in their firmware of > > reusing > > the PCIBAR space reserved for the

Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder

On Sat, 2017-08-12 at 13:15 +0200, Wolfram Sang wrote: > On Mon, Jun 26, 2017 at 04:40:08PM -0400, Lyude wrote: > > There's quite a number of machines on the market, mainly Lenovo > > ThinkPads, that make the horrible mistake in their firmware of > > reusing > > the PCIBAR space reserved for the

Re: [PATCH] Input: rmi4 - remove the need for artificial IRQ in case of HID

Hi, could we get this thread going again? I've been hit by this problem on my new machine recently, Razer Blade Stealth, and it's been making the touchpad rather difficult to use (jumping cursors being seen, just like the ones mentioned in the thread). Additionally, I've been running this patch

Re: [PATCH] Input: rmi4 - remove the need for artificial IRQ in case of HID

Hi, could we get this thread going again? I've been hit by this problem on my new machine recently, Razer Blade Stealth, and it's been making the touchpad rather difficult to use (jumping cursors being seen, just like the ones mentioned in the thread). Additionally, I've been running this patch

Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume

Yeah I noticed that, sorry if my response wasn't very clear! Should probably wait to have my morning coffee before responding to these messages :P On Mon, 2017-07-24 at 21:28 +0200, Jiri Kosina wrote: > On Mon, 24 Jul 2017, Lyude Paul wrote: > > > > > So, call hid_hw_open()

Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume

Yeah I noticed that, sorry if my response wasn't very clear! Should probably wait to have my morning coffee before responding to these messages :P On Mon, 2017-07-24 at 21:28 +0200, Jiri Kosina wrote: > On Mon, 24 Jul 2017, Lyude Paul wrote: > > > > > So, call hid_hw_open()

Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume

On Mon, 2017-07-24 at 10:15 +0200, Benjamin Tissoires wrote: > On Jul 22 2017 or thereabouts, Lyude wrote: > > So it looks like that suspend/resume has actually always been > > broken on > > hid-rmi. The fact it worked was a rather silly coincidence that was > > relying on the HID device to

Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume

On Mon, 2017-07-24 at 10:15 +0200, Benjamin Tissoires wrote: > On Jul 22 2017 or thereabouts, Lyude wrote: > > So it looks like that suspend/resume has actually always been > > broken on > > hid-rmi. The fact it worked was a rather silly coincidence that was > > relying on the HID device to

Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume

On Sun, 2017-07-23 at 12:54 +0300, Andy Shevchenko wrote: > On Sun, Jul 23, 2017 at 4:15 AM, Lyude wrote: > > > So, call hid_hw_open() in rmi_post_resume() so we make sure that > > the > > device is alive before we try talking to it. > > > > This fixes RMI device

Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume

On Sun, 2017-07-23 at 12:54 +0300, Andy Shevchenko wrote: > On Sun, Jul 23, 2017 at 4:15 AM, Lyude wrote: > > > So, call hid_hw_open() in rmi_post_resume() so we make sure that > > the > > device is alive before we try talking to it. > > > > This fixes RMI device suspend/resume over HID. > > -

Re: [PATCH v2 0/3] Cleanup evergreen/si IRQ handling code

On Sat, 2017-05-20 at 13:39 +0200, Christian König wrote: > Am 20.05.2017 um 01:48 schrieb Lyude: > > This is the first part of me going through and cleaning up the IRQ > > handling > > code for radeon, since after taking a look at it the other day > > while trying to > > debug something I

Re: [PATCH v2 0/3] Cleanup evergreen/si IRQ handling code

On Sat, 2017-05-20 at 13:39 +0200, Christian König wrote: > Am 20.05.2017 um 01:48 schrieb Lyude: > > This is the first part of me going through and cleaning up the IRQ > > handling > > code for radeon, since after taking a look at it the other day > > while trying to > > debug something I

Re: [PATCH] drm/radeon: Unbreak HPD handling for r600+

Mind giving me this a poke when this gets pushed upstream btw? On Fri, 2017-05-12 at 08:56 +0200, Christian König wrote: > Am 12.05.2017 um 01:31 schrieb Lyude: > > We end up reading the interrupt register for HPD5, and then writing > > it > > to HPD6 which on systems without anything using HPD5

Re: [PATCH] drm/radeon: Unbreak HPD handling for r600+

Mind giving me this a poke when this gets pushed upstream btw? On Fri, 2017-05-12 at 08:56 +0200, Christian König wrote: > Am 12.05.2017 um 01:31 schrieb Lyude: > > We end up reading the interrupt register for HPD5, and then writing > > it > > to HPD6 which on systems without anything using HPD5

Re: [PATCH] drm/nouveau: Fix drm poll_helper handling

> Fixes: cae9ff036eea ("drm/nouveau: Don't enabling polling twice on > runtime resume") > Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> > Cc: Lyude Paul <ly...@redhat.com> > Cc: Dave Airlie <airl...@redhat.com> > Cc: Gleb Nemshilov <g..

Re: [PATCH] drm/nouveau: Fix drm poll_helper handling

036eea ("drm/nouveau: Don't enabling polling twice on > runtime resume") > Signed-off-by: Peter Ujfalusi > Cc: Lyude Paul > Cc: Dave Airlie > Cc: Gleb Nemshilov > --- > Hi, > > this patch was created and tested in connection of: > https://bugs.freedesk

Re: [PATCH] drm/nouveau: Add support for clockgating on Fermi+

= -1; /* undefined */ > > return 0; > >  } > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/clkgate.c > > b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/clkgate.c > > new file mode 100644 > > index 000..c030ea9 > > --

Re: [PATCH] drm/nouveau: Add support for clockgating on Fermi+

   return 0; > >  } > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/clkgate.c > > b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/clkgate.c > > new file mode 100644 > > index 000..c030ea9 > > --- /dev/null > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/th

Re: [PATCH] drm/i915/dp: Stop enabling limited color ranges for everything

On Thu, 2017-01-05 at 09:52 +0100, Daniel Vetter wrote: > On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote: > > No matter what we do here, the question remains what to do with > > Chamelium. Changing the color range is really a workaround for > > Chamelium, not a fix. Using CEA range is

Re: [PATCH] drm/i915/dp: Stop enabling limited color ranges for everything

On Thu, 2017-01-05 at 09:52 +0100, Daniel Vetter wrote: > On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote: > > No matter what we do here, the question remains what to do with > > Chamelium. Changing the color range is really a workaround for > > Chamelium, not a fix. Using CEA range is

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

On Thu, 2016-11-03 at 16:25 +, Chris Wilson wrote: > On Thu, Nov 03, 2016 at 12:11:55PM -0400, Lyude Paul wrote: > > > > On Thu, 2016-11-03 at 12:11 -0400, Lyude Paul wrote: > > > > > > On Thu, 2016-11-03 at 16:02 +, Chris Wilson wrote: > > >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

On Thu, 2016-11-03 at 16:25 +, Chris Wilson wrote: > On Thu, Nov 03, 2016 at 12:11:55PM -0400, Lyude Paul wrote: > > > > On Thu, 2016-11-03 at 12:11 -0400, Lyude Paul wrote: > > > > > > On Thu, 2016-11-03 at 16:02 +, Chris Wilson wrote: > > >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

On Thu, 2016-11-03 at 12:11 -0400, Lyude Paul wrote: > On Thu, 2016-11-03 at 16:02 +, Chris Wilson wrote: > > > > On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote: > > > > > > > > > Weine's investigation on benchmarking the suspend/resume p

<    4   5   6   7   8   9   10   >