Forklift DRM layer + i915 changes from linux-stable to kernel 4.4 |
||||
Issue descriptionDue to recurring DP-MST issues and the fact that we are releasing newest boards on kernel 4.4 I would like to forklift all linux-stable DRM layer plus i915 changes to bring kernel 4.4 up to date.
,
Dec 5
Well, we have a ton of DP-MST issues and no clear end in sight. The testing nokolluru@ has done with upstream kernel running on the same hardware shows significant improvement. We have enterprise clients that require DP-MST functionality working correctly with multiple docks and monitors. I understand that doing forklifts can be a big disruption, but on the other hand Intel has done some huge graphics/drm forklifts before (like huge one (1700 CLs) DP-MST support in kernel 3.18) so I do not think that should be issue. Of course I am fine with Intel fixing DP-MST or doing the forklift themselves. I have decent setup that automates most of cherry-picking/testing work and I will push all of this through CQ so it will receive decent testing.
,
Dec 5
I understand your point of view. If forklifting a entire subsystem is an option why is an entire kernel change not being considered?
,
Dec 6
Fwiw, I don't have much reservation about bringing i915 forward to stable, and don't have enough context to weigh in on whether uprevving kernel is a good idea. The i915 driver is well tested and usually includes more bug fixes than bugs as platforms age. I do worry a bit about rockchip, though. Do we know how disruptive this will be for rockchip? The upstream support for rk3399 is pretty good, but I think there are still some missing pieces. Also, if we're doing this for MST, Lyude has been doing a bunch of work on it since 4.19 so we'll likely want to pick patches from mainline as well.
,
Dec 6
,
Dec 6
I'd tend to agree with Guenter that we should be spending more effort figuring out how to uprev kernels than to do huge backports. As per Guenter, the typical reason stated for not doing uprevs is that there will be too many long-tail problems introduced in the graphics stack because upstream doesn't test that well. It seems like the forklift would suffer from the same problem and I'd rather see resources invested in solving the long tail problems in the uprev than the forklift. --- To Sean's point, rk3399 could definitely be tricky to uprev, but hopefully not impossible? |
||||
►
Sign in to add a comment |
||||
Comment 1 by groeck@chromium.org
, Dec 4