Re: [PATCH] tracing/treewide: Remove second parameter of __assign_str()

r_len() > __assign_rel_str() > __assign_rel_str_len() > > I tested this with both an allmodconfig and an allyesconfig (build only for > both). > > [1] > https://lore.kernel.org/linux-trace-kernel/2024011442.634192...@goodmis.org/ > > Cc: Masami Hiramatsu > Cc: Mathieu Desnoyers > Cc: Linus Torvalds > Cc: Julia Lawall > Signed-off-by: Steven Rostedt (Google) Acked-by: Rafael J. Wysocki # for thermal

Re: [PATCH] ACPI: video: Fix name collision with architecture's video.o

CC Hans who has been doing the majority of the ACPI video work. On Thu, May 16, 2024 at 2:43 PM Thomas Zimmermann wrote: > > Commit 2fd001cd3600 ("arch: Rename fbdev header and source files") > renames the video source files under arch/ such that they does not > refer to fbdev any longer. The

Re: [PATCH v3 1/2] pm: runtime: Simplify pm_runtime_get_if_active() usage

On Mon, Jan 22, 2024 at 7:12 PM Bjorn Helgaas wrote: > > On Mon, Jan 22, 2024 at 01:41:21PM +0200, Sakari Ailus wrote: > > There are two ways to opportunistically increment a device's runtime PM > > usage count, calling either pm_runtime_get_if_active() or > > pm_runtime_get_if_in_use(). The

Re: [Intel-gfx] [PATCH v2] powercap: intel_rapl: Downgrade BIOS locked limits pr_warn() to pr_debug()

me. The user can't do anything about this so > printing scary warnings doesn't make sense > > Keep the printk but make it pr_debug() instead of pr_warn() > to make it clear it's not a serious issue. > > Cc: Zhang Rui > Cc: Wang Wendy > Cc: Rafael J. Wysocki > Cc: Srini

Re: [Intel-gfx] [PATCH] powercap: intel_rapl: Don't warn about BIOS locked limits during resume

On Tue, Oct 24, 2023 at 8:48 PM Ville Syrjälä wrote: > > On Tue, Oct 24, 2023 at 08:31:34PM +0200, Rafael J. Wysocki wrote: > > On Tue, Oct 24, 2023 at 7:11 PM Ville Syrjälä > > wrote: > > > > > > On Wed, Oct 04, 2023 at 09:59:47PM +0300, Ville Syrjälä wrote

Re: [Intel-gfx] [PATCH] powercap: intel_rapl: Don't warn about BIOS locked limits during resume

bug > > > here? > > > > I presume someone wanted to make it pr_warn() for a reason. > > I don't mind either way. > > Ping. Can someone make a decision on how this should get fixed > so we get this moving forward? I thought we were going to replace the pr_

Re: [Intel-gfx] [PATCH] MAINTAINERS: update the 01.org website entries

repository is already referred to by the T: entry in that section. > > The link resolves the pm-graph project page in Intel's Open Ecosystem area > at intel.com. Update this webpage entry. > > M: "Todd E Brandt" > L: linux...@vger.kernel.org > > Signed-

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

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: [Intel-gfx] [PATCH v2] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops

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: [Intel-gfx] [PATCH] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops

On Monday, January 9, 2023 9:57:21 PM CET Hans de Goede wrote: > The Dell Latitude E6430 both with and without the optional NVidia dGPU > has a bug in its ACPI tables which is causing Linux to assign the wrong > ACPI fwnode / companion to the pci_device for the i915 iGPU. > > Specifically under

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

On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede wrote: > > Hi, > > On 10/27/22 14:09, Rafael J. Wysocki wrote: > > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote: > >> > >> Hi, > >> > >> On 10/27/22 11:52, Matthew Garrett wrote: > &g

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

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: > >>

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

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: [Intel-gfx] [PATCH] drm/i915: Allow D3 when we are not actively managing a known PCI device.

On 9/23/2022 8:20 PM, Vivi, Rodrigo wrote: Rafael, could you please add your thoughts here? Sure, sorry for the delay. I gather the idea is to bind the driver to the device without actually doing anything more to it and to put it into D3, so it doesn't draw too much power. Using

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

m the "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: [Intel-gfx] [PATCH][next] treewide: Replace zero-length arrays with flexible-array members

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

Re: [Intel-gfx] [PATCH] PM: sleep: Avoid calling put_device() under dpm_list_mtx

On 12/16/2021 2:27 PM, Thomas Hellström wrote: Hi, Rafael, On 11/4/21 18:26, Rafael J. Wysocki wrote: It is generally unsafe to call put_device() with dpm_list_mtx held, because the given device's release routine may carry out an action depending on that lock which then may deadlock, so modify

Re: [Intel-gfx] [PATCH 02/17] Use memberof(T, m) instead of explicit NULL dereference

Len Brown > Cc: "Michael S. Tsirkin" > Cc: Miguel Ojeda > Cc: Mike Rapoport > Cc: Nick Desaulniers > Cc: "Rafael J. Wysocki" > Cc: Rasmus Villemoes > Cc: Rodrigo Vivi > Cc: Russell King > Cc: Somnath Kotur > Cc: Sriharsha Basavapatna &g

Re: [Intel-gfx] [PATCH v2 1/2] ACPI: utils: Add acpi_reduced_hardware() helper

On Wed, Apr 7, 2021 at 7:58 PM Hans de Goede wrote: > > Add a getter for the acpi_gbl_reduced_hardware variable so that modules > can check if they are running on an ACPI reduced-hw platform or not. > > Signed-off-by: Hans de Goede > --- > Changes in v2: > - Use EXPORT_SYMBOL_GPL instead of

Re: [Intel-gfx] [PATCH 1/2] ACPI: utils: Add acpi_reduced_hardware() helper

On Wed, Apr 7, 2021 at 7:43 PM Hans de Goede wrote: > > Hi, > > On 4/7/21 7:13 PM, Rafael J. Wysocki wrote: > > On Tue, Apr 6, 2021 at 11:17 PM Hans de Goede wrote: > >> > >> Add a getter for the acpi_gbl_reduced_hardware variable so that modules > >

Re: [Intel-gfx] [PATCH 1/2] ACPI: utils: Add acpi_reduced_hardware() helper

On Tue, Apr 6, 2021 at 11:17 PM Hans de Goede wrote: > > Add a getter for the acpi_gbl_reduced_hardware variable so that modules > can check if they are running on an ACPI reduced-hw platform or not. > > Signed-off-by: Hans de Goede > --- > drivers/acpi/utils.c| 11 +++ >

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

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: [Intel-gfx] [PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation)

le of test and those do > show that restoring the LPSS-context indeed does not seem to be necessary > on devices using s2idle suspend (and successfully reaching S0i3). But I > have no hardware to test deep / S3 suspend. So I'm not sure that not > restoring the context is safe. > > That lea

Re: [Intel-gfx] [PATCH v3 01/15] ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase

device-link added by the pwm-get this > ensures that the PWM controller will be on when the troublesome PS0 > method runs, which stops it from poking the PWM controller. > > Signed-off-by: Hans de Goede Acked-by: Rafael J. Wysocki > --- > drivers/acpi/acpi_lpss.c | 1 + > 1 fi

Re: [Intel-gfx] [RFC] GPU-bound energy efficiency improvements for the intel_pstate driver (v2.99)

On Monday, May 11, 2020 11:01:41 PM CEST Francisco Jerez wrote: > > --==-=-= > Content-Type: multipart/mixed; boundary="=-=-=" > > --=-=-= > Content-Type: text/plain; charset=utf-8 > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > Peter Zijlstra writes: > > > On

Re: [Intel-gfx] [PATCH] cpufreq/pstate: Only mention the BIOS disabling turbo mode once

a > Cc: Len Brown > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > --- > drivers/cpufreq/intel_pstate.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > index c8

[Intel-gfx] [PATCH v2 7/9] PM: sleep: core: Rename DPM_FLAG_NEVER_SKIP

From: "Rafael J. Wysocki" Rename DPM_FLAG_NEVER_SKIP to DPM_FLAG_NO_DIRECT_COMPLETE which matches its purpose more closely. No functional impact. Signed-off-by: Rafael J. Wysocki Acked-by: Bjorn Helgaas # for PCI parts Acked-by: Jeff Kirsher --- -> v2: * Rebased.

[Intel-gfx] [PATCH 5/7] PM: sleep: core: Rename DPM_FLAG_NEVER_SKIP

From: "Rafael J. Wysocki" Rename DPM_FLAG_NEVER_SKIP to DPM_FLAG_NO_DIRECT_COMPLETE which matches its purpose more closely. No functional impact. Signed-off-by: Rafael J. Wysocki --- Documentation/driver-api/pm/devices.rst| 6 +++--- Documentation/power/pci.rst

Re: [Intel-gfx] [PATCH 08/10] cpufreq: intel_pstate: Enable VLP controller based on ACPI FADT profile and CPUID.

On Tuesday, March 10, 2020 10:42:01 PM CET Francisco Jerez wrote: > For the moment the VLP controller is only enabled on ICL platforms > other than server FADT profiles in order to reduce the validation > effort of the initial submission. It should work on any other > processors that support HWP

Re: [Intel-gfx] [PATCH 06/10] cpufreq: intel_pstate: Implement VLP controller target P-state range estimation.

On Tuesday, March 10, 2020 10:41:59 PM CET Francisco Jerez wrote: > The function introduced here calculates a P-state range derived from > the statistics computed in the previous patch which will be used to > drive the HWP P-state range or (if HWP is not available) as basis for > some additional

Re: [Intel-gfx] [PATCH 05/10] cpufreq: intel_pstate: Implement VLP controller statistics and status calculation.

On Tuesday, March 10, 2020 10:41:58 PM CET Francisco Jerez wrote: > The goal of the helper code introduced here is to compute two > informational data structures: struct vlp_input_stats aggregating > various scheduling and PM statistics gathered in every call of the > update_util() hook, and

Re: [Intel-gfx] [PATCH 04/10] Revert "cpufreq: intel_pstate: Drop ->update_util from pstate_funcs"

On Tuesday, March 10, 2020 10:41:57 PM CET Francisco Jerez wrote: > This reverts commit c4f3f70cacba2fa19545389a12d09b606d2ad1cf. A > future commit will introduce a new update_util implementation, so the > pstate_funcs table entry is going to be useful. This basically means that you want to

Re: [Intel-gfx] [PATCHv2 01/10] PM: QoS: Add CPU_RESPONSE_FREQUENCY global PM QoS limit.

On Wednesday, March 11, 2020 8:23:19 PM CET Francisco Jerez wrote: > The purpose of this PM QoS limit is to give device drivers additional > control over the latency/energy efficiency trade-off made by the PM > subsystem (particularly the CPUFREQ governor). It allows device > drivers to set a

Re: [Intel-gfx] [PATCH 16/28] drm: i915: Call cpu_latency_qos_*() instead of pm_qos_*()

On Wed, Feb 12, 2020 at 12:40 AM Rafael J. Wysocki wrote: > > From: "Rafael J. Wysocki" > > Call cpu_latency_qos_add/update/remove_request() instead of > pm_qos_add/update/remove_request(), respectively, because the > latter are going to be dropped. > >

[Intel-gfx] [PATCH 16/28] drm: i915: Call cpu_latency_qos_*() instead of pm_qos_*()

From: "Rafael J. Wysocki" Call cpu_latency_qos_add/update/remove_request() instead of pm_qos_add/update/remove_request(), respectively, because the latter are going to be dropped. No intentional functional impact. Signed-off-by: Rafael J. Wysocki --- drivers/gpu/drm/i915/display/

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

ng 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 whole serie

Re: [Intel-gfx] [PATCH v2] Core-for-CI:ICL_only Disable ACPI idle driver

On 4/9/2019 8:29 AM, Anshuman Gupta wrote: There were few system hung observed while running i915_pm_rpm igt test. FDO https://bugs.freedesktop.org/show_bug.cgi?id=108840 Root cause is believed to due to page fault in ACPI idle driver. (FDO comment 18). It has been suggested by Daniel Vetter to

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

; - Remove 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: [Intel-gfx] [PATCH 2/3] components: multiple components for a device

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

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

(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: [Intel-gfx] [PATCH v5 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting

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: [Intel-gfx] [PATCH v5 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting

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:

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

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

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

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: [Intel-gfx] [PATCH v5 2/3] drm/i915: Move on the new pm runtime interface

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

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

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 > >

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

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 Stern > Date: Mon May 14 13:30:03 2012 -0400 > &

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

LAGS: 0246 ORIG_RAX: > > > 0001 > > > [12301.899282] RAX: ffda RBX: 000d RCX: > > > 7f452ac7f7a4 > > > [12301.899288] RDX: 000d RSI: 5612a1abf7c0 RDI: > > > 000000000001 > > > [1230

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

2301.899295] RBP: 5612a1abf7c0 R08: 000a R09: > > 5612a1c46730 > > [12301.899301] R10: 000a R11: 0246 R12: > > 000d > > [12301.899308] R13: 0001 R14: 00007f452af4a740 R15: > > 000d > > > >

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

5612a1abf7c0 R08: 0000000a R09: > 5612a1c46730 > [12301.899301] R10: 000a R11: 0246 R12: > 000d > [12301.899308] R13: 0001 R14: 7f452af4a740 R15: > 000d > > Locking around I've noticed that usb and i

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

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: [Intel-gfx] [PATCH v2 3/3] drm/i915: Move to new PM core fields

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

Re: [Intel-gfx] [PATCH v4 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC

On Fri, Dec 14, 2018 at 12:05 PM Mika Westerberg wrote: > > On Fri, Dec 14, 2018 at 11:48:35AM +0100, Hans de Goede wrote: > > > > +#include > > > > > > Why is this include needed? > > > > It is no longer needed in v4, since the parsing of the raw > > MIPI sequence data (which needed this

Re: [Intel-gfx] [PATCH 1/2] sysfs: constify sysfs create/remove files harder

On Fri, Oct 5, 2018 at 9:36 AM Jani Nikula wrote: > > On Fri, 05 Oct 2018, "Rafael J. Wysocki" wrote: > > On Thu, Oct 4, 2018 at 4:38 PM Jani Nikula wrote: > >> > >> Let the passed in array be const (and thus placed in rodata) instead of > >&g

Re: [Intel-gfx] [PATCH 2/2] drm/i915/sysfs: make attrs arrays const

On Thu, Oct 4, 2018 at 4:38 PM Jani Nikula wrote: > > They don't need to be modified. > > Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Signed-off-by: Jani Nikula Reviewed-by: Rafael J. Wysocki > --- > drivers/gpu/drm/i915/i915_sysfs.c | 4 ++-- >

Re: [Intel-gfx] [PATCH 1/2] sysfs: constify sysfs create/remove files harder

ot modify either the pointer passed to it, or the contents of the array pointed to by that pointer. They don't imply the location of the array itself, though. As for the changes: Reviewed-by: Rafael J. Wysocki > Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Signed-off-

Re: [Intel-gfx] [PATCH] cpufreq: use for_each_if

On Mon, Jul 9, 2018 at 6:11 PM, Daniel Vetter wrote: > Avoids the inverted condition compared to the open coded version. > > Signed-off-by: Daniel Vetter > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > Cc: linux...@vger.kernel.org > Cc: Eric Engestrom > -- >

Re: [Intel-gfx] [PATCH v2] drm/i915/pmu: Fix sleep under atomic in RC6 readout

On 2/6/2018 10:54 PM, Imre Deak wrote: Hi Rafael, On Tue, Feb 06, 2018 at 09:11:02PM +, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-02-06 18:33:11) From: Tvrtko Ursulin We are not allowed to call intel_runtime_pm_get from the PMU counter read callback

Re: [Intel-gfx] [-next PATCH 3/4] treewide: Use DEVICE_ATTR_RO

} > > -static DEVICE_ATTR(power_state, 0444, power_state_show, NULL); > +static DEVICE_ATTR_RO(power_state); > > static ssize_t > acpi_eject_store(struct device *d, struct device_attribute *attr, > @@ -462,7 +462,7 @@ static ssize_t description_show(struct device *dev, > > return result; > } > -static DEVICE_ATTR(description, 0444, description_show, NULL); > +static DEVICE_ATTR_RO(description); > > static ssize_t > acpi_device_sun_show(struct device *dev, struct device_attribute *attr, Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> for this bit. Thanks! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] ACPI / PM: Fix acpi_pm_notifier_lock vs. flush_workqueue() deadlock

On Wed, Nov 8, 2017 at 1:41 PM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: > On Wednesday, November 8, 2017 1:31:22 PM CET Ville Syrjälä wrote: >> On Wed, Nov 08, 2017 at 01:23:56PM +0100, Rafael J. Wysocki wrote: >> > On Wed, Nov 8, 2017 at 12:06 AM, Rafael J. Wys

Re: [Intel-gfx] [PATCH] ACPI / PM: Fix acpi_pm_notifier_lock vs. flush_workqueue() deadlock

On Wednesday, November 8, 2017 1:31:22 PM CET Ville Syrjälä wrote: > On Wed, Nov 08, 2017 at 01:23:56PM +0100, Rafael J. Wysocki wrote: > > On Wed, Nov 8, 2017 at 12:06 AM, Rafael J. Wysocki <r...@rjwysocki.net> > > wrote: > > > On Tuesday, November 7, 2017 11:47:54

Re: [Intel-gfx] [PATCH] ACPI / PM: Fix acpi_pm_notifier_lock vs. flush_workqueue() deadlock

On Wed, Nov 8, 2017 at 12:06 AM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: > On Tuesday, November 7, 2017 11:47:54 PM CET Rafael J. Wysocki wrote: >> On Tue, Nov 7, 2017 at 10:08 PM, Ville Syrjala >> <ville.syrj...@linux.intel.com> wrote: >> > From: Ville Sy

Re: [Intel-gfx] [PATCH] ACPI / PM: Fix acpi_pm_notifier_lock vs. flush_workqueue() deadlock

On Tue, Nov 7, 2017 at 11:47 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Tue, Nov 7, 2017 at 10:08 PM, Ville Syrjala > <ville.syrj...@linux.intel.com> wrote: >> From: Ville Syrjälä <ville.syrj...@linux.intel.com> >> >> acpi_remove_pm_notifier

Re: [Intel-gfx] [PATCH] ACPI / PM: Fix acpi_pm_notifier_lock vs. flush_workqueue() deadlock

On Tuesday, November 7, 2017 11:47:54 PM CET Rafael J. Wysocki wrote: > On Tue, Nov 7, 2017 at 10:08 PM, Ville Syrjala > <ville.syrj...@linux.intel.com> wrote: > > From: Ville Syrjälä <ville.syrj...@linux.intel.com> > > > > acpi_remove_pm_notifier() end

Re: [Intel-gfx] [PATCH] ACPI / PM: Fix acpi_pm_notifier_lock vs. flush_workqueue() deadlock

ken by > by the work via acpi_pm_notify_handler(). This can deadlock. OK, good catch! [cut] > > Cc: sta...@vger.kernel.org > Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com> > Cc: Len Brown <l...@kernel.org> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc:

Re: [Intel-gfx] [PATCH 2/3] ACPI/DRM: rework ACPI_VIDEO Kconfig dependencies

; depends on INPUT > select THERMAL > + select BACKLIGHT_CLASS_DEVICE > + select BACKLIGHT_LCD_SUPPORT > + default y > help > This driver implements the ACPI Extensions For Display Adapters > for int

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

nd not break either SMBus or > i915, we temporarily unmap the PCI device for the SMBus controller, > do the thing that the firmware wanted to do, then remap the device and > report a firmware bug. > > Signed-off-by: Lyude <ly...@redhat.com> > Cc: Rafael J. Wysocki <rafael.j.wy

Re: [Intel-gfx] [PATCH v2 3/5] ACPI / bus: Switch to use new generic UUID API

On Mon, Jun 5, 2017 at 6:20 PM, Andy Shevchenko wrote: > On Mon, 2017-06-05 at 18:03 +0200, Christoph Hellwig wrote: >> > + in_params[0].buffer.pointer = (u8 *) >> >> Any idea why the pointer is defined as a u8 * in union acpi_object >> instead of a void?

Re: [Intel-gfx] [PATCH v2 5/5] ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()

the conversion and it's safe to > get rid of it. Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> with one caveat. I have a pending patch that will use acpi_evaluate_dsm(), so I'd like this to be made available in an immutable branch once

Re: [Intel-gfx] [PATCH v2 3/5] ACPI / bus: Switch to use new generic UUID API

ko <andriy.shevche...@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

ver's system suspend handlers which effectively disables > the optimization. > > Needed by the next patch fixing suspend/resume on i915. > > Suggested by Rafael. > > v2-v3: > - unchanged > > v4: > - Move the flag to dev_flags instead of using a bit field. (Rafael

Re: [Intel-gfx] [PATCH v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

On Tuesday, May 02, 2017 12:05:38 PM Imre Deak wrote: > On Mon, May 01, 2017 at 10:36:13PM +0200, Rafael J. Wysocki wrote: > > On Sunday, April 30, 2017 03:57:13 PM Imre Deak wrote: > > > On Sat, Apr 29, 2017 at 12:21:57PM +0200, Rafael J. Wysocki wrote: > > > > On F

Re: [Intel-gfx] [PATCH v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

On Sunday, April 30, 2017 03:57:13 PM Imre Deak wrote: > On Sat, Apr 29, 2017 at 12:21:57PM +0200, Rafael J. Wysocki wrote: > > On Friday, April 28, 2017 11:33:02 PM Rafael J. Wysocki wrote: > > > On Friday, April 28, 2017 05:16:02 PM Imre Deak wrote: > > > >

Re: [Intel-gfx] [PATCH v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

On Friday, April 28, 2017 11:33:02 PM Rafael J. Wysocki wrote: > On Friday, April 28, 2017 05:16:02 PM Imre Deak wrote: > > Some drivers - like i915 - may not support the system suspend direct > > complete optimization due to differences in their runtime and system > > suspend

Re: [Intel-gfx] [PATCH v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

ver's system suspend handlers which effectively disables > the optimization. > > Needed by the next patch fixing suspend/resume on i915. > > Suggested by Rafael. > > Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com> > Cc: Bjorn Helgaas <bhelg...@google.c

Re: [Intel-gfx] [PATCH v8 1/2] ACPI / bus: Introduce a list of ids for "always present" devices

On Friday, April 21, 2017 01:43:51 PM Hans de Goede wrote: > Hi, > > On 21-04-17 13:38, Andy Shevchenko wrote: > > On Fri, 2017-04-21 at 12:47 +0200, Hans de Goede wrote: > >> Several Bay / Cherry Trail devices (all of which ship with Windows 10) > >> hide > >> the LPSS PWM controller in ACPI,

Re: [Intel-gfx] [PATCH v2 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

On Monday, April 24, 2017 10:42:42 PM Lukas Wunner wrote: > On Mon, Apr 24, 2017 at 10:02:30PM +0200, Lukas Wunner wrote: > > On Mon, Apr 24, 2017 at 05:27:42PM +0300, Imre Deak wrote: > > > Some drivers - like i915 - may not support the system suspend direct > > > complete optimization due to

Re: [Intel-gfx] [PATCH v7 1/2] ACPI / bus: Introduce a list of ids for "always present" devices

On Friday, April 21, 2017 12:42:31 PM Hans de Goede wrote: > HI, > [cut] > >>> And in that path, which I seem to have overlooked before, the > >>> acpi_set_device_status() call is too early for invoking > >>> acpi_device_always_present(adev), so the latter should be called > >>> directly from

Re: [Intel-gfx] [PATCH v7 1/2] ACPI / bus: Introduce a list of ids for "always present" devices

On Friday, April 21, 2017 11:59:34 AM Hans de Goede wrote: > Hi, > > On 19-04-17 22:14, Rafael J. Wysocki wrote: > > On Wed, Apr 19, 2017 at 2:04 PM, Hans de Goede <hdego...@redhat.com> wrote: > >> Several Bay / Cherry Trail devices (all of which ship with Wind

Re: [Intel-gfx] [PATCH v7 1/2] ACPI / bus: Introduce a list of ids for "always present" devices

On Wed, Apr 19, 2017 at 2:04 PM, Hans de Goede wrote: > Several Bay / Cherry Trail devices (all of which ship with Windows 10) hide > the LPSS PWM controller in ACPI, typically the _STA method looks like this: > > Method (_STA, 0, NotSerialized) // _STA: Status > { >

Re: [Intel-gfx] [PATCH v6 1/3] ACPI / bus: Introduce a list of ids for "always present" devices

On Wed, Apr 19, 2017 at 6:17 PM, Lukas Wunner <lu...@wunner.de> wrote: > On Wed, Apr 19, 2017 at 12:28:50PM +0200, Rafael J. Wysocki wrote: >> On Wed, Apr 19, 2017 at 10:59 AM, Hans de Goede <hdego...@redhat.com> wrote: >> > On 18-04-17 15:34, Rafael J. Wysocki wro

Re: [Intel-gfx] [PATCH v6 1/3] ACPI / bus: Introduce a list of ids for "always present" devices

On Wed, Apr 19, 2017 at 10:59 AM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > > On 18-04-17 15:34, Rafael J. Wysocki wrote: >> >> On Tue, Apr 18, 2017 at 1:54 PM, Hans de Goede <hdego...@redhat.com> >> wrote: >>> >>> Several C

Re: [Intel-gfx] [PATCH v6 1/3] ACPI / bus: Introduce a list of ids for "always present" devices

On Tue, Apr 18, 2017 at 1:54 PM, Hans de Goede wrote: > Several Cherry Trail devices (all of which ship with Windows 10) hide the > LPSS PWM controller in ACPI, typically the _STA method looks like this: > > Method (_STA, 0, NotSerialized) // _STA: Status > { >

Re: [Intel-gfx] [PATCH] drm/i915: Prevent the system suspend complete optimization

Hi, First off, sorry for introducing the problem and thanks for taking care of it! On 4/11/2017 7:09 PM, Imre Deak wrote: On Tue, Apr 11, 2017 at 05:54:07PM +0100, Chris Wilson wrote: On Tue, Apr 11, 2017 at 07:12:35PM +0300, Imre Deak wrote: +static int i915_pm_prepare(struct device

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

On Mon, Feb 27, 2017 at 10:58 PM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > > On 27-02-17 22:49, Rafael J. Wysocki wrote: >> >> On Mon, Feb 27, 2017 at 10:29 PM, Hans de Goede <hdego...@redhat.com> >> wrote: >>> >>>

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

On Mon, Feb 27, 2017 at 10:29 PM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > > On 27-02-17 22:25, Rafael J. Wysocki wrote: >> >> On Mon, Feb 27, 2017 at 3:25 PM, Hans de Goede <hdego...@redhat.com> >> wrote: >>> >>>

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

On Mon, Feb 27, 2017 at 3:40 PM, Takashi Iwai <ti...@suse.de> wrote: > On Mon, 27 Feb 2017 15:25:32 +0100, > Hans de Goede wrote: >> >> Hi, >> >> On 27-02-17 14:30, Rafael J. Wysocki wrote: >> > +Mika & Andy >> > >> > On Saturda

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

On Mon, Feb 27, 2017 at 3:25 PM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > > On 27-02-17 14:30, Rafael J. Wysocki wrote: >> >> +Mika & Andy >> >> On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote: >>> >>> Seve

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

+Mika & Andy On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote: > Several cherrytrail devices (all of which ship with windows 10) hide the > lpss pwm controller in ACPI, typically the _STA method looks like this: > > Method (_STA, 0, NotSerialized) // _STA: Status > { >

[Intel-gfx] [PATCH] PM / runtime: Avoid false-positive warnings from might_sleep_if()

On Thursday, February 02, 2017 02:34:42 PM Sedat Dilek wrote: > On Wed, Feb 1, 2017 at 1:22 AM, Rafael J. Wysocki <raf...@kernel.org> wrote: > > On Mon, Jan 30, 2017 at 11:44 PM, Rafael J. Wysocki > > <rafael.j.wyso...@intel.com> wrote: > >> On

Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Mon, Jan 30, 2017 at 11:44 PM, Rafael J. Wysocki <rafael.j.wyso...@intel.com> wrote: > On 1/24/2017 2:33 AM, Sedat Dilek wrote: >> >> On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki <raf...@kernel.org> >> wrote: >>> >>> On Fri, Dec 30, 2

Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On 1/31/2017 1:02 PM, Imre Deak wrote: On Tue, Jan 31, 2017 at 12:39:35PM +0100, Rafael J. Wysocki wrote: On 1/31/2017 11:58 AM, Imre Deak wrote: Hi Rafael, Hi, On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote: On 1/24/2017 2:33 AM, Sedat Dilek wrote: On Fri, Dec 30, 2016

Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On 1/31/2017 11:58 AM, Imre Deak wrote: Hi Rafael, Hi, On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote: On 1/24/2017 2:33 AM, Sedat Dilek wrote: On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: On Fri, Dec 30, 2016 at 12:40 PM, Sedat

Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On 1/24/2017 2:33 AM, Sedat Dilek wrote: On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek <sedat.di...@gmail.com> wrote: Hi, I have already reported this issue in [1]. One of the issue was solved. U

Re: [Intel-gfx] [PATCH v2 3/3] acpi: lpss: call pwm_add_table() for bsw PWM device

On Mon, Jan 30, 2017 at 9:18 AM, Thierry Reding wrote: > On Sun, Jan 22, 2017 at 05:14:09PM +0100, Hans de Goede wrote: >> On x86 we do not have devicetree to link the PWM controller and >> the display controller together. So someone needs to call >> pwm_add_table() to

Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek wrote: > Hi, > > I have already reported this issue in [1]. > One of the issue was solved. > Unfortunately, it looks like there is still a different problem here > (Ubuntu/precise AMD64). > > I tried v4.10-rc1 and latest Linus

Re: [Intel-gfx] [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek wrote: > On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula wrote: >> On Wed, 28 Dec 2016, Sedat Dilek wrote: >>> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek wrote:

Re: [Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type

On Tuesday, January 19, 2016 05:31:04 PM Lukas Wunner wrote: > Hi Rafael, > > On Tue, Jan 19, 2016 at 12:59:13AM +0100, Rafael J. Wysocki wrote: > > On Tuesday, January 19, 2016 12:00:47 AM Lukas Wunner wrote: > > > Hi, > > > > > > On Mon, Jan 18, 2

Re: [Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type

On Monday, January 18, 2016 02:31:00 PM Ankitprasad Sharma wrote: > On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote: > > On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sha...@intel.com > > wrote: > > > From: Ankitprasad Sharma <ankitprasad.r.sha...@i

Re: [Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type

On Tuesday, January 19, 2016 12:00:47 AM Lukas Wunner wrote: > Hi, > > On Mon, Jan 18, 2016 at 11:46:18PM +0100, Rafael J. Wysocki wrote: > > On Monday, January 18, 2016 11:39:07 PM Lukas Wunner wrote: [cut] > > > > > If you want to check if the device

  1   2   3   >