On 2/26/20 6:41 PM, Souza, Jose wrote:
Hi Hans
Just commenting in the "[ 3.309061] [drm:intel_dump_pipe_config
[i915]] MST master transcoder: <invalid>" message, it is the expected
behaviour for anything older than Tigerlake, from TGL+ this will be set
in MST mode.
On Wed, 2020-02-26 at 18:52 +0100, Hans de Goede wrote:
Hi,
On 2/26/20 5:05 PM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede <hdegoede@xxxxxxxxxx
wrote:
Hi,
On 2/26/20 4:29 PM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede <
hdegoede@xxxxxxxxxx> wrote:
Hi Lyude and everyone else,
Lyude I'm mailing you about this because you have done a lot
of
work on DP MST, but if this rings a bell to anyone else feel
free to weigh in on this.
Might be a duplicate of:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2Fissues%2F1052&data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&sdata=AKmPhCqvvKtgzDBaobU4g74bErQQ7O3aL%2FJ8Al2Ey2I%3D&reserved=0
Looks like you are right, reverting the commit which the bisect
from that issue points to:
cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
atomic check")
Fixes the issue for me. I will add a comment to the issue.
Note I'm using integrated Intel gfx, so that means that this
issue
definitely is not amdgpu specific.
I'm not too familiar with the mst code, but I wonder if we were
exceeding the bandwidth limits in some setups and it just happened
to
work, but now that we enforcing them, they don't which is correct,
but
a regression from some users' perspective?
I seriously doubt that is the case according to:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.lenovo.com%2Fnl%2Fen%2Fsolutions%2Fpd029622&data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&sdata=64uP50QojK2HkemDq3EGNKCVEgVl1ZxucyI%2F%2Bkk2Ng0%3D&reserved=0
The gen 2 tb3 dock can handle 2 external
displays at 3840*2160@60Hz together with the internal
panel being on and both my external displays run at
1920x1080@60 so I'm consuming less then half of the
maximum bandwidth.
There definitely is a bug somewhere in the
cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
atomic check")
commit (or somewhere else and triggered by that commit).
Regards,
Hans
+ Lin Wyane, Lyude Paul
Hi,
Sorry I'm late responding to the thread.
The reason why this issue could have missed is because this patch was
pushed as a part of DSC MST patch series and with DSC the pbn is much
lower so it wouldn't fail this check.
Anyways this check might have exposed a different bug in DRM. It seems
like the variable of available_pbn doesn't get updated on the ports in
the topology so the calculation of branch's bandwidth limit is not
correct, which would cause a branch bandwidth to be bottle-necked by
pbn_limit variable.
From DP 1.4 standart it seems like DRM should update available_pbn on
each port, when processing RESOURCE_STATUS_NOTIFY sideband message when
topology changes. Right now DRM doesn't seem to be doing anything about
it. Was it the intention, or has it just never implemented? If it the
intention, then the patch should be reverted till a new solution is
delivered, otherwise it should be treated as a bug exposed by a branch
bandwidth check.
I would appreciate any suggestions.
Thanks,
Mikita
Alex
Regards,
Hans
I'm currently using a Lenovo X1 7th gen + a Lenovo TB3 gen 2
dock
as my daily rider for testing purposes. When 5.6-rc1 came out
I
noticed that only 1 of the 2 1920x1080@60 monitors on the
dock
lights up.
There are no kernel errors in the logs, but mutter/gnome-
shell says:
gnome-shell[1316]: Failed to post KMS update: Page flip of 93
failed
With 93 being the crtc-id of the crtc used for the monitor
which is
displaying black. Since then I've waited for 5.6-rc3 hoping
that a
fix was already queued up, but 5.6-rc3 still has this
problem.
gnome-shell does behave as if all monitors are connected, so
the
monitor is seen, but we are failing to actually send any
frames
to it.
I've put a log collected with drm.debug=0x104 here:
https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Ffedorapeople.org%2F~jwrdegoede%2Fdrm-debug.log&data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&sdata=eHPlfCRZXIPp9O%2B9CHvwb1kg5ffIhO%2FFFgwTcuWFKHM%3D&reserved=0
This message stands out as pointing to the likely cause of
this problem:
[ 3.309061] [drm:intel_dump_pipe_config [i915]] MST master
transcoder: <invalid>
Regards,
Hans
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&sdata=im2LrBE%2BgjCL%2FN4%2B%2BZOOu6Eci5SuaZrT8l3mOuDRQH0%3D&reserved=0
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&sdata=im2LrBE%2BgjCL%2FN4%2B%2BZOOu6Eci5SuaZrT8l3mOuDRQH0%3D&reserved=0
--
Thanks,
Mikita Lipski
Software Engineer 2, AMD
mikita.lipski@xxxxxxx
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
