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 +++
> include/acpi/acpi_bus.h | 1 +
> include/linux/acpi.h| 5 +
> 3 files changed, 17 insertions(+)
>
> diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
> index 682edd913b3b..4cb061d3169a 100644
> --- a/drivers/acpi/utils.c
> +++ b/drivers/acpi/utils.c
> @@ -872,6 +872,17 @@ acpi_dev_get_first_match_dev(const char *hid, const char
> *uid, s64 hrv)
> }
> EXPORT_SYMBOL(acpi_dev_get_first_match_dev);
>
> +/**
> + * acpi_reduced_hardware - Return if this is an ACPI-reduced-hw machine
> + *
> + * Return true when running on an ACPI-reduced-hw machine, false otherwise.
> + */
> +bool acpi_reduced_hardware(void)
> +{
> + return acpi_gbl_reduced_hardware;
> +}
> +EXPORT_SYMBOL(acpi_reduced_hardware);
EXPORT_SYMBOL_GPL()?
> +
> /*
> * acpi_backlight= handling, this is done here rather then in video_detect.c
> * because __setup cannot be used in modules.
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index f28b097c658f..d631cb52283e 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -78,6 +78,7 @@ acpi_evaluate_dsm_typed(acpi_handle handle, const guid_t
> *guid, u64 rev,
>
> bool acpi_dev_found(const char *hid);
> bool acpi_dev_present(const char *hid, const char *uid, s64 hrv);
> +bool acpi_reduced_hardware(void);
>
> #ifdef CONFIG_ACPI
>
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 3bdcfc4401b7..e2e6db8313c8 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -748,6 +748,11 @@ acpi_dev_get_first_match_dev(const char *hid, const char
> *uid, s64 hrv)
> return NULL;
> }
>
> +static inline bool acpi_reduced_hardware(void)
> +{
> + return false;
> +}
> +
> static inline void acpi_dev_put(struct acpi_device *adev) {}
>
> static inline bool is_acpi_node(const struct fwnode_handle *fwnode)
> --
> 2.30.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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
> >> 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 +++
> >> include/acpi/acpi_bus.h | 1 +
> >> include/linux/acpi.h| 5 +
> >> 3 files changed, 17 insertions(+)
> >>
> >> diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
> >> index 682edd913b3b..4cb061d3169a 100644
> >> --- a/drivers/acpi/utils.c
> >> +++ b/drivers/acpi/utils.c
> >> @@ -872,6 +872,17 @@ acpi_dev_get_first_match_dev(const char *hid, const
> >> char *uid, s64 hrv)
> >> }
> >> EXPORT_SYMBOL(acpi_dev_get_first_match_dev);
> >>
> >> +/**
> >> + * acpi_reduced_hardware - Return if this is an ACPI-reduced-hw machine
> >> + *
> >> + * Return true when running on an ACPI-reduced-hw machine, false
> >> otherwise.
> >> + */
> >> +bool acpi_reduced_hardware(void)
> >> +{
> >> + return acpi_gbl_reduced_hardware;
> >> +}
> >> +EXPORT_SYMBOL(acpi_reduced_hardware);
> >
> > EXPORT_SYMBOL_GPL()?
>
> Yes, that was my intention, no idea what happened here.
>
> Before I send a v2, do you have any remarks on patch 2/2 (which is actually
> the more interesting patch) ?
I thought that basing that check on the ACPICA's global variable may
be too coarse grained for some cases, but then I've decided to do it
as is now and we'll see.
No need to resend that one.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 EXPORT_SYMBOL
> ---
> drivers/acpi/utils.c| 11 +++
> include/acpi/acpi_bus.h | 1 +
> include/linux/acpi.h| 5 +
> 3 files changed, 17 insertions(+)
>
> diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
> index 682edd913b3b..b20774c48c74 100644
> --- a/drivers/acpi/utils.c
> +++ b/drivers/acpi/utils.c
> @@ -872,6 +872,17 @@ acpi_dev_get_first_match_dev(const char *hid, const char
> *uid, s64 hrv)
> }
> EXPORT_SYMBOL(acpi_dev_get_first_match_dev);
>
> +/**
> + * acpi_reduced_hardware - Return if this is an ACPI-reduced-hw machine
> + *
> + * Return true when running on an ACPI-reduced-hw machine, false otherwise.
> + */
> +bool acpi_reduced_hardware(void)
> +{
> + return acpi_gbl_reduced_hardware;
> +}
> +EXPORT_SYMBOL_GPL(acpi_reduced_hardware);
> +
> /*
> * acpi_backlight= handling, this is done here rather then in video_detect.c
> * because __setup cannot be used in modules.
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index f28b097c658f..d631cb52283e 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -78,6 +78,7 @@ acpi_evaluate_dsm_typed(acpi_handle handle, const guid_t
> *guid, u64 rev,
>
> bool acpi_dev_found(const char *hid);
> bool acpi_dev_present(const char *hid, const char *uid, s64 hrv);
> +bool acpi_reduced_hardware(void);
>
> #ifdef CONFIG_ACPI
>
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 3bdcfc4401b7..e2e6db8313c8 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -748,6 +748,11 @@ acpi_dev_get_first_match_dev(const char *hid, const char
> *uid, s64 hrv)
> return NULL;
> }
>
> +static inline bool acpi_reduced_hardware(void)
> +{
> + return false;
> +}
> +
> static inline void acpi_dev_put(struct acpi_device *adev) {}
>
> static inline bool is_acpi_node(const struct fwnode_handle *fwnode)
> --
Applied along with the [2/2] as 5.13 material, thanks!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 worst case we report one wrong sample, > > >> which I guess is still not ideal since someone could be querying the PMU > > >> with quite low frequency. > > >> > > >> There are tests which probably can hit this, but to run them > > >> automatically your patches would need to be rebased on drm-tip and maybe > > >> sent to our trybot. I can do that after the holiday break if you are > > >> okay with having the series waiting until then. > > > > > > yes looks good to me > > > > Looks good to me as well. And our CI agrees with it. So: > > > > Reviewed-by: Tvrtko Ursulin > > Thanks for the review and the test > > > > > I assume you will take the patch through some power related tree and we > > will eventually pull it back to drm-tip. > > Rafael, > How do you want to proceed with this patch and the 2 others of the serie ? I'm going to queue up the whole series for 5.1. Thanks! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 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 worst case we report one wrong sample, > > > >> which I guess is still not ideal since someone could be querying the > > > >> PMU > > > >> with quite low frequency. > > > >> > > > >> There are tests which probably can hit this, but to run them > > > >> automatically your patches would need to be rebased on drm-tip and > > > >> maybe > > > >> sent to our trybot. I can do that after the holiday break if you are > > > >> okay with having the series waiting until then. > > > > > > > > yes looks good to me > > > > > > Looks good to me as well. And our CI agrees with it. So: > > > > > > Reviewed-by: Tvrtko Ursulin > > > > Thanks for the review and the test > > > > > > > > I assume you will take the patch through some power related tree and we > > > will eventually pull it back to drm-tip. > > > > Rafael, > > How do you want to proceed with this patch and the 2 others of the serie ? > > I'm going to queue up the whole series for 5.1. And it has been queued up now, thanks! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 the
> > runtime debug counters inline with genpd and other pm subsytems which
> > uses ktime based accounting.
> >
> > timekeeping is initialized before pm_runtime_init() so ktime_get() will
> > be ready before first call. In fact, timekeeping_init() is called early
> > in start_kernel() which is way before driver_init() (and that's when
> > devices can start to be initialized) called from rest_init() via
> > kernel_init_freeable() and do_basic_setup().
> >
> This is not (always) correct. My qemu "collie" boot test fails with this
> patch applied. Reverting the patch fixes the problem. Bisect log attached.
>
> With some added debugging:
>
> ...
> IRQS: 16, nr_irqs: 65, preallocated irqs: 65
> irq: Cannot allocate irq_descs @ IRQ1, assuming pre-allocated
> gpio gpiochip0: ### pm_runtime_init()
> irq: Cannot allocate irq_descs @ IRQ33, assuming pre-allocated
> ## timekeeping_init()
> sched_clock: 32 bits at 3686kHz, resolution 271ns, wraps every
> 58254200ns^M
> ...
>
> This is with:
>
> void pm_runtime_init(struct device *dev)
> {
> + dev_info(dev, "### pm_runtime_init() \n");
> +
> ...
> @@ -1526,6 +1526,8 @@ void __init timekeeping_init(void)
> struct clocksource *clock;
> unsigned long flags;
>
> + pr_info("## timekeeping_init() \n");
> +
>
> Guenter
>
> ---
> # bad: [a37d50ca3b837c19a297f349365d11a20c1087d0] Add linux-next specific
> files for 20190117
> # good: [1c7fc5cbc33980acd13d668f1c8f0313d6ae9fd8] Linux 5.0-rc2
> git bisect start 'HEAD' 'v5.0-rc2'
> # bad: [4edb817d29fdf19fb5d52784bb3c29c40e00f586] Merge remote-tracking
> branch 'pm/linux-next'
> git bisect bad 4edb817d29fdf19fb5d52784bb3c29c40e00f586
> # good: [6d95886720d306a1914a7c9a8aeb0bcbc7aef018] Merge remote-tracking
> branch 'omap/for-next'
> git bisect good 6d95886720d306a1914a7c9a8aeb0bcbc7aef018
> # good: [975b5cdd74430bc8a04f832d65a47cdb95b73fec] Merge remote-tracking
> branch 'fuse/for-next'
> git bisect good 975b5cdd74430bc8a04f832d65a47cdb95b73fec
> # good: [112386d2189fc54b979c3a8bf64b2908df91e123] Merge remote-tracking
> branch 'i2c/i2c/for-next'
> git bisect good 112386d2189fc54b979c3a8bf64b2908df91e123
> # good: [3943f059823b6e15884387f31618b84826e924b3] media: coda: Add control
> for h.264 chroma qp index offset
> git bisect good 3943f059823b6e15884387f31618b84826e924b3
> # good: [44970b5079ee100875b06e45db5d6e91a16e] Merge remote-tracking
> branch 'v4l-dvb/master'
> git bisect good 44970b5079ee100875b06e45db5d6e91a16e
> # bad: [599170c2b860aca3364574f833bb9cc801c9668d] Merge branch 'pm-core' into
> linux-next
> git bisect bad 599170c2b860aca3364574f833bb9cc801c9668d
> # good: [347d570919ca9a3a3653ce9cbb7399c7c0ba8248] Merge branch 'acpi-pci'
> into linux-next
> git bisect good 347d570919ca9a3a3653ce9cbb7399c7c0ba8248
> # good: [e0a9fde86ba1bc26dd754c733b32e70cd8f1c187] Merge branches
> 'acpi-tables' and 'acpi-apei' into linux-next
> git bisect good e0a9fde86ba1bc26dd754c733b32e70cd8f1c187
> # good: [3b4ed2e2eb5583774a1ed4aa4596a5a3c55f2567] drm/i915: Move on the new
> pm runtime interface
> git bisect good 3b4ed2e2eb5583774a1ed4aa4596a5a3c55f2567
> # bad: [c75c303933a68c547f3352d1d708843f9449d3f4] PM: clock_ops: fix missing
> clk_prepare() return value check
> git bisect bad c75c303933a68c547f3352d1d708843f9449d3f4
> # bad: [3982ab9ce433efc72ca31eb9ddc85d9355966444] PM-runtime: Replace jiffies
> based accounting with ktime-based accounting
> git bisect bad 3982ab9ce433efc72ca31eb9ddc85d9355966444
> # first bad commit: [3982ab9ce433efc72ca31eb9ddc85d9355966444] PM-runtime:
> Replace jiffies based accounting with ktime-based accounting
OK, dropping this one for now, we need a working replacement.
Thanks!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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: Thara Gopinath > > > > > > > > This patch replaces jiffies based accounting for runtime_active_time > > > > and runtime_suspended_time with ktime base accounting. This makes the > > > > runtime debug counters inline with genpd and other pm subsytems which > > > > uses ktime based accounting. > > > > > > > > timekeeping is initialized before pm_runtime_init() so ktime_get() will > > > > be ready before first call. In fact, timekeeping_init() is called early > > > > in start_kernel() which is way before driver_init() (and that's when > > > > devices can start to be initialized) called from rest_init() via > > > > kernel_init_freeable() and do_basic_setup(). > > > > > > > This is not (always) correct. My qemu "collie" boot test fails with this > > > patch applied. Reverting the patch fixes the problem. Bisect log attached. > > > > > > > Can you try the patch below ? > > ktime_get_mono_fast_ns() has the advantage of being init with dummy clock so > > it can be used at early_init. > > Another possibility would be delay the init of the gpiochip Well, right. Initializing devices before timekeeping doesn't feel particularly robust from the design perspective. How exactly does that happen? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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: > > >> > > >> 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: Thara Gopinath > > >>>>> > > >>>>> This patch replaces jiffies based accounting for runtime_active_time > > >>>>> and runtime_suspended_time with ktime base accounting. This makes the > > >>>>> runtime debug counters inline with genpd and other pm subsytems which > > >>>>> uses ktime based accounting. > > >>>>> > > >>>>> timekeeping is initialized before pm_runtime_init() so ktime_get() > > >>>>> will > > >>>>> be ready before first call. In fact, timekeeping_init() is called > > >>>>> early > > >>>>> in start_kernel() which is way before driver_init() (and that's when > > >>>>> devices can start to be initialized) called from rest_init() via > > >>>>> kernel_init_freeable() and do_basic_setup(). > > >>>>> > > >>>> This is not (always) correct. My qemu "collie" boot test fails with > > >>>> this > > >>>> patch applied. Reverting the patch fixes the problem. Bisect log > > >>>> attached. > > >>>> > > >>> > > >>> Can you try the patch below ? > > >>> ktime_get_mono_fast_ns() has the advantage of being init with dummy > > >>> clock so > > >>> it can be used at early_init. > > >> > > >> Another possibility would be delay the init of the gpiochip > > > > > > Well, right. > > > > > > Initializing devices before timekeeping doesn't feel particularly > > > robust from the design perspective. > > > > > > How exactly does that happen? > > > > > > > With an added 'initialized' flag and backtrace into the timekeeping code, > > with the change suggested earlier applied: > > > > [ cut here ] > > WARNING: CPU: 0 PID: 0 at kernel/time/timekeeping.c:453 > > ktime_get_mono_fast_ns+0x114/0x12c > > Timekeeping not initialized > > CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc2-next-20190117-dirty #2 > > Hardware name: Sharp-Collie > > Backtrace: > > [] (dump_backtrace) from [] (show_stack+0x18/0x1c) > > r7:0009 r6: r5:c065ba90 r4:c06d3e54 > > [] (show_stack) from [] (dump_stack+0x20/0x28) > > [] (dump_stack) from [] (__warn+0xcc/0xf4) > > [] (__warn) from [] (warn_slowpath_fmt+0x4c/0x6c) > > r8:df407b08 r7: r6:c0c01550 r5:c065bad8 r4:c06dd028 > > [] (warn_slowpath_fmt) from [] > > (ktime_get_mono_fast_ns+0x114/0x12c) > > r3: r2:c065bad8 > > r5: r4:df407b08 > > [] (ktime_get_mono_fast_ns) from [] > > (pm_runtime_init+0x38/0xb8) > > r9:c06c9a5c r8:df407b08 r7: r6:c0c01550 r5: r4:df407b08 > > [] (pm_runtime_init) from [] > > (device_initialize+0xb0/0xec) > > r7: r6:c0c01550 r5: r4:df407b08 > > [] (device_initialize) from [] > > (gpiochip_add_data_with_key+0x9c/0x884) > > r7: r6:c06fca34 r5: r4: > > [] (gpiochip_add_data_with_key) from [] > > (sa1100_init_gpio+0x40/0x98) > > r10:dfffcd60 r9:c06c9a5c r8:c06dd020 r7:c06dd028 r6: r5: > > r4:c06fca34 > > [] (sa1100_init_gpio) from [] > > (sa1100_init_irq+0x2c/0x3c) > > r7:c06dd028 r6: r5:c0713300 r4:c06e1070 > > [] (sa1100_init_irq) from [] (init_IRQ+0x20/0x28) > > r5:c0713300 r4: > > [] (init_IRQ) from [] (start_kernel+0x254/0x4cc) > > [] (start_kernel) from [<>] ( (null)) > > r10:717f r9:6901b119 r8:c100 r7:0092 r6:313d r5:0053 > > r4:c06a7330 > > ---[ end trace 91e1bd00dd7cce32 ]--- > > Does it means that only the pm_runtime_init is done before > timekeeping_init() but no update_pm_runtime_accounting() ? This platform calls device_initialize(), via sa1100_init_irq(), from init_IRQ() which is in the start_kernel() code path before timekeeping_init(). That's the initialization of structure fields alone. Runtime PM really cannot be used legitimately before driver_init(), because it needs bus types to be there at least. > In this case, we can keep using ktimeçget in > update_pm_runtime_accounting() and find a solution to deal with > early_call of pm_runtime_init() Given the above, I think that initializing accounting_timestamp in pm_runtime_init() to anything different from 0 is a mistake. Note that update_pm_runtime_accounting() ignores the delta value if power.disable_depth is not zero anyway, so it really should be sufficient to update accounting_timestamp when enabling runtime PM - and I'm not sure why it is not updated in pm_runtime_enable() for that matter (that looks like a bug to me). ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 disable ACPI idle
driver for Core-for-CI, only for ICL.
This hacky patch is only for ICL processor and for Core-for-CI branch.
v2: Fixed compilation errors raised by lkp.
commit message improvement.
Cc: martin.pe...@intel.com
Cc: daniel.vet...@intel.com
Signed-off-by: Anshuman Gupta
This is fine only as long as it doesn't anywhere close to the mainline.
If ACPI idle crashes on new Intel HW, it needs to be fixed to work with
it instead of refusing to work on it.
---
drivers/acpi/processor_driver.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 9d6aff2..ee842a2f 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -35,6 +35,12 @@
#include
+/* Only for Core-for-CI so don't want ia64 to fail compilation.*/
+#ifdef CONFIG_X86
+#include
+#include
+#endif
+
#include "internal.h"
#define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80
@@ -58,6 +64,13 @@ static const struct acpi_device_id processor_device_ids[] = {
};
MODULE_DEVICE_TABLE(acpi, processor_device_ids);
+#define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
+static const struct x86_cpu_id intel_cpu_ids[] = {
+ ICPU(INTEL_FAM6_ICELAKE_MOBILE),/* ICL */
+ {}
+};
+MODULE_DEVICE_TABLE(x86cpu, intel_cpu_ids);
+
static struct device_driver acpi_processor_driver = {
.name = "processor",
.bus = &cpu_subsys,
@@ -226,6 +239,7 @@ static inline void acpi_pss_perf_exit(struct acpi_processor
*pr,
static int __acpi_processor_start(struct acpi_device *device)
{
struct acpi_processor *pr = acpi_driver_data(device);
+ const struct x86_cpu_id *id;
acpi_status status;
int result = 0;
@@ -239,7 +253,9 @@ static int __acpi_processor_start(struct acpi_device *device)
if (result && !IS_ENABLED(CONFIG_ACPI_CPU_FREQ_PSS))
dev_dbg(&device->dev, "CPPC data invalid or not present\n");
- if (!cpuidle_get_driver() || cpuidle_get_driver() == &acpi_idle_driver)
+ id = x86_match_cpu(intel_cpu_ids);
+ if (!id && (!cpuidle_get_driver() || cpuidle_get_driver() ==
+ &acpi_idle_driver))
acpi_processor_power_init(pr);
result = acpi_pss_perf_init(pr, device);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] components: multiple components for a device
) On Wed, Feb 6, 2019 at 5:46 PM Daniel Vetter wrote:
>
> Component framework is extended to support multiple components for
> a struct device. These will be matched with different masters based on
> its sub component value.
>
> We are introducing this, as I915 needs two different components
> with different subcomponent value, which will be matched to two
> different component masters(Audio and HDCP) based on the subcomponent
> values.
>
> v2: Add documenation.
>
> v3: Rebase on top of updated documenation.
>
> Signed-off-by: Daniel Vetter (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
> Signed-off-by: Daniel Vetter
> ---
> drivers/base/component.c | 160 +-
> include/linux/component.h | 9 ++-
> 2 files changed, 129 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/base/component.c b/drivers/base/component.c
> index f34d4b784709..68ccd5a0d5d6 100644
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -47,6 +47,7 @@ struct component;
> struct component_match_array {
> void *data;
> int (*compare)(struct device *, void *);
> + int (*compare_typed)(struct device *, int, void *);
> void (*release)(struct device *, void *);
> struct component *component;
> bool duplicate;
> @@ -74,6 +75,7 @@ struct component {
> bool bound;
>
> const struct component_ops *ops;
> + int subcomponent;
> struct device *dev;
> };
>
> @@ -158,7 +160,7 @@ static struct master *__master_find(struct device *dev,
> }
>
> static struct component *find_component(struct master *master,
> - int (*compare)(struct device *, void *), void *compare_data)
> + struct component_match_array *mc)
> {
> struct component *c;
>
> @@ -166,8 +168,13 @@ static struct component *find_component(struct master
> *master,
> if (c->master && c->master != master)
> continue;
>
> - if (compare(c->dev, compare_data))
> + if (mc->compare_typed) {
> + if (mc->compare_typed(c->dev, c->subcomponent,
> + mc->data))
This line break looks kind of weird to me,
> + return c;
> + } else if (mc->compare(c->dev, mc->data)) {
> return c;
> + }
Also, why don't you do
if (mc->compare(c->dev, mc->data) || (mc->compare_typed &&
mc->compare_typed(c->dev, c->subcomponent, mc->data)))
return c;
The only difference is that ->compare() will run first and if it finds
a match, c will be returned right away. Does it matter?
> }
>
> return NULL;
> @@ -192,7 +199,7 @@ static int find_components(struct master *master)
> if (match->compare[i].component)
> continue;
>
> - c = find_component(master, mc->compare, mc->data);
> + c = find_component(master, mc);
> if (!c) {
> ret = -ENXIO;
> break;
> @@ -327,30 +334,12 @@ static int component_match_realloc(struct device *dev,
> return 0;
> }
>
> -/**
> - * component_match_add_release - add a component match with release callback
> - * @master: device with the aggregate driver
> - * @matchptr: pointer to the list of component matches
> - * @release: release function for @compare_data
> - * @compare: compare function to match against all components
> - * @compare_data: opaque pointer passed to the @compare function
> - *
> - * This adds a new component match to the list stored in @matchptr, which the
"This" appears to be redundant here (and in some places below too).
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 components for
> > > a struct device. These will be matched with different masters based on
> > > its sub component value.
> > >
> > > We are introducing this, as I915 needs two different components
> > > with different subcomponent value, which will be matched to two
> > > different component masters(Audio and HDCP) based on the subcomponent
> > > values.
> > >
> > > v2: Add documenation.
> > >
> > > v3: Rebase on top of updated documenation.
> > >
> > > Signed-off-by: Daniel Vetter (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
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/base/component.c | 160 +-
> > > include/linux/component.h | 9 ++-
> > > 2 files changed, 129 insertions(+), 40 deletions(-)
> > >
> > > diff --git a/drivers/base/component.c b/drivers/base/component.c
> > > index f34d4b784709..68ccd5a0d5d6 100644
> > > --- a/drivers/base/component.c
> > > +++ b/drivers/base/component.c
> > > @@ -47,6 +47,7 @@ struct component;
> > > struct component_match_array {
> > > void *data;
> > > int (*compare)(struct device *, void *);
> > > + int (*compare_typed)(struct device *, int, void *);
> > > void (*release)(struct device *, void *);
> > > struct component *component;
> > > bool duplicate;
> > > @@ -74,6 +75,7 @@ struct component {
> > > bool bound;
> > >
> > > const struct component_ops *ops;
> > > + int subcomponent;
> > > struct device *dev;
> > > };
> > >
> > > @@ -158,7 +160,7 @@ static struct master *__master_find(struct device
> > > *dev,
> > > }
> > >
> > > static struct component *find_component(struct master *master,
> > > - int (*compare)(struct device *, void *), void *compare_data)
> > > + struct component_match_array *mc)
> > > {
> > > struct component *c;
> > >
> > > @@ -166,8 +168,13 @@ static struct component *find_component(struct
> > > master *master,
> > > if (c->master && c->master != master)
> > > continue;
> > >
> > > - if (compare(c->dev, compare_data))
> > > + if (mc->compare_typed) {
> > > + if (mc->compare_typed(c->dev, c->subcomponent,
> > > + mc->data))
> >
> > This line break looks kind of weird to me,
> >
> > > + return c;
> > > + } else if (mc->compare(c->dev, mc->data)) {
> > > return c;
> > > + }
> >
> > Also, why don't you do
> >
> > if (mc->compare(c->dev, mc->data) || (mc->compare_typed &&
> > mc->compare_typed(c->dev, c->subcomponent, mc->data)))
> > return c;
> >
> > The only difference is that ->compare() will run first and if it finds
> > a match, c will be returned right away. Does it matter?
>
> Tried it, yes it does matter: We have either ->compare or ->compare_typed,
Well, that's not obvious. :-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] components: multiple components for a device
On Fri, Feb 8, 2019 at 12:28 AM Daniel Vetter wrote:
>
> Component framework is extended to support multiple components for
> a struct device. These will be matched with different masters based on
> its sub component value.
>
> We are introducing this, as I915 needs two different components
> with different subcomponent value, which will be matched to two
> different component masters(Audio and HDCP) based on the subcomponent
> values.
>
> v2: Add documenation.
>
> v3: Rebase on top of updated documenation.
>
> v4: Review from Rafael:
> - 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: Russell King
> Cc: Rafael J. Wysocki
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Signed-off-by: Daniel Vetter
Reviewed-by: Rafael J. Wysocki
> ---
> drivers/base/component.c | 158 +-
> include/linux/component.h | 10 ++-
> 2 files changed, 129 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/base/component.c b/drivers/base/component.c
> index 1624c2a892a5..7dbc41cccd58 100644
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -47,6 +47,7 @@ struct component;
> struct component_match_array {
> void *data;
> int (*compare)(struct device *, void *);
> + int (*compare_typed)(struct device *, int, void *);
> void (*release)(struct device *, void *);
> struct component *component;
> bool duplicate;
> @@ -74,6 +75,7 @@ struct component {
> bool bound;
>
> const struct component_ops *ops;
> + int subcomponent;
> struct device *dev;
> };
>
> @@ -158,7 +160,7 @@ static struct master *__master_find(struct device *dev,
> }
>
> static struct component *find_component(struct master *master,
> - int (*compare)(struct device *, void *), void *compare_data)
> + struct component_match_array *mc)
> {
> struct component *c;
>
> @@ -166,7 +168,11 @@ static struct component *find_component(struct master
> *master,
> if (c->master && c->master != master)
> continue;
>
> - if (compare(c->dev, compare_data))
> + if (mc->compare && mc->compare(c->dev, mc->data))
> + return c;
> +
> + if (mc->compare_typed &&
> + mc->compare_typed(c->dev, c->subcomponent, mc->data))
> return c;
> }
>
> @@ -192,7 +198,7 @@ static int find_components(struct master *master)
> if (match->compare[i].component)
> continue;
>
> - c = find_component(master, mc->compare, mc->data);
> + c = find_component(master, mc);
> if (!c) {
> ret = -ENXIO;
> break;
> @@ -327,29 +333,12 @@ static int component_match_realloc(struct device *dev,
> return 0;
> }
>
> -/**
> - * component_match_add_release - add a component match with release callback
> - * @master: device with the aggregate driver
> - * @matchptr: pointer to the list of component matches
> - * @release: release function for @compare_data
> - * @compare: compare function to match against all components
> - * @compare_data: opaque pointer passed to the @compare function
> - *
> - * Adds a new component match to the list stored in @matchptr, which the
> @master
> - * aggregate driver needs to function. The list of component matches pointed
> to
> - * by @matchptr must be initialized to NULL before adding the first match.
> - *
> - * The allocated match list in @matchptr is automatically released using devm
> - * actions, where upon @release will be called to free any references held by
> - * @compare_data, e.g. when @compare_data is a &device_node that must be
> - * released with of_node_put().
> - *
> - * See also component_match_add().
> - */
> -void component_match_add_release(struct device *master,
> +static void __component_match_add(struct device *master,
> struct component_match **matchptr,
> void (*release)(struct device *, void *),
> - int (*compare)(struct device *, void *), void *compare_data)
> + int (*compare)(struct device *, void *),
> + int (*compare_typed)(struct device *, int, void *),
> + void *compare_data)
>
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 include) has been moved > > to the i915 VBT code now. > > > > I've dropped this from my local version of the patch. > > OK. > > > Note sure if you (Mika) are the right person to ask, but in the > > coverletter of v1 I suggested merging all 3 patches through the i915 tree > > since the drivers/acpi/pmic/intel_pmic* files typically do > > not see all that churn. If I can get an Ack from you or > > Rafael for that then I can push the version with the include > > dropped to drm-next (through drm-intel-next-queued) myself > > once the 3th patch also has been acked. > > I guess it is up to Rafael whether my ack is enough Yes, it is. :-) > but here it is for both patches, > > Acked-by: Mika Westerberg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 infrastructure.
> > >
> > > Signed-off-by: Vincent Guittot
> > > ---
> > > drivers/gpu/drm/i915/i915_pmu.c | 12 ++--
> > > drivers/gpu/drm/i915/i915_pmu.h | 4 ++--
> > > 2 files changed, 8 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> > > b/drivers/gpu/drm/i915/i915_pmu.c
> > > index d6c8f8f..cf6437d 100644
> > > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > > @@ -493,14 +493,14 @@ static u64 get_rc6(struct drm_i915_private *i915)
> > > */
> > > if (kdev->power.runtime_status == RPM_SUSPENDED) {
> > > if
> > > (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> > > - i915->pmu.suspended_jiffies_last =
> > > -
> > > kdev->power.suspended_jiffies;
> > > + i915->pmu.suspended_time_last =
> > > + kdev->power.suspended_time;
> > >
> >
> > Huh, so patch 2 introduces a complier error because of removing the
> > old fields. We can't have that.
>
> I agree
> The patch was mainly to raise discussion
OK, so patch [1/3] from this series should be applicable regardless, right?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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:
> > > >
> > > > 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 infrastructure.
> > > > >
> > > > > Signed-off-by: Vincent Guittot
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_pmu.c | 12 ++--
> > > > > drivers/gpu/drm/i915/i915_pmu.h | 4 ++--
> > > > > 2 files changed, 8 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> > > > > b/drivers/gpu/drm/i915/i915_pmu.c
> > > > > index d6c8f8f..cf6437d 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > > > > @@ -493,14 +493,14 @@ static u64 get_rc6(struct drm_i915_private
> > > > > *i915)
> > > > > */
> > > > > if (kdev->power.runtime_status == RPM_SUSPENDED) {
> > > > > if
> > > > > (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> > > > > - i915->pmu.suspended_jiffies_last =
> > > > > -
> > > > > kdev->power.suspended_jiffies;
> > > > > + i915->pmu.suspended_time_last =
> > > > > + kdev->power.suspended_time;
> > > > >
> > > >
> > > > Huh, so patch 2 introduces a complier error because of removing the
> > > > old fields. We can't have that.
> > >
> > > I agree
> > > The patch was mainly to raise discussion
> >
> > OK, so patch [1/3] from this series should be applicable regardless, right?
>
> Yes
OK, I'll queue it up, then.
Next time you do something like that please mark patches for
discussion in a series as [RFC] so it is all clear.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] sysfs: Disable lockdep for driver bind/unbind files
> 00 00 00 8b 05 aa f0 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d
> 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
> [12301.899273] RSP: 002b:7ffceafa6918 EFLAGS: 0246 ORIG_RAX:
> 0001
> [12301.899282] RAX: ffda RBX: 000d RCX:
> 7f452ac7f7a4
> [12301.899288] RDX: 000d RSI: 5612a1abf7c0 RDI:
> 0001
> [12301.899295] RBP: 5612a1abf7c0 R08: 000a 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 i2c already handle similar
"Looking" I suppose? ;-)
Apart from this LGTM, so
Reviewed-by: Rafael J. Wysocki
> 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
>
> sysfs: get rid of some lockdep false positives
>
> commit e9b526fe704812364bca07edd15eadeba163ebfb
> Author: Alexander Sverdlin
> Date: Fri May 17 14:56:35 2013 +0200
>
> i2c: suppress lockdep warning on delete_device
>
> Implement the same trick for driver bind/unbind.
>
> Cc: "Rafael J. Wysocki"
> Cc: Greg Kroah-Hartman
> Cc: Ramalingam C
> Cc: Arend van Spriel
> Cc: Andy Shevchenko
> Cc: Geert Uytterhoeven
> Cc: Bartosz Golaszewski
> Cc: Heikki Krogerus
> Cc: Vivek Gautam
> Cc: Joe Perches
> Signed-off-by: Daniel Vetter
> ---
> drivers/base/bus.c | 4 ++--
> include/linux/device.h | 4
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index 8bfd27ec73d6..5d2411b848cd 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -195,7 +195,7 @@ static ssize_t unbind_store(struct device_driver *drv,
> const char *buf,
> bus_put(bus);
> return err;
> }
> -static DRIVER_ATTR_WO(unbind);
> +static DRIVER_ATTR_IGNORE_LOCKDEP(unbind, S_IWUSR, NULL, unbind_store);
>
> /*
> * Manually attach a device to a driver.
> @@ -231,7 +231,7 @@ static ssize_t bind_store(struct device_driver *drv,
> const char *buf,
> bus_put(bus);
> return err;
> }
> -static DRIVER_ATTR_WO(bind);
> +static DRIVER_ATTR_IGNORE_LOCKDEP(bind, S_IWUSR, NULL, bind_store);
>
> static ssize_t show_drivers_autoprobe(struct bus_type *bus, char *buf)
> {
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 1b25c7a43f4c..d2cb1a6c5d95 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -326,6 +326,10 @@ struct driver_attribute {
> struct driver_attribute driver_attr_##_name = __ATTR_RO(_name)
> #define DRIVER_ATTR_WO(_name) \
> struct driver_attribute driver_attr_##_name = __ATTR_WO(_name)
> +#define DRIVER_ATTR_IGNORE_LOCKDEP(_name, _mode, _show, _store) \
> + struct driver_attribute driver_attr_##_name = \
> + __ATTR_IGNORE_LOCKDEP(_name, _mode, _show, _store)
> +
>
> extern int __must_check driver_create_file(struct device_driver *driver,
> const struct driver_attribute *attr);
> --
> 2.20.0.rc1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] sysfs: Disable lockdep for driver bind/unbind files
lock_sched_held+0x6f/0x80
> > [12301.899209] ? rcu_sync_lockdep_assert+0x29/0x50
> > [12301.899216] ? __sb_start_write+0x13c/0x1a0
> > [12301.899221] ? vfs_write+0x17f/0x1b0
> > [12301.899227] vfs_write+0xb9/0x1b0
> > [12301.899233] ksys_write+0x50/0xc0
> > [12301.899239] do_syscall_64+0x4b/0x180
> > [12301.899247] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > [12301.899253] RIP: 0033:0x7f452ac7f7a4
> > [12301.899259] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80
> > 00 00 00 00 8b 05 aa f0 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05
> > <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
> > [12301.899273] RSP: 002b:7ffceafa6918 EFLAGS: 0246 ORIG_RAX:
> > 0001
> > [12301.899282] RAX: ffda RBX: 000d RCX:
> > 7f452ac7f7a4
> > [12301.899288] RDX: 000d RSI: 5612a1abf7c0 RDI:
> > 0001
> > [12301.899295] RBP: 5612a1abf7c0 R08: 000a 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 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
> >
> > sysfs: get rid of some lockdep false positives
> >
> > commit e9b526fe704812364bca07edd15eadeba163ebfb
> > Author: Alexander Sverdlin
> > Date: Fri May 17 14:56:35 2013 +0200
> >
> > i2c: suppress lockdep warning on delete_device
> >
> > Implement the same trick for driver bind/unbind.
> >
> > Cc: "Rafael J. Wysocki"
> > Cc: Greg Kroah-Hartman
> > Cc: Ramalingam C
> > Cc: Arend van Spriel
> > Cc: Andy Shevchenko
> > Cc: Geert Uytterhoeven
> > Cc: Bartosz Golaszewski
> > Cc: Heikki Krogerus
> > Cc: Vivek Gautam
> > Cc: Joe Perches
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/base/bus.c | 4 ++--
> > include/linux/device.h | 4
> > 2 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> > index 8bfd27ec73d6..5d2411b848cd 100644
> > --- a/drivers/base/bus.c
> > +++ b/drivers/base/bus.c
> > @@ -195,7 +195,7 @@ static ssize_t unbind_store(struct device_driver *drv,
> > const char *buf,
> > bus_put(bus);
> > return err;
> > }
> > -static DRIVER_ATTR_WO(unbind);
> > +static DRIVER_ATTR_IGNORE_LOCKDEP(unbind, S_IWUSR, NULL, unbind_store);
> >
> > /*
> > * Manually attach a device to a driver.
> > @@ -231,7 +231,7 @@ static ssize_t bind_store(struct device_driver *drv,
> > const char *buf,
> > bus_put(bus);
> > return err;
> > }
> > -static DRIVER_ATTR_WO(bind);
> > +static DRIVER_ATTR_IGNORE_LOCKDEP(bind, S_IWUSR, NULL, bind_store);
> >
> > static ssize_t show_drivers_autoprobe(struct bus_type *bus, char *buf)
> > {
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 1b25c7a43f4c..d2cb1a6c5d95 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -326,6 +326,10 @@ struct driver_attribute {
> > struct driver_attribute driver_attr_##_name = __ATTR_RO(_name)
> > #define DRIVER_ATTR_WO(_name) \
> > struct driver_attribute driver_attr_##_name = __ATTR_WO(_name)
> > +#define DRIVER_ATTR_IGNORE_LOCKDEP(_name, _mode, _show, _store) \
> > + struct driver_attribute driver_attr_##_name = \
> > + __ATTR_IGNORE_LOCKDEP(_name, _mode, _show, _store)
> > +
>
> I don't want to give driver writers the ability to shoot themselves in
> the foot, can you just put this in the bus.c file itself so that no one
> else will abuse this and "open code" the unbind/bind attributes instead
> of using a #define for it?
Good point, but any attribute starting a driver unbind via sysfs will
need this, won't it?
> Also I've been trying to get rid of the "specify the mode" macros, so
> that everyone uses the RO, WO, and RW versions, so adding a generic one
> here is not going to help with that effort :)
But if that goes into bus.c directly, the mode arg doesn't hurt IMO
and one macro would be sufficient to cover both attrs.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] sysfs: Disable lockdep for driver bind/unbind files
/0xa0
> > > [12301.899085] acpi_video_unregister+0x24/0x40
> > > [12301.899127] i915_driver_unload+0x42/0x130 [i915]
> > > [12301.899160] i915_pci_remove+0x19/0x30 [i915]
> > > [12301.899169] pci_device_remove+0x36/0xb0
> > > [12301.899176] device_release_driver_internal+0x185/0x240
> > > [12301.899183] unbind_store+0xaf/0x180
> > > [12301.899189] kernfs_fop_write+0x104/0x190
> > > [12301.899195] __vfs_write+0x31/0x180
> > > [12301.899203] ? rcu_read_lock_sched_held+0x6f/0x80
> > > [12301.899209] ? rcu_sync_lockdep_assert+0x29/0x50
> > > [12301.899216] ? __sb_start_write+0x13c/0x1a0
> > > [12301.899221] ? vfs_write+0x17f/0x1b0
> > > [12301.899227] vfs_write+0xb9/0x1b0
> > > [12301.899233] ksys_write+0x50/0xc0
> > > [12301.899239] do_syscall_64+0x4b/0x180
> > > [12301.899247] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > [12301.899253] RIP: 0033:0x7f452ac7f7a4
> > > [12301.899259] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f
> > > 80 00 00 00 00 8b 05 aa f0 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f
> > > 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
> > > [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:
> > > 0001
> > > [12301.899295] RBP: 5612a1abf7c0 R08: 000a 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 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
> > >
> > > sysfs: get rid of some lockdep false positives
> > >
> > > commit e9b526fe704812364bca07edd15eadeba163ebfb
> > > Author: Alexander Sverdlin
> > > Date: Fri May 17 14:56:35 2013 +0200
> > >
> > > i2c: suppress lockdep warning on delete_device
> > >
> > > Implement the same trick for driver bind/unbind.
> > >
> > > Cc: "Rafael J. Wysocki"
> > > Cc: Greg Kroah-Hartman
> > > Cc: Ramalingam C
> > > Cc: Arend van Spriel
> > > Cc: Andy Shevchenko
> > > Cc: Geert Uytterhoeven
> > > Cc: Bartosz Golaszewski
> > > Cc: Heikki Krogerus
> > > Cc: Vivek Gautam
> > > Cc: Joe Perches
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/base/bus.c | 4 ++--
> > > include/linux/device.h | 4
> > > 2 files changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> > > index 8bfd27ec73d6..5d2411b848cd 100644
> > > --- a/drivers/base/bus.c
> > > +++ b/drivers/base/bus.c
> > > @@ -195,7 +195,7 @@ static ssize_t unbind_store(struct device_driver
> > > *drv, const char *buf,
> > > bus_put(bus);
> > > return err;
> > > }
> > > -static DRIVER_ATTR_WO(unbind);
> > > +static DRIVER_ATTR_IGNORE_LOCKDEP(unbind, S_IWUSR, NULL, unbind_store);
> > >
> > > /*
> > > * Manually attach a device to a driver.
> > > @@ -231,7 +231,7 @@ static ssize_t bind_store(struct device_driver *drv,
> > > const char *buf,
> > > bus_put(bus);
> > > return err;
> > > }
> > > -static DRIVER_ATTR_WO(bind);
> > > +static DRIVER_ATTR_IGNORE_LOCKDEP(bind, S_IWUSR, NULL, bind_store);
> > >
> > > static ssize_t show_drivers_autoprobe(struct bus_type *bus, char *buf)
> > > {
> > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > index 1b25c7a43f4c..d2cb1a6c5d95 100644
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -326,6 +326,10 @@ struct driver_attribute {
> > > struct driver_attribute driver_attr_##_name = __ATTR_RO(_name)
> > > #define DRIVER_ATTR_WO(_name) \
> > > struct driver_attribute driver_attr_##_name = __ATTR_WO(_name)
> > > +#define DRIVER_ATTR_IGNORE_LOCKDEP(_name, _mode, _show, _store) \
> > > + struct driver_attribute driver_attr_##_name = \
> > > + __ATTR_IGNORE_LOCKDEP(_name, _mode, _show, _store)
> > > +
> >
> > I don't want to give driver writers the ability to shoot themselves in
> > the foot, can you just put this in the bus.c file itself so that no one
> > else will abuse this and "open code" the unbind/bind attributes instead
> > of using a #define for it?
>
> So part of the reasons I've put these here is that I think we can do a
> lot better. Instead of ignoring lockdep I think we can implement
> nested lockdep annotations. It's going to be a bit a pain to wire that
> through from sysfs->kernfs, but for all the (now 3) uses of
> _IGNORE_LOCKDEP it should work if the add/remove_files functions use
> mutex_lock_nested.
Agreed.
>I think then there's not really a problem with
> exposing this. Aside from it's already exposed, but only for devices,
> as DEVICE_ATTR_IGNORE_LOCKDEP.
Right.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] sysfs: Disable lockdep for driver bind/unbind files
> 00 00 00 8b 05 aa f0 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d
> 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
> [12301.899273] RSP: 002b:7ffceafa6918 EFLAGS: 0246 ORIG_RAX:
> 0001
> [12301.899282] RAX: ffda RBX: 000d RCX:
> 7f452ac7f7a4
> [12301.899288] RDX: 000d RSI: 5612a1abf7c0 RDI:
> 0001
> [12301.899295] RBP: 5612a1abf7c0 R08: 000a 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 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
>
> sysfs: get rid of some lockdep false positives
>
> commit e9b526fe704812364bca07edd15eadeba163ebfb
> Author: Alexander Sverdlin
> Date: Fri May 17 14:56:35 2013 +0200
>
> i2c: suppress lockdep warning on delete_device
>
> Implement the same trick for driver bind/unbind.
>
> v2: Put the macro into bus.c (Greg).
>
> Cc: "Rafael J. Wysocki"
It would have been fine to retain the R-by:
Reviewed-by: Rafael J. Wysocki
> Cc: Greg Kroah-Hartman
> Cc: Ramalingam C
> Cc: Arend van Spriel
> Cc: Andy Shevchenko
> Cc: Geert Uytterhoeven
> Cc: Bartosz Golaszewski
> Cc: Heikki Krogerus
> Cc: Vivek Gautam
> Cc: Joe Perches
> Signed-off-by: Daniel Vetter
> ---
> drivers/base/bus.c | 7 +--
> include/linux/device.h | 1 +
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index 8bfd27ec73d6..585e2e1c9c8f 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -31,6 +31,9 @@ static struct kset *system_kset;
>
> #define to_drv_attr(_attr) container_of(_attr, struct driver_attribute, attr)
>
> +#define DRIVER_ATTR_IGNORE_LOCKDEP(_name, _mode, _show, _store) \
> + struct driver_attribute driver_attr_##_name = \
> + __ATTR_IGNORE_LOCKDEP(_name, _mode, _show, _store)
>
> static int __must_check bus_rescan_devices_helper(struct device *dev,
> void *data);
> @@ -195,7 +198,7 @@ static ssize_t unbind_store(struct device_driver *drv,
> const char *buf,
> bus_put(bus);
> return err;
> }
> -static DRIVER_ATTR_WO(unbind);
> +static DRIVER_ATTR_IGNORE_LOCKDEP(unbind, S_IWUSR, NULL, unbind_store);
>
> /*
> * Manually attach a device to a driver.
> @@ -231,7 +234,7 @@ static ssize_t bind_store(struct device_driver *drv,
> const char *buf,
> bus_put(bus);
> return err;
> }
> -static DRIVER_ATTR_WO(bind);
> +static DRIVER_ATTR_IGNORE_LOCKDEP(bind, S_IWUSR, NULL, bind_store);
>
> static ssize_t show_drivers_autoprobe(struct bus_type *bus, char *buf)
> {
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 1b25c7a43f4c..41424d6e27c7 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -327,6 +327,7 @@ struct driver_attribute {
> #define DRIVER_ATTR_WO(_name) \
> struct driver_attribute driver_attr_##_name = __ATTR_WO(_name)
>
> +
> extern int __must_check driver_create_file(struct device_driver *driver,
> const struct driver_attribute *attr);
> extern void driver_remove_file(struct device_driver *driver,
> --
> 2.20.0.rc1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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
> > runtime debug counters inline with genpd and other pm subsytems which
> > uses ktime based accounting.
> >
> > Signed-off-by: Thara Gopinath
> > [move from ktime to raw nsec]
> > Signed-off-by: Vincent Guittot
> > ---
> > drivers/base/power/runtime.c | 17 +
> > drivers/base/power/sysfs.c | 11 ---
> > include/linux/pm.h | 6 +++---
> > 3 files changed, 20 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > index e695544..f700524 100644
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -64,8 +64,8 @@ static int rpm_suspend(struct device *dev, int rpmflags);
> > */
> > void update_pm_runtime_accounting(struct device *dev)
> > {
> > - unsigned long now = jiffies;
> > - unsigned long delta;
> > + u64 now = ktime_to_ns(ktime_get());
> > + u64 delta;
> >
> > delta = now - dev->power.accounting_timestamp;
> >
> > @@ -75,9 +75,9 @@ void update_pm_runtime_accounting(struct device *dev)
> > return;
> >
> > if (dev->power.runtime_status == RPM_SUSPENDED)
> > - dev->power.suspended_jiffies += delta;
> > + dev->power.suspended_time += delta;
> > else
> > - dev->power.active_jiffies += delta;
> > + dev->power.active_time += delta;
> > }
> >
> > static void __update_runtime_status(struct device *dev, enum rpm_status
> > status)
> > @@ -88,17 +88,18 @@ static void __update_runtime_status(struct device *dev,
> > enum rpm_status status)
> >
> > u64 pm_runtime_suspended_time(struct device *dev)
> > {
> > - unsigned long flags, time;
> > + u64 time;
> > + unsigned long flags;
> >
> > spin_lock_irqsave(&dev->power.lock, flags);
> >
> > update_pm_runtime_accounting(dev);
> >
> > - time = dev->power.suspended_jiffies;
> > + time = dev->power.suspended_time;
> >
> > spin_unlock_irqrestore(&dev->power.lock, flags);
> >
> > - return jiffies_to_nsecs(time);
> > + return time;
> > }
> > EXPORT_SYMBOL_GPL(pm_runtime_suspended_time);
> >
> > @@ -1503,7 +1504,7 @@ void pm_runtime_init(struct device *dev)
> > dev->power.request_pending = false;
> > dev->power.request = RPM_REQ_NONE;
> > dev->power.deferred_resume = false;
> > - dev->power.accounting_timestamp = jiffies;
> > + dev->power.accounting_timestamp = ktime_to_ns(ktime_get());
>
> This change worries me a bit, but it may not be a problem in practice.
>
> pm_runtime_init() is called when devices get initialized, via
> device_initialize(). If timekeeping has not been initialized prior a
> call to ktime_get() is done, it will fail and causing a NULL pointer
> deference or something along those lines.
>
> In other words, do we know that device_initialize() is always called
> after timekeeping has been initialized during boot?
We do.
timekeeping_init() is called early in start_kernel() which is way
before driver_init() (and that's when devices can start to be
initialized) called from rest_init() via kernel_init_freeable() and
do_basic_setup().
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
@@ -1748,21 +1769,27 @@ int dpm_suspend(pm_message_t state)
struct device *dev = to_device(dpm_prepared_list.prev);
get_device(dev);
+
mutex_unlock(&dpm_list_mtx);
error = device_suspend(dev);
mutex_lock(&dpm_list_mtx);
+
if (error) {
pm_dev_err(dev, state, "", error);
dpm_save_failed_dev(dev_name(dev));
- put_device(dev);
- break;
- }
- if (!list_empty(&dev->power.entry))
+ } else if (!list_empty(&dev->power.entry)) {
list_move(&dev->power.entry, &dpm_suspended_list);
+ }
+
+ mutex_unlock(&dpm_list_mtx);
+
put_device(dev);
- if (async_error)
+
+ mutex_lock(&dpm_list_mtx);
+
+ if (error || async_error)
break;
}
mutex_unlock(&dpm_list_mtx);
@@ -1879,6 +1906,7 @@ int dpm_prepare(pm_message_t state)
struct device *dev = to_device(dpm_list.next);
get_device(dev);
+
mutex_unlock(&dpm_list_mtx);
trace_device_pm_callback_start(dev, "", state.event);
@@ -1886,21 +1914,23 @@ int dpm_prepare(pm_message_t state)
trace_device_pm_callback_end(dev, error);
mutex_lock(&dpm_list_mtx);
- if (error) {
- if (error == -EAGAIN) {
- put_device(dev);
- error = 0;
- continue;
- }
+
+ if (!error) {
+ dev->power.is_prepared = true;
+ if (!list_empty(&dev->power.entry))
+ list_move_tail(&dev->power.entry, &dpm_prepared_list);
+ } else if (error == -EAGAIN) {
+ error = 0;
+ } else {
dev_info(dev, "not prepared for power transition: code
%d\n",
error);
- put_device(dev);
- break;
It appears the above break disappeared.
}
- dev->power.is_prepared = true;
- if (!list_empty(&dev->power.entry))
- list_move_tail(&dev->power.entry, &dpm_prepared_list);
+
+ mutex_unlock(&dpm_list_mtx);
+
put_device(dev);
Should be
if (error)
break;
Here?
Looks like that.
Symptoms is if we return an error from the device prepare callback, we
end up spinning forever with little clue what's going on.
+
+ mutex_lock(&dpm_list_mtx);
}
mutex_unlock(&dpm_list_mtx);
trace_suspend_resume(TPS("dpm_prepare"), state.event, false);
I'll have a look, thanks for the report!
Re: [Intel-gfx] [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
On Tue, Jul 12, 2022 at 9:39 PM Hans de Goede wrote: > > Hi All, > > As mentioned in my RFC titled "drm/kms: control display brightness through > drm_connector properties": > https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/ > > The first step towards this is to deal with some existing technical debt > in backlight handling on x86/ACPI boards, specifically we need to stop > registering multiple /sys/class/backlight devs for a single display. > > This series implements my RFC describing my plan for these cleanups: > https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343...@redhat.com/ > > This new version addresses the few small remarks made on version 1 (mainly > changing patch 1/29) and more importantly this finishes the refactoring by > else addressing all the bits from 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-rc2 is out. Please feel free to add Acked-by: Rafael J. Wysocki to all of the ACPI video patches in this series. Thanks! > Hans de Goede (29): > ACPI: video: Add acpi_video_backlight_use_native() helper > drm/i915: Don't register backlight when another backlight should be > used > drm/amdgpu: Don't register backlight when another backlight should be > used > drm/radeon: Don't register backlight when another backlight should be > used > drm/nouveau: Don't register backlight when another backlight should be > used > ACPI: video: Drop backlight_device_get_by_type() call from > acpi_video_get_backlight_type() > ACPI: video: Remove acpi_video_bus from list before tearing it down > ACPI: video: Simplify acpi_video_unregister_backlight() > ACPI: video: Make backlight class device registration a separate step > ACPI: video: Remove code to unregister acpi_video backlight when a > native backlight registers > drm/i915: Call acpi_video_register_backlight() (v2) > drm/nouveau: Register ACPI video backlight when nv_backlight > registration fails > drm/amdgpu: Register ACPI video backlight when skipping amdgpu > backlight registration > drm/radeon: Register ACPI video backlight when skipping radeon > backlight registration > ACPI: video: Refactor acpi_video_get_backlight_type() a bit > ACPI: video: Add Nvidia WMI EC brightness control detection > ACPI: video: Add Apple GMUX brightness control detection > platform/x86: apple-gmux: Stop calling acpi/video.h functions > platform/x86: toshiba_acpi: Stop using > acpi_video_set_dmi_backlight_type() > platform/x86: acer-wmi: Move backlight DMI quirks to > acpi/video_detect.c > platform/x86: asus-wmi: Drop DMI chassis-type check from backlight > handling > platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI > video_detect.c > platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI > video_detect.c > platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] > quirks to ACPI video_detect.c > ACPI: video: Remove acpi_video_set_dmi_backlight_type() > ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk > ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native > quirks > ACPI: video: Fix indentation of video_detect_dmi_table[] entries > drm/todo: Add entry about dealing with brightness control on devices > with > 1 panel > > Documentation/gpu/todo.rst| 68 +++ > drivers/acpi/Kconfig | 1 + > drivers/acpi/acpi_video.c | 59 ++- > drivers/acpi/video_detect.c | 415 +++--- > drivers/gpu/drm/Kconfig | 12 + > .../gpu/drm/amd/amdgpu/atombios_encoders.c| 14 +- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 + > drivers/gpu/drm/gma500/Kconfig| 2 + > drivers/gpu/drm/i915/Kconfig | 2 + > .../gpu/drm/i915/display/intel_backlight.c| 7 + > drivers/gpu/drm/i915/display/intel_display.c | 8 + > drivers/gpu/drm/i915/display/intel_panel.c| 3 + > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/nouveau/nouveau_backlight.c | 14 + > drivers/gpu/drm/radeon/atombios_encoders.c| 7 + > drivers/gpu/drm/radeon/radeon_encoders.c | 11 +- > .../gpu/drm/radeon/radeon_legacy_encoders.c | 7 + > drivers/platform/x86/acer-wmi.c | 66 --- > drivers/platform/x86/apple-gmux.c
Re: [Intel-gfx] [PATCH 02/17] Use memberof(T, m) instead of explicit NULL dereference
On Fri, Nov 19, 2021 at 12:37 PM Alejandro Colomar wrote: > > Signed-off-by: Alejandro Colomar > Cc: Ajit Khaparde > Cc: Andrew Morton > Cc: Andy Shevchenko > Cc: Arnd Bergmann > Cc: Bjorn Andersson > Cc: Borislav Petkov > Cc: Corey Minyard > Cc: Chris Mason > Cc: Christian Brauner > Cc: David Sterba > Cc: Jani Nikula > Cc: Jason Wang > Cc: Jitendra Bhivare > Cc: John Hubbard > Cc: John S. Gruber > Cc: Jonathan Cameron > Cc: Joonas Lahtinen > Cc: Josef Bacik > Cc: Kees Cook > Cc: Ketan Mukadam > Cc: 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 > Cc: Subbu Seetharaman > Cc: > Cc: > Cc: > Cc: > Cc: > Cc: > Cc: > --- > arch/x86/include/asm/bootparam_utils.h | 3 ++- > arch/x86/kernel/signal_compat.c | 5 +++-- > drivers/gpu/drm/i915/i915_utils.h | 5 ++--- > drivers/gpu/drm/i915/intel_runtime_pm.h | 2 +- > drivers/net/ethernet/emulex/benet/be.h | 7 --- > drivers/net/ethernet/i825xx/ether1.c| 7 +-- > drivers/scsi/be2iscsi/be.h | 7 --- > drivers/scsi/be2iscsi/be_cmds.h | 5 - > fs/btrfs/ctree.h| 5 +++-- > include/acpi/actypes.h | 4 +++- The change in actypes.h would need to be submitted to the upstream ACPICA project via https://github.com/acpica/acpica/ Thanks! > include/linux/container_of.h| 6 +++--- > include/linux/virtio_config.h | 14 +++--- > 12 files changed, 41 insertions(+), 29 deletions(-)
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 11:47:43AM -0600, Gustavo A. R. Silva wrote: > > > > > > > > These all look trivially correct to me. Only two didn't have the end of > > > > the struct visible in the patch, and checking those showed them to be > > > > trailing members as well, so: > > > > > > > > Reviewed-by: Kees Cook > > > > > > I'll add this to my -next tree. > > > > I would like to ask you to send mlx5 patch separately to netdev. We are > > working > > to delete that file completely and prefer to avoid from unnecessary merge > > conflicts. > > Oh OK. Sure thing; I will do so. Can you also send the ACPI patch separately, please? We would like to route it through the upstream ACPICA code base.
Re: [Intel-gfx] [PATCH 1/3] ACPI / LPSS: Rename pwm_backlight pwm-lookup to pwm_soc_backlight
On Tuesday, November 19, 2019 4:18:16 PM CET Hans de Goede wrote:
> At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
> different PWM controllers for controlling the LCD's backlight brightness.
> Either the one integrated into the PMIC or the one integrated into the
> SoC (the 1st LPSS PWM controller).
>
> So far in the LPSS code on BYT we have skipped registering the LPSS PWM
> controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is
> present, assuming that in this case the PMIC PWM controller will be used.
>
> On CHT we have been relying on only 1 of the 2 PWM controllers being
> enabled in the DSDT at the same time; and always registered the lookup.
>
> So far this has been working, but the correct way to determine which PWM
> controller needs to be used is by checking a bit in the VBT table and
> recently I've learned about 2 different BYT devices:
> Point of View MOBII TAB-P800W
> Acer Switch 10 SW5-012
>
> Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
> PWM controller (and the VBT correctly indicates this), so here our old
> heuristics fail.
>
> Since only the i915 driver has access to the VBT, this commit renames
> the "pwm_backlight" lookup entries for the 1st BYT/CHT LPSS PWM controller
> to "pwm_soc_backlight" so that the i915 driver can do a pwm_get() for
> the right controller 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 whole series.
Thanks!
> ---
> drivers/acpi/acpi_lpss.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> index 751ed38f2a10..63e81d8e675b 100644
> --- a/drivers/acpi/acpi_lpss.c
> +++ b/drivers/acpi/acpi_lpss.c
> @@ -69,10 +69,6 @@ ACPI_MODULE_NAME("acpi_lpss");
> #define LPSS_SAVE_CTXBIT(4)
> #define LPSS_NO_D3_DELAY BIT(5)
>
> -/* Crystal Cove PMIC shares same ACPI ID between different platforms */
> -#define BYT_CRC_HRV 2
> -#define CHT_CRC_HRV 3
> -
> struct lpss_private_data;
>
> struct lpss_device_desc {
> @@ -158,7 +154,7 @@ static void lpss_deassert_reset(struct lpss_private_data
> *pdata)
> */
> static struct pwm_lookup byt_pwm_lookup[] = {
> PWM_LOOKUP_WITH_MODULE("80860F09:00", 0, ":00:02.0",
> -"pwm_backlight", 0, PWM_POLARITY_NORMAL,
> +"pwm_soc_backlight", 0, PWM_POLARITY_NORMAL,
> "pwm-lpss-platform"),
> };
>
> @@ -170,8 +166,7 @@ static void byt_pwm_setup(struct lpss_private_data *pdata)
> if (!adev->pnp.unique_id || strcmp(adev->pnp.unique_id, "1"))
> return;
>
> - if (!acpi_dev_present("INT33FD", NULL, BYT_CRC_HRV))
> - pwm_add_table(byt_pwm_lookup, ARRAY_SIZE(byt_pwm_lookup));
> + pwm_add_table(byt_pwm_lookup, ARRAY_SIZE(byt_pwm_lookup));
> }
>
> #define LPSS_I2C_ENABLE 0x6c
> @@ -204,7 +199,7 @@ static void byt_i2c_setup(struct lpss_private_data *pdata)
> /* BSW PWM used for backlight control by the i915 driver */
> static struct pwm_lookup bsw_pwm_lookup[] = {
> PWM_LOOKUP_WITH_MODULE("80862288:00", 0, ":00:02.0",
> -"pwm_backlight", 0, PWM_POLARITY_NORMAL,
> +"pwm_soc_backlight", 0, PWM_POLARITY_NORMAL,
> "pwm-lpss-platform"),
> };
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 lower bound on the response latency of PM (defined as
> the time it takes from wake-up to the CPU reaching a certain
> steady-state level of performance [e.g. the nominal frequency] in
> response to a step-function load). It reports to PM the minimum
> ramp-up latency considered of use to the application, and explicitly
> requests PM to filter out oscillations faster than the specified
> frequency. It is somewhat complementary to the current
> CPU_DMA_LATENCY PM QoS class which can be understood as specifying an
> upper latency bound on the CPU wake-up time, instead of a lower bound
> on the CPU frequency ramp-up time.
>
> Note that even though this provides a latency constraint it's
> represented as its reciprocal in Hz units for computational efficiency
> (since it would take a 64-bit division to compute the number of cycles
> elapsed from a time increment in nanoseconds and a time bound, while a
> frequency can simply be multiplied with the time increment).
>
> This implements a MAX constraint so that the strictest (highest
> response frequency) request is honored. This means that PM won't
> provide any guarantee that frequencies greater than the specified
> bound will be filtered, since that might be incompatible with the
> constraints specified by another more latency-sensitive application (A
> more fine-grained result could be achieved with a scheduling-based
> interface). The default value needs to be equal to zero (best effort)
> for it to behave as identity of the MAX operation.
>
> v2: Drop wake_up_all_idle_cpus() call from
> cpu_response_frequency_qos_apply() (Peter).
>
> Signed-off-by: Francisco Jerez
> ---
> include/linux/pm_qos.h | 9 +++
> include/trace/events/power.h | 33 +
> kernel/power/qos.c | 138 ++-
First, the documentation (Documentation/power/pm_qos_interface.rst) needs to be
updated too to cover the new QoS category.
> 3 files changed, 162 insertions(+), 18 deletions(-)
>
> diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
> index 4a69d4af3ff8..b522e2194c05 100644
> --- a/include/linux/pm_qos.h
> +++ b/include/linux/pm_qos.h
> @@ -28,6 +28,7 @@ enum pm_qos_flags_status {
> #define PM_QOS_LATENCY_ANY_NS((s64)PM_QOS_LATENCY_ANY *
> NSEC_PER_USEC)
>
> #define PM_QOS_CPU_LATENCY_DEFAULT_VALUE (2000 * USEC_PER_SEC)
> +#define PM_QOS_CPU_RESPONSE_FREQUENCY_DEFAULT_VALUE 0
I would call this PM_QOS_CPU_SCALING_RESPONSE_DEFAULT_VALUE and all of the
API pieces accordingly.
> #define PM_QOS_RESUME_LATENCY_DEFAULT_VALUE PM_QOS_LATENCY_ANY
> #define PM_QOS_RESUME_LATENCY_NO_CONSTRAINT PM_QOS_LATENCY_ANY
> #define PM_QOS_RESUME_LATENCY_NO_CONSTRAINT_NS PM_QOS_LATENCY_ANY_NS
> @@ -162,6 +163,14 @@ static inline void cpu_latency_qos_update_request(struct
> pm_qos_request *req,
> static inline void cpu_latency_qos_remove_request(struct pm_qos_request
> *req) {}
> #endif
>
> +s32 cpu_response_frequency_qos_limit(void);
For example
cpu_scaling_response_qos_limit()
> +bool cpu_response_frequency_qos_request_active(struct pm_qos_request *req);
cpu_scaling_response_qos_request_active()
and so on.
> +void cpu_response_frequency_qos_add_request(struct pm_qos_request *req,
> + s32 value);
> +void cpu_response_frequency_qos_update_request(struct pm_qos_request *req,
> +s32 new_value);
> +void cpu_response_frequency_qos_remove_request(struct pm_qos_request *req);
> +
> #ifdef CONFIG_PM
> enum pm_qos_flags_status __dev_pm_qos_flags(struct device *dev, s32 mask);
> enum pm_qos_flags_status dev_pm_qos_flags(struct device *dev, s32 mask);
> diff --git a/include/trace/events/power.h b/include/trace/events/power.h
> index af5018aa9517..7e4b52e8ca3a 100644
> --- a/include/trace/events/power.h
> +++ b/include/trace/events/power.h
> @@ -359,45 +359,48 @@ DEFINE_EVENT(power_domain, power_domain_target,
> );
>
> /*
> - * CPU latency QoS events used for global CPU latency QoS list updates
> + * CPU latency/response frequency QoS events used for global CPU PM
> + * QoS list updates.
> */
> -DECLARE_EVENT_CLASS(cpu_latency_qos_request,
> +DECLARE_EVENT_CLASS(pm_qos_request,
>
> - TP_PROTO(s32 value),
> + TP_PROTO(const char *name, s32 value),
>
> - TP_ARGS(value),
> + TP_ARGS(name, value),
>
> TP_STRUCT__entry(
> + __string(name, name )
> __field( s32,value )
> ),
>
> TP_fast_assign(
> + __assign_str(name, name);
> __entry->value = value;
> ),
>
> - TP_p
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 introduce a new scaling algorithm.
In my view that needs to be exposed via scaling_governor so users can
switch over between this and the existing ones (powersave and performance).
That would require the cpufreq core to be updated somewhat to recognize
an additional CPUFREQ_POLICY_ value, but that should be perfectly doable.
And ->
> Signed-off-by: Francisco Jerez
> ---
> drivers/cpufreq/intel_pstate.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 7fa869004cf0..8cb5bf419b40 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -277,6 +277,7 @@ static struct cpudata **all_cpu_data;
> * @get_scaling: Callback to get frequency scaling factor
> * @get_val: Callback to convert P state to actual MSR write value
> * @get_vid: Callback to get VID data for Atom platforms
> + * @update_util: Active mode utilization update callback.
> *
> * Core and Atom CPU models have different way to get P State limits. This
> * structure is used to store those callbacks.
> @@ -290,6 +291,8 @@ struct pstate_funcs {
> int (*get_aperf_mperf_shift)(void);
> u64 (*get_val)(struct cpudata*, int pstate);
> void (*get_vid)(struct cpudata *);
> + void (*update_util)(struct update_util_data *data, u64 time,
> + unsigned int flags);
> };
>
> static struct pstate_funcs pstate_funcs __read_mostly;
> @@ -1877,6 +1880,7 @@ static struct pstate_funcs core_funcs = {
> .get_turbo = core_get_turbo_pstate,
> .get_scaling = core_get_scaling,
> .get_val = core_get_val,
> + .update_util = intel_pstate_update_util,
> };
>
> static const struct pstate_funcs silvermont_funcs = {
> @@ -1887,6 +1891,7 @@ static const struct pstate_funcs silvermont_funcs = {
> .get_val = atom_get_val,
> .get_scaling = silvermont_get_scaling,
> .get_vid = atom_get_vid,
> + .update_util = intel_pstate_update_util,
> };
>
> static const struct pstate_funcs airmont_funcs = {
> @@ -1897,6 +1902,7 @@ static const struct pstate_funcs airmont_funcs = {
> .get_val = atom_get_val,
> .get_scaling = airmont_get_scaling,
> .get_vid = atom_get_vid,
> + .update_util = intel_pstate_update_util,
> };
>
> static const struct pstate_funcs knl_funcs = {
> @@ -1907,6 +1913,7 @@ static const struct pstate_funcs knl_funcs = {
> .get_aperf_mperf_shift = knl_get_aperf_mperf_shift,
> .get_scaling = core_get_scaling,
> .get_val = core_get_val,
> + .update_util = intel_pstate_update_util,
> };
>
> #define ICPU(model, policy) \
> @@ -2013,9 +2020,7 @@ static void intel_pstate_set_update_util_hook(unsigned
> int cpu_num)
> /* Prevent intel_pstate_update_util() from using stale data. */
> cpu->sample.time = 0;
> cpufreq_add_update_util_hook(cpu_num, &cpu->update_util,
> - (hwp_active ?
> - intel_pstate_update_util_hwp :
> - intel_pstate_update_util));
-> it should be possible to extend this code to install an update_util matching
the scaling algo chosen by the user.
> + pstate_funcs.update_util);
> cpu->update_util_set = true;
> }
>
> @@ -2584,6 +2589,7 @@ static void __init copy_cpu_funcs(struct pstate_funcs
> *funcs)
> pstate_funcs.get_scaling = funcs->get_scaling;
> pstate_funcs.get_val = funcs->get_val;
> pstate_funcs.get_vid = funcs->get_vid;
> + pstate_funcs.update_util = funcs->update_util;
> pstate_funcs.get_aperf_mperf_shift = funcs->get_aperf_mperf_shift;
> }
>
> @@ -2750,8 +2756,11 @@ static int __init intel_pstate_init(void)
> id = x86_match_cpu(hwp_support_ids);
> if (id) {
> copy_cpu_funcs(&core_funcs);
> - if (!no_hwp) {
> + if (no_hwp) {
> + pstate_funcs.update_util = intel_pstate_update_util;
> + } else {
> hwp_active++;
> + pstate_funcs.update_util = intel_pstate_update_util_hwp;
> hwp_mode_bdw = id->driver_data;
> intel_pstate.attr = hwp_cpufreq_attrs;
> goto hwp_cpu_matched;
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 struct vlp_status_sample which contains status
> information derived from the former indicating whether the system is
> likely to have an IO or CPU bottleneck. This will be used as main
> heuristic input by the new variably low-pass filtering controller (AKA
> VLP)
I'm not sure how widely used this is.
It would be good to provide a pointer to a definition of it where all of
the maths is described and the foundation of it is explained. Alternatively,
document it in the kernel source.
> that will assist the HWP at finding a reasonably energy-efficient
> P-state given the additional information available to the kernel about
> I/O utilization and scheduling behavior.
>
> Signed-off-by: Francisco Jerez
> ---
> drivers/cpufreq/intel_pstate.c | 230 +
> 1 file changed, 230 insertions(+)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 8cb5bf419b40..12ee350db2a9 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -33,6 +34,8 @@
> #include
> #include
>
> +#include "../../kernel/sched/sched.h"
> +
> #define INTEL_PSTATE_SAMPLING_INTERVAL (10 * NSEC_PER_MSEC)
>
> #define INTEL_CPUFREQ_TRANSITION_LATENCY 2
> @@ -59,6 +62,11 @@ static inline int32_t mul_fp(int32_t x, int32_t y)
> return ((int64_t)x * (int64_t)y) >> FRAC_BITS;
> }
>
> +static inline int rnd_fp(int32_t x)
What does md stand for?
> +{
> + return (x + (1 << (FRAC_BITS - 1))) >> FRAC_BITS;
> +}
> +
> static inline int32_t div_fp(s64 x, s64 y)
> {
> return div64_s64((int64_t)x << FRAC_BITS, y);
> @@ -169,6 +177,49 @@ struct vid_data {
> int32_t ratio;
> };
>
> +/**
> + * Scheduling and PM statistics gathered by update_vlp_sample() at
> + * every call of the VLP update_state() hook, used as heuristic
> + * inputs.
> + */
> +struct vlp_input_stats {
> + int32_t realtime_count;
> + int32_t io_wait_count;
> + uint32_t max_response_frequency_hz;
> + uint32_t last_response_frequency_hz;
> +};
> +
> +enum vlp_status {
> + VLP_BOTTLENECK_IO = 1 << 0,
> + /*
> + * XXX - Add other status bits here indicating a CPU or TDP
> + * bottleneck.
> + */
> +};
> +
> +/**
> + * Heuristic status information calculated by get_vlp_status_sample()
> + * from struct vlp_input_stats above, indicating whether the system
> + * has a potential IO or latency bottleneck.
> + */
> +struct vlp_status_sample {
> + enum vlp_status value;
> + int32_t realtime_avg;
> +};
> +
> +/**
> + * struct vlp_data - VLP controller parameters and state.
> + * @sample_interval_ns: Update interval in ns.
> + * @sample_frequency_hz: Reciprocal of the update interval in Hz.
> + */
> +struct vlp_data {
> + s64 sample_interval_ns;
> + int32_t sample_frequency_hz;
> +
> + struct vlp_input_stats stats;
> + struct vlp_status_sample status;
> +};
> +
> /**
> * struct global_params - Global parameters, mostly tunable via sysfs.
> * @no_turbo:Whether or not to use turbo P-states.
> @@ -239,6 +290,7 @@ struct cpudata {
>
> struct pstate_data pstate;
> struct vid_data vid;
> + struct vlp_data vlp;
>
> u64 last_update;
> u64 last_sample_time;
> @@ -268,6 +320,18 @@ struct cpudata {
>
> static struct cpudata **all_cpu_data;
>
> +/**
> + * struct vlp_params - VLP controller static configuration
> + * @sample_interval_ms: Update interval in ms.
> + * @avg*_hz: Exponential averaging frequencies of the various
> + *low-pass filters as an integer in Hz.
> + */
> +struct vlp_params {
> + int sample_interval_ms;
> + int avg_hz;
> + int debug;
> +};
> +
> /**
> * struct pstate_funcs - Per CPU model specific callbacks
> * @get_max: Callback to get maximum non turbo effective P state
> @@ -296,6 +360,11 @@ struct pstate_funcs {
> };
>
> static struct pstate_funcs pstate_funcs __read_mostly;
> +static struct vlp_params vlp_params __read_mostly = {
> + .sample_interval_ms = 10,
> + .avg_hz = 2,
> + .debug = 0,
> +};
>
> static int hwp_active __read_mostly;
> static int hwp_mode_bdw __read_mostly;
> @@ -1793,6 +1862,167 @@ static inline int32_t get_target_pstate(struct
> cpudata *cpu)
> return target;
> }
>
> +/**
> + * Initialize the struct vlp_data of the specified CPU to the defaults
> + * calculated from @vlp_params.
> + */
Nit: All of the function header comments need to be in the canonical kerneldoc
format, ie. with arguments l
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 kernel-side frequency selection mechanism which will
> choose a single P-state from the range. This is meant to provide a
> variably low-pass filtering effect that will damp oscillations below a
> frequency threshold that can be specified by device drivers via PM QoS
> in order to achieve energy-efficient behavior in cases where the
> system has an IO bottleneck.
>
> Signed-off-by: Francisco Jerez
The separation of this patch from the other one appears to be artificial
and it actually makes reviewing them both harder in my perspective.
What would be wrong with merging them together?
> ---
> drivers/cpufreq/intel_pstate.c | 157 +
> 1 file changed, 157 insertions(+)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 12ee350db2a9..cecadfec8bc1 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -207,17 +207,34 @@ struct vlp_status_sample {
> int32_t realtime_avg;
> };
>
> +/**
> + * VLP controller state used for the estimation of the target P-state
> + * range, computed by get_vlp_target_range() from the heuristic status
> + * information defined above in struct vlp_status_sample.
> + */
> +struct vlp_target_range {
> + unsigned int value[2];
> + int32_t p_base;
> +};
> +
> /**
> * struct vlp_data - VLP controller parameters and state.
> * @sample_interval_ns: Update interval in ns.
> * @sample_frequency_hz: Reciprocal of the update interval in Hz.
> + * @gain*:Response factor of the controller relative to each
> + *one of its linear input variables as fixed-point
> + *fraction.
> */
> struct vlp_data {
> s64 sample_interval_ns;
> int32_t sample_frequency_hz;
> + int32_t gain_aggr;
> + int32_t gain_rt;
> + int32_t gain;
>
> struct vlp_input_stats stats;
> struct vlp_status_sample status;
> + struct vlp_target_range target;
> };
>
> /**
> @@ -323,12 +340,18 @@ static struct cpudata **all_cpu_data;
> /**
> * struct vlp_params - VLP controller static configuration
> * @sample_interval_ms: Update interval in ms.
> + * @setpoint_*_pml: Target CPU utilization at which the controller is
> + *expected to leave the current P-state untouched,
> + *as an integer per mille.
> * @avg*_hz: Exponential averaging frequencies of the various
> *low-pass filters as an integer in Hz.
> */
> struct vlp_params {
> int sample_interval_ms;
> + int setpoint_0_pml;
> + int setpoint_aggr_pml;
> int avg_hz;
> + int realtime_gain_pml;
> int debug;
> };
>
> @@ -362,7 +385,10 @@ struct pstate_funcs {
> static struct pstate_funcs pstate_funcs __read_mostly;
> static struct vlp_params vlp_params __read_mostly = {
> .sample_interval_ms = 10,
> + .setpoint_0_pml = 900,
> + .setpoint_aggr_pml = 1500,
> .avg_hz = 2,
> + .realtime_gain_pml = 12000,
> .debug = 0,
> };
>
> @@ -1873,6 +1899,11 @@ static void intel_pstate_reset_vlp(struct cpudata *cpu)
> vlp->sample_interval_ns = vlp_params.sample_interval_ms * NSEC_PER_MSEC;
> vlp->sample_frequency_hz = max(1u, (uint32_t)MSEC_PER_SEC /
> vlp_params.sample_interval_ms);
> + vlp->gain_rt = div_fp(cpu->pstate.max_pstate *
> + vlp_params.realtime_gain_pml, 1000);
> + vlp->gain_aggr = max(1, div_fp(1000, vlp_params.setpoint_aggr_pml));
> + vlp->gain = max(1, div_fp(1000, vlp_params.setpoint_0_pml));
> + vlp->target.p_base = 0;
> vlp->stats.last_response_frequency_hz = vlp_params.avg_hz;
> }
>
> @@ -1996,6 +2027,132 @@ static const struct vlp_status_sample
> *get_vlp_status_sample(
> return last_status;
> }
>
> +/**
> + * Calculate the target P-state range for the next update period.
> + * Uses a variably low-pass-filtering controller intended to improve
> + * energy efficiency when a CPU response frequency target is specified
> + * via PM QoS (e.g. under IO-bound conditions).
> + */
> +static const struct vlp_target_range *get_vlp_target_range(struct cpudata
> *cpu)
> +{
> + struct vlp_data *vlp = &cpu->vlp;
> + struct vlp_target_range *last_target = &vlp->target;
> +
> + /*
> + * P-state limits in fixed-point as allowed by the policy.
> + */
> + const int32_t p0 = int_tofp(max(cpu->pstate.min_pstate,
> + cpu->min_perf_ratio));
> + const int32_t p1 = int_tofp(cpu->max_perf_ratio);
> +
> + /*
> + * Observed
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 though (and soon enough on non-HWP too):
> In order to override the default behavior (e.g. to test on other
> platforms) the VLP controller can be forcefully enabled or disabled by
> passing "intel_pstate=vlp" or "intel_pstate=no_vlp" respectively in
> the kernel command line.
>
> v2: Handle HWP VLP controller.
>
> Signed-off-by: Francisco Jerez
> ---
> .../admin-guide/kernel-parameters.txt | 5
> Documentation/admin-guide/pm/intel_pstate.rst | 7 ++
> drivers/cpufreq/intel_pstate.c| 25 +--
> 3 files changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 0c9894247015..9bc55fc2752e 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1828,6 +1828,11 @@
> per_cpu_perf_limits
> Allow per-logical-CPU P-State performance control
> limits using
> cpufreq sysfs interface
> + vlp
> + Force use of VLP P-state controller. Overrides
> selection
> + derived from ACPI FADT profile.
> + no_vlp
> + Prevent use of VLP P-state controller (see "vlp"
> parameter).
>
> intremap= [X86-64, Intel-IOMMU]
> on enable Interrupt Remapping (default)
> diff --git a/Documentation/admin-guide/pm/intel_pstate.rst
> b/Documentation/admin-guide/pm/intel_pstate.rst
> index 67e414e34f37..da6b64812848 100644
> --- a/Documentation/admin-guide/pm/intel_pstate.rst
> +++ b/Documentation/admin-guide/pm/intel_pstate.rst
> @@ -669,6 +669,13 @@ of them have to be prepended with the ``intel_pstate=``
> prefix.
> Use per-logical-CPU P-State limits (see `Coordination of P-state
> Limits`_ for details).
>
> +``vlp``
> + Force use of VLP P-state controller. Overrides selection derived
> + from ACPI FADT profile.
> +
> +``no_vlp``
> + Prevent use of VLP P-state controller (see "vlp" parameter).
> +
>
> Diagnostics and Tuning
> ==
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index a01eed40d897..050cc8f03c26 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -3029,6 +3029,7 @@ static int intel_pstate_update_status(const char *buf,
> size_t size)
>
> static int no_load __initdata;
> static int no_hwp __initdata;
> +static int vlp __initdata = -1;
> static int hwp_only __initdata;
> static unsigned int force_load __initdata;
>
> @@ -3193,6 +3194,7 @@ static inline void
> intel_pstate_request_control_from_smm(void) {}
> #endif /* CONFIG_ACPI */
>
> #define INTEL_PSTATE_HWP_BROADWELL 0x01
> +#define INTEL_PSTATE_HWP_VLP 0x02
>
> #define ICPU_HWP(model, hwp_mode) \
> { X86_VENDOR_INTEL, 6, model, X86_FEATURE_HWP, hwp_mode }
> @@ -3200,12 +3202,15 @@ static inline void
> intel_pstate_request_control_from_smm(void) {}
> static const struct x86_cpu_id hwp_support_ids[] __initconst = {
> ICPU_HWP(INTEL_FAM6_BROADWELL_X, INTEL_PSTATE_HWP_BROADWELL),
> ICPU_HWP(INTEL_FAM6_BROADWELL_D, INTEL_PSTATE_HWP_BROADWELL),
> + ICPU_HWP(INTEL_FAM6_ICELAKE, INTEL_PSTATE_HWP_VLP),
> + ICPU_HWP(INTEL_FAM6_ICELAKE_L, INTEL_PSTATE_HWP_VLP),
> ICPU_HWP(X86_MODEL_ANY, 0),
> {}
> };
>
> static int __init intel_pstate_init(void)
> {
> + bool use_vlp = vlp == 1;
> const struct x86_cpu_id *id;
> int rc;
>
> @@ -3222,8 +3227,19 @@ static int __init intel_pstate_init(void)
> pstate_funcs.update_util = intel_pstate_update_util;
> } else {
> hwp_active++;
> - pstate_funcs.update_util = intel_pstate_update_util_hwp;
> - hwp_mode_bdw = id->driver_data;
> +
> + if (vlp < 0 && !intel_pstate_acpi_pm_profile_server() &&
> + (id->driver_data & INTEL_PSTATE_HWP_VLP)) {
> + /* Enable VLP controller by default. */
> + use_vlp = true;
> + }
> +
> + pstate_funcs.update_util = use_vlp ?
> + intel_pstate_update_util_hwp_vlp :
> + intel_pstate_update_util_hwp;
This basically is only good in a prototype in my view.
There is an interface for selecting scaling algorithms in cpufreq already and
in order to avoid confusion, that one needs to be extended instead of
[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| 10 +-
drivers/base/power/main.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 2 +-
drivers/gpu/drm/i915/intel_runtime_pm.c| 2 +-
drivers/gpu/drm/radeon/radeon_kms.c| 2 +-
drivers/misc/mei/pci-me.c | 2 +-
drivers/misc/mei/pci-txe.c | 2 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/ethernet/intel/igc/igc_main.c | 2 +-
drivers/pci/pcie/portdrv_pci.c | 2 +-
include/linux/pm.h | 6 +++---
13 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/Documentation/driver-api/pm/devices.rst
b/Documentation/driver-api/pm/devices.rst
index f66c7b9126ea..4ace0eba4506 100644
--- a/Documentation/driver-api/pm/devices.rst
+++ b/Documentation/driver-api/pm/devices.rst
@@ -361,9 +361,9 @@ the phases are: ``prepare``, ``suspend``, ``suspend_late``,
``suspend_noirq``.
runtime PM disabled.
This feature also can be controlled by device drivers by using the
- ``DPM_FLAG_NEVER_SKIP`` and ``DPM_FLAG_SMART_PREPARE`` driver power
- management flags. [Typically, they are set at the time the driver is
- probed against the device in question by passing them to the
+ ``DPM_FLAG_NO_DIRECT_COMPLETE`` and ``DPM_FLAG_SMART_PREPARE`` driver
+ power management flags. [Typically, they are set at the time the driver
+ is probed against the device in question by passing them to the
:c:func:`dev_pm_set_driver_flags` helper function.] If the first of
these flags is set, the PM core will not apply the direct-complete
procedure described above to the given device and, consequenty, to any
diff --git a/Documentation/power/pci.rst b/Documentation/power/pci.rst
index aa1c7fce6cd0..9e1408121bea 100644
--- a/Documentation/power/pci.rst
+++ b/Documentation/power/pci.rst
@@ -1004,11 +1004,11 @@ including the PCI bus type. The flags should be set
once at the driver probe
time with the help of the dev_pm_set_driver_flags() function and they should
not
be updated directly afterwards.
-The DPM_FLAG_NEVER_SKIP flag prevents the PM core from using the
direct-complete
-mechanism allowing device suspend/resume callbacks to be skipped if the device
-is in runtime suspend when the system suspend starts. That also affects all of
-the ancestors of the device, so this flag should only be used if absolutely
-necessary.
+The DPM_FLAG_NO_DIRECT_COMPLETE flag prevents the PM core from using the
+direct-complete mechanism allowing device suspend/resume callbacks to be
skipped
+if the device is in runtime suspend when the system suspend starts. That also
+affects all of the ancestors of the device, so this flag should only be used if
+absolutely necessary.
The DPM_FLAG_SMART_PREPARE flag instructs the PCI bus type to only return a
positive value from pci_pm_prepare() if the ->prepare callback provided by the
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 21187ee37b22..aa9c8df9fc4b 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1850,7 +1850,7 @@ static int device_prepare(struct device *dev,
pm_message_t state)
spin_lock_irq(&dev->power.lock);
dev->power.direct_complete = state.event == PM_EVENT_SUSPEND &&
(ret > 0 || dev->power.no_pm_callbacks) &&
- !dev_pm_test_driver_flags(dev, DPM_FLAG_NEVER_SKIP);
+ !dev_pm_test_driver_flags(dev, DPM_FLAG_NO_DIRECT_COMPLETE);
spin_unlock_irq(&dev->power.lock);
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index fd1dc3236eca..a9086ea1ab60 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -191,7 +191,7 @@ int amdgpu_driver_load_kms(struct drm_device *dev, unsigned
long flags)
}
if (adev->runpm) {
- dev_pm_set_driver_flags(dev->dev, DPM_FLAG_NEVER_SKIP);
+ dev_pm_set_driver_flags(dev->dev, DPM_FLAG_NO_DIRECT_COMPLETE);
pm_runtime_use_autosuspend(dev->dev);
pm_runtime_set_autosuspend_delay(dev->dev, 5000);
pm_runtime_set_active(dev->dev);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index ad719c9602af..9cb2d7548daa 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -549,7 +549,7 @@ void intel_runtime_pm_enable(struct intel_runtime_pm *rpm)
[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.
* Added tags received so far.
---
Documentation/driver-api/pm/devices.rst| 6 +++---
Documentation/power/pci.rst| 10 +-
drivers/base/power/main.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 2 +-
drivers/gpu/drm/i915/intel_runtime_pm.c| 2 +-
drivers/gpu/drm/radeon/radeon_kms.c| 2 +-
drivers/misc/mei/pci-me.c | 2 +-
drivers/misc/mei/pci-txe.c | 2 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/ethernet/intel/igc/igc_main.c | 2 +-
drivers/pci/pcie/portdrv_pci.c | 2 +-
include/linux/pm.h | 6 +++---
13 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/Documentation/driver-api/pm/devices.rst
b/Documentation/driver-api/pm/devices.rst
index f66c7b9126ea..4ace0eba4506 100644
--- a/Documentation/driver-api/pm/devices.rst
+++ b/Documentation/driver-api/pm/devices.rst
@@ -361,9 +361,9 @@ the phases are: ``prepare``, ``suspend``, ``suspend_late``,
``suspend_noirq``.
runtime PM disabled.
This feature also can be controlled by device drivers by using the
- ``DPM_FLAG_NEVER_SKIP`` and ``DPM_FLAG_SMART_PREPARE`` driver power
- management flags. [Typically, they are set at the time the driver is
- probed against the device in question by passing them to the
+ ``DPM_FLAG_NO_DIRECT_COMPLETE`` and ``DPM_FLAG_SMART_PREPARE`` driver
+ power management flags. [Typically, they are set at the time the driver
+ is probed against the device in question by passing them to the
:c:func:`dev_pm_set_driver_flags` helper function.] If the first of
these flags is set, the PM core will not apply the direct-complete
procedure described above to the given device and, consequenty, to any
diff --git a/Documentation/power/pci.rst b/Documentation/power/pci.rst
index aa1c7fce6cd0..9e1408121bea 100644
--- a/Documentation/power/pci.rst
+++ b/Documentation/power/pci.rst
@@ -1004,11 +1004,11 @@ including the PCI bus type. The flags should be set
once at the driver probe
time with the help of the dev_pm_set_driver_flags() function and they should
not
be updated directly afterwards.
-The DPM_FLAG_NEVER_SKIP flag prevents the PM core from using the
direct-complete
-mechanism allowing device suspend/resume callbacks to be skipped if the device
-is in runtime suspend when the system suspend starts. That also affects all of
-the ancestors of the device, so this flag should only be used if absolutely
-necessary.
+The DPM_FLAG_NO_DIRECT_COMPLETE flag prevents the PM core from using the
+direct-complete mechanism allowing device suspend/resume callbacks to be
skipped
+if the device is in runtime suspend when the system suspend starts. That also
+affects all of the ancestors of the device, so this flag should only be used if
+absolutely necessary.
The DPM_FLAG_SMART_PREPARE flag instructs the PCI bus type to only return a
positive value from pci_pm_prepare() if the ->prepare callback provided by the
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 3170d93e29f9..dbc1e5e7346b 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1844,7 +1844,7 @@ static int device_prepare(struct device *dev,
pm_message_t state)
spin_lock_irq(&dev->power.lock);
dev->power.direct_complete = state.event == PM_EVENT_SUSPEND &&
(ret > 0 || dev->power.no_pm_callbacks) &&
- !dev_pm_test_driver_flags(dev, DPM_FLAG_NEVER_SKIP);
+ !dev_pm_test_driver_flags(dev, DPM_FLAG_NO_DIRECT_COMPLETE);
spin_unlock_irq(&dev->power.lock);
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index fd1dc3236eca..a9086ea1ab60 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -191,7 +191,7 @@ int amdgpu_driver_load_kms(struct drm_device *dev, unsigned
long flags)
}
if (adev->runpm) {
- dev_pm_set_driver_flags(dev->dev, DPM_FLAG_NEVER_SKIP);
+ dev_pm_set_driver_flags(dev->dev, DPM_FLAG_NO_DIRECT_COMPLETE);
pm_runtime_use_autosuspend(dev->dev);
pm_runtime_set_autosuspend_delay(dev->dev, 5000);
pm_runtime_set_active(dev->dev);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index ad719c9602af..9cb2d7548daa 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm
Re: [Intel-gfx] [PATCH] cpufreq/pstate: Only mention the BIOS disabling turbo mode once
On Friday, April 10, 2020 9:26:29 PM CEST Chris Wilson wrote:
> Make a note of the first time we discover the turbo mode has been
> disabled by the BIOS, as otherwise we complain every time we try to
> update the mode.
>
> Signed-off-by: Chris Wilson
> Cc: Srinivas Pandruvada
> 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 c81e1ff29069..b4c014464a20 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -1058,7 +1058,7 @@ static ssize_t store_no_turbo(struct kobject *a, struct
> kobj_attribute *b,
>
> update_turbo_state();
> if (global.turbo_disabled) {
> - pr_warn("Turbo disabled by BIOS or unavailable on processor\n");
> + pr_notice_once("Turbo disabled by BIOS or unavailable on
> processor\n");
> mutex_unlock(&intel_pstate_limits_lock);
> mutex_unlock(&intel_pstate_driver_lock);
> return -EPERM;
>
Applied as a fix for 5.7-rc4, sorry for the delay.
Thanks!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[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/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.c | 12 +---
drivers/gpu/drm/i915/intel_sideband.c | 5 +++--
3 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index c7424e2a04a3..208457005a11 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1360,7 +1360,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
* lowest possible wakeup latency and so prevent the cpu from going into
* deep sleep states.
*/
- pm_qos_update_request(&i915->pm_qos, 0);
+ cpu_latency_qos_update_request(&i915->pm_qos, 0);
intel_dp_check_edp(intel_dp);
@@ -1488,7 +1488,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
ret = recv_bytes;
out:
- pm_qos_update_request(&i915->pm_qos, PM_QOS_DEFAULT_VALUE);
+ cpu_latency_qos_update_request(&i915->pm_qos, PM_QOS_DEFAULT_VALUE);
if (vdd)
edp_panel_vdd_off(intel_dp, false);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f7385abdd74b..74481a189cfc 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -502,8 +502,7 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
mutex_init(&dev_priv->backlight_lock);
mutex_init(&dev_priv->sb_lock);
- pm_qos_add_request(&dev_priv->sb_qos,
- PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE);
+ cpu_latency_qos_add_request(&dev_priv->sb_qos, PM_QOS_DEFAULT_VALUE);
mutex_init(&dev_priv->av_mutex);
mutex_init(&dev_priv->wm.wm_mutex);
@@ -568,7 +567,7 @@ static void i915_driver_late_release(struct
drm_i915_private *dev_priv)
vlv_free_s0ix_state(dev_priv);
i915_workqueues_cleanup(dev_priv);
- pm_qos_remove_request(&dev_priv->sb_qos);
+ cpu_latency_qos_remove_request(&dev_priv->sb_qos);
mutex_destroy(&dev_priv->sb_lock);
}
@@ -1226,8 +1225,7 @@ static int i915_driver_hw_probe(struct drm_i915_private
*dev_priv)
}
}
- pm_qos_add_request(&dev_priv->pm_qos, PM_QOS_CPU_DMA_LATENCY,
- PM_QOS_DEFAULT_VALUE);
+ cpu_latency_qos_add_request(&dev_priv->pm_qos, PM_QOS_DEFAULT_VALUE);
intel_gt_init_workarounds(dev_priv);
@@ -1273,7 +1271,7 @@ static int i915_driver_hw_probe(struct drm_i915_private
*dev_priv)
err_msi:
if (pdev->msi_enabled)
pci_disable_msi(pdev);
- pm_qos_remove_request(&dev_priv->pm_qos);
+ cpu_latency_qos_remove_request(&dev_priv->pm_qos);
err_mem_regions:
intel_memory_regions_driver_release(dev_priv);
err_ggtt:
@@ -1296,7 +1294,7 @@ static void i915_driver_hw_remove(struct drm_i915_private
*dev_priv)
if (pdev->msi_enabled)
pci_disable_msi(pdev);
- pm_qos_remove_request(&dev_priv->pm_qos);
+ cpu_latency_qos_remove_request(&dev_priv->pm_qos);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index cbfb7171d62d..0648eda309e4 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -60,7 +60,7 @@ static void __vlv_punit_get(struct drm_i915_private *i915)
* to the Valleyview P-unit and not all sideband communications.
*/
if (IS_VALLEYVIEW(i915)) {
- pm_qos_update_request(&i915->sb_qos, 0);
+ cpu_latency_qos_update_request(&i915->sb_qos, 0);
on_each_cpu(ping, NULL, 1);
}
}
@@ -68,7 +68,8 @@ static void __vlv_punit_get(struct drm_i915_private *i915)
static void __vlv_punit_put(struct drm_i915_private *i915)
{
if (IS_VALLEYVIEW(i915))
- pm_qos_update_request(&i915->sb_qos, PM_QOS_DEFAULT_VALUE);
+ cpu_latency_qos_update_request(&i915->sb_qos,
+ PM_QOS_DEFAULT_VALUE);
iosf_mbi_punit_release();
}
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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.
>
> No intentional functional impact.
>
> Signed-off-by: Rafael J. Wysocki
Please note that the whole series is available here:
https://lore.kernel.org/linux-pm/1654227.8mz0SueHsU@kreacher/
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
> drivers/gpu/drm/i915/i915_drv.c | 12 +---
> drivers/gpu/drm/i915/intel_sideband.c | 5 +++--
> 3 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index c7424e2a04a3..208457005a11 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1360,7 +1360,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> * lowest possible wakeup latency and so prevent the cpu from going
> into
> * deep sleep states.
> */
> - pm_qos_update_request(&i915->pm_qos, 0);
> + cpu_latency_qos_update_request(&i915->pm_qos, 0);
>
> intel_dp_check_edp(intel_dp);
>
> @@ -1488,7 +1488,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
>
> ret = recv_bytes;
> out:
> - pm_qos_update_request(&i915->pm_qos, PM_QOS_DEFAULT_VALUE);
> + cpu_latency_qos_update_request(&i915->pm_qos, PM_QOS_DEFAULT_VALUE);
>
> if (vdd)
> edp_panel_vdd_off(intel_dp, false);
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f7385abdd74b..74481a189cfc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -502,8 +502,7 @@ static int i915_driver_early_probe(struct
> drm_i915_private *dev_priv)
> mutex_init(&dev_priv->backlight_lock);
>
> mutex_init(&dev_priv->sb_lock);
> - pm_qos_add_request(&dev_priv->sb_qos,
> - PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE);
> + cpu_latency_qos_add_request(&dev_priv->sb_qos, PM_QOS_DEFAULT_VALUE);
>
> mutex_init(&dev_priv->av_mutex);
> mutex_init(&dev_priv->wm.wm_mutex);
> @@ -568,7 +567,7 @@ static void i915_driver_late_release(struct
> drm_i915_private *dev_priv)
> vlv_free_s0ix_state(dev_priv);
> i915_workqueues_cleanup(dev_priv);
>
> - pm_qos_remove_request(&dev_priv->sb_qos);
> + cpu_latency_qos_remove_request(&dev_priv->sb_qos);
> mutex_destroy(&dev_priv->sb_lock);
> }
>
> @@ -1226,8 +1225,7 @@ static int i915_driver_hw_probe(struct drm_i915_private
> *dev_priv)
> }
> }
>
> - pm_qos_add_request(&dev_priv->pm_qos, PM_QOS_CPU_DMA_LATENCY,
> - PM_QOS_DEFAULT_VALUE);
> + cpu_latency_qos_add_request(&dev_priv->pm_qos, PM_QOS_DEFAULT_VALUE);
>
> intel_gt_init_workarounds(dev_priv);
>
> @@ -1273,7 +1271,7 @@ static int i915_driver_hw_probe(struct drm_i915_private
> *dev_priv)
> err_msi:
> if (pdev->msi_enabled)
> pci_disable_msi(pdev);
> - pm_qos_remove_request(&dev_priv->pm_qos);
> + cpu_latency_qos_remove_request(&dev_priv->pm_qos);
> err_mem_regions:
> intel_memory_regions_driver_release(dev_priv);
> err_ggtt:
> @@ -1296,7 +1294,7 @@ static void i915_driver_hw_remove(struct
> drm_i915_private *dev_priv)
> if (pdev->msi_enabled)
> pci_disable_msi(pdev);
>
> - pm_qos_remove_request(&dev_priv->pm_qos);
> + cpu_latency_qos_remove_request(&dev_priv->pm_qos);
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_sideband.c
> b/drivers/gpu/drm/i915/intel_sideband.c
> index cbfb7171d62d..0648eda309e4 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -60,7 +60,7 @@ static void __vlv_punit_get(struct drm_i915_private *i915)
> * to the Valleyview P-unit and not all sideband communications.
> */
> if (IS_VALLEYVIEW(i915)) {
> - pm_qos_update_request(&i915->sb_qos, 0);
> + cpu_latency_qos_update_request(&i915->sb_qos, 0);
> on_each_cpu(ping, NULL, 1);
> }
> }
> @@ -68,7 +68,8 @@ static void __vlv_punit_get(struct drm_i915_private *i915)
> static void __vlv_punit_put(struct drm_i915_private *i915)
> {
> if (IS_VALLEYVIEW(i915))
> - pm_qos_update_request(&i915->sb_qos, PM_QOS_DEFAULT_VALUE);
> + cpu_latency_qos_update_request(&i915->sb_qos,
> + PM_QOS_DEFAULT_VALUE);
>
> iosf_mbi_punit_release();
> }
> --
> 2.16.4
>
>
>
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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. > > We're also complaining about the inability to recruit maintainers: > > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ > > And burn out: > > http://antirez.com/news/129 Right. > The whole crux of your argument seems to be maintainers' time isn't > important so we should accept all trivial patches ... I'm pushing back > on that assumption in two places, firstly the valulessness of the time > and secondly that all trivial patches are valuable. > > > If some company does not want to pay for that, that's fine, but they > > don't get to be maintainers and claim `Supported`. > > What I'm actually trying to articulate is a way of measuring value of > the patch vs cost ... it has nothing really to do with who foots the > actual bill. > > One thesis I'm actually starting to formulate is that this continual > devaluing of maintainers is why we have so much difficulty keeping and > recruiting them. Absolutely. This is just one of the factors involved, but a significant one IMV. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 Mon, Apr 27, 2020 at 08:22:47PM -0700, Francisco Jerez wrote: > >> This addresses the technical concerns people brought up about my > >> previous v2 revision of this series. Other than a few bug fixes, the > >> only major change relative to v2 is that the controller is now exposed > >> as a new CPUFREQ generic governor as requested by Rafael (named > >> "adaptive" in this RFC though other naming suggestions are welcome). > >> Main reason for calling this v2.99 rather than v3 is that I haven't > >> yet addressed all the documentation requests from the v2 thread -- > >> Will spend some time doing that as soon as I have an ACK (ideally from > >> Rafael) that things are moving in the right direction. > >>=20 > >> You can also find this series along with the WIP code for non-HWP > >> platforms in this branch: > >>=20 > >> https://github.com/curro/linux/tree/intel_pstate-vlp-v2.99 > >>=20 > >> Thanks! > >>=20 > >> [PATCHv2.99 01/11] PM: QoS: Add CPU_SCALING_RESPONSE global PM QoS limit. > >> [PATCHv2.99 02/11] drm/i915: Adjust PM QoS scaling response frequency ba= > sed on GPU load. > >> [PATCHv2.99 03/11] OPTIONAL: drm/i915: Expose PM QoS control parameters = > via debugfs. > >> [PATCHv2.99 04/11] cpufreq: Define ADAPTIVE frequency governor policy. > >> [PATCHv2.99 05/11] cpufreq: intel_pstate: Reorder intel_pstate_clear_upd= > ate_util_hook() and intel_pstate_set_update_util_hook(). > >> [PATCHv2.99 06/11] cpufreq: intel_pstate: Call intel_pstate_set_update_u= > til_hook() once from the setpolicy hook. > >> [PATCHv2.99 07/11] cpufreq: intel_pstate: Implement VLP controller stati= > stics and target range calculation. > >> [PATCHv2.99 08/11] cpufreq: intel_pstate: Implement VLP controller for H= > WP parts. > >> [PATCHv2.99 09/11] cpufreq: intel_pstate: Enable VLP controller based on= > ACPI FADT profile and CPUID. > >> [PATCHv2.99 10/11] OPTIONAL: cpufreq: intel_pstate: Add tracing of VLP c= > ontroller status. > >> [PATCHv2.99 11/11] OPTIONAL: cpufreq: intel_pstate: Expose VLP controlle= > r parameters via debugfs. > > > > What I'm missing is an explanation for why this isn't using the > > infrastructure that was build for these kinds of things? The thermal > > framework, was AFAIU, supposed to help with these things, and the IPA > > thing in particular is used by ARM to do exactly this GPU/CPU power > > budget thing. > > > > If thermal/IPA is found wanting, why aren't we improving that? > > The GPU/CPU power budget "thing" is only a positive side effect of this > series on some TDP-bound systems. Its ultimate purpose is improving the > energy efficiency of workloads which have a bottleneck on a device other > than the CPU, by giving the bottlenecking device driver some influence > over the response latency of CPUFREQ governors via a PM QoS interface. > This seems to be completely outside the scope of the thermal framework > and IPA AFAIU. > > > > > How much of that ADAPTIVE crud is actually intel_pstate specific? On a > > (really) quick read it appears to me that much of the controller bits > > there can be applied more generic, and thus should not be part of any > > one governor. > > > > The implementation of that is intel_pstate-specific right now, but the > basic algorithm could be made to work on any other governor in > principle, which is why it is exposed as a generic CPUFREQ governor. I > don't care about taking out the generic CPUFREQ governor changes if you > don't like them, and going back to some driver-specific means of turning > it on and off (though Rafael might disagree with that). > > > Specifically, I want to use sched_util as cpufreq governor and use the > > intel_pstate as a passive driver. > > Yeah, getting a similar optimization into the schedutil governor has > been on my wish list for a while, but I haven't had the time to get very > far on that except for a handful of hacks. The intel_pstate handling is > going to be necessary anyway in order to handle HWP systems gracefully, > at least in the near future until schedutil becomes a viable alternative > to intel_pstate in active mode on HWP systems. FWIW, work is under way to make intel_pstate in the passive mode work on HWP systems. I have a prototype patch for that, but it can be improved. I'll post a new version of it for review, possibly next week. Cheers! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 01/15] ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase
On Sat, Jun 20, 2020 at 2:18 PM Hans de Goede wrote:
>
> The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
> controller gets poked from the _PS0 method of the graphics-card device:
>
> Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> If (((Local0 & 0x03) == 0x03))
> {
> PSAT &= 0xFFFC
> Local1 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> RSTA = Zero
> RSTF = Zero
> RSTA = One
> RSTF = One
> PWMB |= 0xC000
> PWMC = PWMB /* \_SB_.PCI0.GFX0.PWMB */
> }
>
> Where PSAT is the power-status register of the PWM controller, so if it
> is in D3 when the GFX0 device's PS0 method runs then it will turn it on
> and restore the PWM ctrl register value it saved from its PS3 handler.
> Note not only does it restore it, it ors it with 0xC000 turning it
> on at a time where we may not want it to get turned on at all.
>
> The pwm_get call which the i915 driver does to get a reference to the
> PWM controller, already adds a device-link making the GFX0 device a
> consumer of the PWM device. So it should already have been resumed when
> the above AML runs and the AML should thus not do its undesirable poking
> of the PWM controller register.
>
> But the PCI core powers on PCI devices in the no-irq resume phase and
> thus calls the troublesome PS0 method in the no-irq resume phase.
> Where as LPSS devices by default are resumed in the early resume phase.
>
> This commit sets the resume_from_noirq flag in the bsw_pwm_dev_desc
> struct, so that Cherry Trail PWM controllers will be resumed in the
> no-irq phase. Together with the 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 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> index c5a5a179f49d..446e666b3466 100644
> --- a/drivers/acpi/acpi_lpss.c
> +++ b/drivers/acpi/acpi_lpss.c
> @@ -257,6 +257,7 @@ static const struct lpss_device_desc bsw_pwm_dev_desc = {
> .flags = LPSS_SAVE_CTX | LPSS_NO_D3_DELAY,
> .prv_offset = 0x800,
> .setup = bsw_pwm_setup,
> + .resume_from_noirq = true,
> };
>
> static const struct lpss_device_desc byt_uart_dev_desc = {
> --
> 2.26.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation)
On Sat, Jun 20, 2020 at 2:18 PM Hans de Goede wrote:
>
> The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
> controller gets turned off from the _PS3 method of the graphics-card dev:
>
> Method (_PS3, 0, Serialized) // _PS3: Power State 3
> {
> ...
> PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> PSAT |= 0x03
> Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> ...
> }
>
> Where PSAT is the power-status register of the PWM controller.
>
> Since the i915 driver will do a pwm_get on the pwm device as it uses it to
> control the LCD panel backlight, there is a device-link marking the i915
> device as a consumer of the pwm device. So that the PWM controller will
> always be suspended after the i915 driver suspends (which is the right
> thing to do). This causes the above GFX0 PS3 AML code to run before
> acpi_lpss.c calls acpi_lpss_save_ctx().
>
> So on these devices the PWM controller will already be off when
> acpi_lpss_save_ctx() runs. This causes it to read/save all 1-s (0x)
> as ctx register values.
>
> When these bogus values get restored on resume the PWM controller actually
> keeps working, since most bits are reserved, but this does set bit 3 of
> the LPSS General purpose register, which for the PWM controller has the
> following function: "This bit is re-used to support 32kHz slow mode.
> Default is 19.2MHz as PWM source clock".
>
> This causes the clock of the PWM controller to switch from 19.2MHz to
> 32KHz, which is a slow-down of a factor 600. Surprisingly enough so far
> there have been few bug reports about this. This is likely because the
> i915 driver was hardcoding the PWM frequency to 46 KHz, which divided
> by 600 would result in a PWM frequency of approx. 78 Hz, which mostly
> still works fine. There are some bug reports about the LCD backlight
> flickering after suspend/resume which are likely caused by this issue.
>
> But with the upcoming patch-series to finally switch the i915 drivers
> code for external PWM controllers to use the atomic API and to honor
> the PWM frequency specified in the video BIOS (VBT), this becomes a much
> bigger problem. On most cases the VBT specifies either 200 Hz or 20
> KHz as PWM frequency, which with the mentioned issue ends up being either
> 1/3 Hz, where the backlight actually visible blinks on and off every 3s,
> or in 33 Hz and horrible flickering of the backlight.
>
> There are a number of possible solutions to this problem:
>
> 1. Make acpi_lpss_save_ctx() run before GFX0._PS3
> Pro: Clean solution from pov of not medling with save/restore ctx code
> Con: As mentioned the current ordering is the right thing to do
> Con: Requires assymmetry in at what suspend/resume phase we do the save vs
> restore, requiring more suspend/resume ordering hacks in already
> convoluted acpi_lpss.c suspend/resume code.
> 2. Do some sort of save once mode for the LPSS ctx
> Pro: Reasonably clean
> Con: Needs a new LPSS flag + code changes to handle the flag
> 3. Detect we have failed to save the ctx registers and do not restore them
> Pro: Not PWM specific, might help with issues on other LPSS devices too
> Con: If we can get away with not restoring the ctx why bother with it at
> all?
> 4. Do not save the ctx for CHT PWM controllers
> Pro: Clean, as simple as dropping a flag?
> Con: Not so simple as dropping a flag, needs a new flag to ensure that
> we still do lpss_deassert_reset() on device activation.
> 5. Make the pwm-lpss code fixup the LPSS-context registers
> Pro: Keeps acpi_lpss.c code clean
> Con: Moves knowledge of LPSS-context into the pwm-lpss.c code
>
> 1 and 5 both do not seem to be a desirable way forward.
>
> 3 and 4 seem ok, but they both assume that restoring the LPSS-context
> registers is not necessary. I have done a couple 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 leaves solution 2, which is about as simple / clean as 3 and 4,
> so this commit fixes the described problem by implementing a new
> LPSS_SAVE_CTX_ONCE flag and setting that for the CHT PWM controllers.
>
> Signed-off-by: Hans de Goede
Acked-by: Rafael J. Wysocki
> ---
> Changes in v2:
> - Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX
> ---
> drivers/acpi/acpi_lpss.c | 21 +
> 1 file changed, 17 insertions(+), 4 d
Re: [Intel-gfx] [-next PATCH 3/4] treewide: Use DEVICE_ATTR_RO
O(type); > > #define HV_CONF_ATTR(name, conf) \ > static ssize_t name ## _show(struct device *dev,\ > diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c > index a041689e5701..545e91420cde 100644 > --- a/drivers/acpi/device_sysfs.c > +++ b/drivers/acpi/device_sysfs.c > @@ -357,7 +357,7 @@ static ssize_t real_power_state_show(struct device *dev, > return sprintf(buf, "%s\n", acpi_power_state_string(state)); > } > > -static DEVICE_ATTR(real_power_state, 0444, real_power_state_show, NULL); > +static DEVICE_ATTR_RO(real_power_state); > > static ssize_t power_state_show(struct device *dev, > struct device_attribute *attr, char *buf) > @@ -367,7 +367,7 @@ static ssize_t power_state_show(struct device *dev, > return sprintf(buf, "%s\n", acpi_power_state_string(adev->power.state)); > } > > -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 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] 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 *kdev)
+{
+ /*
+* Get a reference to disable the direct complete optimization. This
+* is needed, since we have a suspend sequence specific to system
+* suspend (that is different from runtime suspend) and because we
+* need to provide power to the sound driver while its system suspend
+* handler is running. This is not possible with the optimization in
+* effect, when the i915 runtime PM is disabled for the whole duration
+* of the suspend sequence if the device was already runtime
+* suspended at the beginning of the sequence. In this case the i915
+* suspend/resume hooks would be also skipped (besides its prepare and
+* complete hooks).
+*/
+ intel_runtime_pm_get(kdev_to_i915(kdev));
+
+ return 0;
+}
+
+static void i915_pm_complete(struct device *kdev)
+{
+ /* Put the ref taken in the prepare step. */
+ intel_runtime_pm_put(kdev_to_i915(kdev));
Do we always call i915_pm_complete() if any of the post-prepare suspend
steps fail? Otherwise, it looks very sensible from our pov.
Yes, it's called even in the failure case (for S3 for example
suspend_devices_and_enter()->Recover_platform:->Resume_devices:->
dpm_resume_end()->dpm_complete()).
->prepare and ->complete are not the most friendly places to do these
things, though, because then the whole kernel needs to wait for them to
return and if they take time, it goes ugly.
Have you considered adding a need_resume flag to struct pci_dev, setting
it for i915 and checking it along with platform_pci_need_resume() in
pci_dev_keep_suspended()?
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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
> {
> If (OSID == One)
> {
> Return (Zero)
> }
>
> Return (0x0F)
> }
>
> Where OSID is some dark magic seen in all Cherry Trail ACPI tables making
> the machine behave differently depending on which OS it *thinks* it is
> booting, this gets set in a number of ways which we cannot control, on
> some newer machines it simple hardcoded to "One" aka win10.
>
> This causes the PWM controller to get hidden, which means Linux cannot
> control the backlight level on cht based tablets / laptops.
>
> Since loading the driver for this does no harm (the only in kernel user
> of it is the i915 driver, which will only use it when it needs it), this
> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
> for the 80862288 device, fixing the lack of backlight control.
>
> Signed-off-by: Hans de Goede
> ---
> Changes in v2:
> -Use pr_debug instead of ACPI_DEBUG_PRINT
> Changes in v3:
> -Un-inline acpi_set_device_status and do the always_present_device_ids
> table check inside the un-inlined version of it
> Changes in v4:
> -Use dev_info instead of pr_debug
> -Not only check for ACPI HID but also for CPU (SoC) model so as to not
> for devices present on other models then for which the quirk is intended and
> to avoid enabling unrelated ACPI devices which happen to use the same HID
> Changes in v5:
> -Only do the dev_info once per device (acpi_set_device_status gets called
> multiple times per device during boot)
> Changes in v6:
> -Allow specifying more then one CPU-model for a single HID
> -Not only match the HID but also the UID, like on Cherry Trail, on some Bay
> Trail Windows 10 tablets we need to enable the PWM controller to get working
> backlight even though _STA returns 0. The Bay Trail SoC has 2 PWM controllers
> and we only need the first one. UID matching will allows adding an entry for
> Bay Trail which only enables the first PWM controller
> ---
> drivers/acpi/bus.c | 65
> +
> include/acpi/acpi_bus.h | 6 +
> 2 files changed, 66 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 34fbe02..eb30630 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -34,6 +34,8 @@
> #include
> #include
> #ifdef CONFIG_X86
> +#include
> +#include
> #include
> #endif
> #include
> @@ -132,6 +134,69 @@ int acpi_bus_get_status(struct acpi_device *device)
> }
> EXPORT_SYMBOL(acpi_bus_get_status);
>
> +#ifdef CONFIG_X86
> +/*
> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because
> + * some recent Windows drivers bind to one device but poke at multiple
> + * devices at the same time, so the others get hidden.
> + * We work around this by always reporting ACPI_STA_DEFAULT for these
> + * devices. Note this MUST only be done for devices where this is safe.
> + *
> + * This forcing of devices to be present is limited to specific CPU (SoC)
> + * models both to avoid potentially causing trouble on other models and
> + * because some HIDs are re-used on different SoCs for completely
> + * different devices.
> + */
> +struct always_present_device_id {
> + struct acpi_device_id hid[2];
> + struct x86_cpu_id cpu_ids[2];
This really is x86-specific, so it should go into somewhere like
arch/x86/kernel/acpi/ or drivers/acpi/x86/ (not present yet).
> + const char *uid;
> +};
> +
> +#define ICPU(model){ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
> +
> +#define ENTRY(hid, uid, cpu_models) { \
> + { { hid, }, {} }, \
> + { cpu_models, {} }, \
> + uid,\
> +}
> +
> +static const struct always_present_device_id always_present_device_ids[] = {
> + /*
> +* Cherry Trail PWM directly poked by GPU driver in win10,
> +* but Linux uses a separate PWM driver, harmless if not used.
> +*/
> + ENTRY("80862288", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT)),
> +};
> +#endif
> +
> +void acpi_set_device_status(struct acpi_device *adev, u32 sta)
> +{
> + u32 *status = (u32 *)&adev->status;
> +#ifdef CONFIG_X86
> + u32 old_status = *status;
> + int i;
> +
> + /* acpi_match_device_ids checks status, so start with default */
> + *status = ACPI_STA_DEFAULT;
> + for (i = 0; i < ARRAY_SIZE(always_present_device_ids); i++) {
> + if (acpi_match_device_ids(adev,
> + always_present_device_ids[i].hid) == 0 &&
> + adev->pnp.unique_id &&
> +
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 wrote:
> Hi,
>
>
> On 18-04-17 15:34, Rafael J. Wysocki wrote:
>>
>> 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
>>> {
>>> If (OSID == One)
>>> {
>>> Return (Zero)
>>> }
>>>
>>> Return (0x0F)
>>> }
>>>
>>> Where OSID is some dark magic seen in all Cherry Trail ACPI tables making
>>> the machine behave differently depending on which OS it *thinks* it is
>>> booting, this gets set in a number of ways which we cannot control, on
>>> some newer machines it simple hardcoded to "One" aka win10.
>>>
>>> This causes the PWM controller to get hidden, which means Linux cannot
>>> control the backlight level on cht based tablets / laptops.
>>>
>>> Since loading the driver for this does no harm (the only in kernel user
>>> of it is the i915 driver, which will only use it when it needs it), this
>>> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
>>> for the 80862288 device, fixing the lack of backlight control.
>>>
>>> Signed-off-by: Hans de Goede
>>> ---
>>> Changes in v2:
>>> -Use pr_debug instead of ACPI_DEBUG_PRINT
>>> Changes in v3:
>>> -Un-inline acpi_set_device_status and do the always_present_device_ids
>>> table check inside the un-inlined version of it
>>> Changes in v4:
>>> -Use dev_info instead of pr_debug
>>> -Not only check for ACPI HID but also for CPU (SoC) model so as to not
>>> for devices present on other models then for which the quirk is intended
>>> and
>>> to avoid enabling unrelated ACPI devices which happen to use the same
>>> HID
>>> Changes in v5:
>>> -Only do the dev_info once per device (acpi_set_device_status gets called
>>> multiple times per device during boot)
>>> Changes in v6:
>>> -Allow specifying more then one CPU-model for a single HID
>>> -Not only match the HID but also the UID, like on Cherry Trail, on some
>>> Bay
>>> Trail Windows 10 tablets we need to enable the PWM controller to get
>>> working
>>> backlight even though _STA returns 0. The Bay Trail SoC has 2 PWM
>>> controllers
>>> and we only need the first one. UID matching will allows adding an entry
>>> for
>>> Bay Trail which only enables the first PWM controller
>>> ---
>>> drivers/acpi/bus.c | 65
>>> +
>>> include/acpi/acpi_bus.h | 6 +
>>> 2 files changed, 66 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>>> index 34fbe02..eb30630 100644
>>> --- a/drivers/acpi/bus.c
>>> +++ b/drivers/acpi/bus.c
>>> @@ -34,6 +34,8 @@
>>> #include
>>> #include
>>> #ifdef CONFIG_X86
>>> +#include
>>> +#include
>>> #include
>>> #endif
>>> #include
>>> @@ -132,6 +134,69 @@ int acpi_bus_get_status(struct acpi_device *device)
>>> }
>>> EXPORT_SYMBOL(acpi_bus_get_status);
>>>
>>> +#ifdef CONFIG_X86
>>> +/*
>>> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
>>> because
>>> + * some recent Windows drivers bind to one device but poke at multiple
>>> + * devices at the same time, so the others get hidden.
>>> + * We work around this by always reporting ACPI_STA_DEFAULT for these
>>> + * devices. Note this MUST only be done for devices where this is safe.
>>> + *
>>> + * This forcing of devices to be present is limited to specific CPU
>>> (SoC)
>>> + * models both to avoid potentially causing trouble on other models and
>>> + * because some HIDs are re-used on different SoCs for completely
>>> + * different devices.
>>> + */
>>> +struct always_present_device_id {
>>> + struct acpi_device_id hid[2];
>>> + struct x86_cpu_id cpu_ids[2];
>>
>>
>> This really is x86-specific, so it should go into somewhere like
>> arch/x86/kernel/acpi/ or drivers/acpi/x86/ (not present yet).
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 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 wrote:
>> > On 18-04-17 15:34, Rafael J. Wysocki wrote:
>> >> 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
>> >>> {
>> >>> If (OSID == One)
>> >>> {
>> >>> Return (Zero)
>> >>> }
>> >>>
>> >>> Return (0x0F)
>> >>> }
>> >>>
>> >>> Where OSID is some dark magic seen in all Cherry Trail ACPI tables making
>> >>> the machine behave differently depending on which OS it *thinks* it is
>> >>> booting, this gets set in a number of ways which we cannot control, on
>> >>> some newer machines it simple hardcoded to "One" aka win10.
>> >>>
>> >>> This causes the PWM controller to get hidden, which means Linux cannot
>> >>> control the backlight level on cht based tablets / laptops.
>> >>>
>> >>> Since loading the driver for this does no harm (the only in kernel user
>> >>> of it is the i915 driver, which will only use it when it needs it), this
>> >>> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
>> >>> for the 80862288 device, fixing the lack of backlight control.
>> >>>
>> >>> Signed-off-by: Hans de Goede
>> >>> ---
>> >>> drivers/acpi/bus.c | 65
>> >>> +
>> >>> include/acpi/acpi_bus.h | 6 +
>> >>> 2 files changed, 66 insertions(+), 5 deletions(-)
>> >>>
>> >>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>> >>> index 34fbe02..eb30630 100644
>> >>> --- a/drivers/acpi/bus.c
>> >>> +++ b/drivers/acpi/bus.c
>> >>> @@ -34,6 +34,8 @@
>> >>> #include
>> >>> #include
>> >>> #ifdef CONFIG_X86
>> >>> +#include
>> >>> +#include
>> >>> #include
>> >>> #endif
>> >>> #include
>> >>> @@ -132,6 +134,69 @@ int acpi_bus_get_status(struct acpi_device *device)
>> >>> }
>> >>> EXPORT_SYMBOL(acpi_bus_get_status);
>> >>>
>> >>> +#ifdef CONFIG_X86
>> >>> +/*
>> >>> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
>> >>> because
>> >>> + * some recent Windows drivers bind to one device but poke at multiple
>> >>> + * devices at the same time, so the others get hidden.
>> >>> + * We work around this by always reporting ACPI_STA_DEFAULT for these
>> >>> + * devices. Note this MUST only be done for devices where this is safe.
>> >>> + *
>> >>> + * This forcing of devices to be present is limited to specific CPU
>> >>> (SoC)
>> >>> + * models both to avoid potentially causing trouble on other models and
>> >>> + * because some HIDs are re-used on different SoCs for completely
>> >>> + * different devices.
>> >>> + */
>> >>> +struct always_present_device_id {
>> >>> + struct acpi_device_id hid[2];
>> >>> + struct x86_cpu_id cpu_ids[2];
>> >>
>> >> This really is x86-specific, so it should go into somewhere like
>> >> arch/x86/kernel/acpi/ or drivers/acpi/x86/ (not present yet).
>> >
>> > Ok, but then how do you want to hook this up, before you said
>> > that you wanted to deal with this in acpi_set_device_status(),
>> > which belongs in drivers/acpi/bus.c, do you want the x86
>> > code to provide something like a
>> >
>> > bool acpi_device_always_present(struct acpi_device *adev) {
>> > }
>> >
>> > Helper function and use that in the drivers/acpi/bus.c
>> > acpi_set_device_status() implementation ?
>>
>> Yes, something like that.
>>
>> In a header file you can make it depend on CONFIG_X86 and provide and
>&
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
> {
> If (OSID == One)
> {
> Return (Zero)
> }
>
> Return (0x0F)
> }
>
> Where OSID is some dark magic seen in all Cherry Trail ACPI tables making
> the machine behave differently depending on which OS it *thinks* it is
> booting, this gets set in a number of ways which we cannot control, on
> some newer machines it simple hardcoded to "One" aka win10.
>
> This causes the PWM controller to get hidden, which means Linux cannot
> control the backlight level on cht based tablets / laptops.
>
> Since loading the driver for this does no harm (the only in kernel user
> of it is the i915 driver, which will only uses it when it needs it), this
> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
> for the LPSS PWM device, fixing the lack of backlight control.
>
> Signed-off-by: Hans de Goede
> ---
> Changes in v2:
> -Use pr_debug instead of ACPI_DEBUG_PRINT
> Changes in v3:
> -Un-inline acpi_set_device_status and do the always_present_device_ids
> table check inside the un-inlined version of it
> Changes in v4:
> -Use dev_info instead of pr_debug
> -Not only check for ACPI HID but also for CPU (SoC) model so as to not
> for devices present on other models then for which the quirk is intended and
> to avoid enabling unrelated ACPI devices which happen to use the same HID
> Changes in v5:
> -Only do the dev_info once per device (acpi_set_device_status gets called
> multiple times per device during boot)
> Changes in v6:
> -Allow specifying more then one CPU-model for a single HID
> -Not only match the HID but also the UID, like on Cherry Trail, on some Bay
> Trail Windows 10 tablets we need to enable the PWM controller to get working
> backlight even though _STA returns 0. The Bay Trail SoC has 2 PWM controllers
> and we only need the first one. UID matching will allows adding an entry for
> Bay Trail which only enables the first PWM controller
> Changes in v7:
> -Put the actual x86 specific matching code and table with always present
> device HID + UID + CPU model entries in a new x86/x86_utils.c file which
> provides an acpi_device_always_present() helper function on x86, on
> non x86 a stub which always returns false is provided
> -Squash in the addition of the Bay Trail PWM entry in the table as it
> is there for the same reasons as the Cherry Trail entry is there
> ---
> drivers/acpi/Makefile| 1 +
> drivers/acpi/bus.c | 10 ++
> drivers/acpi/x86/x86_utils.c | 85
>
> include/acpi/acpi_bus.h | 15 +---
> 4 files changed, 106 insertions(+), 5 deletions(-)
> create mode 100644 drivers/acpi/x86/x86_utils.c
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index d78065c..f3940ac 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -50,6 +50,7 @@ acpi-$(CONFIG_ACPI_REDUCED_HARDWARE_ONLY) += evged.o
> acpi-y += sysfs.o
> acpi-y += property.o
> acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
> +acpi-$(CONFIG_X86) += x86/x86_utils.o
> acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
> acpi-$(CONFIG_ACPI_NUMA) += numa.o
> acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 34fbe02..4d952cc 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -132,6 +132,16 @@ int acpi_bus_get_status(struct acpi_device *device)
> }
> EXPORT_SYMBOL(acpi_bus_get_status);
>
> +void acpi_set_device_status(struct acpi_device *adev, u32 sta)
> +{
> + u32 *status = (u32 *)&adev->status;
> +
> + if (acpi_device_always_present(adev))
> + *status = ACPI_STA_DEFAULT;
> + else
> + *status = sta;
*((u32 *)&adev->status) = acpi_device_always_present(adev) ?
ACPI_STA_DEFAULT : sta;
and I guess it could still be static inline?
But that said, evaluating _STA for the always present devices is
pointless (as Lukas noticed), so why not to modify
acpi_bus_get_status() to do something like:
if (acpi_device_always_present(adev)) {
acpi_set_device_status(adev, ACPI_STA_DEFAULT);
return 0;
}
upfront and modify the other path invoking acpi_set_device_status() accordingly.
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 acpi_add_single_object() like
acpi_init_device_object(device, handle, type, sta);
if (acpi_device_always_present(adev))
acpi_set_device_status(adev, ACPI_STA_DEFAULT);
Thanks,
Rafael
__
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 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
> >> {
> >> If (OSID == One)
> >> {
> >> Return (Zero)
> >> }
> >>
> >> Return (0x0F)
> >> }
> >>
> >> Where OSID is some dark magic seen in all Cherry Trail ACPI tables making
> >> the machine behave differently depending on which OS it *thinks* it is
> >> booting, this gets set in a number of ways which we cannot control, on
> >> some newer machines it simple hardcoded to "One" aka win10.
> >>
> >> This causes the PWM controller to get hidden, which means Linux cannot
> >> control the backlight level on cht based tablets / laptops.
> >>
> >> Since loading the driver for this does no harm (the only in kernel user
> >> of it is the i915 driver, which will only uses it when it needs it), this
> >> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
> >> for the LPSS PWM device, fixing the lack of backlight control.
> >>
> >> Signed-off-by: Hans de Goede
> >> ---
> >> Changes in v2:
> >> -Use pr_debug instead of ACPI_DEBUG_PRINT
> >> Changes in v3:
> >> -Un-inline acpi_set_device_status and do the always_present_device_ids
> >> table check inside the un-inlined version of it
> >> Changes in v4:
> >> -Use dev_info instead of pr_debug
> >> -Not only check for ACPI HID but also for CPU (SoC) model so as to not
> >> for devices present on other models then for which the quirk is intended
> >> and
> >> to avoid enabling unrelated ACPI devices which happen to use the same HID
> >> Changes in v5:
> >> -Only do the dev_info once per device (acpi_set_device_status gets called
> >> multiple times per device during boot)
> >> Changes in v6:
> >> -Allow specifying more then one CPU-model for a single HID
> >> -Not only match the HID but also the UID, like on Cherry Trail, on some Bay
> >> Trail Windows 10 tablets we need to enable the PWM controller to get
> >> working
> >> backlight even though _STA returns 0. The Bay Trail SoC has 2 PWM
> >> controllers
> >> and we only need the first one. UID matching will allows adding an entry
> >> for
> >> Bay Trail which only enables the first PWM controller
> >> Changes in v7:
> >> -Put the actual x86 specific matching code and table with always present
> >> device HID + UID + CPU model entries in a new x86/x86_utils.c file which
> >> provides an acpi_device_always_present() helper function on x86, on
> >> non x86 a stub which always returns false is provided
> >> -Squash in the addition of the Bay Trail PWM entry in the table as it
> >> is there for the same reasons as the Cherry Trail entry is there
>
>
>
> >> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> >> index 34fbe02..4d952cc 100644
> >> --- a/drivers/acpi/bus.c
> >> +++ b/drivers/acpi/bus.c
> >> @@ -132,6 +132,16 @@ int acpi_bus_get_status(struct acpi_device *device)
> >> }
> >> EXPORT_SYMBOL(acpi_bus_get_status);
> >>
> >> +void acpi_set_device_status(struct acpi_device *adev, u32 sta)
> >> +{
> >> + u32 *status = (u32 *)&adev->status;
> >> +
> >> + if (acpi_device_always_present(adev))
> >> + *status = ACPI_STA_DEFAULT;
> >> + else
> >> + *status = sta;
> >
> > *((u32 *)&adev->status) = acpi_device_always_present(adev) ?
> > ACPI_STA_DEFAULT : sta;
> >
> > and I guess it could still be static inline?
> >
> > But that said, evaluating _STA for the always present devices is
> > pointless (as Lukas noticed), so why not to modify
> > acpi_bus_get_status() to do something like:
> >
> > if (acpi_device_always_present(adev)) {
> > acpi_set_device_status(adev, ACPI_STA_DEFAULT);
> > return 0;
> > }
> >
> > upfront
>
> Hehe, my v1 of this patch actually did the check in acpi_bus_get_status()
> I moved it to acpi_set_device
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 acpi_add_single_object() like > >>> > >>> acpi_init_device_object(device, handle, type, sta); > >>> if (acpi_device_always_present(adev)) > >>> acpi_set_device_status(adev, ACPI_STA_DEFAULT); > >> > >> That is not necessary, the place(s) where we care about status being > >> fixed-up for always-present devices, so that they get scanned / their > >> platform device initiated, is in acpi_bus_attach() which > >> already calls acpi_bus_get_status() and thus gets the > >> acpi_device_always_present() check applied before checking. > >> > >> For hotplugged devices there are acpi_scan_bus_check and > >> acpi_scan_device_check but those both also already call > >> acpi_bus_get_status() before checking adev->status. > > > > OK > > > > Which probably means that we don't need to initialize adev->status > > in acpi_init_device_object() to anything meaningful, do we? > > Right, I don't think that is necessary. But maybe it is necessary > for some special cases (e.g. power resources) ? For power resources _STA is defined differently at all and we don't even call acpi_add_single_object() for them. :-) Are there any other special cases in which that may matter? Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 differences in their runtime and system > > > suspend sequence. Add a flag that when set resumes the device before > > > calling the driver's system suspend handlers which effectively disables > > > the optimization. > > > > FWIW, there are at least two alternative solutions to this problem which > > do not require changes to the PCI core: > > > > (1) Add a ->prepare hook to i915_pm_ops which calls pm_runtime_get_sync() > > and a ->complete hook which calls pm_runtime_put(). > > Thinking a bit more about this, it's even simpler: The PM core acquires > a runtime PM ref in device_prepare() and releases it in device_complete(), > so it's sufficient to just call pm_runtime_resume() in a ->prepare hook > that's newly added to i915. No ->complete hook necessary. Tentative > patch below, based on drm-intel-fixes, would replace both of your patches. Calling it in ->prepare() means that everybody is now waiting for you to resume. Not quite optimal IMO. Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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, typically the _STA method looks like
> >> this:
> >>
> >> Method (_STA, 0, NotSerialized) // _STA: Status
> >> {
> >> If (OSID == One)
> >> {
> >> Return (Zero)
> >> }
> >>
> >> Return (0x0F)
> >> }
> >>
> >> Where OSID is some dark magic seen in all Cherry Trail ACPI tables
> >> making
> >> the machine behave differently depending on which OS it *thinks* it is
> >> booting, this gets set in a number of ways which we cannot control, on
> >> some newer machines it simple hardcoded to "One" aka win10.
> >>
> >> This causes the PWM controller to get hidden, which means Linux cannot
> >> control the backlight level on cht based tablets / laptops.
> >>
> >> Since loading the driver for this does no harm (the only in kernel
> >> user
> >> of it is the i915 driver, which will only uses it when it needs it),
> >> this
> >> commit makes acpi_bus_get_status() always set status to
> >> ACPI_STA_DEFAULT
> >> for the LPSS PWM device, fixing the lack of backlight control.
> >>
> >
> >> drivers/acpi/Makefile| 1 +
> >> drivers/acpi/bus.c | 5 +++
> >> drivers/acpi/x86/x86_utils.c | 85
> >>
> >
> > Perhaps .../x86/utils.c ?
>
> I thought that utils.c would be too generic,
> but that was mainly thinking about module kernel
> cmdline options which do not apply here, still
> having a somewhat unique basename seems useful.
I renamed it to util.c while applying the patches.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization
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 sequence. Add a flag that when set resumes the device before
> calling the driver'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
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Cc: sta...@vger.kernel.org
> Signed-off-by: Imre Deak
Acked-by: Rafael J. Wysocki
The reason why the opt-out flag was not added on day one was because we were
not sure whether or not it would be necessary at all.
Quite evidently, it is needed.
> ---
>
> [ After discussing with Jani, I'm going to apply this and the next patch
> for now to the intel-gfx specific CI branch to unblock our testing. ]
>
> drivers/pci/pci.c | 3 ++-
> include/linux/pci.h | 7 +++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 7904d02..020f02d 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2141,7 +2141,8 @@ bool pci_dev_keep_suspended(struct pci_dev *pci_dev)
>
> if (!pm_runtime_suspended(dev)
> || pci_target_state(pci_dev) != pci_dev->current_state
> - || platform_pci_need_resume(pci_dev))
> + || platform_pci_need_resume(pci_dev)
> + || pci_dev->needs_resume)
> return false;
>
> /*
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 5948cfd..2f012f8 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -316,6 +316,9 @@ struct pci_dev {
> unsigned inthotplug_user_indicators:1; /* SlotCtl indicators
> controlled exclusively by
> user sysfs */
> + unsigned intneeds_resume:1; /* Resume before calling the driver's
> +system suspend hooks, disabling the
> +direct_complete optimization. */
> unsigned intd3_delay; /* D3->D0 transition time in ms */
> unsigned intd3cold_delay; /* D3cold->D0 transition time in ms */
>
> @@ -1110,6 +1113,10 @@ bool pci_check_pme_status(struct pci_dev *dev);
> void pci_pme_wakeup_bus(struct pci_bus *bus);
> void pci_d3cold_enable(struct pci_dev *dev);
> void pci_d3cold_disable(struct pci_dev *dev);
> +static inline void pci_resume_before_suspend(struct pci_dev *dev, bool
> enable)
> +{
> + dev->needs_resume = enable;
> +}
>
> static inline int pci_enable_wake(struct pci_dev *dev, pci_power_t state,
> bool enable)
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 sequence. Add a flag that when set resumes the device before > > calling the driver'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 > > Cc: Bjorn Helgaas > > Cc: linux-...@vger.kernel.org > > Cc: sta...@vger.kernel.org > > Signed-off-by: Imre Deak > > Acked-by: Rafael J. Wysocki > > The reason why the opt-out flag was not added on day one was because we were > not sure whether or not it would be necessary at all. > > Quite evidently, it is needed. But that said, it actually can be implemented as a flag in dev_flags too, say PCI_DEV_FLAGS_NEEDS_RESUME, in analogy with PCI_DEV_FLAGS_NO_D3 that's already there. The struct size would not need to grow then which I guess would be better? Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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: > > > > Some drivers - like i915 - may not support the system suspend direct > > > > complete optimization due to differences in their runtime and system > > > > suspend sequence. Add a flag that when set resumes the device before > > > > calling the driver'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 > > > > Cc: Bjorn Helgaas > > > > Cc: linux-...@vger.kernel.org > > > > Cc: sta...@vger.kernel.org > > > > Signed-off-by: Imre Deak > > > > > > Acked-by: Rafael J. Wysocki > > > > > > The reason why the opt-out flag was not added on day one was because we > > > were > > > not sure whether or not it would be necessary at all. > > > > > > Quite evidently, it is needed. > > > > But that said, it actually can be implemented as a flag in dev_flags too, > > say > > PCI_DEV_FLAGS_NEEDS_RESUME, in analogy with PCI_DEV_FLAGS_NO_D3 that's > > already there. > > > > The struct size would not need to grow then which I guess would be better? > > Hm, both the bit field and the flag would need to increase if running > out of bits, so what's the difference? (Atm, the struct size wouldn't > change either way.) In the bit field case this depends on what the compiler thinks is better to be entirely precise, so they are not 100% equivalent. Plus, since there already are things related to PM in dev_flags, why to depart from that pattern? Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 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 sequence. Add a flag that when set resumes the device before > > > > > > calling the driver'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 > > > > > > Cc: Bjorn Helgaas > > > > > > Cc: linux-...@vger.kernel.org > > > > > > Cc: sta...@vger.kernel.org > > > > > > Signed-off-by: Imre Deak > > > > > > > > > > Acked-by: Rafael J. Wysocki > > > > > > > > > > The reason why the opt-out flag was not added on day one was because > > > > > we were > > > > > not sure whether or not it would be necessary at all. > > > > > > > > > > Quite evidently, it is needed. > > > > > > > > But that said, it actually can be implemented as a flag in dev_flags > > > > too, say > > > > PCI_DEV_FLAGS_NEEDS_RESUME, in analogy with PCI_DEV_FLAGS_NO_D3 that's > > > > already there. > > > > > > > > The struct size would not need to grow then which I guess would be > > > > better? > > > > > > Hm, both the bit field and the flag would need to increase if running > > > out of bits, so what's the difference? (Atm, the struct size wouldn't > > > change either way.) > > > > In the bit field case this depends on what the compiler thinks is better to > > be > > entirely precise, so they are not 100% equivalent. > > > > Plus, since there already are things related to PM in dev_flags, why to > > depart > > from that pattern? > > There are a few PM related flags in the bit field too. > > The need for moving it is still not clear to me, but I don't see any > problem with it either, so will move it there. Well, we are not too consistent in that respect overall. Either way works, so I guess it's Bjorn's call at this point. :-) 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
On Tuesday, May 02, 2017 03:04:08 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 sequence. Add a flag that when set resumes the device before
> calling the driver'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)
Acked-by: Rafael J. Wysocki
And yes, the PCI device PM flags need to be cleaned up. I'll take care of this
later unless somebody else steps up.
>
> Cc: Rafael J. Wysocki
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Cc: sta...@vger.kernel.org
> Signed-off-by: Imre Deak
> Acked-by: Rafael J. Wysocki (v3)
> ---
> drivers/pci/pci.c | 3 ++-
> include/linux/pci.h | 5 +
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 7904d02..a4ef755 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2141,7 +2141,8 @@ bool pci_dev_keep_suspended(struct pci_dev *pci_dev)
>
> if (!pm_runtime_suspended(dev)
> || pci_target_state(pci_dev) != pci_dev->current_state
> - || platform_pci_need_resume(pci_dev))
> + || platform_pci_need_resume(pci_dev)
> + || (pci_dev->dev_flags & PCI_DEV_FLAGS_NEEDS_RESUME))
> return false;
>
> /*
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 5948cfd..8acb560 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -178,6 +178,11 @@ enum pci_dev_flags {
> PCI_DEV_FLAGS_NO_PM_RESET = (__force pci_dev_flags_t) (1 << 7),
> /* Get VPD from function 0 VPD */
> PCI_DEV_FLAGS_VPD_REF_F0 = (__force pci_dev_flags_t) (1 << 8),
> + /*
> + * Resume before calling the driver's system suspend hooks, disabling
> + * the direct_complete optimization.
> + */
> + PCI_DEV_FLAGS_NEEDS_RESUME = (__force pci_dev_flags_t) (1 << 9),
> };
>
> enum pci_irq_reroute_variant {
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] sysfs: constify sysfs create/remove files harder
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
> a mutable array of const pointers.
I'm not sure if the changes guarantee what you want. If I'm not
mistaken, they just mean that the function itself cannot 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-by: Jani Nikula
> ---
> fs/sysfs/file.c | 4 ++--
> include/linux/sysfs.h | 8
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> index 0a7252aecfa5..bb71db63c99c 100644
> --- a/fs/sysfs/file.c
> +++ b/fs/sysfs/file.c
> @@ -334,7 +334,7 @@ int sysfs_create_file_ns(struct kobject *kobj, const
> struct attribute *attr,
> }
> EXPORT_SYMBOL_GPL(sysfs_create_file_ns);
>
> -int sysfs_create_files(struct kobject *kobj, const struct attribute **ptr)
> +int sysfs_create_files(struct kobject *kobj, const struct attribute * const
> *ptr)
> {
> int err = 0;
> int i;
> @@ -493,7 +493,7 @@ bool sysfs_remove_file_self(struct kobject *kobj, const
> struct attribute *attr)
> return ret;
> }
>
> -void sysfs_remove_files(struct kobject *kobj, const struct attribute **ptr)
> +void sysfs_remove_files(struct kobject *kobj, const struct attribute * const
> *ptr)
> {
> int i;
> for (i = 0; ptr[i]; i++)
> diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> index 987cefa337de..786816cf4aa5 100644
> --- a/include/linux/sysfs.h
> +++ b/include/linux/sysfs.h
> @@ -234,7 +234,7 @@ int __must_check sysfs_create_file_ns(struct kobject
> *kobj,
> const struct attribute *attr,
> const void *ns);
> int __must_check sysfs_create_files(struct kobject *kobj,
> - const struct attribute **attr);
> + const struct attribute * const *attr);
> int __must_check sysfs_chmod_file(struct kobject *kobj,
> const struct attribute *attr, umode_t mode);
> struct kernfs_node *sysfs_break_active_protection(struct kobject *kobj,
> @@ -243,7 +243,7 @@ void sysfs_unbreak_active_protection(struct kernfs_node
> *kn);
> void sysfs_remove_file_ns(struct kobject *kobj, const struct attribute *attr,
> const void *ns);
> bool sysfs_remove_file_self(struct kobject *kobj, const struct attribute
> *attr);
> -void sysfs_remove_files(struct kobject *kobj, const struct attribute **attr);
> +void sysfs_remove_files(struct kobject *kobj, const struct attribute * const
> *attr);
>
> int __must_check sysfs_create_bin_file(struct kobject *kobj,
>const struct bin_attribute *attr);
> @@ -342,7 +342,7 @@ static inline int sysfs_create_file_ns(struct kobject
> *kobj,
> }
>
> static inline int sysfs_create_files(struct kobject *kobj,
> - const struct attribute **attr)
> + const struct attribute * const *attr)
> {
> return 0;
> }
> @@ -377,7 +377,7 @@ static inline bool sysfs_remove_file_self(struct kobject
> *kobj,
> }
>
> static inline void sysfs_remove_files(struct kobject *kobj,
> -const struct attribute **attr)
> +const struct attribute * const *attr)
> {
> }
>
> --
> 2.11.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
> b/drivers/gpu/drm/i915/i915_sysfs.c
> index e5e6f6bb2b05..b9aa8515254e 100644
> --- a/drivers/gpu/drm/i915/i915_sysfs.c
> +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> @@ -483,7 +483,7 @@ static ssize_t gt_rp_mhz_show(struct device *kdev, struct
> device_attribute *attr
> return snprintf(buf, PAGE_SIZE, "%d\n", val);
> }
>
> -static const struct attribute *gen6_attrs[] = {
> +static const struct attribute * const gen6_attrs[] = {
> &dev_attr_gt_act_freq_mhz.attr,
> &dev_attr_gt_cur_freq_mhz.attr,
> &dev_attr_gt_boost_freq_mhz.attr,
> @@ -495,7 +495,7 @@ static const struct attribute *gen6_attrs[] = {
> NULL,
> };
>
> -static const struct attribute *vlv_attrs[] = {
> +static const struct attribute * const vlv_attrs[] = {
> &dev_attr_gt_act_freq_mhz.attr,
> &dev_attr_gt_cur_freq_mhz.attr,
> &dev_attr_gt_boost_freq_mhz.attr,
> --
> 2.11.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 > >> a mutable array of const pointers. > > > > I'm not sure if the changes guarantee what you want. If I'm not > > mistaken, they just mean that the function itself cannot 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. > > I mean, this change allows the caller to add the appropriate const > qualifiers to the array definition, allowing the placement in > rodata. Can't do that withouth the extra const in the function. I figured that out, but the changelog is a bit unclear. If you said "Allow ..." instead of "Let ...", it would be somewhat clearer IMO. :-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 > -- > v2: Fix the logic fumble in the 2nd hunk, spotted by Eric. Acked-by: Rafael J. Wysocki Or do you want me to apply it? > --- > include/linux/cpufreq.h | 8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h > index 882a9b9e34bc..3a774f523d00 100644 > --- a/include/linux/cpufreq.h > +++ b/include/linux/cpufreq.h > @@ -649,9 +649,7 @@ static inline void dev_pm_opp_free_cpufreq_table(struct > device *dev, > > #define cpufreq_for_each_valid_entry(pos, table) \ > for (pos = table; pos->frequency != CPUFREQ_TABLE_END; pos++) \ > - if (pos->frequency == CPUFREQ_ENTRY_INVALID)\ > - continue; \ > - else > + for_each_if (pos->frequency != CPUFREQ_ENTRY_INVALID) > > /* > * cpufreq_for_each_valid_entry_idx - iterate with index over a cpufreq > @@ -663,9 +661,7 @@ static inline void dev_pm_opp_free_cpufreq_table(struct > device *dev, > > #define cpufreq_for_each_valid_entry_idx(pos, table, idx) \ > cpufreq_for_each_entry_idx(pos, table, idx) \ > - if (pos->frequency == CPUFREQ_ENTRY_INVALID)\ > - continue; \ > - else > + for_each_if (pos->frequency != CPUFREQ_ENTRY_INVALID) > > > int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy, > -- > 2.18.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] PCI / PM: tune down RPM suspend error message with EBUSY and EAGAIN retval
On 11/27/2015 12:39 PM, Jani Nikula wrote:
On Wed, 18 Nov 2015, Daniel Vetter wrote:
On Wed, Nov 18, 2015 at 03:28:38PM +0200, Imre Deak wrote:
On ke, 2015-11-18 at 12:56 +0200, Imre Deak wrote:
The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
suspend hooks as errors, but they still show up as errors in dmesg. Tune
them down.
One problem caused by this was noticed by Daniel: the i915 driver
returns EAGAIN to signal a temporary failure to suspend and as a request
towards the RPM core for scheduling a suspend again. This is a normal
event, but the resulting error message flags a breakage during the
driver's automated testing which parses dmesg and picks up the error.
v2:
- fix compile breake when CONFIG_PM_SLEEP=n (0-day builder)
Reported-by: Daniel Vetter
Signed-off-by: Imre Deak
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92992
Reviewed-by: Daniel Vetter
Rafael, can you please pick this up for 4.4? The spurious KERN_ERR noise
in dmesg is causing a lot fo spurious fail in our (very recently put into
place) i915 CI system.
Rafael, ping.
Well, so I'm not sure about this one.
And the question is ->
---
drivers/base/power/main.c | 7 +--
drivers/pci/pci-driver.c | 2 +-
include/linux/pm.h| 11 +--
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 1710c26..39d2090 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1679,9 +1679,12 @@ int dpm_suspend_start(pm_message_t state)
}
EXPORT_SYMBOL_GPL(dpm_suspend_start);
-void __suspend_report_result(const char *function, void *fn, int ret)
+void __suspend_report_result(const char *function, void *fn, int ret,
+bool runtime_pm)
{
- if (ret)
+ if (runtime_pm && (ret == -EBUSY || ret == -EAGAIN))
+ printk(KERN_DEBUG "%s(): %pF returns %d\n", function, fn, ret);
+ else if (ret)
printk(KERN_ERR "%s(): %pF returns %d\n", function, fn, ret);
}
-> why you are adding overhead to this function, instead of -->
EXPORT_SYMBOL_GPL(__suspend_report_result);
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 108a311..9569572 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1142,7 +1142,7 @@ static int pci_pm_runtime_suspend(struct device *dev)
pci_dev->state_saved = false;
pci_dev->no_d3cold = false;
error = pm->runtime_suspend(dev);
- suspend_report_result(pm->runtime_suspend, error);
+ rpm_suspend_report_result(pm->runtime_suspend, error);
--> replacing the suspend_report_result() above with a direct printk()
in the if (error) block below.
Surely, suspend_report_result() was not designed with runtime PM in mind
and it was a mistake to use it here. It just seemed to do the right
thing, but it clearly doesn't.
if (error)
return error;
if (!pci_dev->d3cold_allowed)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 35d599e..54f37e3 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -702,11 +702,17 @@ extern int dpm_suspend_late(pm_message_t state);
extern int dpm_suspend(pm_message_t state);
extern int dpm_prepare(pm_message_t state);
-extern void __suspend_report_result(const char *function, void *fn, int ret);
+extern void __suspend_report_result(const char *function, void *fn, int ret,
+ bool runtime_pm);
#define suspend_report_result(fn, ret) \
do {\
- __suspend_report_result(__func__, fn, ret); \
+ __suspend_report_result(__func__, fn, ret, false); \
+ } while (0)
+
+#define rpm_suspend_report_result(fn, ret) \
+ do {\
+ __suspend_report_result(__func__, fn, ret, true); \
} while (0)
extern int device_pm_wait_for_dev(struct device *sub, struct device *dev);
@@ -744,6 +750,7 @@ static inline int dpm_suspend_start(pm_message_t state)
}
#define suspend_report_result(fn, ret) do {} while (0)
+#define rpm_suspend_report_result(fn, ret) do {} while (0)
static inline int device_pm_wait_for_dev(struct device *a, struct device *b)
{
BTW, if you're changing PM code, it is good to CC linux-pm too (now
done) and if you're changing PCI code, it is mandatory to CC linux-pci
and the PCI maintainer (now done too).
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] PCI / PM: tune down RPM suspend error message with EBUSY and EAGAIN retval
On Saturday, November 28, 2015 10:34:24 AM Imre Deak wrote:
> The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
> suspend hooks as errors, but they still show up as errors in dmesg. Tune
> them down.
>
> One problem caused by this was noticed by Daniel: the i915 driver
> returns EAGAIN to signal a temporary failure to suspend and as a request
> towards the RPM core for scheduling a suspend again. This is a normal
> event, but the resulting error message flags a breakage during the
> driver's automated testing which parses dmesg and picks up the error.
>
> v2:
> - fix compile breake when CONFIG_PM_SLEEP=n (0-day builder)
> v3:
> - instead of modifying the suspend_report_result() helper to disinguish
> between the runtime and system suspend case, inline the error
> printing, it's not used anywhere else (Rafael)
> v4:
> - don't refer to log levels as flags in code comment (Rafael)
> - use pr_debug(), pr_err() instead of the corresponding printk() (Rafael)
>
> Reported-by: Daniel Vetter
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92992
> CC: Bjorn Helgaas
> CC: Rafael J. Wysocki
> Signed-off-by: Imre Deak
This is fine by me.
Bjorn, any objections against applying it? It reduces log noise quite
a bit for i915.
> ---
> drivers/pci/pci-driver.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 4446fcb..32a9947 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -1146,9 +1146,21 @@ static int pci_pm_runtime_suspend(struct device *dev)
> pci_dev->state_saved = false;
> pci_dev->no_d3cold = false;
> error = pm->runtime_suspend(dev);
> - suspend_report_result(pm->runtime_suspend, error);
> - if (error)
> + if (error) {
> + /*
> + * -EBUSY and -EAGAIN is used to request the runtime PM core
> + * to schedule a new suspend, so log the event only with debug
> + * log level.
> + */
> + if (error == -EBUSY || error == -EAGAIN)
> + pr_debug("%s(): %pF returns %d\n", __func__,
> + pm->runtime_suspend, error);
> + else
> + pr_err("%s(): %pF returns %d\n", __func__,
> +pm->runtime_suspend, error);
> +
> return error;
> + }
> if (!pci_dev->d3cold_allowed)
> pci_dev->no_d3cold = true;
>
>
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] PCI / PM: tune down RPM suspend error message with EBUSY and EAGAIN retval
On Fri, Nov 27, 2015 at 7:17 PM, Imre Deak wrote:
> The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
> suspend hooks as errors, but they still show up as errors in dmesg. Tune
> them down.
>
> One problem caused by this was noticed by Daniel: the i915 driver
> returns EAGAIN to signal a temporary failure to suspend and as a request
> towards the RPM core for scheduling a suspend again. This is a normal
> event, but the resulting error message flags a breakage during the
> driver's automated testing which parses dmesg and picks up the error.
>
> v2:
> - fix compile breake when CONFIG_PM_SLEEP=n (0-day builder)
> v3:
> - instead of modifying the suspend_report_result() helper to disinguish
> between the runtime and system suspend case, inline the error
> printing, it's not used anywhere else (Rafael)
>
> Reported-by: Daniel Vetter
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92992
> CC: Bjorn Helgaas
> CC: Rafael J. Wysocki
> Signed-off-by: Imre Deak
> ---
> drivers/pci/pci-driver.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 4446fcb..67eb4ac 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -1146,9 +1146,20 @@ static int pci_pm_runtime_suspend(struct device *dev)
> pci_dev->state_saved = false;
> pci_dev->no_d3cold = false;
> error = pm->runtime_suspend(dev);
> - suspend_report_result(pm->runtime_suspend, error);
> - if (error)
> + if (error) {
> + /*
> +* -EBUSY and -EAGAIN is used to request the runtime PM core
> +* to schedule a new suspend, so don't flag it as an error.
> +*/
KERN_DEBUG and KERN_ERR are log levels, not flags.
Besides, maybe we can use pr_err() and pr_debug() here?
> + if (error == -EBUSY || error == -EAGAIN)
> + printk(KERN_DEBUG "%s(): %pF returns %d\n", __func__,
> + pm->runtime_suspend, error);
> + else
> + printk(KERN_ERR "%s(): %pF returns %d\n", __func__,
> + pm->runtime_suspend, error);
> +
> return error;
> + }
> if (!pci_dev->d3cold_allowed)
> pci_dev->no_d3cold = true;
>
> --
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] PCI / PM: Tune down retryable runtime suspend error messages
On Monday, November 30, 2015 09:02:55 PM Imre Deak wrote:
> The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
> suspend hooks as errors, but they still show up as errors in dmesg. Tune
> them down. See rpm_suspend() for details of handling these return values.
>
> Note that we use dev_dbg() for the retryable retvals, so after this
> change you'll need either CONFIG_DYNAMIC_DEBUG or CONFIG_PCI_DEBUG
> for them to show up in the log.
>
> One problem caused by this was noticed by Daniel: the i915 driver
> returns EAGAIN to signal a temporary failure to suspend and as a request
> towards the RPM core for scheduling a suspend again. This is a normal
> event, but the resulting error message flags a breakage during the
> driver's automated testing which parses dmesg and picks up the error.
>
> Reported-by: Daniel Vetter
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92992
> CC: Bjorn Helgaas
> CC: Rafael J. Wysocki
> Signed-off-by: Imre Deak
Hi Bjorn,
Are you going to handle this one or should I take care of it?
Rafael
> ---
>
> v2:
> - fix compile breake when CONFIG_PM_SLEEP=n (0-day builder)
> v3:
> - instead of modifying the suspend_report_result() helper to disinguish
> between the runtime and system suspend case, inline the error
> printing, it's not used anywhere else (Rafael)
> v4:
> - don't refer to log levels as flags in code comment (Rafael)
> - use pr_debug(), pr_err() instead of the corresponding printk() (Rafael)
> v5:
> - clarify commit message (Bjorn)
> - use dev_dbg, dev_err instead of pr_debug, pr_err (Bjorn)
> - use %pf in printk format instead of %pF (Bjorn)
> - make the debug/error messages more meaningful (Bjorn)
> ---
> drivers/pci/pci-driver.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 4446fcb..d7ffd66 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -1146,9 +1146,21 @@ static int pci_pm_runtime_suspend(struct device *dev)
> pci_dev->state_saved = false;
> pci_dev->no_d3cold = false;
> error = pm->runtime_suspend(dev);
> - suspend_report_result(pm->runtime_suspend, error);
> - if (error)
> + if (error) {
> + /*
> + * -EBUSY and -EAGAIN is used to request the runtime PM core
> + * to schedule a new suspend, so log the event only with debug
> + * log level.
> + */
> + if (error == -EBUSY || error == -EAGAIN)
> + dev_dbg(dev, "can't suspend now (%pf returned %d)\n",
> + pm->runtime_suspend, error);
> + else
> + dev_err(dev, "can't suspend (%pf returned %d)\n",
> + pm->runtime_suspend, error);
> +
> return error;
> + }
> if (!pci_dev->d3cold_allowed)
> pci_dev->no_d3cold = true;
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle
On Wednesday, December 09, 2015 06:22:19 PM Joonas Lahtinen wrote: > Introduce pm_runtime_get_noidle to for situations where it is not > desireable to touch an idling device. One use scenario is periodic > hangchecks performed by the drm/i915 driver which can be omitted > on a device in a runtime idle state. > > v2: > - Fix inconsistent return value when !CONFIG_PM. > - Update documentation for bool return value > > Signed-off-by: Joonas Lahtinen > Reported-by: Chris Wilson > Cc: Chris Wilson > Cc: "Rafael J. Wysocki" > Cc: linux...@vger.kernel.org Well, I don't quite see how this can be used in a non-racy way without doing an additional pm_runtime_resume() or something like that in the same code path. Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle
On Thursday, December 10, 2015 11:43:50 AM Imre Deak wrote: > On Thu, 2015-12-10 at 01:58 +0100, Rafael J. Wysocki wrote: > > On Wednesday, December 09, 2015 06:22:19 PM Joonas Lahtinen wrote: > > > Introduce pm_runtime_get_noidle to for situations where it is not > > > desireable to touch an idling device. One use scenario is periodic > > > hangchecks performed by the drm/i915 driver which can be omitted > > > on a device in a runtime idle state. > > > > > > v2: > > > - Fix inconsistent return value when !CONFIG_PM. > > > - Update documentation for bool return value > > > > > > Signed-off-by: Joonas Lahtinen > > > Reported-by: Chris Wilson > > > Cc: Chris Wilson > > > Cc: "Rafael J. Wysocki" > > > Cc: linux...@vger.kernel.org > > > > Well, I don't quite see how this can be used in a non-racy way > > without doing an additional pm_runtime_resume() or something like > > that in the same code path. > > We don't want to resume, that would be the whole point. We'd like to > ensure that we hold a reference _and_ the device is already active. So > AFAICS we'd need to check runtime_status == RPM_ACTIVE in addition > after taking the reference. Right, and that under the lock. Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle
On Thursday, December 10, 2015 10:36:37 PM Rafael J. Wysocki wrote: > On Thursday, December 10, 2015 11:43:50 AM Imre Deak wrote: > > On Thu, 2015-12-10 at 01:58 +0100, Rafael J. Wysocki wrote: > > > On Wednesday, December 09, 2015 06:22:19 PM Joonas Lahtinen wrote: > > > > Introduce pm_runtime_get_noidle to for situations where it is not > > > > desireable to touch an idling device. One use scenario is periodic > > > > hangchecks performed by the drm/i915 driver which can be omitted > > > > on a device in a runtime idle state. > > > > > > > > v2: > > > > - Fix inconsistent return value when !CONFIG_PM. > > > > - Update documentation for bool return value > > > > > > > > Signed-off-by: Joonas Lahtinen > > > > Reported-by: Chris Wilson > > > > Cc: Chris Wilson > > > > Cc: "Rafael J. Wysocki" > > > > Cc: linux...@vger.kernel.org > > > > > > Well, I don't quite see how this can be used in a non-racy way > > > without doing an additional pm_runtime_resume() or something like > > > that in the same code path. > > > > We don't want to resume, that would be the whole point. We'd like to > > ensure that we hold a reference _and_ the device is already active. So > > AFAICS we'd need to check runtime_status == RPM_ACTIVE in addition > > after taking the reference. > > Right, and that under the lock. Which basically means you can call pm_runtime_resume() just fine, because it will do nothing if the status is RPM_ACTIVE already. So really, why don't you use pm_runtime_get_sync()? Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle
On Thursday, December 10, 2015 11:20:40 PM Imre Deak wrote:
> On Thu, 2015-12-10 at 22:42 +0100, Rafael J. Wysocki wrote:
> > On Thursday, December 10, 2015 10:36:37 PM Rafael J. Wysocki wrote:
> > > On Thursday, December 10, 2015 11:43:50 AM Imre Deak wrote:
> > > > On Thu, 2015-12-10 at 01:58 +0100, Rafael J. Wysocki wrote:
> > > > > On Wednesday, December 09, 2015 06:22:19 PM Joonas Lahtinen
> > > > > wrote:
> > > > > > Introduce pm_runtime_get_noidle to for situations where it is
> > > > > > not
> > > > > > desireable to touch an idling device. One use scenario is
> > > > > > periodic
> > > > > > hangchecks performed by the drm/i915 driver which can be
> > > > > > omitted
> > > > > > on a device in a runtime idle state.
> > > > > >
> > > > > > v2:
> > > > > > - Fix inconsistent return value when !CONFIG_PM.
> > > > > > - Update documentation for bool return value
> > > > > >
> > > > > > Signed-off-by: Joonas Lahtinen > > > > > om>
> > > > > > Reported-by: Chris Wilson
> > > > > > Cc: Chris Wilson
> > > > > > Cc: "Rafael J. Wysocki"
> > > > > > Cc: linux...@vger.kernel.org
> > > > >
> > > > > Well, I don't quite see how this can be used in a non-racy way
> > > > > without doing an additional pm_runtime_resume() or something
> > > > > like
> > > > > that in the same code path.
> > > >
> > > > We don't want to resume, that would be the whole point. We'd like
> > > > to
> > > > ensure that we hold a reference _and_ the device is already
> > > > active. So
> > > > AFAICS we'd need to check runtime_status == RPM_ACTIVE in
> > > > addition
> > > > after taking the reference.
> > >
> > > Right, and that under the lock.
> >
> > Which basically means you can call pm_runtime_resume() just fine,
> > because it will do nothing if the status is RPM_ACTIVE already.
> >
> > So really, why don't you use pm_runtime_get_sync()?
>
> The difference would be that if the status is not RPM_ACTIVE already we
> would drop the reference and report error. The caller would in this
> case forego of doing something, since we the device is suspended or on
> the way to being suspended. One example of such a scenario is a
> watchdog like functionality: the watchdog work would
> call pm_runtime_get_noidle() and check if the device is ok by doing
> some HW access, but only if the device is powered. Otherwise the work
> item would do nothing (meaning it also won't reschedule itself). The
> watchdog work would get rescheduled next time the device is woken up
> and some work is submitted to the device.
So first of all the name "pm_runtime_get_noidle" doesn't make sense.
I guess what you need is something like
bool pm_runtime_get_if_active(struct device *dev)
{
unsigned log flags;
bool ret;
spin_lock_irqsave(&dev->power.lock, flags);
if (dev->power.runtime_status == RPM_ACTIVE) {
atomic_inc(&dev->power.usage_count);
ret = true;
} else {
ret = false;
}
spin_unlock_irqrestore(&dev->power.lock, flags);
}
and the caller will simply bail out if "false" is returned, but if "true"
is returned, it will have to drop the usage count, right?
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle
On Friday, December 11, 2015 01:03:50 PM Ulf Hansson wrote:
> [...]
>
> >> >
> >> > Which basically means you can call pm_runtime_resume() just fine,
> >> > because it will do nothing if the status is RPM_ACTIVE already.
> >> >
> >> > So really, why don't you use pm_runtime_get_sync()?
> >>
> >> The difference would be that if the status is not RPM_ACTIVE already we
> >> would drop the reference and report error. The caller would in this
> >> case forego of doing something, since we the device is suspended or on
> >> the way to being suspended. One example of such a scenario is a
> >> watchdog like functionality: the watchdog work would
> >> call pm_runtime_get_noidle() and check if the device is ok by doing
> >> some HW access, but only if the device is powered. Otherwise the work
> >> item would do nothing (meaning it also won't reschedule itself). The
> >> watchdog work would get rescheduled next time the device is woken up
> >> and some work is submitted to the device.
> >
> > So first of all the name "pm_runtime_get_noidle" doesn't make sense.
> >
> > I guess what you need is something like
> >
> > bool pm_runtime_get_if_active(struct device *dev)
> > {
> > unsigned log flags;
> > bool ret;
> >
> > spin_lock_irqsave(&dev->power.lock, flags);
> >
> > if (dev->power.runtime_status == RPM_ACTIVE) {
> > atomic_inc(&dev->power.usage_count);
> > ret = true;
> > } else {
> > ret = false;
> > }
> >
> > spin_unlock_irqrestore(&dev->power.lock, flags);
> > }
> >
> > and the caller will simply bail out if "false" is returned, but if "true"
> > is returned, it will have to drop the usage count, right?
> >
> > Thanks,
> > Rafael
> >
>
> Why not just:
>
> pm_runtime_get_noresume():
> if (RPM_ACTIVE)
> "do some actions"
> pm_runtime_put();
Because that's racy?
What if the rpm_suspend() is running for the device, but it hasn't changed
the status yet?
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle
On Friday, December 11, 2015 02:54:45 PM Imre Deak wrote:
> On to, 2015-12-10 at 23:14 +0100, Rafael J. Wysocki wrote:
> > On Thursday, December 10, 2015 11:20:40 PM Imre Deak wrote:
> > > On Thu, 2015-12-10 at 22:42 +0100, Rafael J. Wysocki wrote:
> > > > On Thursday, December 10, 2015 10:36:37 PM Rafael J. Wysocki
> > > > wrote:
> > > > > On Thursday, December 10, 2015 11:43:50 AM Imre Deak wrote:
> > > > > > On Thu, 2015-12-10 at 01:58 +0100, Rafael J. Wysocki wrote:
> > > > > > > On Wednesday, December 09, 2015 06:22:19 PM Joonas Lahtinen
> > > > > > > wrote:
> > > > > > > > Introduce pm_runtime_get_noidle to for situations where
> > > > > > > > it is
> > > > > > > > not
> > > > > > > > desireable to touch an idling device. One use scenario is
> > > > > > > > periodic
> > > > > > > > hangchecks performed by the drm/i915 driver which can be
> > > > > > > > omitted
> > > > > > > > on a device in a runtime idle state.
> > > > > > > >
> > > > > > > > v2:
> > > > > > > > - Fix inconsistent return value when !CONFIG_PM.
> > > > > > > > - Update documentation for bool return value
> > > > > > > >
> > > > > > > > Signed-off-by: Joonas Lahtinen > > > > > > > el.c
> > > > > > > > om>
> > > > > > > > Reported-by: Chris Wilson
> > > > > > > > Cc: Chris Wilson
> > > > > > > > Cc: "Rafael J. Wysocki"
> > > > > > > > Cc: linux...@vger.kernel.org
> > > > > > >
> > > > > > > Well, I don't quite see how this can be used in a non-racy
> > > > > > > way
> > > > > > > without doing an additional pm_runtime_resume() or
> > > > > > > something
> > > > > > > like
> > > > > > > that in the same code path.
> > > > > >
> > > > > > We don't want to resume, that would be the whole point. We'd
> > > > > > like
> > > > > > to
> > > > > > ensure that we hold a reference _and_ the device is already
> > > > > > active. So
> > > > > > AFAICS we'd need to check runtime_status == RPM_ACTIVE in
> > > > > > addition
> > > > > > after taking the reference.
> > > > >
> > > > > Right, and that under the lock.
> > > >
> > > > Which basically means you can call pm_runtime_resume() just fine,
> > > > because it will do nothing if the status is RPM_ACTIVE already.
> > > >
> > > > So really, why don't you use pm_runtime_get_sync()?
> > >
> > > The difference would be that if the status is not RPM_ACTIVE
> > > already we
> > > would drop the reference and report error. The caller would in this
> > > case forego of doing something, since we the device is suspended or
> > > on
> > > the way to being suspended. One example of such a scenario is a
> > > watchdog like functionality: the watchdog work would
> > > call pm_runtime_get_noidle() and check if the device is ok by doing
> > > some HW access, but only if the device is powered. Otherwise the
> > > work
> > > item would do nothing (meaning it also won't reschedule itself).
> > > The
> > > watchdog work would get rescheduled next time the device is woken
> > > up
> > > and some work is submitted to the device.
> >
> > So first of all the name "pm_runtime_get_noidle" doesn't make sense.
> >
> > I guess what you need is something like
> >
> > bool pm_runtime_get_if_active(struct device *dev)
> > {
> > unsigned log flags;
> > bool ret;
> >
> > spin_lock_irqsave(&dev->power.lock, flags);
> >
> > if (dev->power.runtime_status == RPM_ACTIVE) {
>
> But here usage_count could be zero, meaning that the device is already
> on the way to be suspended (autosuspend or ASYNC suspend), no?
The usage counter equal to 0 need not mean that the device is being suspended
right now.
Also even if that's the case, the usage counter may be incremented at this very
moment by a concurrent thread and you'll lose the opportunity to do what you
want.
> In that case we don't want to return success. That would unnecessarily prolong
> the time the device is kept active.
Why?
If you have something to do if the device is active, then do it is the status
is "active". It really shouldn't matter when the device is going to be
suspended
going forward.
> > atomic_inc(&dev->power.usage_count);
> > ret = true;
> > } else {
> > ret = false;
> > }
> >
> > spin_unlock_irqrestore(&dev->power.lock, flags);
> > }
> >
> > and the caller will simply bail out if "false" is returned, but if
> > "true"
> > is returned, it will have to drop the usage count, right?
>
> Yes.
OK, I'll send a patch adding this function then.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle
On Friday, December 11, 2015 05:47:08 PM Imre Deak wrote: > On pe, 2015-12-11 at 16:40 +0100, Rafael J. Wysocki wrote: > > On Friday, December 11, 2015 02:54:45 PM Imre Deak wrote: > > > On to, 2015-12-10 at 23:14 +0100, Rafael J. Wysocki wrote: > > > > On Thursday, December 10, 2015 11:20:40 PM Imre Deak wrote: > > > > > On Thu, 2015-12-10 at 22:42 +0100, Rafael J. Wysocki wrote: > > > > > > On Thursday, December 10, 2015 10:36:37 PM Rafael J. Wysocki > > > > > > wrote: > > > > > > > On Thursday, December 10, 2015 11:43:50 AM Imre Deak wrote: > > > > > > > > On Thu, 2015-12-10 at 01:58 +0100, Rafael J. Wysocki > > > > > > > > wrote: > > > > > > > > > On Wednesday, December 09, 2015 06:22:19 PM Joonas > > > > > > > > > Lahtinen > > > > > > > > > wrote: > > > > > > > > > > Introduce pm_runtime_get_noidle to for situations > > > > > > > > > > where > > > > > > > > > > it is > > > > > > > > > > not > > > > > > > > > > desireable to touch an idling device. One use > > > > > > > > > > scenario is > > > > > > > > > > periodic > > > > > > > > > > hangchecks performed by the drm/i915 driver which can > > > > > > > > > > be > > > > > > > > > > omitted > > > > > > > > > > on a device in a runtime idle state. > > > > > > > > > > > > > > > > > > > > v2: > > > > > > > > > > - Fix inconsistent return value when !CONFIG_PM. > > > > > > > > > > - Update documentation for bool return value > > > > > > > > > > > > > > > > > > > > Signed-off-by: Joonas Lahtinen > > > > > > > > > .int > > > > > > > > > > el.c > > > > > > > > > > om> > > > > > > > > > > Reported-by: Chris Wilson > > > > > > > > > > Cc: Chris Wilson > > > > > > > > > > Cc: "Rafael J. Wysocki" > > > > > > > > > > Cc: linux...@vger.kernel.org > > > > > > > > > > > > > > > > > > Well, I don't quite see how this can be used in a non- > > > > > > > > > racy > > > > > > > > > way > > > > > > > > > without doing an additional pm_runtime_resume() or > > > > > > > > > something > > > > > > > > > like > > > > > > > > > that in the same code path. > > > > > > > > > > > > > > > > We don't want to resume, that would be the whole point. > > > > > > > > We'd > > > > > > > > like > > > > > > > > to > > > > > > > > ensure that we hold a reference _and_ the device is > > > > > > > > already > > > > > > > > active. So > > > > > > > > AFAICS we'd need to check runtime_status == RPM_ACTIVE in > > > > > > > > addition > > > > > > > > after taking the reference. > > > > > > > > > > > > > > Right, and that under the lock. > > > > > > > > > > > > Which basically means you can call pm_runtime_resume() just > > > > > > fine, > > > > > > because it will do nothing if the status is RPM_ACTIVE > > > > > > already. > > > > > > > > > > > > So really, why don't you use pm_runtime_get_sync()? > > > > > > > > > > The difference would be that if the status is not RPM_ACTIVE > > > > > already we > > > > > would drop the reference and report error. The caller would in > > > > > this > > > > > case forego of doing something, since we the device is > > > > > suspended or > > > > > on > > > > > the way to being suspended. One example of such a scenario is a > > > > > watchdog like functionality: the watchdog work would > > > >
Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle
On Friday, December 11, 2015 04:59:45 PM Ulf Hansson wrote:
> On 11 December 2015 at 16:13, Rafael J. Wysocki wrote:
> > On Friday, December 11, 2015 01:03:50 PM Ulf Hansson wrote:
> >> [...]
> >>
> >> >> >
> >> >> > Which basically means you can call pm_runtime_resume() just fine,
> >> >> > because it will do nothing if the status is RPM_ACTIVE already.
> >> >> >
> >> >> > So really, why don't you use pm_runtime_get_sync()?
> >> >>
> >> >> The difference would be that if the status is not RPM_ACTIVE already we
> >> >> would drop the reference and report error. The caller would in this
> >> >> case forego of doing something, since we the device is suspended or on
> >> >> the way to being suspended. One example of such a scenario is a
> >> >> watchdog like functionality: the watchdog work would
> >> >> call pm_runtime_get_noidle() and check if the device is ok by doing
> >> >> some HW access, but only if the device is powered. Otherwise the work
> >> >> item would do nothing (meaning it also won't reschedule itself). The
> >> >> watchdog work would get rescheduled next time the device is woken up
> >> >> and some work is submitted to the device.
> >> >
> >> > So first of all the name "pm_runtime_get_noidle" doesn't make sense.
> >> >
> >> > I guess what you need is something like
> >> >
> >> > bool pm_runtime_get_if_active(struct device *dev)
> >> > {
> >> > unsigned log flags;
> >> > bool ret;
> >> >
> >> > spin_lock_irqsave(&dev->power.lock, flags);
> >> >
> >> > if (dev->power.runtime_status == RPM_ACTIVE) {
> >> > atomic_inc(&dev->power.usage_count);
> >> > ret = true;
> >> > } else {
> >> > ret = false;
> >> > }
> >> >
> >> > spin_unlock_irqrestore(&dev->power.lock, flags);
> >> > }
> >> >
> >> > and the caller will simply bail out if "false" is returned, but if "true"
> >> > is returned, it will have to drop the usage count, right?
> >> >
> >> > Thanks,
> >> > Rafael
> >> >
> >>
> >> Why not just:
> >>
> >> pm_runtime_get_noresume():
> >> if (RPM_ACTIVE)
> >> "do some actions"
> >> pm_runtime_put();
> >
> > Because that's racy?
>
> Right, that was too easy. :-)
>
> >
> > What if the rpm_suspend() is running for the device, but it hasn't changed
> > the status yet?
>
> So if we can add a pm_runtime_barrier() or even simplifier, just hold
> the spin_lock when checking if the rpm status is RPM_ACTIVE.
That would work too, but then we'd need to carry out one extra atomic operation.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle
On Saturday, December 12, 2015 12:21:43 AM Rafael J. Wysocki wrote:
> On Friday, December 11, 2015 05:47:08 PM Imre Deak wrote:
> > On pe, 2015-12-11 at 16:40 +0100, Rafael J. Wysocki wrote:
> > > On Friday, December 11, 2015 02:54:45 PM Imre Deak wrote:
> > > > On to, 2015-12-10 at 23:14 +0100, Rafael J. Wysocki wrote:
> > > > > On Thursday, December 10, 2015 11:20:40 PM Imre Deak wrote:
> > > > > > On Thu, 2015-12-10 at 22:42 +0100, Rafael J. Wysocki wrote:
> > > > > > > On Thursday, December 10, 2015 10:36:37 PM Rafael J. Wysocki
[cut]
>
> Yes, my suggested function can be written like this:
>
> bool pm_runtime_get_if_active(struct device *dev)
> {
> unsigned log flags;
> bool ret = false;
>
> spin_lock_irqsave(&dev->power.lock, flags);
>
> if (dev->power.runtime_status == RPM_ACTIVE) {
> if (atomic_inc_return(&dev->power.usage_count) > 1)
> ret = true;
> else
> atomic_dec(&dev->power.usage_count);
> }
>
> spin_unlock_irqrestore(&dev->power.lock, flags);
> return ret;
> }
>
> but this is obviously racy with respect to anyone concurrently changing the
> usage counter.
Somethng like this would be slightly more efficient:
bool pm_runtime_get_if_in_use(struct device *dev)
{
unsigned log flags;
bool ret = false;
spin_lock_irqsave(&dev->power.lock, flags);
if (dev->power.runtime_status == RPM_ACTIVE)
ret = !!atomic_inc_not_zero(&dev->power.usage_count);
spin_unlock_irqrestore(&dev->power.lock, flags);
return ret;
}
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle
On Saturday, December 12, 2015 12:41:06 AM Rafael J. Wysocki wrote:
> On Saturday, December 12, 2015 12:21:43 AM Rafael J. Wysocki wrote:
> > On Friday, December 11, 2015 05:47:08 PM Imre Deak wrote:
> > > On pe, 2015-12-11 at 16:40 +0100, Rafael J. Wysocki wrote:
> > > > On Friday, December 11, 2015 02:54:45 PM Imre Deak wrote:
> > > > > On to, 2015-12-10 at 23:14 +0100, Rafael J. Wysocki wrote:
> > > > > > On Thursday, December 10, 2015 11:20:40 PM Imre Deak wrote:
> > > > > > > On Thu, 2015-12-10 at 22:42 +0100, Rafael J. Wysocki wrote:
> > > > > > > > On Thursday, December 10, 2015 10:36:37 PM Rafael J. Wysocki
>
> [cut]
>
> >
> > Yes, my suggested function can be written like this:
> >
> > bool pm_runtime_get_if_active(struct device *dev)
> > {
> > unsigned log flags;
> > bool ret = false;
> >
> > spin_lock_irqsave(&dev->power.lock, flags);
> >
> > if (dev->power.runtime_status == RPM_ACTIVE) {
> > if (atomic_inc_return(&dev->power.usage_count) > 1)
> > ret = true;
> > else
> > atomic_dec(&dev->power.usage_count);
> > }
> >
> > spin_unlock_irqrestore(&dev->power.lock, flags);
> > return ret;
> > }
> >
> > but this is obviously racy with respect to anyone concurrently changing the
> > usage counter.
>
> Somethng like this would be slightly more efficient:
And below is a patch to implement the thing, compile-tested only.
Please let me know if that's what you need.
Thanks,
Rafael
---
From: Rafael J. Wysocki
Subject: PM / runtime: Add new helper for conditional usage count incrementation
Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
that will increment the device's runtime PM usage counter and
return 'true' if its status is RPM_ACTIVE and its usage counter
is greater than 0 at the same time ('false' will be returned
otherwise).
This is useful for things that should only be done if the device
is active (from the runtime PM perspective) and used by somebody
(as indicated by the usage counter) already and engaging the device
otherwise would be overkill.
Requested-by: Imre Deak
Signed-off-by: Rafael J. Wysocki
---
Documentation/power/runtime_pm.txt |5 +
drivers/base/power/runtime.c | 21 +
include/linux/pm_runtime.h |5 +
3 files changed, 31 insertions(+)
Index: linux-pm/drivers/base/power/runtime.c
===
--- linux-pm.orig/drivers/base/power/runtime.c
+++ linux-pm/drivers/base/power/runtime.c
@@ -966,6 +966,27 @@ int __pm_runtime_resume(struct device *d
EXPORT_SYMBOL_GPL(__pm_runtime_resume);
/**
+ * pm_runtime_get_if_in_use - Conditionally bump up the device's usage counter.
+ * @dev: Device to handle.
+ *
+ * Increment the device's runtime PM usage counter and return 'true' if its
+ * runtime PM status is RPM_ACTIVE and its usage counter is already different
+ * from zero at the same time. Otherwise, return 'false'.
+ */
+bool pm_runtime_get_if_in_use(struct device *dev)
+{
+ unsigned long flags;
+ bool retval;
+
+ spin_lock_irqsave(&dev->power.lock, flags);
+ retval = dev->power.runtime_status == RPM_ACTIVE ?
+ !!atomic_inc_not_zero(&dev->power.usage_count) : false;
+ spin_unlock_irqrestore(&dev->power.lock, flags);
+ return retval;
+}
+EXPORT_SYMBOL_GPL(pm_runtime_get_if_in_use);
+
+/**
* __pm_runtime_set_status - Set runtime PM status of a device.
* @dev: Device to handle.
* @status: New runtime PM status of the device.
Index: linux-pm/include/linux/pm_runtime.h
===
--- linux-pm.orig/include/linux/pm_runtime.h
+++ linux-pm/include/linux/pm_runtime.h
@@ -39,6 +39,7 @@ extern int pm_runtime_force_resume(struc
extern int __pm_runtime_idle(struct device *dev, int rpmflags);
extern int __pm_runtime_suspend(struct device *dev, int rpmflags);
extern int __pm_runtime_resume(struct device *dev, int rpmflags);
+extern bool pm_runtime_get_if_in_use(struct device *dev);
extern int pm_schedule_suspend(struct device *dev, unsigned int delay);
extern int __pm_runtime_set_status(struct device *dev, unsigned int status);
extern int pm_runtime_barrier(struct device *dev);
@@ -143,6 +144,10 @@ static inline int pm_schedule_suspend(st
{
return -ENOSYS;
}
+static inline bool pm_runtime_get_if_in_use(struct device *dev)
+{
+ return true;
+}
static inline int __pm_runtime_set_status(struct device *dev,
Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle
On Saturday, December 12, 2015 07:49:56 PM Chris Wilson wrote:
> On Sat, Dec 12, 2015 at 09:40:45PM +0200, Imre Deak wrote:
> > On Sat, 2015-12-12 at 02:51 +0100, Rafael J. Wysocki wrote:
> > > +bool pm_runtime_get_if_in_use(struct device *dev)
> > > +{
> > > + unsigned long flags;
> > > + bool retval;
> > > +
> > > + spin_lock_irqsave(&dev->power.lock, flags);
> > > + retval = dev->power.runtime_status == RPM_ACTIVE ?
> > > + !!atomic_inc_not_zero(&dev->power.usage_count) :
> > > false;
> > > + spin_unlock_irqrestore(&dev->power.lock, flags);
> > > + return retval;
> > > +}
> > > +EXPORT_SYMBOL_GPL(pm_runtime_get_if_in_use);
> > > +
> >
> > To me this looks ok:
> > Acked-by: Imre Deak
>
> Pendant says
> retval = (dev->power.runtime_status == RPM_ACTIVE &&
> atomic_inc_not_zero(&dev->power.usage_count);
Well, this wouldn't build AFAICS.
retval = dev->power.runtime_status == RPM_ACTIVE &&
atomic_inc_not_zero(&dev->power.usage_count);
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] PM / runtime: Add new helper for conditional usage count incrementation
From: Rafael J. Wysocki
Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
that will increment the device's runtime PM usage counter and
return 'true' if its status is RPM_ACTIVE and its usage counter
is greater than 0 at the same time ('false' will be returned
otherwise).
This is useful for things that should only be done if the device
is active (from the runtime PM perspective) and used by somebody
(as indicated by the usage counter) already and they are not worth
bothering otherwise.
Requested-by: Imre Deak
Acked-by: Imre Deak
Signed-off-by: Rafael J. Wysocki
---
Documentation/power/runtime_pm.txt |5 +
drivers/base/power/runtime.c | 21 +
include/linux/pm_runtime.h |5 +
3 files changed, 31 insertions(+)
Index: linux-pm/drivers/base/power/runtime.c
===
--- linux-pm.orig/drivers/base/power/runtime.c
+++ linux-pm/drivers/base/power/runtime.c
@@ -966,6 +966,27 @@ int __pm_runtime_resume(struct device *d
EXPORT_SYMBOL_GPL(__pm_runtime_resume);
/**
+ * pm_runtime_get_if_in_use - Conditionally bump up the device's usage counter.
+ * @dev: Device to handle.
+ *
+ * Increment the device's runtime PM usage counter and return 'true' if its
+ * runtime PM status is RPM_ACTIVE and its usage counter is already different
+ * from zero at the same time. Otherwise, return 'false'.
+ */
+bool pm_runtime_get_if_in_use(struct device *dev)
+{
+ unsigned long flags;
+ bool retval;
+
+ spin_lock_irqsave(&dev->power.lock, flags);
+ retval = dev->power.runtime_status == RPM_ACTIVE
+ && atomic_inc_not_zero(&dev->power.usage_count);
+ spin_unlock_irqrestore(&dev->power.lock, flags);
+ return retval;
+}
+EXPORT_SYMBOL_GPL(pm_runtime_get_if_in_use);
+
+/**
* __pm_runtime_set_status - Set runtime PM status of a device.
* @dev: Device to handle.
* @status: New runtime PM status of the device.
Index: linux-pm/include/linux/pm_runtime.h
===
--- linux-pm.orig/include/linux/pm_runtime.h
+++ linux-pm/include/linux/pm_runtime.h
@@ -39,6 +39,7 @@ extern int pm_runtime_force_resume(struc
extern int __pm_runtime_idle(struct device *dev, int rpmflags);
extern int __pm_runtime_suspend(struct device *dev, int rpmflags);
extern int __pm_runtime_resume(struct device *dev, int rpmflags);
+extern bool pm_runtime_get_if_in_use(struct device *dev);
extern int pm_schedule_suspend(struct device *dev, unsigned int delay);
extern int __pm_runtime_set_status(struct device *dev, unsigned int status);
extern int pm_runtime_barrier(struct device *dev);
@@ -143,6 +144,10 @@ static inline int pm_schedule_suspend(st
{
return -ENOSYS;
}
+static inline bool pm_runtime_get_if_in_use(struct device *dev)
+{
+ return true;
+}
static inline int __pm_runtime_set_status(struct device *dev,
unsigned int status) { return 0; }
static inline int pm_runtime_barrier(struct device *dev) { return 0; }
Index: linux-pm/Documentation/power/runtime_pm.txt
===
--- linux-pm.orig/Documentation/power/runtime_pm.txt
+++ linux-pm/Documentation/power/runtime_pm.txt
@@ -371,6 +371,11 @@ drivers/base/power/runtime.c and include
- increment the device's usage counter, run pm_runtime_resume(dev) and
return its result
+ bool pm_runtime_get_if_in_use(struct device *dev);
+- increment the device's usage counter and return 'true' if its runtime PM
+ status is 'active' and its usage counter is greater than 0 at the same
+ time; return 'false' otherwise
+
void pm_runtime_put_noidle(struct device *dev);
- decrement the device's usage counter
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] PM / runtime: Add new helper for conditional usage count incrementation
On Tuesday, December 15, 2015 03:28:54 PM Ulf Hansson wrote:
> On 14 December 2015 at 23:22, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
>
> As we already have pm_runtime_set_active() and pm_runtime_active(),
> changing the new function name to "pm_runtime_get_if_active" may be
> better!?
"In use" is supposed to mean "active and reference counted".
> > that will increment the device's runtime PM usage counter and
> > return 'true' if its status is RPM_ACTIVE and its usage counter
> > is greater than 0 at the same time ('false' will be returned
> > otherwise).
> >
> > This is useful for things that should only be done if the device
> > is active (from the runtime PM perspective) and used by somebody
> > (as indicated by the usage counter) already and they are not worth
> > bothering otherwise.
> >
> > Requested-by: Imre Deak
> > Acked-by: Imre Deak
> > Signed-off-by: Rafael J. Wysocki
> > ---
> > Documentation/power/runtime_pm.txt |5 +
> > drivers/base/power/runtime.c | 21 +
> > include/linux/pm_runtime.h |5 +
> > 3 files changed, 31 insertions(+)
> >
> > Index: linux-pm/drivers/base/power/runtime.c
> > ===
> > --- linux-pm.orig/drivers/base/power/runtime.c
> > +++ linux-pm/drivers/base/power/runtime.c
> > @@ -966,6 +966,27 @@ int __pm_runtime_resume(struct device *d
> > EXPORT_SYMBOL_GPL(__pm_runtime_resume);
> >
> > /**
> > + * pm_runtime_get_if_in_use - Conditionally bump up the device's usage
> > counter.
> > + * @dev: Device to handle.
> > + *
> > + * Increment the device's runtime PM usage counter and return 'true' if its
> > + * runtime PM status is RPM_ACTIVE and its usage counter is already
> > different
> > + * from zero at the same time. Otherwise, return 'false'.
> > + */
> > +bool pm_runtime_get_if_in_use(struct device *dev)
> > +{
> > + unsigned long flags;
> > + bool retval;
> > +
> > + spin_lock_irqsave(&dev->power.lock, flags);
> > + retval = dev->power.runtime_status == RPM_ACTIVE
> > + && atomic_inc_not_zero(&dev->power.usage_count);
>
> Don't we also need to check that runtime PM is enabled (&&
> !dev->power.disable_depth), or the user of this function don't care
> about that?
The user probably cares, but calling this for devices with runtime PM
disabled doesn't really make sense to me (the status is not meaningful
then).
> > + spin_unlock_irqrestore(&dev->power.lock, flags);
> > + return retval;
> > +}
> > +EXPORT_SYMBOL_GPL(pm_runtime_get_if_in_use);
> > +
>
> [...]
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] PM / runtime: Add new helper for conditional usage count incrementation
On Tuesday, December 15, 2015 10:06:33 AM Alan Stern wrote:
> On Mon, 14 Dec 2015, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki
> >
> > Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
> > that will increment the device's runtime PM usage counter and
> > return 'true' if its status is RPM_ACTIVE and its usage counter
> > is greater than 0 at the same time ('false' will be returned
> > otherwise).
> >
> > This is useful for things that should only be done if the device
> > is active (from the runtime PM perspective) and used by somebody
> > (as indicated by the usage counter) already and they are not worth
> > bothering otherwise.
>
>
> > --- linux-pm.orig/drivers/base/power/runtime.c
> > +++ linux-pm/drivers/base/power/runtime.c
> > @@ -966,6 +966,27 @@ int __pm_runtime_resume(struct device *d
> > EXPORT_SYMBOL_GPL(__pm_runtime_resume);
> >
> > /**
> > + * pm_runtime_get_if_in_use - Conditionally bump up the device's usage
> > counter.
> > + * @dev: Device to handle.
> > + *
> > + * Increment the device's runtime PM usage counter and return 'true' if its
> > + * runtime PM status is RPM_ACTIVE and its usage counter is already
> > different
> > + * from zero at the same time. Otherwise, return 'false'.
>
> The phrasing of this comment is slightly ambiguous (it's not clear
> whether the "if" clause applies to both the increment and the return
> or just the return). IMO it would be somewhat better to write:
>
> If the runtime PM status is RPM_ACTIVE and the runtime PM usage
> counter is nonzero, increment the counter and return 'true'.
> Otherwise return false without changing the counter.
Yes, that sounds better, thanks!
I'll resend the patch with that modification.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] PM / runtime: Add new helper for conditional usage count incrementation
From: Rafael J. Wysocki
Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
that will increment the device's runtime PM usage counter and
return 'true' if its status is RPM_ACTIVE and its usage counter
is greater than 0 at the same time ('false' will be returned
otherwise).
This is useful for things that should only be done if the device
is active (from the runtime PM perspective) and used by somebody
(as indicated by the usage counter) already and they are not worth
bothering otherwise.
Requested-by: Imre Deak
Signed-off-by: Rafael J. Wysocki
---
Changes from v1:
- kerneldoc and runtime PM doc changes as suggested by Alan.
- The new function returns an int now and -EINVAL is returned for devices
with runtime PM disabled.
---
Documentation/power/runtime_pm.txt |6 ++
drivers/base/power/runtime.c | 24
include/linux/pm_runtime.h |5 +
3 files changed, 35 insertions(+)
Index: linux-pm/drivers/base/power/runtime.c
===
--- linux-pm.orig/drivers/base/power/runtime.c
+++ linux-pm/drivers/base/power/runtime.c
@@ -966,6 +966,30 @@ int __pm_runtime_resume(struct device *d
EXPORT_SYMBOL_GPL(__pm_runtime_resume);
/**
+ * pm_runtime_get_if_in_use - Conditionally bump up the device's usage counter.
+ * @dev: Device to handle.
+ *
+ * Return -EINVAL if runtime PM is disabled for the device.
+ *
+ * If that's not the case and if the device's runtime PM status is RPM_ACTIVE
+ * and the runtime PM usage counter is nonzero, increment the counter and
+ * return 1. Otherwise return 0 without changing the counter.
+ */
+int pm_runtime_get_if_in_use(struct device *dev)
+{
+ unsigned long flags;
+ int retval;
+
+ spin_lock_irqsave(&dev->power.lock, flags);
+ retval = dev->power.disable_depth > 0 ? -EINVAL :
+ dev->power.runtime_status == RPM_ACTIVE
+ && atomic_inc_not_zero(&dev->power.usage_count);
+ spin_unlock_irqrestore(&dev->power.lock, flags);
+ return retval;
+}
+EXPORT_SYMBOL_GPL(pm_runtime_get_if_in_use);
+
+/**
* __pm_runtime_set_status - Set runtime PM status of a device.
* @dev: Device to handle.
* @status: New runtime PM status of the device.
Index: linux-pm/include/linux/pm_runtime.h
===
--- linux-pm.orig/include/linux/pm_runtime.h
+++ linux-pm/include/linux/pm_runtime.h
@@ -39,6 +39,7 @@ extern int pm_runtime_force_resume(struc
extern int __pm_runtime_idle(struct device *dev, int rpmflags);
extern int __pm_runtime_suspend(struct device *dev, int rpmflags);
extern int __pm_runtime_resume(struct device *dev, int rpmflags);
+extern int pm_runtime_get_if_in_use(struct device *dev);
extern int pm_schedule_suspend(struct device *dev, unsigned int delay);
extern int __pm_runtime_set_status(struct device *dev, unsigned int status);
extern int pm_runtime_barrier(struct device *dev);
@@ -143,6 +144,10 @@ static inline int pm_schedule_suspend(st
{
return -ENOSYS;
}
+static inline int pm_runtime_get_if_in_use(struct device *dev)
+{
+ return -EINVAL;
+}
static inline int __pm_runtime_set_status(struct device *dev,
unsigned int status) { return 0; }
static inline int pm_runtime_barrier(struct device *dev) { return 0; }
Index: linux-pm/Documentation/power/runtime_pm.txt
===
--- linux-pm.orig/Documentation/power/runtime_pm.txt
+++ linux-pm/Documentation/power/runtime_pm.txt
@@ -371,6 +371,12 @@ drivers/base/power/runtime.c and include
- increment the device's usage counter, run pm_runtime_resume(dev) and
return its result
+ int pm_runtime_get_if_in_use(struct device *dev);
+- return -EINVAL if 'power.disable_depth' is nonzero; otherwise, if the
+ runtime PM status is RPM_ACTIVE and the runtime PM usage counter is
+ nonzero, increment the counter and return 1; otherwise return 0 without
+ changing the counter
+
void pm_runtime_put_noidle(struct device *dev);
- decrement the device's usage counter
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 create the link, so that the i915 driver's >> pwm_get(dev, "pwm_backlight") call returns the lpss' pwm0. >> >> The PWM subsystem does not want to have pwm_add_table() calls >> directly in PWM drivers (this leads to probe ordering issues), >> so lets do it here since the acpi-lpss code is always builtin. >> >> Signed-off-by: Hans de Goede >> Acked-by: Thierry Reding >> --- >> Changes in v2: >> -Set new pwm_lookup module_name field in the table >> --- >> drivers/acpi/acpi_lpss.c | 13 + >> 1 file changed, 13 insertions(+) > > Rafael, do you mind if I take this through the PWM tree to resolve the > build-time dependency? No, I don't, please go ahead, unless Mika/Andy see any problems in it. Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 wrote:
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 tree up to...
commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
"mm/filemap: fix parameters to test_bit()"
Here we go...
[ 29.636047] BUG: sleeping function called from invalid context at
drivers/base/power/runtime.c:1032
[ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
[ 29.636058] 1 lock held by Xorg/1500:
[ 29.636060] #0: (&dev->struct_mutex){+.+.+.}, at:
[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
[ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
4.10.0-rc1-6-iniza-amd64 #1
[ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
[ 29.636111] Call Trace:
[ 29.636120] dump_stack+0x85/0xc2
[ 29.636124] ___might_sleep+0x196/0x260
[ 29.636127] __might_sleep+0x53/0xb0
[ 29.636131] __pm_runtime_resume+0x7a/0x90
[ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915]
[ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
[ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915]
[ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
[ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
[ 29.636275] ? trace_hardirqs_on+0xd/0x10
[ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
[ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
[ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
[ 29.636347] ? __might_fault+0x4e/0xb0
[ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915]
[ 29.636376] ? __might_fault+0x4e/0xb0
[ 29.636395] drm_ioctl+0x206/0x450 [drm]
[ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915]
[ 29.636425] ? __fget+0x5/0x200
[ 29.636429] do_vfs_ioctl+0x91/0x6f0
[ 29.636431] ? __fget+0x111/0x200
[ 29.636433] ? __fget+0x5/0x200
[ 29.636436] SyS_ioctl+0x79/0x90
[ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6
On suspend/resume I see the same call trace.
[2] points to the "BUG" line.
Well, this appears to be an i915 issue, but not a serious one.
Clearly, a function that may sleep (pm_runtime_get_sync() in
intel_runtime_pm_get()) is called with disabled interrupts. If I
understand the code correctly, though, it actually is not going to
sleep in this particular case, because pm_runtime_get_sync() has
already been called once for this device in the same code path which
means that this particular instance will return immediately, so this
is a false-positive (most likely).
Let me see if I the might_sleep_if() assertion in
__pm_runtime_resume(() can be moved to a better place.
Hi Rafael,
did you had a chance to look at this?
The problem still remains in Linux v4.10-rc5.
No, I didn't.
As I said, this is not a serious issue.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 wrote:
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 tree up to...
commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
"mm/filemap: fix parameters to test_bit()"
Here we go...
[ 29.636047] BUG: sleeping function called from invalid context at
drivers/base/power/runtime.c:1032
[ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
[ 29.636058] 1 lock held by Xorg/1500:
[ 29.636060] #0: (&dev->struct_mutex){+.+.+.}, at:
[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
[ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
4.10.0-rc1-6-iniza-amd64 #1
[ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
[ 29.636111] Call Trace:
[ 29.636120] dump_stack+0x85/0xc2
[ 29.636124] ___might_sleep+0x196/0x260
[ 29.636127] __might_sleep+0x53/0xb0
[ 29.636131] __pm_runtime_resume+0x7a/0x90
[ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915]
[ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
[ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915]
[ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
[ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
[ 29.636275] ? trace_hardirqs_on+0xd/0x10
[ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
[ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
[ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
[ 29.636347] ? __might_fault+0x4e/0xb0
[ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915]
[ 29.636376] ? __might_fault+0x4e/0xb0
[ 29.636395] drm_ioctl+0x206/0x450 [drm]
[ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915]
[ 29.636425] ? __fget+0x5/0x200
[ 29.636429] do_vfs_ioctl+0x91/0x6f0
[ 29.636431] ? __fget+0x111/0x200
[ 29.636433] ? __fget+0x5/0x200
[ 29.636436] SyS_ioctl+0x79/0x90
[ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6
On suspend/resume I see the same call trace.
[2] points to the "BUG" line.
Well, this appears to be an i915 issue, but not a serious one.
Clearly, a function that may sleep (pm_runtime_get_sync() in
intel_runtime_pm_get()) is called with disabled interrupts. If I
understand the code correctly, though, it actually is not going to
sleep in this particular case, because pm_runtime_get_sync() has
already been called once for this device in the same code path which
means that this particular instance will return immediately, so this
is a false-positive (most likely).
Not sure what's the root cause, but thought to clarify the above:
Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize
things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume
the device on this path. This isn't a guarantee though,
aliasing_gtt_bind_vma() could be called from other places without an RPM
reference. So preemption being disabled at that point is not
intentional. I also can't see where on the above path it would get
disabled due to a bug or otherwise.
The i915 code is correct AFAICS, but the core complains about a nested
invocation of pm_runtime_get_sync() with disabled interrupts (which
looks OK though), so the complaint is a false positive.
As I said, the way to go here appears to be to tweak the core, which I'm
going to do.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 at 3:02 PM, Rafael J. Wysocki wrote:
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 tree up to...
commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
"mm/filemap: fix parameters to test_bit()"
Here we go...
[ 29.636047] BUG: sleeping function called from invalid context at
drivers/base/power/runtime.c:1032
[ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
[ 29.636058] 1 lock held by Xorg/1500:
[ 29.636060] #0: (&dev->struct_mutex){+.+.+.}, at:
[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
[ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
4.10.0-rc1-6-iniza-amd64 #1
[ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
[ 29.636111] Call Trace:
[ 29.636120] dump_stack+0x85/0xc2
[ 29.636124] ___might_sleep+0x196/0x260
[ 29.636127] __might_sleep+0x53/0xb0
[ 29.636131] __pm_runtime_resume+0x7a/0x90
[ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915]
[ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
[ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915]
[ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
[ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
[ 29.636275] ? trace_hardirqs_on+0xd/0x10
[ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
[ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
[ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
[ 29.636347] ? __might_fault+0x4e/0xb0
[ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915]
[ 29.636376] ? __might_fault+0x4e/0xb0
[ 29.636395] drm_ioctl+0x206/0x450 [drm]
[ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915]
[ 29.636425] ? __fget+0x5/0x200
[ 29.636429] do_vfs_ioctl+0x91/0x6f0
[ 29.636431] ? __fget+0x111/0x200
[ 29.636433] ? __fget+0x5/0x200
[ 29.636436] SyS_ioctl+0x79/0x90
[ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6
On suspend/resume I see the same call trace.
[2] points to the "BUG" line.
Well, this appears to be an i915 issue, but not a serious one.
Clearly, a function that may sleep (pm_runtime_get_sync() in
intel_runtime_pm_get()) is called with disabled interrupts. If I
understand the code correctly, though, it actually is not going to
sleep in this particular case, because pm_runtime_get_sync() has
already been called once for this device in the same code path which
means that this particular instance will return immediately, so this
is a false-positive (most likely).
Not sure what's the root cause, but thought to clarify the above:
Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize
things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume
the device on this path. This isn't a guarantee though,
aliasing_gtt_bind_vma() could be called from other places without an RPM
reference. So preemption being disabled at that point is not
intentional. I also can't see where on the above path it would get
disabled due to a bug or otherwise.
The i915 code is correct AFAICS, but the core complains about a nested
invocation of pm_runtime_get_sync() with disabled interrupts (which looks OK
though), so the complaint is a false positive.
Well, my point was that interrupts (or preemption) doesn't seem to get
disabled anywhere on that path.
But the might_sleep_if() assertion in __pm_runtime_resume() triggers for
some reason. I wonder why then?
Of course, I may be overlooking something in the i915 code.
In any case, if you do
pm_runtime_get_sync(dev)
local_irq_disable()
pm_runtime_get_sync(dev)
pm_runtime_put(dev)
local_irq_enable()
pm_runtime_put(dev)
that is technically correct, but it will cause the core to complain.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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
wrote:
> On 1/24/2017 2:33 AM, Sedat Dilek wrote:
>>
>> On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki
>> wrote:
>>>
>>> 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 tree up to...
>>>>
>>>> commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
>>>> "mm/filemap: fix parameters to test_bit()"
>>>>
>>>> Here we go...
>>>>
>>>> [ 29.636047] BUG: sleeping function called from invalid context at
>>>> drivers/base/power/runtime.c:1032
>>>> [ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
>>>> [ 29.636058] 1 lock held by Xorg/1500:
>>>> [ 29.636060] #0: (&dev->struct_mutex){+.+.+.}, at:
>>>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>>>> [ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
>>>> 4.10.0-rc1-6-iniza-amd64 #1
>>>> [ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>>> [ 29.636111] Call Trace:
>>>> [ 29.636120] dump_stack+0x85/0xc2
>>>> [ 29.636124] ___might_sleep+0x196/0x260
>>>> [ 29.636127] __might_sleep+0x53/0xb0
>>>> [ 29.636131] __pm_runtime_resume+0x7a/0x90
>>>> [ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915]
>>>> [ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
>>>> [ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915]
>>>> [ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
>>>> [ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250
>>>> [i915]
>>>> [ 29.636275] ? trace_hardirqs_on+0xd/0x10
>>>> [ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0
>>>> [i915]
>>>> [ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
>>>> [ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
>>>> [ 29.636347] ? __might_fault+0x4e/0xb0
>>>> [ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915]
>>>> [ 29.636376] ? __might_fault+0x4e/0xb0
>>>> [ 29.636395] drm_ioctl+0x206/0x450 [drm]
>>>> [ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915]
>>>> [ 29.636425] ? __fget+0x5/0x200
>>>> [ 29.636429] do_vfs_ioctl+0x91/0x6f0
>>>> [ 29.636431] ? __fget+0x111/0x200
>>>> [ 29.636433] ? __fget+0x5/0x200
>>>> [ 29.636436] SyS_ioctl+0x79/0x90
>>>> [ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6
>>>>
>>>> On suspend/resume I see the same call trace.
>>>> [2] points to the "BUG" line.
>>>
>>> Well, this appears to be an i915 issue, but not a serious one.
>>>
>>> Clearly, a function that may sleep (pm_runtime_get_sync() in
>>> intel_runtime_pm_get()) is called with disabled interrupts. If I
>>> understand the code correctly, though, it actually is not going to
>>> sleep in this particular case, because pm_runtime_get_sync() has
>>> already been called once for this device in the same code path which
>>> means that this particular instance will return immediately, so this
>>> is a false-positive (most likely).
>>>
>>> Let me see if I the might_sleep_if() assertion in
>>> __pm_runtime_resume(() can be moved to a better place.
>>>
>> Hi Rafael,
>>
>> did you had a chance to look at this?
>> The problem still remains in Linux v4.10-rc5.
>
>
> No, I didn't.
>
> As I said, this is not a serious issue.
Something like the attached (untested).
Please try it and let me know if it makes the splat go away.
Thanks,
Rafael
---
drivers/base/power/runtime.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
Index: linux-pm/drivers/base/power/runtime.c
===
--- linux-pm.orig/drivers/base/power/runtime.c
+++ linux-pm/drivers/base/power/runtime.c
@@ -966,13 +966,13 @@ int __pm_runtime_idle(struct device *dev
unsigned long flags;
int retval;
- might_sleep_if(!(rpmflags & RPM_ASYNC) &&a
[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 wrote:
> > On Mon, Jan 30, 2017 at 11:44 PM, 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
> >>> wrote:
> >>>>
> >>>> 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 tree up to...
> >>>>>
> >>>>> commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
> >>>>> "mm/filemap: fix parameters to test_bit()"
> >>>>>
> >>>>> Here we go...
> >>>>>
> >>>>> [ 29.636047] BUG: sleeping function called from invalid context at
> >>>>> drivers/base/power/runtime.c:1032
> >>>>> [ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
> >>>>> [ 29.636058] 1 lock held by Xorg/1500:
> >>>>> [ 29.636060] #0: (&dev->struct_mutex){+.+.+.}, at:
> >>>>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> >>>>> [ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
> >>>>> 4.10.0-rc1-6-iniza-amd64 #1
> >>>>> [ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> >>>>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> >>>>> [ 29.636111] Call Trace:
> >>>>> [ 29.636120] dump_stack+0x85/0xc2
> >>>>> [ 29.636124] ___might_sleep+0x196/0x260
> >>>>> [ 29.636127] __might_sleep+0x53/0xb0
> >>>>> [ 29.636131] __pm_runtime_resume+0x7a/0x90
> >>>>> [ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915]
> >>>>> [ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
> >>>>> [ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915]
> >>>>> [ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
> >>>>> [ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250
> >>>>> [i915]
> >>>>> [ 29.636275] ? trace_hardirqs_on+0xd/0x10
> >>>>> [ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0
> >>>>> [i915]
> >>>>> [ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
> >>>>> [ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
> >>>>> [ 29.636347] ? __might_fault+0x4e/0xb0
> >>>>> [ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915]
> >>>>> [ 29.636376] ? __might_fault+0x4e/0xb0
> >>>>> [ 29.636395] drm_ioctl+0x206/0x450 [drm]
> >>>>> [ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915]
> >>>>> [ 29.636425] ? __fget+0x5/0x200
> >>>>> [ 29.636429] do_vfs_ioctl+0x91/0x6f0
> >>>>> [ 29.636431] ? __fget+0x111/0x200
> >>>>> [ 29.636433] ? __fget+0x5/0x200
> >>>>> [ 29.636436] SyS_ioctl+0x79/0x90
> >>>>> [ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6
> >>>>>
> >>>>> On suspend/resume I see the same call trace.
> >>>>> [2] points to the "BUG" line.
> >>>>
> >>>> Well, this appears to be an i915 issue, but not a serious one.
> >>>>
> >>>> Clearly, a function that may sleep (pm_runtime_get_sync() in
> >>>> intel_runtime_pm_get()) is called with disabled interrupts. If I
> >>>> understand the code correctly, though, it actually is not going to
> >>>> sleep in this particular case, because pm_runtime_get_sync() has
> >>>> already been called once for this device in the same code path which
> >>>> means that this particular instance will return immediately, so this
> >>>> is a false-positive (most likely).
> >>>>
> >>>> Let me see if I the might_sleep_if() assertion in
> >>>> __pm_runtime_resume(() can be moved to a b
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
> {
> If (OSID == One)
> {
> Return (Zero)
> }
>
> Return (0x0F)
> }
>
> Where OSID is some dark magic seen in all cherrytrail ACPI tables making
> the machine behave differently depending on which OS it *thinks* it is
> booting, this gets set in a number of ways which we cannot control, on
> some newer machines it simple hardcoded to "One" aka win10.
>
> This causes the PWM controller to get hidden, which means Linux cannot
> control the backlight level on cht based tablets / laptops.
>
> Since loading the driver for this does no harm (the only in kernel user
> of it is the i915 driver, which will only use it when it needs it), this
> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
> for the 80862288 device, fixing the lack of backlight control.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/acpi/bus.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 95855cb..483d4d0 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -109,11 +109,36 @@ acpi_status acpi_bus_get_status_handle(acpi_handle
> handle,
> return status;
> }
>
> +/*
> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because
> + * some recent windows drivers bind to one device but poke at multiple
> + * devices at the same time, so the others get hidden.
> + * We work around this by always reporting ACPI_STA_DEFAULT for these
> + * devices. Note this MUST only be done for devices where this is safe.
> + */
> +static const struct acpi_device_id always_present_device_ids[] = {
> + /*
> + * Cherrytrail pwm directly poked by GPU driver in win10,
> + * but Linux uses a separate pwm driver, harmless if not used.
> + */
> + { "80862288", },
> + { }
> +};
> +
> int acpi_bus_get_status(struct acpi_device *device)
> {
> acpi_status status;
> unsigned long long sta;
>
> + /* acpi_match_device_ids checks status, so start with default */
> + acpi_set_device_status(device, ACPI_STA_DEFAULT);
This shouldn't be done in a "get" routine.
Ideally, a scan handler should do that or similar.
> + if (acpi_match_device_ids(device, always_present_device_ids) == 0) {
> + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device [%s] is in always
> present list setting status [%08x]\n",
> + device->pnp.bus_id, ACPI_STA_DEFAULT));
pr_debug() please. The ACPI_DEBUG_PRINT() stuff is basically for ACPICA
(yes, I know it is used elsewhere and no, it is not a good idea to do that).
> + return 0;
> + }
> + acpi_set_device_status(device, 0);
> +
> status = acpi_bus_get_status_handle(device->handle, &sta);
> if (ACPI_FAILURE(status))
> return -ENODEV;
>
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 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:
>>>
>>> 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
>>> {
>>> If (OSID == One)
>>> {
>>> Return (Zero)
>>> }
>>>
>>> Return (0x0F)
>>> }
>>>
>>> Where OSID is some dark magic seen in all cherrytrail ACPI tables making
>>> the machine behave differently depending on which OS it *thinks* it is
>>> booting, this gets set in a number of ways which we cannot control, on
>>> some newer machines it simple hardcoded to "One" aka win10.
>>>
>>> This causes the PWM controller to get hidden, which means Linux cannot
>>> control the backlight level on cht based tablets / laptops.
>>>
>>> Since loading the driver for this does no harm (the only in kernel user
>>> of it is the i915 driver, which will only use it when it needs it), this
>>> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
>>> for the 80862288 device, fixing the lack of backlight control.
>>>
>>> Signed-off-by: Hans de Goede
>>> ---
>>> drivers/acpi/bus.c | 25 +
>>> 1 file changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>>> index 95855cb..483d4d0 100644
>>> --- a/drivers/acpi/bus.c
>>> +++ b/drivers/acpi/bus.c
>>> @@ -109,11 +109,36 @@ acpi_status acpi_bus_get_status_handle(acpi_handle
>>> handle,
>>> return status;
>>> }
>>>
>>> +/*
>>> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
>>> because
>>> + * some recent windows drivers bind to one device but poke at multiple
>>> + * devices at the same time, so the others get hidden.
>>> + * We work around this by always reporting ACPI_STA_DEFAULT for these
>>> + * devices. Note this MUST only be done for devices where this is safe.
>>> + */
>>> +static const struct acpi_device_id always_present_device_ids[] = {
>>> + /*
>>> +* Cherrytrail pwm directly poked by GPU driver in win10,
>>> +* but Linux uses a separate pwm driver, harmless if not used.
>>> +*/
>>> + { "80862288", },
>>> + { }
>>> +};
>>> +
>>> int acpi_bus_get_status(struct acpi_device *device)
>>> {
>>> acpi_status status;
>>> unsigned long long sta;
>>>
>>> + /* acpi_match_device_ids checks status, so start with default */
>>> + acpi_set_device_status(device, ACPI_STA_DEFAULT);
>>
>>
>> This shouldn't be done in a "get" routine.
>
>
> With this you mean the acpi_match_device_ids() check I assume ?
> (acpi_bus_get_status already calls acpi_set_device_status())
Yes, the device ID check.
>> Ideally, a scan handler should do that or similar.
>
>
> The problem is that drivers/acpi/scan.c: acpi_bus_attach()
> calls acpi_bus_get_status() and if it does not set
> the status to present acpi_bus_attach() exits without bothering
> with attaching scan handlers, which is why I ended up doing this
> here.
Fair enough.
Two problems with this approach.
One is that it doesn't prevent _STA from being evaluated as
acpi_bus_get_status_handle() is called directly from a couple of
places.
Second, what if the same device ID is used on another system where
_STA actually works correctly for that device?
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 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 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
>> >> {
>> >> If (OSID == One)
>> >> {
>> >> Return (Zero)
>> >> }
>> >>
>> >> Return (0x0F)
>> >> }
>> >>
>> >> Where OSID is some dark magic seen in all cherrytrail ACPI tables making
>> >> the machine behave differently depending on which OS it *thinks* it is
>> >> booting, this gets set in a number of ways which we cannot control, on
>> >> some newer machines it simple hardcoded to "One" aka win10.
>> >>
>> >> This causes the PWM controller to get hidden, which means Linux cannot
>> >> control the backlight level on cht based tablets / laptops.
>> >>
>> >> Since loading the driver for this does no harm (the only in kernel user
>> >> of it is the i915 driver, which will only use it when it needs it), this
>> >> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
>> >> for the 80862288 device, fixing the lack of backlight control.
>> >>
>> >> Signed-off-by: Hans de Goede
>> >> ---
>> >> drivers/acpi/bus.c | 25 +
>> >> 1 file changed, 25 insertions(+)
>> >>
>> >> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>> >> index 95855cb..483d4d0 100644
>> >> --- a/drivers/acpi/bus.c
>> >> +++ b/drivers/acpi/bus.c
>> >> @@ -109,11 +109,36 @@ acpi_status acpi_bus_get_status_handle(acpi_handle
>> >> handle,
>> >>return status;
>> >> }
>> >>
>> >> +/*
>> >> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because
>> >> + * some recent windows drivers bind to one device but poke at multiple
>> >> + * devices at the same time, so the others get hidden.
>> >> + * We work around this by always reporting ACPI_STA_DEFAULT for these
>> >> + * devices. Note this MUST only be done for devices where this is safe.
>> >> + */
>> >> +static const struct acpi_device_id always_present_device_ids[] = {
>> >> + /*
>> >> + * Cherrytrail pwm directly poked by GPU driver in win10,
>> >> + * but Linux uses a separate pwm driver, harmless if not used.
>> >> + */
>> >> + { "80862288", },
>> >> + { }
>> >> +};
>> >> +
>> >> int acpi_bus_get_status(struct acpi_device *device)
>> >> {
>> >>acpi_status status;
>> >>unsigned long long sta;
>> >>
>> >> + /* acpi_match_device_ids checks status, so start with default */
>> >> + acpi_set_device_status(device, ACPI_STA_DEFAULT);
>> >
>> > This shouldn't be done in a "get" routine.
>>
>> With this you mean the acpi_match_device_ids() check I assume ?
>> (acpi_bus_get_status already calls acpi_set_device_status())
>>
>> > Ideally, a scan handler should do that or similar.
>>
>> The problem is that drivers/acpi/scan.c: acpi_bus_attach()
>> calls acpi_bus_get_status() and if it does not set
>> the status to present acpi_bus_attach() exits without bothering
>> with attaching scan handlers, which is why I ended up doing this
>> here.
>
> Oh, this is interesting, please let me join to the party.
>
> We've hit a similar problem, but for other one: namely, it's INT0002
> that is found on a few CHT devices. It's never bound properly by a
> similar reason, where _STA is always zero on Linux:
>
> Method (_STA, 0, NotSerialized) // _STA: Status
> {
> If (SOCS <= 0x04)
> {
> Return (0x0F)
> }
> Else
> {
> Return (Zero)
> }
> }
>
> The device is supposed to be a "virtual GPIO" stuff, and the driver
> hasn't been upstreamed from Intel. Due to the lack of this driver
> (and it's binding), the machine gets spurious IRQ#9 after the PM
> resume, and it locks up at the second time of PM.
Well, the solution here seems to be to acquire the missing driver
instead of adding quirks to the ACPI core.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 wrote:
> Hi,
>
>
> On 27-02-17 22:25, Rafael J. Wysocki wrote:
>>
>> On Mon, Feb 27, 2017 at 3:25 PM, Hans de Goede
>> 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:
>>>>>
>>>>>
>>>>> 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
>>>>> {
>>>>> If (OSID == One)
>>>>> {
>>>>> Return (Zero)
>>>>> }
>>>>>
>>>>> Return (0x0F)
>>>>> }
>>>>>
>>>>> Where OSID is some dark magic seen in all cherrytrail ACPI tables
>>>>> making
>>>>> the machine behave differently depending on which OS it *thinks* it is
>>>>> booting, this gets set in a number of ways which we cannot control, on
>>>>> some newer machines it simple hardcoded to "One" aka win10.
>>>>>
>>>>> This causes the PWM controller to get hidden, which means Linux cannot
>>>>> control the backlight level on cht based tablets / laptops.
>>>>>
>>>>> Since loading the driver for this does no harm (the only in kernel user
>>>>> of it is the i915 driver, which will only use it when it needs it),
>>>>> this
>>>>> commit makes acpi_bus_get_status() always set status to
>>>>> ACPI_STA_DEFAULT
>>>>> for the 80862288 device, fixing the lack of backlight control.
>>>>>
>>>>> Signed-off-by: Hans de Goede
>>>>> ---
>>>>> drivers/acpi/bus.c | 25 +
>>>>> 1 file changed, 25 insertions(+)
>>>>>
>>>>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>>>>> index 95855cb..483d4d0 100644
>>>>> --- a/drivers/acpi/bus.c
>>>>> +++ b/drivers/acpi/bus.c
>>>>> @@ -109,11 +109,36 @@ acpi_status
>>>>> acpi_bus_get_status_handle(acpi_handle
>>>>> handle,
>>>>> return status;
>>>>> }
>>>>>
>>>>> +/*
>>>>> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
>>>>> because
>>>>> + * some recent windows drivers bind to one device but poke at multiple
>>>>> + * devices at the same time, so the others get hidden.
>>>>> + * We work around this by always reporting ACPI_STA_DEFAULT for these
>>>>> + * devices. Note this MUST only be done for devices where this is
>>>>> safe.
>>>>> + */
>>>>> +static const struct acpi_device_id always_present_device_ids[] = {
>>>>> + /*
>>>>> +* Cherrytrail pwm directly poked by GPU driver in win10,
>>>>> +* but Linux uses a separate pwm driver, harmless if not used.
>>>>> +*/
>>>>> + { "80862288", },
>>>>> + { }
>>>>> +};
>>>>> +
>>>>> int acpi_bus_get_status(struct acpi_device *device)
>>>>> {
>>>>> acpi_status status;
>>>>> unsigned long long sta;
>>>>>
>>>>> + /* acpi_match_device_ids checks status, so start with default
>>>>> */
>>>>> + acpi_set_device_status(device, ACPI_STA_DEFAULT);
>>>>
>>>>
>>>>
>>>> This shouldn't be done in a "get" routine.
>>>
>>>
>>>
>>> With this you mean the acpi_match_device_ids() check I assume ?
>>> (acpi_bus_get_status already calls acpi_set_device_status())
>>
>>
>> Yes, the device ID check.
>>
>>>> Ideally, a scan handler should do that or similar.
>>>
>>>
>>>
>>> The problem is that drivers/acpi/scan.c: acpi_bus_attach()
>>> calls acpi_bus_get_status() and if it does not set
>>> the status to present acpi_bus_attach() exits without bothering
>>> with attaching scan handlers, which is why I ended up doing this
>>> here.
>>
>>
>> Fair enough.
>>
>> Two problems with this approach.
>>
>> One is that it doesn't prevent _STA from being evaluated as
>> acpi_bus_get_status_handle() is called directly from a couple of
>> places.
>
> Yes I noticed that, but that is not a problem for this
> (and I would assume most) devices. Intervening directly
> in acpi_bus_get_status_handle is harder as there is no
> access to the hid there.
But if you modify acpi_set_device_status(), that should make it
consistent AFAICS.
And this is just a quirk for devices where _STA is known to return
garbage sometimes and I'd call it a quirk openly.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 wrote:
> Hi,
>
>
> On 27-02-17 22:49, Rafael J. Wysocki wrote:
>>
>> On Mon, Feb 27, 2017 at 10:29 PM, Hans de Goede
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 27-02-17 22:25, Rafael J. Wysocki wrote:
>>>>
>>>>
>>>> On Mon, Feb 27, 2017 at 3:25 PM, Hans de Goede
>>>> 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:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>> {
>>>>>>> If (OSID == One)
>>>>>>> {
>>>>>>> Return (Zero)
>>>>>>> }
>>>>>>>
>>>>>>> Return (0x0F)
>>>>>>> }
>>>>>>>
>>>>>>> Where OSID is some dark magic seen in all cherrytrail ACPI tables
>>>>>>> making
>>>>>>> the machine behave differently depending on which OS it *thinks* it
>>>>>>> is
>>>>>>> booting, this gets set in a number of ways which we cannot control,
>>>>>>> on
>>>>>>> some newer machines it simple hardcoded to "One" aka win10.
>>>>>>>
>>>>>>> This causes the PWM controller to get hidden, which means Linux
>>>>>>> cannot
>>>>>>> control the backlight level on cht based tablets / laptops.
>>>>>>>
>>>>>>> Since loading the driver for this does no harm (the only in kernel
>>>>>>> user
>>>>>>> of it is the i915 driver, which will only use it when it needs it),
>>>>>>> this
>>>>>>> commit makes acpi_bus_get_status() always set status to
>>>>>>> ACPI_STA_DEFAULT
>>>>>>> for the 80862288 device, fixing the lack of backlight control.
>>>>>>>
>>>>>>> Signed-off-by: Hans de Goede
>>>>>>> ---
>>>>>>> drivers/acpi/bus.c | 25 +
>>>>>>> 1 file changed, 25 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>>>>>>> index 95855cb..483d4d0 100644
>>>>>>> --- a/drivers/acpi/bus.c
>>>>>>> +++ b/drivers/acpi/bus.c
>>>>>>> @@ -109,11 +109,36 @@ acpi_status
>>>>>>> acpi_bus_get_status_handle(acpi_handle
>>>>>>> handle,
>>>>>>> return status;
>>>>>>> }
>>>>>>>
>>>>>>> +/*
>>>>>>> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
>>>>>>> because
>>>>>>> + * some recent windows drivers bind to one device but poke at
>>>>>>> multiple
>>>>>>> + * devices at the same time, so the others get hidden.
>>>>>>> + * We work around this by always reporting ACPI_STA_DEFAULT for
>>>>>>> these
>>>>>>> + * devices. Note this MUST only be done for devices where this is
>>>>>>> safe.
>>>>>>> + */
>>>>>>> +static const struct acpi_device_id always_present_device_ids[] = {
>>>>>>> + /*
>>>>>>> +* Cherrytrail pwm directly poked by GPU driver in win10,
>>>>>>> +* but Linux uses a separate pwm driver, harmless if not
>>>>>>> used.
>>>>>>> +*/
>>>>>>> + { "80862288", },
>>>>>>> + { }
>>>>>>> +};
>>>>>>> +
>&g
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Kill intel_runtime_pm_disable()
On Tuesday, November 10, 2015 09:20:56 AM Jesse Barnes wrote:
> On 11/06/2015 05:08 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > intel_runtime_pm_disable() takes an extra rpm reference which combined
> > with the one we leak from intel_display_set_init_power() leaves the
> > usage count at +1 after the driver has been unloaded.
> > The original ref is dropped explicitly in intel_runtime_pm_enable().
> > So the next time we load the driver we can no longer do runtime PM ever.
> >
> > This used to work, but
> > commit 292b990e86ab ("drm/i915: Update power domains on readout.")
> > broke things by not dropping the init power domain during fbdev
> > teardown. Based on the comment in intel_power_domains_fini(), the
> > way it used to to work wasn't intentional. As in we weren't supposed
> > to drop the init power during driver unload. And since we no longer
> > do, we now leak an extra rpm reference.
> >
> > So fix things by throwing intel_runtime_pm_disable() to the bin, so
> > that the only leaked reference comes from the init power domain.
> >
> > Cc: Maarten Lankhorst
> > Cc: Daniel Stone
> > Cc: Jesse Barnes
> > Fixes: 292b990e86ab ("drm/i915: Update power domains on readout.")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 17 -
> > 1 file changed, 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 1017555..bdc9ed4 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -1847,21 +1847,6 @@ int intel_power_domains_init(struct drm_i915_private
> > *dev_priv)
> > return 0;
> > }
> >
> > -static void intel_runtime_pm_disable(struct drm_i915_private *dev_priv)
> > -{
> > - struct drm_device *dev = dev_priv->dev;
> > - struct device *device = &dev->pdev->dev;
> > -
> > - if (!HAS_RUNTIME_PM(dev))
> > - return;
> > -
> > - if (!intel_enable_rc6(dev))
> > - return;
> > -
> > - /* Make sure we're not suspended first. */
> > - pm_runtime_get_sync(device);
> > -}
> > -
> > /**
> > * intel_power_domains_fini - finalizes the power domain structures
> > * @dev_priv: i915 device instance
> > @@ -1872,8 +1857,6 @@ static void intel_runtime_pm_disable(struct
> > drm_i915_private *dev_priv)
> > */
> > void intel_power_domains_fini(struct drm_i915_private *dev_priv)
> > {
> > - intel_runtime_pm_disable(dev_priv);
> > -
> > /* The i915.ko module is still not prepared to be loaded when
> > * the power well is not enabled, so just enable it in case
> > * we're going to unload/reload. */
> >
>
> Yeah I guess this is fine. Will we still disable RPM on unload? What's
> the expected behavior here? Cc'ing Rafael.
If that's a PCI device, you don't have to do anything with it. In fact,
you aren't expected to do anything with it even.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type
On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sha...@intel.com wrote:
> From: Ankitprasad Sharma
>
> Some modules, like i915.ko, needs to detect when certain ACPI features
> are active inorder to prevent corruption on contended resources.
> In particular, use of BIOS RapidStart Technology may corrupt the contents
> of the reserved graphics memory, due to unalarmed hibernation. In which
> case i915.ko cannot assume that it (reserved gfx memory) remains
> unmodified and must recreate teh contents and importantly not use it to
> store unrecoverable user data.
>
> Signed-off-by: Ankitprasad Sharma
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: linux-a...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
> drivers/acpi/bus.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index a212cef..69509c7 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> .remove = acpi_device_remove,
> .uevent = acpi_device_uevent,
> };
> +EXPORT_SYMBOL_GPL(acpi_bus_type);
>
> /* --
> Initialization/Cleanup
>
No.
I see no reason whatsoever for doing this.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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
> > >
> > > Some modules, like i915.ko, needs to detect when certain ACPI features
> > > are active inorder to prevent corruption on contended resources.
> > > In particular, use of BIOS RapidStart Technology may corrupt the contents
> > > of the reserved graphics memory, due to unalarmed hibernation. In which
> > > case i915.ko cannot assume that it (reserved gfx memory) remains
> > > unmodified and must recreate teh contents and importantly not use it to
> > > store unrecoverable user data.
> > >
> > > Signed-off-by: Ankitprasad Sharma
> > > Cc: "Rafael J. Wysocki"
> > > Cc: Len Brown
> > > Cc: linux-a...@vger.kernel.org
> > > Cc: linux-ker...@vger.kernel.org
> > > ---
> > > drivers/acpi/bus.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > > index a212cef..69509c7 100644
> > > --- a/drivers/acpi/bus.c
> > > +++ b/drivers/acpi/bus.c
> > > @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> > > .remove = acpi_device_remove,
> > > .uevent = acpi_device_uevent,
> > > };
> > > +EXPORT_SYMBOL_GPL(acpi_bus_type);
> > >
> > > /*
> > > --
> > > Initialization/Cleanup
> > >
> >
> > No.
> >
> > I see no reason whatsoever for doing this.
> >
> > Thanks,
> > Rafael
> Hi Rafael,
>
> Thanks for the response.
>
> Can you please help me with, how to detect the presence of a certain
> acpi device using its id (for example, INT3392 for Intel RST device)?
If you want to check if the device ir present at all, you cen use
acpi_device_is_present() introduced recently (although that would need
to be exported if you want to use it from a driver).
> As you might have seen (in the next patch in this series), that we use
> this symbol (acpi_bus_type) to iterate over all the devices registered
> on acpi bus, to check if there is a device with id INT3392 present or
> not.
Please don't do that this way.
I'll have a look at the other patch later.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type
On Monday, January 18, 2016 03:57:29 PM Rafael J. Wysocki wrote:
> 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
> > > >
> > > > Some modules, like i915.ko, needs to detect when certain ACPI features
> > > > are active inorder to prevent corruption on contended resources.
> > > > In particular, use of BIOS RapidStart Technology may corrupt the
> > > > contents
> > > > of the reserved graphics memory, due to unalarmed hibernation. In which
> > > > case i915.ko cannot assume that it (reserved gfx memory) remains
> > > > unmodified and must recreate teh contents and importantly not use it to
> > > > store unrecoverable user data.
> > > >
> > > > Signed-off-by: Ankitprasad Sharma
> > > > Cc: "Rafael J. Wysocki"
> > > > Cc: Len Brown
> > > > Cc: linux-a...@vger.kernel.org
> > > > Cc: linux-ker...@vger.kernel.org
> > > > ---
> > > > drivers/acpi/bus.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > > > index a212cef..69509c7 100644
> > > > --- a/drivers/acpi/bus.c
> > > > +++ b/drivers/acpi/bus.c
> > > > @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> > > > .remove = acpi_device_remove,
> > > > .uevent = acpi_device_uevent,
> > > > };
> > > > +EXPORT_SYMBOL_GPL(acpi_bus_type);
> > > >
> > > > /*
> > > > --
> > > > Initialization/Cleanup
> > > >
> > >
> > > No.
> > >
> > > I see no reason whatsoever for doing this.
> > >
> > > Thanks,
> > > Rafael
> > Hi Rafael,
> >
> > Thanks for the response.
> >
> > Can you please help me with, how to detect the presence of a certain
> > acpi device using its id (for example, INT3392 for Intel RST device)?
>
> If you want to check if the device ir present at all, you cen use
> acpi_device_is_present() introduced recently (although that would need
> to be exported if you want to use it from a driver).
I meant acpi_dev_present(), sorry about the mistake.
I guess we should rename it to acpi_device_found() or something similar
to avoid such confusion in the future.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type
On Monday, January 18, 2016 11:39:07 PM Lukas Wunner wrote:
> Hi,
>
> On Mon, Jan 18, 2016 at 11:28:27PM +0100, Rafael J. Wysocki wrote:
> > On Monday, January 18, 2016 03:57:29 PM Rafael J. Wysocki wrote:
> > > 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
> > > > > >
> > > > > > Some modules, like i915.ko, needs to detect when certain ACPI
> > > > > > features
> > > > > > are active inorder to prevent corruption on contended resources.
> > > > > > In particular, use of BIOS RapidStart Technology may corrupt the
> > > > > > contents
> > > > > > of the reserved graphics memory, due to unalarmed hibernation. In
> > > > > > which
> > > > > > case i915.ko cannot assume that it (reserved gfx memory) remains
> > > > > > unmodified and must recreate teh contents and importantly not use
> > > > > > it to
> > > > > > store unrecoverable user data.
> > > > > >
> > > > > > Signed-off-by: Ankitprasad Sharma
> > > > > > Cc: "Rafael J. Wysocki"
> > > > > > Cc: Len Brown
> > > > > > Cc: linux-a...@vger.kernel.org
> > > > > > Cc: linux-ker...@vger.kernel.org
> > > > > > ---
> > > > > > drivers/acpi/bus.c | 1 +
> > > > > > 1 file changed, 1 insertion(+)
> > > > > >
> > > > > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > > > > > index a212cef..69509c7 100644
> > > > > > --- a/drivers/acpi/bus.c
> > > > > > +++ b/drivers/acpi/bus.c
> > > > > > @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> > > > > > .remove = acpi_device_remove,
> > > > > > .uevent = acpi_device_uevent,
> > > > > > };
> > > > > > +EXPORT_SYMBOL_GPL(acpi_bus_type);
> > > > > >
> > > > > > /*
> > > > > > --
> > > > > > Initialization/Cleanup
> > > > > >
> > > > >
> > > > > No.
> > > > >
> > > > > I see no reason whatsoever for doing this.
> > > > >
> > > > > Thanks,
> > > > > Rafael
> > > > Hi Rafael,
> > > >
> > > > Thanks for the response.
> > > >
> > > > Can you please help me with, how to detect the presence of a certain
> > > > acpi device using its id (for example, INT3392 for Intel RST device)?
> > >
> > > If you want to check if the device ir present at all, you cen use
> > > acpi_device_is_present() introduced recently (although that would need
> > > to be exported if you want to use it from a driver).
> >
> > I meant acpi_dev_present(), sorry about the mistake.
> >
> > I guess we should rename it to acpi_device_found() or something similar
> > to avoid such confusion in the future.
>
> The name was chosen because the PCI equivalent is called pci_dev_present()
> and I assumed that name already stuck in developers' heads, so if they're
> looking for an ACPI presence detection function, that's what they'd look
> for first.
But "present" in ACPI really means something different. There may be ACPI
device objects in the namespace for devices that are not *actually* present.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 ir present at all, you cen use > > > > > acpi_device_is_present() introduced recently (although that would need > > > > > to be exported if you want to use it from a driver). > > > > > > > > I meant acpi_dev_present(), sorry about the mistake. > > > > > > > > I guess we should rename it to acpi_device_found() or something similar > > > > to avoid such confusion in the future. > > > > > > The name was chosen because the PCI equivalent is called pci_dev_present() > > > and I assumed that name already stuck in developers' heads, so if they're > > > looking for an ACPI presence detection function, that's what they'd look > > > for first. > > > > But "present" in ACPI really means something different. There may be ACPI > > device objects in the namespace for devices that are not *actually* present. > > You mean synthesized devices like LNXSYBUS? > Don't think anyone is going to test for the presence of that. No, I mean real devices, where the corresponding ACPI object has _STA that returns 0. There may be a couple of reasons for that. The device the ACPI object corresponds to may not be physically present (eg. it may possible to hot-add it) or the device may depend on something else for functionality and that thing hasn't been set up yet etc. The presence of an ACPI device object in the namespace means that the platform firmware knows about the device, but it need not mean that the device is really there. _STA returns that piece of information. > > I've posted 5 patches over the last days which use acpi_dev_present(): > > http://lists.freedesktop.org/archives/dri-devel/2016-January/098403.html > http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103056.html > http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103058.html > http://thread.gmane.org/gmane.linux.drivers.platform.x86.devel/8474/focus=8475 > http://thread.gmane.org/gmane.linux.drivers.platform.x86.devel/8474/focus=8476 > > When considering a rename of the function, please bear in mind that it > will cause breakage for anyone testing or merging these patches. > (Postponing a rename until these patches have landed would avoid that.) No problem with that. Please let me know when these patches are merged. Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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, 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 ir present at all, you cen use > > > > > > > acpi_device_is_present() introduced recently (although that would > > > > > > > need > > > > > > > to be exported if you want to use it from a driver). > > > > > > > > > > > > I meant acpi_dev_present(), sorry about the mistake. > > > > > > > > > > > > I guess we should rename it to acpi_device_found() or something > > > > > > similar > > > > > > to avoid such confusion in the future. > > > > > > > > > > The name was chosen because the PCI equivalent is called > > > > > pci_dev_present() > > > > > and I assumed that name already stuck in developers' heads, so if > > > > > they're > > > > > looking for an ACPI presence detection function, that's what they'd > > > > > look > > > > > for first. > > > > > > > > But "present" in ACPI really means something different. There may be > > > > ACPI > > > > device objects in the namespace for devices that are not *actually* > > > > present. > > > > > > You mean synthesized devices like LNXSYBUS? > > > Don't think anyone is going to test for the presence of that. > > > > No, I mean real devices, where the corresponding ACPI object has _STA that > > returns 0. > > > > There may be a couple of reasons for that. The device the ACPI object > > corresponds to may not be physically present (eg. it may possible to > > hot-add it) or the device may depend on something else for functionality > > and that thing hasn't been set up yet etc. > > > > The presence of an ACPI device object in the namespace means that the > > platform firmware knows about the device, but it need not mean that > > the device is really there. _STA returns that piece of information. > > Thank you for the clarification, these are very good points. > > The drivers in question use acpi_get_devices() merely to probe for > presence of a device in the namespace. They do not invoke _STA, > nor do they even hold a pointer to the acpi_device or acpi_handle > when detecting presence. Mostly this is about activating quirks > if a certain ACPI device is detected. I know, but it doesn't matter too much. I don't want people to wonder what the difference between acpi_dev_present() and acpi_device_is_present() is and when to use which of them. > Currently about 50% of the calls to acpi_get_devices() in the drivers > fit this pattern and the point of acpi_dev_present() is to give > developers a simple, lightweight tool as an alternative. Again, I know, but the name of the function should be different. > However the kernel-doc should be amended to clarify that _STA is not > invoked. The patch below is a suggestion, feel free to rephrase. That's OK, but it's not enough. I guess it won't be a big deal to change the function name and rebase the patches depending on it on top of that change, will it? Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/5] ACPI / bus: Switch to use new generic UUID API
On Wednesday, May 31, 2017 10:41:50 PM Andy Shevchenko wrote: > There are new types and helpers that are supposed to be used in new code. > > As a preparation to get rid of legacy types and API functions do > the conversion here. > > Signed-off-by: Andy Shevchenko Acked-by: Rafael J. Wysocki Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 5/5] ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()
On Wednesday, May 31, 2017 10:41:52 PM Andy Shevchenko wrote: > acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 > bytes. Instead we convert them to use guid_t type. At the same time we > convert current users. > > acpi_str_to_uuid() becomes useless after the conversion and it's safe to > get rid of it. Acked-by: Rafael J. Wysocki 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 applied. Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 *)&guid; >> >> Any idea why the pointer is defined as a u8 * in union acpi_object >> instead of a void? > > I guess this question to Rafael. That data type is defined in upstream ACPICA and the reason why it is defined the way it is has something to do with history I suppose. Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder
On Monday, June 26, 2017 04:40:08 PM 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 SMBus for things that are completely
> unrelated to the SMBus controller, such as the OpRegion used for i915.
> This is very bad and entirely evil, but with Lenovo's historically poor
> track record of fixing their firmware, it is extremely unlikely this is
> ever going to be properly fixed.
>
> So, while it would be nice if we could just cut off the SMBus controller
> and call it a day this unfortunately breaks RMI4 mode completely for
> most of the ThinkPads. Even though this behavior is extremely wrong, for
> whatever reason sharing the PCIBAR between the OpRegion and SMBus seems
> to be just fine. Regardless however, I think it's safe to assume that
> when the BIOS accesses the PCIBAR space of the SMBus controller like
> this that it's trying to get to something else that we mapped the SMBus
> controller over.
>
> On my X1 Carbon, this assumption appears to be correct. I've traced down
> the firmware accesses to being caused by the firmware mistakenly placing
> the SWSCI mailbox for i915 on top of the SMBus host controller region.
> And indeed, blacklisting i915 causes the firmware to never attempt to
> touch this region.
>
> So, in order to try to workaround this and 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
> Cc: Rafael J. Wysocki
> Cc: Benjamin Tissoires
> Cc: Mika Westerberg
> Cc: Jean Delvare
> Cc: Wolfram Sang
> Cc: intel-gfx@lists.freedesktop.org
> ---
> So: unfortunately
>
> a7ae81952cda (i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI
> BAR)
>
> Seems to prevent the ThinkPad X1 Carbon 4th gen and the T460s from actually
> using their SMBus controllers at all. As mentioned above, I've traced the
> issue
> down to the firmware responding to the SWSCI by sticking data in places it
> shouldn't, e.g. the SMBus registers.
>
> I'm entirely unsure if this patch is the correct fix for this, and wouldn't be
> at all surprised if it's just as bad of a patch as I think it is ;P. So I
> figured I'd send it to intel-gfx and the authors of the original version of
> this
> patch to get their take on it and see if there might be something less hacky
> we
> can do to fix this.
It would really help to send this to linux-a...@vger.kernel.org (as pretty much
everything ACPI-related).
Adding the CC and retaining the patch below for completeness.
>
> drivers/i2c/busses/i2c-i801.c | 41 +
> 1 file changed, 25 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index 6484fa6..bfbe0f9 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -1406,33 +1406,42 @@ i801_acpi_io_handler(u32 function,
> acpi_physical_address address, u32 bits,
> {
> struct i801_priv *priv = handler_context;
> struct pci_dev *pdev = priv->pci_dev;
> + struct device *dev = &pdev->dev;
> acpi_status status;
> + int err;
>
> - /*
> - * Once BIOS AML code touches the OpRegion we warn and inhibit any
> - * further access from the driver itself. This device is now owned
> - * by the system firmware.
> - */
> mutex_lock(&priv->acpi_lock);
>
> - if (!priv->acpi_reserved) {
> - priv->acpi_reserved = true;
> + /*
> + * BIOS AML code should never actually touch the SMBus registers,
> + * however crappy firmware (mainly Lenovo's) can make the mistake of
> + * mapping things over the SMBus region that should definitely not be
> + * there (such as the OpRegion for Intel GPUs).
> + * This is extremely bad firmware behavior, but it is unlikely this will
> + * ever get fixed by Lenovo.
> + */
> + dev_warn_once(dev,
> + FW_BUG "OpRegion overlaps with SMBus registers, working
> around\n");
>
> - dev_warn(&pdev->dev, "BIOS is accessing SMBus registers\n");
> - dev_warn(&pdev->dev, "Driver SMBus register access
> inhibited\n");
> -
> - /*
> - * BIOS is accessing the host controller so prevent it from
> - * suspending automatically from now on.
> -
Re: [Intel-gfx] [PATCH 2/3] ACPI/DRM: rework ACPI_VIDEO Kconfig dependencies
On Wednesday, July 26, 2017 03:53:11 PM Arnd Bergmann wrote: > ACPI_VIDEO keeps causing problems with circular Kconfig dependencies, > as it depends on a couple of other symbols, and it gets selected by > drivers that may end up being depending on others. > > This is an attempt to simplify this by changing all drivers that > currently 'select ACPI_VIDEO' to use 'depends on'. This by itself > simplifies the dependency lists for the other drivers. We make > ACPI_VIDEO 'default y' to avoid having it turned off for 'make > oldconfig' users. This should again be fine as x86 users will > normally want this enabled and the option is not available elsewhere. > > I'm moving the 'select BACKLIGHT_CLASS_DEVICE/BACKLIGHT_LCD_SUPPORT' > into ACPI_VIDEO as a further simplification, those were already > selected by anything that selected ACPI_VIDEO before. > > Changing the INPUT dependency in ACPI_CMPC is necessary to avoid a > circular dependency with X86_PLATFORM_DEVICES/NOUVEAU. > > Signed-off-by: Arnd Bergmann > --- > drivers/acpi/Kconfig| 5 - > drivers/gpu/drm/gma500/Kconfig | 6 +- > drivers/gpu/drm/i915/Kconfig| 7 +-- > drivers/gpu/drm/nouveau/Kconfig | 10 ++ > drivers/platform/x86/Kconfig| 6 ++ > 5 files changed, 10 insertions(+), 24 deletions(-) > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > index 1ce52f84dc23..a8f5a40e2914 100644 > --- a/drivers/acpi/Kconfig > +++ b/drivers/acpi/Kconfig > @@ -182,9 +182,12 @@ config ACPI_BUTTON > > config ACPI_VIDEO > tristate "Video" > - depends on X86 && BACKLIGHT_CLASS_DEVICE > + depends on X86 > 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 integrated graphics devices on motherboard, as specified in Acked-by: Rafael J. Wysocki for the ACPI_VIDEO changes. Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
