Re: [PATCH v3 1/5] ACPI: video: Handle fetching EDID that is longer than 256 bytes

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

Re: [PATCH v3 1/5] ACPI: video: Handle fetching EDID that is longer than 256 bytes

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

Re: [PATCH 1/2] ACPI: video: Handle fetching EDID that is longer than 256 bytes

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

Re: [V11 1/8] ACPI: Add support for AMD ACPI based Wifi band RFI mitigation feature

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

Re: [V9 2/9] drivers core: add ACPI based WBRF mechanism introduced by AMD

On Fri, Aug 18, 2023 at 5:27 AM Evan Quan wrote: > > AMD has introduced an ACPI based mechanism to support WBRF for some > platforms with AMD dGPU + WLAN. This needs support from BIOS equipped > with necessary AML implementations and dGPU firmwares. This needs a problem statement in the first

Re: [V9 1/9] drivers core: Add support for Wifi band RF mitigations

On Fri, Aug 18, 2023 at 5:27 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. > >

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

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

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

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

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

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

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

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

Re: [PATCH v3 0/3] Adjust ACPI video detection fallback path

On Thu, Dec 15, 2022 at 8:38 PM Rafael J. Wysocki wrote: > > On Thu, Dec 15, 2022 at 8:20 PM Limonciello, Mario > wrote: > > > > [Public] > > > > > -Original Message- > > > From: Limonciello, Mario > > > Sent: Thursday, Decembe

Re: [PATCH v3 0/3] Adjust ACPI video detection fallback path

On Thu, Dec 15, 2022 at 8:20 PM Limonciello, Mario wrote: > > [Public] > > > -Original Message- > > From: Limonciello, Mario > > Sent: Thursday, December 8, 2022 10:42 > > To: Rafael J . Wysocki ; Deucher, Alexander > > ; Hans de Goede > >

Re: [PATCH v2 1/3] ACPI: video: Allow GPU drivers to report no panels

On Thu, Dec 8, 2022 at 2:09 AM Mario Limonciello wrote: > > The current logic for the ACPI backlight detection will create > a backlight device if no native or vendor drivers have created > 8 seconds after the system has booted if the ACPI tables > included backlight control methods. > > If the

Re: [PATCH] ACPICA: Fix return

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

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

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

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

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

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

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

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

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

Re: [PATCH] ACPI: PM: s2idle: Add missing LPS0 functions for AMD

On Wed, May 5, 2021 at 3:21 PM Alex Deucher wrote: > > These are supposedly not required for AMD platforms, > but at least some HP laptops seem to require it to > properly turn off the keyboard backlight. > > Based on a patch from Marcin Bachry . > > Bug:

Re: [PATCH] ACPI: Test for ACPI_SUCCESS rather than !ACPI_FAILURE

On Wed, Jan 27, 2021 at 5:06 PM Bjorn Helgaas wrote: > > On Wed, Jan 27, 2021 at 04:44:02PM +0100, Rafael J. Wysocki wrote: > > On Wed, Jan 27, 2021 at 4:16 PM Bjorn Helgaas wrote: > > > > > > On Tue, Jan 26, 2021 at 02:23:17PM -0600, Bjorn Helgaas wrot

Re: [PATCH] ACPI: Test for ACPI_SUCCESS rather than !ACPI_FAILURE

On Wed, Jan 27, 2021 at 4:16 PM Bjorn Helgaas wrote: > > On Tue, Jan 26, 2021 at 02:23:17PM -0600, Bjorn Helgaas wrote: > > From: Bjorn Helgaas > > > > The double negative makes it hard to read "if (!ACPI_FAILURE(status))". > > Replace it with "if (ACPI_SUCCESS(status))". > > > > Signed-off-by:

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

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

Re: [PATCH] PCI/ACPI: Whitelist hotplug ports for D3 if power managed by ACPI

On Fri, Oct 2, 2020 at 4:20 PM Deucher, Alexander wrote: > > [AMD Public Use] > > > -Original Message- > > From: amd-gfx On Behalf Of > > Rafael J. Wysocki > > Sent: Friday, October 2, 2020 10:17 AM > > To: Lukas Wunner > > Cc: Aaron Zakhrov

Re: [PATCH] PCI/ACPI: Whitelist hotplug ports for D3 if power managed by ACPI

d-and-tested-by: matoro > Reported-by: Aaron Zakhrov > Reported-by: Michal Rostecki > Reported-by: Shai Coleman > Signed-off-by: Lukas Wunner > Cc: sta...@vger.kernel.org > Cc: Alex Deucher > Cc: Rafael J. Wysocki > Cc: Mika Westerberg > --- > drivers/pci/pci-a

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

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

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

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

Re: [PATCH] drm/amdgpu: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtime

is properly retained. Fixes: c62ec4610c40 ("PM / core: Fix direct_complete handling for devices with no callbacks") Cc: Rafael J. Wysocki Signed-off-by: Alex Deucher Acked-by: Rafael J. Wysocki --- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 1 + 1 file changed, 1 insertion(+)

Re: [PATCH] gpu: drm: radeon: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtime

On Sun, Feb 17, 2019 at 12:37 AM Alex Deucher wrote: > > On Sat, Feb 16, 2019 at 1:01 AM Lukas Wunner wrote: > > > > On Fri, Feb 15, 2019 at 11:01:04AM -0500, Alex Deucher wrote: > > > On Fri, Feb 15, 2019 at 10:39 AM Rafael J. Wysocki > > > wrote: > &

[PATCH] gpu: drm: radeon: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtime

From: Rafael J. Wysocki On HP ProBook 4540s, if PM-runtime is enabled in the radeon driver and the direct-complete optimization is used for the radeon device during system-wide suspend, the system doesn't resume. Preventing direct-complete from being used with the radeon device by setting

Re: [trivial PATCH V2] treewide: Align function definition open/close braces

drew Morton picks this up. > > V2: Remove fs/xfs/libxfs/xfs_alloc.c as it's updated and remerge the rest > > arch/x86/include/asm/atomic64_32.h | 2 +- > drivers/acpi/custom_method.c | 2 +- > drivers/acpi/fan.c |

Re: [trivial PATCH] treewide: Align function definition open/close braces

t raid6_calls raid6_sse2x2 = { > raid6_sse22_gen_syndrome, > @@ -366,9 +366,9 @@ static void raid6_sse24_gen_syndrome(int disks, size_t > bytes, void **ptrs) > kernel_fpu_end(); > } > > - static void raid6_sse24_xor_syndrome(int disks, int start, int stop, > +static void raid6_sse24_xor_syndrome(int disks, int start, int stop, >size_t bytes, void **ptrs) > - { > +{ > u8 **dptr = (u8 **)ptrs; > u8 *p, *q; > int d, z, z0; > @@ -471,7 +471,7 @@ static void raid6_sse24_gen_syndrome(int disks, size_t > bytes, void **ptrs) > } > asm volatile("sfence" : : : "memory"); > kernel_fpu_end(); > - } > +} > > > const struct raid6_calls raid6_sse2x4 = { > diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c > index 0c11f434a374..ec619f51d336 100644 > --- a/sound/soc/fsl/fsl_dma.c > +++ b/sound/soc/fsl/fsl_dma.c > @@ -879,7 +879,7 @@ static const struct snd_pcm_ops fsl_dma_ops = { > }; > > static int fsl_soc_dma_probe(struct platform_device *pdev) > - { > +{ > struct dma_object *dma; > struct device_node *np = pdev->dev.of_node; > struct device_node *ssi_np; > > -- Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> for the ACPI part. Thanks! ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote: > There are ~4300 uses of pr_warn and ~250 uses of the older > pr_warning in the kernel source tree. > > Make the use of pr_warn consistent across all kernel files. > > This excludes all files in tools/ as there is a separate >