Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Qualcomm hardware support increasingly in good shape with Linux kernel

phoronix.com

Post reply on HN
Print view View original

11–20 of 38 posts

Re: Qualcomm hardware support increasingly in good shape with Linux kernel

#11

Post by stefan_ »

jauntywundrkind wrote: post #2

There really has been a huge shift for Qualcomm, and it's great to see. It's so interesting to me to guess how and where this is happening, what the pressure points are driving this. It feels like there's two areas that have been highly motivated to make Qualcomm more than good for limited-lifetime appliances running unmaintained kernel. First around were the motivated hobbyists, namely, OpenWRT. OpenWRT already had…

I guess the good news is that if I remember correctly, the NSS stuff was already dropped again for the next generation...

There is also the whole interesting disconnect where they employ one or two cranky old timers to maintain the upstream ath drivers, then have the usual Indian teams write untested rushed upstream "support" patch series for the routing WiFi chips. The old timers don't want to test them because they believe their job is in the tiny and shrinking Qualcomm laptop WiFi market and the Indian teams don't test by doctrine and superior orders. And this is for the Qualcomm-on-Qualcomm case; they fare much worse trying to submit patch series for all the other bits and pieces you need to make the Qualcomm SOC work that invariably comes with the routing WiFi chips.

Re: Qualcomm hardware support increasingly in good shape with Linux kernel

#12

Post by stragies »

dirkf wrote: post #6

On a related note: I have the impression Broadcom is more and more losing terrain to the likes of Qualcomm and Mediatek. A couple of years ago nearly everybody was using Broadcom chips in their products (or at least in the consumer-grade telecom devices I'm familiar with as part of my job). Now I'm seeing a shift away from them. I can't really say if it's due to better features, price, vendor support, open source sup…

If you check out the forum.openwrt.org, you'll see, that broadcom support is mostly limited to Raspberry PI devices, and some 400Mhz museum pieces.

9/10 times the turned-down requests for OpenWrt support of Device XY are because of Broadcom SOCs/Wireless_chips in the device.

Re: Qualcomm hardware support increasingly in good shape with Linux kernel

#13

Post by protastus »

zozbot234 wrote: post #10
protastus wrote: post #7

Earlier quoted context omitted.

100% agree with you. Qualcomm historically wrote awful OSS code that couldn't be upstreamed because it barely worked on a subset of their own SoCs, and broke basic function for everything else. Typically featuring incredibly invasive architectural changes that patched far too many layers of the OS with unmaintainable code. QC then converted bad code into a business model, nickel and diming OEMs who needed bugs fixed…

Every mainline-supported device starts out as "booting to console". GPU support on ARM SoC's is currently achieved through a variety of community-developed drivers, such as lima and panfrost. That part at least is comparatively well-understood. The manufacturer does not directly support these community drivers, so it's not very clear how much Qualcomm could help there.

There are so many ways they could help. For GPU, they could support freedreno (both the kernel and Mesa parts) instead of KGSL and the closed source Adreno libraries.

A great start would be to make the user space Adreno GLES libraries talk to the freedreno DRM backend. So one could use the QC proprietary GLES libs with a mainline kernel without rebuilding with KGSL.

There's a similar story here for every subsystem driver, where they insist on a brittle proprietary solutions (one branch for every chip!) that can't be upstreamed.

Re: Qualcomm hardware support increasingly in good shape with Linux kernel

#14

Post by seba_dos1 »

One thing I noted from the FOSDEM talk is that even though Qualcomm supports mainlining through Linaro, it's done based on existing code (both NDAed and public) and there's close to no documentation provided neither publicly nor privately to the devs. When you'll happen to work on that code in the future in mainline Linux trying to catch some bug, all you'll have to cross-check things with may be the same buggy code you try to fix - so in the end it's just like it would be reverse engineered, but without all the notes that community may have produced while trying to understand the thing.

Re: Qualcomm hardware support increasingly in good shape with Linux kernel

#15

Post by zozbot234 »

protastus wrote: post #13
zozbot234 wrote: post #10

Earlier quoted context omitted.

Every mainline-supported device starts out as "booting to console". GPU support on ARM SoC's is currently achieved through a variety of community-developed drivers, such as lima and panfrost. That part at least is comparatively well-understood. The manufacturer does not directly support these community drivers, so it's not very clear how much Qualcomm could help there.

There are so many ways they could help. For GPU, they could support freedreno (both the kernel and Mesa parts) instead of KGSL and the closed source Adreno libraries. A great start would be to make the user space Adreno GLES libraries talk to the freedreno DRM backend. So one could use the QC proprietary GLES libs with a mainline kernel without rebuilding with KGSL. There's a similar story here for every subsystem dr…

But Qualcomm does not currently support freedreno, it's purely a community effort. It's not Qualcomm's job to bring it to feature parity with their proprietary drivers, so the proposal to have their libraries talk to it by default is just not very sensible.

Re: Qualcomm hardware support increasingly in good shape with Linux kernel

#16

Post by bgnn »

dirkf wrote: post #6

On a related note: I have the impression Broadcom is more and more losing terrain to the likes of Qualcomm and Mediatek. A couple of years ago nearly everybody was using Broadcom chips in their products (or at least in the consumer-grade telecom devices I'm familiar with as part of my job). Now I'm seeing a shift away from them. I can't really say if it's due to better features, price, vendor support, open source sup…

it's because of the CEO Hock Tan. Broadcom became a sort of investment fund rather than an engineering company. Hock even wanted to buy Qualcomm but got blocked by Trump. This was because it was very likely Hock would just divide it into pieces, cut R&D and start charging 2-3x more for the existing products like he did for Broadcom, symantec, CA techmologies and now vmware. He even sued Broadcom customers like VW.. Despite all this its stock is rising and rising..

Re: Qualcomm hardware support increasingly in good shape with Linux kernel

#17

Post by charcircuit »

jauntywundrkind wrote: post #5
charcircuit wrote: post #3

Earlier quoted context omitted.

Don't forget about Android where Qualcomm is popular too. Having upstream support is important for GKI since not everything can just be a kernel module.

I'm having a heckuva time reading the tea leaves on GKI. On the one hand, we might actually be able to upgrade kernels! Neat, overdue, necessary. S24 has 7 years of updates! Why & what changed? Well, there's decent upstream support. Ok, so they can keep the computer running. But the phone is basically a whole second system, and GKI promise to let them keep the phone parts running along as is, while the computer part…

>We're opening a pandora's box where a good portion of the computer's drivers are no longer running on Linux.

What do you mean by this? Device drivers are still running on Linux.

>How many of the upstreaming efforts that are now underway will be undermined by folks running vendor blobs against the stable & closed Google Kernel Interface

Keep in mind that the KMI (kernel module interface) is only stable within the same LTS release. When upgrading to the next LTS there can be breakages since Linux still hasn't made a stable API for out of tree developers to use.

>instead of the changing & GPL Linux Kernel Interface

The interface is the same normal interface as any other kernel modules. It's up to the kernel module's developers if they wish to use GPL exported symbols or not.

>GKI seems like an insane threat to mainstream winning

I see it as being mostly neutral as it's goal is for being able to deliver security updates to phones by just swapping out the kernel. It's slightly beneficial in the sense that the code for the initial startup of the system has to be upstreamed since the kernel has to be able to boot far enough to get to the point where it can load vendor kernel modules.

>it's a totally parallel constructed world designed to avoid the need to mainstream

The world where there is code that can not be upstreamed already exists. GKI is about cleaning up the boundary of where upstream code lives and where third party code lives making each piece more modular.

>I'd love to see a Google Kernel Interface run on a non-Android device

As mentioned by a sibling GKI stands for Google Kernel Image and you could run it on a non Android device if you wish as it's open source including information like what version of the compiler should be used.

>& have the wrapper be ultra-coupled to Android

There is no wrapper here. There are a few additional patches to the kernel that add some hooks for vendor kernel modules to use, but kernel modules do not have to go through a wrapper.

Re: Qualcomm hardware support increasingly in good shape with Linux kernel

#18

Post by seba_dos1 »

zozbot234 wrote: post #15
protastus wrote: post #13

Earlier quoted context omitted.

There are so many ways they could help. For GPU, they could support freedreno (both the kernel and Mesa parts) instead of KGSL and the closed source Adreno libraries. A great start would be to make the user space Adreno GLES libraries talk to the freedreno DRM backend. So one could use the QC proprietary GLES libs with a mainline kernel without rebuilding with KGSL. There's a similar story here for every subsystem dr…

But Qualcomm does not currently support freedreno, it's purely a community effort. It's not Qualcomm's job to bring it to feature parity with their proprietary drivers, so the proposal to have their libraries talk to it by default is just not very sensible.

> It's not Qualcomm's job

It should be if they're really serious about software support.

Re: Qualcomm hardware support increasingly in good shape with Linux kernel

#19

Post by protastus »

zozbot234 wrote: post #15
protastus wrote: post #13

Earlier quoted context omitted.

There are so many ways they could help. For GPU, they could support freedreno (both the kernel and Mesa parts) instead of KGSL and the closed source Adreno libraries. A great start would be to make the user space Adreno GLES libraries talk to the freedreno DRM backend. So one could use the QC proprietary GLES libs with a mainline kernel without rebuilding with KGSL. There's a similar story here for every subsystem dr…

But Qualcomm does not currently support freedreno, it's purely a community effort. It's not Qualcomm's job to bring it to feature parity with their proprietary drivers, so the proposal to have their libraries talk to it by default is just not very sensible.

You claimed it wasn't clear how Qualcomm could help. I pointed out how they could help. There's precedent too, with ARM supporting panfrost.

QC is not a low level employee lacking agency over their job description. They're a business that is free to set their strategy in response to risk and competition.

The less that QC upstreams, the more risk they incur, especially with tightening security scrutiny (e.g. 2021 Cyber EO requirements).

QC can also get disrupted by Mediatek doing a better job with Linux.

Re: Qualcomm hardware support increasingly in good shape with Linux kernel

#20

Post by qwertox »

bgnn wrote: post #16
dirkf wrote: post #6

On a related note: I have the impression Broadcom is more and more losing terrain to the likes of Qualcomm and Mediatek. A couple of years ago nearly everybody was using Broadcom chips in their products (or at least in the consumer-grade telecom devices I'm familiar with as part of my job). Now I'm seeing a shift away from them. I can't really say if it's due to better features, price, vendor support, open source sup…

it's because of the CEO Hock Tan. Broadcom became a sort of investment fund rather than an engineering company. Hock even wanted to buy Qualcomm but got blocked by Trump. This was because it was very likely Hock would just divide it into pieces, cut R&D and start charging 2-3x more for the existing products like he did for Broadcom, symantec, CA techmologies and now vmware. He even sued Broadcom customers like VW.. D…

Broadcom is so odd that I get the feeling that they landed a huge hidden deal with the US government that they no longer have the need to do traditional free-market business.
Post reply on HN