ARM Is Very Busy In The Next Kernel With A Lot For NVIDIA Tegra, Snapdragon 835 & More

[phoronix]

Phoronix: ARM Is Very Busy In The Next Kernel With A Lot For NVIDIA Tegra, Snapdragon 835 & More

The pull requests adding new ARM chip/SoC support and various platforms/boards were merged on Monday evening. For this Linux 4.20 (or 5.0) kernel cycle there is a lot of new hardware support, especially among the popular ARM SBCs. NVIDIA Tegra upstreaming bits is also another big standout for this kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.20-5.0-ARM

[SyXbiT]

I do wonder the purpose of adding mainline support to the kernel for Snapdragon devices. In the case of the SD835, that uses the 4.4 kernel. That's what the drivers run against. I believe every shipped SD835 device used the 4.4 kernel (same for SD845 and the 4.9 kernel.)

[caligula]

I do wonder the purpose of adding mainline support to the kernel for Snapdragon devices. In the case of the SD835, that uses the 4.4 kernel. That's what the drivers run against. I believe every shipped SD835 device used the 4.4 kernel (same for SD845 and the 4.9 kernel.)

Um, they have start somewhere? Having a legacy blob kernel is almost like not having a kernel at all.

[uid313]

Where is Snapdragon 845 support?
Qualcomm are very late with adding in support. Look at Intel and AMD, they add support before the product is even on the market.

[RussianNeuroMancer]

I still hope for SD835 laptops support, but this probably doesn't make sense until Qualcomm decide to implement ACPI support for their boards themselves.

https://h30434.www3.hp.com/t5/Notebook-Operating-System-and-Recovery/installing-linux-on-envy-x2/m-p/6732756/highlight/true#M534653

[mbello]

As things stand now, I would not buy an Arm laptop. I run linux and there is generally very mediocre open source Arm support with the GPU drivers being mostly a reverse engineering effort. Intel and AMD are way ahead.
Arm and Qualcomm are the first two that should lead the pack and start showing commitment to proper Linux support.

[Ardje]

Arm and Qualcomm are the first two that should lead the pack and start showing commitment to proper Linux support.

Qualcomm is lagging indeed, compared to Exynos or other ARM SoC providers.
GPU drivers is a pain. I think all the drivers that are out there are mostly reversed engineered with some getting support later on.
Otoh: Linux is lagging for basic SoC support. GPU's are usually not bound to any display hardware, but just that: a gpu "copro". There are scalers, jpeg (de)compressors, rotators, bitstream codecs, framebuffer mixers and framebuffer serialisers. Currently everything in linux is based on intel architecture.

[edwaleni]

Qualcomm is lagging indeed, compared to Exynos or other ARM SoC providers.
GPU drivers is a pain. I think all the drivers that are out there are mostly reversed engineered with some getting support later on.
Otoh: Linux is lagging for basic SoC support. GPU's are usually not bound to any display hardware, but just that: a gpu "copro". There are scalers, jpeg (de)compressors, rotators, bitstream codecs, framebuffer mixers and framebuffer serialisers. Currently everything in linux is based on intel architecture.

With mainstream kernel support, I would expect ARM device support to start picking up speed.

[robclark]

Qualcomm is lagging indeed, compared to Exynos or other ARM SoC providers.
GPU drivers is a pain. I think all the drivers that are out there are mostly reversed engineered with some getting support later on.
Otoh: Linux is lagging for basic SoC support. GPU's are usually not bound to any display hardware, but just that: a gpu "copro". There are scalers, jpeg (de)compressors, rotators, bitstream codecs, framebuffer mixers and framebuffer serialisers. Currently everything in linux is based on intel architecture.

GPU driver situation on qcom is not too bad (ofc I'm biased).. but we tend to have drm/msm + freedreno upstream support before the rest of the kernel driver dependencies are merged. And you have snapdragon boards like db410c with *everything* (display, gpu, vid dec/enc, camera, etc) working out of the box on upstream kernel for the last 4 or 5 kernel releases, iirc.

Defn not *yet* to point of having upstream kernel support before devices ship, like intel is. But getting there, and huge progress compared to where we were a few years ago.. even starting to see patches posted in advance of Si.. anyways, I think qcom is ahead at this point compared to the other ARM SoCs, and making good progress.

Usually the problem with bringing up a new devicetree based SoC is the large dependency tree on other lower level drivers to do something simple like light up the display.. that ends up depending on at least two other clock drivers, a gdsc/genpd driver, some regulator drivers, and possibly interconnect driver (depending on the power-on defaults and whether that provides enough bandwidth to feed display). I'd really like to see a dump of the ACPI tables and lspci type output from a windows-arm laptop w/ one of the snapdragon SoC's.. if they used ACPI in a sane way to abstract some of this complexity, it could make bring-up of a new SoC much faster and more equivalent to the amount of work it is for an intel device. That would be an interesting development.

[suberimakuri]

Woohoo. More Rock support. Arch latest seems great though.