On Fri, Feb 2, 2024 at 5:09 PM Mario Limonciello
wrote:
>
> On 2/2/2024 10:07, Rafael J. Wysocki wrote:
> > On Thu, Feb 1, 2024 at 11:11 PM Mario Limonciello
> > wrote:
> >>
> >> The ACPI specification allows for an EDID to be up to 512 bytes but
> >>
e
> Signed-off-by: Mario Limonciello
Acked-by: Rafael J. Wysocki
or I can apply it if that's preferred.
Thanks!
> ---
> v1->v2:
> * Use for loop for acpi_video_get_edid()
> * Use one of Rafael's suggestions for acpi_video_device_EDID()
> * Decrease
On Fri, Jan 26, 2024 at 7:55 PM Mario Limonciello
wrote:
>
> The ACPI specification allows for an EDID to be up to 512 bytes but
> the _DDC EDID fetching code will only try up to 256 bytes.
>
> Modify the code to instead start at 512 bytes and work it's way
> down instead.
>
> Link:
>
On Mon, Jan 22, 2024 at 7:12 PM Bjorn Helgaas wrote:
>
> On Mon, Jan 22, 2024 at 01:41:21PM +0200, Sakari Ailus wrote:
> > There are two ways to opportunistically increment a device's runtime PM
> > usage count, calling either pm_runtime_get_if_active() or
> > pm_runtime_get_if_in_use(). The
+Saravana
On Thu, Dec 7, 2023 at 10:51 AM richard clark
wrote:
>
> Hi,
>
> I have to comment out below code to make the mmc driver be probed
> before the kernel try to run the init mounting the rootfs in the dev
> node generate by the driver:
>
> really_probe(...)
> {
>...
> #if 0
>
ng idea.
>
> Cc: "Rafael J. Wysocki"
> Cc: Saravana Kannan
> Signed-off-by: Greg Kroah-Hartman
Acked-by: "Rafael J. Wysocki"
> ---
> drivers/base/core.c| 2 +-
> include/linux/device.h | 1 -
> 2 files changed, 1 insertion(+), 2 deletions(-)
On Thu, Aug 31, 2023 at 8:21 AM Evan Quan wrote:
>
> Due to electrical and mechanical constraints in certain platform designs
> there may be likely interference of relatively high-powered harmonics of
> the (G-)DDR memory clocks with local radio module frequency bands used
> by Wifi 6/6e/7.
>
>
f0/0x100
> ret_from_fork+0x10/0x20
>
> The issue is that dev_pm_qos_mtx is held in the runpm suspend/resume (or
> freq change) path, but it is also held across allocations that could
> recurse into shrinker.
>
> Solve this by changing dev_pm_qos_constraints_allocate() into a fu
ndant
> allocation.
>
> Suggested-by: Rafael J. Wysocki
> Signed-off-by: Rob Clark
> ---
> This is an alternative to
> https://patchwork.freedesktop.org/patch/551417/?series=115028=4
>
> So, this does _slightly_ change error paths, for ex
> dev_pm_qos_update_user_latency_tolera
On Fri, Aug 4, 2023 at 10:38 PM Rob Clark wrote:
>
> On Fri, Aug 4, 2023 at 12:11 PM Rafael J. Wysocki wrote:
> >
> > On Fri, Aug 4, 2023 at 8:38 PM Rob Clark wrote:
> > >
> > > On Fri, Aug 4, 2023 at 10:07 AM Rafael J. Wysocki
> > > wrote:
> &
On Fri, Aug 4, 2023 at 8:38 PM Rob Clark wrote:
>
> On Fri, Aug 4, 2023 at 10:07 AM Rafael J. Wysocki wrote:
> >
> > On Fri, Aug 4, 2023 at 12:02 AM Rob Clark wrote:
> > >
> > > From: Rob Clark
> > >
> > > In the process of adding lo
On Fri, Aug 4, 2023 at 12:02 AM Rob Clark wrote:
>
> From: Rob Clark
>
> In the process of adding lockdep annotation for drm GPU scheduler's
> job_run() to detect potential deadlock against shrinker/reclaim, I hit
> this lockdep splat:
>
>
On Fri, Jun 23, 2023 at 6:48 PM Limonciello, Mario
wrote:
>
>
> On 6/23/2023 11:28 AM, Rafael J. Wysocki wrote:
> > On Fri, Jun 23, 2023 at 5:57 PM Limonciello, Mario
> > wrote:
> >>
> >> On 6/23/2023 9:52 AM, Rafael J. Wysocki wrote:
> >>&g
On Wed, Jun 21, 2023 at 7:47 AM Evan Quan wrote:
>
> From: Mario Limonciello
>
> Due to electrical and mechanical constraints in certain platform designs
> there may be likely interference of relatively high-powered harmonics of
> the (G-)DDR memory clocks with local radio module frequency bands
On Fri, Jun 23, 2023 at 5:57 PM Limonciello, Mario
wrote:
>
>
> On 6/23/2023 9:52 AM, Rafael J. Wysocki wrote:
> > On Wed, Jun 21, 2023 at 7:47 AM Evan Quan wrote:
> >> From: Mario Limonciello
> >>
> >> Due to electrical and mechanical constraints
On Wed, Jun 21, 2023 at 7:47 AM Evan Quan wrote:
>
> From: Mario Limonciello
>
> Due to electrical and mechanical constraints in certain platform designs
> there may be likely interference of relatively high-powered harmonics of
> the (G-)DDR memory clocks with local radio module frequency bands
On Mon, Mar 20, 2023 at 3:45 PM Rob Clark wrote:
>
> From: Rob Clark
>
> In the process of adding lockdep annotation for drm GPU scheduler's
> job_run() to detect potential deadlock against shrinker/reclaim, I hit
> this lockdep splat:
>
>
On Sun, Mar 12, 2023 at 9:42 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Annotate dev_pm_qos_mtx to teach lockdep to scream about allocations
> that could trigger reclaim under dev_pm_qos_mtx.
So why is this needed?
> Signed-off-by: Rob Clark
> ---
> drivers/base/power/qos.c | 11 +++
On Sun, Mar 12, 2023 at 9:42 PM Rob Clark wrote:
>
> From: Rob Clark
>
> In the process of adding lockdep annotation for drm GPU scheduler's
> job_run() to detect potential deadlock against shrinker/reclaim, I hit
> this lockdep splat:
>
>
On Thu, Jan 19, 2023 at 6:24 PM Hans de Goede wrote:
>
> The Asus U46E backlight tables have a set of interesting problems:
>
> 1. Its ACPI tables do make _OSI ("Windows 2012") checks, so
>acpi_osi_is_win8() should return true.
>
>But the tables have 2 sets of _OSI calls, one from the
On Thu, Jan 19, 2023 at 5:38 PM Hans de Goede wrote:
>
> Hi Rafael,
>
> With the backlight changes landing in 6.1.y now showing up in
> distribution repositories I have been receiving a steady stream of
> backlight bug reports by email.
>
> These bug-reports fall into various categories and most
On Fri, Jan 13, 2023 at 12:41 PM Hans de Goede wrote:
>
> The Acer Aspire 4810T predates Windows 8, so it defaults to using
> acpi_video# for backlight control, but this is non functional on
> this model.
>
> Add a DMI quirk to use the native backlight interface which does
> work properly.
>
>
On Wed, Jan 11, 2023 at 9:23 PM Hans de Goede wrote:
>
> Hi,
>
> On 1/11/23 21:16, Rafael J. Wysocki wrote:
> > On Tue, Jan 10, 2023 at 4:30 PM Hans de Goede wrote:
> >>
> >> The Dell Latitude E6430 both with and without the optional NVidia dGPU
> >>
wrong acpi_device because of the wrong
> acpi_find_child_device() return. This breaks the ACPI video code,
> leading to non working backlight control in some cases.
>
> Add a type.backlight flag, mark ACPI video bus devices with this and make
> find_child_checks() return a higher
On Monday, January 9, 2023 9:57:21 PM CET Hans de Goede wrote:
> The Dell Latitude E6430 both with and without the optional NVidia dGPU
> has a bug in its ACPI tables which is causing Linux to assign the wrong
> ACPI fwnode / companion to the pci_device for the i915 iGPU.
>
> Specifically under
ave the correct signature to preserve the build.
>
> Cc: "Rafael J. Wysocki"
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Greg Kroah-Ha
On Tue, Nov 8, 2022 at 12:48 PM wrote:
>
> return is not a function, parentheses are not required
>
> Signed-off-by: KaiLong Wang
ACPICA material is to be submitted to the upstream project at GitHub
(please see MAINTAINERS for the link).
You may notice, however, that your changes do not align
On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede wrote:
>
> Hi,
>
> On 10/27/22 14:09, Rafael J. Wysocki wrote:
> > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 10/27/22 11:52, Matthew Garrett wrote:
> &g
On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote:
>
> Hi,
>
> On 10/27/22 11:52, Matthew Garrett wrote:
> > On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote:
> >
> >> The *only* behavior which actually is new in 6.1 is the native GPU
> >> drivers now doing the equivalent of:
> >>
send it in a fixes pull-req
> for 6.1 to Linus? Or shall I pick this one up and include it
> in my next pull-req?
It would be better if you could pick this up IMV, so please free to add
Acled-by: Rafael J. Wysocki
to it.
Thanks!
> >
> > drivers/acpi/video_detect.c |
On Wed, Oct 19, 2022 at 2:22 PM Ville Syrjälä
wrote:
>
> On Wed, Oct 19, 2022 at 01:35:26PM +0200, Rafael J. Wysocki wrote:
> > On Wed, Oct 19, 2022 at 11:02 AM Ville Syrjälä
> > wrote:
> > >
> > > On Tue, Oct 18, 2022 at 07:34:03PM +0200, Rafael J. Wysocki wr
On Tue, Sep 27, 2022 at 9:47 AM Liu Ying wrote:
>
> On Mon, 2022-09-26 at 11:47 +0200, Ulf Hansson wrote:
> > On Fri, 23 Sept 2022 at 17:23, Liu Ying wrote:
> > > On Fri, 2022-09-23 at 15:48 +0200, Ulf Hansson wrote:
> > > > On Fri, 23 Sept 2022 at 14:47, Liu Ying wrote:
> > > > > After a
From: Rafael J. Wysocki
According to the ACPI specification [1], the ACPI_FADT_LOW_POWER_S0
flag merely means that it is better to use low-power S0 idle on the
given platform than S3 (provided that the latter is supported) and it
doesn't preclude using either of them (which of them will be used
m the "Other issues" section of
> the refactor RFC (resulting in patches 15-29 which are new in v2).
>
> Please review and test! I hope to be able to make an immutable branch
> based on 5.20-rc1 + this series available for merging into the various
> touched subsystems once 5.20-
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
On Thu, Jan 27, 2022 at 2:05 PM Hans de Goede wrote:
>
> Hi,
>
> On 1/26/22 18:11, Rafael J. Wysocki wrote:
> > On Wed, Jan 26, 2022 at 5:41 PM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 1/26/22 16:54, Rafael J. Wysocki wrote:
>
On Wed, Jan 26, 2022 at 5:41 PM Hans de Goede wrote:
>
> Hi,
>
> On 1/26/22 16:54, Rafael J. Wysocki wrote:
> > On Wed, Jan 26, 2022 at 2:47 PM Hans de Goede wrote:
> >>
> >> Hi All,
> >>
> >> On 1/23/22 10:10, Tong Zhang wrote:
&g
On Wed, Jan 26, 2022 at 2:47 PM Hans de Goede wrote:
>
> Hi All,
>
> On 1/23/22 10:10, Tong Zhang wrote:
> > when acpi=off is provided in bootarg, kernel crash with
> >
> > [1.252739] BUG: kernel NULL pointer dereference, address:
> > 0018
> > [1.258308] Call Trace:
> > [
CC Daniel, Thomas and dri-devel.
On Mon, Dec 27, 2021 at 5:32 PM wrote:
>
> Hello
>
> I've noticed my laptop totally freeze when going to hibernation.
> The git bisect log is appended below.
> Please note however that even the previous good commit was "good" (ie :
> laptop managed to suspend
On Wed, Nov 24, 2021 at 12:53 AM Srinivas Pandruvada
wrote:
>
> On Tue, 2021-11-23 at 14:19 +0100, Rafael J. Wysocki wrote:
> > On Wed, Aug 18, 2021 at 8:08 AM Kees Cook
> > wrote:
> > >
> > > In preparation for FORTIFY_SOURCE performing compile-time an
On Wed, Aug 18, 2021 at 8:08 AM Kees Cook wrote:
>
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memcpy(), avoid intentionally writing across
> neighboring fields.
>
> Use struct_group() in struct art around members weight, and ac[0-9]_max,
>
On Fri, Oct 29, 2021 at 6:29 PM Dmitry Osipenko wrote:
>
> 29.10.2021 18:56, Rafael J. Wysocki пишет:
> > On Fri, Oct 29, 2021 at 5:20 PM Dmitry Osipenko wrote:
> >>
> >> 26.10.2021 01:40, Dmitry Osipenko пишет:
> >>> + ret = devm_pm
On Fri, Oct 29, 2021 at 5:20 PM Dmitry Osipenko wrote:
>
> 26.10.2021 01:40, Dmitry Osipenko пишет:
> > + ret = devm_pm_runtime_enable(>dev);
> > + if (ret)
> > + return ret;
> > +
> > + ret = devm_tegra_core_dev_init_opp_table_common(>dev);
> > + if (ret)
> > +
From: Rafael J. Wysocki
The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle
From: Rafael J. Wysocki
The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle
On Tue, May 11, 2021 at 7:00 PM Stephen Boyd wrote:
>
> Quoting Rafael J. Wysocki (2021-05-11 03:52:06)
> > On Mon, May 10, 2021 at 9:08 PM Stephen Boyd wrote:
> >
> > [cut]
> >
> > >
> > > >
> > > > > I will try it, but then I
On Mon, May 10, 2021 at 9:08 PM Stephen Boyd wrote:
[cut]
>
> >
> > > I will try it, but then I wonder about things like system wide
> > > suspend/resume too. The drm encoder chain would need to reimplement the
> > > logic for system wide suspend/resume so that any PM ops attached to the
> > >
On Sat, May 8, 2021 at 9:41 AM Stephen Boyd wrote:
>
> The device lists are poorly ordered when the component device code is
> used. This is because component_master_add_with_match() returns 0
> regardless of component devices calling component_add() first. It can
> really only fail if an
On Tue, May 4, 2021 at 10:08 AM Chris Chiu wrote:
>
> Hi,
> We have some Intel laptops (11th generation CPU) with NVIDIA GPU
> suffering the same GPU falling off the bus problem while exiting
> s2idle with external display connected. These laptops connect the
> external display via the
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.
>
>
On 11/16/2020 10:05 PM, Steven Rostedt wrote:
On Mon, 16 Nov 2020 12:55:29 -0800
Peiyong Lin wrote:
Hi there,
May I ask whether the merge window has passed? If so is it possible to
ask for a review?
This is up to the maintainers of power management to accept this.
Rafael?
I'd say up to
> Reviewed-by: Javier Martinez Canillas
> Reviewed-by: Andy Shevchenko
Reviewed-by: Rafael J. Wysocki
> ---
> drivers/base/base.h | 3 +++
> drivers/base/core.c | 8 ++--
> drivers/base/dd.c | 23 ++-
> 3 files changed, 31 insertions(+), 3 dele
> return probe_err(dev, err, ...);
>
> Signed-off-by: Andrzej Hajda
Reviewed-by: Rafael J. Wysocki
> ---
> drivers/base/core.c| 42 ++
> include/linux/device.h | 3 +++
> 2 files changed, 45 insertions(+)
>
> diff --git a
On Wed, Jun 10, 2020 at 12:12 PM Lukasz Luba wrote:
>
> Add support for other devices than CPUs. The registration function
> does not require a valid cpumask pointer and is ready to handle new
> devices. Some of the internal structures has been reorganized in order to
> keep consistent view (like
On Wed, Jun 24, 2020 at 4:44 PM Andrzej Hajda wrote:
>
>
> On 24.06.2020 14:14, Rafael J. Wysocki wrote:
> > On Wed, Jun 24, 2020 at 1:41 PM Andrzej Hajda wrote:
> >> Many resource acquisition functions return error value encapsulated in
> >> pointer instead of
On Wed, Jun 24, 2020 at 1:41 PM Andrzej Hajda wrote:
>
> Many resource acquisition functions return error value encapsulated in
> pointer instead of integer value. To simplify coding we can use macro
> which will accept both types of error.
> With this patch user can use:
> probe_err(dev,
On Wed, Jun 24, 2020 at 1:41 PM Andrzej Hajda wrote:
>
> /sys/kernel/debug/devices_deferred property contains list of deferred devices.
> This list does not contain reason why the driver deferred probe, the patch
> improves it.
> The natural place to set the reason is probe_err function
return probe_err(dev, err, ...);
>
> Signed-off-by: Andrzej Hajda
> Reviewed-by: Javier Martinez Canillas
> Reviewed-by: Mark Brown
> Reviewed-by: Andy Shevchenko
Reviewed-by Rafael J. Wysocki
> ---
> drivers/base/core.c| 39 +++
>
le of test and those do
> show that restoring the LPSS-context indeed does not seem to be necessary
> on devices using s2idle suspend (and successfully reaching S0i3). But I
> have no hardware to test deep / S3 suspend. So I'm not sure that not
> restoring the context is safe.
>
> That lea
device-link added by the pwm-get this
> ensures that the PWM controller will be on when the troublesome PS0
> method runs, which stops it from poking the PWM controller.
>
> Signed-off-by: Hans de Goede
Acked-by: Rafael J. Wysocki
> ---
> drivers/acpi/acpi_lpss.c | 1 +
> 1 fi
On Wed, Jun 3, 2020 at 6:12 PM Lukasz Luba wrote:
>
>
>
> On 6/3/20 4:40 PM, Rafael J. Wysocki wrote:
> > On Wed, Jun 3, 2020 at 5:26 PM Lukasz Luba wrote:
> >>
> >>
> >>
> >> On 6/3/20 4:13 PM, Rafael J. Wysocki wrote:
> >>> O
On Wed, Jun 3, 2020 at 5:26 PM Lukasz Luba wrote:
>
>
>
> On 6/3/20 4:13 PM, Rafael J. Wysocki wrote:
> > On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote:
> >>
> >> Hi Daniel,
> >>
> >> On 6/1/20 10:44 PM, Daniel Lezcano wrote:
> >&
On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote:
>
> Hi Daniel,
>
> On 6/1/20 10:44 PM, Daniel Lezcano wrote:
> > On 27/05/2020 11:58, Lukasz Luba wrote:
> >> Add support for other devices than CPUs. The registration function
> >> does not require a valid cpumask pointer and is ready to handle
On Fri, May 29, 2020 at 5:01 PM Lukasz Luba wrote:
>
> Hi Rafael,
>
>
> On 5/27/20 10:58 AM, Lukasz Luba wrote:
> > Hi all,
> >
> > Background of this version:
> > This is the v8 of the patch set and is has smaller scope. I had to split
> > the series into two: EM changes and thermal changes due
On Wed, May 13, 2020 at 11:46 PM Emil Velikov wrote:
>
> With earlier commits, the API no longer discards the const-ness of the
> sysrq_key_op. As such we can add the notation.
>
> Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
> Cc: linux-ker...@vger.kernel.org
> Cc: "
On Friday, May 8, 2020 6:34:57 AM CEST Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the amdgpu tree got a conflict in:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>
> between commit:
>
> e07515563d01 ("PM: sleep: core: Rename DPM_FLAG_NEVER_SKIP")
>
> from the pm tree
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.
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
On Thu, Dec 12, 2019 at 2:32 PM Ulf Hansson wrote:
>
> On Thu, 12 Dec 2019 at 13:33, Thierry Reding wrote:
> >
> > On Thu, Dec 12, 2019 at 09:52:22AM +0100, Ulf Hansson wrote:
> > > On Mon, 9 Dec 2019 at 14:03, Thierry Reding
> > > wrote:
> > > >
> > > > From: Thierry Reding
> > > >
> > > >
On Mon, Dec 9, 2019 at 12:17 PM Karol Herbst wrote:
>
> anybody any other ideas?
Not yet, but I'm trying to collect some more information.
> It seems that both patches don't really fix
> the issue and I have no idea left on my side to try out. The only
> thing left I could do to further
On Fri, Nov 29, 2019 at 1:07 PM Thierry Reding wrote:
>
> On Fri, Nov 29, 2019 at 11:22:08AM +0100, Rafael J. Wysocki wrote:
> >
[cut]
Sorry for the delay.
First off, let me note that I have seen your most recent patches and
thanks for taking the feedback into account, much
ng on the VBT bit, instead of the i915 driver
> relying on a "pwm_backlight" lookup getting registered which magically
> points to the right controller.
>
> Signed-off-by: Hans de Goede
Acked-by: Rafael J. Wysocki
Or please let me know if you want me to take the whole serie
On Fri, Nov 29, 2019 at 11:08 AM Thierry Reding
wrote:
>
> On Thu, Nov 28, 2019 at 11:20:01PM +0100, Rafael J. Wysocki wrote:
> > On Thursday, November 28, 2019 11:03:57 PM CET Rafael J. Wysocki wrote:
> > > On Thursday, November 28, 2019 5:50:26 PM CET
On Fri, Nov 29, 2019 at 10:34 AM Thierry Reding
wrote:
>
> On Thu, Nov 28, 2019 at 11:03:57PM +0100, Rafael J. Wysocki wrote:
> > On Thursday, November 28, 2019 5:50:26 PM CET Thierry Reding wrote:
> > >
> > > --0F1p//8PRICkK4MW
> > > Content-Type: tex
On Thursday, November 28, 2019 11:03:57 PM CET Rafael J. Wysocki wrote:
> On Thursday, November 28, 2019 5:50:26 PM CET Thierry Reding wrote:
> >
> > --0F1p//8PRICkK4MW
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Tr
On Thursday, November 28, 2019 5:50:26 PM CET Thierry Reding wrote:
>
> --0F1p//8PRICkK4MW
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Thu, Nov 28, 2019 at 05:14:51PM +0100, Rafael J. Wyso
On Thu, Nov 28, 2019 at 5:03 PM Thierry Reding wrote:
>
> From: Thierry Reding
>
> Currently the driver PM core will automatically acquire a runtime PM
> reference for devices before system sleep is entered. This is needed
> to avoid potential issues related to devices' parents getting put to
>
On Fri, Nov 22, 2019 at 12:52 PM Mika Westerberg
wrote:
>
[cut]
[I'm really running out of time for today, unfortunately.]
> > > > The current design is mostly based on the PCI PM Spec 1.2, so it would
> > > > be consequent to follow system-wide suspend in PM-runtime and avoid
> > > > putting
On Fri, Nov 22, 2019 at 12:34 PM Karol Herbst wrote:
>
> On Fri, Nov 22, 2019 at 12:30 PM Rafael J. Wysocki wrote:
> >
[cut]
> >
>
> the issue is not AML related at all as I am able to reproduce this
> issue without having to invoke any of that at all, I just
On Fri, Nov 22, 2019 at 11:36 AM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg
> > wrote:
> > >
> > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. W
-off-by: Karol Herbst
> Cc: Bjorn Helgaas
> Cc: Lyude Paul
> Cc: Rafael J. Wysocki
> Cc: Mika Westerberg
> Cc: linux-...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Bugzilla: https://
On Fri, Nov 22, 2019 at 1:13 AM Karol Herbst wrote:
>
> so while trying to test with d3cold disabled, I noticed that I run
> into the exact same error.
Does this mean that you disabled d3cold on the GPU via sysfs (the
"d3cold_allowed" attribute was 0) and the original problem still
occurred in
On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
> > wrote:
> > >
> > > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg
On Thu, Nov 21, 2019 at 5:06 PM Karol Herbst wrote:
>
> On Thu, Nov 21, 2019 at 4:47 PM Rafael J. Wysocki wrote:
> >
> > On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote:
> > >
> > > On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg
> > > wrote:
On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote:
>
> On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > > wrot
On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > > wrote:
On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > > last week or so I found systems where the GPU was under the "PCI
> > > Express Root Port" (name from lspci) and on those systems a
On Thu, Nov 21, 2019 at 12:17 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 12:03:52PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol H
On Thu, Nov 21, 2019 at 12:08 PM Rafael J. Wysocki wrote:
>
> On Thu, Nov 21, 2019 at 12:03 PM Rafael J. Wysocki wrote:
> >
> > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbs
On Thu, Nov 21, 2019 at 12:03 PM Rafael J. Wysocki wrote:
>
> On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> wrote:
> >
> > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > > with the branch and patch applied:
> > > https:/
On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > with the branch and patch applied:
> >
On Wed, Nov 20, 2019 at 10:40 PM Karol Herbst wrote:
>
> On Wed, Nov 20, 2019 at 10:37 PM Rafael J. Wysocki wrote:
> >
> > On Wed, Nov 20, 2019 at 4:53 PM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrot
On Wed, Nov 20, 2019 at 4:53 PM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrote:
> > On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote:
> > > > On Wed, Nov 20, 2019 at 1:09
On Wed, Nov 20, 2019 at 1:10 PM Karol Herbst wrote:
>
> On Wed, Nov 20, 2019 at 1:06 PM Rafael J. Wysocki wrote:
> >
> > On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst wrote:
> > >
> > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki
> > > wrot
On Wed, Nov 20, 2019 at 1:06 PM Rafael J. Wysocki wrote:
>
> On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst wrote:
> >
> > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg
&g
On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst wrote:
>
> On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki wrote:
> >
> > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. W
On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. Wysocki wrote:
> > On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg
> > wrote:
> > >
> > > Hi Karol,
> > >
> > > On Tue
On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg
wrote:
>
> Hi Karol,
>
> On Tue, Nov 19, 2019 at 11:26:45PM +0100, Karol Herbst wrote:
> > On Tue, Nov 19, 2019 at 10:50 PM Bjorn Helgaas wrote:
> > >
> > > [+cc Dave]
> > >
> > > On Thu, Oct 17, 2019 at 02:19:01PM +0200, Karol Herbst wrote:
> > >
On Monday, October 21, 2019 4:51:48 PM CET Geert Uytterhoeven wrote:
> There is no need to cast a typed pointer to a void pointer when calling
> a function that accepts the latter. Remove it, as the cast prevents
> further compiler checks.
>
> Signed-off-by: Geert Uytterhoeven
> ---
>
On Monday, October 21, 2019 4:51:48 PM CET Geert Uytterhoeven wrote:
> There is no need to cast a typed pointer to a void pointer when calling
> a function that accepts the latter. Remove it, as the cast prevents
> further compiler checks.
>
> Signed-off-by: Geert Uytterhoeven
Greg, have you
1 - 100 of 526 matches
Mail list logo
