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 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,
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 int
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 the
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
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,
Ink
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
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
Cc:
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 actual
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 that
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
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
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
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
---
driv
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
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
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 a/drivers/gpu/drm/drm_dp_
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
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 t
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
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 delet
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,
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
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 --git
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 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 re
https://bugs.freedesktop.org/show_bug.cgi?id=109229
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #5 from Timothy A
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
fo
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 don
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
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 chan
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 pic
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
Rev
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: Don't
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 idem
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
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 the
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 a
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 signa
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
> dm_dp_destroy_mst_connecto
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 defined(CONFIG_DRM
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 va
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 va
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 va
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 firmwa
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
C
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 va
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
[ 7
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
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 P
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 fake
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 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 peopl
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 stream_
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 th
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 prope
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 teste
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
---
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 alread
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 va
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 n
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 firmwa
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
>
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 fake
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 as
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 stream_
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
[ 7
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 drm_dp
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 now
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 simpli
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 whic
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 encode
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 -
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
[
Den 05.01.2019 19.25, skrev Noralf Trønnes:
>
>
> Den 24.12.2018 16.03, skrev Peter Wu:
>> On Mon, Dec 24, 2018 at 03:52:55PM +0100, Noralf Trønnes wrote:
>>>
>>>
>>> Den 24.12.2018 00.10, skrev Peter Wu:
On Sun, Dec 23, 2018 at 02:55:52PM +0100, Noralf Trønnes wrote:
>
>
> Den
Den 07.01.2019 13.39, skrev Gerd Hoffmann:
> Hi,
>
>> If register_framebuffer() fails during fbdev setup we will leak the
>> framebuffer, the GEM buffer and the shadow buffer for defio. This is
>> because drm_fb_helper_fbdev_setup() just calls drm_fb_helper_fini() on
>> error not taking into a
https://bugs.freedesktop.org/show_bug.cgi?id=109073
--- Comment #9 from whoop ---
Created attachment 143016
--> https://bugs.freedesktop.org/attachment.cgi?id=143016&action=edit
kern.log using kernel v5.0-rc1 with black screen before login without power
adapter plugged in
--
You are receiving
On Tue, Jan 8, 2019 at 9:16 AM Ioana Ciornei wrote:
>
>
> > Subject: [PATCH 2/2] drm/msm/gpu: fix building without debugfs
> >
> > When debugfs is disabled, but coredump is turned on, the adreno driver
> > fails to
> > build:
> >
> > drivers/gpu/drm/msm/adreno/a3xx_gpu.c:460:4: error: 'struct msm
https://bugs.freedesktop.org/show_bug.cgi?id=109073
--- Comment #8 from whoop ---
Without the power adapter connected v5.0-rc1 hangs with black screen at login
screen before actual login.
--
You are receiving this mail because:
You are the assignee for the bug.__
On 2019-01-07 7:56 p.m., 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 driver.
>
From: Ville Syrjälä
Fill out the AVI infoframe quantization range bits using
drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as well.
This changes the behaviour slightly as
drm_hdmi_avi_infoframe_quant_range() will set a non-zero Q bit
even when QS==0 iff the Q bit matched the default
From: Ville Syrjälä
Move the CEA-861 QS bit handling entirely into the edid code. No
need to bother the drivers with this.
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: amd-...@lists.freedesktop.org
Cc: Eric Anholt (supporter:DRM DRIVERS FOR VC4)
Signed-off-by: Ville
From: Ville Syrjälä
Fill out the AVI infoframe quantization range bits using
drm_hdmi_avi_infoframe_quant_range() instead of hand rolling it.
This changes the behaviour slightly as
drm_hdmi_avi_infoframe_quant_range() will set a non-zero Q bit
even when QS==0 iff the Q bit matched the default qu
From: Ville Syrjälä
Make life easier for drivers by simply passing the connector
to drm_hdmi_avi_infoframe_from_display_mode() and
drm_hdmi_avi_infoframe_quant_range(). That way drivers don't
need to worry about is_hdmi2_sink mess.
v2: Make is_hdmi2_sink() return true for sil-sii8620
Adapt t
On Mon, 2019-01-07 at 17:07 -0300, Ezequiel Garcia wrote:
> On Mon, 2019-01-07 at 14:26 +0100, Heiko Stuebner wrote:
> > Hi,
> >
> > sorry, only now got to test this on actual hardware,
> >
> > Am Freitag, 14. Dezember 2018, 17:29:20 CET schrieb Ezequiel Garcia:
> > > From: Daniele Castagna
> >
https://bugs.freedesktop.org/show_bug.cgi?id=109246
--- Comment #7 from tme ---
Created attachment 143015
--> https://bugs.freedesktop.org/attachment.cgi?id=143015&action=edit
dmesg output
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=109246
--- Comment #6 from tme ---
Created attachment 143014
--> https://bugs.freedesktop.org/attachment.cgi?id=143014&action=edit
Xorg log
I reproduced the problem at about 210 in the log.
Unfortunately I don't see an option to poll inputs in my m
Hi Jani.
Nice cleanup.
On Tue, Jan 08, 2019 at 10:27:09AM +0200, Jani Nikula wrote:
> Needs just a few additional includes here and there.
>
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Acked-by: Daniel Vetter
> Signed-off-by: Jani Nikula
Acked-by: Sam Ravnborg
_
https://bugs.freedesktop.org/show_bug.cgi?id=109234
--- Comment #9 from bmil...@gmail.com ---
(In reply to fin4478 from comment #8)
> (In reply to bmilreu from comment #7)
> > (In reply to fin4478 from comment #6)
> > > blablabla
> >
> > This makes zero sense and is totally uncalled for, speciall
Le lun. 7 janv. 2019 à 16:59, Noralf Trønnes a écrit :
>
>
>
> Den 30.12.2018 18.48, skrev Sam Ravnborg:
> > 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
https://bugs.freedesktop.org/show_bug.cgi?id=109234
--- Comment #8 from fin4...@hotmail.com ---
(In reply to bmilreu from comment #7)
> (In reply to fin4478 from comment #6)
> > blablabla
>
> This makes zero sense and is totally uncalled for, specially here. Go back
> to posting your usual bs in
1 - 100 of 203 matches
Mail list logo
