Qualcomm Rolls Out ~110k Lines Of New Kernel Code For Snapdragon 845 Display Support

[robclark]

Actually Qualcomm is pretty lagging... Samsung has for a long time been number 1 (as kernel contributor != intel arch, Samsung has been in the top 5 for years). Ti is also big. I think we can even say that nvidia was pretty good, but only on ARM.
I assume that Qualcomms 100k lines will be rejected, until AMD and Samsung also can work with the same framework. Or better: I think it should be rejected unless it is a generic solution that will work for AMD, exynos, Pi's broadcom, rockchip, win etc. too...

AMD/exynos/rpi/rockchip have their own different display controllers, I'm not exactly sure how you expect a driver for qcom's new display controller to be a generic solution? To be clear, this is an addition to the msm drm driver, not a new framework. It does need, and will undergo some cleanup, this first RFC is just to get more reviewer eye's on the code, no one expects it to be merged as-is.

And btw, where have you been for the last few years? I'd agree with your statement about qcom upstream support perhaps a few years ago. But upstream support has gotten pretty good recently. (Ie. db410c has everything upstream, including wifi, audio, display, gpu, camera, v4l2 m2m video encode/decode, etc). There is upstream kernel working on for example, the nexus7 tablet (a couple years ago already). A bunch of people are working on various 8974 phones, etc.

[starshipeleven]

Maybe someday we can see generic ARM images for distros? That'll be the day

That would mean the devices get bullshit board firmware like UEFI. Not a world I would like to live in.

It's actually quite easy to make a "generic" image that can be customized to work on each specific device by just rebuilding its kernel images (not recompiling, just repackaging the kernel image) with the right dtb (devicetree files, hardware list for a specific board) and a few other things.

The issue is that very few ARM devices actually make any sense to port over, or have limited/non-existing documentation so porting is not possible.

[schmidtbag]

FYI, there are generic ARM images for distros, at least if you've got an ARMv8. That doesn't mean all hardware complies with the generic image, but, generic images do exist.

[starshipeleven]

FYI, there are generic ARM images for distros, at least if you've got an ARMv8. That doesn't mean all hardware complies with the generic image, but, generic images do exist.

You can't have a true "generic" image like we have on x86 without UEFI as without UEFI there is no way for the linux kernel to know what hardware is there in the board.

How many ARM boards have UEFI? Even now that u-boot can have a EFI-like mode they aren't exactly common afaik.

As said it's pretty easy to "specialize" a generic image, just select the right dtb to load (which is the hardware list on that board), and repackage the kernel in a way the bootloader can actually detect and load it, maybe add some kernel command line parameters, and off you go.

[PeeJay]

Rather than UEFI just put a device tree in flash in a common location.

[starshipeleven]

Rather than UEFI just put a device tree in flash in a common location.

Too smart for ARM manufacturers.

[schmidtbag]

You can't have a true "generic" image like we have on x86 without UEFI as without UEFI there is no way for the linux kernel to know what hardware is there in the board.

How many ARM boards have UEFI? Even now that u-boot can have a EFI-like mode they aren't exactly common afaik.

As said it's pretty easy to "specialize" a generic image, just select the right dtb to load (which is the hardware list on that board), and repackage the kernel in a way the bootloader can actually detect and load it, maybe add some kernel command line parameters, and off you go.

This is all true. To my knowledge, no ARM boards have an EFI and never will. But things like u-boot act as an EFI substitute. But, generic kernels still exist for ARM.

When it comes to ARM, a generic kernel means something different vs x86. Traditionally, you would need a custom kernel for pretty much every ARM platform, even if they were based on the same chip. This, along with the fact many drivers were closed source, made maintenance a tremendous burden, and greatly hampered ARM's success. I have a few ARM devices where they're still stuck on the 3.x kernel, at least if you want proper hardware support. But once ARMv8 came around, "generic" kernels became a priority. The ways these work is many (but not all) ARMv8 devices can share the same upstream disk image and kernel. The part that isn't so generic is how the device boots (such as with u-boot) and how you install the OS. As far as I'm aware, all ARMv8 devices out there will boot with generic disk images, but may lack complete hardware support without their own downstream kernel.

[starshipeleven]

When it comes to ARM, a generic kernel means something different vs x86.

Technically speaking, no. A generic kernel on ARM means that you don't need non-upstreamed/able patches to support a specific hardware platform anymore, all quirks and platform-specific bs were mainlined.

For example, devices based off Marvell Kirkwood SoC can boot fine with a "generic" kernel in Debian (armel architecture, ARM without FPU coprocessor) and they are using an ARMv5 core with no FPU. Only thing you need is a device tree file so the kernel can know what hardware is on that board.

As far as I'm aware, all ARMv8 devices out there will boot with generic disk images, but may lack complete hardware support without their own downstream kernel.

Any device, even older ARM processors will boot fine with a "generic" kernel too (as long as it is compiled for their architecture and presence/absence of FPU), the issue is actually having the thing do more than just run the kernel serial console attached to the debug pins.

The issue is the same as it was before, lack of drivers or documentation to run/initialize/operate the other controllers on the board.

[pal666]

I wish Qualcomm's attitude doesn't change after (if) Broadcom buys Qualcomm. But...

i wish it change because broadcom even employs mesa dev

[pal666]

Yea now that their patents expired they do not have to be afraid that their drivers will leak some patent violation their competitors might exploit against them so they are willing to do this.

you've got it backwards. their competitors might exploit only violation of competitors patents, so expiration of qualcomm patents is irrelevant. it just weakens qualcomm position because now qualcomm can't retaliate because competitors cant violate expired patents