Am 19.09.2018 um 17:39 schrieb Michel Dänzer:
On 2018-09-19 2:30 p.m., Christian König wrote:
Am 18.09.2018 um 18:17 schrieb Nayan Deshmukh:
having a delayed work item per job is redundant as we only need one
per scheduler to track the time out the currently executing job.
Well that looks simp
Hi Dave,
A couple of modesetting fixes and a fix for a long-standing buffer-eviction
problem cc'd stable.
The following changes since commit 8ca4fff974ad5288d38298f15bf218f2eac2d5e7:
Merge tag 'drm-intel-fixes-2018-09-19' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-09-
Hi,
> void virtio_gpu_cmd_transfer_to_host_2d(struct virtio_gpu_device *vgdev,
> uint32_t resource_id, uint64_t offset,
> ...
> struct virtio_gpu_fbdev *vgfbdev = vgdev->vgfbdev;
> struct virtio_gpu_framebuffer *fb = &vgfbdev->vgfb;
> struct
Pass virtio_gpu_object down to virtio_gpu_cmd_transfer_to_host_2d and
virtio_gpu_cmd_transfer_to_host_3d functions, instead of passing just
the virtio resource handle.
This is needed to lookup the scatter list of the object, for dma sync.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/
Signed-off-by: Lucas De Marchi
---
Android.common.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/Android.common.mk b/Android.common.mk
index e3de1069..d0e5d559 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -2,6 +2,7 @@
LOCAL_CFLAGS += \
-DMAJOR_IN_SYSMACROS=1 \
On Fri, Sep 14, 2018 at 10:28:46AM +0100, Eric Engestrom wrote:
> On Thursday, 2018-09-13 16:57:11 -0700, Lucas De Marchi wrote:
> > Rely on -fvisibility=hidden to hide the symbols. Previous version of
> > this series applying only to drm_intel.so is
> >
> > Reviewed-by: Eric Engestrom
> >
>
On Fri, Sep 14, 2018 at 10:02:19AM +0200, Michel Dänzer wrote:
>
> The shortlog prefix of this patch should be amdgpu: instead of libkms:.
thanks, I fixed that.
Lucas De Marchi
> With that fixed, this patch and the radeon patch are
>
> Reviewed-by: Michel Dänzer
>
>
> --
> Earthling Michel
While requesting a Developer role I was pointed to this url and check
those with "owner" role. So add it to our documentation.
v2: rollback previous text, but add a link to gitlab's page
showing project members.
v3: reprhase paragraph adding link to members page
Signed-off-by: Lucas De Marchi
https://bugzilla.kernel.org/show_bug.cgi?id=201183
--- Comment #6 from marten (marte...@gmail.com) ---
(In reply to Nicholas Kazlauskas from comment #4)
> Do you only see this problem occur before you start an X session?
>
> It might help if you could post a log from 4.18 with drm.debug=6 include
https://bugzilla.kernel.org/show_bug.cgi?id=201183
--- Comment #5 from marten (marte...@gmail.com) ---
Created attachment 278677
--> https://bugzilla.kernel.org/attachment.cgi?id=278677&action=edit
Kernel 4.18 with drm.debug=6
--
You are receiving this mail because:
You are watching the assign
https://bugs.freedesktop.org/show_bug.cgi?id=101978
--- Comment #10 from Timothy Arceri ---
(In reply to Konstantin A. Lepikhov from comment #9)
> BTW running warthunder under brand new 4.15 kernel + latest amd-staging-4.15
> gives 25-30+ FPS and the same during the gameplay with performance set
https://bugs.freedesktop.org/show_bug.cgi?id=107334
--- Comment #5 from Timothy Arceri ---
Also I used: unigine-valley-1.1.7
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedeskto
https://bugs.freedesktop.org/show_bug.cgi?id=107334
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #4 from Timothy A
https://bugs.freedesktop.org/show_bug.cgi?id=100443
Alex Deucher changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
On Thu, Sep 20, 2018 at 12:09 AM Dave Airlie wrote:
>
> On Thu, 20 Sep 2018 at 14:03, Dave Airlie wrote:
> >
> > On my 32-bit arm build
> >
> > MODPOST 1797 modules
> > ERROR: "__aeabi_uldivmod" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> >
> > Somebody added a ul/ul without using the do_
https://bugs.freedesktop.org/show_bug.cgi?id=100443
Devin Prince changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=107990
--- Comment #3 from John ---
> When you say working I assume you mean it no longer crashes at start up?
Correct, sorry about the lack of clarity.
It still takes quite a while on the black screen with the white line, but it
eventually passes it
On Thu, 20 Sep 2018 at 14:03, Dave Airlie wrote:
>
> On my 32-bit arm build
>
> MODPOST 1797 modules
> ERROR: "__aeabi_uldivmod" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
>
> Somebody added a ul/ul without using the do_div stuff.
>
> I won't pull this until it's fixed.
It seems to be the
On my 32-bit arm build
MODPOST 1797 modules
ERROR: "__aeabi_uldivmod" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Somebody added a ul/ul without using the do_div stuff.
I won't pull this until it's fixed.
Dave.
On Sat, 15 Sep 2018 at 01:52, Alex Deucher wrote:
>
> Hi Dave,
>
> First pull
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #1 from Shmerl ---
Same thing happens with kernel 4.19-rc4.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop
From: "abhin...@codeaurora.org"
Add the device tree bindings for Truly NT35597 panel driver.
This panel driver supports both single DSI and dual DSI.
However, this patch series supports only dual DSI.
Changes in v7:
- Change the compatible string to indicate only the
panel driver string a
From: "abhin...@codeaurora.org"
Add support for Truly NT35597 panel driver used
in MSM reference platforms.
This panel driver supports both single DSI and dual DSI
modes.
However, this patch series adds support only for
dual DSI mode.
Changes in v7:
- Make the panel commands, name and mode as
https://bugs.freedesktop.org/show_bug.cgi?id=107990
--- Comment #2 from Timothy Arceri ---
When you say working I assume you mean it no longer crashes at start up?
Have you reported this to the packages of Mesa on Arch?
fno-plt is a gcc optimisation flag that is not applied to Mesa by default,
https://bugs.freedesktop.org/show_bug.cgi?id=95517
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=107694
Timothy Arceri changed:
What|Removed |Added
Resolution|NOTOURBUG |---
Status|RESOLVED
On Wed, Sep 19, 2018 at 04:27:22PM -0700, Lucas De Marchi wrote:
> While requesting a Developer role I was pointed to this url and check
> those with "owner" role. So add it to our documentation.
>
> v2: rollback previous text, but add a link to gitlab's page
> showing project members.
>
> Si
On Fri, Sep 14, 2018 at 10:28:46AM +0100, Eric Engestrom wrote:
> On Thursday, 2018-09-13 16:57:11 -0700, Lucas De Marchi wrote:
> > Rely on -fvisibility=hidden to hide the symbols. Previous version of
> > this series applying only to drm_intel.so is
> >
> > Reviewed-by: Eric Engestrom
> >
>
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #63 from Anthony Ruhier ---
FYI, I also had this bug under linux 4.17 and 4.18, but it seems to have been
fixed in 4.19-rc3. The suspend/hibernate issue has also been fixed.
--
You are receiving this mail because:
You are the assig
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #64 from Anthony Ruhier ---
(In reply to Anthony Ruhier from comment #63)
> FYI, I also had this bug under linux 4.17 and 4.18, but it seems to have
> been fixed in 4.19-rc3. The suspend/hibernate issue has also been fixed.
Forgot t
While requesting a Developer role I was pointed to this url and check
those with "owner" role. So add it to our documentation.
v2: rollback previous text, but add a link to gitlab's page
showing project members.
Signed-off-by: Lucas De Marchi
---
CONTRIBUTING | 4 +++-
1 file changed, 3 ins
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc pro
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against conne
On Wed, Sep 19, 2018 at 03:47:48PM +0800, Chih-Wei Huang wrote:
> 2018-09-14 2:23 GMT+08:00 Lucas De Marchi :
> > +Chris
> >>
> >> That's because drm_gralloc use the IS_GEN9 macro
> >> (and other IS_GEN{n} macros) directly.
> >>
> >> Since IS_GEN{n} are public APIs, I don't see
> >
> >
> > IS_GEN()
https://bugs.freedesktop.org/show_bug.cgi?id=107990
--- Comment #1 from John ---
I had someone else try this, and it worked for him as well with a 580.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
Hook this into amdgpu's atomic check for their connectors so they never
get modesets on no-longer-present MST connectors. We'll also expand on
this later once we add DP MST fallback retraining support.
As well, turns out that the only atomic DRM driver without the
->best_encoder() bug is amdgpu. C
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on no-l
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try to
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that we can prevent further
action on the port such as connector probes, mode probing, etc.
However, we're going to need access to intel_connector->mst_port in
order to fixup ->best_e
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable CRTC
There's two major things this patchset does:
- Add drm_dp_mst_connector_atomic_check() so drivers don't need to use
->best_encoder() to prevent modesets on zombie MST connectors. We'll
use this later for implementing MST fallback retraining as well.
- Fix DPMS on->off changes failing with l
Currently the way that we prevent userspace from performing new modesets
on MST connectors that have just been destroyed is rather broken.
There's nothing in the actual DRM DP MST topology helpers that checks
whether or not a connector still exists, instead each DRM driver does
this on it's own, us
https://bugs.freedesktop.org/show_bug.cgi?id=102962
--- Comment #16 from Simon ---
I have the same issue - I am running ArchLabs with arch repos, recent drivers,
lutris installer of Overwatch. When firing D.Vas rockets or certain other
sparkly effects, the gpu hangs. This is dmesg of when it happ
On 09/19/2018 06:38 AM, Gerd Hoffmann wrote:
Once display manger is kicked off for example (sudo systemctl start
lightdm.service) and
resource id 3 gets created from user space down, it still gives a blank
black screen.
>>>
>>> Hmm. I'd suspect there is simply a code path m
On Wed, 2018-09-19 at 18:58 +, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.18.8, v4.14
On Wed, 2018-09-19 at 18:58 +, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.18.8, v4.14
g,
> intel-...@lists.freedesktop.org, amd-...@lists.freedesktop.org
> CC: David Airlie , linux-ker...@vger.kernel.org,
> sta...@vger.kernel.org, Sean Paul
>
> Hi Lyude,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on drm-inte
On Tue, Sep 18, 2018 at 05:19:09PM +0200, Daniel Vetter wrote:
> On Mon, Aug 27, 2018 at 9:18 AM, Shawn Guo wrote:
> > On Fri, Aug 17, 2018 at 10:24:06AM +0800, zhong jiang wrote:
> >> for_each_available_child_of_node will get and put the node properly,
> >> the following of_node_put will lead to
On Thu, Sep 20, 2018 at 6:40 AM Sean Paul wrote:
>
> From: Sean Paul
>
> Move udl maintenance into drm-misc tree. I've also signed up to be a
> reviewer, but have kept it at "Odd Fixes" level of support.
>
> Cc: Dave Airlie
Acked-by: Dave Airlie
> Cc: David Airlie
> Cc: Gustavo Padovan
> Cc
On Wed, Sep 19, 2018 at 01:04:42PM -0700, Abhinav Kumar wrote:
> On 2018-09-19 11:33, Sean Paul wrote:
> > From: Sean Paul
> >
> > TP_printk is not synchronous, so storing pointers and then later
> > derferencing them is a Bad Idea. This patch stores everything locally to
> minor typo "dereferenc
From: Sean Paul
Another "small driver" moving into drm-misc. Stefan has also offered to
co-maintain it.
Cc: Marek Vasut
Cc: Stefan Agner
Cc: David Airlie
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Signed-off-by: Sean Paul
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git
From: Sean Paul
Move udl maintenance into drm-misc tree. I've also signed up to be a
reviewer, but have kept it at "Odd Fixes" level of support.
Cc: Dave Airlie
Cc: David Airlie
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Signed-off-by: Sean Paul
---
MAINTAINERS | 3 +++
1 file changed, 3 in
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.19-rc4 next-20180919]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Lyude-Paul/Fix-legacy-DPMS-changes-with-MS
On 2018-09-19 11:33, Sean Paul wrote:
From: Sean Paul
TP_printk is not synchronous, so storing pointers and then later
derferencing them is a Bad Idea. This patch stores everything locally
to
minor typo "dereferencing",
avoid display stomped memory.
Signed-off-by: Sean Paul
After fixing t
Hi Dave,
Another week another PR. There's a conflict in i915_drv.c, as you may have seen
from Stephen's email earlier this week. The rerere cache has the resolution, so
dim to the rescue!
drm-misc-next-2018-09-19:
drm-misc-next for 4.20:
UAPI Changes:
- None
Cross-subsystem Changes:
- None
Cor
On 2018-09-19 11:33, Sean Paul wrote:
From: Sean Paul
It's useful to know which bits of the flush come from
"extra_flush_bits"
Signed-off-by: Sean Paul
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 14 +
On 2018-09-19 11:33, Sean Paul wrote:
From: Sean Paul
We're printing the frame_busy_mask in a trace, but after it's been
cleared. This, as it turns out, is pretty pointless.
Signed-off-by: Sean Paul
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
1 file
https://bugs.freedesktop.org/show_bug.cgi?id=107991
kyle.de...@mykolab.com changed:
What|Removed |Added
Product|Mesa|DRI
Component|Drivers/
https://bugs.freedesktop.org/show_bug.cgi?id=107950
--- Comment #8 from SET ---
(In reply to Michel Dänzer from comment #6)
Tried with xf86-video-ati 18.1.0 :
Same delayed freeze.
I think the host gets overheated. The last line in kernel.log is
Sep 19 20:44:44 hp2 kernel: [ 337.131484] amdg
From: Sean Paul
TP_printk is not synchronous, so storing pointers and then later
derferencing them is a Bad Idea. This patch stores everything locally to
avoid display stomped memory.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 98 +--
1 file ch
From: Sean Paul
It's useful to know which bits of the flush come from "extra_flush_bits"
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 14 +-
2 files changed, 11 insertions(+), 6 deletions(-)
diff -
From: Sean Paul
We're printing the frame_busy_mask in a trace, but after it's been
cleared. This, as it turns out, is pretty pointless.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/m
https://bugs.freedesktop.org/show_bug.cgi?id=107991
--- Comment #1 from kyle.de...@mykolab.com ---
I'm running Mesa master compiled with LLVM master, and kernel 4.18.8.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-de
https://bugs.freedesktop.org/show_bug.cgi?id=107991
kyle.de...@mykolab.com changed:
What|Removed |Added
Summary|RX580 ~ ring gfx timeout ~ |RX580 ~ ring gfx timeout ~
https://bugs.freedesktop.org/show_bug.cgi?id=107991
Bug ID: 107991
Summary: RX580 ~ ring gfx timeout ~ particular shaders created
by a dolphin-emu game can bring down AMDGPU
Product: Mesa
Version: git
Hardware: x86-64 (AMD6
Since we already expose the vbios.rom file here, why not also expose the
strap_peek?
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/dr
This is a small patch series that adds a strap_peek file into our
debugfs, and sets the size of the vbios.rom debugfs file so that nvbios
can easily be used to parse the vbios even on systems where the normal
BIOS retrieval methods (for example, laptops that need ACPI to access
the vbios for the nv
With this, nvbios /sys/kernel/debug/dri/*/vbios.rom now works!
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau
Hi Kieran,
On Wed, Sep 19, 2018 at 07:15:45PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 19, 2018 at 04:56:58PM +0100, Kieran Bingham wrote:
> > Planes without an alpha property, using __drm_atomic_helper_plane_reset
> > will have their plane state alpha initialised as zero, which represents
> > a
https://bugs.freedesktop.org/show_bug.cgi?id=107001
cla...@mathr.co.uk changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
On Tue, Sep 18, 2018 at 6:57 AM Icenowy Zheng wrote:
>
> 在 2018-09-17一的 16:54 +0200，Maxime Ripard写道：
> > On Mon, Sep 10, 2018 at 04:32:30PM +0200, Jernej Škrabec wrote:
> > > Dne ponedeljek, 10. september 2018 ob 16:23:54 CEST je Maxime
> > > Ripard
> > > napisal(a):
> > > > On Fri, Sep 07, 2018 a
On Wed, Sep 19, 2018 at 04:56:58PM +0100, Kieran Bingham wrote:
> Planes without an alpha property, using __drm_atomic_helper_plane_reset
> will have their plane state alpha initialised as zero, which represents
> a transparent alpha.
>
> If this value is then used for the plane, it may not be vis
If the alpha property is not added to a plane, a default value will be
used, which can result in a non-visible layer if the alpha is
initialised as 0.
Provide an alpha blend property on all planes.
Fixes: 161ad653d6c9 ("drm: rcar-du: Use __drm_atomic_helper_plane_reset
instead of copying the logi
Planes without an alpha property, using __drm_atomic_helper_plane_reset
will have their plane state alpha initialised as zero, which represents
a transparent alpha.
If this value is then used for the plane, it may not be visible by
default, and thus doesn't represent a good initialisation state.
Testing on the RCar Salvaltor-XS using the rcar-du has identified that
commit 161ad653d6c9 ("drm: rcar-du: Use __drm_atomic_helper_plane_reset
instead of copying the logic") caused a regression in display output on
the primary planes.
The effect was that primary plane was 'invisible' though second
On 2018-09-19 2:30 p.m., Christian König wrote:
> Am 18.09.2018 um 18:17 schrieb Nayan Deshmukh:
>> having a delayed work item per job is redundant as we only need one
>> per scheduler to track the time out the currently executing job.
>
> Well that looks simpler than I thought it would be.
>
> B
Hi Dave,
Here goes drm-intel-fixes-2018-09-19:
Only fixes coming from gvt containing "Two more BXT fixes from Colin,
one srcu locking fix and one fix for GGTT clear when destroy vGPU."
Thanks,
Rodrigo.
The following changes since commit 7876320f88802b22d4e2daf7eb027dd14175a0f8:
Linux 4.19-rc
On 18.07.2018 22:33, Peter Seiderer wrote:
> Use meson library instead of shared_library to enable static build.
>
> Signed-off-by: Peter Seiderer
thanks, seems to work
--
t
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.f
drm-misc-fixes-2018-09-19:
drm-misc-fixes for v4.19-rc5:
- Fix crash in vgem in drm_drv_uses_atomic_modeset.
- Allow atomic drivers that don't set DRIVER_ATOMIC to create debugfs entries.
- Fix compiler warning for unused connector_funcs.
- Fix null pointer deref on UDL unplug.
- Disable DRM suppor
https://bugs.freedesktop.org/show_bug.cgi?id=107990
Bug ID: 107990
Summary: Got Dying Light working in Arch by changing Mesa's
compile steps, how to get it working Out Of the Box?
Product: Mesa
Version: 18.2
Hardware: x86-6
On Tue, 11 Sep 2018, "Lee, Shawn C" wrote:
> Only specific N value (0x8000) would be acceptable for LG
> LP140WF6-SPM1 eDP panel which is running at asynchronous
> clock mode. With the other N value, it will enter BITS mode
> and display black screen. This patch series set constant N
> value for s
Hi Simon,
On Wednesday, 19 September 2018 11:35:07 EEST Simon Horman wrote:
> On Mon, Sep 17, 2018 at 11:59:32AM +0300, Laurent Pinchart wrote:
> > On Monday, 17 September 2018 11:54:04 EEST Laurent Pinchart wrote:
> >> On Monday, 17 September 2018 11:47:15 EEST Laurent Pinchart wrote:
> >>> On Mo
https://bugzilla.kernel.org/show_bug.cgi?id=201183
--- Comment #4 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
Do you only see this problem occur before you start an X session?
It might help if you could post a log from 4.18 with drm.debug=6 included in
your boot parameters.
--
Yo
Am 18.09.2018 um 18:17 schrieb Nayan Deshmukh:
having a delayed work item per job is redundant as we only need one
per scheduler to track the time out the currently executing job.
Well that looks simpler than I thought it would be.
But it shows the next problem that the timeout and the complet
On Wed, 19 Sep 2018, Chris Chiu wrote:
> I have few ASUS laptops, X705FD(Intel i7-8565), X560UD(Intel i5-8250U)
> and X530UN(Intel i7-8550U) share the same problem. The HDMI connector
> status stays 'connected' even the HDMI cable has been unplugged.
> Then the status in sysfs would never change s
Hi,
On Fri, Sep 14, 2018 at 02:18:37PM +0530, Kishon Vijay Abraham I wrote:
> > +/**
> > + * phy_validate() - Checks the phy parameters
> > + * @phy: the phy returned by phy_get()
> > + * @mode: phy_mode the configuration is applicable to.
> > + * @opts: Configuration to check
On Wed, 19 Sep 2018, Chris Chiu wrote:
> I tried to add a slight delay in the hotplug work as follows
>
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -378,6 +378,8 @@ static void do_i915_hotplug_check(struct work_struct
> *work,
>
> spin_un
Hi, Stu:
On Wed, 2018-09-12 at 14:02 +0800, Stu Hsieh wrote:
> This patch add function to match the connector and crtc
>
> Because the connector set the possible_crtc to match the crtc.
>
> This function would search the connector in every ddp path and
> return the corresponding value for possib
Quoting Chris Chiu (2018-09-19 12:29:33)
> I have few ASUS laptops, X705FD(Intel i7-8565), X560UD(Intel i5-8250U)
> and X530UN(Intel i7-8550U) share the same problem. The HDMI connector
> status stays 'connected' even the HDMI cable has been unplugged.
> Then the status in sysfs would never change
> >> Once display manger is kicked off for example (sudo systemctl start
> >> lightdm.service) and
> >> resource id 3 gets created from user space down, it still gives a blank
> >> black screen.
> >
> > Hmm. I'd suspect there is simply a code path missing. Can you send the
> > patch you have?
On Wed, Sep 19, 2018 at 07:09:53AM +, An, Jiandi wrote:
> With virtio gpu ttm-pages being dma mapped, dma sync is needed when
> swiotlb is used as bounce buffers, before TRANSFER_TO_HOST_2D/3D
> commands are sent.
Pushed to drm-misc-next.
thanks,
Gerd
__
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Create our own plane and use drm_crtc_init_with_planes() instead of
depending on the d
Turns out we need the pixel format fixup not only for the addfb ioctl,
but also for fbdev emulation code.
Ideally we would place it in drm_mode_legacy_fb_format(). That would
create alot of churn though, and most drivers don't care because they
never ever run on a big endian platform. So add a n
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little
endian, so using a
Fix fbdev emulation.
Fix bochs-drm and virtio-gpu drivers.
Gerd Hoffmann (5):
drm: move native byte order quirk to new drm_mode_legacy_fb_format2
function
drm: use drm_mode_legacy_fb_format2 in drm_gem_fbdev_fb_create
drm/bochs: fix DRM_FORMAT_* handling for big endian machines.
drm/bo
Add bochs_hw_set_*_endian() helper functions, to set the framebuffer
byteorder at mode set time. Support both DRM_FORMAT_XRGB and
DRM_FORMAT_BGRX framebuffer formats, no matter what the native
machine byte order is.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs.h |
Creating framebuffers for fbdev emulation should use the correct format
code too, so switch drm_gem_fbdev_fb_create() over to use the new
drm_mode_legacy_fb_format2() function.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 --
1 file changed, 4 insertions(
On Tue, Sep 18, 2018 at 02:10:17PM -0700, Manasi Navare wrote:
> On Tue, Sep 18, 2018 at 10:46:46PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> > > On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 18, 2018 at 12:
https://bugzilla.kernel.org/show_bug.cgi?id=201183
--- Comment #3 from marten (marte...@gmail.com) ---
Thank you Michel.
That fixes it.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-dev
On Sun, Sep 16, 2018 at 12:34:05PM +0800, Icenowy Zheng wrote:
> When adding support for A64 HDMI PHY in 4.19, we assumed that the two
> PLL-VIDEOs can both feed the HDMI PHY clock. However experiments show
> that the mux bit discovered in R40 blob is not applicable on A64. This
> is not discovered
Signed-off-by: Chunming Zhou
---
tests/amdgpu/Makefile.am | 3 +-
tests/amdgpu/amdgpu_test.c | 12 ++
tests/amdgpu/amdgpu_test.h | 21 +++
tests/amdgpu/meson.build | 2 +-
tests/amdgpu/syncobj_tests.c | 259 +++
5 files changed, 295 insertions(+),
1 - 100 of 128 matches
Mail list logo
