Am 25.01.21 um 04:27 schrieb Tian Tao:
fixed the below warning:
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check
before some freeing functions is not needed.
Signed-off-by: Tian Tao
Acked-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 +--
On Thu, 21 Jan 2021 at 18:27, Christian König wrote:
>
> I still have no idea what's going on here.
>
> The KASAN messages from the DC code are completely unrelated.
>
> Please add the full dmesg to your bug report.
>
I did it.
https://gitlab.freedesktop.org/drm/amd/-/issues/1439#note_776267
--
[AMD Public Use]
The link error has been fixed by:
5da047444e82 drm/amd/display: fix 64-bit division issue on 32-bit OS
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Randy Dunlap
Sent: Saturday, January 23, 2021 2:02 AM
To: Stephen Rothwell ; Linux Next Mailing List
C
On Fri, Jan 22, 2021 at 11:00:22PM +0800, Colin King wrote:
> From: Colin Ian King
>
> Currently the ! operator is incorrectly being used to flip bits on
> mask values. Fix this by using the bit-wise ~ operator instead.
>
> Addresses-Coverity: ("Logical vs. bitwise operator")
> Fixes: 3c9a7b7d6e
On 2021-01-21 2:05 p.m., Kazlauskas, Nicholas wrote:
On 2021-01-19 10:50 a.m., Aurabindo Pillai wrote:
[Why]
A seamless transition between modes can be performed if the new incoming
mode has the same timing parameters as the optimized mode on a display
with a
variable vtotal min/max.
Smooth
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/gem/i915_gem_object.h
between commit:
41a9c75d0acf ("drm/i915/gem: Move stolen node into GEM object union")
from the drm tree and commit:
5fbc2c2bfa5c ("drm/i915/gem: Add a helper to read data
https://bugzilla.kernel.org/show_bug.cgi?id=201497
--- Comment #22 from Jay Tuckey (jay@tuckey.email) ---
@Sebastien that could well be the case. The screen works fine under windows,
but it could be that they are working around bad EDID data?
Is there any way I can validate if the EDID is bad?
-
https://bugzilla.kernel.org/show_bug.cgi?id=201497
--- Comment #21 from Sebastien Bernard (sbern...@nerim.net) ---
The more I think about it,
the more it seems to be related only to this monitor.
I think the 4.19 kernel closed a bug and is rejectiting the EDID reported by
this screen.
If someone
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #42 from MajorGonzo (majorgo...@juno.com) ---
I made a change a while back. I added:
amdgpu.gpu_recovery=1
as a grub parameter. I have no other (of the many suggested) parameters set:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amdgpu.
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #41 from Panagiotis Polychronis (panospolychro...@gmail.com) ---
(In reply to j.cordoba from comment #40)
> (In reply to Randune from comment #39)
> > There doesn't appear to be any progress on this bug, does anyone have any
> > sugges
On Thu, 21 Jan 2021 15:14:18 +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qxp/qm Display Processing Unit.
>
> Signed-off-by: Liu Ying
> ---
> v5->v6:
> * Use graph schema. So, drop Rob's R-b tag as review is needed.
>
> v4->v5:
> * No change.
>
> v3->v4:
> * Improve compatible pro
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #40 from j.cordoba (j.cord...@gmx.net) ---
(In reply to Randune from comment #39)
> There doesn't appear to be any progress on this bug, does anyone have any
> suggestions with regards on how to fix this issue?
Try to add iommu=pt as
On Sun, Jan 24, 2021 at 9:24 PM Simon Ser wrote:
> On Sunday, January 24th, 2021 at 9:10 PM, Mario Kleiner <
> mario.kleiner...@gmail.com> wrote:
>
> > But it still needs to be fixed if we want working HDR. I thought
> > libdrm copies the definitions from the kernel periodically, so the
> > fix s
Den 24.01.2021 19.38, skrev Lubomir Rintel:
> On Wed, Jan 20, 2021 at 06:00:30PM +0100, Noralf Trønnes wrote:
>> Hi,
>>
>> A while back I had the idea to turn a Raspberry Pi Zero into a $5
>> USB to HDMI/SDTV/DSI/DPI display adapter.
>>
>> The reason for calling it 'Generic' is so anyone can make
The check was introduced to make sure that only the
DRM_FORMAT_MOD_LINEAR modifier is accepted by tinydrm.
However, if .format_mod_supported is not hooked up to
drm_simple_kms_format_mod_supported then the core will
simply validate modifiers against the format_modifiers
list passed into drm_simple
On Sunday, January 24th, 2021 at 9:10 PM, Mario Kleiner
wrote:
> But it still needs to be fixed if we want working HDR. I thought
> libdrm copies the definitions from the kernel periodically, so the
> fix should propagate?
There will always be user-space that sends 1 instead of 0. This
shouldn'
On Sun, Jan 24, 2021 at 9:15 AM Simon Ser wrote:
> On Sunday, January 24th, 2021 at 5:40 AM, Mario Kleiner <
> mario.kleiner...@gmail.com> wrote:
>
> > According to the CTA 861.G spec, HDMI_STATIC_METADATA_TYPE1 is
> > not 1, but zero, so fix this enum.
> >
> > While this doesn't cause problems i
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #39 from Randune (randyk...@gmail.com) ---
There doesn't appear to be any progress on this bug, does anyone have any
suggestions with regards on how to fix this issue?
--
You may reply to this email to add a comment.
You are receivi
https://bugzilla.kernel.org/show_bug.cgi?id=211277
Jerome C (m...@jeromec.com) changed:
What|Removed |Added
CC||m...@jeromec.com
--- Commen
Den 20.01.2021 19.02, skrev Daniel Vetter:
> On Wed, Jan 20, 2021 at 6:11 PM Noralf Trønnes wrote:
>>
>> This adds a generic USB display driver with the intention that it can be
>> used with future USB interfaced low end displays/adapters. The Linux
>> gadget device driver will serve as the cano
This is a note to let you know that I've just added the patch titled
drm/syncobj: Fix use-after-free
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-syncobj-fix-use-aft
This is a note to let you know that I've just added the patch titled
drm/syncobj: Fix use-after-free
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-syncobj-fix-use-afte
Hi Nikolaus,
Le dim. 24 janv. 2021 à 10:30, H. Nikolaus Schaller
a écrit :
Hi Paul,
we observed the same issue on the jz4730 (which is almost identical
to the jz4740 wrt. LCDC) and our solution [1] was simpler.
It leaves the hwdesc f0 and f1 as they are and just takes f1 for
really
programm
Hi,
Here are three independent fixes. The first one addresses a
use-after-free in bridge/panel.c; the second one addresses a
use-after-free in the ingenic-drm driver; finally, the third one makes
the ingenic-drm driver work again on older Ingenic SoCs.
Changes from v2:
- patch [1/4] added a FIXME
On Wed, Jan 20, 2021 at 06:00:30PM +0100, Noralf Trønnes wrote:
> Hi,
>
> A while back I had the idea to turn a Raspberry Pi Zero into a $5
> USB to HDMI/SDTV/DSI/DPI display adapter.
>
> The reason for calling it 'Generic' is so anyone can make a USB
> display/adapter against this driver, all th
Even though the JZ4740 did not have the OSD mode, it had (according to
the documentation) two DMA channels, but there is absolutely no
information about how to select the second DMA channel.
Make the ingenic-drm driver work in non-OSD mode by using the
foreground0 plane (which is bound to the DMA0
Since the encoders have been devm-allocated, they will be freed way
before drm_mode_config_cleanup() is called. To avoid use-after-free
conditions, we then must ensure that drm_encoder_cleanup() is called
before the encoders are freed.
v2: Use the new __drmm_simple_encoder_alloc() function
v3: Us
Hi Paul,
> Am 24.01.2021 um 10:43 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
> Le dim. 24 janv. 2021 à 10:30, H. Nikolaus Schaller a
> écrit :
>> Hi Paul,
>> we observed the same issue on the jz4730 (which is almost identical
>> to the jz4740 wrt. LCDC) and our solution [1] was simpler.
>> It
Hi Paul,
we observed the same issue on the jz4730 (which is almost identical
to the jz4740 wrt. LCDC) and our solution [1] was simpler.
It leaves the hwdesc f0 and f1 as they are and just takes f1 for really
programming the first DMA descriptor if there is no OSD.
We have tested on jz4730 and jz4
This performs the same operation as drmm_simple_encoder_alloc(), but
only allocates and returns a struct drm_encoder instance.
Signed-off-by: Paul Cercueil
---
include/drm/drm_simple_kms_helper.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/drm/drm_simple_kms_he
If we don't call drm_connector_cleanup() manually in
panel_bridge_detach(), the connector will be cleaned up with the other
DRM objects in the call to drm_mode_config_cleanup(). However, since our
drm_connector is devm-allocated, by the time drm_mode_config_cleanup()
will be called, our connector w
From: Emil Renner Berthing
This converts the driver to use the new tasklet API introduced in
commit 12cc923f1ccc ("tasklet: Introduce new initialization API")
Signed-off-by: Emil Renner Berthing
---
Tested on my Dell XPS 13 9300.
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +--
driver
From: Lucas Nussbaum
Subject: Re: [PATCH 2/2] drm/vc4: Correct POS1_SCL for hvs5
Date: Sat, 23 Jan 2021 09:05:48 +0100
> On 21/01/21 at 11:57 +0100, Maxime Ripard wrote:
>> From: Dom Cobley
>>
>> Fixes failure with 4096x1080 resolutions
>>
>> [ 284.315379] WARNING: CPU: 1 PID: 901 at
>> driv
https://bugzilla.kernel.org/show_bug.cgi?id=209713
--- Comment #11 from Oliver Reeh (oli...@diereehs.de) ---
The problem is back with kernel 5.10.10.
[ 89.664494] WARNING: CPU: 6 PID: 4323 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_link_encoder.c:483
dcn10_get_dig_frontend+0x94/0xc
On Sunday, January 24th, 2021 at 5:40 AM, Mario Kleiner
wrote:
> According to the CTA 861.G spec, HDMI_STATIC_METADATA_TYPE1 is
> not 1, but zero, so fix this enum.
>
> While this doesn't cause problems in the kernel yet, as the
> constant isn't actively used by drivers yet, it did create
> conf
35 matches
Mail list logo
