From: "Dr. David Alan Gilbert"
Free doorbells in the error paths of cik_init and in cik_fini.
Build tested only.
Suggested-by: Christophe JAILLET
Signed-off-by: Dr. David Alan Gilbert
---
RFC->v1
Renamed ringCP[12]->ring_cp[12]
Cleaned up doorbells in cik_startup failure case
drivers/gp
From: "Dr. David Alan Gilbert"
smu_v13_0_init_display_count() was added in 2020 by
commit c05d1c401572 ("drm/amd/swsmu: add aldebaran smu13 ip support (v3)")
but is unused.
See discussion on:
https://lore.kernel.org/all/dm4pr12mb5165d85bd85bc8fc8bf7a3b48e...@dm4pr12mb5165.namprd12.prod.outlook.c
From: "Dr. David Alan Gilbert"
Hi,
A few more AMD deadcoding patches spinning out of the
questions I asked, and Kenneth answered.
See:
https://lore.kernel.org/all/dm4pr12mb5165d85bd85bc8fc8bf7a3b48e...@dm4pr12mb5165.namprd12.prod.outlook.com/
Dave
Signed-off-by: Dr. David Alan Gilbert
From: "Dr. David Alan Gilbert"
smu_mode2_reset_is_support() was added in 2020 by
commit 5c03e5843e6b ("drm/amdgpu:add smu mode1/2 support for aldebaran")
but has remained unused.
See discussion at:
https://lore.kernel.org/all/dm4pr12mb5165d85bd85bc8fc8bf7a3b48e...@dm4pr12mb5165.namprd12.prod.out
From: "Dr. David Alan Gilbert"
The previous patch removed smu_mode2_reset_is_support()
which was the only function to call through the mode2_reset_is_support()
method pointer.
Remove the remaining functions that were assigned to it
and the pointer itself.
See discussion at:
https://lore.kernel.
From: "Dr. David Alan Gilbert"
smu_v13_0_display_clock_voltage_request() and
smu_v13_0_set_min_deep_sleep_dcefclk() were added in 2020 by
commit c05d1c401572 ("drm/amd/swsmu: add aldebaran smu13 ip support (v3)")
but have remained unused.
Remove them.
smu_v13_0_display_clock_voltage_request() w
From: "Dr. David Alan Gilbert"
smu7_copy_bytes_from_smc() was added in 2016 by
commit 1ff55f465103 ("drm/amd/powerplay: implement smu7_smumgr for asics
with smu ip version 7.")
but never used.
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
.../drm/amd/pm/powerplay/smumgr/smu7_smumgr.c
From: "Dr. David Alan Gilbert"
Hi,
A bunch more deadcode around the AMD GPUs.
(I've not done smu_v14 which all looks rather new
to me, so perhaps you're still intending to use
some of the unused functions).
Signed-off-by: Dr. David Alan Gilbert
Dr. David Alan Gilbert (3):
drm/amd/pm/smu7:
From: "Dr. David Alan Gilbert"
The last use of smu_v11_0_get_dpm_level_range() was removed in 2020 by
commit 46a301e14e8a ("drm/amd/powerplay: drop unnecessary Navi1x specific
APIs")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v11_0.h | 5 ---
.
From: "Dr. David Alan Gilbert"
rn_vbios_smu_set_dprefclk() was added in 2019 by
commit 4edb6fc91878 ("drm/amd/display: Add Renoir clock manager")
rv1_vbios_smu_set_dprefclk() was also added in 2019 by
commit dc88b4a684d2 ("drm/amd/display: make clk mgr soc specific")
neither have been used.
Rem
From: "Dr. David Alan Gilbert"
The last use of r600_hdmi_audio_workaround() was removed by 2014's
commit 6e72376dcc66 ("radeon/audio: consolidate audio_mode_set()
functions")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/radeon/r600_hdmi.c | 22 --
From: "Dr. David Alan Gilbert"
radeon_doorbell_free() was added in 2013 by
commit 75efdee11b5d ("drm/radeon: implement simple doorbell page
allocator")
but never used.
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/radeon/radeon.h| 1 -
drivers/gpu/drm/radeon/ra
From: "Dr. David Alan Gilbert"
radeon_fence_wait_any() last use was removed in 2023's
commit 254986e324ad ("drm/radeon: Use the drm suballocation manager
implementation.")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/radeon/radeon.h | 3 --
drivers/gpu/drm/radeo
From: "Dr. David Alan Gilbert"
Hi,
Another set of deadcoding around amd/radeon GPU stuff.
Dave
Signed-off-by: Dr. David Alan Gilbert
Dr. David Alan Gilbert (4):
drm/radeon/radeon_audio: Remove unused r600_hdmi_audio_workaround
drm/radeon: Remove unused radeon_doorbell_free
drm/radeon:
From: "Dr. David Alan Gilbert"
Hi,
Here's another blob of deadcoding in the amdgpu's;
this set is all the symbols I noticed that start with 'P'.
Most, as normal are whole function removals,
but I also nuke the powerdown_uvd member in one patch.
Dave
Signed-off-by: Dr. David Alan Gilbert
From: "Dr. David Alan Gilbert"
phm_powerdown_uvd() has been unused since 2017's
commit 47047263c527 ("drm/amd/powerplay: delete eventmgr related files.")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
.../gpu/drm/amd/pm/powerplay/hwmgr/hardwaremanager.c | 10 --
drivers/gpu/dr
From: "Dr. David Alan Gilbert"
pp_atomfwctrl_get_pp_assign_pin() and pp_atomfwctrl_get_pp_assign_pin()
were added in 2017 by
commit 0d2c7569e196 ("drm/amdgpu: add new atomfirmware based helpers for
powerplay")
but have remained unused.
Remove them, and the helper functions they used.
Signed-off
From: "Dr. David Alan Gilbert"
pqm_get_kernel_queue() has been unused since 2022's
commit 5bdd3eb25354 ("drm/amdkfd: Remove unused old debugger
implementation")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 2 --
.../gpu/drm/amd/am
From: "Dr. David Alan Gilbert"
With phm_powerdown_uvd() gone in the previous patch, there's
now no longer anything that reads the powerdown_uvd member of the
pp_hwmgr_func.
Remove it.
There are a few assignments to it; a boring NULL which can just go,
and two functions, but those functions are
From: "Dr. David Alan Gilbert"
pre_surface_trace() has been unused since 2017's
commit 745cc746da42 ("drm/amd/display: remove
dc_pre_update_surfaces_to_stream from dc use")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
.../gpu/drm/amd/display/dc/core/dc_debug.c| 120 ---
From: "Dr. David Alan Gilbert"
print__rq_dlg_params_st() was added in 2017 by
commit 061bfa06a42a ("drm/amdgpu/display: Add dml support for DCN")
but has remained unused.
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
.../drm/amd/display/dc/dml/display_rq_dlg_helpers.c | 11 --
From: "Dr. David Alan Gilbert"
The last use of optc3_fpu_set_vrr_m_const() was removed in 2022's
commit 64f991590ff4 ("drm/amd/display: Fix a compilation failure on PowerPC
caused by FPU code")
which removed the only caller (with a similar) name.
Remove it.
Signed-off-by: Dr. David Alan Gilbert
From: "Dr. David Alan Gilbert"
The nbif_v6_3_1_sriov_funcs instance of amdgpu_nbio_funcs was added in
commit 894c6d3522d1 ("drm/amdgpu: Add nbif v6_3_1 ip block support")
but has remained unused.
Alex has confirmed it wasn't needed.
Remove it, together with the four unused stub functions:
nbi
From: "Dr. David Alan Gilbert"
mod_freesync_get_vmin_vmax() and mod_freesync_get_v_position() were
added in 2017 by
commit 72ada5f76939 ("drm/amd/display: FreeSync Auto Sweep Support")
mod_freesync_is_valid_range() was added in 2018 by
commit e80e94460841 ("drm/amd/display: add method to check f
From: "Dr. David Alan Gilbert"
link_enc_cfg_get_link_enc_used_by_stream() is no longer used after
2021's:
commit 6366b00346c0 ("drm/amd/display: Maintain consistent mode of
operation during encoder assignment")
which introduces and uses the _current version instead.
Remove it.
Signed-off-by: Dr
From: "Dr. David Alan Gilbert"
get_clock_requirements_for_state() was added in 2018 by
commit 8ab2180f96f5 ("drm/amd/display: Add function to fetch clock
requirements")
but never used.
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 12 -
From: "Dr. David Alan Gilbert"
get_max_support_fbc_buffersize() is unused since 2021's
commit 94f0d0c80cf3 ("drm/amd/display/dc/dce110/dce110_compressor: Remove
unused function 'dce110_get_required_compressed_surfacesize")
removed it's only caller.
Remove it.
Signed-off-by: Dr. David Alan Gilbe
From: "Dr. David Alan Gilbert"
mpc1_is_mpcc_idle() was added in 2017 by
commit feb4a3cd8eb0 ("drm/amd/display: Integrating MPC pseudocode")
but never used.
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
.../gpu/drm/amd/display/dc/mpc/dcn10/dcn10_mpc.c | 16
.../gpu/drm/
From: "Dr. David Alan Gilbert"
Another small pile of deadcode patches.
Signed-off-by: Dr. David Alan Gilbert
Dr. David Alan Gilbert (7):
drm/amd/display: Remove unused mpc1_is_mpcc_idle
drm/amd/display: Remove unused freesync functions
drm/amd/display: Remove unused dc_stream_get_crtc_p
From: "Dr. David Alan Gilbert"
hubbub1_toggle_watermark_change_req() last use was removed in 2017 by
commit b8fce2c9d773 ("drm/amd/display: Optimize programming front end")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
.../amd/display/dc/hubbub/dcn10/dcn10_hubbub.c | 18 ---
From: "Dr. David Alan Gilbert"
The last user of dc_stream_get_crtc_position() was
mod_freesync_get_v_position() which is removed in a previous
patch in this series.
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 27 --
dri
From: "Dr. David Alan Gilbert"
kfd_device_by_pci_dev(), kfd_get_pasid_limit() and kfd_set_pasid_limit()
have been unused since 2023's
commit c99a2e7ae291 ("drm/amdkfd: drop IOMMUv2 support")
Remove them.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/amd/amdkfd/kfd_pasid.c| 24
From: "Dr. David Alan Gilbert"
Hi,
This removes a bunch more functions (and a field) from
drm/amd/display that are unused.
Signed-off-by: Dr. David Alan Gilbert
Dave
Dr. David Alan Gilbert (5):
drm/amd/display: Remove unused enable_surface_flip_reporting
drm/amd/display: Remove unused d
From: "Dr. David Alan Gilbert"
dwb3_set_host_read_rate_control() has been unused since it was added by
commit 8993dee0de2a ("drm/amd/display: Add DCN3 DWB")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
.../gpu/drm/amd/display/dc/dwb/dcn30/dcn30_dwb.c| 13 -
.../gpu/drm
From: "Dr. David Alan Gilbert"
dc_stream_warmup_writeback() is unused since it was added in 2019 by
commit 6a652f6d127d ("drm/amd/display: Add warmup escape call support")
Remove it.
Note there is a dcn30 version that's called directly which is kept.
Signed-off-by: Dr. David Alan Gilbert
---
From: "Dr. David Alan Gilbert"
enable_surface_flip_reporting() has been unused since it was added by
commit 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/amd/display/dc/core/dc_surface.c | 7 ---
drivers/gpu/dr
From: "Dr. David Alan Gilbert"
mmhubbub_warmup is a field that was only read by the just removed
dc_stream_warmup_writeback() function.
Remove the field and it's initialisers.
It was only ever initialised to a single function value
(dcn30_mmhubbub_warmup) which is called explicitly elsewhere.
From: "Dr. David Alan Gilbert"
dcn_find_dcfclk_suits_all() last use was removed by 2018's
commit 4fd994c448a3 ("drm/amd/display: Start using the new pp_smu
interface")
Remove it, and the dcn_find_normalized_clock_vdd_Level helper it used.
Signed-off-by: Dr. David Alan Gilbert
---
.../drm/amd/
From: "Dr. David Alan Gilbert"
Commit c2c2ce1e9623 ("drm/amd/display: Optimize passive update planes.")
removed the last caller of context_timing_trace.
Remove it.
With that gone, no one is now looking at the 'timing_trace' flag, remove
it and all the places that set it.
Signed-off-by: Dr. Davi
From: "Dr. David Alan Gilbert"
cm3_helper_translate_curve_to_degamma_hw_format() since it was added in
2020's commit
03f54d7d3448 ("drm/amd/display: Add DCN3 DPP")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
.../amd/display/dc/dcn30/dcn30_cm_common.c| 151 --
.../
From: "Dr. David Alan Gilbert"
calculate_user_regamma_coeff() and calculate_user_regamma_ramp() were
added in 2018 in commit
55a01d4023ce ("drm/amd/display: Add user_regamma to color module")
but never used.
Remove them and their helpers.
Signed-off-by: Dr. David Alan Gilbert
---
.../amd/dis
From: "Dr. David Alan Gilbert"
We start with the function 'atomctrl_calculate_voltage_evv_on_sclk'
which has been unused since 2016's commit
e805ed83ba1c ("drm/amd/powerplay: delete useless files.")
Remove it.
It was the last user of the struct ATOM_ASIC_PROFILING_INFO_V3_4
remove it.
It was a
From: "Dr. David Alan Gilbert"
Hi,
This is a bunch of deadcode removal in amdgpu;
some of the functions are ones which were previously
used but haven't been for a while, others are functions
that were added a few years ago and haven't ever been used.
There are some others that I've not remov
From: "Dr. David Alan Gilbert"
amdgpu_gfx_bit_to_me_queue has been unused since it was added in
commit 7470bfcf2014 ("drm/amdgpu: add helper function for gfx queue/bitmap
transition")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 10 --
From: "Dr. David Alan Gilbert"
amdgpu_gmc_vram_cpu_pa has been unused since commit
087451f372bf ("drm/amdgpu: use generic fb helpers instead of setting up AMD
own's.")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 12
drivers/gpu/
From: "Dr. David Alan Gilbert"
amdgpu_atpx_dgpu_req_power_for_displays has been unused since
commit bdb1ccb080da ("drm/amdgpu: remove ATPX_DGPU_REQ_POWER_FOR_DISPLAYS
check when hotplug-in")
amdgpu_atpx_get_dhandle has been unused since commit
f9b7f3703ff9 ("drm/amdgpu/acpi: make ATPX/ATCS struc
From: "Dr. David Alan Gilbert"
amdgpu_device_ip_is_idle is unused.
It was renamed from 'amdgpu_is_idle' which was originally added in
commit 5dbbb60ba61e ("drm/amdgpu: add IP helpers for wait_for_idle and is_idle")
but hasn't been used.
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
dr
From: "Dr. David Alan Gilbert"
amdgpu_i2c_add and amdgpu_i2c_init were added in 2015's commit
d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
but never used.
Remove them.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 25 -
driver
From: "Dr. David Alan Gilbert"
bios_get_vga_enabled_displays has been unused since
commit 5a8132b9f606 ("drm/amd/display: remove dead dc vbios code")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c | 7 ---
drivers/gpu/drm/am
e.
>
> With the help of Arch Linux team, we was able to track bad commit to
> this:
> https://gitlab.freedesktop.org/agd5f/linux/-/commit/63d0b87213a0ba241b3fcfba3fe7b0aed0cd1cc5
Hamza Mahfooz, in case you missed it, that is a patch of yours:
63d0b87213a0ba ("drm/amd/display: add
;> -Original Message-
>> From: ke...@holm.dev
>> Sent: Sunday, July 28, 2024 12:43 AM
>> To: Linux regressions mailing list ; Deucher,
>> Alexander ; Wu, Hersen
>> ; Lin, Wayne
>> Cc: regressi...@lists.linux.dev; sta...@vger.kernel.org; LKML > ker...@vg
On 29.07.24 10:47, Christian Heusel wrote:
> On 24/07/29 10:35AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>> [+Greg +stable]
>>
>> On 29.07.24 10:16, Lin, Wayne wrote:
>>>
>>> Thanks for the report.
>>>
>>>
On 16.07.24 19:33, Alex Deucher wrote:
> This reverts commit bc87d666c05a13e6d4ae1ddce41fc43d2567b9a2 and the
> register changes from commit 6d4279cb99ac4f51d10409501d29969f687ac8dc.
>
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3478
> Cc: mikhail.v.gavri...@gmail.com
> Cc: Rodrigo S
displays.
>
> The CPU in the Lenovo P14s is a 'AMD Ryzen 7 PRO 5850U with Radeon
> Graphics' and it has no discrete GPU.
>
> I first noticed the issue with kernel version '6.10.0-arch1-2'
> provided by arch linux. With the previous kernel version
> '6.9
; version), or revert both commits 6296562f30b1 and 2105e8e00da4 (on
> stable, linux-6.9.y). I have no problems on any recent linux-mainline
> (v6.10{,-rc*}) when reverting these two commits (in addition to
> reverting 7902ec988a9a and 6856f079cd45 to successfully build the
> kernel). I
looks stalled -- and the regression report is 6 weeks
old by now. :-/ Or was a solution found in between?
So I assume no solution will be ready in time for the 6.10 final? I also
assume a "simple" temporary revert is not a option or bears big risks?
Ciao, Thorsten (wearing his '
of 771ed66105de and unfortunately the
> issue is not fixed.
> I saw a green flashing bar on top of the screen again.
Hmmm, I might have missed something, but it looks like nothing happened
here since then. What's the status? Is the issue still happening? Any
solution in sight?
Ciao, T
On 06.06.24 05:06, Winston Ma wrote:
> Hi I got the same problem on Linux Kernel 6.10-rc2. I got the problem by
> following the procedure below:
>
> 1. Boot Linux Kernel 6.10-rc2
> 2. Open Firefox (Any browser should work)
> 3. Open a Youtube Video
> 4. On the playing vid
gress somewhere and I just
missed it? Or would it be better if Mikhail would report this to
https://gitlab.freedesktop.org/drm/amd/-/issues/ ?
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
at
>> kernel/locking/mutex.c:585
> I am also getting this error on every boot. Decoded stacktrace:
TWIMC & for the record: Boris also reported this; Vasant Hegde replied
and said a fix is in the works:
https://lore.kernel.org/all/898d356d-ec7d-41de-82d8-3ed4dc559...@amd.com/
Ciao
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
Hmm, from here it looks like the patch now that it was reviewed more
that a week ago is still not even in -next. Is there a reason?
I know, we are in the merge window
On 18.04.24 21:43, Harry Wentland wrote:
> On 2024-03-07 01:29, Wayne Lin wrote:
>> [Why]
>> Commit:
>> - commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
>> allocation/removement")
>> accidently overwrite the commit
>> - commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in
>> dr
On 21.02.24 16:53, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 21.02.24 16:39, Alex Deucher wrote:
>> On Wed, Feb 21, 2024 at 1:06 AM Linux regression tracking (Thorsten
>> Leemhuis) wrote:
>>>
>>> On 20.02.24 21:18, Alex Deucher wrote:
>>&g
On 21.02.24 16:39, Alex Deucher wrote:
> On Wed, Feb 21, 2024 at 1:06 AM Linux regression tracking (Thorsten
> Leemhuis) wrote:
>>
>> On 20.02.24 21:18, Alex Deucher wrote:
>>> On Tue, Feb 20, 2024 at 2:41 PM Romano wrote:
>>>>
>>>> If the incr
be
>>> an issue if you stick the bounding box.
>>>
>>> Alex
>>>
>>>> As for solution, what some suggested already exist - a patch posted by
>>>> fililip on gitlab is probably the way most of you would agree. It
>>>> introduce
On 20.02.24 16:27, Hans de Goede wrote:
> Hi,
>
> On 2/20/24 16:15, Alex Deucher wrote:
>> On Tue, Feb 20, 2024 at 10:03 AM Linux regression tracking (Thorsten
>> Leemhuis) wrote:
>>>
>>> On 20.02.24 15:45, Alex Deucher wrote:
>>>> On Mon
On 20.02.24 15:45, Alex Deucher wrote:
> On Mon, Feb 19, 2024 at 9:47 AM Linux regression tracking (Thorsten
> Leemhuis) wrote:
>>
>> On 17.02.24 14:30, Greg KH wrote:
>>> On Sat, Feb 17, 2024 at 02:01:54PM +0100, Roman Benes wrote:
>>>> Minimum power limit
param is readonly, even for root).
>
>
> Thank you in advance for looking into this, with regards: Romano
"""
And while at it, let me add this issue to the tracking as well
[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find b
ot fix: drm/amd/display: Only allow dig mapping to pwrseq in new asic
#regzbot ignore-activity
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.
On 27.01.24 14:14, Salvatore Bonaccorso wrote:
>
> In Debian (https://bugs.debian.org/1061449) we got the following
> quotred report:
>
> On Wed, Jan 24, 2024 at 07:38:16PM +0100, Patrice Duroux wrote:
>>
>> Giving a try to 6.7, here is a message extracted from dmesg:
>> [4.177226] ---
[TLDR: This mail in primarily relevant for Linux kernel regression
tracking. See link in footer if these mails annoy you.]
On 01.12.23 01:30, Bagas Sanjaya wrote:
>
>> Since kernel version 6.1.57 I have problems with external monitor wakeup
>> after suspend on Thinkpad X13 AM
[TLDR: This mail in primarily relevant for Linux kernel regression
tracking. See link in footer if these mails annoy you.]
On 26.10.23 19:33, Alexey Klimov wrote:
> #regzbot introduced: 1cfb4d612127
> #regzbot title: rx7600 stopped working after "1cfb4d612127 drm/amdgpu: put
>
smatch issue is something I'll need to fix in driver for
>> Linux.
>
> @Mahfooz, Hamza @Alvin Lee any update on a fix for this?
Still no news afaics. Or was there any progress I missed?
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Ev
it seems the issue
wasn't discussed anywhere else during the last 10 days, but I might have
missed something.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
#regzbot poke
[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.
See link in footer if these mails annoy you.]
On 14.11.23 11:55, Mikhail Gavrilov wrote:
On 19.11.23 14:24, Bagas Sanjaya wrote:
> On Sun, Nov 19, 2023 at 04:47:01PM +1000, Dave Airlie wrote:
>>> On 12.11.23 01:46, Phillip Susi wrote:
I had been testing some things on a post 6.6-rc5 kernel for a week or
two and then when I pulled to a post 6.6 release kernel, I found that
>>>
.7-rc1 (or rc2, which
comes out later today) or 6.6.2-rc1 improve things.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did som
[TLDR: This mail in primarily relevant for Linux kernel regression
tracking. See link in footer if these mails annoy you.]
On 04.11.23 10:42, Sudip Mukherjee wrote:
> On Thu, 2 Nov 2023 at 22:53, Alex Deucher wrote:
>> On Thu, Nov 2, 2023 at 1:07 PM Sudip Mukherjee
>> wrote:
&g
[TLDR: This mail in primarily relevant for Linux kernel regression
tracking. See link in footer if these mails annoy you.]
On 14.07.23 04:50, Bagas Sanjaya wrote:
> Anyway, I'm adding it to regzbot to ensure it doesn't fall through cracks
> unnoticed:
>
> #regzbot intr
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
I still have this issue on my list of tracked regressions.
Was this fixed in between? Doesn't look like it from here, but I might
be missing something.
Ciao
[TLDR: This mail in primarily relevant for Linux kernel regression
tracking. See link in footer if these mails annoy you.]
On 19.07.23 18:17, Linux regression tracking #adding (Thorsten Leemhuis)
wrote:
> On 17.07.23 15:09, Michel Dänzer wrote:
>> On 5/10/23 23:23, Alex Deucher wrote:
[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.
See link in footer if these mails annoy you.]
On 17.07.23 15:09, Michel Dänzer wrote:
> On 5/
On 14.07.23 05:12, Steven Rostedt wrote:
> On Fri, 14 Jul 2023 09:50:17 +0700
> Bagas Sanjaya wrote:
>
>> I notice a regression report on Bugzilla [1]. Quoting from it:
>>
>>
>> See Bugzilla for the full thread and attached patches that fixes
>> this regression.
>>
>> Later, when bisecting, the r
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.
only way to get down to the
problem. Sure, sending a few developers a quick inquiry along the lines
of "do you maybe have an idea what's up there" is fine, but that's not
what you did in your mail. Your list of recipients is also quite long;
that's risky: if you do that t
On 02.05.23 15:48, Felix Richter wrote:
> On 5/2/23 15:34, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 02.05.23 15:13, Alex Deucher wrote:
>>> On Tue, May 2, 2023 at 7:45 AM Linux regression tracking (Thorsten
>>> Leemhuis) wrote:
>>>
>>
On 02.05.23 15:13, Alex Deucher wrote:
> On Tue, May 2, 2023 at 7:45 AM Linux regression tracking (Thorsten
> Leemhuis) wrote:
>
>> On 30.04.23 13:44, Felix Richter wrote:
>>> Hi,
>>>
>>> I am running into an issue with the integrated GPU of the Ryzen
[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]
[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might
[TLDR: This mail in primarily relevant for Linux kernel regression
tracking. See link in footer if these mails annoy you.]
On 26.12.22 14:26, Thorsten Leemhuis wrote:
> On 25.12.22 13:14, Michael Laß wrote:
>> CC'ing amd-gfx as this might be an issue in the amd driver.
>>
>
accepted? patchwork doesn't
> show any activity on them, or at least I can't figure it out...
I didn't look closer (hence please correct me if I'm wrong), but the
core changes afaics are in the DRM pull airlied send a few hours ago to
Linus (note the "amdgpu […] DP MST fixes" line):
https://lore.kernel.org/all/capm%3d9tzuu4xnx6t5v7sksk%2ba5heapoc1iemyznsyqzgztj%3d...@mail.gmail.com/
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
From: Thomas Zimmermann Sent: Monday, December 19, 2022
8:05 AM
>
> Generic fbdev drivers use the apertures field in struct fb_info to
> control ownership of the framebuffer memory and graphics device. Do
> not set the values in hyperv-fb.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/
changes for DCN2")
Signed-off-by: Wen Yang
Cc: Aurabindo Pillai
Cc: Hamza Mahfooz
Cc: Guenter Roeck
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Leo Li
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/amd/display/dc
From: Alex Deucher Sent: Tuesday, April 12, 2022 7:13 AM
>
> On Tue, Apr 12, 2022 at 4:01 AM Paul Menzel wrote:
> >
> > [Cc: +x86 folks]
> >
> > Dear Alex, dear x86 folks,
> >
> >
> > x86 folks, can you think of alternatives to access `X86_HYPER_MS_HYPERV`
> > from `arch/x86/include/asm/hypervis
On Tue, Sep 15, 2020 at 04:59:39PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in armada.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Rus
On Tue, Nov 20, 2018 at 06:13:42PM +0200, Ville Syrjala wrote:
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index a7c39f39793f..38c66fbc8276 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -849,7 +849,8 @@
(While there's a rain shower...)
On Thu, Apr 26, 2018 at 02:09:42AM -0700, Christoph Hellwig wrote:
> synopsis:
>
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c:pdevinfo.dma_mask
> = DMA_BIT_MASK(32);
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c: pdevinfo.dma_mask =
On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote:
> On arm that doesn't work. The iommu api seems like a good fit, except
> the dma-api tends to get in the way a bit (drm/msm apparently has
> similar problems like tegra), and if you need contiguous memory
> dma_alloc_coherent is the on
On Wed, Apr 25, 2018 at 08:33:12AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote:
> > - dma api hides the cache flushing requirements from us. GPUs love
> > non-snooped access, and worse give userspace control over that. We want
> > a strict sep
On Wed, Apr 25, 2018 at 01:54:39AM -0700, Christoph Hellwig wrote:
> [discussion about this patch, which should have been cced to the iommu
> and linux-arm-kernel lists, but wasn't:
> https://www.spinics.net/lists/dri-devel/msg173630.html]
>
> On Wed, Apr 25, 2018 at 09:41
99 matches
Mail list logo
