archlinuxarm/PKGBUILDs — pull request #623 by jquagga (2013-11-16 19:33:49+00:00)
Title: linux-chromebook kernel config changes to better support Spring

from ChromiumOS config. This adds RTC support for the Spring, SlimPort-support (although I have no way to test that), and importantly backlight brightness support so I don't have to wear sunglasses to use the laptop.

Ok, here’s a basic rundown of what I’ve done here. I compared Google’s ChromeOS kernel config and the arch kernel config and ran a diff on hardware drivers in the kernel. Then I made the minimal changes I could to enable those drivers without touching/breaking anything else.

Here’s what the diff below does:

* Bump pkgrel to 2. We’re using the same snapshot as last time, but we are changing the kernel config so I thought it made sense to update this.
* First kernel change is to default to the Interactive Governor. This is the same setting ChromeOS is using now. This is not strictly required for hardware support of course, but it does match upstream and I often use this laptop in interactive usage. This could certainly be undone though.
* We add the regulator for the Keyboard embedded controller as upstream does. I imagine we want that.
* Video_VIVI is a module in upstream. I made it a module here as well. I’m not sure what this gets us.
* DRM_PS8622 is important as it’s the driver for the display on Spring. This gets me backlight control and all of those wonderful things! HP Chromebook users are certainly going to want this.
* DRM_ANX7808 is the SlimPort video driver for the slim port video out on the Spring. I don’t have a SlimPort adapter to test if it works, but without the driver I’m guessing it wouldn’t work at all. So we’ll add support for that.
* HID_BATTERY_STRENGTH was enabled upstream. It lets my mouse say it’s about to run out of battery so I left it enabled here.
* The Logitech WTP is also enabled upstream as a module. It’s a driver for a logitech multi-touch trackpad. Again, I can pull this out but it’s just a module for a hardware device.
* EHCI_S5P_HSIS_RESET is enabled upstream so I enabled it here.
* The two RTC changes - up until now everything has been an addition. The RTC changes require an addition and the change from y to m (as it is upstream). The s3c driver doesn’t appear to work on Spring. It doesn’t initiate and the clock resets to 1999 on every boot. S5M works fine, however if it’s loaded after S3C (as it does when s3c and s5m are both set to =y), then the clock has already been reset to 1999 and well, it’s pointless. By making S5M a built in and S3C a module, both drivers still load. However now the kernel knows the s3c is spouting nonsense and keeps the data from S5M. That would appear to be what we want. I have a RTC!

Again, I have no way of testing these changes on Snow. The biggest thing to test is that the RTC still works properly (either by using S5M, or by picking up S3C from the module right afterward). Whether or not the default governor should be interactive for on demand I don’t have strong feelings for either way - I was just trying to copy settings from upstream to round out hardware support.