On Wed, May 7, 2025 at 9:45 PM Mario Limonciello wrote:
>
> On 5/7/2025 2:39 PM, Rafael J. Wysocki wrote:
> > On Wed, May 7, 2025 at 9:17 PM Mario Limonciello wrote:
> >>
> >> On 5/7/2025 2:14 PM, Rafael J. Wysocki wrote:
> >>> On Thu, May 1, 2025 a
On Wed, May 7, 2025 at 9:17 PM Mario Limonciello wrote:
>
> On 5/7/2025 2:14 PM, Rafael J. Wysocki wrote:
> > On Thu, May 1, 2025 at 11:17 PM Mario Limonciello
> > wrote:
> >>
> >> From: Mario Limonciello
> >>
> >> commit 2965e6355dcd (&quo
On Thu, May 1, 2025 at 11:17 PM Mario Limonciello wrote:
>
> From: Mario Limonciello
>
> commit 2965e6355dcd ("drm/amd: Add Suspend/Hibernate notification
> callback support") introduced a VRAM eviction earlier in the PM
> sequences when swap was still available for evicting to. This helped
> to
On Wed, Apr 16, 2025 at 3:32 PM Michal Wilczynski
wrote:
>
> On 4/15/25 18:42, Rafael J. Wysocki wrote:
> > On Mon, Apr 14, 2025 at 8:53 PM Michal Wilczynski
> > wrote:
> >>
> >> Introduce a new dev_pm_info flag - platform_resources_managed, to
> >> i
On Mon, Apr 14, 2025 at 8:53 PM Michal Wilczynski
wrote:
>
> Introduce a new dev_pm_info flag - platform_resources_managed, to
> indicate whether platform PM resources such as clocks or resets are
> managed externally (e.g. by a generic power domain driver) instead of
> directly by the consumer de
From: Rafael Beims
Add the I2S audio input port for audio over HDMI support.
Signed-off-by: Rafael Beims
---
.../bindings/display/bridge/lontium,lt8912b.yaml | 8
1 file changed, 8 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/bridge/lontium
From: Rafael Beims
Add support for HDMI codec with audio coming from the I2S input.
Support 48kHz and 96kHz sample rate, with 16 bits word size.
Co-developed-by: João Paulo Gonçalves
Signed-off-by: João Paulo Gonçalves
Signed-off-by: Rafael Beims
---
drivers/gpu/drm/bridge/Kconfig
On 03/02/2025 16:23, raf...@beims.me wrote:
From: Rafael Beims
Add support for HDMI codec with audio coming from the I2S input.
Support 48kHz and 96kHz sample rate, with 16 bits word size.
Co-developed-by: João Paulo Gonçalves
Signed-off-by: João Paulo Gonçalves
Signed-off-by: Rafael Beims
From: Rafael Beims
This patch series adds HDMI audio support to the Lontium LT8912B bridge driver
using the I2S input. The audio output was tested using a Verdin iMX8MM + DSI to
HDMI adapter connected to different monitors.
Rafael Beims (2):
dt-bindings: display: bridge: lt8912b: Add I2S
On Thu, Nov 21, 2024 at 6:28 PM Antheas Kapenekakis wrote:
>
> The following series moves the _DSM 3,4,7,8 firmware notifications outside
> the suspend sequence, and makes them part of a transition function, where
> the system can transition freely between them when it is not suspended.
> This tra
On Wed, Oct 9, 2024 at 2:48 PM Richard Fitzgerald
wrote:
>
> On 08/10/2024 7:24 pm, Rafael J. Wysocki wrote:
> > On Tue, Oct 8, 2024 at 12:35 AM Ulf Hansson wrote:
> >>
> >> On Tue, 8 Oct 2024 at 00:25, Laurent Pinchart
> >> wrote:
> >>>
>
On Tue, Oct 8, 2024 at 8:24 PM Rafael J. Wysocki wrote:
>
> On Tue, Oct 8, 2024 at 12:35 AM Ulf Hansson wrote:
> >
> > On Tue, 8 Oct 2024 at 00:25, Laurent Pinchart
> > wrote:
> > >
> > > Hi Ulf,
> > >
> > > On Tue, Oct 08, 2024 at 12:
On Tue, Oct 8, 2024 at 12:35 AM Ulf Hansson wrote:
>
> On Tue, 8 Oct 2024 at 00:25, Laurent Pinchart
> wrote:
> >
> > Hi Ulf,
> >
> > On Tue, Oct 08, 2024 at 12:08:24AM +0200, Ulf Hansson wrote:
> > > On Mon, 7 Oct 2024 at 20:49, Laurent Pinchart wrote:
> > > > On Fri, Oct 04, 2024 at 04:38:36PM
On Wed, Aug 14, 2024 at 10:10 PM Andy Shevchenko wrote:
>
> On Wed, Aug 14, 2024 at 09:01:56PM +0200, Hans de Goede wrote:
> > Hi Rafael,
> >
> > 6.10 has a new backlight driver for UART attached backlight controller
> > boards found in some Dell All in One models.
:
>
> __assign_str_len()
> __assign_rel_str()
> __assign_rel_str_len()
>
> I tested this with both an allmodconfig and an allyesconfig (build only for
> both).
>
> [1]
> https://lore.kernel.org/linux-trace-kernel/2024011442.634192...@goodmis.org/
>
> Cc: Masami Hiramatsu
> Cc: Mathieu Desnoyers
> Cc: Linus Torvalds
> Cc: Julia Lawall
> Signed-off-by: Steven Rostedt (Google)
Acked-by: Rafael J. Wysocki # for thermal
CC Hans who has been doing the majority of the ACPI video work.
On Thu, May 16, 2024 at 2:43 PM Thomas Zimmermann wrote:
>
> Commit 2fd001cd3600 ("arch: Rename fbdev header and source files")
> renames the video source files under arch/ such that they does not
> refer to fbdev any longer. The new
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
> >>
device
> 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()
&g
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:
> https://uef
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 forme
+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
> link_
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.
>
> To
msm_job_run+0x78/0x150
> drm_sched_main+0x290/0x370
> kthread+0xf0/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.
>
&
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&rev=4
>
> So, this does _slightly_ change error paths, for ex
> dev_pm_qos_update_user_laten
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 lockdep
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 in
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 usua
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 var
On Fri, Jan 13, 2023 at 12:41 PM Hans de Goede wrote:
>
> The Acer Aspire 4810T predates Windows 8, so it defaults to using
> acpi_video# for backlight control, but this is non functional on
> this model.
>
> Add a DMI quirk to use the native backlight interface which does
> work properly.
>
> Sig
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 th
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 w
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:
> >>
; > Changelog:
> >
> > v2: - Added explanatory comment to the code and added check for the
> > native backlight presence, like was requested by Hans de Goede.
>
> Thanks this version looks good to me:
>
> Reviewed-by: Hans de Goede
>
> Rafael, can you pick this u
nt issue
reported by coccinelle in 'display_rq_dlg_calc_314.c':
static bool CalculateBytePerPixelAnd256BBlockSizes(...) {
...
} else if (SourcePixelFormat == dm_444_16 || SourcePixelFormat ==
dm_444_16) {
...
}
Signed-off-by: Rafael Mendonca
---
.../dc/dml/dcn314/dis
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
Fixes: 264fb4d332f5 ("drm/amdgpu: Add multi-GPU DMA mapping helpers")
Signed-off-by: Rafael Mendonca
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/driv
ng.
Fixes: 902bc65de0b3 ("drm/amdgpu/powerplay/psm: return an error in power state
init")
Signed-off-by: Rafael Mendonca
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/pp_psm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pp_psm.c
b/drivers/gpu/
On Tue, Sep 27, 2022 at 9:47 AM Liu Ying wrote:
>
> On Mon, 2022-09-26 at 11:47 +0200, Ulf Hansson wrote:
> > On Fri, 23 Sept 2022 at 17:23, Liu Ying wrote:
> > > On Fri, 2022-09-23 at 15:48 +0200, Ulf Hansson wrote:
> > > > On Fri, 23 Sept 2022 at 14:47, Liu Ying wrote:
> > > > > After a device
If the copy of the description string from userspace fails, then the page
for the instance descriptor doesn't get freed before returning -EFAULT,
which leads to a memleak.
Fixes: 7a7a933edd6c ("drm/vmwgfx: Introduce VMware mks-guest-stats")
Signed-off-by: Rafael Mendonca
---
x_irq")
Signed-off-by: Rafael Mendonca
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 51
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
he "Other issues" section of
> the refactor RFC (resulting in patches 15-29 which are new in v2).
>
> Please review and test! I hope to be able to make an immutable branch
> based on 5.20-rc1 + this series available for merging into the various
> touched subsystems once 5.20-
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
acpi,
> and at a first glance about half of those are missing an acpi_disabled
> check. IMHO it would be better to simply add an acpi_disabled check to
> acpi_get_devices() itself.
>
> Rafael, do you agree ?
Yes, I do.
> Note the just added chrome privacy-screen check uses
> acpi_
CC Daniel, Thomas and dri-devel.
On Mon, Dec 27, 2021 at 5:32 PM wrote:
>
> Hello
>
> I've noticed my laptop totally freeze when going to hibernation.
> The git bisect log is appended below.
> Please note however that even the previous good commit was "good" (ie :
> laptop managed to suspend and
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_runti
On Fri, Oct 29, 2021 at 5:20 PM Dmitry Osipenko wrote:
>
> 26.10.2021 01:40, Dmitry Osipenko пишет:
> > + ret = devm_pm_runtime_enable(&pdev->dev);
> > + if (ret)
> > + return ret;
> > +
> > + ret = devm_tegra_core_dev_init_opp_table_common(&pdev->dev);
> > + if (ret)
>
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
> > > m
On Sat, May 8, 2021 at 9:41 AM Stephen Boyd wrote:
>
> The device lists are poorly ordered when the component device code is
> used. This is because component_master_add_with_match() returns 0
> regardless of component devices calling component_add() first. It can
> really only fail if an allocati
On Tue, May 4, 2021 at 10:08 AM Chris Chiu wrote:
>
> Hi,
> We have some Intel laptops (11th generation CPU) with NVIDIA GPU
> suffering the same GPU falling off the bus problem while exiting
> s2idle with external display connected. These laptops connect the
> external display via the HDMI/Di
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
> 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 introduced
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 +++
>
t 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.
>
> Tha
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 +
>
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 ne
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
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
> > > >
> > > > Th
On Mon, Dec 9, 2019 at 12:17 PM Karol Herbst wrote:
>
> anybody any other ideas?
Not yet, but I'm trying to collect some more information.
> It seems that both patches don't really fix
> the issue and I have no idea left on my side to try out. The only
> thing left I could do to further investig
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
er depending on the VBT bit, instead of the i915 driver
> relying on a "pwm_backlight" lookup getting registered which magically
> points to the right controller.
>
> Signed-off-by: Hans de Goede
Acked-by: Rafael J. Wysocki
Or please let me know if you want me to take the who
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
> r
On Fri, Nov 22, 2019 at 12:52 PM Mika Westerberg
wrote:
>
[cut]
[I'm really running out of time for today, unfortunately.]
> > > > The current design is mostly based on the PCI PM Spec 1.2, so it would
> > > > be consequent to follow system-wide suspend in PM-runtime and avoid
> > > > putting P
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
1 - 100 of 644 matches
Mail list logo
