Re: NVIDIA GPU fallen off the bus after exiting s2idle

2021-05-06 Thread Rafael J. Wysocki
On Tue, May 4, 2021 at 10:08 AM Chris Chiu wrote: > > Hi, > We have some Intel laptops (11th generation CPU) with NVIDIA GPU > suffering the same GPU falling off the bus problem while exiting > s2idle with external display connected. These laptops connect the > external display via the HDMI/Di

Re: [PATCH] component: Move host device to end of device lists on binding

2021-05-10 Thread Rafael J. Wysocki
On Sat, May 8, 2021 at 9:41 AM Stephen Boyd wrote: > > The device lists are poorly ordered when the component device code is > used. This is because component_master_add_with_match() returns 0 > regardless of component devices calling component_add() first. It can > really only fail if an allocati

Re: [PATCH] component: Move host device to end of device lists on binding

2021-05-11 Thread Rafael J. Wysocki
On Mon, May 10, 2021 at 9:08 PM Stephen Boyd wrote: [cut] > > > > > > I will try it, but then I wonder about things like system wide > > > suspend/resume too. The drm encoder chain would need to reimplement the > > > logic for system wide suspend/resume so that any PM ops attached to the > > > m

Re: [PATCH] component: Move host device to end of device lists on binding

2021-05-11 Thread Rafael J. Wysocki
On Tue, May 11, 2021 at 7:00 PM Stephen Boyd wrote: > > Quoting Rafael J. Wysocki (2021-05-11 03:52:06) > > On Mon, May 10, 2021 at 9:08 PM Stephen Boyd wrote: > > > > [cut] > > > > > > > > > > > > > > I will try it, but then I

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Rafael J. Wysocki
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley wrote: > > On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote: > > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley > > wrote: [cut] > > > > Maintainers routinely review 1-line trivial patches, not to mention > > internal API changes, etc. > >

Re: [PATCH v4] Add power/gpu_frequency tracepoint.

2020-11-17 Thread Rafael J. Wysocki
On 11/16/2020 10:05 PM, Steven Rostedt wrote: On Mon, 16 Nov 2020 12:55:29 -0800 Peiyong Lin wrote: Hi there, May I ask whether the merge window has passed? If so is it possible to ask for a review? This is up to the maintainers of power management to accept this. Rafael? I'd say up to th

[PATCH v1 2/7] nouveau: ACPI: Use the ACPI_COMPANION() macro directly

2021-10-12 Thread Rafael J. Wysocki
From: Rafael J. Wysocki The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION() macro and the ACPI handle produced by the former comes from the ACPI device object produced by the latter, so it is way more straightforward to evaluate the latter directly instead of passing the handle

[PATCH v2 2/7] nouveau: ACPI: Use the ACPI_COMPANION() macro directly

2021-10-13 Thread Rafael J. Wysocki
From: Rafael J. Wysocki The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION() macro and the ACPI handle produced by the former comes from the ACPI device object produced by the latter, so it is way more straightforward to evaluate the latter directly instead of passing the handle

Re: acpi_get_devices() crash when acpi_disabled==true (was [PATCH v2] drm/privacy-screen: honor acpi=off in detect_thinkpad_privacy_screen)

2022-01-26 Thread Rafael J. Wysocki
On Wed, Jan 26, 2022 at 2:47 PM Hans de Goede wrote: > > Hi All, > > On 1/23/22 10:10, Tong Zhang wrote: > > when acpi=off is provided in bootarg, kernel crash with > > > > [1.252739] BUG: kernel NULL pointer dereference, address: > > 0018 > > [1.258308] Call Trace: > > [1

Re: acpi_get_devices() crash when acpi_disabled==true (was [PATCH v2] drm/privacy-screen: honor acpi=off in detect_thinkpad_privacy_screen)

2022-01-26 Thread Rafael J. Wysocki
On Wed, Jan 26, 2022 at 5:41 PM Hans de Goede wrote: > > Hi, > > On 1/26/22 16:54, Rafael J. Wysocki wrote: > > On Wed, Jan 26, 2022 at 2:47 PM Hans de Goede wrote: > >> > >> Hi All, > >> > >> On 1/23/22 10:10, Tong Zhang wrote: > &g

Re: acpi_get_devices() crash when acpi_disabled==true (was [PATCH v2] drm/privacy-screen: honor acpi=off in detect_thinkpad_privacy_screen)

2022-01-27 Thread Rafael J. Wysocki
On Thu, Jan 27, 2022 at 2:05 PM Hans de Goede wrote: > > Hi, > > On 1/26/22 18:11, Rafael J. Wysocki wrote: > > On Wed, Jan 26, 2022 at 5:41 PM Hans de Goede wrote: > >> > >> Hi, > >> > >> On 1/26/22 16:54, Rafael J. Wysocki wrote: >

Re: [PATCH v14 20/39] pwm: tegra: Add runtime PM and OPP support

2021-10-29 Thread Rafael J. Wysocki
On Fri, Oct 29, 2021 at 5:20 PM Dmitry Osipenko wrote: > > 26.10.2021 01:40, Dmitry Osipenko пишет: > > + ret = devm_pm_runtime_enable(&pdev->dev); > > + if (ret) > > + return ret; > > + > > + ret = devm_tegra_core_dev_init_opp_table_common(&pdev->dev); > > + if (ret) >

Re: [PATCH v14 20/39] pwm: tegra: Add runtime PM and OPP support

2021-10-29 Thread Rafael J. Wysocki
On Fri, Oct 29, 2021 at 6:29 PM Dmitry Osipenko wrote: > > 29.10.2021 18:56, Rafael J. Wysocki пишет: > > On Fri, Oct 29, 2021 at 5:20 PM Dmitry Osipenko wrote: > >> > >> 26.10.2021 01:40, Dmitry Osipenko пишет: > >>> + ret = devm_pm_runti

Re: [PATCH v2 12/63] thermal: intel: int340x_thermal: Use struct_group() for memcpy() region

2021-11-23 Thread Rafael J. Wysocki
On Wed, Aug 18, 2021 at 8:08 AM Kees Cook wrote: > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > field bounds checking for memcpy(), avoid intentionally writing across > neighboring fields. > > Use struct_group() in struct art around members weight, and ac[0-9]_max, >

Re: [PATCH v2 12/63] thermal: intel: int340x_thermal: Use struct_group() for memcpy() region

2021-11-24 Thread Rafael J. Wysocki
On Wed, Nov 24, 2021 at 12:53 AM Srinivas Pandruvada wrote: > > On Tue, 2021-11-23 at 14:19 +0100, Rafael J. Wysocki wrote: > > On Wed, Aug 18, 2021 at 8:08 AM Kees Cook > > wrote: > > > > > > In preparation for FORTIFY_SOURCE performing compile-time an

Re: Regression report on laptop suspend

2021-12-27 Thread Rafael J. Wysocki
CC Daniel, Thomas and dri-devel. On Mon, Dec 27, 2021 at 5:32 PM wrote: > > Hello > > I've noticed my laptop totally freeze when going to hibernation. > The git bisect log is appended below. > Please note however that even the previous good commit was "good" (ie : > laptop managed to suspend and

Re: [PATCH v5 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting

2019-01-21 Thread Rafael J. Wysocki
On Mon, Jan 21, 2019 at 4:17 PM Vincent Guittot wrote: > > On Fri, 18 Jan 2019 at 13:08, Guenter Roeck wrote: > > > > On 1/18/19 3:05 AM, Rafael J. Wysocki wrote: > > > On Fri, Jan 18, 2019 at 11:53 AM Vincent Guittot > > > wrote: > > >> >

Re: Armada DRM: bridge with componentized devices

2019-01-24 Thread Rafael J. Wysocki
On Friday, January 18, 2019 1:57:47 PM CET Daniel Vetter wrote: > On Fri, Jan 18, 2019 at 12:38 PM Rafael J. Wysocki wrote: > > > > On Fri, Jan 18, 2019 at 12:17 PM Rafael J. Wysocki > > wrote: > > > > > > On Fri, Jan 18, 2019 at 12:06 PM Daniel Vetter

Re: [PATCH 1/2] component: Add documentation

2019-02-05 Thread Rafael J. Wysocki
onstituing components. > > But that's way more than a quick doc typing exercise ... > > Thanks to Ram for commenting on an initial draft of these docs. Look goods to me overall (even though I'm not super-familiar with the component framework), but see below. > Cc: "C, Ramal

Re: [PATCH] component: Add documentation

2019-02-06 Thread Rafael J. Wysocki
t; - s/framework/helper > - clarify the documentation for component_match_add functions. > > Cc: "C, Ramalingam" > Cc: Greg Kroah-Hartman > Cc: Russell King > Cc: Rafael J. Wysocki > Cc: Jaroslav Kysela > Cc: Takashi Iwai > Cc: Rodrigo Vivi > Cc:

Re: [PATCH 2/3] components: multiple components for a device

2019-02-06 Thread Rafael J. Wysocki
(v1 code) > Signed-off-by: Ramalingam C (v1 commit message) > Cc: Ramalingam C > Cc: Greg Kroah-Hartman > Cc: Russell King > Cc: Rafael J. Wysocki > Cc: Jaroslav Kysela > Cc: Takashi Iwai > Cc: Rodrigo Vivi > Cc: Jani Nikula

Re: [PATCH 2/3] components: multiple components for a device

2019-02-07 Thread Rafael J. Wysocki
On Thu, Feb 7, 2019 at 11:40 PM Daniel Vetter wrote: > > On Wed, Feb 06, 2019 at 11:57:04PM +0100, Rafael J. Wysocki wrote: > > ) On Wed, Feb 6, 2019 at 5:46 PM Daniel Vetter > > wrote: > > > > > > Component framework is extended to support multiple compone

Re: [PATCH 2/4] components: multiple components for a device

2019-02-07 Thread Rafael J. Wysocki
ove redundant "This" from kerneldoc (also in the previous patch) > - Streamline the logic in find_component() a bit. > > Signed-off-by: Daniel Vetter (v1 code) > Signed-off-by: Ramalingam C (v1 commit message) > Cc: Ramalingam C > Cc: Greg Kroah-Hartman > Cc: R

Re: [PATCH v2 3/3] drm/i915: Move to new PM core fields

2018-12-18 Thread Rafael J. Wysocki
On Mon, Dec 17, 2018 at 3:22 PM Vincent Guittot wrote: > > On Fri, 14 Dec 2018 at 15:36, Ulf Hansson wrote: > > > > On Fri, 14 Dec 2018 at 15:22, Vincent Guittot > > wrote: > > > > > > With jiffies been replaced by raw ns in PM core accounting, 915 driver is > > > updated to use this new time in

Re: [PATCH v2 3/3] drm/i915: Move to new PM core fields

2018-12-18 Thread Rafael J. Wysocki
On Tue, Dec 18, 2018 at 10:58 AM Vincent Guittot wrote: > > On Tue, 18 Dec 2018 at 10:57, Rafael J. Wysocki wrote: > > > > On Mon, Dec 17, 2018 at 3:22 PM Vincent Guittot > > wrote: > > > > > > On Fri, 14 Dec 2018 at 15:36, Ulf Hansson wrote: &g

Re: [PATCH] sysfs: Disable lockdep for driver bind/unbind files

2018-12-18 Thread Rafael J. Wysocki
> 0001 > [12301.899295] RBP: 5612a1abf7c0 R08: 000a R09: > 5612a1c46730 > [12301.899301] R10: 000a R11: 0246 R12: > 000d > [12301.899308] R13: 0001 R14: 7f452af4a740 R15: >

Re: [PATCH] sysfs: Disable lockdep for driver bind/unbind files

2018-12-19 Thread Rafael J. Wysocki
I: > > 0001 > > [12301.899295] RBP: 5612a1abf7c0 R08: 000a R09: > > 5612a1c46730 > > [12301.899301] R10: 000a R11: 0246 R12: > > 000d > > [12301.899308] R13: 0001 R14: 7f452af4a

Re: [PATCH] sysfs: Disable lockdep for driver bind/unbind files

2018-12-19 Thread Rafael J. Wysocki
12301.899273] RSP: 002b:7ffceafa6918 EFLAGS: 0246 ORIG_RAX: > > > 0001 > > > [12301.899282] RAX: ffda RBX: 000d RCX: > > > 7f452ac7f7a4 > > > [12301.899288] RDX: 000d RSI: 00005612a1abf7c0 RDI: >

Re: [PATCH] sysfs: Disable lockdep for driver bind/unbind files

2018-12-19 Thread Rafael J. Wysocki
: > 000d > > Locking around I've noticed that usb and i2c already handle similar > recursion problems, where a sysfs file can unbind the same type of > sysfs somewhere else in the hierarchy. Relevant commits are: > > commit 356c05d58af05d582e634b54b40050c73609617b > Author: Alan Ste

Re: [PATCH v4 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting

2018-12-21 Thread Rafael J. Wysocki
On Thu, Dec 20, 2018 at 11:03 PM Ulf Hansson wrote: > > On Thu, 20 Dec 2018 at 15:17, Vincent Guittot > wrote: > > > > From: Thara Gopinath > > > > This patch replaces jiffies based accounting for runtime_active_time > > and runtime_suspended_time with ktime base accounting. This makes the > > r

Re: [PATCH v4 03/11] vga-switcheroo: make PCI dependency explicit

2019-01-07 Thread Rafael J. Wysocki
On Mon, Jan 7, 2019 at 11:34 AM Daniel Vetter wrote: > > On Sun, Dec 30, 2018 at 07:56:04PM +, Sinan Kaya wrote: > > This driver depends on the PCI infrastructure but the dependency has not > > been explicitly called out. > > > > Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without

Re: [Intel-gfx] [PATCH v5 2/3] drm/i915: Move on the new pm runtime interface

2019-01-07 Thread Rafael J. Wysocki
On Mon, Jan 7, 2019 at 3:04 PM Vincent Guittot wrote: > > Hi Tvrtko, > > On Mon, 31 Dec 2018 at 13:32, Tvrtko Ursulin > wrote: > > > > > > On 21/12/2018 13:26, Vincent Guittot wrote: > > > On Fri, 21 Dec 2018 at 12:33, Tvrtko Ursulin > > [snip] > > > >> > > >> If it is always monotonic, then wors

Re: Armada DRM: bridge with componentized devices

2019-01-09 Thread Rafael J. Wysocki
On Wed, Jan 9, 2019 at 10:13 AM Andrzej Hajda wrote: > > +CC: Rafael J. Wysocki > > On 08.01.2019 16:07, Russell King - ARM Linux wrote: > > On Tue, Jan 08, 2019 at 03:33:54PM +0100, Andrzej Hajda wrote: > >> On 08.01.2019 14:21, Russell King - ARM Linux wrote: >

Re: Armada DRM: bridge with componentized devices

2019-01-11 Thread Rafael J. Wysocki
On Fri, Jan 11, 2019 at 3:20 PM Daniel Vetter wrote: > > On Wed, Jan 9, 2019 at 10:31 AM Russell King - ARM Linux > wrote: > > On Wed, Jan 09, 2019 at 10:24:01AM +0100, Rafael J. Wysocki wrote: > > > On Wed, Jan 9, 2019 at 10:13 AM Andrzej Hajda wrote: > > >

Re: Armada DRM: bridge with componentized devices

2019-01-11 Thread Rafael J. Wysocki
On Fri, Jan 11, 2019 at 3:32 PM Russell King - ARM Linux wrote: > > On Fri, Jan 11, 2019 at 03:26:44PM +0100, Rafael J. Wysocki wrote: > > On Fri, Jan 11, 2019 at 3:20 PM Daniel Vetter wrote: > > > > > > On Wed, Jan 9, 2019 at 10:31 AM Russell King - ARM Linux >

Re: Armada DRM: bridge with componentized devices

2019-01-11 Thread Rafael J. Wysocki
On Fri, Jan 11, 2019 at 3:36 PM Daniel Vetter wrote: > > On Fri, Jan 11, 2019 at 3:32 PM Russell King - ARM Linux > wrote: > > On Fri, Jan 11, 2019 at 03:26:44PM +0100, Rafael J. Wysocki wrote: > > > On Fri, Jan 11, 2019 at 3:20 PM Daniel Vetter wrote: > > > &g

Re: Armada DRM: bridge with componentized devices

2019-01-14 Thread Rafael J. Wysocki
On Fri, Jan 11, 2019 at 3:49 PM Russell King - ARM Linux wrote: > > On Fri, Jan 11, 2019 at 03:36:28PM +0100, Rafael J. Wysocki wrote: > > On Fri, Jan 11, 2019 at 3:32 PM Russell King - ARM Linux > > wrote: > > > > > > On Fri, Jan 11, 2019 at 03:26:44PM +0100,

Re: Armada DRM: bridge with componentized devices

2019-01-14 Thread Rafael J. Wysocki
[CC Lukas and linux-pm] On Mon, Jan 14, 2019 at 1:32 PM Rafael J. Wysocki wrote: > > On Fri, Jan 11, 2019 at 3:49 PM Russell King - ARM Linux > wrote: [cut] > > > > This thread is discussing how to deal with Armada DRM, its use of the > > component helper,

Re: Armada DRM: bridge with componentized devices

2019-01-15 Thread Rafael J. Wysocki
[CC Greg] On Tuesday, January 15, 2019 1:04:02 AM CET Rafael J. Wysocki wrote: > [CC Lukas and linux-pm] > > On Mon, Jan 14, 2019 at 1:32 PM Rafael J. Wysocki wrote: > > > > On Fri, Jan 11, 2019 at 3:49 PM Russell King - ARM Linux > > wrote: > > [cut] > &

Re: [Intel-gfx] [PATCH v5 2/3] drm/i915: Move on the new pm runtime interface

2019-01-16 Thread Rafael J. Wysocki
On Monday, January 7, 2019 3:21:49 PM CET Rafael J. Wysocki wrote: > On Mon, Jan 7, 2019 at 3:04 PM Vincent Guittot > wrote: > > > > Hi Tvrtko, > > > > On Mon, 31 Dec 2018 at 13:32, Tvrtko Ursulin > > wrote: > > > > > > > > > On

Re: Armada DRM: bridge with componentized devices

2019-01-16 Thread Rafael J. Wysocki
On Wednesday, January 16, 2019 7:42:45 PM CET Daniel Vetter wrote: > On Tue, Jan 15, 2019 at 11:47 PM Rafael J. Wysocki wrote: > > > > [CC Greg] > > > > On Tuesday, January 15, 2019 1:04:02 AM CET Rafael J. Wysocki wrote: > > > [CC Lukas and linux-pm] > &g

Re: Armada DRM: bridge with componentized devices

2019-01-17 Thread Rafael J. Wysocki
On Thursday, January 17, 2019 6:26:25 PM CET Russell King - ARM Linux admin wrote: > On Tue, Jan 15, 2019 at 11:47:00PM +0100, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > Subject: [PATCH] driver core: Fix adding device links to probing suppliers > > > >

Re: Armada DRM: bridge with componentized devices

2019-01-18 Thread Rafael J. Wysocki
On Fri, Jan 18, 2019 at 10:37 AM Lucas Stach wrote: > > Am Donnerstag, den 17.01.2019, 13:20 +0100 schrieb Daniel Vetter: > [...] > > > > > I don't think it is addressed here. > > > > > > Can anyone please explain to me what happens in more detail? > > > > My understanding (and this might be wrong

Re: [PATCH v5 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting

2019-01-18 Thread Rafael J. Wysocki
On Thu, Jan 17, 2019 at 11:16 PM Guenter Roeck wrote: > > On Fri, Dec 21, 2018 at 11:33:56AM +0100, Vincent Guittot wrote: > > From: Thara Gopinath > > > > This patch replaces jiffies based accounting for runtime_active_time > > and runtime_suspended_time with ktime base accounting. This makes th

Re: [PATCH v5 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting

2019-01-18 Thread Rafael J. Wysocki
On Fri, Jan 18, 2019 at 11:53 AM Vincent Guittot wrote: > > On Fri, 18 Jan 2019 at 11:42, Vincent Guittot > wrote: > > > > Hi Guenter, > > > > Le Thursday 17 Jan 2019 à 14:16:28 (-0800), Guenter Roeck a écrit : > > > On Fri, Dec 21, 2018 at 11:33:56AM +0100, Vincent Guittot wrote: > > > > From: T

Re: Armada DRM: bridge with componentized devices

2019-01-18 Thread Rafael J. Wysocki
On Fri, Jan 18, 2019 at 12:06 PM Daniel Vetter wrote: > > On Fri, Jan 18, 2019 at 11:03 AM Rafael J. Wysocki wrote: > > > > On Fri, Jan 18, 2019 at 10:37 AM Lucas Stach wrote: > > > > > > Am Donnerstag, den 17.01.2019, 13:20 +0100 schrieb Daniel Vetter: &

Re: Armada DRM: bridge with componentized devices

2019-01-18 Thread Rafael J. Wysocki
On Fri, Jan 18, 2019 at 12:17 PM Rafael J. Wysocki wrote: > > On Fri, Jan 18, 2019 at 12:06 PM Daniel Vetter wrote: > > > > On Fri, Jan 18, 2019 at 11:03 AM Rafael J. Wysocki > > wrote: > > > > > > On Fri, Jan 18, 2019 at 10:37 AM Lucas Stach >

Re: [PATCH 00/10] cpufreq: Migrate users of policy notifiers to QoS requests

2019-07-16 Thread Rafael J. Wysocki
On Tue, Jul 16, 2019 at 11:49 AM Viresh Kumar wrote: > > Hello, > > Now that cpufreq core supports taking QoS requests for min/max cpu > frequencies, lets migrate rest of the users to using them instead of the > policy notifiers. Technically, this still is linux-next only. :-) > The CPUFREQ_NOTI

Re: [PATCH 00/10] cpufreq: Migrate users of policy notifiers to QoS requests

2019-07-16 Thread Rafael J. Wysocki
On Tue, Jul 16, 2019 at 12:14 PM Viresh Kumar wrote: > > On 16-07-19, 12:06, Rafael J. Wysocki wrote: > > On Tue, Jul 16, 2019 at 11:49 AM Viresh Kumar > > wrote: > > > > > > Hello, > > > > > > Now that cpufreq core supports taking QoS re

Re: [PATCH][next] treewide: Replace zero-length arrays with flexible-array members

2022-02-16 Thread Rafael J. Wysocki
On Tue, Feb 15, 2022 at 8:24 PM Gustavo A. R. Silva wrote: > > On Tue, Feb 15, 2022 at 09:19:29PM +0200, Leon Romanovsky wrote: > > On Tue, Feb 15, 2022 at 01:21:10PM -0600, Gustavo A. R. Silva wrote: > > > On Tue, Feb 15, 2022 at 10:17:40AM -0800, Kees Cook wrote: > > > > On Tue, Feb 15, 2022 at

[PATCH] drm: amd: amdgpu: ACPI: Add comment about ACPI_FADT_LOW_POWER_S0

2022-08-25 Thread Rafael J. Wysocki
From: Rafael J. Wysocki According to the ACPI specification [1], the ACPI_FADT_LOW_POWER_S0 flag merely means that it is better to use low-power S0 idle on the given platform than S3 (provided that the latter is supported) and it doesn't preclude using either of them (which of them will be

Re: [PATCH v2] PM: runtime: Return properly from rpm_resume() if dev->power.needs_force_resume flag is set

2022-09-27 Thread Rafael J. Wysocki
On Tue, Sep 27, 2022 at 9:47 AM Liu Ying wrote: > > On Mon, 2022-09-26 at 11:47 +0200, Ulf Hansson wrote: > > On Fri, 23 Sept 2022 at 17:23, Liu Ying wrote: > > > On Fri, 2022-09-23 at 15:48 +0200, Ulf Hansson wrote: > > > > On Fri, 23 Sept 2022 at 14:47, Liu Ying wrote: > > > > > After a device

Re: [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display

2022-07-14 Thread Rafael J. Wysocki
he "Other issues" section of > the refactor RFC (resulting in patches 15-29 which are new in v2). > > Please review and test! I hope to be able to make an immutable branch > based on 5.20-rc1 + this series available for merging into the various > touched subsystems once 5.20-

Re: [PATCH 4/5] power: avs: smartreflex: Remove superfluous cast in debugfs_create_file() call

2019-11-08 Thread Rafael J. Wysocki
On Monday, October 21, 2019 4:51:48 PM CET Geert Uytterhoeven wrote: > There is no need to cast a typed pointer to a void pointer when calling > a function that accepts the latter. Remove it, as the cast prevents > further compiler checks. > > Signed-off-by: Geert Uytterhoeven Greg, have you ta

Re: [PATCH 4/5] power: avs: smartreflex: Remove superfluous cast in debugfs_create_file() call

2019-11-13 Thread Rafael J. Wysocki
On Monday, October 21, 2019 4:51:48 PM CET Geert Uytterhoeven wrote: > There is no need to cast a typed pointer to a void pointer when calling > a function that accepts the latter. Remove it, as the cast prevents > further compiler checks. > > Signed-off-by: Geert Uytterhoeven > --- > drivers/p

Re: [PATCH v2 2/2] drm/tegra: Do not implement runtime PM

2019-12-12 Thread Rafael J. Wysocki
On Thu, Dec 12, 2019 at 2:32 PM Ulf Hansson wrote: > > On Thu, 12 Dec 2019 at 13:33, Thierry Reding wrote: > > > > On Thu, Dec 12, 2019 at 09:52:22AM +0100, Ulf Hansson wrote: > > > On Mon, 9 Dec 2019 at 14:03, Thierry Reding > > > wrote: > > > > > > > > From: Thierry Reding > > > > > > > > Th

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

2019-10-21 Thread Rafael J. Wysocki
On Mon, Oct 21, 2019 at 4:14 AM Alex Hung wrote: > > We have done some tests on three of Intel + nVidia configuration > systems with OEM _OSI strings removed - while some bugs are still > observed, ex. one out of three has suspend/resume issues, no system > crashes were observed - the biggest issu

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

2019-10-21 Thread Rafael J. Wysocki
ed that approached. OK, please let me know when the _OSI string in question can be dropped. > On Mon, Oct 21, 2019 at 10:14 AM Rafael J. Wysocki wrote: > > > > On Mon, Oct 21, 2019 at 4:14 AM Alex Hung wrote: > > > > > > We have done some tests on three of Intel + n

Re: [RFC PATCH] pci: prevent putting pcie devices into lower device states on certain intel bridges

2019-10-02 Thread Rafael J. Wysocki
On Tue, Oct 1, 2019 at 9:34 PM Bjorn Helgaas wrote: > > On Tue, Oct 01, 2019 at 06:21:28PM +0200, Karol Herbst wrote: > > On Tue, Oct 1, 2019 at 3:27 PM Bjorn Helgaas wrote: > > > On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote: > > > > On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg

Re: [RFC PATCH] pci: prevent putting pcie devices into lower device states on certain intel bridges

2019-10-03 Thread Rafael J. Wysocki
On Tuesday, October 1, 2019 12:00:50 PM CEST Karol Herbst wrote: > On Tue, Oct 1, 2019 at 11:11 AM Mika Westerberg > wrote: > > > > On Tue, Oct 01, 2019 at 10:56:39AM +0200, Karol Herbst wrote: > > > On Tue, Oct 1, 2019 at 10:47 AM Mika Westerberg > > > wrote: > > > > > > > > On Mon, Sep 30, 2019

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-20 Thread Rafael J. Wysocki
On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg wrote: > > Hi Karol, > > On Tue, Nov 19, 2019 at 11:26:45PM +0100, Karol Herbst wrote: > > On Tue, Nov 19, 2019 at 10:50 PM Bjorn Helgaas wrote: > > > > > > [+cc Dave] > > > > > > On Thu, Oct 17, 2019 at 02:19:01PM +0200, Karol Herbst wrote: > > >

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-20 Thread Rafael J. Wysocki
On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg wrote: > > On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. Wysocki wrote: > > On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg > > wrote: > > > > > > Hi Karol, > > > > > > On Tue

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-20 Thread Rafael J. Wysocki
On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst wrote: > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki wrote: > > > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg > > wrote: > > > > > > On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. Wyso

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-20 Thread Rafael J. Wysocki
On Wed, Nov 20, 2019 at 1:06 PM Rafael J. Wysocki wrote: > > On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst wrote: > > > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki > > wrote: > > > > > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg &g

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-20 Thread Rafael J. Wysocki
On Wed, Nov 20, 2019 at 1:10 PM Karol Herbst wrote: > > On Wed, Nov 20, 2019 at 1:06 PM Rafael J. Wysocki wrote: > > > > On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst wrote: > > > > > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki > > > wrot

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-20 Thread Rafael J. Wysocki
On Wed, Nov 20, 2019 at 4:53 PM Mika Westerberg wrote: > > On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrote: > > On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg > > wrote: > > > > > > On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote: > > > > On Wed, Nov 20, 2019 at 1:09 PM

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-20 Thread Rafael J. Wysocki
On Wed, Nov 20, 2019 at 10:40 PM Karol Herbst wrote: > > On Wed, Nov 20, 2019 at 10:37 PM Rafael J. Wysocki wrote: > > > > On Wed, Nov 20, 2019 at 4:53 PM Mika Westerberg > > wrote: > > > > > > On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrot

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-21 Thread Rafael J. Wysocki
On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg wrote: > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote: > > with the branch and patch applied: > > https://gist.githubusercontent.com/karolherbst/03c4c8141b0fa292d781badfa186479e/raw/5c62640afbc57d6e69ea924c338bd2836e770d02/gistfile

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-21 Thread Rafael J. Wysocki
On Thu, Nov 21, 2019 at 12:03 PM Rafael J. Wysocki wrote: > > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg > wrote: > > > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote: > > > with the branch and patch applied: > > > https:/

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-21 Thread Rafael J. Wysocki
On Thu, Nov 21, 2019 at 12:08 PM Rafael J. Wysocki wrote: > > On Thu, Nov 21, 2019 at 12:03 PM Rafael J. Wysocki wrote: > > > > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg > > wrote: > > > > > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbs

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-21 Thread Rafael J. Wysocki
On Thu, Nov 21, 2019 at 12:17 PM Mika Westerberg wrote: > > On Thu, Nov 21, 2019 at 12:03:52PM +0100, Rafael J. Wysocki wrote: > > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg > > wrote: > > > > > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbs

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-21 Thread Rafael J. Wysocki
On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg wrote: > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote: > > > last week or so I found systems where the GPU was under the "PCI > > > Express Root Port" (name from lspci) and on those systems a

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-21 Thread Rafael J. Wysocki
On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg wrote: > > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote: > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > > > wrote:

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-21 Thread Rafael J. Wysocki
On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote: > > On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg > wrote: > > > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > > > wrot

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-21 Thread Rafael J. Wysocki
On Thu, Nov 21, 2019 at 5:06 PM Karol Herbst wrote: > > On Thu, Nov 21, 2019 at 4:47 PM Rafael J. Wysocki wrote: > > > > On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote: > > > > > > On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg > > > wrote:

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-21 Thread Rafael J. Wysocki
On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg wrote: > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote: > > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg > > wrote: > > > > > > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-22 Thread Rafael J. Wysocki
On Fri, Nov 22, 2019 at 1:13 AM Karol Herbst wrote: > > so while trying to test with d3cold disabled, I noticed that I run > into the exact same error. Does this mean that you disabled d3cold on the GPU via sysfs (the "d3cold_allowed" attribute was 0) and the original problem still occurred in th

Re: [PATCH v5] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-22 Thread Rafael J. Wysocki
-off-by: Karol Herbst > Cc: Bjorn Helgaas > Cc: Lyude Paul > Cc: Rafael J. Wysocki > Cc: Mika Westerberg > Cc: linux-...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Bugzilla: https://

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-22 Thread Rafael J. Wysocki
On Fri, Nov 22, 2019 at 11:36 AM Mika Westerberg wrote: > > On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote: > > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg > > wrote: > > > > > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. W

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-22 Thread Rafael J. Wysocki
On Fri, Nov 22, 2019 at 12:34 PM Karol Herbst wrote: > > On Fri, Nov 22, 2019 at 12:30 PM Rafael J. Wysocki wrote: > > [cut] > > > > the issue is not AML related at all as I am able to reproduce this > issue without having to invoke any of that at all, I just

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-11-22 Thread Rafael J. Wysocki
On Fri, Nov 22, 2019 at 12:52 PM Mika Westerberg wrote: > [cut] [I'm really running out of time for today, unfortunately.] > > > > The current design is mostly based on the PCI PM Spec 1.2, so it would > > > > be consequent to follow system-wide suspend in PM-runtime and avoid > > > > putting P

Re: [PATCH 1/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep

2019-11-28 Thread Rafael J. Wysocki
On Thu, Nov 28, 2019 at 5:03 PM Thierry Reding wrote: > > From: Thierry Reding > > Currently the driver PM core will automatically acquire a runtime PM > reference for devices before system sleep is entered. This is needed > to avoid potential issues related to devices' parents getting put to > r

Re: [PATCH 1/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep

2019-11-28 Thread Rafael J. Wysocki
On Thursday, November 28, 2019 5:50:26 PM CET Thierry Reding wrote: > > --0F1p//8PRICkK4MW > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Thu, Nov 28, 2019 at 05:14:51PM +0100, Rafael J. Wyso

Re: [PATCH 1/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep

2019-11-28 Thread Rafael J. Wysocki
On Thursday, November 28, 2019 11:03:57 PM CET Rafael J. Wysocki wrote: > On Thursday, November 28, 2019 5:50:26 PM CET Thierry Reding wrote: > > > > --0F1p//8PRICkK4MW > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > Content-Tr

Re: [PATCH 1/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep

2019-11-29 Thread Rafael J. Wysocki
On Fri, Nov 29, 2019 at 10:34 AM Thierry Reding wrote: > > On Thu, Nov 28, 2019 at 11:03:57PM +0100, Rafael J. Wysocki wrote: > > On Thursday, November 28, 2019 5:50:26 PM CET Thierry Reding wrote: > > > > > > --0F1p//8PRICkK4MW > > > Content-Type: tex

Re: [PATCH 1/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep

2019-11-29 Thread Rafael J. Wysocki
On Fri, Nov 29, 2019 at 11:08 AM Thierry Reding wrote: > > On Thu, Nov 28, 2019 at 11:20:01PM +0100, Rafael J. Wysocki wrote: > > On Thursday, November 28, 2019 11:03:57 PM CET Rafael J. Wysocki wrote: > > > On Thursday, November 28, 2019 5:50:26 PM CET

Re: [PATCH 1/3] ACPI / LPSS: Rename pwm_backlight pwm-lookup to pwm_soc_backlight

2019-11-29 Thread Rafael J. Wysocki
er depending on the VBT bit, instead of the i915 driver > relying on a "pwm_backlight" lookup getting registered which magically > points to the right controller. > > Signed-off-by: Hans de Goede Acked-by: Rafael J. Wysocki Or please let me know if you want me to take the who

Re: [PATCH 1/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep

2019-12-03 Thread Rafael J. Wysocki
On Fri, Nov 29, 2019 at 1:07 PM Thierry Reding wrote: > > On Fri, Nov 29, 2019 at 11:22:08AM +0100, Rafael J. Wysocki wrote: > > [cut] Sorry for the delay. First off, let me note that I have seen your most recent patches and thanks for taking the feedback into account, much

Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

2019-12-09 Thread Rafael J. Wysocki
On Mon, Dec 9, 2019 at 12:17 PM Karol Herbst wrote: > > anybody any other ideas? Not yet, but I'm trying to collect some more information. > It seems that both patches don't really fix > the issue and I have no idea left on my side to try out. The only > thing left I could do to further investig

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

2019-09-05 Thread Rafael J. Wysocki
Alex Hung and Mario need to answer this question I think. > On Mon, Aug 19, 2019 at 11:52 AM Rafael J. Wysocki wrote: > > > > On Thursday, August 15, 2019 12:47:35 AM CEST Dave Airlie wrote: > > > On Thu, 15 Aug 2019 at 07:31, Karol Herbst wrot

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

2019-08-19 Thread Rafael J. Wysocki
On Thursday, August 15, 2019 12:47:35 AM CEST Dave Airlie wrote: > On Thu, 15 Aug 2019 at 07:31, Karol Herbst wrote: > > > > This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c. > > > > The original commit message didn't even make sense. AMD _does_ support it > > and > > it works with No

Re: [PATCH v2] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops

2023-01-11 Thread Rafael J. Wysocki
wrong acpi_device because of the wrong > acpi_find_child_device() return. This breaks the ACPI video code, > leading to non working backlight control in some cases. > > Add a type.backlight flag, mark ACPI video bus devices with this and make > find_child_checks() return a higher

Re: [PATCH v2] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops

2023-01-11 Thread Rafael J. Wysocki
On Wed, Jan 11, 2023 at 9:23 PM Hans de Goede wrote: > > Hi, > > On 1/11/23 21:16, Rafael J. Wysocki wrote: > > On Tue, Jan 10, 2023 at 4:30 PM Hans de Goede wrote: > >> > >> The Dell Latitude E6430 both with and without the optional NVidia dGPU > >>

Re: [PATCH] ACPI: video: Add backlight=native DMI quirk for Acer Aspire 4810T

2023-01-17 Thread Rafael J. Wysocki
On Fri, Jan 13, 2023 at 12:41 PM Hans de Goede wrote: > > The Acer Aspire 4810T predates Windows 8, so it defaults to using > acpi_video# for backlight control, but this is non functional on > this model. > > Add a DMI quirk to use the native backlight interface which does > work properly. > > Sig

Re: [PATCH 0/2] ACPI: video: More backlight quirks

2023-01-23 Thread Rafael J. Wysocki
On Thu, Jan 19, 2023 at 5:38 PM Hans de Goede wrote: > > Hi Rafael, > > With the backlight changes landing in 6.1.y now showing up in > distribution repositories I have been receiving a steady stream of > backlight bug reports by email. > > These bug-reports fall into various categories and most o

Re: [PATCH] ACPI: video: Add backlight=native DMI quirk for Asus U46E

2023-01-23 Thread Rafael J. Wysocki
On Thu, Jan 19, 2023 at 6:24 PM Hans de Goede wrote: > > The Asus U46E backlight tables have a set of interesting problems: > > 1. Its ACPI tables do make _OSI ("Windows 2012") checks, so >acpi_osi_is_win8() should return true. > >But the tables have 2 sets of _OSI calls, one from the usua

Re: [PATCH] ACPI: PCI: Fix device reference counting in acpi_get_pci_dev()

2022-10-19 Thread Rafael J. Wysocki
On Wed, Oct 19, 2022 at 2:22 PM Ville Syrjälä wrote: > > On Wed, Oct 19, 2022 at 01:35:26PM +0200, Rafael J. Wysocki wrote: > > On Wed, Oct 19, 2022 at 11:02 AM Ville Syrjälä > > wrote: > > > > > > On Tue, Oct 18, 2022 at 07:34:03PM +0200, Rafael J. Wysocki wr

Re: [PATCH v2] ACPI: video: Fix missing native backlight on Chromebooks

2022-10-24 Thread Rafael J. Wysocki
p and send it in a fixes pull-req > for 6.1 to Linus? Or shall I pick this one up and include it > in my next pull-req? It would be better if you could pick this up IMV, so please free to add Acled-by: Rafael J. Wysocki to it. Thanks! > > > > drivers/acpi/video_detect

Re: [PATCH 3/5] kobject: kset_uevent_ops: make filter() callback take a const *

2022-11-21 Thread Rafael J. Wysocki
ave the correct signature to preserve the build. > > Cc: "Rafael J. Wysocki" > Cc: Sumit Semwal > Cc: "Christian König" > Cc: linux-me...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linaro-mm-...@lists.linaro.org > Signed-off-by: Greg Kroah-Ha

Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

2022-10-27 Thread Rafael J. Wysocki
On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote: > > Hi, > > On 10/27/22 11:52, Matthew Garrett wrote: > > On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > > > >> The *only* behavior which actually is new in 6.1 is the native GPU > >> drivers now doing the equivalent of: > >>

  1   2   3   4   5   6   >