| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After resume from suspend the NVMe does not wake up again when the
device was put into D3cold. This is something that is worked around by
TUXEDO Tomte[1] via udev rules. However, I personally don't like this
approach and it can lead to race conditions when we're going into
suspend before udev is initialised.
Interestingly, the device does even go into NPSS via APST, but if
changing to D3cold while APST is enabled, the device does not wake up
again.
Right now I just added a new quirk to disable D3cold during device
probe for now, but we could maybe find a better workaround eg. by
disabling APST before D3cold and re-enabling it again. Not sure whether
this is feasible, but since I have limited time right now I can't dig
more into this.
[1]: https://github.com/tuxedocomputers/tuxedo-tomte/commit/2c8d71170868a2663705fbea6ac150eecb96e6ce
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
| |
Yay static linting.
|
|
|
|
|
|
|
|
| |
Not updating the microcode on thinkpads is kind of a death sentence
for some kernel updates, so let’s do it by default.
In case somebody uses it for an AMD thinkpad in the future, we might
have to check whether the option creates a problem.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I had some weird issues with the low-battery udev rule, mainly it not
triggering when it should. Usually, the event would only get processed
when the battery changed state, e.g. from Discharging to Charging.
Consequently, the laptop would hibernate when you'd save it from running
out of battery by plugging it in, but, if you forgot, it'd be content to
run out of battery.
I'll try upower instead now which is the “normal” solution used by the
major desktop environments. It's has some extra complexity, as it also
provides a d-bus API for other applications to use, but we'll see how it
goes.
|
|
|
|
|
|
| |
This kernel module is required for some operations supported by
TLP (e.g. tlp recalibrate), so we should enable it and be it to prevent
confusing error messages (as I encountered).
|
| |
|
|
|
|
|
|
|
| |
`runCommandLocal` was added to nixpkgs in
https://github.com/NixOS/nixpkgs/pull/74642
to speed up trivial `runCommand` derivations by always building them
locally. We have a few places where that’s good to use.
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have not yet tested this in production but will do shortly.
Nevertheless, kernel 4.19 should bring a few improvements regarding
hardware support to the table and kernel 4.14 doesn't build anymore with
our BFQ patch, so let's move on :-)
In case the kernel doesn't work, we can still patch it up accordingly.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
| |
Introduced in NixOS/nixpkgs@53730c5a9228be45add3f71482f6827b3d950fa0.
Let's stay on version 4.14 for now and backport patches from later
releases, because 4.14 is the latest LTS release which includes enough
hardware support for the T100HA to work.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
| |
While grepping for occurences of importing nixpkgs-path.nix I found this
and it really is unused, so let's remove it.
No functional changes.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Almost all of the issues we so far needed patches for have been
addressed upstream with the exception of backlight probing.
The reason for this is detailled in the following bug:
https://bugs.freedesktop.org/show_bug.cgi?id=96571
In summary, when the I915 driver is built into the kernel, it can't
access the PWM because it's initialized at a later stage.
What we're now doing instead is that we compile i915 as a module and
bake the necessary PWM modules directly into the kernel.
This has the advantage that we no longer need the backlight.patch,
because after all this is already a workaround and having a workaround
that doesn't require us to rebase the patch once a new kernel arrives
seems to be a better solution in my opinion.
With this update we can now revert the reintroduction of kernel 4.12
done in 45bdcd7fc7788316cbad2d7d412e421b230715dc.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
It has been removed by NixOS/nixpkgs@964672dde516d1b9a5d2248db33253dc36.
This kernel version is officially EOL but in order to switch to a newer
kernel I need to rebase the patches first.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
We no longer need to use linux_testing, because kernel 4.12 is stable
since yesterday.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can now safely drop the sound, sdio and drm patches, because they all
have been applied upstream already and after some testing the T100HA
works quite nicely.
One exception however is a small part from the drm patch, which is the
PMIC hack which I originally introduced in
e8861698f019eb218be451e444898a1cb5577d21 as a separate file which it's
now again, but rebased against kernel 4.12-rc6.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
| |
This is because `enableAllFirmware` now contains a new entry that is unfree.
Other machines probably want to move as well, cc @aszlig @sternenseemann.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following commit was introduced in kernel 4.9.3:
* ASoC: cht_bsw_rt5645: Fix leftover kmalloc
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.3
This is the only commit that was dropped (because it was applied
upstream) during this rebase.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following two commits were introduced in kernel 4.9.2:
* drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from
vlv_init_display_clock_gating
* drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting
See https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.2 for a
full change log.
So we no longer need these commits anymore, because they were applied
upstream.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
| |
With the latest patches, this is no longer needed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
Regression introduced by 4a27d62243942c4be181c7129fb532a709a15a8e.
I've removed the fwbase variable in this commit, so the kernel is unable
to completely load the WiFi firmware.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
After fixing the issues left we had since version 4.8, we can now safely
switch to the latest mainline kernel. Turns out that the system is now a
lot more stable and triggers less warnings and errors in dmesg.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is essentially a backport of @plbossart's "experimental/codecs"
branch against Linux 4.9.
The original repository can be found at:
https://github.com/plbossart/sound/commits/experimental/codecs
Thanks to him for doing a lot of work on getting sound working for these
CherryTrail devices.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is essentially a cherry-pick of the three commits mentioned in:
https://bugs.freedesktop.org/show_bug.cgi?id=97529#c33
Plus a backport against Linux 4.9 of the following patch:
https://bugs.freedesktop.org/attachment.cgi?id=128410
(essentially https://patchwork.freedesktop.org/series/16242/)
And also the backlight.patch (a PMIC hack) we had before all combined
into one patch, which now should fix the following bug:
https://bugs.freedesktop.org/show_bug.cgi?id=97529
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation of boot.kernelPatches uses .override and passes back
the original kernelPatches attribute to the patches that are going to be
added from boot.kernelPatches.
However, the T100HA module already uses .override to pass these patches
but without re-using the existing patches. So instead of just adding
preexisting patches to the kernelPatches attribute, let's just switch to
boot.kernelPatches, which should also allow overrides and introspection
from different NixOS modules.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
The right attribute is vuizvui.kernel.linux_4_7 and not
vuizvui.linux_4_7.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removed in NixOS/nixpkgs@b3f7d626c164ae591a067f78bfcbb06fc3a588b9.
We are currently stuck in 4.7 with the T100HA because of this upstream
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=97529
So let's bring back the expression for Linux 4.7 until there is time for
debugging the mentioned bug.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While I had terse Internet connectivity these days, I haven't checked
T100HA hardware related news/patchs very often.
Meanwhile a small patch by @tagorereddy popped up on hadess/rtl8723bs#80
which works around the SDIO detection.
On some devices the BIOS has an option to map the SDIO controller to PCI
instead of ACPI, but the T100HA doesn't have this option.
IIUC the issue here is that the controller is already being attached via
PCI device ID 80862280, which prevented the platform device from being
attached via ACPI.
The patch circumvents that by removing PCI device ID 80862280 while
probing for ACPI devices in SDHCI (yes, very hacky but works) and forces
the ACPI platform device to be initialized if the HID is 80860F14:02.
I've rebased and tidied up the original patch a bit to prevent warnings
during build.
Other than this patch, we now need to add the right firmware and the
corresponding parameters to hardware.firmware, so that the actual driver
for the WiFi card can be loaded.
The firmware parameters are stored in EFI on the host itself:
/sys/firmware/efi/efivars/nvram-74b00bd9-805a-4d61-b51f-43268123d113
So I added a copy of it to prevent impurities.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
Since NixOS/nixpkgs@da36847d925058fd86f027b64cc712c57be11ad8 we no
longer need so much cruft to specify kernel patches, so let's switch to
boot.kernelPatches instead of the hackery we had so far.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
Kernel 4.8 currently has an Intel GFX regression right now, so let's
keep it at kernel 4.7 until we have properly bisected the issue and/or
have a fix for this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Upstream issue: https://bugs.freedesktop.org/show_bug.cgi?id=97529
|
|
|
|
|
|
|
| |
The upstream repository now has support for kernel 4.x, so we no longer
need the patch.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
These flags are applied via the kernel config, so if we add it using our
compiler wrapper the kernel build process is unable to detect these
flags and the build will fail.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using xset for DPMS control only works as soon as we have an X session,
but we want to work around the issue as early as possible so let's set
it in preDeviceCommands.
The program here directly uses the ioctls to blank/unblank the current
console without enums/constants (14 is blank and 4 is unblank) because
it's just a workaround and supposed to go away in the near future.
If we'd wanted to use the constants from tiocl.h, we'd have to add
dependencies on Linux headers, but I'm lazy right now ;-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
This reverts commit bafb5933654cdb7e35f0c54418bdd0dcb999f98c.
We can finally drop that patch, because the issue has been fixed
upstream already.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
This was a copy & paste error by me, because I copied the options out of
an existing configuration, which contained the CONFIG_ prefixes. Within
extraConfig of the generic kernel builder, we only use the names without
prefixes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 9d4575855bf1ae2136d85a2d0aa7b5ede50cfc67.
The upstream issue systemd/systemd#3735 has been fixed and it got
included in systemd version 331.
Since NixOS/nixpkgs@51871dfb3777 we're also on version 331, so we
no longer need this patch in Vuizvui.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
| |
Let's enable the options that *should* work with this kind of hardware
regardless whether it's currently working in mainline. It doesn't make a
huge difference to the kernel configuration prior to this change, but
let's better compile in these options rather than wondering why some
hardware isn't working.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I didn't use -rc6 directly but a few commits after the tag.
Within the mainline merges there was torvalds/linux@45209046c47b93fad.
I didn't investigate further why this exactly is a problem other than
freezing the machine shortly after the bootloader hands over control to
the kernel.
Reverting this commit fixes this issue for now until I have time to look
into it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
Not that this improves anything significant in terms of hardware
support, but I'm debugging on the basis of the -next kernels, so it's
better to stay on latest mainline for the vuizvui builds (current -next
kernels for the last few weeks make the situation even worse).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
| |
This one is tracked upstream at systemd/systemd#3632.
I've implemented the workaround proposed by @medhefgo as a patch.
As this module is only for a particular hardware, we won't cause
troubles for other hardware.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
| |
This adds a few #ifdefs for Atom platforms, however I don't remember
what exactly it fixed/changed for the T100HA.
Nevertheless it's probably a good idea to optimize for that architecture
because we're going to compile our custom kernel anyway.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 0182e0ca12760da2aecd65de98c85a76ecdcedc6.
With the latest testing kernel, the machine still gets random GPU
lockups which are already fixed in linux-next, so let's get back to
linux-next even though things break from time to time.
We can still pin a specific next version to base our patches on once we
have a base version that's stable enough.
I've also fixed the backlight patch to compile against the latest next
version.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
This fix is more or less because of GCC 5 rather than just against
kernel 4.x, because the number of arguments for rtw_select_queue() have
been changed since 4.0 already.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
This is to not clutter up the hardware/ namespace with patches (we're
going to add one).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, linux-next-20160408 introduces a few unrelated bugs to the
hardware, so instead of updating to the latest -next version, we're
going for the latest -rc instead.
This should also help a lot in development to focus on the important
parts instead of dealing with completely unrelated bugs/issues.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
| |
This really is specific to the RTL8192CX chipset and I originally was
using this for tyree along with the mainline kernel modules.
Unfortunately, I had connection drop outs so I switched to the original
Realtek driver, which is now vuizvui.hardware.rtl8192cu, so the firmware
is used and should be enabled there as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
It's actually a backport of Realtek's own USB WiFi driver that is not
(yet?) in mainline. I'm using this for tyree (the T100HA) because the
internal WiFi card isn't recognized by SDHCI yet.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
| |
Essentially forcing DPMS standby and bringing it on again for now
mitigates the vblank issue with the I915 driver.
Of course in the long term I need to debug this properly, but for now
this works consistently so I'll leave it that way.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both of these patches are from the following Google Drive:
https://drive.google.com/folderview?id=0B4DiU2o72FbuejQ1S2VZZW5xV2c
The meta-keys-asus.patch (which is called just meta-keys.patch in this
repository) is used verbatim.
However, the baytrail-backlight.4.4.patch (here just backlight.patch) is
a rebased version of the patch from the Google Drive with a few
modifications by me, which boils down to:
* Remove the module parameter force_backlight_pmic, because this module
is hardware-specific so we don't actually need to do that (and *if*
we want to do that we'd compile it in directly).
* Add an unused pipe function argument to vlv_pmic_setup_backlight().
As the backlight patch introduces the functions intel_soc_pmic_readb()
and intel_soc_pmic_writeb() which are not available at module link time,
I have also added DRM_I915 to be compiled into the kernel.
In addition I needed to disable VIDEO_EM28XX and RAPIDIO, because they
do not compile with linux-next-20160226 and I didn't bother to provide
fixes because it's for hardware that is not existing on the T100HA.
Note that I'm using linux-next-20160226 here instead of 20160229 because
the latter has some networking I/O issues right now.
This makes the backlight, battery status and charging usable on the
T100HA and the fixes from the drm-intel-fixes branch are no longer
needed because they're already in linux-next-20160229.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
So far INTEL_SOC_PMIC hasn't been enabled *at* *all* so there wasn't any
battery status available nor did it charge while the system was running.
Enabling INTEL_SOC_PMIC now solves this issue.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already have a directory just for hardware-specific configuration
options and the module option already says "vuizvui.hardware", so it
should better be consistent with the directory layout.
Tested using:
nix-instantiate release.nix -A machines.profpatsch.katara
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|