Hi Jani,
On Wednesday, 2 January 2019 09:47:58 EET Jani Nikula wrote:
> On Fri, 28 Dec 2018, Jani Nikula wrote:
> > Thanks for all the reviews, pushed patches 1-5 to topic/drmp-cleanup
> > with $(git merge-base drm-misc-next drm-intel-next-queued) as the
> > starting point. It's also included in
https://bugs.freedesktop.org/show_bug.cgi?id=109178
Martin Peres changed:
What|Removed |Added
Group|spam|
--
You are receiving this mail because
https://bugs.freedesktop.org/show_bug.cgi?id=109140
--- Comment #1 from Hai ---
Is there any update for this issue? Thanks
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.
https://bugs.freedesktop.org/show_bug.cgi?id=109178
--- Comment #4 from Jani Nikula ---
(In reply to Jan from comment #2)
> The samsung-laptop.ko module is enabling the use of the keyboard backlight
> keys.
This bugzilla is about display and graphics, not about keyboard. Try these
people and lis
https://bugs.freedesktop.org/show_bug.cgi?id=109178
Jani Nikula changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=109178
Jan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #6 from Jan ---
Ok apologies
https://bugs.freedesktop.org/show_bug.cgi?id=109001
--- Comment #10 from wirch.edu...@gmail.com ---
Disabling stuff does not help. Running kernel 4.20.0-1 and these settings:
Section "Device"
Identifier "Device0"
Driver "amdgpu"
BusID "PCI:14:0:0"
Optio
Quoting Eric Wong (2018-12-27 13:49:48)
> I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
> chipset) and hit some kernel panics while trying to view
> image/animation-intensive stuff in Firefox (X11) unless I use
> "iommu_intel=igfx_off".
>
> With Debian stable backport kernels, "linux-
On Wed, 02 Jan 2019, Laurent Pinchart wrote:
> Hi Jani,
>
> On Wednesday, 2 January 2019 09:47:58 EET Jani Nikula wrote:
>> On Fri, 28 Dec 2018, Jani Nikula wrote:
>> > Thanks for all the reviews, pushed patches 1-5 to topic/drmp-cleanup
>> > with $(git merge-base drm-misc-next drm-intel-next-que
Hi Sean, Maarten & Maxime -
I embarked on removing drmP.h includes from i915, but that requires a
bunch of drm header cleanup to add relevant includes and forward
declarations. Due to the timing, propagating the patches back to i915
would take eons, so Daniel suggested a topic branch to be merged
Hi Alexander,
On Thu, 2018-12-20 at 11:06 +0300, Alexander Shiyan wrote:
> The CSI0/CSI1 registers offset is at +0xe03/+0xe038000 relative
> to the control module registers on IPUv3EX.
> This patch fixes wrong values for i.MX51 CSI0/CSI1.
>
> Signed-off-by: Alexander Shiyan
> ---
> drivers/
On 12/24/18 7:15 AM, Daniel Vetter wrote:
> On Fri, Dec 21, 2018 at 09:33:24AM -0500, Nicholas Kazlauskas wrote:
>> The behavior of drm_atomic_helper_cleanup_planes differs depending on
>> whether the commit was an asynchronous update or not.
>>
>> For a typical (non-async) atomic commit prepare_fb
https://bugzilla.kernel.org/show_bug.cgi?id=201815
Sam Bazley (sambaz...@protonmail.com) changed:
What|Removed |Added
CC||sambaz...@protonma
On Thu, 2018-12-13 at 14:49 +0100, Gerd Hoffmann wrote:
A few words explaining why the generic emulation is OK would be useful.
The commit might be clear for seasoned DRM developers, however
given this driver is a nice target for those learning DRM
(as it can be tested easily), I think having a m
On Wed, 2018-12-19 at 13:27 +0100, Gerd Hoffmann wrote:
> Sending the flush command only makes sense if we actually have
> a framebuffer attached to the scanout (handle != 0).
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_plane.c | 11 ++-
> 1 file changed, 6 in
On Wed, 2018-12-19 at 13:27 +0100, Gerd Hoffmann wrote:
> Just call drm_fence_put directly instead.
> Also set vgfb->fence to NULL after dropping the reference.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 -
> drivers/gpu/drm/virtio/virtgpu_fence.c | 8 ---
On Wed, 2018-12-19 at 13:27 +0100, Gerd Hoffmann wrote:
> Create virtio_gpu_object_params, use that to pass object parameters to
> virtio_gpu_object_create. Also drop unused "kernel" parameter (unused,
> always false).
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.
drm-misc-next-fixes-2019-01-02:
Fixes for v4.21:
- Fix null pointer dereference on null state pointer.
- Fix leaking damage clip when destroying plane state.
The following changes since commit 2e6e902d185027f8e3cb8b7305238f7e35d6a436:
Linux 4.20-rc4 (2018-11-25 14:19:31 -0800)
are available in
On 12/28/2018 07:03 PM, Randy Dunlap wrote:
> On 12/28/18 7:15 AM, Bartlomiej Zolnierkiewicz wrote:
>> Making FB_BACKLIGHT tristate by commit b4a1ed0cd18b ("fbdev:
>> make FB_BACKLIGHT a tristate") caused unmet dependencies in
>> some configurations:
>>
>> WARNING: unmet direct dependencies detect
As per the VirtIO spec, the virtqueues must be reset during cleanup
(see "3.3.1 Driver Requirements: Device Cleanup").
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/d
The virtio_gpu_output is a member of struct virtio_gpu_device
and is not a dynamically-allocated chunk, so it's wrong to kfree() it.
Removing it fixes a memory corruption BUG() that can be triggered
when the virtio-gpu driver is removed.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/virtio/
This driver depends on the PCI infrastructure but the dependency has not
been explicitly called out.
Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya
Reviewed-by: Lukas Wunner
Acked-by: Daniel Vetter
---
drivers/gpu/vga/Kconfig | 1 +
1
https://bugzilla.kernel.org/show_bug.cgi?id=201067
--- Comment #15 from Axel (at...@t-online.de) ---
It is fixed for me with kernel 4.20.0
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-
https://bugs.freedesktop.org/show_bug.cgi?id=109178
Jan changed:
What|Removed |Added
Resolution|NOTOURBUG |---
Status|CLOSED
https://bugs.freedesktop.org/show_bug.cgi?id=109177
Alex Deucher changed:
What|Removed |Added
QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
On 02.01.2019 18:02, Ahmad Fatoum wrote:
> Hello,
>
> I got a board with the RED[0:7]/BLUE[0:7] lanes originating from the
> LCDIF swapped and would like to describe this in the device tree:
>
> This first patch extends the mxsfb driver to support
> following bus formats:
> MEDIA_BUS_FMT_BG
Hi Ahmad.
On Wed, Jan 02, 2019 at 10:05:31PM +0100, Stefan Agner wrote:
> On 02.01.2019 18:02, Ahmad Fatoum wrote:
> > Hello,
> >
> > I got a board with the RED[0:7]/BLUE[0:7] lanes originating from the
> > LCDIF swapped and would like to describe this in the device tree:
> >
> > This first patc
On 12/23/18 6:47 PM, Zengtao (B) wrote:
Hi laura:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Friday, December 21, 2018 4:50 AM
To: Zengtao (B) ; sumit.sem...@linaro.org
Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
; Todd Kjos ; Martijn Coenen
; Joel Fernandes ;
d
On 12/24/18 12:19 AM, Qing Xia wrote:
Now, as Google's user guide, if userspace need clean ION buffer's
cache, they should call ioctl(fd, DMA_BUF_IOCTL_SYNC, sync). Then
we found that ion_dma_buf_begin_cpu_access/ion_dma_buf_end_cpu_access
will do ION buffer's map_kernel, it's not necessary. And
This has never actually worked, and isn't needed anyway: the driver's
always going to try to deallocate VCPI when it tears down the display
that the VCPI belongs to.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/d
While this isn't a complete fix, this will improve the reliability of
drm_dp_get_last_connected_port_and_mstb() pretty significantly during
hotplug events, since there's a chance that the in-memory topology tree
may not be fully updated when drm_dp_get_last_connected_port_and_mstb()
is called and t
So that the ports stay around until we've destroyed the connectors, in
order to ensure that we don't pass an invalid pointer to any MST helpers
once we introduce the new MST VCPI helpers.
Changes since v1:
* Move drm_dp_mst_get_port_malloc() to where we assign
intel_connector->port - danvet
Sig
This is the series I've been working on for a while now to get all of
the atomic DRM drivers in the tree to use the atomic MST helpers, and to
make the atomic MST helpers actually idempotent. Turns out it's a lot
more difficult to do that without also fixing how port and branch device
refcounting w
The current way of handling refcounting in the DP MST helpers is really
confusing and probably just plain wrong because it's been hacked up many
times over the years without anyone actually going over the code and
seeing if things could be simplified.
To the best of my understanding, the current s
Going through the currently programmed payloads isn't safe without
holding mgr->payload_lock, so actually do that and warn if anyone tries
calling nv50_msto_payload() in the future without grabbing the right
locks.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc:
s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/
s/drm_dp_put_port/drm_dp_mst_topology_put_port/
s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/
s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/
This is a much more consistent naming scheme,
There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks a
Same as we did for i915, but for nouveau this time. Additionally, we
grab a malloc reference to the port that lasts for the entire lifetime
of nv50_mstc, which gives us the guarantee that mstc->port will always
point to valid memory for as long as the mstc stays around.
Signed-off-by: Lyude Paul
Changes since v6:
- Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
commit
- Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
called directly
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc:
Up until now, freeing payloads on remote MST hubs that just had ports
removed has almost never worked because we've been relying on port
validation in order to stop us from accessing ports that have already
been freed from memory, but ports which need their payloads released due
to being removed wi
There has been a TODO waiting for quite a long time in
drm_dp_mst_topology.c:
/* We cannot rely on port->vcpi.num_slots to update
* topology_state->avail_slots as the port may not exist if the parent
* branch device was unplugged. This should be fixed by tracking
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't actual
Now that we finally have a sane way to keep port allocations around, use
it to fix the potential unchecked ->port accesses that nouveau makes by
making sure we keep the mst port allocated for as long as it's
drm_connector is accessible.
Additionally, now that we've guaranteed that mstc->port is al
Trying to destroy the connector using mstc->connector.funcs->destroy()
if connector initialization fails is wrong: there is no possible
codepath in nv50_mstc_new where nv50_mstm_add_connector() would return
<0 and mstc would be non-NULL.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airl
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
1 file changed, 7 insertions(+), 1 del
Just like i915 and nouveau, it's a good idea for us to hold a malloc
reference to the port here so that we never pass a freed pointer to any
of the DP MST helper functions.
Also, we stop unsetting aconnector->port in
dm_dp_destroy_mst_connector(). There's literally no point to that
assignment that
https://bugs.freedesktop.org/show_bug.cgi?id=108992
--- Comment #21 from Zheng Luo ---
With iommu=soft I still occasionally experience frozen screen with following
logs:
Jan 02 16:11:18 lzThinkpad gnome-shell[1647]: Failed to flip: Cannot allocate
memory
Jan 02 16:11:18 lzThinkpad kernel: amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=109177
--- Comment #4 from MirceaKitsune ---
Created attachment 142947
--> https://bugs.freedesktop.org/attachment.cgi?id=142947&action=edit
dmesg.txt
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=109177
--- Comment #5 from MirceaKitsune ---
Created attachment 142948
--> https://bugs.freedesktop.org/attachment.cgi?id=142948&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=109177
--- Comment #6 from MirceaKitsune ---
Created attachment 142949
--> https://bugs.freedesktop.org/attachment.cgi?id=142949&action=edit
Xorg.0.log.old
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=109171
--- Comment #5 from Sherif ---
Created attachment 142951
--> https://bugs.freedesktop.org/attachment.cgi?id=142951&action=edit
I used something like dmesg | vim.
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=109171
--- Comment #6 from Sherif ---
Sorry, I didn't pay attention to the dmesg part.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.fre
52 matches
Mail list logo
