[Bug 109138] [KBL-G][GL-CTS]KHR-GL31.texture_size_promotion.functional test failed
https://bugs.freedesktop.org/show_bug.cgi?id=109138 --- Comment #1 from Hai --- Created attachment 142877 --> https://bugs.freedesktop.org/attachment.cgi?id=142877&action=edit TestResults.qpa -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109138] [KBL-G][GL-CTS]KHR-GL31.texture_size_promotion.functional test failed
https://bugs.freedesktop.org/show_bug.cgi?id=109138 Bug ID: 109138 Summary: [KBL-G][GL-CTS]KHR-GL31.texture_size_promotion.functio nal test failed Product: DRI Version: XOrg git Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: hai@intel.com When Use Kaby Lake-g(AMD Vega M GPU) to do the OpenGL CTS test, the case " KHR-GL31.texture_size_promotion.functional" will fail Following is the environtment PlatformKabyLake-G CPU Intel (R) Core (TM) i7-8809G CPU @3.10GHz GPU AMD(Radeon RX Vega M GH Graphics); Memory 16G OS Ubutu18.04 Kernel 4.19.0 Mesa: mesa 18.3.0 (https://mesa.freedesktop.org/archive/mesa-18.3.0.tar.gz) VK-GL-CTS version https://github.com/KhronosGroup/VK-GL-CTS commit 54e546a1a0a6fa412ea4c3e3081bbc9518928a6e How to reproduce $ ./glcts -n KHR-GL31.texture_size_promotion.functional Writing test log into TestResults.qpa dEQP Core git-54e546a1a0a6fa412ea4c3e3081bbc9518928a6e (0x54e546a1) starting.. target implementation = 'Default' Test case 'KHR-GL31.texture_size_promotion.functional'.. Fail (Fail) DONE! Test run totals: Passed: 0/1 (0.0%) Failed: 1/1 (100.0%) Not supported: 0/1 (0.0%) Warnings: 0/1 (0.0%) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/11] vga-switcheroo: make PCI dependency explicit
This driver depends on the PCI infrastructure but the dependency has not been explicitly called out. Signed-off-by: Sinan Kaya Reviewed-by: Lukas Wunner --- drivers/gpu/vga/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig index b677e5d524e6..d5f1d8e1c6f8 100644 --- a/drivers/gpu/vga/Kconfig +++ b/drivers/gpu/vga/Kconfig @@ -21,6 +21,7 @@ config VGA_SWITCHEROO bool "Laptop Hybrid Graphics - GPU switching support" depends on X86 depends on ACPI + depends on PCI select VGA_ARB help Many laptops released in 2008/9/10 have two GPUs with a multiplexer -- 2.19.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/11] vga-switcheroo: make PCI dependency explicit
On 12/23/2018 8:15 PM, Lukas Wunner wrote:
On Sun, Dec 23, 2018 at 02:00:15AM +0300, Sinan Kaya wrote:
On Sat, Dec 22, 2018 at 7:40 PM Lukas Wunner wrote:
On Sat, Dec 22, 2018 at 09:07:12AM +, Sinan Kaya wrote:
This driver depends on the PCI infrastructure but the dependency has not
been explicitly called out.
Signed-off-by: Sinan Kaya
Reviewed-by: Lukas Wunner
This series doesn't have a cover letter so it's unclear to me through
which tree it's supposed to go in? Each patch through the individual
subsystem tree or all through the same tree? If the former I guess I
could push this to drm-misc...
Feel free to apply individual patches independently. Let me know which
one you applied so that I can drop them on the next rev.
I've realized only now that this patch fixes fallout of commit
5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
which is part of Rafael's acpi pull for v4.21.
Usually such fixes go through the same tree as the offending commit,
so I'd expect Raphael to pick up the whole series and forward it to
Linus in the second half of the merge window. I'm not sure if that's
how it'll play out though given the holidays.
I'll do follow-up with Rafael. Apologize for not giving the full story.
Trying to get pieces out in the middle of vacation as there was a breakage.
I didn't have time to polish.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup
On Sun, Dec 23, 2018 at 02:55:52PM +0100, Noralf Trønnes wrote:
>
>
> Den 23.12.2018 01.55, skrev Peter Wu:
> > After drm_fb_helper_fbdev_setup calls drm_fb_helper_init,
> > "dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will
> > have some effect). After that, drm_fb_helper_initial_config is called
> > which may call the "fb_probe" driver callback.
> >
> > This driver callback may call drm_fb_helper_defio_init (as is done by
> > drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs)
> > as documented. These are normally cleaned up on exit by
> > drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini.
> >
> > If an error occurs after "fb_probe", but before setup is complete, then
> > calling just drm_fb_helper_fini will leak resources. This was triggered
> > by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"):
> >
> > [ 50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support
> > this framebuffer
> > [ 50.009436] bochs-drm :00:02.0: [drm:drm_fb_helper_fbdev_setup]
> > *ERROR* fbdev: Failed to set configuration (ret=-38)
> > [ 50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for
> > :00:02.0 on minor 2
> > [ 50.013604] WARNING: CPU: 1 PID: 1 at
> > drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0
> > [ 50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G
> > T 4.20.0-rc7 #1
> > [ 50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0
> > ...
> > [ 50.023155] Call Trace:
> > [ 50.023155] ? bochs_kms_fini+0x1e/0x30
> > [ 50.023155] ? bochs_unload+0x18/0x40
> >
> > This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n.
> >
> > Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian
> > Link: https://lkml.kernel.org/r/20181223004315.GA11455@al
> > Fixes: 8741216396b2 ("drm/fb-helper: Add
> > drm_fb_helper_fbdev_setup/teardown()")
> > Reported-by: kernel test robot
> > Cc: Noralf Trønnes
> > Signed-off-by: Peter Wu
> > ---
> > drivers/gpu/drm/drm_fb_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 9d64f874f965..432e0f3b9267 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -2860,7 +2860,7 @@ int drm_fb_helper_fbdev_setup(struct drm_device *dev,
> > return 0;
> > err_drm_fb_helper_fini:
> > - drm_fb_helper_fini(fb_helper);
> > + drm_fb_helper_fbdev_teardown(dev);
>
> This change will break the error path for drm_fbdev_generic_setup()
> because drm_fb_helper_generic_probe() cleans up on error but doesn't
> clear drm_fb_helper->fb resulting in a double drm_framebuffer_remove().
This should probably considered a bug of drm_fb_helper_generic_probe.
Ownership of fb_helper should remain with the caller. The caller can
detect an error and act accordingly.
> My assumption has been that the drm_fb_helper_funcs->fb_probe callback
> cleans up its resources on error. Clearly this is not the case for bochs, so
> my take on this is that bochsfb_create() needs to clean up on error.
That assumption still holds for bochs. The problem is this sequence:
- drm_fb_helper_fbdev_setup is called.
- fb_probe succeeds (this is crucial).
- register_framebuffer fails.
- error path of setup is triggered.
As fb_helper is fully setup by drivers, the drm_fb_helper core should
fully deallocate it again on the error path or else a leak occurs.
> Gerd has a patchset that switches bochs over to the generic fbdev
> emulation, but ofc that doesn't help with 4.20:
> https://patchwork.freedesktop.org/series/54269/
And that does not help with other users of the drm_fb_helper who use
functions like drm_fb_helper_defio_init. They will likely run in the
same problem.
I don't have a way to test tinydrm or other drivers, but if you force
register_framebuffer to fail, you should be able to reproduce the
problem with drm_fb_helper_generic_probe.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported
https://bugs.freedesktop.org/show_bug.cgi?id=109135 --- Comment #2 from rmuncr...@humanavance.com --- Ooops, I accidentally overwrote the log from linux-amd-wip-git with a later failed test with 4.20.0-rc7-mainline, so the bad log I attached is for 4.20.0-rc7-mainline. However as I said before it's been the same error all along for all kernels from 4.19.x on. I'll recompile linux-amd-wip-git and get log from their if anyone needs it though. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: Revert syncobj timeline changes.
On 21.12.2018 21:27, Christian König wrote:
> Am 19.12.18 um 18:53 schrieb Dmitry Osipenko:
>> [SNIP]
>>> @@ -931,9 +718,6 @@ static signed long
>>> drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
>>> if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) {
>>> for (i = 0; i < count; ++i) {
>>> - if (entries[i].fence)
>>> - continue;
>>> -
>>> drm_syncobj_fence_get_or_add_callback(syncobjs[i],
>>> &entries[i].fence,
>>> &entries[i].syncobj_cb,
>> Hello,
>>
>> The above three removed lines we added in commit 337fe9f5c1e7de
>> ("drm/syncobj: Don't leak fences when WAIT_FOR_SUBMIT is set") that fixed a
>> memleak. Removal of the lines returns the memleak because of disbalanced
>> fence refcounting and it looks like they were removed unintentionally in
>> this patch.
>
> That was already fixed with 61a98b1b9a8c7 drm/syncobj: remove drm_syncobj_cb
> and cleanup.
>
> This cleanup removed all the duplicate checking and is now adding the
> callback only once.
Okay, though that commit is not in linux-next. I assume it will show up
eventually.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: offb: Pass actual name in offb_init_palette_hacks
Patch is far from perfect but was tested also by: Elimar Riesebieter
riese...@lxtec.de
Le jeu. 20 déc. 2018 17:10, Mathieu Malaterre a écrit :
> Rob, any comment ?
>
> On Fri, Dec 7, 2018 at 1:59 PM Mathieu Malaterre wrote:
> >
> > This is a partial revert of commit 5c63e407aaab ("fbdev: Convert to
> > using %pOFn instead of device_node.name"). This is the minimal work to
> > get a Mac Mini G4 back to a bootable state. The function
> > offb_init_palette_hacks would need to handle the case where `name` has
> > been set to NULL.
> >
> > Cc: Rob Herring
> > Fixes: 5c63e407aaab ("fbdev: Convert to using %pOFn instead of
> device_node.name")
> > Cc: sta...@vger.kernel.org # v4.19+
> > Signed-off-by: Mathieu Malaterre
> > ---
> > drivers/video/fbdev/offb.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
> > index 31f769d67195..6e75851f8142 100644
> > --- a/drivers/video/fbdev/offb.c
> > +++ b/drivers/video/fbdev/offb.c
> > @@ -648,7 +648,7 @@ static void __init offb_init_nodriver(struct
> device_node *dp, int no_real_node)
> > /* kludge for valkyrie */
> > if (strcmp(dp->name, "valkyrie") == 0)
> > address += 0x1000;
> > - offb_init_fb(no_real_node ? "bootx" : NULL,
> > + offb_init_fb(no_real_node ? "bootx" : dp->name,
> > width, height, depth, pitch, address,
> > foreign_endian, no_real_node ? NULL : dp);
> > }
> > --
> > 2.19.2
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/powerplay/polaris10_smumgr: Remove duplicate
Remove ppatomctrl.h which is included more than once Signed-off-by: Brajeswar Ghosh --- drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c index 872d3824337b..2b2c26616902 100644 --- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c +++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c @@ -44,7 +44,6 @@ #include "smu7_hwmgr.h" #include "hardwaremanager.h" -#include "ppatomctrl.h" #include "atombios.h" #include "pppcielanes.h" -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/psr: simplify enable_psr handling
The following commit:
commit 2bdd045e3a30 ("drm/i915/psr: Check if VBT says PSR can be enabled.")
added some code with no usable functionality. Regardless of how the psr
default is set up in the BDB_DRIVER_FEATURES section, if the enable_psr
module parameter isn't specified it defaults to 0.
Remove this dead code, simplify the way that enable_psr is handled and
update the module parameter string to match the actual functionality.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: Ross Zwisler
---
drivers/gpu/drm/i915/i915_drv.h| 1 -
drivers/gpu/drm/i915/i915_params.c | 4 +---
drivers/gpu/drm/i915/i915_params.h | 2 +-
drivers/gpu/drm/i915/intel_bios.c | 1 -
drivers/gpu/drm/i915/intel_psr.c | 7 ---
5 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 872a2e159a5f9..b4c50ba0b22a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1115,7 +1115,6 @@ struct intel_vbt_data {
} edp;
struct {
- bool enable;
bool full_link;
bool require_aux_wakeup;
int idle_frames;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 295e981e4a398..80ce8758c3c69 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -87,9 +87,7 @@ i915_param_named_unsafe(enable_ppgtt, int, 0400,
"(-1=auto [default], 0=disabled, 1=aliasing, 2=full, 3=full with
extended address space)");
i915_param_named_unsafe(enable_psr, int, 0600,
- "Enable PSR "
- "(0=disabled, 1=enabled) "
- "Default: -1 (use per-chip default)");
+ "Enable PSR (default: false)");
i915_param_named_unsafe(alpha_support, bool, 0400,
"Enable alpha quality driver support for latest hardware. "
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 6c4d4a21474b5..144572f17a83d 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -42,7 +42,7 @@ struct drm_printer;
param(int, enable_dc, -1) \
param(int, enable_fbc, -1) \
param(int, enable_ppgtt, -1) \
- param(int, enable_psr, -1) \
+ param(int, enable_psr, 0) \
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 1faa494e2bc91..d676d483d5cf1 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -551,7 +551,6 @@ parse_driver_features(struct drm_i915_private *dev_priv,
*/
if (!driver->drrs_enabled)
dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
- dev_priv->vbt.psr.enable = driver->psr_enabled;
}
static void
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index b6838b525502e..26e7eb318cf07 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -1065,13 +1065,6 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
if (!dev_priv->psr.sink_support)
return;
- if (i915_modparams.enable_psr == -1) {
- i915_modparams.enable_psr = dev_priv->vbt.psr.enable;
-
- /* Per platform default: all disabled. */
- i915_modparams.enable_psr = 0;
- }
-
/* Set link_standby x link_off defaults */
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
/* HSW and BDW require workarounds that we don't implement. */
--
2.20.1.415.g653613c723-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/amd: validate user GEM object size
When creating frame buffer, userspace may request to attach to a
previously allocated GEM object that is smaller than what GPU
requires. Validation must be done to prevent out-of-bound DMA,
which could not only corrupt memory but also reveal sensitive data.
This fix is not done in a common code path because individual
driver might have different requirement.
Cc: sta...@vger.kernel.org # v4.2+
Signed-off-by: Yu Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 883a4df2386d..a58fb8e021c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -527,6 +527,7 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
struct drm_gem_object *obj;
struct amdgpu_framebuffer *amdgpu_fb;
int ret;
+ int height;
struct amdgpu_device *adev = dev->dev_private;
int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
int pitch = amdgpu_align_pitch(adev, mode_cmd->pitches[0], cpp, false);
@@ -550,6 +551,13 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
return ERR_PTR(-EINVAL);
}
+ height = ALIGN(mode_cmd->height, 8);
+ if (obj->size < pitch * height) {
+ DRM_DEBUG_KMS("Invalid GEM size: expecting >= %d but got %zu\n",
+ pitch * height, obj->size);
+ return ERR_PTR(-EINVAL);
+ }
+
amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL);
if (amdgpu_fb == NULL) {
drm_gem_object_put_unlocked(obj);
--
2.20.1.415.g653613c723-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/amd: validate user pitch alignment
On Fri, Dec 21, 2018 at 10:07:26AM +0100, Michel Dänzer wrote: > On 2018-12-21 4:10 a.m., Yu Zhao wrote: > > Userspace may request pitch alignment that is not supported by GPU. > > Some requests 32, but GPU ignores it and uses default 64 when cpp is > > 4. If GEM object is allocated based on the smaller alignment, GPU > > DMA will go out of bound. > > > > For GPU that does frame buffer compression, DMA writing out of bound > > memory will cause memory corruption. > > > > Signed-off-by: Yu Zhao > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > index e309d26170db..755daa332f8a 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > @@ -527,6 +527,15 @@ amdgpu_display_user_framebuffer_create(struct > > drm_device *dev, > > struct drm_gem_object *obj; > > struct amdgpu_framebuffer *amdgpu_fb; > > int ret; > > + struct amdgpu_device *adev = dev->dev_private; > > + int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0); > > + int pitch = amdgpu_align_pitch(adev, mode_cmd->width, cpp, false); > > Also, this needs to use mode_cmd->pitches[0] instead of mode_cmd->width, > otherwise it'll spuriously fail for larger but well-aligned pitches. Good point, thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] drm/amd: validate user pitch alignment
Userspace may request pitch alignment that is not supported by GPU.
Some requests 32, but GPU ignores it and uses default 64 when cpp is
4. If GEM object is allocated based on the smaller alignment, GPU
DMA will go out of bound.
For GPU that does frame buffer compression, DMA writing out of bound
memory will cause memory corruption.
Cc: sta...@vger.kernel.org # v4.2+
Signed-off-by: Yu Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 686a26de50f9..883a4df2386d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -527,6 +527,15 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
struct drm_gem_object *obj;
struct amdgpu_framebuffer *amdgpu_fb;
int ret;
+ struct amdgpu_device *adev = dev->dev_private;
+ int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
+ int pitch = amdgpu_align_pitch(adev, mode_cmd->pitches[0], cpp, false);
+
+ if (mode_cmd->pitches[0] != pitch) {
+ DRM_DEBUG_KMS("Invalid pitch: expecting %d but got %d\n",
+ pitch, mode_cmd->pitches[0]);
+ return ERR_PTR(-EINVAL);
+ }
obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
if (obj == NULL) {
--
2.20.1.415.g653613c723-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/amd: validate user pitch alignment
Userspace may request pitch alignment that is not supported by GPU.
Some requests 32, but GPU ignores it and uses default 64 when cpp is
4. If GEM object is allocated based on the smaller alignment, GPU
DMA will go out of bound.
For GPU that does frame buffer compression, DMA writing out of bound
memory will cause memory corruption.
Signed-off-by: Yu Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 686a26de50f9..883a4df2386d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -527,6 +527,15 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
struct drm_gem_object *obj;
struct amdgpu_framebuffer *amdgpu_fb;
int ret;
+ struct amdgpu_device *adev = dev->dev_private;
+ int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
+ int pitch = amdgpu_align_pitch(adev, mode_cmd->pitches[0], cpp, false);
+
+ if (mode_cmd->pitches[0] != pitch) {
+ DRM_DEBUG_KMS("Invalid pitch: expecting %d but got %d\n",
+ pitch, mode_cmd->pitches[0]);
+ return ERR_PTR(-EINVAL);
+ }
obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
if (obj == NULL) {
--
2.20.1.415.g653613c723-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: Revert syncobj timeline changes.
On 21.12.2018 21:45, Koenig, Christian wrote:
> Am 21.12.18 um 19:35 schrieb Dmitry Osipenko:
>> On 21.12.2018 21:27, Christian König wrote:
>>> Am 19.12.18 um 18:53 schrieb Dmitry Osipenko:
[SNIP]
> @@ -931,9 +718,6 @@ static signed long
> drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
> if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) {
> for (i = 0; i < count; ++i) {
> - if (entries[i].fence)
> - continue;
> -
> drm_syncobj_fence_get_or_add_callback(syncobjs[i],
> &entries[i].fence,
> &entries[i].syncobj_cb,
Hello,
The above three removed lines we added in commit 337fe9f5c1e7de
("drm/syncobj: Don't leak fences when WAIT_FOR_SUBMIT is set") that fixed
a memleak. Removal of the lines returns the memleak because of disbalanced
fence refcounting and it looks like they were removed unintentionally in
this patch.
>>> That was already fixed with 61a98b1b9a8c7 drm/syncobj: remove
>>> drm_syncobj_cb and cleanup.
>>>
>>> This cleanup removed all the duplicate checking and is now adding the
>>> callback only once.
>> Okay, though that commit is not in linux-next. I assume it will show up
>> eventually.
>
> Need to double check, that could indeed be a problem.
Thanks for taking care!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: anx7808: fix a missing check of return value
Thanks for the tip! Will submit patch V2 soon.
On Thu, Dec 20, 2018 at 11:07 PM Laurent Pinchart <
laurent.pinch...@ideasonboard.com> wrote:
> Hi Kangjie,
>
> Thank you for the patch.
>
> On Thursday, 20 December 2018 09:41:16 EET Kangjie Lu wrote:
> > Both anx78xx_set_bits() and anx78xx_clear_bits() in the poweron process
> > may fail. The fix inserts checks for their return values. If the poweron
> > process fails, it calls anx78xx_poweroff().
> >
> > Signed-off-by: Kangjie Lu
> > ---
> > drivers/gpu/drm/bridge/analogix-anx78xx.c | 26 ---
> > 1 file changed, 18 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> > b/drivers/gpu/drm/bridge/analogix-anx78xx.c index
> > f8433c93f463..a57104c71739 100644
> > --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> > +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> > @@ -610,20 +610,20 @@ static int anx78xx_enable_interrupts(struct anx78xx
> > *anx78xx) return 0;
> > }
> >
> > -static void anx78xx_poweron(struct anx78xx *anx78xx)
> > +static int anx78xx_poweron(struct anx78xx *anx78xx)
> > {
> > struct anx78xx_platform_data *pdata = &anx78xx->pdata;
> > - int err;
> > + int err = 0;
> >
> > if (WARN_ON(anx78xx->powered))
> > - return;
> > + return err;
>
> You can return 0 here.
>
> >
> > if (pdata->dvdd10) {
> > err = regulator_enable(pdata->dvdd10);
> > if (err) {
> > DRM_ERROR("Failed to enable DVDD10 regulator:
> %d\n",
> > err);
> > - return;
> > + return err;
> > }
> >
> > usleep_range(1000, 2000);
> > @@ -638,12 +638,18 @@ static void anx78xx_poweron(struct anx78xx
> *anx78xx)
> > gpiod_set_value_cansleep(pdata->gpiod_reset, 0);
> >
> > /* Power on registers module */
> > - anx78xx_set_bits(anx78xx->map[I2C_IDX_TX_P2],
> SP_POWERDOWN_CTRL_REG,
> > + err = anx78xx_set_bits(anx78xx->map[I2C_IDX_TX_P2],
> SP_POWERDOWN_CTRL_REG,
> > SP_HDCP_PD | SP_AUDIO_PD | SP_VIDEO_PD | SP_LINK_PD);
> > - anx78xx_clear_bits(anx78xx->map[I2C_IDX_TX_P2],
> SP_POWERDOWN_CTRL_REG,
> > + err |= anx78xx_clear_bits(anx78xx->map[I2C_IDX_TX_P2],
> > SP_POWERDOWN_CTRL_REG, SP_REGISTER_PD | SP_TOTAL_PD);
>
> If both functions fail with a different error code, this may result in a
> meaningless error being returned. One option is to do
>
> err = anx78xx_set_bits(...);
> if (!err)
> err = anx78xx_clear_bits(...);
>
> The construct gets quickly ugly though, so I sometimes define register
> accessors as taking an int * for the error code instead of returning it.
>
> void write(..., int *status)
> {
> if (*status)
> return;
>
> *status = real_write(...);
> }
>
> and then use it as
>
> int status = 0;
>
> write(..., &status);
> write(..., &status);
> write(..., &status);
> write(..., &status);
> write(..., &status);
>
> return status;
>
> This may be overkill here.
>
> > + if (err) {
> > + anx78xx_poweroff(anx78xx);
> > + return err;
> > + }
> >
> > anx78xx->powered = true;
> > +
> > + return err;
>
> And return 0 here too, removing the need to initialize the err variable to
> 0.
>
> > }
> >
> > static void anx78xx_poweroff(struct anx78xx *anx78xx)
> > @@ -1144,7 +1150,9 @@ static irqreturn_t anx78xx_hpd_threaded_handler(int
> > irq, void *data) mutex_lock(&anx78xx->lock);
> >
> > /* Cable is pulled, power on the chip */
> > - anx78xx_poweron(anx78xx);
> > + err = anx78xx_poweron(anx78xx);
> > + if (err)
> > + DRM_ERROR("Failed to power on the chip: %d\n", err);
>
> Wouldn't it be better to move the error message to the an78xx_poweron()
> function ? That way it would also be printed in the probe() path.
>
> > err = anx78xx_enable_interrupts(anx78xx);
> > if (err)
> > @@ -1379,7 +1387,9 @@ static int anx78xx_i2c_probe(struct i2c_client
> > *client, }
> >
> > /* Look for supported chip ID */
> > - anx78xx_poweron(anx78xx);
> > + err = anx78xx_poweron(anx78xx);
> > + if (err)
> > + goto err_poweroff;
>
> If poweron fails, doesn't it clean up after itself ? Do you need to call
> poweroff here ?
>
> > err = regmap_read(anx78xx->map[I2C_IDX_TX_P2], SP_DEVICE_IDL_REG,
> > &idl);
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
>
--
Kangjie Lu
Assistant Professor
Department of Computer Science and Engineering
University of Minnesota
Personal homepage
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/psr: simplify enable_psr handling
On Fri, Dec 21, 2018 at 11:23:07AM -0800, Dhinakaran Pandiyan wrote:
> On Fri, 2018-12-21 at 10:23 -0700, Ross Zwisler wrote:
> > The following commit:
> >
> > commit 2bdd045e3a30 ("drm/i915/psr: Check if VBT says PSR can be
> > enabled.")
> >
> > added some code with no usable functionality. Regardless of how the
> > psr
> > default is set up in the BDB_DRIVER_FEATURES section, if the
> > enable_psr
> > module parameter isn't specified it defaults to 0.
> Right, that was intentional and the commit message even makes a note of
> it
> " Note: The feature currently remains disabled by default for all
> platforms irrespective of what VBT says."
>
>
> Anyway, we've enabled the feature by default now and the current code
> should take into account the VBT flag if the module parameter is left
> to a default value. Please check git://anongit.freedesktop.org/drm-tip
> drm-tip.
Fair enough. It's a bad pattern to introduce dead code as a placeholder for
some future work, though. This code has been in the tree for three major
kernel releases (v4.{18,19,20}) without providing any useful functionality.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Change to use DEFINE_SHOW_ATTRIBUTE macro
ping.. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/amd: validate user GEM object size
When creating frame buffer, userspace may request to attach to a
previously allocated GEM object that is smaller than what GPU
requires. Validation must be done to prevent out-of-bound DMA,
which could not only corrupt memory but also reveal sensitive data.
This fix is not done in a common code path because individual
driver might have different requirement.
Signed-off-by: Yu Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 883a4df2386d..098d6a816ee1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -527,6 +527,7 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
struct drm_gem_object *obj;
struct amdgpu_framebuffer *amdgpu_fb;
int ret;
+ int height;
struct amdgpu_device *adev = dev->dev_private;
int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
int pitch = amdgpu_align_pitch(adev, mode_cmd->pitches[0], cpp, false);
@@ -550,6 +551,13 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
return ERR_PTR(-EINVAL);
}
+ height = ALIGN(mode_cmd->height, 8);
+ if (obj->size < pitch * height) {
+ DRM_DEBUG_KMS("Invalid GEM size: expecting >= %d but got %ld\n",
+ pitch * height, obj->size);
+ return ERR_PTR(-EINVAL);
+ }
+
amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL);
if (amdgpu_fb == NULL) {
drm_gem_object_put_unlocked(obj);
--
2.20.1.415.g653613c723-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/powerplay: Remove duplicate header
On Fri, Dec 21, 2018 at 2:49 PM Brajeswar Ghosh wrote: > > Remove hwmgr_ppt.h which is included more than once > > Signed-off-by: Brajeswar Ghosh > --- Acked-by: Souptick Joarder > drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > index e5a60aa44b5d..07d180ce4d18 100644 > --- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > +++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > @@ -28,7 +28,6 @@ > #include "hardwaremanager.h" > #include "hwmgr_ppt.h" > #include "ppatomctrl.h" > -#include "hwmgr_ppt.h" > #include "power_state.h" > #include "smu_helper.h" > > -- > 2.17.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/11] vga-switcheroo: make PCI dependency explicit
On Sun, Dec 23, 2018 at 02:00:15AM +0300, Sinan Kaya wrote:
> On Sat, Dec 22, 2018 at 7:40 PM Lukas Wunner wrote:
> > On Sat, Dec 22, 2018 at 09:07:12AM +, Sinan Kaya wrote:
> > > This driver depends on the PCI infrastructure but the dependency has not
> > > been explicitly called out.
> > >
> > > Signed-off-by: Sinan Kaya
> > > Reviewed-by: Lukas Wunner
> >
> > This series doesn't have a cover letter so it's unclear to me through
> > which tree it's supposed to go in? Each patch through the individual
> > subsystem tree or all through the same tree? If the former I guess I
> > could push this to drm-misc...
>
> Feel free to apply individual patches independently. Let me know which
> one you applied so that I can drop them on the next rev.
I've realized only now that this patch fixes fallout of commit
5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
which is part of Rafael's acpi pull for v4.21.
Usually such fixes go through the same tree as the offending commit,
so I'd expect Raphael to pick up the whole series and forward it to
Linus in the second half of the merge window. I'm not sure if that's
how it'll play out though given the holidays.
Additionally, drm-misc is currently in a somewhat confusing state:
Normally fixes targeting v4.21 should have been applied to
drm-misc-next-fixes for the last 2 weeks, yet no new commits have
been applied to that branch since December 5, but plenty of stuff
that should have been applied (various fixes and a MAINTAINERS change)
went to drm-misc-next instead. So it looks like a lot of folks picked
the wrong branch and drm-misc-next is now a mix of v4.22 features and
v4.21 fixes. I think I should rather not add to this mess before a
drm-misc maintainer has had a chance to sort it out.
I'll be sure to keep an eye on this though. The fallout addressed by
the patch is mostly confined to randconfigs I think, so waiting a few
more days probably won't hurt much.
Thanks,
Lukas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109137] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vcn_enc0 timeout
https://bugs.freedesktop.org/show_bug.cgi?id=109137 Bug ID: 109137 Summary: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vcn_enc0 timeout Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: so...@web.de AMD Ryzen 5 2400G with Radeon Vega Graphics -> Always get a ring vcn-enc0 timeout when running the following command: /usr/bin/ffmpeg -init_hw_device vaapi=foo:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_device foo -hwaccel_output_format vaapi -i test.ts -filter_hw_device foo -vf 'format=nv12|vaapi,hwupload,deinterlace_vaapi=rate=field:auto=1' -c:v hevc_vaapi -b:v 3.5M -maxrate 4M -bufsize 1M -c:a copy -c:s copy -f mpegts test2.ts This error is reproducable (every attempt...). The converting is is always interrupted, sometimes seconds after start, sometimes minutes after start, it has never reached the end... More system details: [0.00] Linux version 4.19.11-041911-generic (kernel@kathleen) (gcc version 8.2.0 (Ubuntu 8.2.0-12ubuntu1)) #201812191931 SMP Wed Dec 19 19:33:33 UTC 2018 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.11-041911-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash amdgpu.dc=1 vt.handoff=1 [0.016008] smpboot: CPU0: AMD Ryzen 5 2400G with Radeon Vega Graphics (family: 0x17, model: 0x11, stepping: 0x0) [1.809423] [drm] initializing kernel modesetting (RAVEN 0x1002:0x15DD 0x1043:0x876B 0xC6). [1.809435] [drm] register mmio base: 0xFE50 [1.809435] [drm] register mmio size: 524288 [1.809451] [drm] add ip block number 0 [1.809451] [drm] add ip block number 1 [1.809452] [drm] add ip block number 2 [1.809452] [drm] add ip block number 3 [1.809453] [drm] add ip block number 4 [1.809454] [drm] add ip block number 5 [1.809455] [drm] add ip block number 6 [1.809455] [drm] add ip block number 7 [1.809456] [drm] add ip block number 8 [1.809491] [drm] VCN decode is enabled in VM mode [1.809491] [drm] VCN encode is enabled in VM mode [1.809491] [drm] VCN jpeg decode is enabled in VM mode [1.833266] [drm] BIOS signature incorrect 0 0 [1.833283] ATOM BIOS: 113-RAVEN-111 [1.833316] [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit [1.833322] amdgpu :06:00.0: VRAM: 2048M 0x00F4 - 0x00F47FFF (2048M used) [1.833323] amdgpu :06:00.0: GART: 1024M 0x00F5 - 0x00F53FFF [1.833326] [drm] Detected VRAM RAM=2048M, BAR=2048M [1.833327] [drm] RAM width 128bits DDR4 [1.833398] [TTM] Zone kernel: Available graphics memory: 3047728 kiB [1.833399] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [1.833399] [TTM] Initializing pool allocator [1.833402] [TTM] Initializing DMA pool allocator [1.833451] [drm] amdgpu: 2048M of VRAM memory ready [1.833452] [drm] amdgpu: 3072M of GTT memory ready. [1.833458] [drm] GART: num cpu pages 262144, num gpu pages 262144 [1.833622] [drm] PCIE GART of 1024M enabled (table at 0x00F40090). [1.834868] [drm] use_doorbell being set to: [true] [1.834980] [drm] Found VCN firmware Version: 1.73 Family ID: 18 [1.834983] [drm] PSP loading VCN firmware [2.032269] amdgpu: [powerplay] dpm has been enabled [2.032346] [drm] DM_PPLIB: values for Invalid clock [2.032347] [drm] DM_PPLIB: 40 in kHz [2.032347] [drm] DM_PPLIB: 933000 in kHz [2.032348] [drm] DM_PPLIB: 120 in kHz [2.032348] [drm] DM_PPLIB: 1333000 in kHz [2.032349] [drm] DM_PPLIB: values for Invalid clock [2.032349] [drm] DM_PPLIB: 30 in kHz [2.032350] [drm] DM_PPLIB: 60 in kHz [2.032350] [drm] DM_PPLIB: 626000 in kHz [2.032350] [drm] DM_PPLIB: 654000 in kHz [2.032579] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2! type 0 expected 3 [2.037825] [drm] Display Core initialized with v3.1.59! [2.038591] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [2.038591] [drm] Driver supports precise vblank timestamp query. [131543.720312] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vcn_enc0 timeout, signaled seq=3845, emitted seq=3846 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup
Den 23.12.2018 01.55, skrev Peter Wu:
After drm_fb_helper_fbdev_setup calls drm_fb_helper_init,
"dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will
have some effect). After that, drm_fb_helper_initial_config is called
which may call the "fb_probe" driver callback.
This driver callback may call drm_fb_helper_defio_init (as is done by
drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs)
as documented. These are normally cleaned up on exit by
drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini.
If an error occurs after "fb_probe", but before setup is complete, then
calling just drm_fb_helper_fini will leak resources. This was triggered
by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"):
[ 50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support this
framebuffer
[ 50.009436] bochs-drm :00:02.0: [drm:drm_fb_helper_fbdev_setup]
*ERROR* fbdev: Failed to set configuration (ret=-38)
[ 50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for :00:02.0
on minor 2
[ 50.013604] WARNING: CPU: 1 PID: 1 at
drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0
[ 50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GT
4.20.0-rc7 #1
[ 50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0
...
[ 50.023155] Call Trace:
[ 50.023155] ? bochs_kms_fini+0x1e/0x30
[ 50.023155] ? bochs_unload+0x18/0x40
This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n.
Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian
Link: https://lkml.kernel.org/r/20181223004315.GA11455@al
Fixes: 8741216396b2 ("drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()")
Reported-by: kernel test robot
Cc: Noralf Trønnes
Signed-off-by: Peter Wu
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9d64f874f965..432e0f3b9267 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2860,7 +2860,7 @@ int drm_fb_helper_fbdev_setup(struct drm_device *dev,
return 0;
err_drm_fb_helper_fini:
- drm_fb_helper_fini(fb_helper);
+ drm_fb_helper_fbdev_teardown(dev);
This change will break the error path for drm_fbdev_generic_setup()
because drm_fb_helper_generic_probe() cleans up on error but doesn't
clear drm_fb_helper->fb resulting in a double drm_framebuffer_remove().
My assumption has been that the drm_fb_helper_funcs->fb_probe callback
cleans up its resources on error. Clearly this is not the case for
bochs, so my take on this is that bochsfb_create() needs to clean up on
error.
Gerd has a patchset that switches bochs over to the generic fbdev
emulation, but ofc that doesn't help with 4.20:
https://patchwork.freedesktop.org/series/54269/
Noralf.
return ret;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Expose more EDID fields to userspace
Hi all,
Right now, the kernel parses EDIDs and exposes some of the data to
userspace. For instance, drmModeConnector has mm{Width,Height} and
subpixel.
Generally, userspace also has another EDID parser. For instance,
wlroots uses it just to get the make/model/serial. I've talked about
this at XDC 2018, and someone mentioned it could be a good idea to
de-duplicate the work.
Would it be reasonable to expose those as DRM connector properties?
Thanks,
--
Simon Ser
https://emersion.fr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108940] QHD bug? drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1613 core_link_enable_stream+0xc14/0x1040
https://bugs.freedesktop.org/show_bug.cgi?id=108940 --- Comment #12 from Stefan --- Created attachment 142876 --> https://bugs.freedesktop.org/attachment.cgi?id=142876&action=edit 4.20.0-rc3-amd-staging-drm-next-git-b8cd95e15410+ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108940] QHD bug? drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1613 core_link_enable_stream+0xc14/0x1040
https://bugs.freedesktop.org/show_bug.cgi?id=108940 --- Comment #11 from Stefan --- I just tried with amd-staging-drm-next. The error is still present. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
