| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The measurements done by hiperdispatch can have sudden spikes and dips
during run time. To prevent these outliers effecting the decision making
process and causing adjustment overhead, use weighted average of the
steal time.
Acked-by: Vasily Gorbik <gor@linux.ibm.com>
Co-developed-by: Tobias Huschle <huschle@linux.ibm.com>
Signed-off-by: Tobias Huschle <huschle@linux.ibm.com>
Signed-off-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
When LPAR is in vertical polarization, CPUs get different polarization
values, namely vertical high, vertical medium and vertical low. These
values represent the likelyhood of the CPU getting physical runtime.
Vertical high CPUs will always get runtime and others get varying
runtime depending on the load the CEC is under.
Vertical high and vertical medium CPUs are considered the CPUs which the
current LPAR has the entitlement to run on. The vertical lows are on the
other hand are borrowed CPUs which would only be given to the LPAR by
hipervisor when the other LPARs are not utilizing them.
Using the CPU capacities, hint linux scheduler when it should prioritise
vertical high and vertical medium CPUs over vertical low CPUs.
By tracking various system statistics hiperdispatch determines when to
adjust cpu capacities.
After each adjustment, rebuilding of scheduler domains is necessary to
notify the scheduler about capacity changes but since this operation is
costly it should be done as sparsely as possible.
Acked-by: Vasily Gorbik <gor@linux.ibm.com>
Co-developed-by: Tobias Huschle <huschle@linux.ibm.com>
Signed-off-by: Tobias Huschle <huschle@linux.ibm.com>
Signed-off-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Linux scheduler allows architectures to assign capacity values to
individual CPUs. This hints scheduler the performance difference between
CPUs and allows more efficient task distribution them. Implement
helper methods to set and get CPU capacities for s390. This is
particularly helpful in vertical polarization configurations of LPARs.
On vertical polarization an LPARs CPUs can get different polarization
values depending on the CEC configuration. CPUs with different
polarization values can perform different from each other, using CPU
capacities this can be reflected to linux scheduler.
Acked-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
By default, all systems on s390 start in horizontal cpu polarization.
Selecting the new config option SCHED_TOPOLOGY_VERTICAL allows to build
a kernel that switches to vertical polarization during boot.
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Tested-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Tobias Huschle <huschle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Provide an additional path to set the polarization of the system, such
that a user no longer relies on the sysfs interface only and is able
configure the polarization for every reboot via sysctl control files.
The new sysctl can be set as follows:
- s390.polarization=0 for horizontal polarization
- s390.polarization=1 for vertical polarization
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Tested-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Tobias Huschle <huschle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Introduce a new debug file which allows to determine how many warning
track grace periods were missed on each CPU.
The new file can be found as /sys/kernel/debug/s390/wti
It is formatted as:
CPU0 CPU1 [...] CPUx
xyz xyz [...] xyz
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Tobias Huschle <huschle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
A virtual CPU that has received a warning-track interrupt may fail to
acknowledge the interrupt within the warning-track grace period.
While this is usually not a problem, it will become necessary to
investigate if there is a large number of such missed warning-track
interrupts. Therefore, it is necessary to track these events.
The information is tracked through the s390 debug facility and can be
found under /sys/kernel/debug/s390dbf/wti/.
The hex_ascii output is formatted as:
<pid> <symbol>
The values pid and current psw are collected when a warning track
interrupt is received. Symbol is either the kernel symbol matching the
collected psw or redacted to <user> when running in user space.
Each line represents the currently executing process when a warning
track interrupt was received which was then not acknowledged within its
grace period.
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Tobias Huschle <huschle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
When a warning track interrupt is received, the kernel has only a very
limited amount of time to make sure, that the CPU can be yielded as
gracefully as possible before being pre-empted by the hypervisor.
The interrupt handler for the wti therefore unparks a kernel thread
which has being created on boot re-using the CPU hotplug kernel thread
infrastructure. These threads exist per CPU and are assigned the
highest possible real-time priority. This makes sure, that said threads
will execute as soon as possible as the scheduler should pre-empt any
other running user tasks to run the real-time thread.
Furthermore, the interrupt handler disables all I/O interrupts to
prevent additional interrupt processing on the soon-preempted CPU.
Interrupt handlers are likely to take kernel locks, which in the worst
case, will be kept while the interrupt handler is pre-empted from itself
underlying physical CPU. In that case, all tasks or interrupt handlers
on other CPUs would have to wait for the pre-empted CPU being dispatched
again. By preventing further interrupt processing, this risk is
minimized.
Once the CPU gets dispatched again, the real-time kernel thread regains
control, reenables interrupts and parks itself again.
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Tobias Huschle <huschle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
The warning-track interrupt (wti) provides a notification that the
receiving CPU will be pre-empted from its physical CPU within a short
time frame. This time frame is called grace period and depends on the
machine type. Giving up the CPU on time may prevent a task to get stuck
while holding a resource.
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Tobias Huschle <huschle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
The hypfs_dbfs_exit() have been removed since
commit 3325b4d85799 ("s390/hypfs: factor out filesystem code"),
and now it is useless, so remove it.
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
Acked-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
The only context where ftrace_enable_ftrace_graph_caller()
or ftrace_disable_ftrace_graph_caller() is called also calls
ftrace_arch_code_modify_post_process(), which already performs
text_poke_sync_lock().
ftrace_run_update_code()
arch_ftrace_update_code()
ftrace_modify_all_code()
ftrace_enable_ftrace_graph_caller()/ftrace_disable_ftrace_graph_caller()
ftrace_arch_code_modify_post_process()
text_poke_sync_lock()
Remove the redundant serialization.
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Use get/copy_from_kernel_nofault to access the kernel text consistently.
Replace memcmp() in ftrace_init_nop() to ensure that in case of
inconsistencies in the 'mcount' table, the kernel reports a failure
instead of potentially crashing.
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
When a sequential instruction fetching facility is present, it is safe
to patch ftrace NOPs in function prologues. All of them are 8-byte
aligned.
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Avoid stop machine on kprobes arm/disarm when sequential instruction
fetching is present.
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
When sequential instruction fetching facility is present,
certain guarantees are provided for code patching. In particular,
atomic overwrites within 8 aligned bytes is safe from an
instruction-fetching point of view.
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
In the past two save areas existed because interrupt handlers
and system call / program check handlers where entered with
interrupts enabled. To prevent a handler from overwriting the
save areas from the previous handler, interrupts used the async
save area, while system call and program check handler used the
sync save area.
Since the removal of critical section cleanup from entry.S, handlers are
entered with interrupts disabled. When the interrupts are re-enabled,
the save area is no longer need. Therefore merge both save areas into one.
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
On newer machines the SHA3 performance of CPACF instructions KIMD and
KLMD can be enhanced by using additional modifier bits. This allows the
application to omit initializing the ICV, but also affects the internal
processing of the instructions. Performance is mostly gained when
processing short messages.
The new CPACF feature is backwards compatible with older machines, i.e.
the new modifier bits are ignored on older machines. However, to save the
ICV initialization, the application must detect the MSA level and omit
the ICV initialization only if this feature is supported.
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Introduce pkey base kernel code with a simple pkey handler registry.
Regroup the pkey code into these kernel modules:
- pkey is the pkey api supporting the ioctls, sysfs and in-kernel api.
Also the pkey base code which offers the handler registry and
handler wrapping invocation functions is integrated there. This
module is automatically loaded in via CPU feature if the MSA feature
is available.
- pkey-cca is the CCA related handler code kernel module a offering
CCA specific implementation for pkey. This module is loaded in
via MODULE_DEVICE_TABLE when a CEX[4-8] card becomes available.
- pkey-ep11 is the EP11 related handler code kernel module offering an
EP11 specific implementation for pkey. This module is loaded in via
MODULE_DEVICE_TABLE when a CEX[4-8] card becomes available.
- pkey-pckmo is the PCKMO related handler code kernel module. This
module is loaded in via CPU feature if the MSA feature is available,
but on init a check for availability of the pckmo instruction is
performed.
The handler modules register via a pkey_handler struct at the pkey
base code and the pkey customer (that is currently the pkey api code
fetches a handler via pkey handler registry functions and calls the
unified handler functions via the pkey base handler functions.
As a result the pkey-cca, pkey-ep11 and pkey-pckmo modules get
independent from each other and it becomes possible to write new
handlers which offer another kind of implementation without implicit
dependencies to other handler implementations and/or kernel device
drivers.
For each of these 4 kernel modules there is an individual Kconfig
entry: CONFIG_PKEY for the base and api, CONFIG_PKEY_CCA for the PKEY
CCA support handler, CONFIG_PKEY_EP11 for the EP11 support handler and
CONFIG_PKEY_PCKMO for the pckmo support. The both CEX related handler
modules (PKEY CCA and PKEY EP11) have a dependency to the zcrypt api
of the zcrypt device driver.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
This is a huge rework of all the pkey kernel module code.
The goal is to split the code into individual parts with
a dedicated calling interface:
- move all the sysfs related code into pkey_sysfs.c
- all the CCA related code goes to pkey_cca.c
- the EP11 stuff has been moved to pkey_ep11.c
- the PCKMO related code is now in pkey_pckmo.c
The CCA, EP11 and PCKMO code may be seen as "handlers" with
a similar calling interface. The new header file pkey_base.h
declares this calling interface. The remaining code in
pkey_api.c handles the ioctl, the pkey module things and the
"handler" independent code on top of the calling interface
invoking the handlers.
This regrouping of the code will be the base for a real
pkey kernel module split into a pkey base module which acts
as a dispatcher and handler modules providing their service.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Add new shash exploiting the HMAC hardware accelerations for SHA224,
SHA256, SHA384 and SHA512 introduced with message-security assist
extension 11.
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Add new cipher exploiting the full AES-XTS hardware acceleration
introduced with message-security assist extension 10.
The full AES-XTS cipher is registered as preferred cipher in addition
to the discrete AES-XTS variant.
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Remove leftover dentry variable after hypfs refactoring.
Before 2fcb3686e160, hypfs_diag.c and other hypfs files were using
debugfs_create_file() explicitly for creating debugfs files and
were storing the returned pointer.
After the refactor, common debugfs file operations and also the
related dentry pointers have been moved into hypfs_dbfs.c and
redefined as new common mechanisms.
Therefore the dentry variable and the debugfs_remove() function
calls in hypfs_diag.c are now redundant.
Current code is not effected since the dentry pointer in
hypfs_diag is implicitly assigned to NULL and debugfs_remove()
returns without an error if the passed pointer is NULL.
Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Add more instructions to the kernel disassembler.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Since commit ba05b39d54ee ("s390/expoline: Make modules use kernel
expolines"), there is no longer any reason not to use
CONFIG_EXPOLINE_EXTERN when supported by the compiler.
On the positive side:
- there is only a single set of expolines generated and used by both the
kernel code and modules,
- it eliminates expolines "comdat" sections, which can confuse tools
like kpatch.
Always enable EXPOLINE_EXTERN if supported by the compiler.
Suggested-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Over the course of CPU generations a few instructions got extended,
changing their base mnemonic, while keeping the former as an extended
mnemonic. Update the instruction mnemonics in the disassembler to their
latest base mnemonic as documented in the latest IBM z/Architecture
Principles of Operation specification [1].
With the IBM z14 the base mnemonics of the following vector instructions
have been changed:
- Vector FP Load Lengthened (VFLL)
- Vector FP Load Rounded (VFLR)
With Message-Security-Assist Extension 5 Perform Pseudorandom Number
Operation (PPNO) has been renamed to Perform Random Number Operation
(PRNO).
With Vector Enhancements Facility 2 the base mnemonics of the following
vector instructions have been changed:
- Vector FP Convert from Fixed (VCFPS)
- Vector FP Convert from Logical (VCFPL)
- Vector FP Convert to Fixed (VCSFP)
- Vector FP Convert to Logical (VCLFP)
[1] IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
Acked-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Treat register numbers as unsigned. Treat signed operand values as
signed.
This resolves multiple instances of the Cppcheck warning:
warning: %i in format string (no. 1) requires 'int' but the argument
type is 'unsigned int'. [invalidPrintfArgType_sint]
Acked-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
There is no DAC connected to the SPI bus of the Elgin RV1108 R1 board.
There is a JG10309-01 LCD controlled via SPI though.
Properly describe it by adding the "elgin,jg10309-01" compatible
string.
Reported-by: Conor Dooley <conor.dooley@microchip.com>
Closes: https://lore.kernel.org/linux-arm-kernel/20240717-parrot-malt-83cc04bf6b36@spud/
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240829113158.3324928-3-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
LPC32XX connects few of its peripherals to pl08x DMA thru a multiplexer,
this driver allows to route a signal request line thru the multiplexer for
given peripheral.
Signed-off-by: Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
Link: https://lore.kernel.org/r/20240628152022.274405-1-piotr.wojtaszczyk@timesys.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Build the Tegra194 PCIe Endpoint driver as a module by default for
ARM64.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
One of the key differences between p3701-0000 and p3701-0008 is the
temperature range. Add this info for p3701-0008.
Signed-off-by: Dara Stotland <dstotland@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
All SKUs of the p3701 module contain a temp sensor connected to the
BPMP I2C. Move the associated nodes from tegra234-p3701-0008.dtsi
to tegra234-p3701.dtsi. Add missing compatible.
Signed-off-by: Dara Stotland <dstotland@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Some padctl supply nodes currently reside in board file, when they
should reside on module level. The nodes are part of module,
not board. Move these nodes to the correct AGX Orin
module file.
Signed-off-by: Dara Stotland <dstotland@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Some of the nodes inside the AGX Orin module file are in the
wrong location. In particular, the SD card interface and
two of the PCIe regulators in the module file should instead
reside in the board file. These components are not part of the
module. They are part of the carrier board. Move these
nodes to the correct location.
Fixes: cd42b26a527f ("arm64: tegra: Add regulators required for PCIe")
Fixes: d71b893a119d ("arm64: tegra: Add Tegra234 SDMMC1 device tree node")
Signed-off-by: Dara Stotland <dstotland@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Current IGX Orin structure has both a top-level module+board
file as well as a board file. Most of the data in the board-file
is closely related to the module itself. The benefit of this
extra file is outweighed by the additional complexity. Merge
the board file into the module+board file for simplicity.
Signed-off-by: Dara Stotland <dstotland@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The current AGX Orin structure has both a top-level module+board
file as well as a board file. Most of the data in the board-file
is closely related to the module itself. The benefit of this
extra file is outweighed by the additional complexity. Merge
the board file into the module+board file for simplicity.
Signed-off-by: Dara Stotland <dstotland@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The AGX Orin module boards contain common nodes that can
be moved to the included module dtsi. This eliminates
redundancy within the files and reduces lines of code.
Data from tegra234-p3701-0000 and tegra234-p3701-0008 that
is common is now in tegra234-p3701.dtsi.
Signed-off-by: Dara Stotland <dstotland@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Pins responsible for controlling these LEDs need to have tristate
control removed if we want them as GPIOs. This change aligns with
pinmux configuration of "dte" pin group in downstream kernel[1].
These LEDs had no function assigned on vendor kernel and there is no
label on the case, the only markings are on PCB which are part of node
names (ds1 marking is on power LED controlled by PMIC), so generic term
is assigned as the function.
1. https://github.com/compulab/trimslice-android-kernel/blob/upstream/arch/arm/mach-tegra/board-trimslice-pinmux.c#L45
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
P2180 modules have WiFi in form of BCM4354 chip, and kernel driver
supports this one, so enable it for all users. The necessary calibration
file can be obtained from Jetson Linux Archive. nvram.txt file is
located in "Driver Package (BSP)" in
nv_tegra/l4t_deb_packages/nvidia-l4t-firmware_<version>_arm64.deb
archive. The rest of necessary blobs can be obtained from official
Linux Firmware repository or (newer ones) from Infineon
ifx-linux-firmware repository (look in older releases).
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
P2180 modules have Bluetooth in form of BCM4354 chip, and kernel driver
supports this one, so enable it for all users. The necessary firmware
can be obtained from Jetson Linux Archive. bcm4354.hcd file is located
in "Driver Package (BSP)" in
nv_tegra/l4t_deb_packages/nvidia-l4t-firmware_<version>_arm64.deb
archive.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
One INA3221 sensor is located on P2180 module and the other two are on
P2597 base board.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Add implementation details for Orin NX/Nano PCIe EP on C4.
Signed-off-by: Vedant Deshpande <vedantd@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Add PCIe C4 EP controller definition in device tree for Tegra234
devices.
Signed-off-by: Vedant Deshpande <vedantd@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Add the definition for the wp-gpio of the P2597's external card slot,
enabling this functionality.
Tested on a P2597 board.
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The current declaration is off-by-one and actually corresponds to the
wp-gpio of the external slot.
Tested on a P2597 board.
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Fixes issue when resuming after suspend made USB in peripheral
mode inaccessible.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Downstream kernel states that backlight has no actual enable GPIO
and uses fixed regulator.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Group GPIO keys into keys and switches.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Add MMC nodes configuration along with WIFI binding to ASUS TF701T
device-tree.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
With these changes sound works, only UCM configs are needed for
complete support.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Complete and adjust magnetometer, thermal sensor, motion tracker,
power and light sensors according to available sources.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
