Add support for the GameForce Chi, which is a handheld gaming console
from GameForce with a Rockchip RK3326 SoC. The device has a 640x480
3.5" dual-lane DSI display, one analog joystick connected to the SoC
SARADC controller and a second analog joystick connected to an unknown
UART based ADC, a single SD card slot, a single USB-C port for
charging, and onboard RTL8723BS WiFi/Bluetooth combo, multiple face
buttons, and an array of R/G/B LEDs used for key backlighting.
The vendor was unable to provide details on the unknown UART based
ADC which I have documented via a comment in the device-tree, and
the vendor also does not have available Bluetooth firmware (the BT
was not previously working on the vendor's OS, this has also been
noted in a device-tree comment).
Aside from the right analog ADC joystick and bluetooth all hardware has
been tested and is working as expected.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://lore.kernel.org/r/20240325134959.11807-6-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Commit 8b5c2b45b8 disabled the internal pull-down for the strobe line
causing I/O errors in HS400 mode for various eMMC modules.
Enable the internal strobe pull-down for the ROCK 4C+ board. Also re-enable
HS400 mode, that was replaced with HS200 mode as a workaround for the
stability issues in:
2bd1d2dd80 ("arm64: dts: rockchip: Disable HS400 for eMMC on ROCK 4C+").
Fixes: 8b5c2b45b8 ("phy: rockchip: set pulldown for strobe line in dts")
Signed-off-by: Folker Schwesinger <dev@folker-schwesinger.de>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20240327192641.14220-3-dev@folker-schwesinger.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Commit 8b5c2b45b8 disabled the internal pull-down for the strobe line
causing I/O errors in HS400 mode for various eMMC modules.
Enable the internal strobe pull-down for ROCK Pi 4 boards. Also re-enable
HS400 mode, that was replaced with HS200 mode as a workaround for the
stability issues in:
cee572756a ("arm64: dts: rockchip: Disable HS400 for eMMC on ROCK Pi 4").
This was tested on ROCK 4SE and ROCK Pi 4B+.
Fixes: 8b5c2b45b8 ("phy: rockchip: set pulldown for strobe line in dts")
Signed-off-by: Folker Schwesinger <dev@folker-schwesinger.de>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20240327192641.14220-2-dev@folker-schwesinger.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Enable the Mali GPU in the RK3588 EVB1.
This marks the GPU regulators as always-on, because the generic
coupler regulator logic from the kernel can only handle them
when they are marked as always-on. Technically it's okay to
disable the regulators, when the GPU is not used.
Considering the RK3588 EVB1 is not battery powered, the slightly
increased power consumption for keeping the regulator always
enabled is not a big deal. Thus it's better to enable GPU support
than wait for a better solution.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20240326165232.73585-5-sebastian.reichel@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add missing cache information to the Rockchip RK356x SoC dtsi, to allow
the userspace, which includes lscpu(1) that uses the virtual files provided
by the kernel under the /sys/devices/system/cpu directory, to display the
proper RK3566 and RK3568 cache information.
Adding the cache information to the RK356x SoC dtsi also makes the following
warning message in the kernel log go away:
cacheinfo: Unable to detect cache hierarchy for CPU 0
The cache parameters for the RK356x dtsi were obtained and partially derived
by hand from the cache size and layout specifications found in the following
datasheets and technical reference manuals:
- Rockchip RK3566 datasheet, version 1.1
- Rockchip RK3568 datasheet, version 1.3
- ARM Cortex-A55 revision r1p0 TRM, version 0100-00
- ARM DynamIQ Shared Unit revision r4p0 TRM, version 0400-02
For future reference, here's a rather detailed summary of the documentation,
which applies to both Rockchip RK3566 and RK3568 SoCs:
- All caches employ the 64-byte cache line length
- Each Cortex-A55 core has 32 KB of L1 4-way, set-associative instruction
cache and 32 KB of L1 4-way, set-associative data cache
- There are no L2 caches, which are per-core and private in Cortex-A55,
because it belongs to the ARM DynamIQ IP core lineup
- The entire SoC has 512 KB of unified L3 16-way, set-associative cache,
which is shared among all four Cortex-A55 CPU cores
- Cortex-A55 cores can be configured without private per-core L2 caches,
in which case the shared L3 cache appears to them as an L2 cache; this
is the case for the RK356x SoCs, so let's use "cache-level = <2>" to
prevent the "huh, no L2 caches, but an L3 cache?" confusion among the
users viewing the data presented to the userspace; another option could
be to have additional 0 KB L2 caches defined, which may be technically
correct, but would probably be even more confusing
Helped-by: Anand Moon <linux.amoon@gmail.com>
Tested-By: Diederik de Haas <didi.debian@cknow.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/2dee6dad8460b0c5f3b5da53cf55f735840efef1.1709957777.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add missing cache information to the Rockchip RK3328 SoC dtsi, to allow
the userspace, which includes lscpu(1) that uses the virtual files provided
by the kernel under the /sys/devices/system/cpu directory, to display the
proper RK3328 cache information.
While there, use a more self-descriptive label for the L2 cache node, which
also makes it more consistent with other SoC dtsi files.
The cache parameters for the RK3328 dtsi were obtained and partially derived
by hand from the cache size and layout specifications found in the following
datasheets, official vendor websites, and technical reference manuals:
- Rockchip RK3328 datasheet, version 1.4
- https://opensource.rock-chips.com/wiki_RK3328, accessed on 2024-02-28
- ARM Cortex-A53 revision r0p3 TRM, version E
For future reference, here's a brief summary of the documentation:
- All caches employ the 64-byte cache line length
- Each Cortex-A53 core has 32 KB of L1 2-way, set-associative instruction
cache and 32 KB of L1 4-way, set-associative data cache
- The entire SoC has 256 KB of unified L2 16-way, set-associative cache
The RK3328 SoC dtsi is also used for the single RK3318-based supported board.
Unfortunately, no datasheet is available for the RK3318, but some unofficial
sources state that its L2 cache size is the same as RK3328's, so it's perhaps
safe to assume the same for the L1 instruction and data cache sizes.
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/a681b3c6dbf7b25b1527b11cea5ae0d6d1733714.1709958234.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Pull EFI fixes from Ard Biesheuvel:
- Fix logic that is supposed to prevent placement of the kernel image
below LOAD_PHYSICAL_ADDR
- Use the firmware stack in the EFI stub when running in mixed mode
- Clear BSS only once when using mixed mode
- Check efi.get_variable() function pointer for NULL before trying to
call it
* tag 'efi-fixes-for-v6.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
efi: fix panic in kdump kernel
x86/efistub: Don't clear BSS twice in mixed mode
x86/efistub: Call mixed mode boot services on the firmware's stack
efi/libstub: fix efi_random_alloc() to allocate memory at alloc_min or higher address
Pull x86 fixes from Thomas Gleixner:
- Ensure that the encryption mask at boot is properly propagated on
5-level page tables, otherwise the PGD entry is incorrectly set to
non-encrypted, which causes system crashes during boot.
- Undo the deferred 5-level page table setup as it cannot work with
memory encryption enabled.
- Prevent inconsistent XFD state on CPU hotplug, where the MSR is reset
to the default value but the cached variable is not, so subsequent
comparisons might yield the wrong result and as a consequence the
result prevents updating the MSR.
- Register the local APIC address only once in the MPPARSE enumeration
to prevent triggering the related WARN_ONs() in the APIC and topology
code.
- Handle the case where no APIC is found gracefully by registering a
fake APIC in the topology code. That makes all related topology
functions work correctly and does not affect the actual APIC driver
code at all.
- Don't evaluate logical IDs during early boot as the local APIC IDs
are not yet enumerated and the invoked function returns an error
code. Nothing requires the logical IDs before the final CPUID
enumeration takes place, which happens after the enumeration.
- Cure the fallout of the per CPU rework on UP which misplaced the
copying of boot_cpu_data to per CPU data so that the final update to
boot_cpu_data got lost which caused inconsistent state and boot
crashes.
- Use copy_from_kernel_nofault() in the kprobes setup as there is no
guarantee that the address can be safely accessed.
- Reorder struct members in struct saved_context to work around another
kmemleak false positive
- Remove the buggy code which tries to update the E820 kexec table for
setup_data as that is never passed to the kexec kernel.
- Update the resource control documentation to use the proper units.
- Fix a Kconfig warning observed with tinyconfig
* tag 'x86-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/boot/64: Move 5-level paging global variable assignments back
x86/boot/64: Apply encryption mask to 5-level pagetable update
x86/cpu: Add model number for another Intel Arrow Lake mobile processor
x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD
Documentation/x86: Document that resctrl bandwidth control units are MiB
x86/mpparse: Register APIC address only once
x86/topology: Handle the !APIC case gracefully
x86/topology: Don't evaluate logical IDs during early boot
x86/cpu: Ensure that CPU info updates are propagated on UP
kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address
x86/pm: Work around false positive kmemleak report in msr_build_context()
x86/kexec: Do not update E820 kexec table for setup_data
x86/config: Fix warning for 'make ARCH=x86_64 tinyconfig'
Pull scheduler doc clarification from Thomas Gleixner:
"A single update for the documentation of the base_slice_ns tunable to
clarify that any value which is less than the tick slice has no effect
because the scheduler tick is not guaranteed to happen within the set
time slice"
* tag 'sched-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/doc: Update documentation for base_slice_ns and CONFIG_HZ relation
