Konrad Dybcio [Tue, 27 Jun 2023 16:24:18 +0000 (18:24 +0200)]
arm64: dts: qcom: msm8939: Drop "qcom,idle-state-spc" compatible
As of today, the only cool and legal way to get ARM64 SMP going is
via PSCI (or spin tables). Sadly, not all chip and device vendors were
considerate of this in the early days of arm64. Qualcomm, for example
reused their tried-and-true spin-up method from MSM8974 and their Krait/
arm32 Cortex designs.
MSM8916 supports SMP with its arm32 dt overlay, as probably could 8939.
But the arm64 DT should not define non-PSCI SMP or CPUidle stuff.
Drop the qcom,idle-state-spc compatible (associated with Qualcomm-specific
CPUIdle) to make the dt checker happy:
apq8039-t2.dtb: idle-states: cpu-sleep-0:compatible:
['qcom,idle-state-spc', 'arm,idle-state'] is too long
Konrad Dybcio [Tue, 27 Jun 2023 14:07:37 +0000 (16:07 +0200)]
arm64: dts: qcom: sm6375: Set up L3 scaling
Add the CPU OPP tables including core frequency and L3 bus frequency.
The L3 throughput values were chosen by studying the frequencies
available in HW LUT and picking the highest one that's less than the
CPU frequency. They will be replaced with a dynamic, bwmon-style
decision maker once support for MEMLAT is introduced upstream.
Available values from the HW LUT:
300000
556800
652800
768000
844800
921600 1171200 1382400 1497600
This commit dramatically improves overall performance of the system.
Unless explicitly specified the interrupt-parent property is inherited
from the parent node on Linux even though this may not be in full
compliance with the devicetree specification.
Following commit 2d5cab9232ba ("arm64: dts: qcom: sc8280xp-pmics:
Specify interrupt parent explicitly"), add an explicit interrupt parent
also for the PMIC RTC node for the benefit of other operating systems
which may be confused by this omission.
Note that any such OS must still implement a fallback to the root
interrupt domain as most devicetrees are written under the assumption
that the interrupt parent is inherited.
Reported-by: Patrick Wildt <patrick@blueri.se> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230627085306.6033-1-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Konrad Dybcio [Wed, 21 Jun 2023 11:21:53 +0000 (13:21 +0200)]
arm64: dts: qcom: sm6115p-j606f: Hook up display
Enable the required nodes, add the required pins and tweak a
regulator to enable non-simplefb display on the Tab P11.
Do note that there exists a second SKU with a different panel+touch
combo, but due to insufficient information, that will need to be
handled separately.
Xperia 1 II / PRO use the Dialog SLG51000 PMIC for powering some camera
sensors. Add the required nodes to support it and remove its remnants
from -edo.dtsi, as it's absent on 5 II.
Konrad Dybcio [Tue, 20 Jun 2023 11:05:35 +0000 (13:05 +0200)]
arm64: dts: qcom: sm8250-edo: Add GPIO line names for PMIC GPIOs
Sony ever so graciously provides GPIO line names in their downstream
kernel (though sometimes they are not 100% accurate and you can judge
that by simply looking at them and with what drivers they are used).
Add these to the PDX203&206 DTSIs to better document the hardware.
Diff between 203 and 206:
pm8009_gpios
< "CAM_PWR_LD_EN",
> "NC",
pm8150_gpios
< "NC",
> "G_ASSIST_N",
< "WLC_EN_N", /* GPIO_10 */
> "NC", /* GPIO_10 */
Which is due to 5 II having an additional Google Assistant hardware
button and 1 II having a wireless charger & different camera wiring
to accommodate the additional 3D iToF sensor.
Konrad Dybcio [Tue, 20 Jun 2023 11:05:34 +0000 (13:05 +0200)]
arm64: dts: qcom: sm8250-edo: Add gpio line names for TLMM
Sony ever so graciously provides GPIO line names in their downstream
kernel (though sometimes they are not 100% accurate and you can judge
that by simply looking at them and with what drivers they are used).
Add these to the PDX203&206 DTSIs to better document the hardware.
Jakob Hauser [Mon, 19 Jun 2023 20:37:43 +0000 (22:37 +0200)]
arm64: dts: qcom: msm8916-samsung-serranove: Add RT5033 PMIC with charger
For the regulators, apply the same settings as in the downstream
devicetree [1], including the "regulator-always-on" for the SAFE_LDO.
For the voltage of SAFE_LDO, however, there is only one voltage of 4.9 V
available in the mainline driver [2][3].
The values of the battery data evolve from following sources:
- precharge current: 450 mA corresponds to the default value of the chip. It
doesn't get changed by the downstream Android driver. Therefore let's stick
to this value.
- constant charge current: The 1000 mA are taken from the downstream devicetree
of the serranove battery. It's not easy to spot. The value is in the line
"input_current_limit" [4]. The rows are according to the power supply type,
the 4th value stands for "main supply" [5]. That's the value used by the
Android driver when a charging cable is plugged into the device.
- charge termination current: In the downstream devicetree of the battery
that's the line "full_check_current_1st", which contains the 150 mA [6].
- precharge voltage: This one doesn't get set in the downstream Android driver.
The chip's default is 2.8 V. That seemed too low to have a notable effect of
handling the battery gentle. The chosen value of 3.5 V is a bit arbitrary
and possibly rather high. As the device is already several years old and
therefore most batteries too, a value on the safe side seems reasonable.
- constant charge voltage: The value of 4.35 V is set in the line
"chg_float_voltage" of the downstream battery devicetree [7].
The "connector" sub-node in the extcon node, the "battery" node in the
general section and the line "power-supplies" in the fuel-gauge node result
from the way of implementation documented in the dt-bindings of
rt5033-charger [8] and mfd rt5033 [9].
arm64: dts: qcom: sc8180x-flex-5g: align gpio-keys node name with bindings
Bindings except certain pattern for gpio-keys children:
sc8180x-lenovo-flex-5g.dtb: gpio-keys: 'lid' does not match any of the regexes: '^(button|event|key|switch|(button|event|key|switch)-[a-z0-9-]+|[a-z0-9-]+-(button|event|key|switch))$', 'pinctrl-[0-9]+'
arm64: dts: qcom: sc8180x: align thermal node name with bindings
Bindings expect thermal node names to end with 'thermal':
sc8180x-lenovo-flex-5g.dtb: thermal-zones: 'gpu-thermal-bottom', 'gpu-thermal-top' do not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$', 'pinctrl-[0-9]+'
arm64: dts: qcom: sc8180x: use generic ADC channel node names
ADC channel node names were changed to require generic 'channel'. The
user-visible part is defined via label.
sc8180x-lenovo-flex-5g.dtb: adc@3100: 'die-temp@6', 'ref-gnd@0', 'vref-1p25@1' do not match any of the regexes: '^channel@[0-9a-f]+$', 'pinctrl-[0-9]+'
arm64: dts: qcom: apq8016-sbc: drop label from I2C and SPI
I2C and SPI controller bindings do not allow label property:
apq8016-sbc.dtb: spi@78b7000: Unevaluated properties are not allowed ('label' was unexpected)
apq8016-sbc.dtb: i2c@78b6000: Unevaluated properties are not allowed ('label' was unexpected)
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
commit c4a48b0df8bf ("dt-bindings: pinctrl: qcom: tlmm should use
output-disable, not input-enable") the property is not accepted anymore.
Pin configuration property "input-enable" was used with the intention to
disable the output, but this is done by default by Linux drivers. Since
commit c4a48b0df8bf ("dt-bindings: pinctrl: qcom: tlmm should use
output-disable, not input-enable") the property is not accepted anymore.
Vincent Guittot [Thu, 15 Jun 2023 15:48:52 +0000 (17:48 +0200)]
arm64: dts: qcom: sm8250: correct dynamic power coefficients
sm8250 faces the same problem with its Energy Model as sdm845. The energy
cost of LITTLE cores is reported to be higher than medium or big cores
EM computes the energy with formula:
energy = OPP's cost / maximum cpu capacity * utilization
On v6.4-rc6 we have:
max capacity of CPU0 = 284
capacity of CPU0's OPP(1612800 Hz) = 253
cost of CPU0's OPP(1612800 Hz) = 191704
max capacity of CPU4 = 871
capacity of CPU4's OPP(710400 Hz) = 255
cost of CPU4's OPP(710400 Hz) = 343217
Both OPPs have almost the same compute capacity but the estimated energy
per unit of utilization will be estimated to:
energy CPU0 = 191704 / 284 * 1 = 675
energy CPU4 = 343217 / 871 * 1 = 394
EM estimates that little CPU0 will consume 71% more than medium CPU4 for
the same compute capacity. According to [1], little consumes 25% less than
medium core for Coremark benchmark at those OPPs for the same duration.
Set the dynamic-power-coefficient of CPU0-3 to 105 to fix the energy model
for little CPUs.
Dmitry Baryshkov [Thu, 15 Jun 2023 08:34:21 +0000 (11:34 +0300)]
Revert "arm64: dts: qcom: msm8996: rename labels for HDMI nodes"
The commit f43b6dc7d56e ("arm64: dts: qcom: msm8996: rename labels for
HDMI nodes") is broken, it changes all the HDMI node names,
compatible strings instead of changing just node aliases. Revert the
commit in order to land a proper clean version.
Reported-by: Konrad Dybcio <konrad.dybcio@linaro.org> Fixes: f43b6dc7d56e ("arm64: dts: qcom: msm8996: rename labels for HDMI nodes") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230615083422.350297-2-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Bjorn Andersson [Wed, 31 May 2023 02:49:44 +0000 (19:49 -0700)]
arm64: dts: qcom: Drop undocumented "svid" property
The Linux typec_mux implementation required that a property named "svid"
was present in the remote node of the of_graph for a match to be found.
With the introduction of commit '4aebc4f89f00 ("usb: typec: mux: Clean up
mux_fwnode_match()")', the implementation is aligned with the binding
and this property can be dropped - and the associated DeviceTree
validation warning resolved.
We just sorted the entries and fields last release, so just out of a
perverse sense of curiosity, I decided to see if we can keep things
ordered for even just one release.
The answer is "No. No we cannot".
I suggest that all kernel developers will need weekly training sessions,
involving a lot of Big Bird and Sesame Street. And at the yearly
maintainer summit, we will all sing the alphabet song together.
I doubt I will keep doing this. At some point "perverse sense of
curiosity" turns into just a cold dark place filled with sadness and
despair.
Repeats: 80e62bc8487b ("MAINTAINERS: re-sort all entries and fields") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge tag 'dma-mapping-6.5-2023-07-09' of git://git.infradead.org/users/hch/dma-mapping
Pull dma-mapping fixes from Christoph Hellwig:
- swiotlb area sizing fixes (Petr Tesarik)
* tag 'dma-mapping-6.5-2023-07-09' of git://git.infradead.org/users/hch/dma-mapping:
swiotlb: reduce the number of areas to match actual memory pool size
swiotlb: always set the number of areas before allocating the pool
Merge tag 'x86-core-2023-07-09' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fix from Thomas Gleixner:
"A single fix for the mechanism to park CPUs with an INIT IPI.
On shutdown or kexec, the kernel tries to park the non-boot CPUs with
an INIT IPI. But the same code path is also used by the crash utility.
If the CPU which panics is not the boot CPU then it sends an INIT IPI
to the boot CPU which resets the machine.
Prevent this by validating that the CPU which runs the stop mechanism
is the boot CPU. If not, leave the other CPUs in HLT"
* tag 'x86-core-2023-07-09' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/smp: Don't send INIT to boot CPU
Merge tag 'mips_6.5_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
Pull MIPS fixes from Thomas Bogendoerfer:
- fixes for KVM
- fix for loongson build and cpu probing
- DT fixes
* tag 'mips_6.5_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
MIPS: kvm: Fix build error with KVM_MIPS_DEBUG_COP0_COUNTERS enabled
MIPS: dts: add missing space before {
MIPS: Loongson: Fix build error when make modules_install
MIPS: KVM: Fix NULL pointer dereference
MIPS: Loongson: Fix cpu_probe_loongson() again
Merge tag '6.5-rc-smb3-client-fixes-part2' of git://git.samba.org/sfrench/cifs-2.6
Pull more smb client updates from Steve French:
- fix potential use after free in unmount
- minor cleanup
- add worker to cleanup stale directory leases
* tag '6.5-rc-smb3-client-fixes-part2' of git://git.samba.org/sfrench/cifs-2.6:
cifs: Add a laundromat thread for cached directories
smb: client: remove redundant pointer 'server'
cifs: fix session state transition to avoid use-after-free issue
Merge tag 'mm-hotfixes-stable-2023-07-08-10-43' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Pull hotfixes from Andrew Morton:
"16 hotfixes. Six are cc:stable and the remainder address post-6.4
issues"
The merge undoes the disabling of the CONFIG_PER_VMA_LOCK feature, since
it was all hopefully fixed in mainline.
* tag 'mm-hotfixes-stable-2023-07-08-10-43' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
lib: dhry: fix sleeping allocations inside non-preemptable section
kasan, slub: fix HW_TAGS zeroing with slub_debug
kasan: fix type cast in memory_is_poisoned_n
mailmap: add entries for Heiko Stuebner
mailmap: update manpage link
bootmem: remove the vmemmap pages from kmemleak in free_bootmem_page
MAINTAINERS: add linux-next info
mailmap: add Markus Schneider-Pargmann
writeback: account the number of pages written back
mm: call arch_swap_restore() from do_swap_page()
squashfs: fix cache race with migration
mm/hugetlb.c: fix a bug within a BUG(): inconsistent pte comparison
docs: update ocfs2-devel mailing list address
MAINTAINERS: update ocfs2-devel mailing list address
mm: disable CONFIG_PER_VMA_LOCK until its fixed
fork: lock VMAs of the parent process when forking
fork: lock VMAs of the parent process when forking
When forking a child process, the parent write-protects anonymous pages
and COW-shares them with the child being forked using copy_present_pte().
We must not take any concurrent page faults on the source vma's as they
are being processed, as we expect both the vma and the pte's behind it
to be stable. For example, the anon_vma_fork() expects the parents
vma->anon_vma to not change during the vma copy.
A concurrent page fault on a page newly marked read-only by the page
copy might trigger wp_page_copy() and a anon_vma_prepare(vma) on the
source vma, defeating the anon_vma_clone() that wasn't done because the
parent vma originally didn't have an anon_vma, but we now might end up
copying a pte entry for a page that has one.
Before the per-vma lock based changes, the mmap_lock guaranteed
exclusion with concurrent page faults. But now we need to do a
vma_start_write() to make sure no concurrent faults happen on this vma
while it is being processed.
This fix can potentially regress some fork-heavy workloads. Kernel
build time did not show noticeable regression on a 56-core machine while
a stress test mapping 10000 VMAs and forking 5000 times in a tight loop
shows ~5% regression. If such fork time regression is unacceptable,
disabling CONFIG_PER_VMA_LOCK should restore its performance. Further
optimizations are possible if this regression proves to be problematic.
mm: lock newly mapped VMA which can be modified after it becomes visible
mmap_region adds a newly created VMA into VMA tree and might modify it
afterwards before dropping the mmap_lock. This poses a problem for page
faults handled under per-VMA locks because they don't take the mmap_lock
and can stumble on this VMA while it's still being modified. Currently
this does not pose a problem since post-addition modifications are done
only for file-backed VMAs, which are not handled under per-VMA lock.
However, once support for handling file-backed page faults with per-VMA
locks is added, this will become a race.
Fix this by write-locking the VMA before inserting it into the VMA tree.
Other places where a new VMA is added into VMA tree do not modify it
after the insertion, so do not need the same locking.
With recent changes necessitating mmap_lock to be held for write while
expanding a stack, per-VMA locks should follow the same rules and be
write-locked to prevent page faults into the VMA being expanded. Add
the necessary locking.
Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull more SCSI updates from James Bottomley:
"A few late arriving patches that missed the initial pull request. It's
mostly bug fixes (the dt-bindings is a fix for the initial pull)"
* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: ufs: core: Remove unused function declaration
scsi: target: docs: Remove tcm_mod_builder.py
scsi: target: iblock: Quiet bool conversion warning with pr_preempt use
scsi: dt-bindings: ufs: qcom: Fix ICE phandle
scsi: core: Simplify scsi_cdl_check_cmd()
scsi: isci: Fix comment typo
scsi: smartpqi: Replace one-element arrays with flexible-array members
scsi: target: tcmu: Replace strlcpy() with strscpy()
scsi: ncr53c8xx: Replace strlcpy() with strscpy()
scsi: lpfc: Fix lpfc_name struct packing
projects / thirdparty / kernel / linux.git / log
