* Re: [RFC PATCH 1/2] dt-bindings: pcie: Document QCOM PCIE ECAM compatible root complex
From: Krzysztof Kozlowski @ 2024-04-04 19:30 UTC (permalink / raw)
To: Mayank Rana, linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
manivannan.sadhasivam, krzysztof.kozlowski+dt, conor+dt,
devicetree
Cc: linux-arm-msm, quic_ramkri, quic_nkela, quic_shazhuss,
quic_msarkar, quic_nitegupt
In-Reply-To: <1712257884-23841-2-git-send-email-quic_mrana@quicinc.com>
On 04/04/2024 21:11, Mayank Rana wrote:
> On some of Qualcomm platform, firmware configures PCIe controller in RC
On which?
Your commit or binding must answer to all such questions.
> mode with static iATU window mappings of configuration space for entire
> supported bus range in ECAM compatible mode. Firmware also manages PCIe
> PHY as well required system resources. Here document properties and
> required configuration to power up QCOM PCIe ECAM compatible root complex
> and PHY for PCIe functionality.
>
> Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
> ---
> .../devicetree/bindings/pci/qcom,pcie-ecam.yaml | 94 ++++++++++++++++++++++
> 1 file changed, 94 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
>
> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
> new file mode 100644
> index 00000000..c209f12
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
> @@ -0,0 +1,94 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/qcom,pcie-ecam.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm ECAM compliant PCI express root complex
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + Qualcomm SOC based ECAM compatible PCIe root complex supporting MSI controller.
Which SoC?
> + Firmware configures PCIe controller in RC mode with static iATU window mappings
> + of configuration space for entire supported bus range in ECAM compatible mode.
> +
> +maintainers:
> + - Mayank Rana <quic_mrana@quicinc.com>
> +
> +allOf:
> + - $ref: /schemas/pci/pci-bus.yaml#
> + - $ref: /schemas/power-domain/power-domain-consumer.yaml
> +
> +properties:
> + compatible:
> + const: qcom,pcie-ecam-rc
No, this must have SoC specific compatibles.
> +
> + reg:
> + minItems: 1
maxItems instead
> + description: ECAM address space starting from root port till supported bus range
> +
> + interrupts:
> + minItems: 1
> + maxItems: 8
This is way too unspecific.
> +
> + ranges:
> + minItems: 2
> + maxItems: 3
Why variable?
> +
> + iommu-map:
> + minItems: 1
> + maxItems: 16
Why variable?
Open existing bindings and look how it is done.
> +
> + power-domains:
> + maxItems: 1
> + description: A phandle to node which is able support way to communicate with firmware
> + for enabling PCIe controller and PHY as well managing all system resources needed to
> + make both controller and PHY operational for PCIe functionality.
This description does not tell me much. Say something specific. And drop
redundant parts like phandle.
> +
> + dma-coherent: true
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - ranges
> + - power-domains
> + - device_type
> + - linux,pci-domain
> + - bus-range
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + pcie0: pci@1c00000 {
> + compatible = "qcom,pcie-ecam-rc";
> + reg = <0x4 0x00000000 0 0x10000000>;
> + device_type = "pci";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0x0 0x40000000 0x0 0x40000000 0x0 0x100000>,
> + <0x02000000 0x0 0x40100000 0x0 0x40100000 0x0 0x1ff00000>,
> + <0x43000000 0x4 0x10100000 0x4 0x10100000 0x0 0x100000>;
Follow DTS coding style about placement and alignment.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 2/2] PCI: Add Qualcomm PCIe ECAM root complex driver
From: Krzysztof Kozlowski @ 2024-04-04 19:33 UTC (permalink / raw)
To: Mayank Rana, linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
manivannan.sadhasivam, krzysztof.kozlowski+dt, conor+dt,
devicetree
Cc: linux-arm-msm, quic_ramkri, quic_nkela, quic_shazhuss,
quic_msarkar, quic_nitegupt
In-Reply-To: <1712257884-23841-3-git-send-email-quic_mrana@quicinc.com>
On 04/04/2024 21:11, Mayank Rana wrote:
> On some of Qualcomm platform, firmware configures PCIe controller into
> ECAM mode allowing static memory allocation for configuration space of
> supported bus range. Firmware also takes care of bringing up PCIe PHY
> and performing required operation to bring PCIe link into D0. Firmware
> also manages system resources (e.g. clocks/regulators/resets/ bus voting).
> Hence add Qualcomm PCIe ECAM root complex driver which enumerates PCIe
> root complex and connected PCIe devices. Firmware won't be enumerating
> or powering up PCIe root complex until this driver invokes power domain
> based notification to bring PCIe link into D0/D3cold mode.
...
> +
> +static int qcom_pcie_ecam_suspend_noirq(struct device *dev)
> +{
> + return pm_runtime_put_sync(dev);
> +}
> +
> +static int qcom_pcie_ecam_resume_noirq(struct device *dev)
> +{
> + return pm_runtime_get_sync(dev);
> +}
> +
> +static int qcom_pcie_ecam_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct qcom_msi *msi;
> + int ret;
> +
> + ret = devm_pm_runtime_enable(dev);
> + if (ret)
> + return ret;
> +
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret < 0) {
> + dev_err(dev, "fail to enable pcie controller: %d\n", ret);
> + return ret;
> + }
> +
> + msi = qcom_msi_init(dev);
> + if (IS_ERR(msi)) {
> + pm_runtime_put_sync(dev);
> + return PTR_ERR(msi);
> + }
> +
> + ret = pci_host_common_probe(pdev);
> + if (ret) {
> + dev_err(dev, "pci_host_common_probe() failed:%d\n", ret);
Don't print function name, but instead say something useful. Above error
message is so not useful that just drop it.
> + qcom_msi_deinit(msi);
> + pm_runtime_put_sync(dev);
> + }
> +
> + return ret;
> +}
> +
> +static const struct dev_pm_ops qcom_pcie_ecam_pm_ops = {
> + NOIRQ_SYSTEM_SLEEP_PM_OPS(qcom_pcie_ecam_suspend_noirq,
> + qcom_pcie_ecam_resume_noirq)
> +};
> +
> +static const struct pci_ecam_ops qcom_pcie_ecam_ops = {
> + .pci_ops = {
> + .map_bus = pci_ecam_map_bus,
> + .read = pci_generic_config_read,
> + .write = pci_generic_config_write,
> + }
> +};
> +
> +static const struct of_device_id qcom_pcie_ecam_of_match[] = {
> + {
> + .compatible = "qcom,pcie-ecam-rc",
> + .data = &qcom_pcie_ecam_ops,
Why do you have ops/match data for generic compatible?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 0/2] Add Qualcomm PCIe ECAM root complex driver
From: Krzysztof Kozlowski @ 2024-04-04 19:33 UTC (permalink / raw)
To: Mayank Rana, linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
manivannan.sadhasivam, krzysztof.kozlowski+dt, conor+dt,
devicetree
Cc: linux-arm-msm, quic_ramkri, quic_nkela, quic_shazhuss,
quic_msarkar, quic_nitegupt
In-Reply-To: <1712257884-23841-1-git-send-email-quic_mrana@quicinc.com>
On 04/04/2024 21:11, Mayank Rana wrote:
> On some of Qualcomm platform, firmware takes care of system resources
> related to PCIe PHY and controller as well bringing up PCIe link and
> having static iATU configuration for PCIe controller to work into
> ECAM compliant mode. Hence add Qualcomm PCIe ECAM root complex driver.
>
> Tested:
> - Validated NVME functionality with PCIe0 and PCIe1 on SA877p-ride platform
>
RFC means code is not ready, right? Please get internal review done and
send it when it is ready. I am not sure if you expect any reviews. Some
people send RFC and do not expect reviews. Some expect. I have no clue
and I do not want to waste my time. Please clarify what you expect from
maintainers regarding this contribution.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: Add SM8550 Xperia 1 V
From: Konrad Dybcio @ 2024-04-04 19:41 UTC (permalink / raw)
To: neil.armstrong, James Schulman, David Rhodes, Richard Fitzgerald,
Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ricardo Rivera-Matos, Bjorn Andersson, Abel Vesa,
Sai Prakash Ranjan, Kees Cook, Tony Luck, Guilherme G. Piccoli
Cc: Marijn Suijten, alsa-devel, patches, linux-sound, devicetree,
linux-kernel, linux-arm-msm, linux-hardening
In-Reply-To: <05e6f92c-388c-4bc6-a4cd-e9d981166d1c@linaro.org>
On 2/12/24 18:26, Neil Armstrong wrote:
> On 12/02/2024 14:10, Konrad Dybcio wrote:
>> Add support for Sony Xperia 1 V, a.k.a PDX234. This device is a part
>> of the SoMC SM8550 Yodo platform.
>>
[...]
>> +/* TODO: Only one SID of PMR735D seems accessible? */
>
>
> What's reported by the cpuinfo pmic array ?
PMK8550 2.1
PM8550 2.0
PM8550VS 2.0
PM8550VS 2.0
PM8550VS 2.0
PM8550VE 2.0
PM8550VS 2.0
PM8550B 2.0
PMR735D 2.0
PM8010 1.1
PM8010 1.1
Not sure if there's only one or the other one is secure?
>
> <snip>
>
> With the pcie thing fixed:
> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
It's gonna be fine with the recent aux clock additions. If you
have no further comments, I'll happily ask for this to be merged ;)
Konrad
^ permalink raw reply
* Re: [PATCH] clk: rockchip: clk-rk3568.c: Add missing USB480M_PHY mux
From: Heiko Stuebner @ 2024-04-04 19:43 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sascha Hauer
Cc: linux-clk, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, David Jander, Sascha Hauer
In-Reply-To: <20240404-clk-rockchip-rk3568-add-usb480m-phy-mux-v1-1-e8542afd58b9@pengutronix.de>
Hi Sascha,
Am Donnerstag, 4. April 2024, 09:27:01 CEST schrieb Sascha Hauer:
> From: David Jander <david@protonic.nl>
>
> The USB480M clock can source from a MUX that selects the clock to come
> from either of the USB-phy internal 480MHz PLLs. These clocks are
> provided by the USB phy driver.
>
> Signed-off-by: David Jander <david@protonic.nl>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/clk/rockchip/clk-rk3568.c | 4 ++++
> include/dt-bindings/clock/rk3568-cru.h | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/clk/rockchip/clk-rk3568.c b/drivers/clk/rockchip/clk-rk3568.c
> index 8cb21d10beca2..2d44bcaef046b 100644
> --- a/drivers/clk/rockchip/clk-rk3568.c
> +++ b/drivers/clk/rockchip/clk-rk3568.c
> @@ -215,6 +215,7 @@ static const struct rockchip_cpuclk_reg_data rk3568_cpuclk_data = {
>
> PNAME(mux_pll_p) = { "xin24m" };
> PNAME(mux_usb480m_p) = { "xin24m", "usb480m_phy", "clk_rtc_32k" };
> +PNAME(mux_usb480m_phy_p) = { "clk_usbphy0_480m", "clk_usbphy1_480m"};
> PNAME(mux_armclk_p) = { "apll", "gpll" };
> PNAME(clk_i2s0_8ch_tx_p) = { "clk_i2s0_8ch_tx_src", "clk_i2s0_8ch_tx_frac", "i2s0_mclkin", "xin_osc0_half" };
> PNAME(clk_i2s0_8ch_rx_p) = { "clk_i2s0_8ch_rx_src", "clk_i2s0_8ch_rx_frac", "i2s0_mclkin", "xin_osc0_half" };
> @@ -485,6 +486,9 @@ static struct rockchip_clk_branch rk3568_clk_branches[] __initdata = {
> MUX(USB480M, "usb480m", mux_usb480m_p, CLK_SET_RATE_PARENT,
> RK3568_MODE_CON0, 14, 2, MFLAGS),
>
> + MUX(USB480M_PHY, "usb480m_phy", mux_usb480m_phy_p, CLK_SET_RATE_PARENT,
> + RK3568_MISC_CON2, 15, 1, MFLAGS),
> +
> /* PD_CORE */
> COMPOSITE(0, "sclk_core_src", apll_gpll_npll_p, CLK_IGNORE_UNUSED,
> RK3568_CLKSEL_CON(2), 8, 2, MFLAGS, 0, 4, DFLAGS | CLK_DIVIDER_READ_ONLY,
> diff --git a/include/dt-bindings/clock/rk3568-cru.h b/include/dt-bindings/clock/rk3568-cru.h
> index d29890865150d..5263085c5b238 100644
> --- a/include/dt-bindings/clock/rk3568-cru.h
> +++ b/include/dt-bindings/clock/rk3568-cru.h
> @@ -78,6 +78,7 @@
> #define CPLL_333M 9
> #define ARMCLK 10
> #define USB480M 11
> +#define USB480M_PHY 12
> #define ACLK_CORE_NIU2BUS 18
> #define CLK_CORE_PVTM 19
> #define CLK_CORE_PVTM_CORE 20
>
Please separate the code change and clock-id addition into separate
patches. That way dt-maintainers will more easily see that there are
changes to the dt-binding inside.
Other than that, the change looks fine :-)
Thanks
Heiko
^ permalink raw reply
* [PATCH v2 0/2] mfd: Add ROHM BD71879
From: Andreas Kemnade @ 2024-04-04 19:54 UTC (permalink / raw)
To: lee, robh+dt, krzysztof.kozlowski+dt, conor+dt, mazziesaccount,
devicetree, linux-kernel
Cc: Andreas Kemnade
Add software-compatible variant of the BD71828.
Changes in v2:
allow compatible = "rohm,bd71879", "rohm,bd71828"
Andreas Kemnade (2):
dt-bindings: mfd: Add ROHM BD71879
mfd: rohm-bd71828: Add software-compatible variant BD71879
.../devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 7 ++++++-
drivers/mfd/rohm-bd71828.c | 4 ++++
2 files changed, 10 insertions(+), 1 deletion(-)
--
2.39.2
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: mfd: Add ROHM BD71879
From: Andreas Kemnade @ 2024-04-04 19:54 UTC (permalink / raw)
To: lee, robh+dt, krzysztof.kozlowski+dt, conor+dt, mazziesaccount,
devicetree, linux-kernel
Cc: Andreas Kemnade
In-Reply-To: <20240404195423.666446-1-andreas@kemnade.info>
As this chip was seen in several devices in the wild, add it.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
.../devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
index 0b62f854bf6b..07f99738fcf6 100644
--- a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
@@ -17,7 +17,12 @@ description: |
properties:
compatible:
- const: rohm,bd71828
+ oneOf:
+ - const: rohm,bd71828
+
+ - items:
+ - const: rohm,bd71879
+ - const: rohm,bd71828
reg:
description:
--
2.39.2
^ permalink raw reply related
* [PATCH v2 2/2] mfd: rohm-bd71828: Add software-compatible variant BD71879
From: Andreas Kemnade @ 2024-04-04 19:54 UTC (permalink / raw)
To: lee, robh+dt, krzysztof.kozlowski+dt, conor+dt, mazziesaccount,
devicetree, linux-kernel
Cc: Andreas Kemnade
In-Reply-To: <20240404195423.666446-1-andreas@kemnade.info>
Add the BD71879 PMIC which is software-compatible to the BD71828, so reuse
the same device_type enum.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
Acked-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
drivers/mfd/rohm-bd71828.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
index 4a1fa8a0d76a..f0b444690d4d 100644
--- a/drivers/mfd/rohm-bd71828.c
+++ b/drivers/mfd/rohm-bd71828.c
@@ -585,6 +585,10 @@ static const struct of_device_id bd71828_of_match[] = {
{
.compatible = "rohm,bd71828",
.data = (void *)ROHM_CHIP_TYPE_BD71828,
+ }, {
+ .compatible = "rohm,bd71879",
+ /* equivalent from a software point of view */
+ .data = (void *)ROHM_CHIP_TYPE_BD71828,
}, {
.compatible = "rohm,bd71815",
.data = (void *)ROHM_CHIP_TYPE_BD71815,
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v9 0/4] PCI: brcmstb: Configure appropriate HW CLKREQ# mode
From: Cyril Brulebois @ 2024-04-04 20:01 UTC (permalink / raw)
To: Jim Quinlan
Cc: linux-pci, Nicolas Saenz Julienne, Bjorn Helgaas,
Lorenzo Pieralisi, Phil Elwell, bcm-kernel-feedback-list,
Conor Dooley,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Jim Quinlan, Krzysztof Kozlowski,
Krzysztof Wilczyński,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Lorenzo Pieralisi, Rob Herring
In-Reply-To: <20240403213902.26391-1-james.quinlan@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 3351 bytes --]
Hi Jim,
Jim Quinlan <james.quinlan@broadcom.com> (2024-04-03):
> v9 -- v8 was setting an internal bus timeout to accomodate large L1 exit
> latencies. After meeting the PCIe HW team it was revealed that the
> HW default timeout value was set low for the purposes of HW debugging
> convenience; for nominal operation it needs to be set to a higher
> value independent of this submission's purpose. This is now a
> separate commit.
>
> -- With v8, Bjorne asked what was preventing a device from exceeding the
> time required for the above internal bus timeout. The answer to this
> is for us to set the endpoints' max latency {no-,}snoop value to
> something below this internal timeout value. If the endpoint
> respects this value as it should, it will not send an LTR request
> with a larger latency value and not put itself in a situation
> that requires more latency than is possible for the platform.
>
> Typically, ACPI or FW sets these max latency values. In most of our
> systems we do not have this happening so it is up to the RC driver to
> set these values in the endpoint devices. If the endpoints already
> have non-zero values that are lower than what we are setting, we let
> them be, as it is possible ACPI or FW set them and knows something
> that we do not.
>
> -- The "clkreq" commit has only been changed to remove the code that was
> setting the timeout value, as this code is now its own commit.
Given the bot's feedback, I took the liberty of running tests on your
patch series except with an extra “static” keyword. On my build system,
gcc 12 wasn't complaining about it but I didn't spend time trying to
find the right options, or trying a switch to clang to confirm the
before/after situation:
-void brcm_set_downstream_devs_ltr_max(struct brcm_pcie *pcie)
+static void brcm_set_downstream_devs_ltr_max(struct brcm_pcie *pcie)
Anyway, this is still:
Tested-by: Cyril Brulebois <cyril@debamax.com>
Test setup:
-----------
- using a $CM with the 20230111 EEPROM
- on the same CM4 IO Board
- with a $PCIE board (PCIe to multiple USB ports)
- and the same Samsung USB flash drive + Logitech keyboard.
where $CM is one of:
- CM4 Lite Rev 1.0
- CM4 8/32 Rev 1.0
- CM4 4/32 Rev 1.1
and $PCIE is one of:
- SupaHub PCE6U1C-R02, VER 006
- SupaHub PCE6U1C-R02, VER 006S
- Waveshare VIA VL805/806-based
Results:
--------
1. Given this is already v9, and given I don't see how this could have
possibly changed, I didn't build or tested an unpatched kernel,
which I would still expect to produce either a successful boot
*without* seeing the devices plugged on the PCIe-to-USB board or the
dreaded SError in most cases.
2. With a patched kernel (v6.7-562-g9f8413c4a66f2 + this series +
“static” in front of brcm_set_downstream_devs_ltr_max()), for all
$CM/$PCIE combinations, I'm getting a system that boots, sees the
flash drive, and gives decent read/write performance on it (plus a
functional keyboard).
Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH v4 1/3] dt-bindings: arm: merge qcom,idle-state with idle-state
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Jonathan Cameron, Jonathan Corbet,
Stephen Boyd, Lorenzo Pieralisi, Anup Patel, David Heidelberg
Cc: Luca Weiss, Rob Herring, Ulf Hansson, Catalin Marinas,
Krzysztof Kozlowski, devicetree, linux-kernel, linux-riscv
In-Reply-To: <20231202234832.155306-1-david@ixit.cz>
On Sun, 03 Dec 2023 00:47:17 +0100, David Heidelberg wrote:
> Merge Qualcomm-specific idle-state binding with generic one.
>
>
Applied, thanks!
[2/3] ARM: dts: qcom: include cpu in idle-state node names
commit: e48919dc1ed568f895eca090dc6c5dc56b12480c
[3/3] ARM: dts: qcom: msm8916: idle-state compatible require the generic idle-state
commit: 8f2cc88cd4a35e33931ca1375ea508c8c9267b57
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8150-hdk: enable WiFI support
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Baryshkov
Cc: linux-arm-msm, devicetree, linux-kernel, Kalle Valo, Jeff Johnson,
ath10k
In-Reply-To: <20240403-sm8150-hdk-wifi-v1-1-8da3063829c2@linaro.org>
On Wed, 03 Apr 2024 20:10:12 +0300, Dmitry Baryshkov wrote:
> Enable modem DSP and WiFI devices on the SM8150 HDK device. The HDK is
> manufactured by Lantronix, but it attributed to Qualcomm, so the
> calibration string uses Qualcomm as manufacturer.
>
> For reference:
>
> ath10k_snoc 18800000.wifi: qmi chip_id 0x30224 chip_family 0x4001 board_id 0x55 soc_id 0x40060000
> ath10k_snoc 18800000.wifi: qmi fw_version 0x32040163 fw_build_timestamp 2019-10-08 05:42 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.0-00355-QCAHLSWMTPLZ-1
> ath10k_snoc 18800000.wifi: wcn3990 hw1.0 target 0x00000008 chip_id 0x00000000 sub 0000:0000
> ath10k_snoc 18800000.wifi: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 0
> ath10k_snoc 18800000.wifi: firmware ver api 5 features wowlan,mgmt-tx-by-reference,non-bmi crc32 b3d4b790
> ath10k_snoc 18800000.wifi: htt-ver 3.73 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1
> ath10k_snoc 18800000.wifi: invalid MAC address; choosing random
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: sm8150-hdk: enable WiFI support
commit: e5fd6512f6e842d8c5883b9fa4d72c8a5295efdc
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8350: Add interconnects to UFS
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Baryshkov
Cc: linux-arm-msm, devicetree
In-Reply-To: <20240313-sm8350-ufs-icc-v1-1-73fa2da99779@linaro.org>
On Wed, 13 Mar 2024 03:32:09 +0200, Dmitry Baryshkov wrote:
> To ensure that UFS doesn't get disconnected from NoC, add interconnect properties
> to the UFS controller.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: sm8350: Add interconnects to UFS
commit: cb06e2b406279f65890233af103c638d3752d328
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/2] arm64: dts: qcom: msm8916: drop dtbTool compatibles
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Baryshkov
Cc: linux-arm-msm, devicetree, Stephan Gerhold
In-Reply-To: <20240314-msm8916-drop-compats-v2-0-5a4b40f832d3@linaro.org>
On Thu, 14 Mar 2024 03:42:47 +0200, Dmitry Baryshkov wrote:
> Only two boards ever has adopted the dtbTool-specific compatibles.
> However the dtbTool should not be used anymore. It was required only for
> the old, broken lk1st bootloader. All users of those boards should have
> updated to use lk2nd instead. Otherwise several important features
> (secondary CPU cores, WiFi, BT) will not work with the upstream kernel.
>
> Drop these extra compatibles, merging these two boards into the common
> bindings case for msm8916.
>
> [...]
Applied, thanks!
[1/2] dt-bindings: arm: qcom: drop dtbTool-specific compatibles
commit: 88d0e4e10d77bb4e575b74ac0f6dd3140ecc3bcd
[2/2] arm64: dts: qcom: msm8916: drop dtbTool-specific compatibles
commit: 3867ad6d39cd97875aca7e5f1b17ea6dd5b1107a
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v3 0/4] arm64: dts: fix several display-related schema warnings
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Rob Clark, Abhinav Kumar, Sean Paul, Marijn Suijten, David Airlie,
Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Vinod Koul, Dmitry Baryshkov
Cc: linux-arm-msm, dri-devel, freedreno, devicetree,
Krzysztof Kozlowski
In-Reply-To: <20240402-fd-fix-schema-v3-0-817ea6ddf775@linaro.org>
On Tue, 02 Apr 2024 05:57:14 +0300, Dmitry Baryshkov wrote:
> Fix several warnings produced by the display nodes.
>
> Please excuse me for the spam for sending v3 soon after v2.
>
>
Applied, thanks!
[2/4] arm64: dts: qcom: sc8180x: drop legacy property #stream-id-cells
commit: 7fb5680b589d5eae64ada1d917b6ff2dab82f5ae
[3/4] arm64: dts: qcom: sc8180x: Drop flags for mdss irqs
commit: 580701ec27f61e0996dd5fcd23b091b6bf6933e3
[4/4] arm64: dts: qcom: sc8180x: add dp_p1 register blocks to DP nodes
commit: 1106ea2266d11ebd97c3493a0c36a45272bfb67a
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: ipq8074: Remove unused gpio from QPIC pins
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Paweł Owoc
Cc: Robert Marko, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240313102713.1727458-1-frut3k7@gmail.com>
On Wed, 13 Mar 2024 11:27:06 +0100, Paweł Owoc wrote:
> gpio16 will only be used for LCD support, as its NAND/LCDC data[8]
> so its bit 9 of the parallel QPIC interface, and ONFI NAND is only 8
> or 16-bit with only 8-bit one being supported in our case so that pin
> is unused.
>
> It should be dropped from the default NAND pinctrl configuration
> as its unused and only needed for LCD.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: ipq8074: Remove unused gpio from QPIC pins
commit: 5f78d9213ae753e2242b0f6a5d4a5e98e55ddc76
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: msm8998-yoshino: Enable RGB led
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio
Cc: Marijn Suijten, linux-arm-msm, devicetree, linux-kernel,
Sebastian Raase, Konrad Dybcio
In-Reply-To: <20240316-topic-maple_led-v1-1-ca3430fd9dc5@linaro.org>
On Sat, 16 Mar 2024 13:10:46 +0100, Konrad Dybcio wrote:
> Add the multicolor description and enable the PMI8998 LPG to expose the
> RGB notification LED.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: msm8998-yoshino: Enable RGB led
commit: 7c2a774f028f6e2acc40bf969fcac288d3143c7f
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: apq8016-sbc: correct GPIO LEDs node names
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski
Cc: Sumit Garg
In-Reply-To: <20240314112657.167006-1-krzysztof.kozlowski@linaro.org>
On Thu, 14 Mar 2024 12:26:57 +0100, Krzysztof Kozlowski wrote:
> Individual LEDs in a GPIO LEDs device node are not addressable, thus
> unit address is not correct.
>
> dtc is also not happy:
>
> Warning (unit_address_vs_reg): /leds/led@5: node has a unit name, but no reg or ranges property
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: apq8016-sbc: correct GPIO LEDs node names
commit: 216e62744b91c9716228fe13f564e83381a1342e
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: pm6150: correct Type-C compatible
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Dmitry Baryshkov, Danila Tikhonov,
linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20240328074544.5076-1-krzysztof.kozlowski@linaro.org>
On Thu, 28 Mar 2024 08:45:44 +0100, Krzysztof Kozlowski wrote:
> The first part of the compatible of Type-C node misses ending quote,
> thus we have one long compatible consisting of two compatible strings
> leading to dtbs_check warnings:
>
> sc7180-idp.dtb: usb-vbus-regulator@1100: compatible:0: 'qcom,pm6150-vbus-reg,\n qcom,pm8150b-vbus-reg' does not match '^[a-zA-Z0-9][a-zA-Z0-9,+\\-._/]+$'
> sc7180-idp.dtb: /soc@0/spmi@c440000/pmic@0/usb-vbus-regulator@1100: failed to match any schema with compatible: ['qcom,pm6150-vbus-reg,\n qcom,pm8150b-vbus-reg']
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: pm6150: correct Type-C compatible
commit: 5582e357d0c6bfdc889773ca3c9b7b0dd31dc334
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: msm8998-yoshino: fix volume-up key
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Sebastian Raase
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
AngeloGioacchino Del Regno, Marijn Suijten, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20240315225237.1616550-1-linux@sraa.de>
On Fri, 15 Mar 2024 23:52:29 +0100, Sebastian Raase wrote:
> The volume-up key is connected to gpio6 on yoshino.
> Fix button node ordering while at it.
> Disable pm8998_resin, since it is now unused.
>
> Tested on maple and lilac.
>
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: msm8998-yoshino: fix volume-up key
commit: 83ef6a5afc1d5e2270797a164972a3de3bd2ea52
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: qcom: sdm630-nile: add pinctrl for camera key
From: Bjorn Andersson @ 2024-04-04 21:23 UTC (permalink / raw)
To: Sebastian Raase
Cc: marijn.suijten, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240315085934.1511722-1-linux@sraa.de>
On Fri, 15 Mar 2024 09:59:25 +0100, Sebastian Raase wrote:
> Add pinctrl configuration for gpio-keys. Without this,
> camera button half-presses are not detected.
>
> Tested on discovery and pioneer.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: sdm630-nile: add pinctrl for camera key
commit: 0fba148c3ac0fb8bc3d2a788c19b2ede4e5d3695
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH 0/2] Add Inline Crypto Engine for SC7280 UFS
From: Bjorn Andersson @ 2024-04-04 21:23 UTC (permalink / raw)
To: Konrad Dybcio, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, cros-qcom-dts-watchers,
Luca Weiss
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <20240313-sc7280-ice-v1-0-3fa089fb7a27@fairphone.com>
On Wed, 13 Mar 2024 13:53:13 +0100, Luca Weiss wrote:
> Add the required bits to support Inline Crypto Engine on SC7280 SoC with
> UFS.
>
>
Applied, thanks!
[2/2] arm64: dts: qcom: sc7280: Add inline crypto engine
commit: dfd5ee7b34bb7611d4d2f4f3cb37152baeaae96d
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v2 0/3] Split sony-castor into shinano-common and add Sony Xperia Z3
From: Bjorn Andersson @ 2024-04-04 21:23 UTC (permalink / raw)
To: ~postmarketos/upstreaming, phone-devel, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Luca Weiss
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20240314-shinano-common-v2-0-a0fce1c72c74@z3ntu.xyz>
On Thu, 14 Mar 2024 19:56:21 +0100, Luca Weiss wrote:
> Prepare for adding sony-leo dts by splitting common parts into a
> separate dtsi file.
>
> Then add the dts for Sony Xperia Z3.
>
> Depends on:
> https://lore.kernel.org/linux-arm-msm/20240306-castor-changes-v1-0-2286eaf85fff@z3ntu.xyz/T/
>
> [...]
Applied, thanks!
[1/3] ARM: dts: qcom: msm8974-sony-castor: Split into shinano-common
commit: 53426f53eda5e4a17197a8bc7dd1045601db407e
[3/3] ARM: dts: qcom: Add Sony Xperia Z3 smartphone
commit: 8d91a5a4a6f5aff714a14ac4a86931aa789655d8
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8650: fix usb interrupts properties
From: Bjorn Andersson @ 2024-04-04 21:23 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong
Cc: linux-arm-msm, devicetree, linux-kernel, Krishna Kurapati
In-Reply-To: <20240314-topic-sm8650-upstream-usb-dt-irq-fix-v1-1-ea8ab2051869@linaro.org>
On Thu, 14 Mar 2024 09:53:06 +0100, Neil Armstrong wrote:
> Update the usb interrupts properties to fix the following
> bindings check errors:
> usb@a6f8800: interrupt-names:0: 'pwr_event' was expected
> from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml#
> usb@a6f8800: interrupt-names:1: 'hs_phy_irq' was expected
> from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml#
> usb@a6f8800: interrupt-names:2: 'dp_hs_phy_irq' was expected
> from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml#
> usb@a6f8800: interrupt-names:3: 'dm_hs_phy_irq' was expected
> from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml#
> usb@a6f8800: interrupt-names: ['hs_phy_irq', 'ss_phy_irq', 'dm_hs_phy_irq', 'dp_hs_phy_irq'] is too short
> from schema $id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml#
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: sm8650: fix usb interrupts properties
commit: 9f42f7380f6757ce7f0cab5bad56fb350941d32b
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v2 0/6] arm64: dts: qcom: qcs6490-rb3gen2: Enable two displays
From: Bjorn Andersson @ 2024-04-04 21:23 UTC (permalink / raw)
To: cros-qcom-dts-watchers, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Catalin Marinas, Will Deacon,
Dmitry Baryshkov, Bjorn Andersson
Cc: linux-arm-msm, devicetree, linux-kernel, linux-arm-kernel,
Douglas Anderson, Abhinav Kumar, Neil Armstrong,
Krishna Kurapati PSSNV
In-Reply-To: <20240326-rb3gen2-dp-connector-v2-0-a9f1bc32ecaf@quicinc.com>
On Tue, 26 Mar 2024 19:04:17 -0700, Bjorn Andersson wrote:
> RB3Gen2 is capable of producing DisplayPort output on a dedicated
> mini-DP connector and USB Type-C.
>
> Utilize Abel's work for DP vs eDP selection to allow configuring both
> controllers in DP-mode, then enable the two output paths.
>
> Tested by driving fbcon to 4k@60 + 4k@30 concurrently.
>
> [...]
Applied, thanks!
[6/6] arm64: defconfig: Enable sc7280 display and gpu clock controllers
commit: a97b6c42a7b823c429fac562a02d291b47b98d7e
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: qcs6490-rb3gen2: Enable UFS
From: Bjorn Andersson @ 2024-04-04 21:23 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240327-rb3gen2-ufs-v2-1-3de6b5dd78dd@quicinc.com>
On Wed, 27 Mar 2024 19:01:13 -0700, Bjorn Andersson wrote:
> The rb3gen2 has UFS memory, adjust the necessary supply voltage and add
> the controller and phy nodes to enable this.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: qcs6490-rb3gen2: Enable UFS
commit: 58dc9622d5de6ce0b80969b136e8e09a7645eca5
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox