Update linux-samsung-p4wifi to kernel 4.16
Created by: Decatf
Notable changes to the p4wifi kernel:
-
Use mainline Broadcom Bluetooth HCI serial driver. Bleeding edge changes in mainline makes BT possible. The current BT stack has moved firmware loading from userspace into the kernel driver. I made a mistake with the firmware paths and it turned out the BT device works without the firmware being loaded. It does not work if the firmware that was pulled from stock ROM is loaded. It is strange but the only thing I can think of is that maybe the bootloader loads firmware. The Samsung bootloader is closed source and locked so we'll never know what's under there.
-
Use mainline Atmel maxtouch driver. It also works without loading the firmware. What the heck.
-
Use mainline STMPE811 driver. The STMPEXXXX series of multi-purpose controller chips has a MFD driver in mainline. The p4wifi only uses the ADC functionality which doesn't exist in mainline. I've used the STMPE framework and added a block that provides ADC function.
With these changes I've dropped the forward port driver counterparts and cleaned up the kernel git history a bit.
Most notable from all this is that bluetooth works. I've packaged Blueman a GTK bluetooth manager. The device is able to pair and transfer files to/from my laptop. Is it worth adding Blueman to pmOS? Only one hurdle is that Blueman depends on libnotify to provide gobject introspection binding for Python but libnotify in Alpine isn't compiled with the introspection files.
Merge request reports
Activity
Last reply by Administrator- Last reply by Administrator
- Last reply by Administrator
-
Created by: PureTryOut
It might be preferable to upstream Blueman to Alpine directly rather than first to us. It's a desktop-focussed Bluetooth interface which fits great in environments like Xfce and Mate (both in upstream repos), and they could probably really use it, where it makes less sense on a phone.
By * postmarketOS Bot on 2018-04-03T00:02:13
-
Created by: Decatf
Code looks good.
If you want to find more about the bootloader possibly loading the firmware, maybe the folks at #postmarketOS-lowlevel could give some helpful pointers.
On a related note: We're slowly heading towards having Android devices using the linux-postmarketos-* packages as well (right now, they are only used by the N900 and qemu-* devices). There will probably a linux-postmarketos-qcom package soon for the Nexus 5 and other Qualcomm devices. What do you think about creating a linux-postmarketos-tegra package, where your patches are just applied as patch files to the latest mainline kernel?
That way we could share the package between other tegra devices, and we could provide more regular kernel updates (that is by trying to apply the patches to the latest mainline kernel, and if they do, just release the update). Plus it would be easy to see how far we're away from mainline without patches.
I've always had this under consideration since early on in porting this device to mainline. The issue is that there are lots of device quirks which require work arounds or hacks in the code. My approach has always been to prioritize making things work functionally for end users. I maintain a 4.4 kernel for my Android ROM. It has been a requirement to carry on warts in code over making it clean and ideally written.
I've kept this shared tegra kernel as a secondary and long term task. It's been gradually getting closer but at the moment it's not possible. I haven't been able to completely be rid of all these work arounds.
For example one long standing issue is that the display controller chip requires a precise clock frequency driving it. In the downstream (stock OEM) kernel the work around is to re-arrange the clock tree. This means changes to core code in a way that's not compatible with other devices. The peripherals are re-parented to a different PLL while one is dedicated to driving the display controller. This deviates from the standard Tegra design. It's not pretty but it works so I kept using that configuration. That's not the end of the story though. It's just that it took so much time to tinker so I left it be in favor making other things work.
So the answer to this is maybe. It all depends on being able to work out the remaining device specific issues such that the work arounds won't break other devices. Without resolving these it remains a device specific kernel and not a generic one. I will need to think about those remaining issues some more.
Is it worth adding Blueman to pmOS? Only one hurdle is that Blueman depends on libnotify to provide gobject introspection binding for Python but libnotify in Alpine isn't compiled with the introspection files.
I think it would be good to have any program to demonstrate the bluetooth function (can Plasma Mobile do bluetooth already @bhush9?). If you want to, you could make a PR to Alpine's aports that enables the introspection files in libnotify (possibly as subpackage, so Alpine users don't need to install them when they don't need it). After that you could make a PR with your Blueman port for pmOS (and if you're willing to maintain it, you could upstream that to Alpine as well).
I will try to get the gobject introspection bindings in upstream. I don't think I would maintain a Blueman package in upstream though.
PS: Note sure if you saw #1386 (comment). But we did not decide on making deviceinfo_dtb available for linux-postmarketos only yet, so it's fine for me either way. In case we have a linux-postmarketos-tegra package, then using deviceinfo_dtb would be the right way to go anyhow.
Okay, I'll use deviceinfo_dtb until the case where it's decided that it's for linux-postmarketos only or ultimately a generic tegra package doesn't work out.
By * postmarketOS Bot on 2018-04-03T01:48:47
Edited by Ghost User
