Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update ROG Ally support #15

Closed
wants to merge 49 commits into from

Conversation

flukejones
Copy link

No description provided.

heftig and others added 30 commits July 28, 2024 14:04
Our default behavior continues to match the vanilla kernel.
The Nvidia proprietary driver has some bugs that leads to issues if used
with the simpledrm driver. The most noticeable is that does not register
an emulated fbdev device.

It just relies on a fbdev to be registered by another driver, that could
be that could be attached to the framebuffer console. On UEFI machines,
this is the efifb driver.

This means that disabling the efifb driver will cause virtual consoles to
not be present in the system when using the Nvidia driver. Legacy BIOS is
not affected just because fbcon is not used there, but instead vgacon.

Unless a VGA mode is specified using the vga= kernel command line option,
in that case the vesafb driver is used instead and its fbdev attached to
the fbcon.

This is a problem because with CONFIG_SYSFB_SIMPLEFB=y, the sysfb platform
code attempts to register a "simple-framebuffer" platform device (that is
matched against simpledrm) and only registers either an "efi-framebuffer"
or "vesa-framebuffer" if this fails to be registered due the video modes
not being compatible.

The Nvidia driver relying on another driver to register the fbdev is quite
fragile, since it can't really assume those will stick around. For example
there are patches posted to remove the EFI and VESA platform devices once
a real DRM or fbdev driver probes.

But in any case, moving to a simpledrm + emulated fbdev only breaks this
assumption and causes users to not have VT if the Nvidia driver is used.

So to prevent this, let's add a workaround and make the sysfb to skip the
"simple-framebuffer" registration when nvidia-drm.modeset=1 option is set.

This is quite horrible, but honestly I can't think of any other approach.

For this to work, the CONFIG_FB_EFI and CONFIG_FB_VESA config options must
be enabled besides CONFIG_DRM_SIMPLEDRM.

Signed-off-by: Javier Martinez Canillas <[email protected]>
Cherry-picked-for: https://bugs.archlinux.org/task/73720
To mitigate https://zolutal.github.io/aslrnt/; do this with a patch to
avoid having to enable `CONFIG_EXPERT`.
Add quirk orientation for AYA NEO 2. The name appears without spaces in
dmi strings. That made it difficult to reuse the 2021 match and the
display is greater in resolution.

Tested by the JELOS team that has been patching their own kernel for a
while now and confirmed by users in the AYA NEO and ChimeraOS discord
servers.

Signed-off-by: Joaquín Ignacio Aramendía <[email protected]>
Add quirk orientation for AYA NEO Founder. The name appears with spaces in
dmi strings as other devices of the brand. The panel is the same as the
NEXT and 2021 models. Those could not be reused as the former has VENDOR
name as "AYANEO" without spaces and the latter has "AYADEVICE".

Tested by the JELOS team that has been patching their own kernel for a
while now and confirmed by users in the AYA NEO and ChimeraOS discord
servers.

Signed-off-by: Joaquín Ignacio Aramendía <[email protected]>
Add quirk orientation for AYA NEO GEEK. One of the more recent devices by
the brand. The name appears without spaces in dmi strings. The board
name is completely different to the previous models making it difficult
to reuse their quirks despite being the same resolution and mounting.

Tested by the JELOS team that has been patching their own kernel for a
while now and confirmed by users in the AYA NEO and ChimeraOS discord
servers.

Signed-off-by: Joaquín Ignacio Aramendía <[email protected]>
Add quirk orientation for the Ayn Loki Zero.

This also has been tested/used by the JELOS team.

Signed-off-by: Bouke Sybren Haarsma <[email protected]>
Add quirk orientation for Ayn Loki Max model.

This has been tested by JELOS team that uses their
own patched kernel for a while now and confirmed by
users in the ChimeraOS discord servers.

Signed-off-by: Bouke Sybren Haarsma <[email protected]>
We are enabling a large set of color calibration features to enhance KMS
color mgmt but these properties are specific of AMD display HW, and
cannot be provided by other vendors. Therefore, set a config option to
enable AMD driver-private properties used on Steam Deck color mgmt
pipeline. Replace the agreed name `AMD_PRIVATE_COLOR` with
our downstream version `CONFIG_DRM_AMD_COLOR_STEAMDECK`.

Signed-off-by: Melissa Wen <[email protected]>
This patch adds a new sysfs event, which will indicate
the userland about a GPU reset, and can also provide
some information like:
- process ID of the process involved with the GPU reset
- process name of the involved process
- the GPU status info (using flags)

This patch also introduces the first flag of the flags
bitmap, which can be appended as and when required.

V2: Addressed review comments from Christian and Amar
   - move the reset information structure to DRM layer
   - drop _ctx from struct name
   - make pid 32 bit(than 64)
   - set flag when VRAM invalid (than valid)
   - add process name as well (Amar)

Cc: Alexandar Deucher <[email protected]>
Cc: Christian Koenig <[email protected]>
Cc: Amaranath Somalapuram <[email protected]>
Signed-off-by: Shashank Sharma <[email protected]>
(cherry picked from commit 90230bd9d9c7d979038547460c9a2cbbeff8d6b9)
[Forward port to 6.0]
Signed-off-by: Cristian Ciocaltea <[email protected]>
This patch adds a work function, which sends a GPU reset
uevent and some contextual infomration, like the PID and
some status flags. This work should be scheduled during
a GPU reset.

The userspace can do some recovery and post-processing work
based on this event and information.

V2: Addressed review comments from Christian
- Changed the name of the work to gpu_reset_event_work
- Added a structure to accommodate some additional information
  (like a PID and some flags)
- Do not add new structure in amdgpu.h

Cc: Alexander Deucher <[email protected]>
Cc: Christian Koenig <[email protected]>
Cc: Amaranath Somalapuram <[email protected]>
Signed-off-by: Shashank Sharma <[email protected]>
(cherry picked from commit f63b09e78126f7da67b69409e2cce1d3ab2d7f46)
[Forward port to 6.0]
Signed-off-by: Cristian Ciocaltea <[email protected]>
Schedule work function with valid PID, process name,
and vram lost status during a GPU reset/ recovery.

Signed-off-by: Somalapuram Amaranath <[email protected]>
(cherry picked from commit 293c019a84c6402b08db9579819b555b01cd613b)
[Forward ported to 6.0]
Signed-off-by: Cristian Ciocaltea <[email protected]>
[Forward ported to 6.9]
Signed-off-by: Bouke Sybren Haarsma <[email protected]>
Add OrangePi NEO handheld device. The OrangePi Neo uses different registers
for PWM manual mode, set PWM, and read fan speed than previous devices. Valid
PWM input and duty cycle is 1-244, we scale this to 1-155 to maintain
compatibility with existing userspace tools.
Add OneXPlayer 2 series and OneXFly handhelds. The 2 series uses a new register
for turbo button takeover. While at it, adjust formatting of some constants and
reorder all cases alphabetically for consistency. Rename some constants for
disambiguation.
Add GPD Win Mini. GPD devices don't have a separate enable register, the PWM
register is used for this purpose. A write value of 0 puts the PWM into auto
mode, writing anything 1-244 puts the PWM into manual mode, and 245-255 are
undefined. We scale to 1-255 and handle manual by writing a value to 70% as a
common sense default.
Bumps the sensitivity of AMD sfh gyro and accelerometers by removing the division
operation and rebasing the units in the hid descriptor.
This helps with the gyro deadzone of the Legion Go. Should not affect existing
devices.
The ultra-low power BMI260 is an IMU consisting of a 16-bit tri-axial
gyroscope and a 16-bit tri-axial accelerometer combining precise
acceleration, angular rate measurement and intelligent on-chip
motion-triggered interrupt features.

The driver supports the BMI260 over I2C. It is based on the BMI160
driver, and like that driver supports accelerometer and gyroscope
reading, as well as data ready interrupts.
Contribution by CVMagic (https://github.com/CVMagic)

aw87xxx: Use strscpy instead of strlcpy

awinic: i2c_driver cleanup and fixes
… also fixed Reset Pin GPIO initialization issue with Ayn Loki Mini
bmi150-accel and bmi323-imu are declared in an almost identical way in the ACPI and in some devices such as the Asus RC71L the "ROTM" property can be found: parse and use the ACPI-defined mount-matrix.

Co-developed-by: Luke D. Jones <[email protected]>
Co-developed-by: Jonathan LoBue <[email protected]>
Signed-off-by: Denis Benato <[email protected]>
jlobue10 and others added 16 commits August 4, 2024 18:33
Patch to test fixing TAS2781 amp getting bound properly to i2c
for ASUS ROG ALLY X.
Add the VID/PID for ASUS ROG RAIKIRI PRO to
xpad_device and the VID to xpad_table.

Signed-off-by: Luke D. Jones <[email protected]>
On almost all ASUS ROG series laptops the MCU used for the USB keyboard
also has a HID packet used for setting the brightness. This is usually
the same as the WMI method. But in some laptops the WMI method either
is missing or doesn't work, so we should default to the HID control.

Signed-off-by: Luke D. Jones <[email protected]>
Add more verbose debug print in the WMI method calls. This helps a lot
with debugging various issues working with regular users as the WMI
methods can be traced now.

Signed-off-by: Luke D. Jones <[email protected]>
…ered

On some newer laptops it appears that an AMD driver can register a
platform_profile handler. If this happens then the asus_wmi driver would
error with -EEXIST when trying to register its own handler leaving the
user with a possibly unusable system - this is especially true for
laptops with an MCU that emit a stream of HID packets, some of which can
be misinterpreted as shutdown signals.

We can safely continue loading the driver instead of bombing out.

Signed-off-by: Luke D. Jones <[email protected]>
In kbd_rgb_mode_store the dev_get_drvdata() call was assuming the device
data was asus_wmi when it was actually led_classdev.

This patch corrects this by making the correct chain of calls to get the
asus_wmi driver data.

Fixes: ae834a5 ("platform/x86: asus-wmi: add support variant of TUF RGB")
Tested-by: Denis Benato <[email protected]>
Signed-off-by: Luke D. Jones <[email protected]>
Adjust quirks for 0x3a20, 0x3a30, 0x3a50 to match the 0x3a60. This
set has now been confirmed to work with this patch.

Signed-off-by: Luke D. Jones <[email protected]>
The new ASUS ROG Ally X functions almost exactly the same as the previous
model, so we can use the same quirks.

Signed-off-by: Luke D. Jones <[email protected]>
The new ROG Ally X functions the same as the previus model so we can use
the same method to ensure the MCU USB devices wake and reconnect
correctly.

Given that two devices marks the start of a trend, this patch also adds
a quirk table to make future additions easier if the MCU is the same.

Signed-off-by: Luke D. Jones <[email protected]>
The fw_attributes_class provides a much cleaner interface to all of the
attributes introduced to asus-wmi. This patch moves all of these extra
attributes over to fw_attributes_class, and shifts the bulk of these
definitions to a new kernel module to reduce the clutter of asus-wmi
with the intention of deprecating the asus-wmi attributes in future.

The work applies only to WMI methods which don't have a clearly defined
place within the sysfs and as a result ended up lumped together in
/sys/devices/platform/asus-nb-wmi/ with no standard API.

Where possible the fw attrs now implement defaults, min, max, scalar,
choices, etc. As en example dgpu_disable becomes:

/sys/class/firmware-attributes/asus-armoury/attributes/dgpu_disable/
├── current_value
├── display_name
├── possible_values
└── type

as do other attributes.

Signed-off-by: Luke D. Jones <[email protected]>
Implement the dgpu TGP control under the asus-armoury module using the
fw_attributes class.

Signed-off-by: Luke D. Jones <[email protected]>
Implement the APU memory size control under the asus-armoury module using
the fw_attributes class.

This allows the APU allocated memory size to be adjusted depending on
the users priority. A reboot is required after change.

Signed-off-by: Luke D. Jones <[email protected]>
Implement Intel core enablement under the asus-armoury module using the
fw_attributes class.

This allows users to enable or disable preformance or efficiency cores
depending on their requirements. After change a reboot is required.

Signed-off-by: Luke D. Jones <[email protected]>
With the existence of the asus-bioscfg module the attributes no-longer
need to live under the /sys/devices/platform/asus-nb-wmi/ path.

Deprecate all those that were implemented in asus-bioscfg with the goal
of removing them fully in the next LTS cycle.

Signed-off-by: Luke D. Jones <[email protected]>
The ASUS ROG Ally X has the same issue as the G14 where it advertises
SPS support but doesn't use it.

Signed-off-by: Luke D. Jones <[email protected]>
@flukejones flukejones force-pushed the 6.10/chimeraos branch 3 times, most recently from 13e20eb to f8595b4 Compare August 4, 2024 10:53
This driver adds full support of the ASUS ROG Ally gamepad:

- dinput is translated to XBox controller (Ally-X only)
- default mode has the QAM buttons mapped (Ally-X only)
  * left is XBox button
  * right is an XBox + A combo for steam QAM
- force feedback is supported (Ally-X only)
- LED brightness control (0-2)
- LED multicolor class support
- Support all configuration

The configuration options available are:

- Gamepad mode (game, wasd, mouse)
- Remapping each button, plus macro map (hold a macro button and press other)
- Joystrick and trigger deadzones
- Gamepad vibration intensity
- Leds (using multicolor class)
- Button turbo abilities (per button)
- Joystick repsonse curves
- Joystick anti-deadzones

The attribute path tree looks like this:

- `./sys/../<USB HID>/`
  - `joystick_left/
    - `deadzone`
    - `mapping` (mouse, wasd, custom)
    - `anti_deadzone`
    - `response_curve`
    - `calibration`
    - `calibration_reset`
  - `trigger_left/
    - `deadzone`
    - `response_curve`
    - `calibration`
    - `calibration_reset`
  - `gamepad_mode`
  - `button_mapping`
    - `A`
    - `B`
    - `dpad_left`
    - etc

No settings are applied until `apply_all` is written to. The exception is
for calibrations.

While there is calibration ability, it can be difficult to get correct
and is heavily device dependent, as such it is set when written and not
when `apply_all` is written to. On driver load the set calibrations are
retrieved - this may be what you've set in Linux, Windows, or factory
defaults.

Signed-off-by: Luke D. Jones <[email protected]>
@flukejones
Copy link
Author

I don't know what commit these conflicts are coming from. Possibly I dropped a series instead of revert? In either case if main branch drops any that match what I've submitted here it should fix itself up.

@BoukeHaarsma23 BoukeHaarsma23 force-pushed the 6.10/chimeraos branch 2 times, most recently from e41dbad to c4bd15e Compare August 7, 2024 16:49
@Samsagax
Copy link
Member

Samsagax commented Aug 8, 2024

Latest patch added to v6.9.12-chos7. Should be in v46-2 when it comes out.

@Samsagax Samsagax closed this Aug 8, 2024
@flukejones flukejones deleted the 6.10/chimeraos branch August 21, 2024 08:32
flukejones pushed a commit to flukejones/linux that referenced this pull request Aug 31, 2024
A sysfs reader can race with a device reset or removal, attempting to
read device state when the device is not actually present. eg:

     [exception RIP: qed_get_current_link+17]
  ChimeraOS#8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
  ChimeraOS#9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
 ChimeraOS#10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
 ChimeraOS#11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
 ChimeraOS#12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
 ChimeraOS#13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
 ChimeraOS#14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
 ChimeraOS#15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
 ChimeraOS#16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
 ChimeraOS#17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb

 crash> struct net_device.state ffff9a9d21336000
    state = 5,

state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
The device is not present, note lack of __LINK_STATE_PRESENT (0b10).

This is the same sort of panic as observed in commit 4224cfd
("net-sysfs: add check for netdevice being present to speed_show").

There are many other callers of __ethtool_get_link_ksettings() which
don't have a device presence check.

Move this check into ethtool to protect all callers.

Fixes: d519e17 ("net: export device speed and duplex via sysfs")
Fixes: 4224cfd ("net-sysfs: add check for netdevice being present to speed_show")
Signed-off-by: Jamie Bainbridge <[email protected]>
Link: https://patch.msgid.link/8bae218864beaa44ed01628140475b9bf641c5b0.1724393671.git.jamie.bainbridge@gmail.com
Signed-off-by: Jakub Kicinski <[email protected]>
flukejones pushed a commit to flukejones/linux that referenced this pull request Sep 3, 2024
A sysfs reader can race with a device reset or removal, attempting to
read device state when the device is not actually present. eg:

     [exception RIP: qed_get_current_link+17]
  ChimeraOS#8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
  ChimeraOS#9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
 ChimeraOS#10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
 ChimeraOS#11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
 ChimeraOS#12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
 ChimeraOS#13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
 ChimeraOS#14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
 ChimeraOS#15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
 ChimeraOS#16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
 ChimeraOS#17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb

 crash> struct net_device.state ffff9a9d21336000
    state = 5,

state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
The device is not present, note lack of __LINK_STATE_PRESENT (0b10).

This is the same sort of panic as observed in commit 4224cfd
("net-sysfs: add check for netdevice being present to speed_show").

There are many other callers of __ethtool_get_link_ksettings() which
don't have a device presence check.

Move this check into ethtool to protect all callers.

Fixes: d519e17 ("net: export device speed and duplex via sysfs")
Fixes: 4224cfd ("net-sysfs: add check for netdevice being present to speed_show")
Signed-off-by: Jamie Bainbridge <[email protected]>
Link: https://patch.msgid.link/8bae218864beaa44ed01628140475b9bf641c5b0.1724393671.git.jamie.bainbridge@gmail.com
Signed-off-by: Jakub Kicinski <[email protected]>
flukejones pushed a commit to flukejones/linux that referenced this pull request Sep 6, 2024
[ Upstream commit a699781 ]

A sysfs reader can race with a device reset or removal, attempting to
read device state when the device is not actually present. eg:

     [exception RIP: qed_get_current_link+17]
  ChimeraOS#8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
  ChimeraOS#9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
 ChimeraOS#10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
 ChimeraOS#11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
 ChimeraOS#12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
 ChimeraOS#13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
 ChimeraOS#14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
 ChimeraOS#15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
 ChimeraOS#16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
 ChimeraOS#17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb

 crash> struct net_device.state ffff9a9d21336000
    state = 5,

state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
The device is not present, note lack of __LINK_STATE_PRESENT (0b10).

This is the same sort of panic as observed in commit 4224cfd
("net-sysfs: add check for netdevice being present to speed_show").

There are many other callers of __ethtool_get_link_ksettings() which
don't have a device presence check.

Move this check into ethtool to protect all callers.

Fixes: d519e17 ("net: export device speed and duplex via sysfs")
Fixes: 4224cfd ("net-sysfs: add check for netdevice being present to speed_show")
Signed-off-by: Jamie Bainbridge <[email protected]>
Link: https://patch.msgid.link/8bae218864beaa44ed01628140475b9bf641c5b0.1724393671.git.jamie.bainbridge@gmail.com
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.