public-mirrors/linux
1
0
Fork 0
mirror of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2025-08-05 16:54:27 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
linux/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts

360 lines
6.7 KiB
Text
Raw Permalink Normal View History

arm64: dts: qcom: sc7280: Add herobrine-r1 Add the new herobrine-r1. Note that this is pretty much a re-design compared to herobrine-r0 so we don't attempt any dtsi to share stuff between them. This patch attempts to define things at 3 levels: 1. The Qcard level. Herobrine includes a Qcard PCB and the Qcard PCB is supposed to be the same (modulo stuffing options) across multiple boards, so trying to define what's there hopefully makes sense. NOTE that newer "CRD" boards from Qualcomm also use Qcard. When support for CRD3 is added hopefully it can use the Qcard include (and perhaps we should even evaluate it using herobrine.dtsi?) 2. The herobrine "baseboard" level. Right now most stuff is here with the exception of things that we _know_ will be different per board. We know that not all boards will have the same set of eMMC, nvme, and SD. We also know that the exact pin names are likely to be different. 3. The actual "board" level, AKA herobrine-rev1. NOTES: - This boots to command prompt. We're still waiting on the PWM driver. - This assumes LTE for now. Once it's clear how WiFi-only SKUs will work we expect some small changes. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220204140550.v4.1.I5604b7af908e8bbe709ac037a6a8a6ba8a2bfa94@changeid
2022-02-04 14:06:07 -08:00
// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Google Herobrine board device tree source
*
* Copyright 2022 Google LLC.
*/
/dts-v1/;
#include "sc7280-herobrine.dtsi"
arm64: dts: qcom: sc7280: Include sc7280-herobrine-audio-rt5682.dtsi in herobrine-r1 Include sc7280-herobrine-audio-rt5682.dtsi in herobrine-r1 as it uses rt5682 codec. Signed-off-by: Judy Hsiao <judyhsiao@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220721083849.1571744-4-judyhsiao@chromium.org
2022-07-21 08:38:49 +00:00
#include "sc7280-herobrine-audio-rt5682.dtsi"
arm64: dts: qcom: Add LTE SKUs for sc7280-villager family This adds LTE skus for villager device tree files. Signed-off-by: Jimmy Chen <jinghung.chen3@hotmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/SG2PR03MB5006B0C3E57803E3B1E0EDBCCC949@SG2PR03MB5006.apcprd03.prod.outlook.com
2022-07-26 17:45:49 +08:00
#include "sc7280-herobrine-lte-sku.dtsi"
arm64: dts: qcom: sc7280: Add herobrine-r1 Add the new herobrine-r1. Note that this is pretty much a re-design compared to herobrine-r0 so we don't attempt any dtsi to share stuff between them. This patch attempts to define things at 3 levels: 1. The Qcard level. Herobrine includes a Qcard PCB and the Qcard PCB is supposed to be the same (modulo stuffing options) across multiple boards, so trying to define what's there hopefully makes sense. NOTE that newer "CRD" boards from Qualcomm also use Qcard. When support for CRD3 is added hopefully it can use the Qcard include (and perhaps we should even evaluate it using herobrine.dtsi?) 2. The herobrine "baseboard" level. Right now most stuff is here with the exception of things that we _know_ will be different per board. We know that not all boards will have the same set of eMMC, nvme, and SD. We also know that the exact pin names are likely to be different. 3. The actual "board" level, AKA herobrine-rev1. NOTES: - This boots to command prompt. We're still waiting on the PWM driver. - This assumes LTE for now. Once it's clear how WiFi-only SKUs will work we expect some small changes. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220204140550.v4.1.I5604b7af908e8bbe709ac037a6a8a6ba8a2bfa94@changeid
2022-02-04 14:06:07 -08:00
/ {
model = "Google Herobrine (rev1+)";
compatible = "google,herobrine", "qcom,sc7280";
};
arm64: dts: qcom: sc7280: herobrine: disable some regulators by default Not all herobrine boards have a world facing camera or a fingerprint sensor, disable the regulators that feed these devices by default and only enable them for the boards that use them. Similarly the audio configuration can vary between boards, not all boards have the regulator pp3300_codec, disable it by default. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Rajendra Nayak <quic_rjendra@quicinc.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220316172814.v1.3.Iad21bd53f3ac14956b8dbbf3825fc7ab29abdf97@changeid
2022-03-16 17:28:19 -07:00
/*
* ADDITIONS TO FIXED REGULATORS DEFINED IN PARENT DEVICE TREE FILES
*
* Sort order matches the order in the parent files (parents before children).
*/
&pp3300_codec {
status = "okay";
};
&pp3300_fp_mcu {
status = "okay";
};
&pp2850_vcm_wf_cam {
status = "okay";
};
&pp2850_wf_cam {
status = "okay";
};
&pp1800_wf_cam {
status = "okay";
};
&pp1200_wf_cam {
status = "okay";
};
arm64: dts: qcom: sc7280: Add herobrine-r1 Add the new herobrine-r1. Note that this is pretty much a re-design compared to herobrine-r0 so we don't attempt any dtsi to share stuff between them. This patch attempts to define things at 3 levels: 1. The Qcard level. Herobrine includes a Qcard PCB and the Qcard PCB is supposed to be the same (modulo stuffing options) across multiple boards, so trying to define what's there hopefully makes sense. NOTE that newer "CRD" boards from Qualcomm also use Qcard. When support for CRD3 is added hopefully it can use the Qcard include (and perhaps we should even evaluate it using herobrine.dtsi?) 2. The herobrine "baseboard" level. Right now most stuff is here with the exception of things that we _know_ will be different per board. We know that not all boards will have the same set of eMMC, nvme, and SD. We also know that the exact pin names are likely to be different. 3. The actual "board" level, AKA herobrine-rev1. NOTES: - This boots to command prompt. We're still waiting on the PWM driver. - This assumes LTE for now. Once it's clear how WiFi-only SKUs will work we expect some small changes. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220204140550.v4.1.I5604b7af908e8bbe709ac037a6a8a6ba8a2bfa94@changeid
2022-02-04 14:06:07 -08:00
/* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */
/*
* Although the trackpad is really part of the herobrine baseboard, we'll
* put the actual definition in the board device tree since different boards
* might hook up different trackpads (or no i2c trackpad at all in the case
* of tablets / detachables).
*/
ap_tp_i2c: &i2c0 {
status = "okay";
clock-frequency = <400000>;
trackpad: trackpad@15 {
compatible = "elan,ekth3000";
reg = <0x15>;
pinctrl-names = "default";
pinctrl-0 = <&tp_int_odl>;
interrupt-parent = <&tlmm>;
interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
vcc-supply = <&pp3300_z1>;
wakeup-source;
};
};
/*
* The touchscreen connector might come off the Qcard, at least in the case of
* eDP. Like the trackpad, we'll put it in the board device tree file since
* different boards have different touchscreens.
*/
ts_i2c: &i2c13 {
status = "okay";
clock-frequency = <400000>;
ap_ts: touchscreen@5c {
compatible = "hid-over-i2c";
reg = <0x5c>;
pinctrl-names = "default";
pinctrl-0 = <&ts_int_conn>, <&ts_rst_conn>;
interrupt-parent = <&tlmm>;
interrupts = <55 IRQ_TYPE_LEVEL_LOW>;
post-power-on-delay-ms = <500>;
hid-descr-addr = <0x0000>;
vdd-supply = <&ts_avdd>;
};
};
arm64: dts: qcom: sc7280: eDP for herobrine boards Add eDP support to herobrine boards, splitting up amongst the different files as makes sense. Rationale for the current split of things: * The eDP connector itself is on qcard. However, not all devices with a qcard will use an eDP panel. Some might use MIPI and, presumably, someone could build a device with qcard that had no display at all. * The qcard provides a PWM for backlight that goes to the eDP connector. This PWM is also provided to the board and it's expected that it would be used as the backlight PWM even for herobrine devices with MIPI displays. * It's currently assumed that all herobrine boards will have some sort of display, either MIPI or eDP (but not both). * We will assume herobrine-rev1 has eDP. The schematics allow for a MIPI panel to be hooked up but, aside from some testing, nobody is doing this and most boards don't have all the parts stuffed for it. The two panels would also share a PWM for backlight, which is weird. * herobrine-villager and herobrine-hoglin (crd) also have eDP. * herobrine-hoglin (crd) has slightly different regulator setup for the backlight. It's expected that this is unique to this board. See comments in the dts file. * There are some regulators that are defined in the qcard schematic but provided by the board like "vreg_edp_bl" and "vreg_edp_3p3". While we could put references to these regulators straight in the qcard.dtsi file, this would force someone using qcard that didn't provide those regulators to provide a dummy or do an ugly /delete-node/. Instead, we'll add references in herobrine.dtsi. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220426124053.v2.1.Iedd71976a78d53c301ce0134832de95a989c9195@changeid
2022-04-26 12:41:03 -07:00
&mdss_edp {
status = "okay";
};
&mdss_edp_phy {
status = "okay";
};
arm64: dts: qcom: sc7280: Add herobrine-r1 Add the new herobrine-r1. Note that this is pretty much a re-design compared to herobrine-r0 so we don't attempt any dtsi to share stuff between them. This patch attempts to define things at 3 levels: 1. The Qcard level. Herobrine includes a Qcard PCB and the Qcard PCB is supposed to be the same (modulo stuffing options) across multiple boards, so trying to define what's there hopefully makes sense. NOTE that newer "CRD" boards from Qualcomm also use Qcard. When support for CRD3 is added hopefully it can use the Qcard include (and perhaps we should even evaluate it using herobrine.dtsi?) 2. The herobrine "baseboard" level. Right now most stuff is here with the exception of things that we _know_ will be different per board. We know that not all boards will have the same set of eMMC, nvme, and SD. We also know that the exact pin names are likely to be different. 3. The actual "board" level, AKA herobrine-rev1. NOTES: - This boots to command prompt. We're still waiting on the PWM driver. - This assumes LTE for now. Once it's clear how WiFi-only SKUs will work we expect some small changes. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220204140550.v4.1.I5604b7af908e8bbe709ac037a6a8a6ba8a2bfa94@changeid
2022-02-04 14:06:07 -08:00
/* For nvme */
&pcie1 {
status = "okay";
};
/* For nvme */
&pcie1_phy {
status = "okay";
};
/* For eMMC */
&sdhc_1 {
status = "okay";
};
/* For SD Card */
&sdhc_2 {
status = "okay";
};
arm64: dts: qcom: sc7280: Add touchscreen to villager 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: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220524134840.1.I80072b8815ac08c12af8f379a33cc2d83693dc51@changeid
2022-05-24 13:48:49 -07:00
/* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */
/*
* This pin goes to the display panel but then doesn't actually do anything
* on the panel itself (it doesn't connect to the touchscreen controller).
* We'll set a pullup here just to park the line.
*/
&ts_rst_conn {
bias-pull-up;
};
arm64: dts: qcom: sc7280: Add herobrine-r1 Add the new herobrine-r1. Note that this is pretty much a re-design compared to herobrine-r0 so we don't attempt any dtsi to share stuff between them. This patch attempts to define things at 3 levels: 1. The Qcard level. Herobrine includes a Qcard PCB and the Qcard PCB is supposed to be the same (modulo stuffing options) across multiple boards, so trying to define what's there hopefully makes sense. NOTE that newer "CRD" boards from Qualcomm also use Qcard. When support for CRD3 is added hopefully it can use the Qcard include (and perhaps we should even evaluate it using herobrine.dtsi?) 2. The herobrine "baseboard" level. Right now most stuff is here with the exception of things that we _know_ will be different per board. We know that not all boards will have the same set of eMMC, nvme, and SD. We also know that the exact pin names are likely to be different. 3. The actual "board" level, AKA herobrine-rev1. NOTES: - This boots to command prompt. We're still waiting on the PWM driver. - This assumes LTE for now. Once it's clear how WiFi-only SKUs will work we expect some small changes. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220204140550.v4.1.I5604b7af908e8bbe709ac037a6a8a6ba8a2bfa94@changeid
2022-02-04 14:06:07 -08:00
/* PINCTRL - BOARD-SPECIFIC */
/*
* Methodology for gpio-line-names:
* - If a pin goes to herobrine board and is named it gets that name.
* - If a pin goes to herobrine board and is not named, it gets no name.
* - If a pin is totally internal to Qcard then it gets Qcard name.
* - If a pin is not hooked up on Qcard, it gets no name.
*/
&pm8350c_gpios {
gpio-line-names = "FLASH_STROBE_1", /* 1 */
"AP_SUSPEND",
"PM8008_1_RST_N",
"",
"",
"",
"PMIC_EDP_BL_EN",
"PMIC_EDP_BL_PWM",
"";
};
&tlmm {
gpio-line-names = "AP_TP_I2C_SDA", /* 0 */
"AP_TP_I2C_SCL",
"SSD_RST_L",
"PE_WAKE_ODL",
"AP_SAR_SDA",
"AP_SAR_SCL",
"PRB_SC_GPIO_6",
"TP_INT_ODL",
"HP_I2C_SDA",
"HP_I2C_SCL",
"GNSS_L1_EN", /* 10 */
"GNSS_L5_EN",
"SPI_AP_MOSI",
"SPI_AP_MISO",
"SPI_AP_CLK",
"SPI_AP_CS0_L",
/*
* AP_FLASH_WP is crossystem ABI. Schematics
* call it BIOS_FLASH_WP_OD.
*/
"AP_FLASH_WP",
"",
"AP_EC_INT_L",
"",
"UF_CAM_RST_L", /* 20 */
"WF_CAM_RST_L",
"UART_AP_TX_DBG_RX",
"UART_DBG_TX_AP_RX",
"",
"PM8008_IRQ_1",
"HOST2WLAN_SOL",
"WLAN2HOST_SOL",
"MOS_BT_UART_CTS",
"MOS_BT_UART_RFR",
"MOS_BT_UART_TX", /* 30 */
"MOS_BT_UART_RX",
"PRB_SC_GPIO_32",
"HUB_RST_L",
"",
"",
"AP_SPI_FP_MISO",
"AP_SPI_FP_MOSI",
"AP_SPI_FP_CLK",
"AP_SPI_FP_CS_L",
"AP_EC_SPI_MISO", /* 40 */
"AP_EC_SPI_MOSI",
"AP_EC_SPI_CLK",
"AP_EC_SPI_CS_L",
"LCM_RST_L",
"EARLY_EUD_N",
"",
"DP_HOT_PLUG_DET",
"IO_BRD_MLB_ID0",
"IO_BRD_MLB_ID1",
"IO_BRD_MLB_ID2", /* 50 */
"SSD_EN",
"TS_I2C_SDA_CONN",
"TS_I2C_CLK_CONN",
"TS_RST_CONN",
"TS_INT_CONN",
"AP_I2C_TPM_SDA",
"AP_I2C_TPM_SCL",
"PRB_SC_GPIO_58",
"PRB_SC_GPIO_59",
"EDP_HOT_PLUG_DET_N", /* 60 */
"FP_TO_AP_IRQ_L",
"",
"AMP_EN",
"CAM0_MCLK_GPIO_64",
"CAM1_MCLK_GPIO_65",
"WF_CAM_MCLK",
"PRB_SC_GPIO_67",
"FPMCU_BOOT0",
"UF_CAM_SDA",
"UF_CAM_SCL", /* 70 */
"",
"",
"WF_CAM_SDA",
"WF_CAM_SCL",
"",
"",
"EN_FP_RAILS",
"FP_RST_L",
"PCIE1_CLKREQ_ODL",
"EN_PP3300_DX_EDP", /* 80 */
"SC_GPIO_81",
"FORCED_USB_BOOT",
"WCD_RESET_N",
"MOS_WLAN_EN",
"MOS_BT_EN",
"MOS_SW_CTRL",
"MOS_PCIE0_RST",
"MOS_PCIE0_CLKREQ_N",
"MOS_PCIE0_WAKE_N",
"MOS_LAA_AS_EN", /* 90 */
"SD_CD_ODL",
"",
"",
"MOS_BT_WLAN_SLIMBUS_CLK",
"MOS_BT_WLAN_SLIMBUS_DAT0",
"HP_MCLK",
"HP_BCLK",
"HP_DOUT",
"HP_DIN",
"HP_LRCLK", /* 100 */
"HP_IRQ",
"",
"",
"GSC_AP_INT_ODL",
"EN_PP3300_CODEC",
"AMP_BCLK",
"AMP_DIN",
"AMP_LRCLK",
"UIM1_DATA_GPIO_109",
"UIM1_CLK_GPIO_110", /* 110 */
"UIM1_RESET_GPIO_111",
"PRB_SC_GPIO_112",
"UIM0_DATA",
"UIM0_CLK",
"UIM0_RST",
"UIM0_PRESENT_ODL",
"SDM_RFFE0_CLK",
"SDM_RFFE0_DATA",
"WF_CAM_EN",
"FASTBOOT_SEL_0", /* 120 */
"SC_GPIO_121",
"FASTBOOT_SEL_1",
"SC_GPIO_123",
"FASTBOOT_SEL_2",
"SM_RFFE4_CLK_GRFC_8",
"SM_RFFE4_DATA_GRFC_9",
"WLAN_COEX_UART1_RX",
"WLAN_COEX_UART1_TX",
"PRB_SC_GPIO_129",
"LCM_ID0", /* 130 */
"LCM_ID1",
"",
"SDR_QLINK_REQ",
"SDR_QLINK_EN",
"QLINK0_WMSS_RESET_N",
"SMR526_QLINK1_REQ",
"SMR526_QLINK1_EN",
"SMR526_QLINK1_WMSS_RESET_N",
"PRB_SC_GPIO_139",
"SAR1_IRQ_ODL", /* 140 */
"SAR0_IRQ_ODL",
"PRB_SC_GPIO_142",
"",
"WCD_SWR_TX_CLK",
"WCD_SWR_TX_DATA0",
"WCD_SWR_TX_DATA1",
"WCD_SWR_RX_CLK",
"WCD_SWR_RX_DATA0",
"WCD_SWR_RX_DATA1",
"DMIC01_CLK", /* 150 */
"DMIC01_DATA",
"DMIC23_CLK",
"DMIC23_DATA",
"",
"",
"EC_IN_RW_ODL",
"HUB_EN",
"WCD_SWR_TX_DATA2",
"",
"", /* 160 */
"",
"",
"",
"",
"",
"",
"",
"",
"",
"", /* 170 */
"MOS_BLE_UART_TX",
"MOS_BLE_UART_RX",
"",
"";
};
Reference in a new issue Copy permalink