https://bugzilla.kernel.org/show_bug.cgi?id=205497
--- Comment #14 from Trek (tre...@inbox.ru) ---
(In reply to Alex Deucher from comment #11)
> If you access the BAR directly you will likely have problems in certain
> power saving modes.
thank you, I'll add a warning message when accessing BAR
https://bugzilla.kernel.org/show_bug.cgi?id=205497
--- Comment #13 from Luya Tshimbalanga (l...@fedoraproject.org) ---
(In reply to Alex Deucher from comment #11)
> (In reply to Trek from comment #7)
> > by default, radeontop calls amdgpu_read_mm_registers, amdgpu_query_info and
> >
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #28 from MasterCATZ (masterc...@hotmail.com) ---
hmm maybe not
it lets me briefly access manual
Found the following PWM controls:
hwmon1/pwm1 current value: 68
hwmon1/pwm1 is currently setup for automatic speed
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #27 from MasterCATZ (masterc...@hotmail.com) ---
pwmconfig
seems to be the only thing that allows me to get manual mode back on
I wounder if this is the actual program giving grieve
--
You are receiving this mail because:
You are
Hi all,
Commit
b4011644b03c ("drm/vmwgfx: remove set but not used variable 'srf'")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpCwR7wqyTYm.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
On 2019-11-11 9:58 a.m., Christian König wrote:
This patch reworks the whole delayed deletion of BOs which aren't idle.
Instead of having two counters for the BO structure we resurrect the BO
when we find that a deleted BO is not idle yet.
This has many advantages, especially that we don't
The subject doesn't match the change. This changes ttm_bo_cleanup_refs,
not ttm_buffer_object_transfer.
On 2019-11-11 9:58 a.m., Christian König wrote:
The function is always called with deleted BOs.
While at it cleanup the indentation as well.
Signed-off-by: Christian König
---
On 2019-11-13 10:20 p.m., zhengbin wrote:
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c: In function kfd_iommu_device_init:
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c:65:30: warning: variable top_dev set but
not used [-Wunused-but-set-variable]
Reported-by:
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #232 from viste.sylv...@gmail.com ---
(In reply to Sander Lienaerts from comment #231)
> Been following this thread for a while now. Can't believe this has been
> known for 3 months, without a fix released.
>
> Just a moment ago a
https://bugs.freedesktop.org/show_bug.cgi?id=112266
--- Comment #8 from rLy ---
(In reply to Alex Deucher from comment #6)
> Created attachment 145971 [details] [review]
> possible fix
>
> Does this patch help?
I tried it as well on 5.4-rc7 and fixed every game I mentioned(CS:GO, SOTTR,
Noticed this while working on some unrelated CRC stuff. Currently,
userspace has very little support for BPCs higher than 8. While this
doesn't matter for most things, on MST topologies we need to be careful
about ensuring that we do our best to make any given display
configuration fit within the
In order to be able to use bpc values that are different from what the
connector reports, we want to be able to store the bpc value we decide
on using for an atomic state in nv50_head_atom and refer to that instead
of simply using the value that the connector reports throughout the
whole atomic
Since nv50_outp_atomic_check_view() can set crtc_state->mode_changed, we
probably should be calling it before handling any PBN changes. Just a
precaution.
Signed-off-by: Lyude Paul
Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
Cc: Ben Skeggs
Cc: Daniel Vetter
Cc: David
Realized when I moved nouveau over to using the atomic DP MST VCPI
helpers that I forgot to ensure that we clamp the BPC to 8 to make us
less likely to run out of bandwidth on a topology when enabling multiple
displays that support >8 BPC - something we want to do until we have
support for
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Signed-off-by: Sean Paul
---
I need to step away from -misc to prioritize other work that I have on
my plate. It's been great fun (most of the time) and very rewarding
doing this job. I will really miss it!
I plan on
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #231 from Sander Lienaerts ---
Been following this thread for a while now. Can't believe this has been known
for 3 months, without a fix released.
Just a moment ago a random freeze occurred running Firefox and other
applications,
https://bugzilla.kernel.org/show_bug.cgi?id=205169
--- Comment #23 from ArneJ (kernelbug5...@arnej.de) ---
I just let Borderlands 2 run for about one hour in the menu which causes a hang
without this patch in at most 3 minutes.
Consider Borderlands 2 also fixed with this :)
--
You are
On Fri, Nov 15, 2019 at 10:27:04PM +0800, zhengbin wrote:
> zhengbin (3):
> drm/gma500: remove set but not used variable 'htotal'
> drm/gma500: remove set but not used variable 'error'
> drm/gma500: remove set but not used variable 'is_hdmi','is_crt'
All three applied, thanks for the
From: Ville Syrjälä
The early return in drm_atomic_set_mode_for_crtc() isn't quite
right. It would mistakenly return and fail to update
crtc_state->enable if someone actually tried to set a zeroed
mode on a currently disabled crtc. That should never actually
happen in response to any userspace
From: Ville Syrjälä
Currently setplane grabs all modeset locks, which seems a bit
excessive. Let's reduce that to just the locks we really need
on atomic drivers. For non-atomic drivers let's stick to the
current scheme for now.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c |
From: Ville Syrjälä
Test the basics of drm_atomic_set_mode_for_crtc(), and in particular
verify that the function doesn't take the shortcut incorrectly.
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/selftests/Makefile| 3 +-
From: Ville Syrjälä
Can't see why we need to delay the page flip event allocation until the
last moment. Move it earlier to simplify error handling.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 45 +++--
1 file changed, 23 insertions(+), 22
From: Ville Syrjälä
Yank out the code for the plane->fb/old_fb/crtc handling from
the page flip path into page_flip_internal(), and provide a
simpler variant for atomic drivers.
We'll also move the fb vs. src viewport checks into the new
functions as they are slightly different between the two
From: Ville Syrjälä
Instead of doing the things in a convoluted way with the failure and
success paths mixed up let's just clear old_fb when we encounter an
error and bail out immediately. We already did this for the pageflip
path.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c
From: Ville Syrjälä
I found this random pile of stuff lying around. Dusted it off
and tossed in the new selftests.
Ville Syrjälä (7):
drm: Move page_flip fb lookup earlier
drm: Allocate the page flip event earlier
drm: Extract page_flip_{internal,atomic}()
drm: Simplify the setplane
From: Ville Syrjälä
No reason that I can see to delay the fb lookup this late. Moving it
earlier allows us to keep it outside of the lock retry loop. This
makes error handling and whatnot simpler.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 29 +++--
On Fri, Nov 15, 2019 at 10:18:26AM +0100, Daniel Vetter wrote:
> On Fri, Nov 15, 2019 at 10:04 AM Jean Delvare wrote:
> >
> > Hi Chris,
> >
> > On Thu, 14 Nov 2019 20:44:13 +, Chris Wilson wrote:
> > > An old display with no audio may not have an EDID with a CEA block, or
> > > it may simply
On Tue, Nov 12, 2019 at 10:36:54AM +0100, Neil Armstrong wrote:
> On 12/11/2019 08:53, Wayne Lin wrote:
> > [Why]
> > In hdmi_mode_alternate_clock(), it adds an exception for VIC 4
> > mode (4096x2160@24) due to there is no alternate clock defined for
> > that mode in HDMI1.4b. But HDMI2.0 adds
On Tue, Nov 12, 2019 at 03:53:07PM +0800, Wayne Lin wrote:
> [Why]
> In hdmi_mode_alternate_clock(), it adds an exception for VIC 4
> mode (4096x2160@24) due to there is no alternate clock defined for
> that mode in HDMI1.4b. But HDMI2.0 adds 23.98Hz for that mode.
>
> [How]
> Remove the
On Tue, Nov 12, 2019 at 03:53:06PM +0800, Wayne Lin wrote:
> [Why]
> HDMI 2.0 adds aspect ratio attribute to distinguish different
> 4k modes. According to Appendix E of HDMI 2.0 spec, source should
> use VSIF to indicate video mode only when the mode is one defined
> in HDMI 1.4b 4K modes.
https://bugzilla.kernel.org/show_bug.cgi?id=205169
--- Comment #22 from Shmerl (shtetl...@gmail.com) ---
It fixes Pathfinder: Kingamer too. But first let the patch be upstreamed, then
it's OK to close the bug :)
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=205169
--- Comment #21 from Dmitri Seletski (drj...@gmail.com) ---
(In reply to Alex Deucher from comment #20)
> Created attachment 285935 [details]
> possible fix
>
> Does this patch help?
It did not just solve one problem, but two!
First of all it
https://bugs.freedesktop.org/show_bug.cgi?id=112266
--- Comment #7 from Shmerl ---
(In reply to Alex Deucher from comment #6)
> Created attachment 145971 [details] [review]
> possible fix
>
> Does this patch help?
Just applied that patch on on top of latest 5.4-rc7+ and tested it. It prevents
On Thu, Nov 14, 2019 at 09:53:25PM -0800, John Hubbard wrote:
> As it says in the updated comment in gup.c: current FOLL_LONGTERM
> behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> FS DAX check requirement on vmas.
>
> However, the corresponding restriction in
Reviewed-by: Lyude Paul
On Fri, 2019-11-15 at 21:42 +0800, zhengbin wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/nouveau/dispnv04/arb.c: In function nv04_calc_arb:
> drivers/gpu/drm/nouveau/dispnv04/arb.c:59:21: warning: variable pclks set
> but not used
Reviewed-by: Lyude Paul
On Fri, 2019-11-15 at 21:42 +0800, zhengbin wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_vram_manager_new:
> drivers/gpu/drm/nouveau/nouveau_ttm.c:66:22: warning: variable mem set but
> not used
The pull request you sent on Fri, 15 Nov 2019 11:18:16 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-11-15
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/37b49f31e800b563ed7a601816ea4b6fc3c5d165
Thank you!
--
Deet-doot-dot, I am a bot.
https://bugzilla.kernel.org/show_bug.cgi?id=205497
--- Comment #12 from V.I.S. (itemc...@mail.ru) ---
I need approx 3-5 days for testing, because this bug is not persistent.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi Dave, Daniel,
Misc fixes for 5.5.
The following changes since commit 53dbc27ad5a93932ff1892a8e4ef266827d74a0f:
drm/amdgpu/powerplay: fix AVFS handling with custom powerplay table
(2019-11-08 12:30:24 -0500)
are available in the Git repository at:
https://bugzilla.kernel.org/show_bug.cgi?id=205521
Luya Tshimbalanga (l...@fedoraproject.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=112266
--- Comment #6 from Alex Deucher ---
Created attachment 145971
--> https://bugs.freedesktop.org/attachment.cgi?id=145971=edit
possible fix
Does this patch help?
--
You are receiving this mail because:
You are the assignee for the
https://bugzilla.kernel.org/show_bug.cgi?id=205169
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=112290
Andre Klapper changed:
What|Removed |Added
Group||spam
Version|XOrg git
https://bugzilla.kernel.org/show_bug.cgi?id=205497
--- Comment #11 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Trek from comment #7)
> by default, radeontop calls amdgpu_read_mm_registers, amdgpu_query_info and
> amdgpu_query_sensor_info, but it can be forced by the command line to
On Tue, Nov 12, 2019 at 10:03 AM Daniel Vetter wrote:
>
> Hi all,
>
> Dave and me chatted about this last week on irc. Essentially we have:
>
> $ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/*c'
> drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0
>
On Fri, Nov 15, 2019 at 11:56 AM Gerd Hoffmann wrote:
>
> On Fri, Nov 15, 2019 at 11:18:28AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 15, 2019 at 10:37 AM Gerd Hoffmann wrote:
> > >
> > > > You need memory pressure, to force ttm to unmap the bo, not userspace.
> > > > So
> > > > roughly
> >
On Fri, Nov 15, 2019 at 1:44 PM Ville Syrjälä
wrote:
>
> On Fri, Nov 15, 2019 at 10:21:13AM +0100, Daniel Vetter wrote:
> > - Our limit is uint32_t, make that explicit.
> >
> > - Untangle the one overflow check, I think (but not sure) that with
> > all three together you could overflow the
https://bugs.freedesktop.org/show_bug.cgi?id=112288
--- Comment #12 from Alex Deucher ---
Does disabling the iommu help? Append iommu=off or iommu=pt to the kernel
command line.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=112297
--- Comment #1 from Daniel Suarez ---
Don't expect this to work anytime soon unfortunately. AMD really slacked off
with the drivers for this and similar bug reports have been open for months.
As for your work, save early, save often while
https://bugs.freedesktop.org/show_bug.cgi?id=112297
Daniel Suarez changed:
What|Removed |Added
Priority|not set |highest
--
You are receiving this
On Thu, Nov 14, 2019 at 9:05 PM Sam Bobroff wrote:
>
> The INTERRUPT_CNTL2 register expects a valid DMA address, but is
> currently set with a GPU MC address. This can cause problems on
> systems that detect the resulting DMA read from an invalid address
> (found on a Power8 guest).
>
> Instead,
Den 15.11.2019 13.34, skrev Ville Syrjälä:
> On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote:
>> Hi Daniel,
>>
>> I don't think we can make any complaints about GPL being more widely
>> used in the DRM code. It's nice to have the code at all, the MIT license
>> is a bonus. Thanks
On 15/11/2019 11:21, Daniel Vetter wrote:
> Doesn't do anything.
>
> Signed-off-by: Daniel Vetter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
Acked-by: Jyri Sarha
> ---
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git
On Fri, Nov 15, 2019 at 10:21:13AM +0100, Daniel Vetter wrote:
> - Our limit is uint32_t, make that explicit.
>
> - Untangle the one overflow check, I think (but not sure) that with
> all three together you could overflow the uint64_t and it'd look
> cool again.
It can't overflow. All theree
On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote:
> Hi Daniel,
>
> I don't think we can make any complaints about GPL being more widely
> used in the DRM code. It's nice to have the code at all, the MIT license
> is a bonus. Thanks for writing it and bearing with us.
>
> Would
https://bugs.freedesktop.org/show_bug.cgi?id=112297
David Biró changed:
What|Removed |Added
Summary|AMDGPU recovery does|AMDGPU.gpu_recovery does
https://bugs.freedesktop.org/show_bug.cgi?id=112297
Bug ID: 112297
Summary: AMDGPU recovery does recover desktop to an unstable
state
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux
On Thu, 14 Nov 2019, Wambui Karuga wrote:
> This adds a new DRM_DEV_WARN helper macro for warnings log output that include
> device pointers. It also includes the use of the DRM_DEV_WARN macro in
> drm/rockchip to replace dev_warn.
I'm trying to solicit new struct drm_device based logging
On Fri, 15 Nov 2019, Joonas Lahtinen wrote:
> Quoting Dave Airlie (2019-11-14 03:33:24)
>> The landing of the i915 CVE fixes into Linus tree has created a bit of
>> a mess in linux-next and downstream in drm-next trees.
>>
>> I talked to Daniel and he had talked to Joonas a bit, and I decided to
Quoting Dave Airlie (2019-11-14 03:33:24)
> The landing of the i915 CVE fixes into Linus tree has created a bit of
> a mess in linux-next and downstream in drm-next trees.
>
> I talked to Daniel and he had talked to Joonas a bit, and I decided to
> go with what Daniel describes as the YOLO merge,
On Fri, Nov 15, 2019 at 11:18:28AM +0100, Daniel Vetter wrote:
> On Fri, Nov 15, 2019 at 10:37 AM Gerd Hoffmann wrote:
> >
> > > You need memory pressure, to force ttm to unmap the bo, not userspace. So
> > > roughly
> > > 1. create bo
> > > 2. mmap it through drm fd, write some stuff
> > > 3.
On Fri, 15 Nov 2019 10:21:13 +0100
Daniel Vetter wrote:
> - Our limit is uint32_t, make that explicit.
>
> - Untangle the one overflow check, I think (but not sure) that with
> all three together you could overflow the uint64_t and it'd look
> cool again. Hence two steps. Also go with the
From: Allen Chen
This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.
Signed-off-by: Jitao Shi
Signed-off-by: Yilun Lin
Signed-off-by: Allen Chen
Signed-off-by: Pi-Hsun Shih
---
drivers/gpu/drm/bridge/Kconfig |7 +
drivers/gpu/drm/bridge/Makefile
On 08. 11. 19 18:59, Laurent Pinchart wrote:
> Enable the dpsub device and wire it up to the PS-GTR PHY lanes routed to
> the DisplayPort connector.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 16
> 1 file changed, 16
This reverts commit 9a42c7c647a9ad0f7ebb147a52eda3dcb7c84292.
Signed-off-by: Allen Chen
---
drivers/gpu/drm/drm_dp_helper.c | 128 ++
drivers/gpu/drm/tegra/Makefile | 1 -
drivers/gpu/drm/tegra/dp.c | 876
drivers/gpu/drm/tegra/dp.h |
The IT6505 is a high-performance DisplayPort 1.1a transmitter, fully compliant
with DisplayPort 1.1a, HDCP 1.3 specifications. The IT6505 supports color depth
of up to 36 bits (12 bits/color) and ensures robust transmission of
high-quality uncompressed video content, along with uncompressed and
From: Allen Chen
Add a DT binding documentation for IT6505.
Signed-off-by: Allen Chen
Signed-off-by: Pi-Hsun Shih
---
.../bindings/display/bridge/ite,it6505.txt | 28 ++
1 file changed, 28 insertions(+)
create mode 100644
Hi Chris,
On Thu, 14 Nov 2019 20:44:13 +, Chris Wilson wrote:
> An old display with no audio may not have an EDID with a CEA block, or
> it may simply be too old to support audio. This is not a driver error,
> so don't flag it as such.
>
> Bugzilla:
On Fri, Nov 15, 2019 at 10:37 AM Gerd Hoffmann wrote:
>
> > You need memory pressure, to force ttm to unmap the bo, not userspace. So
> > roughly
> > 1. create bo
> > 2. mmap it through drm fd, write some stuff
> > 3. export to dma-buf, mmap it, verify stuff is there
> > 4. create a pile more bo,
From: Colin Ian King
The assignment of adev dereferences pointer hwmgr before hwmgr is null
checked, hence there is a potential null pointer deference issue. Fix
this by assigning adev after the null check.
Addresses-Coverity: ("Dereference before null check")
Fixes: 0896d2f7ba4d
> You need memory pressure, to force ttm to unmap the bo, not userspace. So
> roughly
> 1. create bo
> 2. mmap it through drm fd, write some stuff
> 3. export to dma-buf, mmap it, verify stuff is there
> 4. create a pile more bo, mmap them write to them
> 5. once you've thrashed all of vram
On Fri, 15 Nov 2019 10:21:14 +0100
Daniel Vetter wrote:
> Spotted while looking through them all.
>
> Signed-off-by: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
Acked-by: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc:
Aside: There's a few other fb_create implementations which
simply check for valid buffer format (or an approximation thereof),
and then call drm_gem_fb_create. For atomic drivers at least we could
walk all planes and make sure the format/modifier combo is valid,
and remove even more code.
For
Again we could delete a lot more if we'd switch over to the generic
fbdev stuff.
Signed-off-by: Daniel Vetter
---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 4 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 11 +---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 5 +-
Spotted while looking through them all.
Signed-off-by: Daniel Vetter
Cc: Sam Ravnborg
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 8 +---
1 file changed, 1
The current code is a pretty good wtf moment, since we drop the
reference before we use it. It's not a big deal, because a) we only
use the pointer, so doesn't blow up and the real reason b) fb->obj[0]
already holds a full reference for us.
Might as well take the real pointer ins't of complicated
Hi all,
Inspired by some chatting with Pekka on irc I looked a lot at our
->fb_create implementations. Some cleanups (the simpler ones) and some
todos (the more involved stuff).
It's not a lot of code that we can collect even with all the todos, but we
have so many drivers nowadays it's worth it
We're doing a great job for really simple drivers right now, but still
a lot of boilerplate for the bigger ones.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 26 ++
1 file changed, 26 insertions(+)
diff --git a/Documentation/gpu/todo.rst
- Our limit is uint32_t, make that explicit.
- Untangle the one overflow check, I think (but not sure) that with
all three together you could overflow the uint64_t and it'd look
cool again. Hence two steps. Also go with the more common (and imo
safer approach) of reducing the range we
If rockchip would switch over to the generic fbdev setup we could
grabage collect even more of all this code (all of the remaining fb
handling code really).
Signed-off-by: Daniel Vetter
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: linux-arm-ker...@lists.infradead.org
Cc:
Doesn't do anything.
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index
On Fri, Nov 15, 2019 at 10:04 AM Jean Delvare wrote:
>
> Hi Chris,
>
> On Thu, 14 Nov 2019 20:44:13 +, Chris Wilson wrote:
> > An old display with no audio may not have an EDID with a CEA block, or
> > it may simply be too old to support audio. This is not a driver error,
> > so don't flag it
https://bugzilla.kernel.org/show_bug.cgi?id=205497
--- Comment #10 from V.I.S. (itemc...@mail.ru) ---
AMD Ryzen 5 2600G + AMD RX560 (multiseat system), system freezed after few days
on kernel 4.19.83 in my case.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=112288
--- Comment #11 from Michel Dänzer ---
(In reply to Alex Deucher from comment #3)
> [1.094054] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu
> kernel modesetting.
> Did you enable vga console?
FWIW, that message is due to
https://bugzilla.kernel.org/show_bug.cgi?id=205497
--- Comment #9 from Trek (tre...@inbox.ru) ---
thanks, I was not aware of it, may be different hardware from the ones on which
kernel 4.19/5.1 works?
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote:
> Hi Daniel,
>
> I don't think we can make any complaints about GPL being more widely
> used in the DRM code. It's nice to have the code at all, the MIT license
> is a bonus. Thanks for writing it and bearing with us.
>
> Would
https://bugzilla.kernel.org/show_bug.cgi?id=205497
--- Comment #8 from V.I.S. (itemc...@mail.ru) ---
Please read here... https://github.com/lestofante/ksysguard-gpu/issues/4
Same issue on 4.19.x LTS kernel.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=205497
Trek (tre...@inbox.ru) changed:
What|Removed |Added
CC||tre...@inbox.ru
--- Comment #7
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c: In function
bios_get_board_layout_info:
drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c:1826:22: warning: variable
bp set but not used [-Wunused-but-set-variable]
It is introduced by commit
Thanks for all the comments and feedback, and they are all so valuable to me.
Let me summarize the main concerns so far here:
(1) Open source driver never specifies what API is creating a gem
object (opengl, vulkan, ...) nor what purpose (transient, shader,
...).
(2) The ioctl to label anything
Add support for Visionox panel driver.
Signed-off-by: Harigovindan P
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-visionox-rm69299.c | 478 +
3 files changed, 488
The bus_flags and bus_format handling logic does not seem to cover
all potential usecases. Specifically, this seems to fail with an
"edt,etm0700g0edh6" display attached to an 24bit display interface,
with interface-pix-fmt = "rgb24" set in DT.
In this specific setup, the panel-simple.c driver
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/display/modules/color/color_gamma.c: In function
build_freesync_hdr:
drivers/gpu/drm/amd/display/modules/color/color_gamma.c:830:20: warning:
variable min_content set but not used [-Wunused-but-set-variable]
It is not used
This adds a new DRM_DEV_WARN helper macro for warnings log output that include
device pointers. It also includes the use of the DRM_DEV_WARN macro in
drm/rockchip to replace dev_warn.
Wambui Karuga (2):
drm/print: add DRM_DEV_WARN macro
drm/rockchip: use DRM_DEV_WARN macro in debug output
Replace the use of dev_warn in debug output with the new DRM specific
DRM_DEV_WARN debug output macro to maintain consistency across the driver.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c: In function
dm_determine_update_type_for_commit:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:6516:36: warning: variable
old_plane_crtc set but not used [-Wunused-but-set-variable]
It is
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/display/dc/bios/bios_parser.c: In function
bios_get_board_layout_info:
drivers/gpu/drm/amd/display/dc/bios/bios_parser.c:2743:22: warning: variable bp
set but not used [-Wunused-but-set-variable]
It is introduced by commit
zhengbin (4):
drm/amd/display: remove set but not used variable 'old_plane_crtc'
drm/amd/display: remove set but not used variable 'bp' in
bios_parser2.c
drm/amd/display: remove set but not used variable 'bp' in
bios_parser.c
drm/amd/display: remove set but not used variable
On Thu, Nov 14, 2019 at 10:47 AM Rob Clark wrote:
>
> On Thu, Nov 14, 2019 at 2:16 AM Harigovindan P
> wrote:
> >
> > Add DSI config changes to support DSI version.
> >
> > Signed-off-by: Harigovindan P
>
> Reviewed-by: Rob Clark
Can we fix the subject/commit text for this to indicate what
Current patchset adds support for rm69299 visionox panel driver used in MSM
reference platforms
and also adds DSI config that supports the respective DSI version.
The visionox panel driver supports a resolution of 1080x2248 with 4 lanes and
supports only single DSI mode.
Current patchset is
1 - 100 of 105 matches
Mail list logo
