- 27 Jun, 2022 9 commits
-
-
Konrad Dybcio authored
While not strictly necessary, at least on maple, configure the USB extcon, which requires two pins on Yoshino. Signed-off-by:
Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220430162353.607709-5-konrad.dybcio@somainline.org
-
Konrad Dybcio authored
It's disabled on downstream, follow it. Signed-off-by:
-
Konrad Dybcio authored
Reorder properties to match new laptop DTs, change hex to dec. Signed-off-by:
-
Konrad Dybcio authored
Keep the nodes and includes in order, clean up unnecessary properties & nodes. Signed-off-by:
-
Konrad Dybcio authored
Remove the unnecessary level of indentation, commonize SDC2 pins and notice that SDCC2_CD_ON and _OFF is identical, deduplicate it! Also, remove some unnecessary overrides and use decimal values in #-cells Signed-off-by:
-
Bryan O'Donoghue authored
Add in the missing vdda-pll-supply rail description. Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by:
-
Bryan O'Donoghue authored
The dts entry vdda-supply connects to a common vdda-phy-supply rail. Rename to reflect what the functionality is. Reviewed-by:
-
David Heidelberg authored
There's no reason the timer needs > 32-bits of address or size. Since we using 32-bit size, we need to define ranges properly. Fixes warnings as: ``` arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dt.yaml: timer@17c90000: #size-cells:0:0: 1 was expected From schema: Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml ``` Signed-off-by:David Heidelberg <david@ixit.cz> Signed-off-by:
-
Krzysztof Kozlowski authored
DT schema expects names of operating points tables to start with "opp-table": ipq6018-cp01-c1.dtb: cpu_opp_table: $nodename:0: 'cpu_opp_table' does not match '^opp-table(-[a-z0-9]+)?$' Use hyphens instead of underscores, fix the names to match DT schema or remove the prefix entirely when it is not needed. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
- 26 Jun, 2022 17 commits
-
-
Vladimir Zapolskiy authored
At the moment there are no changes in SM8250 board files, which require camera clock controller to run, whenever it is needed for a particular board, the status of camcc device node will be changed in a board file. Signed-off-by:
Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by:
-
Dmitry Baryshkov authored
As we are converting this platform to use DT clock bindings, add clocks and clock-names properties to the MMCC device tree node. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Dmitry Baryshkov authored
Add device tree node for uart20, which is typically used for Bluetooth attachment. Signed-off-by:
-
Srinivasa Rao Mandadapu authored
Add pm7325 ldo_l17b regulator, which is required for wcd codec vdd buck supply on sc7280-qcard board. Signed-off-by:
Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> Co-developed-by:
Venkata Prasad Potturu <quic_potturu@quicinc.com> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
-
Douglas Anderson authored
sc7280-herobrine based boards are specced to be able to access their SPI flash at 50 MHz with the drive strength of the pins set at 8. The drive strength is already set to 8 in "sc7280-herobrine.dtsi", so let's bump up the clock. The matching firmware change for this is at: https://review.coreboot.org/c/coreboot/+/63948 NOTE: the firmware change isn't _required_ to make the kernel work at 50 MHz, it merely shows that the boards are known to work fine at 50 MHz. ALSO NOTE: this doesn't update the "sc7280-chrome-common.dtsi" file which is used by both herobrine boards and IDP. At the moment the IDP boards aren't configuring a drive strength of 8 and it seems safer to just leave them at the slower speed if they're already working. Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
-
Matthias Kaehlcke authored
Specify the path of the modem FW for SC7280 Chrome OS boards in the 'remoteproc_mpss' node. Signed-off-by:
-
Douglas Anderson authored
This enables DisplayPort for herobrine boards. Signed-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by:
-
Stephen Boyd authored
We don't use this carveout on trogdor boards, and having it defined in the sc7180 SoC file causes an overlap message to be printed at boot. OF: reserved mem: OVERLAP DETECTED! memory@86000000 (0x0000000086000000--0x000000008ec00000) overlaps with memory@8b700000 (0x000000008b700000--0x000000008b710000) Delete the node in the trogdor dtsi file to fix the overlap problem and remove the error message. Cc: Alex Elder <elder@linaro.org> Cc: Matthias Kaehlcke <mka@chromium.org> Fixes: 310b2666 ("arm64: dts: qcom: sc7180: define ipa_fw_mem node") Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Matthias Kaehlcke authored
Enable the 'wifi' and 'remoteproc_wpss' nodes for all sc7280 based Chrome OS boards. Delete the corresponding entries from sc7280-idp.dtsi since this file includes sc7280-chrome-common.dtsi. Signed-off-by:
-
Douglas Anderson authored
This adds board bindings for boards that are downstream but not quite upstream yet. Signed-off-by:
-
Douglas Anderson authored
This copy-pastes compatibles from sc7280-based boards from the device trees to the yaml file. It also fixes the CRD/IDP bindings which had gotten stale. Signed-off-by:
-
Douglas Anderson authored
This copy-pastes compatibles from sc7180-based boards from the device trees to the yaml file so that `make dtbs_check` will be happy. NOTES: - I make no attempt to try to share an "item" for all sc7180 based Chromebooks. Because of the revision matching scheme used by the Chromebook bootloader, at times we need a different number of revisions listed. - Some of the odd entries in here (like google,homestar-rev23 or the fact that "Google Lazor Limozeen without Touchscreen" changed from sku5 to sku6) are not typos but simply reflect reality. - Many revisions of boards here never actually went to consumers, but they are still in use within various companies that were involved in Chromebook development. Since Chromebooks are developed with an "upstream first" methodology, having these revisions supported with upstream Linux is important. Making it easy for Chromebooks to be developed with an "upstream first" methodology is valuable to the upstream community because it improves the quality of upstream and gets Chromebooks supported with vanilla upstream faster. One other note here is that, though the bootloader effectively treats the list of compatibles in a given device tree as unordered, some people would prefer future boards to list higher-numbered revisions first in the list. Chromebooks here are not changing and typically list lower revisions first just to avoid churn. Signed-off-by:
-
Douglas Anderson authored
The qcom.yaml bindings file has a whole description of what the top-level compatible should look like for Qualcomm devices. It doesn't match what Chromebooks do, so add a link to the Chromebook docs. Reported-by:
-
Douglas Anderson authored
This documents how many Chromebooks pick the device tree that will be passed to the OS and can help understand the revisions / SKUs listed as the top-level "compatible" in many Chromebooks. Signed-off-by:
-
Matthias Kaehlcke authored
Villager has a backlit keyboard, enable support for the backlight. Signed-off-by:
-
Matthias Kaehlcke authored
On herobrine boards the keyboard backlight is controlled through the PWM LED driver. Currently both the PWM LED node and the node for the keyboard backlight are disabled in sc7280-herobrine.dtsi, which requires boards with a backlit keyboard to enable both nodes. There are no other PWM LEDs on herobrine boards besides the keyboard backlight, delete the 'disabled' status from the keyboard backlight node, with that boards only have to enable the 'pwmleds' node for keyboard backlight support. Also add a label to the 'pwmleds' node to allow board files to refer to it with a phandle. Signed-off-by:
-
Douglas Anderson authored
This adds the touchscreen to the sc7280-herobrine-villager device tree. Note that the touchscreen on villager actually uses the reset line and thus we use the more specific "elan,ekth6915" compatible which allows us to specify the reset. The fact that villager's touchscreen uses the reset line can be contrasted against the touchscreen for CRD/herobrine-r1. On those boards, even though the touchscreen goes to the display, it's not hooked up to anything there. In order to keep the line parked on herobrine/CRD, we'll move the pullup from the qcard.dtsi file to the specific boards. This allows us to disable the pullup in the villager device tree since the pin is an output. Signed-off-by:
-
- 25 Jun, 2022 5 commits
-
-
Srinivasa Rao Mandadapu authored
Add LPASS LPI pinctrl properties, which are required for Audio functionality on herobrine based platforms of rev5+ (aka CRD 3.0/3.1) boards. Signed-off-by:
-
Srinivasa Rao Mandadapu authored
Add LPASS LPI pinctrl node required for Audio functionality on sc7280 based platforms. Signed-off-by:
-
Srinivasa Rao Mandadapu authored
Add drive strength property for secondary MI2S on sc7280 based platforms of rev5+ (aka CRD 3.0/3.1) boards. Signed-off-by:
-
Srinivasa Rao Mandadapu authored
Add pinmux nodes for primary and secondary I2S for SC7280 based platforms. Signed-off-by:
-
Dang Huynh authored
WLED is used for controlling display backlight on this phone. Signed-off-by:
Dang Huynh <danct12@riseup.net> Signed-off-by:
-
- 24 Jun, 2022 4 commits
-
-
Vinod Polimera authored
Drop the assigned clock rate property and vote on the mdp clock as per calculated value during the usecase. This patch is dependent on the patch ("drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe") [1]. [1] https://lore.kernel.org/r/1647269217-14064-2-git-send-email-quic_vpolimer@quicinc.com/Signed-off-by:Vinod Polimera <quic_vpolimer@quicinc.com> Reviewed-by:
-
Vinod Polimera authored
Drop the assigned clock rate property and vote on the mdp clock as per calculated value during the usecase. This patch is dependent on the patch ("drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe") [1]. [1] https://lore.kernel.org/r/1647269217-14064-2-git-send-email-quic_vpolimer@quicinc.com/Signed-off-by: -
Vinod Polimera authored
Drop the assigned clock rate property and vote on the mdp clock as per calculated value during the usecase. This patch is dependent on the patch ("drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe") [1]. [1] https://lore.kernel.org/r/1647269217-14064-2-git-send-email-quic_vpolimer@quicinc.com/Signed-off-by: -
Vinod Polimera authored
Drop the assigned clock rate property and vote on the mdp clock as per calculated value during the usecase. This patch is dependent on the patch ("drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe") [1]. [1] https://lore.kernel.org/r/1647269217-14064-2-git-send-email-quic_vpolimer@quicinc.com/Signed-off-by:
-
- 06 Jun, 2022 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull file descriptor fix from Al Viro: "Fix for breakage in #work.fd this window" * tag 'pull-work.fd-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: fix the breakage in close_fd_get_file() calling conventions change
-
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mmLinus Torvalds authored
Pull mm hotfixes from Andrew Morton: "Fixups for various recently-added and longer-term issues and a few minor tweaks: - fixes for material merged during this merge window - cc:stable fixes for more longstanding issues - minor mailmap and MAINTAINERS updates" * tag 'mm-hotfixes-stable-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/oom_kill.c: fix vm_oom_kill_table[] ifdeffery x86/kexec: fix memory leak of elf header buffer mm/memremap: fix missing call to untrack_pfn() in pagemap_range() mm: page_isolation: use compound_nr() correctly in isolate_single_pageblock() mm: hugetlb_vmemmap: fix CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON MAINTAINERS: add maintainer information for z3fold mailmap: update Josh Poimboeuf's email
-
- 05 Jun, 2022 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mmLinus Torvalds authored
Pull delay-accounting update from Andrew Morton: "A single featurette for delay accounting. Delayed a bit because, unusually, it had dependencies on both the mm-stable and mm-nonmm-stable queues" * tag 'mm-nonmm-stable-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: delayacct: track delays from write-protect copy
-
Linus Torvalds authored
The bluetooth code uses our bitmap infrastructure for the two bits (!) of connection setup flags, and in the process causes odd problems when it converts between a bitmap and just the regular values of said bits. It's completely pointless to do things like bitmap_to_arr32() to convert a bitmap into a u32. It shoudln't have been a bitmap in the first place. The reason to use bitmaps is if you have arbitrary number of bits you want to manage (not two!), or if you rely on the atomicity guarantees of the bitmap setting and clearing. The code could use an "atomic_t" and use "atomic_or/andnot()" to set and clear the bit values, but considering that it then copies the bitmaps around with "bitmap_to_arr32()" and friends, there clearly cannot be a lot of atomicity requirements. So just use a regular integer. In the process, this avoids the warnings about erroneous use of bitmap_from_u64() which were triggered on 32-bit architectures when conversion from a u64 would access two words (and, surprise, surprise, only one word is needed - and indeed overkill - for a 2-bit bitmap). That was always problematic, but the compiler seems to notice it and warn about the invalid pattern only after commit 0a97953f ("lib: add bitmap_{from,to}_arr64") changed the exact implementation details of 'bitmap_from_u64()', as reported by Sudip Mukherjee and Stephen Rothwell. Fixes: fe92ee64 ("Bluetooth: hci_core: Rework hci_conn_params flags") Link: https://lore.kernel.org/all/YpyJ9qTNHJzz0FHY@debian/ Link: https://lore.kernel.org/all/20220606080631.0c3014f2@canb.auug.org.au/ Link: https://lore.kernel.org/all/20220605162537.1604762-1-yury.norov@gmail.com/Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
Sudip Mukherjee <sudipm.mukherjee@gmail.com> Reviewed-by:
Yury Norov <yury.norov@gmail.com> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
