[AMD Public Use]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, September 16, 2020 02:24
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 2/4] drm/amdgpu: add VCN 3.0 AV1 registers
This
[AMD Public Use]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, September 16, 2020 02:24
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 3/4] drm/amdgpu: use the AV1 defines for VCN 3.0
[AMD Public Use]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, September 16, 2020 02:24
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Gao, Likun
Subject: [PATCH 4/4] drm/amdgpu: add device ID for
Reviewed-by:Hawking Zhang
Sent from my iPhone
> On Sep 16, 2020, at 02:24, Alex Deucher wrote:
>
> Add the VRS registers.
>
> Signed-off-by: Alex Deucher
> ---
> .../include/asic_reg/gc/gc_10_3_0_default.h | 2 +
> .../include/asic_reg/gc/gc_10_3_0_offset.h| 4 ++
>
Hi Dave, Daniel,
Fixes for 5.9.
The following changes since commit 7f7a47952c0f981f9c9a6409c8cf8d025d55af64:
Merge tag 'drm-misc-fixes-2020-09-09' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2020-09-11 09:49:23
+1000)
are available in the Git repository at:
Ping?
On Tue, Sep 15, 2020 at 2:22 PM Alex Deucher wrote:
>
> Navi12 has worked fine for a while now.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
Ping on this series?
Alex
On Tue, Sep 15, 2020 at 2:24 PM Alex Deucher wrote:
>
> Add the VRS registers.
>
> Signed-off-by: Alex Deucher
> ---
> .../include/asic_reg/gc/gc_10_3_0_default.h | 2 +
> .../include/asic_reg/gc/gc_10_3_0_offset.h| 4 ++
>
[AMD Official Use Only - Internal Distribution Only]
Thanks. Reviewed-by: Evan Quan
-Original Message-
From: Xiaoliang Pang
Sent: Thursday, September 17, 2020 11:46 AM
To: Quan, Evan ; Deucher, Alexander
; Koenig, Christian ;
airl...@linux.ie; dan...@ffwll.ch; Feng, Kenneth ;
Remember KFD module initializaton status in a global variable. Skip KFD
device probing when the module was not initialized. Other amdgpu_amdkfd
calls are then protected by the adev->kfd.dev check.
Also print a clear error message when KFD disables itself. Amdgpu
continues its intialization even
modify the return value is -EINVAL
Fixes: f83a9991648bb("drm/amd/powerplay: add Vega10 powerplay support (v5)")
Fixes: 2cac05dee6e30("drm/amd/powerplay: add the hw manager for vega12 (v4)")
Cc: Eric Huang
Cc: Evan Quan
Signed-off-by: Xiaoliang Pang
---
Some nit-picks and one more possible simplification inline. I want to
make adding more stats later as painless as possible.
Looks good otherwise.
Am 2020-09-16 um 2:42 p.m. schrieb Philip Cox:
> Add per-process eviction counters to sysfs to keep track of
> how many eviction events have happened
On Wed, Sep 16, 2020 at 6:16 PM Zhuo, Qingqing wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> On Wed, Sep 16, 2020 at 3:42 PM Qingqing Zhuo wrote:
> >
> > From: jinlong zhang
> >
> > [why]
> > while read edid return defer, then it enter to msleep, but it actually
> > took
On Wed, Sep 16, 2020 at 3:04 AM Christoph Hellwig wrote:
>
> On Tue, Sep 15, 2020 at 02:46:07PM -0400, Alex Deucher wrote:
> > This change breaks tons of systems.
>
> Did you do at least some basic root causing on why? Do GPUs get
> fed address they can't deal with? Any examples?
>
> Bug 1
[AMD Official Use Only - Internal Distribution Only]
On Wed, Sep 16, 2020 at 3:42 PM Qingqing Zhuo wrote:
>
> From: jinlong zhang
>
> [why]
> while read edid return defer, then it enter to msleep, but it actually
> took more time during msleep, this will cause remaining edid read
> fail.
>
>
On Wed, Sep 16, 2020 at 3:42 PM Qingqing Zhuo wrote:
>
> From: jinlong zhang
>
> [why]
> while read edid return defer, then it enter to msleep,
> but it actually took more time during msleep,
> this will cause remaining edid read fail.
>
> [how]
> Replacing msleep with udelay, it will not take
On Wed, Sep 16, 2020 at 11:05 AM Bokun Zhang wrote:
>
> From: Tiecheng Zhou
>
> In FLR routine, init_data_exchange is called at reset_sriov
> while fini_data_exchange is not. This will duplicating work
> thread.
>
> So call fini_data_exchange before reset for SRIOV
>
> Change-Id:
On Wed, Sep 16, 2020 at 11:05 AM Bokun Zhang wrote:
>
> - Add VF2PF message support
> - Remove incorrect Macro to avoid compile error
> - Remove duplicated struct and use amdgv_sriovmsg.h
>
> Change-Id: I8175d304871f4b5aab75fd071a6bdf8008137dbe
> Signed-off-by: Bokun Zhang
Please drop the SWDEV
On Wed, Sep 16, 2020 at 11:05 AM Bokun Zhang wrote:
>
> - Add guest side change to support VF2PF message
> - Fix coding style
>
> Change-Id: I82e5518cb10ec0b19fecaba7e05b02f4b7f2b409
> Signed-off-by: Bokun Zhang
Please drop the SWDEV reference from the subject and prefix the patch
with
On Tue, Sep 15, 2020 at 11:34 PM Ye Bin wrote:
>
> Addresses the following gcc warning with "make W=1":
>
> In file included from
> drivers/gpu/drm/amd/amdgpu/../display/dmub/src/../dmub_srv.h:67:0,
> from drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_dcn21.c:26:
>
On Wed, Sep 16, 2020 at 1:09 PM Luben Tuikov wrote:
>
> Not being able to create amdgpu sysfs attributes
> is not a fatal error warranting not to continue
> to try to bring up the display. Thus, if we get
> an error trying to create amdgpu sysfs attrs,
> report it and continue on to try to bring
On Wed, Sep 16, 2020 at 12:21 PM Tom St Denis wrote:
>
> This register was requested for umr debugging support.
>
> Signed-off-by: Tom St Denis
Reviewed-by: Alex Deucher
> ---
> .../amd/include/asic_reg/uvd/uvd_7_0_offset.h | 3 +++
> .../include/asic_reg/uvd/uvd_7_0_sh_mask.h| 20
From: Anthony Koo
[Header Changes]
- Add new SCRATCH0 status bits for detecting restore state
Signed-off-by: Anthony Koo
Reviewed-by: Aric Cyr
Acked-by: Qingqing Zhuo
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
From: Peikang Zhang
[Why]
We dont's turn off backlight before power off eDP (VDD),
which is a violation of eDP specs.
[How]
Power off eDP backlight before power off eDP
Signed-off-by: Peikang Zhang
Reviewed-by: Anthony Koo
Acked-by: Qingqing Zhuo
---
From: Aric Cyr
Signed-off-by: Aric Cyr
Reviewed-by: Aric Cyr
Acked-by: Qingqing Zhuo
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index
From: jinlong zhang
[why]
while read edid return defer, then it enter to msleep,
but it actually took more time during msleep,
this will cause remaining edid read fail.
[how]
Replacing msleep with udelay, it will not take any extra time, edid return pass
finally.
Signed-off-by: jinlong zhang
From: Anthony Koo
Signed-off-by: Anthony Koo
Reviewed-by: Aric Cyr
Acked-by: Qingqing Zhuo
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
From: Chris Park
[Why]
HDMI requires fallback to TMDS by redetection
in order to switch PHY settings.
This avoids black out when link training fail
during mode setting, link quality update,
disable driver sequence.
[How]
Allow driver to redetect HDMI displays
based on retraining or fallback
From: Wesley Chalmers
[WHY]
When disabling DP video, the current REG_WAIT timeout
of 50ms is too low for certain cases with very high
VSYNC intervals.
[HOW]
Increase the timeout to 102ms, so that
refresh rates as low as 10Hz can be handled properly.
Signed-off-by: Wesley Chalmers
Reviewed-by:
From: Wesley Chalmers
[WHY]
Only the leftmost ODM pipe should be offset when scaling. A previous
code change was intended to implement this policy, but a section of code
was overlooked.
Signed-off-by: Wesley Chalmers
Reviewed-by: Aric Cyr
Acked-by: Qingqing Zhuo
Cc:
---
From: David Galiffi
[Why]
Typo in backlight refactor introduced wrong register offset.
[How]
SR(BIOS_SCRATCH_2) to NBIO_SR(BIOS_SCRATCH_2).
Signed-off-by: David Galiffi
Reviewed-by: Anthony Koo
Acked-by: Qingqing Zhuo
Cc:
---
drivers/gpu/drm/amd/display/dc/dce/dce_panel_cntl.h | 2 +-
1
From: Taimur Hassan
[Why]
When running a game/benchmark with v-sync disabled, disabling a plane
(which is v-sync) can cause an underflow. This is due to flips that are
pending before pipe locking being applied after locks are released and
pipes have been re-arranged or disconnected. This can
From: Wyatt Wood
[Why]
For DMUB implementation of PSR, the 'wait' parameter,
used to determine if driver should wait for PSR enable/disable,
is not implemented correctly.
[How]
Implement wait for PSR enable/disable.
Signed-off-by: Wyatt Wood
Reviewed-by: Anthony Koo
Acked-by: Qingqing Zhuo
From: Wenjing Liu
[why]
Regression is caused by previous change with attempt to correct the
extended cr aux rd interval delay due to mis interpretation of the DP specs.
I4b4f508e30e5218ffeb7e40cc19e6dc54357361e
The change turns out not working well with certain RXs.
So we decided to keep the cr
From: Peikang Zhang
[Why]
dce_is_panel_backlight_on() will return wrong value if
LVTMA_BLON_OVRD is 0
[How]
When LVTMA_BLON_OVRD is 0, read
LVTMA_PWRSEQ_TARGET_STATE instead
Signed-off-by: Peikang Zhang
Reviewed-by: Anthony Koo
Acked-by: Qingqing Zhuo
---
From: Gary Li
[WHY]
In DCN10 when a panel with YCbCr420 capability is connected via
USB-C to HDMI active dongle, no YCbCr420 option is listed in
Radeon settings.
[HOW]
Enable DP YCbCr420 mode support for DCN10
Signed-off-by: Gary Li
Reviewed-by: Eric Yang
Acked-by: Qingqing Zhuo
---
This DC patchset brings improvements in multiple areas. In summary, we have:
* DC version 3.2.104.
* DMUB Firmware release 0.0.34.
* Improve on HDMI fallback mechanism.
* Enable DP YCbCr420 mode support for DCN10 ASICs.
* Bug fixes for backlight, ODM, eDP and others.
--
Anthony Koo (2):
From: Aric Cyr
Signed-off-by: Aric Cyr
Reviewed-by: Aric Cyr
Acked-by: Qingqing Zhuo
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index
On 2020-09-16 1:08 p.m., Bhawanpreet Lakha wrote:
[Why]
"Copy GSL groups when committing a new context" patch was accidentally
removed during a refactor
Patch: 21ffcc94d5b ("drm/amd/display: Copy GSL groups when committing a new
context")
[How]
Re add it
Fixes: b6e881c9474 ("drm/amd/display:
Add per-process eviction counters to sysfs to keep track of
how many eviction events have happened for each process.
v2: rename the stats dir, and track all evictions per process, per device.
v3: Simplify the stats kobject handling and cleanup.
Signed-off-by: Philip Cox
---
Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
> Several GEM and PRIME callbacks have been deprecated in favor of
> per-instance GEM object functions. Remove the callbacks as they are
> now unused. The only exception is .gem_prime_mmap, which is still
> in use by several drivers.
>
> What is
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Slava Abramov
From: amd-gfx on behalf of Luben Tuikov
Sent: Wednesday, September 16, 2020 1:08 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Tuikov, Luben
Subject: [PATCH]
[Why]
"Copy GSL groups when committing a new context" patch was accidentally
removed during a refactor
Patch: 21ffcc94d5b ("drm/amd/display: Copy GSL groups when committing a new
context")
[How]
Re add it
Fixes: b6e881c9474 ("drm/amd/display: update navi to use new surface
programming
Not being able to create amdgpu sysfs attributes
is not a fatal error warranting not to continue
to try to bring up the display. Thus, if we get
an error trying to create amdgpu sysfs attrs,
report it and continue on to try to bring up
a display.
Signed-off-by: Luben Tuikov
---
This register was requested for umr debugging support.
Signed-off-by: Tom St Denis
---
.../amd/include/asic_reg/uvd/uvd_7_0_offset.h | 3 +++
.../include/asic_reg/uvd/uvd_7_0_sh_mask.h| 20 +++
2 files changed, 23 insertions(+)
diff --git
On Wed, Sep 16, 2020 at 04:02:18PM +0200, Christian König wrote:
> Am 16.09.20 um 15:36 schrieb Alex Deucher:
> > On Wed, Sep 16, 2020 at 3:51 AM Daniel Vetter wrote:
> > > On Wed, Sep 16, 2020 at 09:38:34AM +0200, Christian König wrote:
> > > > Am 15.09.20 um 21:35 schrieb Ville Syrjälä:
> > > >
On 2020-09-16 5:12 a.m., Daniel Vetter wrote:
On Fri, Sep 11, 2020 at 10:59:23AM -0400, Rodrigo Siqueira wrote:
Debug issues related to display can be a challenge due to the complexity
around this topic and different source of information might help in this
process. We already have support for
- Add VF2PF message support
- Remove incorrect Macro to avoid compile error
- Remove duplicated struct and use amdgv_sriovmsg.h
Change-Id: I8175d304871f4b5aab75fd071a6bdf8008137dbe
Signed-off-by: Bokun Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +-
From: Tiecheng Zhou
In FLR routine, init_data_exchange is called at reset_sriov
while fini_data_exchange is not. This will duplicating work
thread.
So call fini_data_exchange before reset for SRIOV
Change-Id: I974c6a3c5de86736eebefc386c03fe0e18e1fae3
Signed-off-by: Tiecheng Zhou
- Add guest side change to support VF2PF message
- Fix coding style
Change-Id: I82e5518cb10ec0b19fecaba7e05b02f4b7f2b409
Signed-off-by: Bokun Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h| 29 +-
drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h | 276
2 files changed,
Reviewed-by: Andrey Grodzovsky
Andrey
On 9/16/20 10:33 AM, Alex Deucher wrote:
We never unmapped the regiser BAR on failure.
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++--
1 file
On Wed, Sep 16, 2020 at 09:20:17AM -0400, Alex Deucher wrote:
> This causes screen corruption when using the GPU which makes the
> system unusable.
You have not addressed any of my questions, especially if the commit
that fixed one of the reports (the only one with a recent kernel)
fixed most of
We never unmapped the regiser BAR on failure.
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git
Am 16.09.20 um 15:36 schrieb Alex Deucher:
On Wed, Sep 16, 2020 at 3:51 AM Daniel Vetter wrote:
On Wed, Sep 16, 2020 at 09:38:34AM +0200, Christian König wrote:
Am 15.09.20 um 21:35 schrieb Ville Syrjälä:
On Tue, Sep 15, 2020 at 03:16:32PM -0400, Alex Deucher wrote:
I question the value of
On Wed, Sep 16, 2020 at 3:51 AM Daniel Vetter wrote:
>
> On Wed, Sep 16, 2020 at 09:38:34AM +0200, Christian König wrote:
> > Am 15.09.20 um 21:35 schrieb Ville Syrjälä:
> > > On Tue, Sep 15, 2020 at 03:16:32PM -0400, Alex Deucher wrote:
> > > > I question the value of these warnings. Why even
This causes screen corruption when using the GPU which makes the
system unusable.
It was noticed by several people closer to when the change went in as
well. We looked into it a bit at the time but couldn't determine the
problem. It only seems to affect really old chips (like 15-20 years
old)
On Wed, Sep 16, 2020 at 2:32 AM Greg KH wrote:
>
> On Tue, Sep 15, 2020 at 02:46:07PM -0400, Alex Deucher wrote:
> > This change breaks tons of systems.
>
> Very vague :(
Screen corruption making the system unusable.
>
> This commit has also been merged for over a year, why the sudden
> problem
On Tue, Sep 15, 2020 at 04:59:58PM +0200, Thomas Zimmermann wrote:
> Several GEM and PRIME callbacks have been deprecated in favor of
> per-instance GEM object functions. Remove the callbacks as they are
> now unused. The only exception is .gem_prime_mmap, which is still
> in use by several
On Tue, Sep 15, 2020 at 04:59:54PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces virtgpu's per-driver PRIME export
> function with a per-object function.
>
> Signed-off-by: Thomas Zimmermann
On Tue, Sep 15, 2020 at 04:59:50PM +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 rockchip. The only exception is gem_prime_mmap,
> which is
On Tue, Sep 15, 2020 at 04:59:46PM +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 nouveau.
>
> Signed-off-by: Thomas Zimmermann
Hm ttm and
On Tue, Sep 15, 2020 at 04:59:45PM +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 msm. The only exception is gem_prime_mmap,
> which is
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Tianci Yin
-Original Message-
From: Jiansong Chen
Sent: Wednesday, September 16, 2020 7:34 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhou1, Tao ; Yin, Tianci (Rico) ;
Chen, Jiansong (Simon)
Subject: [PATCH] drm/amdgpu:
On Tue, Sep 15, 2020 at 04:59:44PM +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 mediatek. The only exception is gem_prime_mmap,
> which is
The information provided via MODULE_FIRMWARE appears in
the module information. External tools(eg. dracut) may use the
list of fw files to include them as appropriate in an initramfs,
thus missing declaration will lead to request firmware failure
in boot time.
Signed-off-by: Jiansong Chen
On Tue, Sep 15, 2020 at 04:59:42PM +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 gma500.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by:
On Wed, Sep 16, 2020 at 12:36:28PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 16.09.20 um 12:03 schrieb Daniel Vetter:
> > On Tue, Sep 15, 2020 at 04:59:41PM +0200, Thomas Zimmermann wrote:
> >> GEM object functions deprecate several similar callback interfaces in
> >> struct drm_driver. This
On Tue, Sep 15, 2020 at 04:59:40PM +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 etnaviv. The only exception is gem_prime_mmap,
> which is
Hi
Am 16.09.20 um 12:03 schrieb Daniel Vetter:
> On Tue, Sep 15, 2020 at 04:59:41PM +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 exynos.
On Tue, Sep 15, 2020 at 04:59:41PM +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 exynos. The only exception is gem_prime_mmap,
> which is
On Wed, Sep 16, 2020 at 08:33:00AM +0200, Greg KH wrote:
> On Tue, Sep 15, 2020 at 02:46:07PM -0400, Alex Deucher wrote:
> > This change breaks tons of systems.
>
> Very vague :(
>
> This commit has also been merged for over a year, why the sudden
> problem now?
Unrelated rant, but one year is
On Fri, Sep 11, 2020 at 10:59:23AM -0400, Rodrigo Siqueira wrote:
> Debug issues related to display can be a challenge due to the complexity
> around this topic and different source of information might help in this
> process. We already have support for tracepoints inside the display
> component,
On Wed, Sep 16, 2020 at 09:38:34AM +0200, Christian König wrote:
> Am 15.09.20 um 21:35 schrieb Ville Syrjälä:
> > On Tue, Sep 15, 2020 at 03:16:32PM -0400, Alex Deucher wrote:
> > > I question the value of these warnings. Why even have a boolean type
> > > if you are going to get warnings when
Am 15.09.20 um 23:52 schrieb Philip Yang:
Set ttm->sg to NULL after kfree, to avoid memory corruption backtrace:
[ 420.932812] kernel BUG at
/build/linux-do9eLF/linux-4.15.0/mm/slub.c:295!
[ 420.934182] invalid opcode: [#1] SMP NOPTI
[ 420.935445] Modules linked in: xt_conntrack
Am 15.09.20 um 21:35 schrieb Ville Syrjälä:
On Tue, Sep 15, 2020 at 03:16:32PM -0400, Alex Deucher wrote:
I question the value of these warnings. Why even have a boolean type
if you are going to get warnings when you use them...
That said, applied to avoid getting these patches again and again
On Tue, Sep 15, 2020 at 02:46:07PM -0400, Alex Deucher wrote:
> This change breaks tons of systems.
Did you do at least some basic root causing on why? Do GPUs get
fed address they can't deal with? Any examples?
Bug 1 doesn't seem to contain any analysis and was reported against
a very old
On Tue, Sep 15, 2020 at 02:46:07PM -0400, Alex Deucher wrote:
> This change breaks tons of systems.
Very vague :(
This commit has also been merged for over a year, why the sudden
problem now?
> This reverts commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713.
You mean "33b3ad3788ab ("drm/radeon:
76 matches
Mail list logo
