similar to: [PATCH AUTOSEL 4.14 14/16] drm/nouveau: Don't disable polling in fallback mode

From: Takashi Iwai <tiwai at suse.de> [ Upstream commit 118780066e30c34de3d9349710b51780bfa0ba83 ] When a fan is controlled via linear fallback without cstate, we shouldn't stop polling. Otherwise it won't be adjusted again and keeps running at an initial crazy pace. Fixes: 800efb4c2857 ("drm/nouveau/drm/therm/fan: add a fallback if no fan control is specified in the

From: Takashi Iwai <tiwai at suse.de> [ Upstream commit 118780066e30c34de3d9349710b51780bfa0ba83 ] When a fan is controlled via linear fallback without cstate, we shouldn't stop polling. Otherwise it won't be adjusted again and keeps running at an initial crazy pace. Fixes: 800efb4c2857 ("drm/nouveau/drm/therm/fan: add a fallback if no fan control is specified in the

On Wed, 12 Sep 2018 at 20:59, Takashi Iwai <tiwai at suse.de> wrote: > > When a fan is controlled via linear fallback without cstate, we > shouldn't stop polling. Otherwise it won't be adjusted again and > keeps running at an initial crazy pace. Martin, Any thoughts on this? Ben. > > Fixes: 800efb4c2857 ("drm/nouveau/drm/therm/fan: add a fallback if no fan

When a fan is controlled via linear fallback without cstate, we shouldn't stop polling. Otherwise it won't be adjusted again and keeps running at an initial crazy pace. Fixes: 800efb4c2857 ("drm/nouveau/drm/therm/fan: add a fallback if no fan control is specified in the vbios") Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103356 Bugzilla:

On Fri, 14 Sep 2018 13:59:25 +0200, Martin Peres wrote: > > On 14/09/2018 10:28, Ben Skeggs wrote: > > On Wed, 12 Sep 2018 at 20:59, Takashi Iwai <tiwai at suse.de> wrote: > >> > >> When a fan is controlled via linear fallback without cstate, we > >> shouldn't stop polling. Otherwise it won't be adjusted again and > >> keeps running

On 14/09/2018 10:28, Ben Skeggs wrote: > On Wed, 12 Sep 2018 at 20:59, Takashi Iwai <tiwai at suse.de> wrote: >> >> When a fan is controlled via linear fallback without cstate, we >> shouldn't stop polling. Otherwise it won't be adjusted again and >> keeps running at an initial crazy pace. > Martin, > > Any thoughts on this? > > Ben. Wow,

This seems to be absolutely necessary for a lot of NV40. Reported-by: gsgf on IRC/freenode Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/nouveau/nvkm/subdev/therm/base.c | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/therm/base.c b/drm/nouveau/nvkm/subdev/therm/base.c index 8894fee..df949fa 100644 ---

On 29/09/16 03:41, Martin Peres wrote: > This seems to be absolutely necessary for a lot of NV40. > > Reported-by: gsgf on IRC/freenode > Signed-off-by: Martin Peres <martin.peres at free.fr> I of course forgot to tag this patch for stable. The thing has been broken on some nv40 ... forever? > --- > drm/nouveau/nvkm/subdev/therm/base.c | 22 +++++++++++++++++++--- >

https://bugs.freedesktop.org/show_bug.cgi?id=107447 Bug ID: 107447 Summary: regression in thermal management of Quadro FX 1500 Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau

From: Sui Jingfeng <suijingfeng at loongson.cn> Should be no functional change Cc: Jaroslav Kysela <perex at perex.cz> Cc: Takashi Iwai <tiwai at suse.com> Cc: Fred Oh <fred.oh at linux.intel.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart at linux.intel.com> Cc: Kai Vehmanen <kai.vehmanen at linux.intel.com> Cc: Bjorn Helgaas <bhelgaas at

> -----Original Message----- > From: Takashi Iwai <tiwai at suse.de> > Sent: Thursday, August 15, 2019 9:57 AM > To: Alex Deucher > Cc: Karol Herbst; Limonciello, Mario; nouveau; Rafael J . Wysocki; LKML; dri-devel; > Linux ACPI Mailing List; Alex Hung; Ben Skeggs; David Airlie > Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to >

On Thu, Aug 15, 2019 at 12:19 PM <Mario.Limonciello at dell.com> wrote: > > > -----Original Message----- > > From: Takashi Iwai <tiwai at suse.de> > > Sent: Thursday, August 15, 2019 9:57 AM > > To: Alex Deucher > > Cc: Karol Herbst; Limonciello, Mario; nouveau; Rafael J . Wysocki; LKML; dri-devel; > > Linux ACPI Mailing List; Alex Hung; Ben

On Thu, 15 Aug 2019 18:19:52 +0200, <Mario.Limonciello at dell.com> wrote: > > > -----Original Message----- > > From: Takashi Iwai <tiwai at suse.de> > > Sent: Thursday, August 15, 2019 9:57 AM > > To: Alex Deucher > > Cc: Karol Herbst; Limonciello, Mario; nouveau; Rafael J . Wysocki; LKML; dri-devel; > > Linux ACPI Mailing List; Alex Hung; Ben

Since the commit 742db30c4ee6 ("drm/nouveau: Add HD-audio component notifier support"), the nouveau driver notifies and pokes the HD-audio HPD and ELD via audio component, but this seems broken. The culprit is the naive assumption that crtc->index corresponds to the HDA pin. Actually this rather corresponds to the MST dev_id (alias "pipe" in the audio component framework)

Macbook 5,1 with MCP79 lost its backlight control since the recent change for supporting GFP-RM; it rewrote the whole nv50 backlight control code and each display engine is supposed to have an entry for IOR bl callback, but it didn't cover mcp77. This patch adds the missing bl entry initialization for mcp77 display engine to recover the backlight control. Fixes: 2274ce7e3681

This patch adds the support for the notification of HD-audio hotplug via the already existing drm_audio_component framework. This allows us more reliable hotplug notification and ELD transfer without accessing HD-audio bus; it's more efficient, and more importantly, it works without waking up the runtime PM. The implementation is rather simplistic: nouveau driver provides the get_eld ops for

https://bugs.freedesktop.org/show_bug.cgi?id=86115 Bug ID: 86115 Summary: Suspend to RAM fails when using Nouveau Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

flight 21641 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/21641/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pv 18 leak-check/check fail REGR. vs. 21026 test-amd64-i386-qemut-rhel6hvm-intel 11 leak-check/check fail REGR. vs. 21026 test-amd64-i386-qemuu-rhel6hvm-intel 11

advanced in the printer-settings on windows) But if the driver does not get copied over? best regards thomas ________________________________________ Von: "Daniel M=C3=BCller" <mueller at tropenklinik.de> An: "Thomas Stegbauer" <mailingliste1 at stegbauer.info>, "Laurent Blume" = <laurent at opensolaris.org> CC: samba at lists.samba.org Gesendet:

d in the printer-settings on windows)=20 But if the driver does not get copied over?=20 best regards=20 thomas=20 ----- Urspr=C3=BCngliche Mail ----- Von: "Daniel M=C3=BCller" <mueller at tropenklinik.de>=20 An: "Thomas Stegbauer" <mailingliste1 at stegbauer.info>, "Laurent Blume" <lau= rent at opensolaris.org>=20 CC: samba at lists.samba.org=20