On Tue, Jan 08, 2019 at 02:41:25PM +0530, Uma Shankar wrote:
> From: Ville Syrjälä
>
> ADD HLG EOTF to the list of EOTF transfer functions supported.
> Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
> HLG defines a nonlinear transfer function in which the lower
> half of the
On Tue, 2019-01-08 at 16:17 -0500, Alex Deucher wrote:
> On Tue, Jan 8, 2019 at 4:11 PM Lyude Paul wrote:
> > Fix the suspend/issues that Jerry Zuo found in amdgpu, and add some
> > compiler warnings for drivers ignoring the return code of
> > drm_dp_mst_topology_mgr_resume() to help ensure we
https://bugs.freedesktop.org/show_bug.cgi?id=109246
--- Comment #10 from Alex Deucher ---
(In reply to Michel Dänzer from comment #8)
>
> This does look like there are hotplug events, and the HDMI output is
> considered disconnected for a moment.
When the monitor enters dpms, it starts polling
From: Nicholas Kazlauskas
[ Upstream commit f41a895026b8cb6f765190de7d2e7bc3ccbbd183 ]
[Why]
The igt@kms_plane@pixel-format-pipe tests can create a sequence where
stream_state is NULL during amdgpu_dm_crtc_set_crc_source which results
in a null pointer dereference.
[How]
Guard against
Move drm_can_sleep() out of drmP.h to allow users
to get rid of the drmP.h include.
There was no header file that was a good match for this helper function.
So add this to drm_util with the relevant includes.
Update comments to use kernel-doc style.
Add FIXME to drm_can_sleep and add note
that
- drmP.h is now stripped down to include files and forward declarations.
- All header files in include/drm/ no longer include drmP.h.
The series was made on top of drm-misc-next
Build tested using arm and x86 all{yes,mod}config
The patches are trivial but touches a lot of files,
so a lot of
From: Ville Syrjälä
[ Upstream commit 2de42f79bb21a412f40ade8831eb6fc445cb78a4 ]
Consider the following scenario:
1. nonblocking enable crtc
2. wait for the event
3. nonblocking disable crtc
On i915 this can lead to a spurious -EBUSY from step 3 on
account of non-enabled planes getting the
drmP.h was the only header file in the past and a lot
of files rely on that drmP.h defines everything.
The goal is to one day to delete drmP.h and
as a step towards this it will no longer be included in the
headers files in include/drm/
To prepare tinydrm/ for this add dependencies that
othwewise
drmP.h is an relic from the days when there was a single header file.
To enable the removal of drmP.h from all users drop include
of drmP.h from drm_modeset_helper.h.
A few files relied on the file included in drmP.h - add explicit
include statements to these files.
Build tested with arm and x86.
Move DRM_SWITCH_POWER out of drmP.h to allow users
to get rid of the drmP include.
Moved to drm_device.h because drm_device.switch_power_state
is the only user.
Converted to enum and added sparse kerneldoc comments.
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean
From: Christian König
[ Upstream commit 2383a767c0ca06f96534456d8313909017c6c8d0 ]
Vega10 has multiple interrupt rings, so this can be called from multiple
calles at the same time resulting in:
[ 71.779334]
[ 71.779406] WARNING: inconsistent lock state
[
drmP.h was the only header file in the past and a lot
of files rely on that drmP.h defines everything.
The goal is to one day to delete drmP.h and
as a step towards this it will no longer be included in the
headers files in include/drm/
To prepare stm/ for this add dependencies that
othwewise was
No further changes required.
Signed-off-by: Sam Ravnborg
Acked-by: Noralf Trønnes
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
---
include/drm/drm_encoder_slave.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drm_encoder_slave.h
With all dependencies fixed we can now remove
drmP.h from drm_gem_cma_helper.h.
It is replaced by the include files required,
or forward declarations as appropritate.
Signed-off-by: Sam Ravnborg
Acked-by: Noralf Trønnes
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
From: Nicholas Kazlauskas
[ Upstream commit 520f08df45fbe300ed650da786a74093d658b7e1 ]
When variable refresh rate is active the hardware counter can return
a position >= vtotal. This results in a vpos being returned from
amdgpu_display_get_crtc_scanoutpos that's a positive value. The
positive
From: Chris Wilson
[ Upstream commit 3b34c14fd50c302db091f020f26dd00ede902c80 ]
As amd_uvd_resume() accesses the uvd ring, it must be initialised first
or else we trigger errors like:
[5.595963] [drm] Found UVD firmware Version: 1.87 Family ID: 17
[5.595969] [drm] PSP loading UVD
This is an ugly one unfortunately. Currently, all DRM drivers supporting
atomic modesetting will save the state that userspace had set before
suspending, then attempt to restore that state on resume. This probably
worked very well at one point, like many other things, until DP MST came
into the
Since I've had to fix two cases of drivers not checking the return code
from this function, let's make the compiler complain so this doesn't
come up again in the future.
Changes since v1:
* Remove unneeded __must_check in function declaration - danvet
Signed-off-by: Lyude Paul
Cc: Jerry Zuo
drm_dp_mst_topology_mgr_resume() returns whether or not it managed to
find the topology in question after a suspend resume cycle, and the
driver is supposed to check this value and disable MST accordingly if
it's gone-in addition to sending a hotplug in order to notify userspace
that something
From: Daniele Castagna
Currently, YUV hardware overlays are converted to RGB using
a color space conversion different than BT.601.
The result is that colors of e.g. NV12 buffers don't match
colors of YUV hardware overlays.
In order to fix this, enable YUV2YUV and set appropriate coefficients
On Tue, 2019-01-08 at 14:12 +0100, h...@lst.de wrote:
> On Tue, Jan 08, 2019 at 09:51:45AM +, Thomas Hellstrom wrote:
> > Hi, Christoph,
> >
> > On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote:
> > > Hi Thomas,
> > >
> > > vmwgfx has been doing some odd checks based on DMA ops
https://bugs.freedesktop.org/show_bug.cgi?id=109246
--- Comment #9 from tme ---
I've tested some more kernels, all from
https://kernel.ubuntu.com/~kernel-ppa/mainline/.
Setting amdgpu.dc=1 on 4.15.18 and 4.16.18 does not reproduce the problem. It
does, however, reproduce on 4.17.19.
Also, I
From: Christian König
[ Upstream commit 2383a767c0ca06f96534456d8313909017c6c8d0 ]
Vega10 has multiple interrupt rings, so this can be called from multiple
calles at the same time resulting in:
[ 71.779334]
[ 71.779406] WARNING: inconsistent lock state
[
From: Trigger Huang
[ Upstream commit 85744e9c100696d3f210e80b85fd56dd19767c81 ]
A bad job is the one triggered TDR(In the current amdgpu's
implementation, actually all the jobs in the current joq-queue will
be treated as bad jobs). In the recovery process, its fence
will be fake signaled and
From: Nicholas Kazlauskas
[ Upstream commit f41a895026b8cb6f765190de7d2e7bc3ccbbd183 ]
[Why]
The igt@kms_plane@pixel-format-pipe tests can create a sequence where
stream_state is NULL during amdgpu_dm_crtc_set_crc_source which results
in a null pointer dereference.
[How]
Guard against
From: Nicholas Kazlauskas
[ Upstream commit 520f08df45fbe300ed650da786a74093d658b7e1 ]
When variable refresh rate is active the hardware counter can return
a position >= vtotal. This results in a vpos being returned from
amdgpu_display_get_crtc_scanoutpos that's a positive value. The
positive
Hi Christoph
On Thu, Jan 03, 2019 at 12:16:46AM -0800, Christoph Hellwig wrote:
> On Sun, Dec 30, 2018 at 06:48:31PM +0100, Sam Ravnborg wrote:
> > +/*
> > + * Use EXPORT_SYMBOL_FOR_TESTS_ONLY() for functions that shall
> > + * only be visible for drmselftests.
> > + */
> > +#if
https://bugs.freedesktop.org/show_bug.cgi?id=109246
--- Comment #8 from Michel Dänzer ---
>From the Xorg log file:
[ 212.439] (II) AMDGPU(0): Allocate new frame buffer 1440x900
[ 212.439] (II) AMDGPU(0): => pitch 6144 bytes
[ 212.639] (II) AMDGPU(0): Allocate new frame buffer 3360x1080
[
On Tue, Jan 8, 2019 at 4:07 PM Russell King - ARM Linux
wrote:
>
> On Tue, Jan 08, 2019 at 03:33:54PM +0100, Andrzej Hajda wrote:
> > On 08.01.2019 14:21, Russell King - ARM Linux wrote:
> > > On Tue, Jan 08, 2019 at 01:27:56PM +0100, Andrzej Hajda wrote:
> > >> On 08.01.2019 12:38, Russell King
On Tue, Jan 8, 2019 at 3:51 PM Paul Kocialkowski
wrote:
>
> During an atomic commit, the HVS is configured with a display list
> for the channel matching the associated CRTC. The Pixel Valve (CRTC)
> and encoder are also configured for the new setup at that time.
> While the Pixel Valve and
From: Nicholas Kazlauskas
[ Upstream commit 520f08df45fbe300ed650da786a74093d658b7e1 ]
When variable refresh rate is active the hardware counter can return
a position >= vtotal. This results in a vpos being returned from
amdgpu_display_get_crtc_scanoutpos that's a positive value. The
positive
On 2019-01-04 7:14 p.m., Lyude Paul wrote:
> 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
On Tue, 2019-01-08 at 19:57 +, Wentland, Harry wrote:
> On 2019-01-04 7:14 p.m., Lyude Paul wrote:
> > 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
On Tue, Jan 8, 2019 at 4:11 PM Lyude Paul wrote:
>
> Fix the suspend/issues that Jerry Zuo found in amdgpu, and add some
> compiler warnings for drivers ignoring the return code of
> drm_dp_mst_topology_mgr_resume() to help ensure we don't need to fix
> this again in the future for someone else's
On 2018-12-19 7:19 p.m., Lyude Paul wrote:
> 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
Add forward declaration and pull in include
file to make drm_framebuffer.h self contained.
While add it order include files alphabetically.
The use of TASK_COMM_LEN is the reason for including sched.h.
I could not see any good way to avoid this dependency,
and users of drm_framebuffer.comm
drmP.h was the only header file in the past and a lot
of files rely on that drmP.h defines everything.
The goal is to one day to delete drmP.h and
as a step towards this it will no longer be included in the
headers files in include/drm/
To prepare arc/ for this add dependencies that
othwewise was
Updated comment style to kernel-doc format in drm_device.h
In struct drm_device there are 12 struct members without doc:
- registered
- filelist_mutex
- filelist
- irq
- vbl_lock
- event_lock
- hose
- sigdata
- sigdata.context
- sigdata.lock
- agp_buffer_map
- agp_buffer_token
They all need
drmP.h is an relic from the days when there was a single header file.
To enable the removal of drmP.h from all users drop include
of drmP.h from bridge/dw_hdmi.h.
A few files relied on the file included in drmP.h - add explicit
include statements or forward declarations to these files.
Build
In the quest to get rid of drmP.h move the newly
added EXPORT_SYMBOL_FOR_TESTS_ONLY to drm_util.h.
Fix the single user.
Add a note to drmP.h to avoid further use of it.
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
---
From: Nicholas Kazlauskas
[ Upstream commit 520f08df45fbe300ed650da786a74093d658b7e1 ]
When variable refresh rate is active the hardware counter can return
a position >= vtotal. This results in a vpos being returned from
amdgpu_display_get_crtc_scanoutpos that's a positive value. The
positive
Fix the suspend/issues that Jerry Zuo found in amdgpu, and add some
compiler warnings for drivers ignoring the return code of
drm_dp_mst_topology_mgr_resume() to help ensure we don't need to fix
this again in the future for someone else's driver.
Cc: Jerry Zuo
Lyude Paul (3):
drm/amdgpu:
From: Nicholas Kazlauskas
[ Upstream commit 520f08df45fbe300ed650da786a74093d658b7e1 ]
When variable refresh rate is active the hardware counter can return
a position >= vtotal. This results in a vpos being returned from
amdgpu_display_get_crtc_scanoutpos that's a positive value. The
positive
On 2018-12-19 7:19 p.m., Lyude Paul wrote:
> 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
On 2019-01-04 7:14 p.m., Lyude Paul wrote:
> 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
From: Chris Wilson
[ Upstream commit 3b34c14fd50c302db091f020f26dd00ede902c80 ]
As amd_uvd_resume() accesses the uvd ring, it must be initialised first
or else we trigger errors like:
[5.595963] [drm] Found UVD firmware Version: 1.87 Family ID: 17
[5.595969] [drm] PSP loading UVD
From: Ville Syrjälä
[ Upstream commit 2de42f79bb21a412f40ade8831eb6fc445cb78a4 ]
Consider the following scenario:
1. nonblocking enable crtc
2. wait for the event
3. nonblocking disable crtc
On i915 this can lead to a spurious -EBUSY from step 3 on
account of non-enabled planes getting the
On 2018-12-19 7:19 p.m., Lyude Paul wrote:
> 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
> Reviewed-by: Daniel Vetter
> Cc: David Airlie
>
On 2018-12-19 7:19 p.m., Lyude Paul wrote:
> 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
>
https://bugs.freedesktop.org/show_bug.cgi?id=109239
--- Comment #5 from Raman Gupta ---
(In reply to Michel Dänzer from comment #4)
> When you wrote "modesetting", you meant "DC". So the problem is the same
> with or without DC?
Yes, DC does not make a difference.
> Does it also happen with
18. 12. 20. 오전 12:57에 Paweł Chmiel 이(가) 쓴 글:
> This commit adds support for s5pv210.
> Currently only NV12 and XRGB formats are supported.
> It was tested by using tool from
> https://www.spinics.net/lists/linux-samsung-soc/msg60498.html
>
> Signed-off-by: Paweł Chmiel
Applied.
Thanks,
https://bugs.freedesktop.org/show_bug.cgi?id=109229
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #5 from Timothy
Hi,
On Tue, Dec 18, 2018 at 2:57 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Dec 18, 2018 at 10:33 AM Jordan Crouse wrote:
> >
> > Add the nodes to describe the Adreno GPU and GMU devices.
> >
> > Signed-off-by: Jordan Crouse
> > ---
> >
> > v7: Updated the GMU compatible string and removed
Hi Chandan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v5.0-rc1 next-20190108]
[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
Hi Chandan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v5.0-rc1 next-20190108]
[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
Hi Daniel,
On Tue, 8 Jan 2019 09:37:22 +0100 Daniel Vetter wrote:
>
>
> https://cgit.freedesktop.org/drm-tip/tree/fixups/drm-misc-next.patch?h=rerere-cache
>
> is the fixup you want. Should get baked into drm-next any moment, since
> the first drm-misc-next pull is already out.
I added that
Hi Uma,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.0-rc1 next-20190108]
[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
https://bugs.freedesktop.org/show_bug.cgi?id=109246
--- Comment #11 from Nathan Patera ---
I have the same exact bug as a secondary confirmation of this bug. I am
currently using kernel version 4.15.0-42-generic with an RX 580
--
You are receiving this mail because:
You are the assignee for
Fix some indenting, split some stuff across multiple lines.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff
Split some stuff across multiple lines, remove some unnecessary braces
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 14 --
1 file changed, 8 insertions(+), 6
Reindent some stuff, and split some stuff across multiple lines so we
aren't going over the text width limit.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 18
Hi Uma,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.0-rc1 next-20190108]
[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
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
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
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
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
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
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
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
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:
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
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
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
Split some stuff across multiple lines
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
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
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
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
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
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
Reviewed-by: Harry Wentland
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
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
Hi Uma,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.0-rc1 next-20190108]
[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
Hi Uma,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.0-rc1 next-20190108]
[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
On Tue, Jan 08, 2019 at 01:27:56PM +0100, Andrzej Hajda wrote:
> On 08.01.2019 12:38, Russell King - ARM Linux wrote:
> > On Tue, Jan 08, 2019 at 12:25:34PM +0100, Andrzej Hajda wrote:
> >> Issues with device links have nothing to do with hotplugging, they are
> >> generic - lifetime of the
https://bugs.freedesktop.org/show_bug.cgi?id=109217
--- Comment #3 from fin4...@hotmail.com ---
Created attachment 143010
--> https://bugs.freedesktop.org/attachment.cgi?id=143010=edit
Xorg log
This bug is present in the 5.0-rc1 kernel too.
--
You are receiving this mail because:
You are the
On Tue, Jan 08, 2019 at 12:39:36AM +, Russell King - ARM Linux wrote:
> On Mon, Jan 07, 2019 at 10:55:15PM +0100, Daniel Vetter wrote:
> > On Mon, Jan 7, 2019 at 5:13 PM Russell King - ARM Linux
> > wrote:
> > >
> > > On Mon, Jan 07, 2019 at 11:45:32AM +0100, Daniel Vetter wrote:
> > > > On
https://bugs.freedesktop.org/show_bug.cgi?id=109246
--- Comment #5 from Alex Deucher ---
Do you have an option in your monitor's menu to poll inputs? If so can you
disable it? Some monitors poll inputs which sometimes causes the hpd pin to
fire which looks like a hotplug event to the driver.
On Tue, 2019-01-08 at 11:43 +0100, Gerd Hoffmann wrote:
> On Thu, Jan 03, 2019 at 01:16:00PM -0300, Ezequiel Garcia wrote:
> > Move the code around so the driver is probed the bus
> > .probe and removed from the bus .remove callbacks.
> > This commit is just a cleanup and shouldn't affect
> >
On Tue, Jan 08, 2019 at 03:33:54PM +0100, Andrzej Hajda wrote:
> On 08.01.2019 14:21, Russell King - ARM Linux wrote:
> > On Tue, Jan 08, 2019 at 01:27:56PM +0100, Andrzej Hajda wrote:
> >> On 08.01.2019 12:38, Russell King - ARM Linux wrote:
> >>> On Tue, Jan 08, 2019 at 12:25:34PM +0100, Andrzej
On Mon, Jan 7, 2019 at 11:36 AM Daniel Vetter wrote:
>
> On Wed, Jan 02, 2019 at 09:49:17AM +0100, Frank Wunderlich wrote:
> > From: CK Hu
> >
> > This patch adds Framebuffer-Driver for Mediatek
> >
> > currently tested on mt7623, maybe works on other platforms
> > MTK-FBDev written by CK Hu and
Hi Uma,
On Thu, Dec 27, 2018 at 11:22:37PM +0530, Uma Shankar wrote:
> This patch adds a colorspace connector property, enabling
> userspace to switch to various supported colorspaces.
> This will help enable BT2020 along with other colorspaces.
>
> v2: Addressed Maarten and Ville's review
Move the code around so the driver is probed the bus
.probe and removed from the bus .remove callbacks.
This commit is just a cleanup and shouldn't affect
functionality.
Signed-off-by: Ezequiel Garcia
---
v2: rebased on drm-misc-next
drivers/gpu/drm/virtio/Makefile | 2 +-
https://bugs.freedesktop.org/show_bug.cgi?id=109217
--- Comment #2 from fin4...@hotmail.com ---
Created attachment 143009
--> https://bugs.freedesktop.org/attachment.cgi?id=143009=edit
5.0-rc1 dmesg
This bug is present in the 5.0-rc1 kernel too.
--
You are receiving this mail because:
You
On Tue, Jan 8, 2019 at 2:22 PM Russell King - ARM Linux
wrote:
> On Tue, Jan 08, 2019 at 01:27:56PM +0100, Andrzej Hajda wrote:
> > On 08.01.2019 12:38, Russell King - ARM Linux wrote:
> > > On Tue, Jan 08, 2019 at 12:25:34PM +0100, Andrzej Hajda wrote:
> > >> Issues with device links have
https://bugs.freedesktop.org/show_bug.cgi?id=108585
--- Comment #19 from Dan Horák ---
They (=
https://src.fedoraproject.org/fork/sharkcz/rpms/kernel/blob/talos/f/ppc64-talos-amdgpu-reset.patch)
can go upstream.
I have a 4.20 kernel on the host with recent firmware for polaris11, the
skiroot
On 1/8/19 3:37 AM, Daniel Vetter wrote:
> On Tue, Jan 08, 2019 at 11:12:41AM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the drm-misc tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In
https://bugs.freedesktop.org/show_bug.cgi?id=108464
--- Comment #16 from Harry Wentland ---
Created attachment 143011
--> https://bugs.freedesktop.org/attachment.cgi?id=143011=edit
[PATCH] drm/amd/display: Limit number of links to num_ddc
Can you see if this patch helps you?
--
You are
Hi Uma,
On Thu, Dec 27, 2018 at 11:22:36PM +0530, Uma Shankar wrote:
> This patch series creates a new connector property to program
> colorspace to sink devices. Modern sink devices support more
> than 1 type of colorspace like 601, 709, BT2020 etc. This helps
> to switch based on content type
On 08.01.2019 14:21, Russell King - ARM Linux wrote:
> On Tue, Jan 08, 2019 at 01:27:56PM +0100, Andrzej Hajda wrote:
>> On 08.01.2019 12:38, Russell King - ARM Linux wrote:
>>> On Tue, Jan 08, 2019 at 12:25:34PM +0100, Andrzej Hajda wrote:
Issues with device links have nothing to do with
In order to test whether the load tracker is working as expected, we
need the ability to compare the commit result with the underrun
indication. With the load tracker always enabled, commits that are
expected to trigger an underrun are always rejected, so userspace
cannot get the actual underrun
From: Boris Brezillon
The DRM framework provides a generic way to report underrun errors.
Let's implement the necessary hooks to support it in the VC4 driver.
Signed-off-by: Boris Brezillon
---
Changes in v3:
- Generic underrun report function has been dropped, adjust the
code accordingly
1 - 100 of 203 matches
Mail list logo
