A Bunch Of New ARM Hardware Will Be Supported With Linux 4.6

[phoronix]

Phoronix: A Bunch Of New ARM Hardware Will Be Supported With Linux 4.6

The ARM SoC updates were mailed out on Sunday afternoon for the Linux 4.6 kernel and it provides mainline support for thirteen new SoCs!..

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.6-New-ARM-SoCs

[stevenc]

Amlogic S905 (meson-gxbb)

Ah, the SoC used by Odroid C2. Having that mainlined should mean it is better supported long-term than past Odroid boards like -XU series.

improved support for the Nokia N900

That's great! But about 5 years too late.

[Imroy]

I'm sure I'm not the only one waiting for mainstream kernel support before ordering the Odroid C2. So this is a promising first step.

[pal666]

I'm sure I'm not the only one waiting for mainstream kernel support before ordering the Odroid C2. So this is a promising first step.

I'm sure I'm not the only one waiting for mainstream mesa support before ordering the Odroid C2. So it has many steps to do.

[onokun]

Allwinner A64 SoC

Can't wait.
Keeping in mind pine64 and Olimex boards.

[SystemCrasher]

Ah, the SoC used by Odroid C2. Having that mainlined should mean it is better supported long-term than past Odroid boards like -XU series.

That's great! But about 5 years too late.

There're still plenty of people using these epic phones, er, I mean pocket computers. Somehow, this platform just refused to die and has been taken over by community instead. That's why opensource is good: it is alive as long as people need it and ready to maintain it. No forced shutdowns, no angered users, no operational costs for Nokia, etc. On other hand, devices tied to closed ecosystems would turn into useless brick once vendor shuts down appstore, etc.

[Ardje]

There're still plenty of people using these epic phones, er, I mean pocket computers. Somehow, this platform just refused to die and has been taken over by community instead. That's why opensource is good: it is alive as long as people need it and ready to maintain it. No forced shutdowns, no angered users, no operational costs for Nokia, etc. On other hand, devices tied to closed ecosystems would turn into useless brick once vendor shuts down appstore, etc.

Indeed. Except for the exynos 5410, the older exynos 4 has received new patches in upstream kernels end of last year.
Problem with all the SoC's is: there is no *full* upstream support.
All the exynos and other SoC's can be compiled for and run, but they contain hardware for which upstream infra structure still hasn't settled.
You might have a 100% opensource kernel, but if upstream kernel has no stable hdmi settings api, or an interface for stapling of v4l2m2m devices together you have to do it yourself.
(That's how v4l2 m2m came to be: we have this device which we want to deliver drivers for, let's try creating a v4l2 m2m structure).
Even simple GPIO on a USB to RS232 interface is not accepted, but a GPIO infra structure (so new patches would be accepted) has been thought about for 5 years now.
Not bashing kernel things, but just those that would say "SoC has an outdated kernel support". It usually is the other way around: the kernel has no standardized support yet for the hardware on the SoC, and hence cannot accept it.
But I might be so lucky that the since long end-of-lifed s3c6410 now has full kernel and dtb support.

[stevenc]

There're still plenty of people using these epic phones, er, I mean pocket computers.

Actually including me And quite a lot of people on these forums it seems.

[SystemCrasher]

Indeed. Except for the exynos 5410, the older exynos 4 has received new patches in upstream kernels end of last year.
Problem with all the SoC's is: there is no *full* upstream support.

Well, it depends. Concerning N900, mainline kernels support nearly all imaginable hardware RX-51 has got. Even cellular modem, some custom nokian tyres ASICs and so on. There're no stinky RIL blob daemons and other android shit. People coded drivers for Ti's BQ-something ("power gauge" and "switching battery charger" ICs). As well as user-mode "BME" counterpart, which actually handles battery charging, low voltage shutdown and so on.

Overall, OMAP3 support in Linux is quite decent. I'm aware of one major shortcomings: GPU drivers rely on 2.6.28 kernel. But it is not a mainline kernel fault Imagination has never published details about PowerVRs, not to mention proper Linux support. Hopefully it gives idea why so many people are eager to swing by their middle fingers when they hear "imagination" or "PowerVR".

All the exynos and other SoC's can be compiled for and run, but they contain hardware for which upstream infra structure still hasn't settled.
You might have a 100% opensource kernel, but if upstream kernel has no stable hdmi settings api,

Linux has got DRM/KMS a while ago, these are fairly generic, they can handle virtually everything. HDMI included, as seen on quite some GPUs & SoCs. I do not get how or why samsung needs special treatment in this regard. If samsung or their community haven't coded proper HW support, it isn't Linux fault. If it needs something really special... as I've recently seen in related mailing lists, people tend to be quite ok about changing DRM/KMS if it fails to cover some use case.

or an interface for stapling of v4l2m2m devices together you have to do it yourself.

I've never seen things like this, but I can swear I've seen some commotion in commit log related to m2m v4l devices. Nokia N900 is fine with "usual' v4l. Omap3 camera IF and N900's sensor are mainlined, etc.

(That's how v4l2 m2m came to be: we have this device which we want to deliver drivers for, let's try creating a v4l2 m2m structure).

Releasing Linux-based device before infrastructure is available hardly counts as major advantage for Samsung or their devices, right?

Even simple GPIO on a USB to RS232 interface is not accepted, but a GPIO infra structure (so new patches would be accepted) has been thought about for 5 years now.

Once again, this is exotic use case. USB to RS232 is normally a tty device, not GPIO. Some few advanced ICs like FTDI2232/4332 and somesuch are more or less like "real" GPIO, which make sense to expose it like GPIOs, but it is not as simple: they have MPSSE engine and I'm not really sure if kernel should support it instead of usermode. I can imagine it could be nice to expose GPIO-like entities in universal way, but not sure how far it should go. IIRC there is already GPIO framework and it being used to expose like a dozen of various kinds of GPIO more or less same way, where user-mode apps do not have to know how exactly some HW implements "gpio". Do you refer this thing, as seen in 4.4-4.5 kernels, or it going to be reworked further/replaced? I can also see LEDs already got more or less unified, to degree I can blink my keyboard leds by usual means. Though somehow, kbd leds aren't exactly well-behaving if I'm trying to use "triggers". I know I want strange thing assigning capslock to CPU load trigger, but same thing works on GPIO based LEDs, dammit.

Not bashing kernel things, but just those that would say "SoC has an outdated kernel support". It usually is the other way around: the kernel has no standardized support yet for the hardware on the SoC, and hence cannot accept it. But I might be so lucky that the since long end-of-lifed s3c6410 now has full kernel and dtb support.

TBH I do not know how it happens in Samsung, I only have idea about OMAPs (due to N900), Allwinner and to less extent Rockchip and few others (due to small devices I'm using for fun and profit) and some MIPS things (due to OpenWRT-related devices). When it comes to kernel it always happens to be moving target, and it is quite okay if some subsystems are changed or added on the go. That's how opensource works. And, honestly, vendor kernels must die in long term. World would be much better place if vendors would do like AMD, cooperating with mainline devs and getting their crap supported in mainline BEFORE releasing devices. Vendor kernels are IMHO dead end in long term, it leads to resources wasted on doing odd things and a lot of abandonware since supporting kernel is a daunting task. Those who aren't mainline kernel devs are inherently unable to do it right, dooming their users to run old kernels with plenty of known bugs or even vulns. IMHO it suxx.

[johanb]

So now that the Odroid C2s processor is supported upstream, what's left to be able to run it on a upstream kernel except for the graphics?

I'm thinking of getting a Odroid C2 as a headless server, so if I could use it with the upstream kernel that would be a huge plus.