Fixes the following category of checkpatch complaints:
WARNING: unnecessary cast may hide bugs, see
http://c-faq.com/malloc/mallocnocast.html
+ char *buf = (char *)kvcalloc(total, sizeof(char), GFP_KERNEL);
Cc: Rodrigo Siqueira
Cc: Aurabindo Pillai
Signed-off-by: Srinivasan
Fixes the following category of checkpatch warning:
WARNING: Block comments use a trailing */ on a separate line
+* non-boosted one. */
WARNING: suspect code indent for conditional statements (8, 24)
+ if ((adev->asic_type >= CHIP_POLARIS10) &&
[...]
+
Fixes the following category of checkpatch warning:
WARNING: msleep < 20ms can sleep for up to 20ms; see
Documentation/timers/timers-howto.rst
+ msleep(10);
Cc: Rodrigo Siqueira
Cc: Aurabindo Pillai
Signed-off-by: Srinivasan Shanmugam
---
Fixes the following category of checkpatch complaints:
WARNING: unnecessary cast may hide bugs, see
http://c-faq.com/malloc/mallocnocast.html
Cc: Rodrigo Siqueira
Cc: Aurabindo Pillai
Signed-off-by: Srinivasan Shanmugam
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
1
Fix the following warnings reported by checkpatch:
WARNING: Block comments use a trailing */ on a separate line
WARNING: Prefer using '"%s...", __func__' to using
'execute_synaptics_rc_command', this function's name, in a string
WARNING: Prefer using '"%s...", __func__' to using
Fix the following warnings reported by checkpatch:
WARNING: Missing a blank line after declarations
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
Cc: Rodrigo Siqueira
Cc: Aurabindo Pillai
Signed-off-by: Srinivasan Shanmugam
---
Conform to Linux kernel coding style.
Reported by checkpatch:
WARNING: please, no space before tabs
And promote sysfs entry for set/get srm to kdoc
Suggested-by: Rodrigo Siqueira
Cc: Rodrigo Siqueira
Cc: Aurabindo Pillai
Signed-off-by: Srinivasan Shanmugam
---
v2:
- Promote sysfs entry
Hi Linus,
Can you please pull this directly,
Thanks,
Dave.
On Sat, 24 Jun 2023 at 07:18, Alex Deucher wrote:
>
> Hi Dave, Daniel, Linus,
>
> Last few fixes for 6.4. Dave already sent out the drm-fixes PR this week.
> I was out of the office earlier in the week and just got this out now.
>
>
Hi Dave, Daniel, Linus,
Last few fixes for 6.4. Dave already sent out the drm-fixes PR this week.
I was out of the office earlier in the week and just got this out now.
The following changes since commit 9bd9be5cbaf8a8faa175ef4fba04a5623281debe:
Merge tag 'drm-misc-fixes-2023-06-21' of
[Public]
Hi all,
This week this patchset was tested on the following systems:
* Lenovo ThinkBook T13s Gen4 with AMD Ryzen 5 6600U
* MSI Gaming X Trio RX 6800
* Gigabyte Gaming OC RX 7900 XTX
These systems were tested on the following display/connection types:
*
This reverts commit 33eec907ce0eb50a56dca621aa7310f7fa904b93.
This is no longer necessary when using newer DMUB F/W.
Cc: Sean Wang
Cc: Marc Rossi
Cc: Hamza Mahfooz
Cc: Tsung-hua (Ryan) Lin
Reviewed-by: Leo Li
Signed-off-by: Mario Limonciello
---
The `DMUB_FW_VERSION` macro has a mistake in that the revision field
is off by one byte. The last byte is typically used for other purposes
and not a revision.
Cc: Sean Wang
Cc: Marc Rossi
Cc: Hamza Mahfooz
Cc: Tsung-hua (Ryan) Lin
Reviewed-by: Leo Li
Signed-off-by: Mario Limonciello
---
A number of parade TCONs are causing system hangs when utilized with
older DMUB firmware and PSR-SU. Some changes have been introduced into
DMUB firmware to add resilience against these failures.
Don't allow running PSR-SU unless on the newer firmware.
Cc: Sean Wang
Cc: Marc Rossi
Cc: Hamza
The same parade TCON issue can potentially happen on Phoenix, and the same
PSR resilience changes have been ported into the DMUB firmware.
Don't allow running PSR-SU unless on the newer firmware.
Cc: Sean Wang
Cc: Marc Rossi
Cc: Hamza Mahfooz
Cc: Tsung-hua (Ryan) Lin
Signed-off-by: Mario
There have been a number of field reports of hangs tied to PSR-SU
specifically to Parade TCONs. These hangs are fixed by changes
in DMCUB firmware for both Rembrandt and Phoenix. Add checks to ensure
that PSR-SU is only enabled when the newer DMCUB firmware is present.
Cc: Sean Wang
Cc: Marc
[AMD Official Use Only - General]
> -Original Message-
> From: Li, Sun peng (Leo)
> Sent: Friday, June 23, 2023 2:27 PM
> To: Limonciello, Mario ; amd-
> g...@lists.freedesktop.org
> Cc: Lin, Tsung-hua (Ryan) ; Rossi, Marc
> ; Wang, Sean ; Mahfooz,
> Hamza
> Subject: Re: [PATCH 2/4]
On 6/22/23 14:25, Mario Limonciello wrote:
This reverts commit 33eec907ce0eb50a56dca621aa7310f7fa904b93.
This is no longer necessary when using newer DMUB F/W.
Cc: Sean Wang
Cc: Marc Rossi
Cc: Hamza Mahfooz
Cc: Tsung-hua (Ryan) Lin
Signed-off-by: Mario Limonciello
Reviewed-by: Leo Li
On 6/22/23 14:25, Mario Limonciello wrote:
The `DMUB_FW_VERSION` macro has a mistake in that the revision field
is off by one byte. The last byte is typically used for other purposes
and not a revision.
Cc: Sean Wang
Cc: Marc Rossi
Cc: Hamza Mahfooz
Cc: Tsung-hua (Ryan) Lin
On 6/22/23 14:25, Mario Limonciello wrote:
A number of parade TCONs are causing system hangs when utilized with
older DMUB firmware and PSR-SU. Some changes have been introduced into
DMUB firmware to add resilience against these failures.
Don't allow running PSR-SU unless on the newer
Applied. Thanks!
Alex
On Thu, Jun 22, 2023 at 3:32 AM Yueh-Shun Li wrote:
>
> Spell "transmission" properly.
>
> Found by searching for keyword "tranm".
>
> Signed-off-by: Yueh-Shun Li
> ---
> .../gpu/drm/amd/display/dc/dcn31/dcn31_hpo_dp_stream_encoder.c | 2 +-
> 1 file changed, 1
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:
> >>> On Wed, Jun 21, 2023 at 7:47 AM Evan Quan 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:
On Wed, Jun 21, 2023 at 7:47 AM Evan Quan wrote:
From: Mario Limonciello
Due to electrical and mechanical constraints in certain
Acked-by: Alex Deucher
On Wed, Jun 21, 2023 at 3:30 AM Evan Quan wrote:
>
> The feature mask bit was not correctly cleared. Without that, the L2H
> and H2L interrupts cannot be enabled.
>
> Signed-off-by: Evan Quan
> ---
> drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_thermal.c | 4 +++-
>
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 Wed, Jun 21, 2023 at 11:38 AM Ben Hutchings wrote:
>
> On Thu, 27 Apr 2023 15:43:28 +0800 xiao sheng wen(肖盛文）
> wrote:
> > Package: firmware-amd-graphics
> > Version: 20230310-1~exp1
> > Severity: normal
> > X-Debbugs-Cc: atzli...@sina.com
> >
> > Hi,
> >
> > When I upgrade to kernel
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 certain platform designs
> >> there may be
On Thu, Jun 22, 2023 at 11:19 PM Mario Limonciello
wrote:
>
> If the securedisplay TA failed to load the first time, it's unlikely
> to work again after a suspend/resume cycle or reset cycle and it appears
> to be causing problems in futher attempts.
>
> Fixes: e42dfa66d592 ("drm/amdgpu: Add
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 certain platform designs
there may be likely interference of relatively high-powered harmonics of
the (G-)DDR memory
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
Hi Su,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.4-rc7 next-20230623]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
> > Do only ACPI based systems have:
> >
> >interference of relatively high-powered harmonics of the (G-)DDR
> >memory clocks with local radio module frequency bands used by
> >Wifi 6/6e/7."
> >
> > Could Device Tree based systems not experience this problem?
>
> They could, of
On Wed, Jun 21, 2023 at 01:50:34PM -0500, Limonciello, Mario wrote:
> So if we go down this path of CONFIG_WBRF and CONFIG_WBRF_ACPI, another
> question would be where should the new "wbrf.c" be stored? The ACPI only
> version most certainly made sense in drivers/acpi/wbrf.c, but a generic
>
On Wed, 2023-06-21 at 18:14 +0200, Andrew Lunn wrote:
> > > Do only ACPI based systems have:
> > >
> > > interference of relatively high-powered harmonics of the (G-)DDR
> > > memory clocks with local radio module frequency bands used by
> > > Wifi 6/6e/7."
> > >
> > > Could Device Tree
On Wed, 2023-06-21 at 21:25 +0200, Andrew Lunn wrote:
> > ACPI core does has notifiers that are used, but they don't work the same.
> > If you look at patch 4, you'll see amdgpu registers and unregisters using
> > both
> >
> > acpi_install_notify_handler()
> > and
> > acpi_remove_notify_handler()
Spell "transmission" properly.
Found by searching for keyword "tranm".
Signed-off-by: Yueh-Shun Li
---
.../gpu/drm/amd/display/dc/dcn31/dcn31_hpo_dp_stream_encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
> I think there is enough details for this to happen. It's done
> so that either the AML can natively behave as a consumer or a
> driver can behave as a consumer.
> > > > > +/**
> > > > > + * APIs needed by drivers/subsystems for contributing frequencies:
> > > > > + * During probe, check
> ACPI core does has notifiers that are used, but they don't work the same.
> If you look at patch 4, you'll see amdgpu registers and unregisters using
> both
>
> acpi_install_notify_handler()
> and
> acpi_remove_notify_handler()
>
> If we supported both ACPI notifications and non-ACPI
On Wed, 2023-06-21 at 17:36 +0200, Andrew Lunn wrote:
> On Wed, Jun 21, 2023 at 01:45:56PM +0800, 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
On Wed, Jun 21, 2023 at 01:45:56PM +0800, 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
On Wed, Jun 21, 2023 at 11:15:00AM -0500, Limonciello, Mario wrote:
>
> On 6/21/2023 10:39 AM, Johannes Berg wrote:
> > On Wed, 2023-06-21 at 17:36 +0200, Andrew Lunn wrote:
> > > On Wed, Jun 21, 2023 at 01:45:56PM +0800, Evan Quan wrote:
> > > > From: Mario Limonciello
> > > >
> > > > Due to
> Think a little more about what a non-ACPI implementation
> would look like:
>
> 1) Would producers and consumers still need you to set CONFIG_ACPI_WBRF?
I would expect there to be an CONFIG_WBRF, and then under that a
CONFIG_WBRF_ACPI, CONFIG_WBRF_DT, CONFIG_WBRF_FOOBAR, each indicating
they
> Honestly I'm not sure though we need this complexity right now? I mean,
> it'd be really easy to replace the calls in mac80211 with some other
> more generalised calls in the future?
>
> You need some really deep platform/hardware level knowledge and
> involvement to do this, so I don't think
> And consumer would need to call it, but only if CONFIG_WBRF_ACPI isn't set.
Why? How is ACPI special that it does not need notifiers?
> I don't see why it couldn't be a DT/ACPI hybrid solution for ARM64.
As said somewhere else, nobody does hybrid. In fact, turn it
around. Why not implement
On Wed, 2023-06-21 at 09:12 -0500, Limonciello, Mario wrote:
> >
> > But then the next question anyway is how we merge this? The wifi parts
> > sort of depend on the first patch, although technically I guess I could
> > merge them since it's all hidden behind the CONFIG_ symbol, assuming you
> >
> I think what you're asking for is another layer of indirection
> like CONFIG_WBRF in addition to CONFIG_ACPI_WBRF.
>
> Producers would call functions like wbrf_supported_producer()
> where the source file is not guarded behind CONFIG_ACPI_WBRF,
> but instead by CONFIG_WBRF and locally use
45 matches
Mail list logo
