On Mon, May 06, 2019 at 04:50:20PM -0300, Jason Gunthorpe wrote:
> On Mon, May 06, 2019 at 06:30:59PM +0200, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0
https://bugs.freedesktop.org/show_bug.cgi?id=109649
--- Comment #7 from Jan Vesely ---
The workaround is still necessary in kernel 5.1.0.
The failure mode is a bit different, it hangs just the application, not entire
machine.
--
You are receiving this mail because:
You are the assignee for the
From: Lucas Stach
[ Upstream commit d4fad0a426c6e26f48c9a7cdd21a7fe9c198d645 ]
Initialize the flow input colorspaces to unknown and reset to that value
when the channel gets disabled. This avoids the state getting mixed up
with a previous mode.
Also keep the CSC settings for the background flow
From: Lucas Stach
[ Upstream commit d4fad0a426c6e26f48c9a7cdd21a7fe9c198d645 ]
Initialize the flow input colorspaces to unknown and reset to that value
when the channel gets disabled. This avoids the state getting mixed up
with a previous mode.
Also keep the CSC settings for the background flow
From: Lucas Stach
[ Upstream commit d4fad0a426c6e26f48c9a7cdd21a7fe9c198d645 ]
Initialize the flow input colorspaces to unknown and reset to that value
when the channel gets disabled. This avoids the state getting mixed up
with a previous mode.
Also keep the CSC settings for the background flow
From: Paul Kocialkowski
[ Upstream commit 02b92adbe33e6dbd15dc6e32540b22f47c4ff0a2 ]
Our sun4i_drv_unbind gets the drm device using dev_get_drvdata.
However, that driver data is never set in sun4i_drv_bind.
Set it there to avoid getting a NULL pointer at unbind time.
Fixes: 9026e0d122ac ("drm:
From: Damian Kos
[ Upstream commit e4056bbb6719fe713bfc4030ac78e8e97ddf7574 ]
This is basically the same fix as in
commit fa68d4f8476b ("drm/rockchip: fix for mailbox read size")
but for cdn_dp_mailbox_validate_receive function.
See patchwork.kernel.org/patch/10671981/ for details.
Signed-off-
From: Enric Balletbo i Serra
[ Upstream commit 4eda776c3cefcb1f01b2d85bd8753f67606282b5 ]
'encoder' is dereferenced before it is null sanity checked, hence we
potentially have a null pointer dereference bug. Instead, initialise
drm_drv from encoder->dev->dev_private after we are sure 'encoder' i
From: Ville Syrjälä
[ Upstream commit 03981c6ebec4fc7056b9b45f847393aeac90d060 ]
I have a Thinkpad X220 Tablet in my hands that is losing vblank
interrupts whenever LP3 watermarks are used.
If I nudge the latency value written to the WM3 register just
by one in either direction the problem disa
From: Chris Wilson
[ Upstream commit 86c1c87d0e6241cbe35bd52badfc84b154e1b959 ]
According to intel_read_wm_latency() it is perfectly legal for one WM
and all subsequent levels to be 0 (and the deeper powersaving states
disabled), so don't shout *ERROR*, over and over again.
Signed-off-by: Chris
From: Paul Kocialkowski
[ Upstream commit 02b92adbe33e6dbd15dc6e32540b22f47c4ff0a2 ]
Our sun4i_drv_unbind gets the drm device using dev_get_drvdata.
However, that driver data is never set in sun4i_drv_bind.
Set it there to avoid getting a NULL pointer at unbind time.
Fixes: 9026e0d122ac ("drm:
From: Lucas Stach
[ Upstream commit d4fad0a426c6e26f48c9a7cdd21a7fe9c198d645 ]
Initialize the flow input colorspaces to unknown and reset to that value
when the channel gets disabled. This avoids the state getting mixed up
with a previous mode.
Also keep the CSC settings for the background flow
From: Lucas Stach
[ Upstream commit 7bcde275eb1d0ac8793c77c7e666a886eb16633d ]
In order to make sure that the plane color space gets reset correctly.
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +-
1 file change
From: Paul Kocialkowski
[ Upstream commit 02b92adbe33e6dbd15dc6e32540b22f47c4ff0a2 ]
Our sun4i_drv_unbind gets the drm device using dev_get_drvdata.
However, that driver data is never set in sun4i_drv_bind.
Set it there to avoid getting a NULL pointer at unbind time.
Fixes: 9026e0d122ac ("drm:
From: Lucas Stach
[ Upstream commit 7bcde275eb1d0ac8793c77c7e666a886eb16633d ]
In order to make sure that the plane color space gets reset correctly.
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +-
1 file change
From: Paul Kocialkowski
[ Upstream commit f5a9ed867c83875546c9aadd4ed8e785e9adcc3c ]
For our component-backed driver to be properly removed, we need to
delete the component master in sun4i_drv_remove and make sure to call
component_unbind_all in the master's unbind so that all components are
unb
From: Lucas Stach
[ Upstream commit d4fad0a426c6e26f48c9a7cdd21a7fe9c198d645 ]
Initialize the flow input colorspaces to unknown and reset to that value
when the channel gets disabled. This avoids the state getting mixed up
with a previous mode.
Also keep the CSC settings for the background flow
From: Paul Kocialkowski
[ Upstream commit e02bc29b2cfa7806830d6da8b2322cddd67e8dfe ]
Our components may still be using the DRM device driver (if only to
access our driver's private data), so make sure to unbind them before
the final drm_dev_put.
Also release our reserved memory after component
From: David Francis
[ Upstream commit c238bfe0be9ef7420f7669a69e27c8c8f4d8a568 ]
[Why]
On some compositors, with two monitors attached, VT terminal
switch can cause a graphical issue by the following means:
There are two streams, one for each monitor. Each stream has one
plane
current state:
From: Martin Leung
[ Upstream commit f4bbebf8e7eb4d294b040ab2d2ba71e70e69b930 ]
[Why]
AUX takes longer to reply when using active DP-DVI dongle on some asics
resulting in up to 2000+ us edid read (timeout).
[How]
1. Adjust AUX poll to match spec
2. Extend the SW timeout. This does not affect no
From: Damian Kos
[ Upstream commit e4056bbb6719fe713bfc4030ac78e8e97ddf7574 ]
This is basically the same fix as in
commit fa68d4f8476b ("drm/rockchip: fix for mailbox read size")
but for cdn_dp_mailbox_validate_receive function.
See patchwork.kernel.org/patch/10671981/ for details.
Signed-off-
From: Lucas Stach
[ Upstream commit 7bcde275eb1d0ac8793c77c7e666a886eb16633d ]
In order to make sure that the plane color space gets reset correctly.
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +-
1 file change
From: Paul Kocialkowski
[ Upstream commit e02bc29b2cfa7806830d6da8b2322cddd67e8dfe ]
Our components may still be using the DRM device driver (if only to
access our driver's private data), so make sure to unbind them before
the final drm_dev_put.
Also release our reserved memory after component
From: Paul Kocialkowski
[ Upstream commit f5a9ed867c83875546c9aadd4ed8e785e9adcc3c ]
For our component-backed driver to be properly removed, we need to
delete the component master in sun4i_drv_remove and make sure to call
component_unbind_all in the master's unbind so that all components are
unb
From: Paul Kocialkowski
[ Upstream commit 02b92adbe33e6dbd15dc6e32540b22f47c4ff0a2 ]
Our sun4i_drv_unbind gets the drm device using dev_get_drvdata.
However, that driver data is never set in sun4i_drv_bind.
Set it there to avoid getting a NULL pointer at unbind time.
Fixes: 9026e0d122ac ("drm:
From: Dave Airlie
[ Upstream commit a0cecc23cfcbf2626497a8c8770856dd56b67917 ]
This patch does more harm than good, as it breaks both Xwayland and
gnome-shell with X11.
Xwayland requires DRI3 & DRI3 requires PRIME.
X11 crash for obscure double-free reason which are hard to debug
(starting X11
From: Jonas Karlman
[ Upstream commit d15d9fd02575ecfada92d42f655940c4f10af842 ]
The Rockchip RK3288 SoC (v2.00a) and RK3328/RK3399 SoCs (v2.11a) have
also been identified as needing this workaround with a single iteration.
Fixes: be41fc55f1aa ("drm: bridge: dw-hdmi: Handle overflow workaround
From: Lucas Stach
[ Upstream commit d4fad0a426c6e26f48c9a7cdd21a7fe9c198d645 ]
Initialize the flow input colorspaces to unknown and reset to that value
when the channel gets disabled. This avoids the state getting mixed up
with a previous mode.
Also keep the CSC settings for the background flow
From: wentalou
[ Upstream commit b575f10dbd6f84c2c8744ff1f486bfae1e4f6f38 ]
shadow was added into shadow_list by amdgpu_bo_create_shadow.
meanwhile, shadow->tbo.mem was not fully configured.
tbo.mem would be fully configured by amdgpu_vm_sdma_map_table until calling
amdgpu_vm_clear_bo.
If sriov
From: David Francis
[ Upstream commit c238bfe0be9ef7420f7669a69e27c8c8f4d8a568 ]
[Why]
On some compositors, with two monitors attached, VT terminal
switch can cause a graphical issue by the following means:
There are two streams, one for each monitor. Each stream has one
plane
current state:
From: Martin Leung
[ Upstream commit f4bbebf8e7eb4d294b040ab2d2ba71e70e69b930 ]
[Why]
AUX takes longer to reply when using active DP-DVI dongle on some asics
resulting in up to 2000+ us edid read (timeout).
[How]
1. Adjust AUX poll to match spec
2. Extend the SW timeout. This does not affect no
From: Lin Yi
[ Upstream commit 543c364d8eeeb42c0edfaac9764f4e9f3d777ec1 ]
the ttm_bo_add_move_fence takes a reference to the struct dma_fence, but
failed to release it on the error path, leading to a memory leak.
add dma_fence_put before return when error occur.
Signed-off-by: Lin Yi
Reviewed-
https://bugs.freedesktop.org/show_bug.cgi?id=88275
Timothy Arceri changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
Nag nag: The below documentation patch, acked-by Daniel and r-b'd by
Nicholas seems to not have made it into drm-next yet?
thanks,
-mario
On Thu, Apr 18, 2019 at 2:45 PM Kazlauskas, Nicholas
wrote:
>
> On 4/18/19 2:01 AM, Mario Kleiner wrote:
> > As discussed with Nicholas and Daniel Vetter (pat
https://bugs.freedesktop.org/show_bug.cgi?id=37274
Timothy Arceri changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=44344
Timothy Arceri changed:
What|Removed |Added
Component|Mesa core |Drivers/Gallium/i915g
Assigne
https://bugs.freedesktop.org/show_bug.cgi?id=108893
--- Comment #19 from Timothy Arceri ---
I installed the game via Proton. Seems it is still very buggy in wine. I had to
follow the instructions here [1] to get it to load without crashing or
constantly changing the screen between windowed and fu
https://bugs.freedesktop.org/show_bug.cgi?id=101769
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #3 from Timothy A
On Fri, 3 May 2019 at 22:17, Daniel Vetter wrote:
>
> On Fri, May 03, 2019 at 10:29:48AM +0100, Liviu Dudau wrote:
> > On Fri, May 03, 2019 at 11:15:23AM +0200, Daniel Vetter wrote:
> > > On Fri, May 3, 2019 at 11:11 AM Liviu Dudau wrote:
> > > >
> > > > On Fri, May 03, 2019 at 09:54:35AM +1000,
https://bugs.freedesktop.org/show_bug.cgi?id=100239
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
On 6 May 2019, at 09:16, Daniel Vetter wrote:
> On Sat, May 04, 2019 at 09:43:14PM +0100, James Clarke wrote:
>> On 15 Jan 2019, at 18:41, Eric Anholt wrote:
>>>
>>> Daniel Vetter writes:
>>>
On Tue, Jan 15, 2019 at 03:04:18PM +, James Clarke wrote:
> Like GNU/Linux, GNU/kFreeBSD'
https://bugzilla.kernel.org/show_bug.cgi?id=203525
--- Comment #5 from Erik (erikjohans...@flashbox.5july.org) ---
By adding commit b59dfdaef173677b0b7e10f375226c0a1114fd20 i was able to boot
4.19.36.
I tried 4.19.36 but it was broken.
4.19.36 broken and 4.19.37 fixed.
I then ran a bisect but i wa
On Mon, May 06, 2019 at 06:56:03PM +0200, Daniel Vetter wrote:
> On Thu, May 02, 2019 at 06:52:56PM +0530, Ramalingam C wrote:
> > On every hdcp revocation check request SRM is read from fw file
> > /lib/firmware/display_hdcp_srm.bin
> >
> > SRM table is parsed and stored at drm_hdcp.c, with funct
> On Sun, May 5, 2019 at 5:19 PM Frank Rowand wrote:
> > You can see the full version 14 document in the submitter's repo:
> >
> > $ git clone https://github.com/isaacs/testanything.github.io.git
> > $ cd testanything.github.io
> > $ git checkout tap14
> > $ ls tap-version-14-specification
> On 5/3/19 4:14 PM, Brendan Higgins wrote:
> >> On 5/2/19 10:36 PM, Brendan Higgins wrote:
> >>> On Thu, May 2, 2019 at 6:45 PM Frank Rowand
> >>> wrote:
>
> On 5/2/19 4:45 PM, Brendan Higgins wrote:
> > On Thu, May 2, 2019 at 2:16 PM Frank Rowand
> > wrote:
> >>
> >>
https://bugs.freedesktop.org/show_bug.cgi?id=110630
--- Comment #4 from Axel Davy ---
Created attachment 144181
--> https://bugs.freedesktop.org/attachment.cgi?id=144181&action=edit
dmesg (after capturing the issue)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=110630
--- Comment #3 from Axel Davy ---
Yes sure,
Here is a video:
http://dev.ipol.im/~adavy/green_lines.mp4
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
https://bugs.freedesktop.org/show_bug.cgi?id=110630
--- Comment #5 from Axel Davy ---
Created attachment 144182
--> https://bugs.freedesktop.org/attachment.cgi?id=144182&action=edit
Xorg log (after having the issue)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=110630
--- Comment #2 from Alex Deucher ---
Can you get a picture or video of the lines? Please attach your dmesg output
and xorg log (if using X).
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=110630
Axel Davy changed:
What|Removed |Added
Summary|Horizontal green lines |Random Horizontal green
|
https://bugs.freedesktop.org/show_bug.cgi?id=110614
--- Comment #5 from raffa...@zoho.com ---
Maybe I should have stated so explicitely,
ec6c2297634eba77248a929048cf4201887a5f0a is the first commit to crash. It looks
like it crashes even before calling si_texture_get_handle as there's nothing
logg
https://bugs.freedesktop.org/show_bug.cgi?id=110614
--- Comment #6 from Julien Isorce ---
This one
https://cgit.freedesktop.org/mesa/mesa/commit/?id=ec6c2297634eba77248a929048cf4201887a5f0a
?
or
https://cgit.freedesktop.org/mesa/mesa/commit/?id=a3c202de0a963c0562796cf75e3a9b3eedf1afad
?
Any cha
https://bugs.freedesktop.org/show_bug.cgi?id=110629
otrebor changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |intel-gfx-bugs@lists.freede
https://bugs.freedesktop.org/show_bug.cgi?id=95298
otrebor changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=110629
Bug ID: 110629
Summary: Intel i915 graphics driver issues with external
monitor when laptop in docking station (opensuse bug
1132926)
Product: Mesa
Version: unsp
Getting rotation info is cheap so we can do it on demand.
This is done in preparation for the removal of struct drm_fb_helper_crtc.
Cc: Hans de Goede
Signed-off-by: Noralf Trønnes
Acked-by: Daniel Vetter
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 131 ---
drm_fb_helper_is_bound() is used to check if DRM userspace is in control.
This is done by looking at the fb on the primary plane. By the time
fb-helper gets around to committing, it's possible that the facts have
changed.
Avoid this race by holding the drm_device->master_mutex lock while
committin
Prepare for moving drm_fb_helper modesetting code to drm_client.
drm_client will be linked to drm.ko, so move
__drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config()
out of drm_kms_helper.ko.
While at it, fix two checkpatch complaints:
- WARNING: Block comments use a trailing */ o
It now only contains the modeset so use that directly instead and attach
a modeset array to drm_client_dev. drm_fb_helper will use this array.
Code will later be moved to drm_client, so add code there in a new file
drm_client_modeset.c with MIT license to match drm_fb_helper.c.
The modeset connect
This moves the modesetting code from drm_fb_helper to drm_client so it
can be shared by all internal clients.
Changes this time:
- Use restore_fbdev_mode_force() in
drm_fb_helper_restore_fbdev_mode_unlocked() to please igt tests. I'm not
currently motivated to learn igt so I have added a todo
No functional changes, just moving code as-is and fixing includes.
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_client_modeset.c | 707 ++-
drivers/gpu/drm/drm_fb_helper.c | 692 --
include/drm/drm_client.h
All drivers add all their connectors so there's no need to keep around an
array of available connectors.
Rename functions which signature is changed since they will be moved to
drm_client in a later patch.
Signed-off-by: Noralf Trønnes
---
Documentation/gpu/todo.rst | 4 +
drivers/gpu/dr
This makes the necessary changes so the commit code can be moved out to
drm_client as-is in the next patch. It's split up to ease review.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 122 +---
1 file changed, 81 insertions(+), 41 deletions(-)
d
Move the modeset commit code to drm_client_modeset.
No changes except exporting API.
v2: Move to drm_client_modeset.c instead of drm_client.c
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client_modeset.c | 287 +++
drivers/gpu/drm/drm_fb_helper.c | 282
This prepares the modeset code so it can be moved out as-is in the next
patch.
v3: Remove stray newline
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 62 +++--
include/drm/drm_fb_helper.h | 4 ---
2 files changed
An example to showcase the client API.
TODO:
- A bootsplash client needs a way to tell drm_fb_helper to stay away,
otherwise it will chime in on setup and hotplug.
Most DRM drivers register fbdev before calling drm_dev_register() (the
generic emulation is an exception). This have to be rever
The values are already present in the modeset.
This is done in preparation for the removal of struct drm_fb_helper_crtc.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 12
include/drm/drm_fb_helper.h |
https://bugzilla.kernel.org/show_bug.cgi?id=203525
--- Comment #4 from Erik (erikjohans...@flashbox.5july.org) ---
Created attachment 282653
--> https://bugzilla.kernel.org/attachment.cgi?id=282653&action=edit
dmesg fixed 4.19.37
--
You are receiving this mail because:
You are watching the ass
On Thu, May 02, 2019 at 06:52:56PM +0530, Ramalingam C wrote:
> On every hdcp revocation check request SRM is read from fw file
> /lib/firmware/display_hdcp_srm.bin
>
> SRM table is parsed and stored at drm_hdcp.c, with functions exported
> for the services for revocation check from drivers (which
On Fri, May 3, 2019 at 4:04 AM Oded Gabbay wrote:
>
> amdkfd is now being upstreamed together with the amdgpu driver. Therefore,
> update the maintainer entry for the driver with the name of the amdgpu
> driver maintainer.
>
We use one tree, but Felix is the maintainer. Should probably put him
r
https://bugzilla.kernel.org/show_bug.cgi?id=203525
--- Comment #3 from Erik (erikjohans...@flashbox.5july.org) ---
Created attachment 282649
--> https://bugzilla.kernel.org/attachment.cgi?id=282649&action=edit
dmesg broken 4.19.35
--
You are receiving this mail because:
You are watching the as
https://bugzilla.kernel.org/show_bug.cgi?id=203525
--- Comment #2 from Erik (erikjohans...@flashbox.5july.org) ---
Created attachment 282647
--> https://bugzilla.kernel.org/attachment.cgi?id=282647&action=edit
dmesg fixed 4.19.39
--
You are receiving this mail because:
You are watching the ass
On Mon, May 06, 2019 at 05:57:53PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Mon, May 06, 2019 at 04:46:29PM +0200, Daniel Vetter wrote:
> > It's mandatory and considered core state since ioctls rely on this
> > working.
> >
> > Thanks to Laurent for pointin
Hello,
On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote:
> The patch series enables device drivers to use cgroups to control the
> following resources within a GPU (or other accelerator device):
> * control allocation of device memory (reuse of memcg)
> and with future work, we could e
On Mon, May 06, 2019 at 04:20:34PM +0200, Gerd Hoffmann wrote:
> On Mon, May 06, 2019 at 03:09:20PM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 06.05.19 um 14:22 schrieb Gerd Hoffmann:
> > >> GEM VRAM could implement PRIME helpers, which would allow for using
> > >> the generic fbcon.
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=110614
--- Comment #4 from Julien Isorce ---
So somehow the factoring is incorrect
https://cgit.freedesktop.org/mesa/mesa/commit/?id=1cec049d4db1c4dcd121bad17df4a77273dd9bb1
If you can log the values for offset and stride before and after this patch i
https://bugs.freedesktop.org/show_bug.cgi?id=110614
--- Comment #3 from raffa...@zoho.com ---
Tested both master and 8cd71f399e73c5d87e9162cc74da76e317a9f41f specifically,
but it still hangs and the stacktrace looks the same.
Any way I can help debug this?
--
You are receiving this mail because:
On Mon, May 6, 2019 at 4:56 AM Jagan Teki wrote:
>
> Hi Sam,
>
> On Thu, May 2, 2019 at 1:04 AM Sam Ravnborg wrote:
> >
> > Hi Jagan
> >
> > On Wed, May 01, 2019 at 05:44:47PM +0530, Jagan Teki wrote:
> > > HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
> > > resolution. It has
On Mon, May 06, 2019 at 10:05:07AM +, Koenig, Christian wrote:
> Am 06.05.19 um 10:04 schrieb Daniel Vetter:
> > [SNIP]
> + /* pin buffer into GTT */
> + return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
> >>> This is kinda what I mean with "shouldn't we pin the attachment" - afaiui
>
Hi Daniel,
Thank you for the patch.
On Mon, May 06, 2019 at 04:46:29PM +0200, Daniel Vetter wrote:
> It's mandatory and considered core state since ioctls rely on this
> working.
>
> Thanks to Laurent for pointing out this gap.
>
> v2: Clarify to "atomic drivers" only.
>
> Cc: Laurent Pinchart
It's mandatory and considered core state since ioctls rely on this
working.
Thanks to Laurent for pointing out this gap.
v2: Clarify to "atomic drivers" only.
Cc: Laurent Pinchart
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
include/drm/drm_connector.h | 4
1 file changed, 4 insertion
On Fri, May 03, 2019 at 11:28:13PM +0530, jagdsh.li...@gmail.com wrote:
> From: Jagadeesh Pagadala
>
> Remove duplicate headers which are included twice.
>
> Signed-off-by: Jagadeesh Pagadala
I collected some acks for the msm and nouveau parts and pushed this. For
next time around would be gre
https://bugs.freedesktop.org/show_bug.cgi?id=110614
--- Comment #2 from Julien Isorce ---
Can you try with latest master ? Should be fixed with:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=8cd71f399e73c5d87e9162cc74da76e317a9f41f
Sorry for the inconvenience
--
You are receiving this mail
On Mon, May 06, 2019 at 03:09:20PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 06.05.19 um 14:22 schrieb Gerd Hoffmann:
> >> GEM VRAM could implement PRIME helpers, which would allow for using
> >> the generic fbcon.
> >
> > bochs_gem_prime_*() functions with this series applied look like you can
https://bugs.freedesktop.org/show_bug.cgi?id=108514
Werner Lueckel changed:
What|Removed |Added
Version|unspecified |DRI git
--
You are receiving this mai
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #34 from Werner Lueckel ---
Is there any chance to get the patch implemented into 18.04 LTS?
The flickering screen is really annoying ...
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=110621
Andre Klapper changed:
What|Removed |Added
Resolution|FIXED |INVALID
Product|DRI
https://bugzilla.kernel.org/show_bug.cgi?id=203525
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugzilla.kernel.org/show_bug.cgi?id=203525
Bug ID: 203525
Summary: brightness with function buttons Acer Aspire A315-41
notebook with AMD Ryzen 5 2500U
Product: Drivers
Version: 2.5
Kernel Version: 4.19.37 5.0.11 5.1
Hi
Am 06.05.19 um 15:17 schrieb Gerd Hoffmann:
> Hi,
>
>> This misses the call to drm_gem_vram_placement(), where
>> drm_gem_vram_push_to_system() enforces placement in system memory.
>
> Ah, missed that detail.
>
>> We
>> could build a common implementation out of both interfaces, but that
>
On 04/23/2019 09:50 AM, Kefeng Wang wrote:
> Using dev_get_drvdata directly.
>
> Cc: Wan ZongShun
> Cc: Kukjin Kim
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Krzysztof Kozlowski
> Cc: Michal Januszewski
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Kefen
On 04/22/2019 03:27 PM, Mauro Carvalho Chehab wrote:
> Convert this small file to ReST in preparation for adding it to
> the driver-api book.
>
> While this is not part of the driver-api book, mark it as
> :orphan:, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab
Ack
On 04/22/2019 03:27 PM, Mauro Carvalho Chehab wrote:
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's a
On Mon, May 06, 2019 at 11:10:34AM +0200, Robert Foss wrote:
> virtio_gpu_fence_emit() always returns 0, since it
> has no error paths.
>
> Consequently no calls for virtio_gpu_fence_emit()
> use the return value, and it can be removed.
>
> Signed-off-by: Robert Foss
> Suggested-by: Emil Velikov
On 04/16/2019 10:25 PM, Arnd Bergmann wrote:
> These are two obscure ioctl commands, in a driver that only
> has compatible commands, so just let the driver handle this
> itself.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Bartlomiej Zolnierkiewicz
Best regards,
--
Bartlomiej Zolnierkiewicz
Sa
On 04/16/2019 04:55 AM, Mauro Carvalho Chehab wrote:
> Convert all documents here from plain txt to ReST format, in
> order to allow parsing them with the documentation build
> system.
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Bartlomiej Zolnierkiewicz
Best regards,
--
Bartlomiej Zol
On 04/02/2019 08:09 PM, Andreas Schwab wrote:
> When the logo is currently drawn on a virtual console, and the console
> loglevel is reduced to quiet, logo_shown must be left alone, so that it
> the scrolling region on that virtual console is properly reset.
>
> Fixes: 10993504d647 ("fbcon: Silen
Hi Hans
On Thu, May 02, 2019 at 10:24:00AM +0200, Hans Verkuil wrote:
> On 4/17/19 9:54 AM, Maxime Ripard wrote:
> > V4L2 uses different fourcc's than DRM, and has a different set of formats.
> > For now, let's add the v4l2 fourcc's for the already existing formats.
>
> For this lib to be more use
Hi,
> This misses the call to drm_gem_vram_placement(), where
> drm_gem_vram_push_to_system() enforces placement in system memory.
Ah, missed that detail.
> We
> could build a common implementation out of both interfaces, but that
> would obfuscate the code IMHO. I'd just leave it as it is.
O
Hi
Am 06.05.19 um 14:40 schrieb Gerd Hoffmann:
> Hi,
>
>> static const struct file_operations bochs_fops = {
>> .owner = THIS_MODULE,
>> -.open = drm_open,
>> -.release= drm_release,
>> -.unlocked_ioctl = drm_ioctl,
>> -.compat_ioctl = drm_comp
1 - 100 of 200 matches
Mail list logo
