Pmbootstrap: Ideas for getting Freedreno working on non-mainline kernel devices?

[zhuowei]

Curently, we have 29 Qualcomm Adreno GPU devices being ported, and only two devices (asus-flo and sony-castor-windy) support the Freedreno kernel driver (drm/msm) required for 3D acceleration in Weston and KWin. The other devices run kernels too old to support the upstream drm/msm driver, and thus can't use Freedreno in Weston due to missing KMS support.

What approach should we take to support GPU acceleration on these devices? I can think of three options:

• Backport drm/msm from newer kernels into each device's kernel. Rob Clark, the developer of Freedreno, maintains backport patches for Linux 3.10 (and older), but it consists of almost 200 commits, and may be unwieldy to get running on each Snapdragon device's kernel.

Edit: It looks like the Nexus 6P kernel diverged a bit from the IFC6540 kernel, which causes compile errors when I try to copy the backport from the Freedreno backported repo.

• Test if Freedreno works in X11 using the kgsl-drm compatibility layer in downstream kernels, and create a shim for Weston/KWin that simulates KMS, borrowing the X11 modesetting code. This would be a horrible kludge, and may not even work as the required kgsl-drm compatibility layer may be broken in the device kernel.

Edit: per Rob Clark's comment, the kgsl support is unlikely to work on kernels newer than 3.4, so the drm/msm backport seems to be preferred.

• Give up and use libhybris.

What are the pros and cons of each?

[ollieparanoid]

Great write up! Honestly, I would not put too much effort into these non-mainline kernels, but applying the patchset from @robclark sounds like a good and relatively quick solution (even if it does not directly apply cleanly).

EDIT: What is the problem with the 200 commits? You could put them in one big packed patch file, like it's done for the kernel patchlevels, and apply it like done here.

(Mainlining would be best of course. I know that it is a massive effort.)

[zhuowei]

@ollieparanoid I'll try applying the backport to the 6P's kernel and see what happens.

[robclark]

I'm not sure the kgsl-drm hack ever worked on something newer than the early msm-3.4 kernels (like what shipped on the nexus4), so not sure it is worth putting a huge amount of effort into that approach. Dealing with the various different versions of kgsl is a bit of a pain.

And the drm backport for 3.10 approach would probably need dsi and panel driver stuff backported, and then per-device panel drivers written (since dsi screens are not such a standardized thing as HDMI or (e)DP).

Some devices have been getting upstream kernel attention (flo is pretty complete, and iirc there was someone working on 6p although he had not gotten as far as enabling the display yet). It would certainly be nice to see some more, although 29 devices is a lot ;-)

Devices that use the same SoC as one that is working upstream (for example 8064 and 8x16 is in good shape upstream, and linaro/qcom is actively working on 8x96), might be good candidates for anyone who wants to work on upstream kernel on a device. And probably devices that use the headphone-jack debug-uart trick will be easier to debug if you don't want to do some soldering. And devices where you don't have to care about making a phone call (like flo) would be better, although I think eventually there will be enough upstream to at least do VoIP.

I guess for at least some devices you might be stuck with libhybris for now.

[zhuowei]

@robclark Wow, thanks for the advice! For DSI, It looks like your backport branch does include drm/gpu/drm/panel, so do I just follow the guide to get display working in the backport?

[robclark]

yeah, I suppose that might work.. at least 3.10 and later are using device-tree, older 3.4 kernels would be much harder. Offhand I'm not sure what other DSI related patches might need to be backported, I think the 3.10 based devices that I was using at the time were all using hdmi display.

[zhuowei]

Update: I tried getting the 3.10 backport to run on an Angler base kernel. It doesn't work.

What I did:

• fetched the ifc6540-4.4.4-drm-v4.8 branch from the Freedreno kernel-msm repo
• squashed all commits from a789aadcb4bf4b40c444775b1bb53bcbd8eb1b0f to a2f7cfcb7645b6f1a5240b50b3146365f90e1e90 into one (55MB!) patch
• applied that on top of the LineageOS 14.1 kernel for Angler (there were only like 10 merge conflicts, which is surprising)
• tried compiling: got errors all over the place.

  CC      kernel/sched/core.o
kernel/sched/core.c:173:6: error: redefinition of '__smp_mb__before_atomic'
 void __smp_mb__before_atomic(void)
      ^
kernel/sched/core.c:157:6: note: previous definition of '__smp_mb__before_atomic' was here
 void __smp_mb__before_atomic(void)
      ^
kernel/sched/core.c:181:6: error: redefinition of '__smp_mb__after_atomic'
 void __smp_mb__after_atomic(void)
      ^
kernel/sched/core.c:165:6: note: previous definition of '__smp_mb__after_atomic' was here
 void __smp_mb__after_atomic(void)
      ^
make[2]: *** [kernel/sched/core.o] Error 1
make[1]: *** [kernel/sched] Error 2
make: *** [kernel] Error 2

Sigh. I really don't want to fix all these errors on a kernel by hand: any advice?

[ollieparanoid]

I don't think you have any other choice there, except for fixing these errors. Maybe you can find existing patches, which address these specific errors.

[nta]

The kind of issue @zhuowei is having seems to be caused by the kernel tree for his device _already_ having certain patches backported:

https://github.com/freedreno/kernel-msm/commit/7335c82adcd5d9b272d1290226883c017ede4468
https://github.com/LineageOS/android_kernel_huawei_angler/commit/7d9e69c77fd3e992f022484798be475a2905ac8f

The Signed-Off-By line indicates this is part of the CAF patch set - however, my shamu does not seem to have this particular patch, but it does have another particular gotcha from CAF that _didn't_ originate upstream and therefore isn't accounted for by backporting the relevant code.

I wonder, for these cases where CAF cherry-picked certain commits that were also separately cherry-picked in the backport branch, if Git would be smart enough to not doubly apply these commits, as clearly happens when 'blindly' making a patch file.

It's a shame even things like _these_ differ across devices' kernel trees, which only makes it harder to maintain a 'generic' method of porting the DRM backports to device-specific kernels.

[dianaxxyyzz]

An for example for some snapdragon 835 devices like Essential Phone , witch comes with kernel 4.x there is no need to patch the kernel ? As long as the kernel already have a drivers/gpu/drm/msm/adreno/ we dnt need to modify the kernel ?

[ollieparanoid]

That sounds about right, although I'm not the expert here. If I was you, I would just try it out :wink:

[robclark]

iirc, a5xx support landed upstream in 4.10.. which I think is newer than what is shipping on existing phones (although maybe not out of reach of backporting.. but my thinking for next interesting target is something w/ 820 since upstream support for db820c is getting pretty close)

[dianaxxyyzz]

So , as everybody knows , freedreno works better on a kernel that have freedreno patch and drm/msm and has less chances to work on a kernel that only supports kgsl .
My final question here is : If I backport the freedreno drm/msm patch to a existing kernel for android 8996 hardware , the android will still work? Or the patches will make X11 to work and disable android video?

[robclark]

on current devices, android uses a completely different kernel driver for display and for gpu, so I don't think a single kernel will work for both android and x11, at least not using qcom's hwc and gles drivers..

linaro and others have been doing some work with mesa and drm-hwc to have android on an upstream kernel. That approach might be a way to have both android and x11 on the same kernel. I guess from the point of view of android build system, this becomes a totally new board/target, so for getting something more than an plain AOSP build, I guess it will take some work. (disclaimer: I'm really not knowledgeable about android build system.)

[dianaxxyyzz]

Ok, thank you very much for your response . I saw a video of you with a linaro guy when you presented AOSP android running with freedreno drivers too . So it is possible android and x11 to use same kernel .
But I think the only work needed is to make things stable. I hope I'm not wrong

[mirh]

I feel particularly dumb for having opened #1123, without realizing that this was already a thing.
So... I don't know maybe this could be reserved for A3xx+?

Though I don't understand, I thought drm/msm was already working with that?
And that KGSL had only been definitively abandoned by devices using like 3.18?

[dianaxxyyzz]

From my undersranding but never tested , freedreno has some support for
Qualcomm kgsl . But just for some kernels . Over years kgsl changed so
freedreno do not work for it . Freedreno focused on new kernel graphic
arhitecture dri . kgsl is something made by Qualcomm and because the code
was not acepted into mainline you can find it just in kernels provided by
Qualcomm.

On Feb 3, 2018 1:36 AM, "mirh" [e-mail] wrote:

I feel particularly dumb for having opened #1123
https://github.com/postmarketOS/pmbootstrap/issues/1123, without
realizing that this was already a thing.
So... I don't know maybe this could be reserved for A3xx+?

Though I don't understand, I thought drm/msm was already working with that?
And that KGSL had only been definitively abandoned by devices using like
3.18?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/postmarketOS/pmbootstrap/issues/727#issuecomment-362741206,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI7edZvDhGpkA81wUg-DJ-qChFL_rxMUks5tQ5vxgaJpZM4Px3i5
.

[mirh]

But just for some kernels . Over years kgsl changed so freedreno do not work for it

Yes, I know.
But last time I checked you could easily replace that with drm/msm on every gpu but a2xx series.
OP doesn't seem to make any distinction for that.

[dianaxxyyzz]

@robclark I have a htc 10 with adreno 530 gpu .
The kernel is a 3.18 one and also have support for some freedreno
https://github.com/LineageOS/android_kernel_htc_msm8996/blob/cm-14.1/drivers/gpu/drm/msm/adreno/
but it do not have for adreno 530 .

Do you think that copying drivers/gpu/drm/msm/adreno/ directory from your wip-8996-drm git tree , to this kernel I have will work ? I ask this because the htc 10 kernel looks to have some support already for a3xx deviecs .