This patch adjust the print string of drm_display_mode object
to remove drm_mode_object dependency in i915 files.
It modifies the print style to standardize the use of DRM_MODE_FMT.
Signed-off-by: Shayenne Moura
Reviewed-by: Jani Nikula
---
Changes in v2:
- Use DRM_MODE_FMT/ARG macros (Daniel
This patch removes the drm_mode_object prints, evaluation and use from
drm_display_mode objects used in drm files. It removes dependency from
drm_mode_object.
Signed-off-by: Shayenne Moura
Reviewed-by: Daniel Vetter
---
Changes in v2 and v3:
- No change
drivers/gpu/drm/drm_crtc_helper.c | 5
This patch finalizes the KMS cleanup task dependency from
drm_display_mode. It removes the use of drm_mode_object
from drm_display_mode struct and it removes the use of
base.id and base.type from drm_display_mode struct
print string.
Signed-off-by: Shayenne Moura
Reviewed-by: Daniel Vetter
---
On Wed, 2019-01-09 at 18:49 +0100, Noralf Trønnes wrote:
> Hi,
>
> I was really pleased to see that the damage helper had landed. Now I
> can
> do framebuffer flushing solely through the display pipe functions.
> This
> prepares the ground for the removal of struct tinydrm_device in my
> next
> se
This patch serie removes drm_mode_object dependency from
drm_display_mode struct. This is part of KMS cleanup.
---
Changes in v3:
- Solve typo in first patch in v2
Changes in v2:
- Make alterations suggested by Daniel and commit
messages clear
Shayenne Moura (7):
drm: msm: Cleanup drm_
This patch adjust the print string of drm_display_mode object
to remove drm_mode_object dependency in sti files.
Signed-off-by: Shayenne Moura
Acked-by: Benjamin Gaignard
---
Changes in v2:
- Use DRM_MODE_FMT/ARG macros (Daniel)
- Make the commit message more clear
Changes in v3:
- No cha
On Thu, 10 Jan 2019 15:10:48 +
Peter Rosin wrote:
> The A2Q and UPDATE bits have no effect in the channel disable registers.
> However, since they are present, assume that the intention is to disable
> planes, not immediately as indicated by the RST bit, but on the next
> frame shift since th
On Thu, 10 Jan 2019 15:10:28 +
Peter Rosin wrote:
> Hi!
>
> I found an unfortunate issue while recoding plane handling to use
> drm_atomic_helper_check_plane_state(). The driver rotates clockwise,
> which is not correct. I simply fixed it (patch 1/4), but maybe that
> will cause regressions
On Thu, 10 Jan 2019 15:10:39 +
Peter Rosin wrote:
> The destination crtc rectangle is independent of source plane rotation.
>
> Signed-off-by: Peter Rosin
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/atm
https://bugs.freedesktop.org/show_bug.cgi?id=109234
bmil...@gmail.com changed:
What|Removed |Added
Summary|amdgpu random hangs with|amdgpu random hangs with
This patch serie removes drm_mode_object dependency from
drm_display_mode struct. This is part of KMS cleanup.
---
Changes in v2:
- Make alterations suggested by Daniel and commit messages clear
Changes in v3:
- Solve typo in first patch in v2
Changes in v4:
- Remove patches already merged
This patch adjust the print string of drm_display_mode object
to remove drm_mode_object dependency in msm files.
Reported-by: kbuild test robot
Signed-off-by: Shayenne Moura
---
Changes in v2:
- Use DRM_MODE_FMT/ARG macros (Daniel).
- Make the commit message more clear
Changes in v3:
- R
This patch removes the drm_mode_object prints, evaluation and use from
drm_display_mode objects used in drm files. It removes dependency from
drm_mode_object.
Signed-off-by: Shayenne Moura
Reviewed-by: Daniel Vetter
---
Changes in v2, v3, and v4:
- No changes
drivers/gpu/drm/drm_crtc_helper
This patch finalizes the KMS cleanup task dependency from
drm_display_mode. It removes the use of drm_mode_object
from drm_display_mode struct and it removes the use of
base.id and base.type from drm_display_mode struct
print string.
Signed-off-by: Shayenne Moura
Reviewed-by: Daniel Vetter
---
On 1/2/19 11:05 AM, Petr Mladek wrote:
> On Thu 2018-12-20 17:31:57, Bartlomiej Zolnierkiewicz wrote:
>>
>> [ added Petr & Sergey to Cc: ]
>>
>> Hi,
>>
>> On 10/30/2018 04:44 PM, Prarit Bhargava wrote:
>>> On text-based systems the 'quiet' boot option will show printk levels
>>> higher than CONSO
https://bugs.freedesktop.org/show_bug.cgi?id=106175
tempel.jul...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FI
The fbcon code can be built as a module and requires console_printk.
Export console_printk.
Signed-off-by: Prarit Bhargava
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Hans de Goede
Cc: Marko Myllynen
Cc: Steven Rostedt (VMware)
Cc: Bartlomiej Zolnierkiewicz
Cc: Kees Cook
Cc: Daniel Vetter
On text-based systems the 'quiet' boot option will show printk levels
higher than CONSOLE_LOGLEVEL_QUIET. The displaying of the Tux logo
during boot can cause some consoles to lose display data and as a result
confuse the end user.
Do not display the Tux logo on systems that are in 'quiet' boot.
On text-based systems the 'quiet' boot option will show printk levels
higher than CONSOLE_LOGLEVEL_QUIET. The displaying of the Tux logo
during boot can cause some consoles to lose display data and as a result
confuse the end user.
Do not display the Tux logo on systems that are in 'quiet' boot.
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #81 from Nicholas Kazlauskas ---
(In reply to tempel.julian from comment #80)
> It seems like the issue is actually not 100% resolved (linux 5.0-rc1).
> The moving of windows is free of stutter now, but moving of windows can
> still
On Thu, 10 Jan 2019 18:51:21 +
Peter Rosin wrote:
> On 2019-01-10 18:29, Boris Brezillon wrote:
> > On Thu, 10 Jan 2019 15:10:48 +
> > Peter Rosin wrote:
> >
> >> The A2Q and UPDATE bits have no effect in the channel disable registers.
> >> However, since they are present, assume that
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #82 from tempel.jul...@gmail.com ---
Could you please try the following?
-disable Plasma compositing with Ctr + Alt + F12 (or in the compositor settings
and log out and in again)
-get the latest Compton release by yshui: https://gith
The TPO (Toppoly) TPG110 is a pretty generic display driver
similar in vein to the Ilitek 93xx devices. It is not a panel
per se but a driver used with several low-cost noname panels.
This is used on the Nomadik NHK15 combined with a OSD
OSD057VA01CT display for WVGA 800x480.
The driver is pretty
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #83 from tempel.jul...@gmail.com ---
Edit: Sorry, I meant disabling KWin compositing via Shift + Alt F12, not Ctrl.
--
You are receiving this mail because:
You are the assignee for the bug.___
Hi,
On Wed, Jul 11, 2018 at 8:34 PM Daniel Vetter wrote:
>
> On Wed, Jul 11, 2018 at 4:52 PM, Noralf Trønnes wrote:
> >
> > Den 11.07.2018 16.06, skrev Maxime Ripard:
> >>
> >> CC'ing Noralf and Daniel,
> >>
> >> On Wed, Jul 11, 2018 at 09:47:53PM +0800, Icenowy Zheng wrote:
> >>>
> >>> Today, d
Den 10.01.2019 20.30, skrev Linus Walleij:
> The TPO (Toppoly) TPG110 is a pretty generic display driver
> similar in vein to the Ilitek 93xx devices. It is not a panel
> per se but a driver used with several low-cost noname panels.
>
> This is used on the Nomadik NHK15 combined with a OSD
> OSD
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
Split some stuff across multiple lines
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: 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/dr
Fix some indenting, split some stuff across multiple lines.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: 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(-)
d
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
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
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
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
Split some stuff across multiple lines, remove some unnecessary braces
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: 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(+)
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
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
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
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,
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:
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
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 18
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
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
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
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
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
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
Hi Linus,
On Wed, Jan 9, 2019 at 7:23 PM Linus Walleij wrote:
>
> The TPO (Toppoly) TPG110 is a pretty generic display driver
> similar in vein to the Ilitek 93xx devices. It is not a panel
> per se but a driver used with several low-cost noname panels.
>
> This is used on the Nomadik NHK15 combi
On Thu, Jan 10, 2019 at 08:01:37PM +0100, Frank Wunderlich wrote:
> Hi Daniel,
>
> > > Would be good to use the new generic fbdev emulation code here, for even
> > > less code. Or at least know why this isn't possible to use for mtk (and
> > > maybe address that in the core code). Hand-rolling fbd
On Thu, Jan 10, 2019 at 04:13:01PM -0200, Shayenne Moura wrote:
> This patch adjust the print string of drm_display_mode object
> to remove drm_mode_object dependency in msm files.
>
> Reported-by: kbuild test robot
For next time around, this is a bit much credit for kbuild test robot. I'd
just
https://bugzilla.kernel.org/show_bug.cgi?id=202217
Bug ID: 202217
Summary: Integrated laptop display doesnt come back up after
using PRIME on wayland
Product: Drivers
Version: 2.5
Kernel Version: 5.0-rc1
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=202217
--- Comment #1 from Haxk20 (haxk...@gmail.com) ---
*** Bug 202197 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
d
Hi Peter.
(Hijacking this thread as I lost the orginal mails)
> >
> > I found an unfortunate issue while recoding plane handling to use
> > drm_atomic_helper_check_plane_state(). The driver rotates clockwise,
> > which is not correct. I simply fixed it (patch 1/4), but maybe that
> > will cause
https://bugzilla.kernel.org/show_bug.cgi?id=202217
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugs.freedesktop.org/show_bug.cgi?id=109290
--- Comment #5 from Martin Peres ---
(In reply to Chris Wilson from comment #3)
> Nah. Give me a machine with 49-bits of memory and I want to test what
> happens if we have a full 48-bit GTT. (Not that it really matters, since the
> interesting
https://bugs.freedesktop.org/show_bug.cgi?id=109290
Chris Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Robert,
On Thu, Jan 10, 2019 at 6:34 AM Robert Chiras wrote:
>
> The eLCDIF controller has control pin for the external LCD reset pin.
> Add support for it and assert this pin in enable and de-assert it in
> disable.
> Also, correct the pm_runtime_enable call, since it was made too early in
>
Am Dienstag, 8. Januar 2019, 22:46:59 CET schrieb Ezequiel Garcia:
> 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 ov
Am Mittwoch, 5. Dezember 2018, 13:33:10 CET schrieb Helen Koike:
> From: Enric Balletbo i Serra
>
> Add support to async updates of cursors by using the new atomic
> interface for that.
>
> Signed-off-by: Enric Balletbo i Serra
> [updated for upstream]
> Signed-off-by: Helen Koike
applied to
https://bugs.freedesktop.org/show_bug.cgi?id=109297
Alex Deucher changed:
What|Removed |Added
Component|Driver/AMDgpu |Drivers/Gallium/radeonsi
Assig
https://bugs.freedesktop.org/show_bug.cgi?id=109297
--- Comment #2 from nolang...@gmail.com ---
Created attachment 143064
--> https://bugs.freedesktop.org/attachment.cgi?id=143064&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=109297
--- Comment #3 from nolang...@gmail.com ---
I am running Wayland, so no xorg log?
Anyway, only sensible thing I could come up with, is if the card is pulling to
much Power over the PCIe connector instead of the extra Plug.
ii libegl-mesa0:amd64
https://bugs.freedesktop.org/show_bug.cgi?id=109135
--- Comment #5 from i...@yahoo.com ---
(In reply to rmuncrief from comment #2)
[...]
> Here's the grub line I use for all testing:
> GRUB_CMDLINE_LINUX_DEFAULT="quiet
> resume=UUID=b4f71480-8fe3-43c2-99c9-fc3f5687545b libata.atapi_passthru16=0
>
Am Mittwoch, 9. Januar 2019, 19:56:36 CET schrieb Ezequiel Garcia:
> Here's a small series supporting plane reflection (aka. mirroring)
> properties on RK3328, RK3368, and RK3399 SoCs.
>
> Note that RK3288 specification doesn't seem to document registers
> for plane mirroring, but instead it only
https://bugs.freedesktop.org/show_bug.cgi?id=108781
--- Comment #39 from i...@yahoo.com ---
Just for the test, if you still have an issue,
would you try with "iommu=soft" ?
e.g. I see in jamespharvey20's log that he has intel_iommu enabled.
--
You are receiving this mail because:
You are the as
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/omapdrm/omap_encoder.c
between commit:
3c613a3bddd3 ("drm/omap: fix incorrect union usage")
from Linus' tree and commit:
13d0add333af ("drm/edid: Pass connector to AVI infoframe functions")
from th
Neil Armstrong writes:
> On 08/12/2018 18:12, Martin Blumenstingl wrote:
>> This series adds support for the Mali-450 GPU on Meson8 and Meson8b.
>> Meson6 uses a Mali-400 GPU but since we don't have a clock driver (and
>> I don't have a device for testing) Meson6 is left out in this series.
>>
>
For the nouveau patches in the series:
Reviewed-By: Ben Skeggs
On Fri, 11 Jan 2019 at 05:59, 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 actua
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
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 18
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
Split some stuff across multiple lines
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: 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/dr
Fix some indenting, split some stuff across multiple lines.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: 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(-)
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
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
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
Split some stuff across multiple lines, remove some unnecessary braces
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: 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(+)
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
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 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
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
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,
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
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
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
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
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:
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
Reviewed-By: Ben Skeggs
Cc: Dani
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
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
Reviewed-By: Ben Skeggs
Cc: Daniel Vetter
Cc: David Ai
https://bugs.freedesktop.org/show_bug.cgi?id=109135
--- Comment #6 from rmuncr...@humanavance.com ---
(In reply to iive from comment #5)
> (In reply to rmuncrief from comment #2)
> [...]
> > Here's the grub line I use for all testing:
> > GRUB_CMDLINE_LINUX_DEFAULT="quiet
> > resume=UUID=b4f71480-
On 1/9/19 11:49 AM, Noralf Trønnes wrote:
This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty
handler. All flushing will now happen in the pipe functions.
Also enable the damage plane property for all except repaper which can
only do full updates.
ili9225:
This change made ili
https://bugs.freedesktop.org/show_bug.cgi?id=109135
--- Comment #7 from Alex Deucher ---
Can you bisect to figure out what commit broke things for you?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=109135
--- Comment #8 from rmuncr...@humanavance.com ---
(In reply to Alex Deucher from comment #7)
> Can you bisect to figure out what commit broke things for you?
Actually I remember doing that many years ago when I was a maintainer for Steam
under w
Hi, Frank:
On Thu, 2019-01-10 at 20:01 +0100, Frank Wunderlich wrote:
> Hi Daniel,
>
> > > Would be good to use the new generic fbdev emulation code here, for even
> > > less code. Or at least know why this isn't possible to use for mtk (and
> > > maybe address that in the core code). Hand-rollin
Hi Sebastian,
On Thursday, 20 December 2018 14:17:27 EET Sebastian Reichel wrote:
> Hi,
>
> On Mon, Dec 10, 2018 at 03:06:17AM +0200, Laurent Pinchart wrote:
> > This patch series hooks up support for drm_bridge and drm_panel in the
> > omapdrm driver.
> >
> > [...]
>
> The series is
>
> Revie
Hi Linus,
Not a huge amount for rc2, assume the usual quiet period, and rc3 will
be most of it.
amdgpu:
- Powerplay fixes
- Virtual display pinning fixes
- Golden register updates for Vega
- Pitch and gem size validation fixes
- SR-IOV init error fix
- Pagetables in system RAM disable for some Ra
https://bugs.freedesktop.org/show_bug.cgi?id=109298
Bug ID: 109298
Summary: AMDGPU leaving DRI2 enabled causes white artifacting
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Hi, Daniel:
On Thu, 2019-01-10 at 21:02 +0100, Daniel Vetter wrote:
> On Thu, Jan 10, 2019 at 08:01:37PM +0100, Frank Wunderlich wrote:
> > Hi Daniel,
> >
> > > > Would be good to use the new generic fbdev emulation code here, for even
> > > > less code. Or at least know why this isn't possible t
The omapdrm and omapdss drivers are architectured based on display
pipelines made of multiple components handled from sink (display) to
source (DSS output). This is incompatible with the DRM bridge and panel
APIs that handle components from source to sink.
Reconcile the omapdrm and omapdss drivers
The field is only used in a safety check during device
connection/disconnection, where the src field can be easily used
instead. Remove it and use src.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
Tested-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/base.c| 6 ++--
101 - 200 of 274 matches
Mail list logo
