Hi again,

regarding upstreaming my commits there are few major reasons why it didn't happen:

• this kernel work was my first experience with kernel internals, pure C and git. Hence many commits are not up to linux kernel coding standards - they do work, but they can't be used "as is" for upstreaming

• some of the drivers were part of the kernel, but seemed to be from different code base - depending on their usage they were modified, or rewritten based on original Nokia kernel. I guess replacing entire drivers is not something that would be upstreamed easy. For example CMT parts from n900 are different than those used on N9. N900 stuff got upstreamed (or is about to be), and I'm not really sure if it's the same HW, or there needs to be some N9/N950 specific stuff in there.

• some hw can't be used without binary blobs from Harmattan (battery - BME, camera - lipomap3camd, and GPS as mentioned earlier). This forced me to do some nasty hacks (twl4030-madc seemed to be quite different and needed "old" stuff in order for BME to work, libomap3camd has trouble because v4l2_event has changed ABI...) This also would be difficult to upstream.

• many of the stuff in there has no proper documentation (CMT, GPS...), hence it would be difficult to explain why some changes are needed. I guess saying: "It works that way", wouldn't be enough

• Jolla used non LTS kernel as a base, maybe if we were on 3.4 LTS this would be a bit easier (AFAIK only "must have" reason for 3.0+ kernel was usage of systemd in Mer)

• Kernel has shifted to device tree, but many of the stuff placed in board-rm680.c seem to be difficult do implement in such way - some of this would also require rewriting drivers

Sadly both of my N9's have stopped working (both developed problems with their CMT modules, one has since been destroyed in an attempt to fix it) I've moved to Android (and no, it's not working out for me. This has reduced my interest in this project considerably, but I'm willing to help. At this point I'm thinking that we would need some kernel hacker that has good knowledge of kernel internals (and maybe even has connections with TI kernel guys and old Nokians that worked on N9) that would be willing to go trough my commits. Still I think that due to lack of documentation (MEIF requires signing NDA with Nokia, so does camera smiapp - together with bunch of "smiapp compatible" sensors that have quirks as they are not 100% compatible - contacting Toshiba, Sony for datasheets could be problematic...) current kernel state is probably best we can do.

It would be awesome if you succeed in getting some helping hands, but I'm under impression that N9/N950 didn't manage to attract "hardcore linux hackers" (at least not as much as N900 did) making it difficult (if not impossible) to find the "right people". In all this time I'm able to count all interested in N9 kernel on fingers of one hand

I've subscribed to TMO thread you linked, and I'll keep an eye on further progress!

Jolla guys did make first steps in making 3.5.3 bootable on N9, but after they moved onto their own HW they stopped developing N9 kernel further. I've made some progress since then, but biggest obstacle remains: problem of performance. It's believed to be due to rather hacky way wayland is implemented on top of closed source PVR binaries (https://github.com/nemomobile/ti-oma...-wayland-wsegl). Possible solutions would be to fix existing wayland implementation (https://twitter.com/hedayatvk was investigating that), or use PVR drivers for android (from LG Optimus Black P970, https://twitter.com/crazybulgarian was looking into that). There is also small possibility that Imagination makes open source driver (https://www.phoronix.com/scan.php?pa...R-Open-Chatter) but I wouldn't hold my breath on that one.

The only non function part of the kernel is GPS - and this will remain unchanged. GPS chip speaks MEIF instead of NMEA, and all the binary blobs for GPS (there seem to be a few of those) from Harmattan are tied to Qt4.

Hello!

You can look at page http://elinux.org/N900 which track upstreaming
status for Nokia N900.

Process for upstreaming support for N9 or N900 should be similar or
quite same.

There are basically two big problems:

1) SGX graphics drivers and changes they need in mainline kernel

There is no open source userspace support for these TI/IM/SGX drivers
and this is enough reason that they will never be merged into mainline
kernel. Also now only KMS graphics drivers are accepted to mainline
kernel, so you those SGX kernel drivers (even they are GPLv2) will never
hit mainline kernel.

Just to note that *every* and *every* SGX chip needs different:
microcode, kernel driver and userspace driver.

Plus those SGX kernel drivers needs some changes (hacks!!) to mainline
kernel to make they work.

I would just say, ignore SGX driver in upstream process and keep them in
separate tree (with also changes to mainline kernel which are needed).


2) Quality of current Nokia/TI drivers which are in some production
Nokia kernels used on Nokia N9.

Lot of times quality is really bad and in that state drivers are not
accepted. You need to communicate with developers of specific kernel
trees what do they think about those drivers, what needed to be fixed,
changes and so, so maintainers can accept and merged them.

Plus whole OMAP and ARM code in kernel is converting to DeviceTree
structures (from old board code), so when you will try to mainline it,
you need to add support for DeviceTree (and probably remove old
platform_device board code which is obsolated).


3) First and important: Create table line on http://elinux.org/N900 and
decide which drivers are needed, which are already in upstream (but
in different name, etc) and which must be rewritten (e.g because
interface/subsystem was changed).

Thanks all.

I think all hackers who hacking n900 kernel know all these information,
so for them it is not needed...

>
>> 3) First and important: Create table line on http://elinux.org/N900 and
>> decide which drivers are needed, which are already in upstream (but
>> in different name, etc) and which must be rewritten (e.g because
>> interface/subsystem was changed).
>
> You mean that we should combine the N900 & N9 efforts together?
>

Rather create new wiki page (on elinux.org). Please not add N9 info into
N900 page as we want to have that page clean...

Originally Posted by marmistrz

Feature request: could you add the possibility of installing kernel only to debian900, without removing all the fs?

When I have time to devote to the N950 kernel upstreaming, I'll probably test >1 kernels, so I don't want to kill my internal memory with write cycles.