* Re: [PATCH 5/6] iio: adc: ad7173: Remove index from temp channel
From: David Lechner @ 2024-04-01 19:40 UTC (permalink / raw)
To: dumitru.ceclan
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-iio,
devicetree, linux-kernel, Dumitru Ceclan
In-Reply-To: <20240401-ad4111-v1-5-34618a9cc502@analog.com>
On Mon, Apr 1, 2024 at 10:10 AM Dumitru Ceclan via B4 Relay
<devnull+dumitru.ceclan.analog.com@kernel.org> wrote:
>
> From: Dumitru Ceclan <dumitru.ceclan@analog.com>
>
> Temperature channel is unique per device, index is not needed.
>
> Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
> ---
This breaks userspace, so the commit message should explain why it is
safe to do this (e.g. driver hasn't reached mainline yet, so won't
break existing users since there are none).
^ permalink raw reply
* Re: [PATCH 4/6] iio: adc: ad7173: refactor ain and vref selection
From: David Lechner @ 2024-04-01 19:40 UTC (permalink / raw)
To: dumitru.ceclan
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-iio,
devicetree, linux-kernel, Dumitru Ceclan
In-Reply-To: <20240401-ad4111-v1-4-34618a9cc502@analog.com>
On Mon, Apr 1, 2024 at 10:10 AM Dumitru Ceclan via B4 Relay
<devnull+dumitru.ceclan.analog.com@kernel.org> wrote:
>
> From: Dumitru Ceclan <dumitru.ceclan@analog.com>
>
> Move validation of analog inputs and reference voltage selection to
> separate functions.
>
> Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
> ---
Same as my comment on PATCH 3/6. We would like to know why this change
is being made.
^ permalink raw reply
* Re: [PATCH 3/6] iio: adc: ad7173: refactor channel configuration parsing
From: David Lechner @ 2024-04-01 19:39 UTC (permalink / raw)
To: dumitru.ceclan
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-iio,
devicetree, linux-kernel, Dumitru Ceclan
In-Reply-To: <20240401-ad4111-v1-3-34618a9cc502@analog.com>
On Mon, Apr 1, 2024 at 10:10 AM Dumitru Ceclan via B4 Relay
<devnull+dumitru.ceclan.analog.com@kernel.org> wrote:
>
> From: Dumitru Ceclan <dumitru.ceclan@analog.com>
>
> Move configurations regarding number of channels from
> *_fw_parse_device_config to *_fw_parse_channel_config.
>
> Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
> ---
Commit messages need to explain _why_ the change is being made [1]. It
is not obvious to me why this needs to be moved.
[1]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#the-canonical-patch-format
^ permalink raw reply
* Re: [PATCH 2/6] iio: adc: ad7173: fix buffers enablement for ad7176-2
From: David Lechner @ 2024-04-01 19:38 UTC (permalink / raw)
To: dumitru.ceclan
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-iio,
devicetree, linux-kernel, Dumitru Ceclan
In-Reply-To: <20240401-ad4111-v1-2-34618a9cc502@analog.com>
On Mon, Apr 1, 2024 at 10:10 AM Dumitru Ceclan via B4 Relay
<devnull+dumitru.ceclan.analog.com@kernel.org> wrote:
>
> From: Dumitru Ceclan <dumitru.ceclan@analog.com>
>
> AD7176-2 does not feature input buffers, enable buffers only on
> supported models.
>
> Fixes: cff259bf7274 ("iio: adc: ad7173: fix buffers enablement for ad7176-2")
> Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
> ---
To be consistent with has_temp, maybe add `.has_input_buf = false,` to
ID_AD7176_2.
But either way:
Reviewed-by: David Lechner <dlechner@baylibre.com>
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: adc: ad7173: add support for ad411x
From: David Lechner @ 2024-04-01 19:37 UTC (permalink / raw)
To: dumitru.ceclan
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-iio,
devicetree, linux-kernel, Dumitru Ceclan
In-Reply-To: <20240401-ad4111-v1-1-34618a9cc502@analog.com>
On Mon, Apr 1, 2024 at 10:10 AM Dumitru Ceclan via B4 Relay
<devnull+dumitru.ceclan.analog.com@kernel.org> wrote:
>
> From: Dumitru Ceclan <dumitru.ceclan@analog.com>
>
> Add support for: AD4111, AD4112, AD4114, AD4115, AD4116.
>
> AD411x family ADCs support a VCOM pin, dedicated for single-ended usage.
> AD4111/AD4112 support current channels, usage is implemented by
> specifying channel reg values bigger than 15.
>
> Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
> ---
> .../devicetree/bindings/iio/adc/adi,ad7173.yaml | 59 +++++++++++++++++++++-
> 1 file changed, 57 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml
> index ea6cfcd0aff4..bba2de0a52f3 100644
> --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml
> @@ -19,7 +19,18 @@ description: |
> primarily for measurement of signals close to DC but also delivers
> outstanding performance with input bandwidths out to ~10kHz.
>
> + Analog Devices AD411x ADC's:
> + The AD411X family encompasses a series of low power, low noise, 24-bit,
> + sigma-delta analog-to-digital converters that offer a versatile range of
> + specifications. They integrate an analog front end suitable for processing
> + fully differential/single-ended and bipolar voltage inputs.
> +
> Datasheets for supported chips:
> + https://www.analog.com/media/en/technical-documentation/data-sheets/AD4111.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/AD4112.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/AD4114.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/AD4115.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/AD4116.pdf
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7172-2.pdf
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7172-4.pdf
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7173-8.pdf
> @@ -31,6 +42,11 @@ description: |
> properties:
> compatible:
> enum:
> + - adi,ad4111
> + - adi,ad4112
> + - adi,ad4114
> + - adi,ad4115
> + - adi,ad4116
> - adi,ad7172-2
> - adi,ad7172-4
> - adi,ad7173-8
> @@ -125,10 +141,19 @@ patternProperties:
>
> properties:
> reg:
> + description:
> + Reg values 16-19 are only permitted for ad4111/ad4112 current channels.
> minimum: 0
> - maximum: 15
> + maximum: 19
This looks wrong. Isn't reg describing the number of logical channels
(# of channel config registers)?
After reviewing the driver, I see that > 16 is used as a way of
flagging current inputs, but still seems like the wrong way to do it.
See suggestion below.
>
> diff-channels:
> + description:
> + For using current channels specify only the positive channel.
> + (IIN2+, IIN2−) -> diff-channels = <2 0>
I find this a bit confusing since 2 is already VIN2 and 0 is already
VIN0. I think it would make more sense to assign unique channel
numbers individually to the negative and positive current inputs.
Also, I think it makes sense to use the same numbers that the
registers in the datasheet use (8 - 11 for negative and 12 to 15 for
positive).
So: (IIN2+, IIN2−) -> diff-channels = <13 10>
> +
> + Family AD411x supports a dedicated VCOM voltage input.
> + To select it set the second channel to 16.
> + (VIN2, VCOM) -> diff-channels = <2 16>
The 411x datasheets call this pin VINCOM so calling it VCOM here is a
bit confusing.
Also, do we need to add a vincom-supply to get this voltage? Or is it
safe to assume it is always connected to AVSS? The datasheet seems to
indicate that the latter is the case. But then it also has this
special case (at least for AD4116, didn't check all datasheets)
"VIN10, VINCOM (single-ended or differential pair)". If it can be used
as part of a fully differential input, we probably need some extra
flag to indicate that case.
Similarly, do we need special handling for ADCIN15 on AD4116? It has a
"(pseudo differential or differential pair)" notation that other
inputs don't. In other words, it is more like VINCOM than it is to the
other ADCINxx pins. So we probably need an adcin15-supply for this pin
to properly get the right channel configuration. I.e. the logic in the
IIO driver would be if adcin15-supply is present, any channels that
use this input are pseudo-differential, otherwise any channels that
use it are fully differential.
> items:
> minimum: 0
> maximum: 31
> @@ -166,7 +191,6 @@ allOf:
> - $ref: /schemas/spi/spi-peripheral-props.yaml#
>
> # Only ad7172-4, ad7173-8 and ad7175-8 support vref2
> - # Other models have [0-3] channel registers
Did you forget to remove
reg:
maximum: 3
from this if statement that this comment is referring to?
> - if:
> properties:
> compatible:
> @@ -187,6 +211,37 @@ allOf:
> - vref
> - refout-avss
> - avdd
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - adi,ad4114
> + - adi,ad4115
> + - adi,ad4116
> + - adi,ad7173-8
> + - adi,ad7175-8
> + then:
> + patternProperties:
> + "^channel@[0-9a-f]$":
> + properties:
> + reg:
> + maximum: 15
As with the previous reg comment, this if statement should not be
needed since maximum should not be changed to 19.
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - adi,ad7172-2
> + - adi,ad7175-2
> + - adi,ad7176-2
> + - adi,ad7177-2
> + then:
> + patternProperties:
> + "^channel@[0-9a-f]$":
> + properties:
> reg:
> maximum: 3
It looks to me like AD7172-4 actually has 8 possible channels rather
than 16. So it would need a special condition as well. But that is a
bug in the previous bindings and should therefore be fixed in a
separate patch.
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: sc7180: Fix UFS PHY clocks
From: Dmitry Baryshkov @ 2024-04-01 19:28 UTC (permalink / raw)
To: Danila Tikhonov
Cc: andersson, konrad.dybcio, vkoul, kishon, robh,
krzysztof.kozlowski+dt, conor+dt, cros-qcom-dts-watchers,
manivannan.sadhasivam, davidwronek, linux-arm-msm, linux-phy,
devicetree, linux-kernel
In-Reply-To: <20240401182240.55282-3-danila@jiaxyga.com>
On Mon, 1 Apr 2024 at 21:23, Danila Tikhonov <danila@jiaxyga.com> wrote:
>
> QMP PHY used in SC7180 requires 3 clocks:
>
> * ref - 19.2MHz reference clock from RPMh
> * ref_aux - Auxiliary reference clock from GCC
> * qref - QREF clock from GCC
>
> While at it, let's move 'clocks' property before 'clock-names' to match
> the style used commonly.
>
> Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
> ---
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v6 RESEND 4/4] arm64: dts: qcom: aim300: add AIM300 AIoT
From: Dmitry Baryshkov @ 2024-04-01 19:22 UTC (permalink / raw)
To: Tengfei Fan
Cc: andersson, konrad.dybcio, robh, krzysztof.kozlowski+dt, conor+dt,
keescook, tony.luck, gpiccoli, linux-arm-msm, devicetree,
linux-kernel, linux-hardening, kernel, Qiang Yu, Ziyue Zhang
In-Reply-To: <20240401093843.2591147-5-quic_tengfan@quicinc.com>
On Mon, 1 Apr 2024 at 12:40, Tengfei Fan <quic_tengfan@quicinc.com> wrote:
>
> Add AIM300 AIoT Carrier board DTS support, including usb, UART, PCIe,
> I2C functions support.
> Here is a diagram of AIM300 AIoT Carrie Board and SoM
> +--------------------------------------------------+
> | AIM300 AIOT Carrie Board |
> | |
> | +-----------------+ |
> |power----->| Fixed regulator |---------+ |
> | +-----------------+ | |
> | | |
> | v VPH_PWR |
> | +----------------------------------------------+ |
> | | AIM300 SOM | | |
> | | |VPH_PWR | |
> | | v | |
> | | +-------+ +--------+ +------+ | |
> | | | UFS | | QCS8550| |PMIC | | |
> | | +-------+ +--------+ +------+ | |
> | | | |
> | +----------------------------------------------+ |
> | |
> | +----+ +------+ |
> | |USB | | UART | |
> | +----+ +------+ |
> +--------------------------------------------------+
>
> Co-developed-by: Qiang Yu <quic_qianyu@quicinc.com>
> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
> Co-developed-by: Ziyue Zhang <quic_ziyuzhan@quicinc.com>
> Signed-off-by: Ziyue Zhang <quic_ziyuzhan@quicinc.com>
> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> .../boot/dts/qcom/qcs8550-aim300-aiot.dts | 384 ++++++++++++++++++
> 2 files changed, 385 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 7d40ec5e7d21..02d9bc3bfce7 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -96,6 +96,7 @@ dtb-$(CONFIG_ARCH_QCOM) += qcm6490-idp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-1000.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-4000.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qrb2210-rb1.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qrb4210-rb2.dtb
> diff --git a/arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts b/arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
> new file mode 100644
> index 000000000000..8188766c3d84
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs8550-aim300-aiot.dts
> @@ -0,0 +1,384 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/leds/common.h>
> +#include "qcs8550-aim300.dtsi"
> +#include "pm8010.dtsi"
> +#include "pmr735d_a.dtsi"
> +#include "pmr735d_b.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. QCS8550 AIM300 AIOT";
> + compatible = "qcom,qcs8550-aim300-aiot", "qcom,qcs8550-aim300", "qcom,qcs8550",
> + "qcom,sm8550";
> +
> + aliases {
> + serial0 = &uart7;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + pinctrl-0 = <&volume_up_n>;
> + pinctrl-names = "default";
> +
> + key-volume-up {
> + label = "Volume Up";
> + debounce-interval = <15>;
> + gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
> + linux,code = <KEY_VOLUMEUP>;
> + linux,can-disable;
> + wakeup-source;
> + };
> + };
> +
> + pmic-glink {
> + compatible = "qcom,sm8550-pmic-glink", "qcom,pmic-glink";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + orientation-gpios = <&tlmm 11 GPIO_ACTIVE_HIGH>;
> +
> + connector@0 {
> + compatible = "usb-c-connector";
> + reg = <0>;
> + power-role = "dual";
> + data-role = "dual";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + pmic_glink_hs_in: endpoint {
> + remote-endpoint = <&usb_1_dwc3_hs>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + pmic_glink_ss_in: endpoint {
> + remote-endpoint = <&redriver_ss_out>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + pmic_glink_sbu: endpoint {
> + remote-endpoint = <&fsa4480_sbu_mux>;
> + };
> + };
> + };
> + };
> + };
> +
> + vph_pwr: regulator-vph-pwr {
> + compatible = "regulator-fixed";
> + regulator-name = "vph_pwr";
> + regulator-min-microvolt = <3700000>;
> + regulator-max-microvolt = <3700000>;
> +
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +};
> +
> +&apps_rsc {
> + regulators-0 {
> + vdd-bob1-supply = <&vph_pwr>;
> + vdd-bob2-supply = <&vph_pwr>;
> + };
> +
> + regulators-3 {
> + vdd-s4-supply = <&vph_pwr>;
> + vdd-s5-supply = <&vph_pwr>;
> + };
> +
> + regulators-4 {
> + vdd-s4-supply = <&vph_pwr>;
> + };
> +
> + regulators-5 {
> + vdd-s1-supply = <&vph_pwr>;
> + vdd-s2-supply = <&vph_pwr>;
> + vdd-s3-supply = <&vph_pwr>;
> + vdd-s4-supply = <&vph_pwr>;
> + vdd-s5-supply = <&vph_pwr>;
> + vdd-s6-supply = <&vph_pwr>;
> + };
> +};
> +
> +&i2c_hub_2 {
> + status = "okay";
> +
> + typec-mux@42 {
> + compatible = "fcs,fsa4480";
> + reg = <0x42>;
> +
> + vcc-supply = <&vreg_bob1>;
> +
> + mode-switch;
> + orientation-switch;
> +
> + port {
> + fsa4480_sbu_mux: endpoint {
> + remote-endpoint = <&pmic_glink_sbu>;
> + };
> + };
> + };
> +
> + typec-retimer@1c {
> + compatible = "onnn,nb7vpq904m";
> + reg = <0x1c>;
> +
> + vcc-supply = <&vreg_l15b_1p8>;
> +
> + orientation-switch;
> + retimer-switch;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + redriver_ss_out: endpoint {
> + remote-endpoint = <&pmic_glink_ss_in>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + redriver_ss_in: endpoint {
> + data-lanes = <3 2 1 0>;
> + remote-endpoint = <&usb_dp_qmpphy_out>;
> + };
> + };
> + };
> + };
> +};
> +
> +&mdss_dsi0 {
> + vdda-supply = <&vreg_l3e_1p2>;
Is this wired on the carrier board or on the AIC300 SoM?
> + status = "okay";
> +
> + panel@0 {
> + compatible = "visionox,vtdr6130";
> + reg = <0>;
> +
> + pinctrl-0 = <&dsi_active>, <&te_active>;
> + pinctrl-1 = <&dsi_suspend>, <&te_suspend>;
> + pinctrl-names = "default", "sleep";
> +
> + reset-gpios = <&tlmm 133 GPIO_ACTIVE_LOW>;
> +
> + vci-supply = <&vreg_l13b_3p0>;
> + vdd-supply = <&vreg_l11b_1p2>;
> + vddio-supply = <&vreg_l12b_1p8>;
> +
> + port {
> + panel0_in: endpoint {
> + remote-endpoint = <&mdss_dsi0_out>;
> + };
> + };
> + };
> +};
> +
> +&mdss_dsi0_out {
> + remote-endpoint = <&panel0_in>;
> + data-lanes = <0 1 2 3>;
> +};
> +
> +&mdss_dsi0_phy {
> + vdds-supply = <&vreg_l1e_0p88>;
This too
> + status = "okay";
> +};
> +
> +&pcie0 {
> + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
And this
> +
> + pinctrl-0 = <&pcie0_default_state>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +};
> +
> +&pcie0_phy {
> + vdda-phy-supply = <&vreg_l1e_0p88>;
> + vdda-pll-supply = <&vreg_l3e_1p2>;
You guess the question. I think I'll stop here. Please review your
changes here, which are really specific to the carrier board and which
apply to the SoM.
> +
> + status = "okay";
> +};
> +
> +&pcie_1_phy_aux_clk {
> + clock-frequency = <1000>;
> +};
> +
> +&pcie1 {
> + perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
> +
> + pinctrl-0 = <&pcie1_default_state>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +};
> +
> +&pcie1_phy {
> + vdda-phy-supply = <&vreg_l3c_0p9>;
> + vdda-pll-supply = <&vreg_l3e_1p2>;
> + vdda-qref-supply = <&vreg_l1e_0p88>;
> +
> + status = "okay";
> +};
> +
> +&pm8550_gpios {
> + volume_up_n: volume-up-n-state {
> + pins = "gpio6";
> + function = "normal";
> + power-source = <1>;
> + bias-pull-up;
> + input-enable;
> + };
> +};
> +
> +&pm8550b_eusb2_repeater {
> + vdd18-supply = <&vreg_l15b_1p8>;
> + vdd3-supply = <&vreg_l5b_3p1>;
> +};
> +
> +
> +&pon_pwrkey {
> + status = "okay";
> +};
> +
> +&pon_resin {
> + linux,code = <KEY_VOLUMEDOWN>;
> +
> + status = "okay";
> +};
> +
> +&qupv3_id_0 {
> + status = "okay";
> +};
> +
> +&remoteproc_adsp {
> + firmware-name = "qcom/qcs8550/adsp.mbn",
> + "qcom/qcs8550/adsp_dtbs.elf";
> + status = "okay";
> +};
> +
> +&remoteproc_cdsp {
> + firmware-name = "qcom/qcs8550/cdsp.mbn",
> + "qcom/qcs8550/cdsp_dtbs.elf";
> + status = "okay";
> +};
> +
> +&sleep_clk {
> + clock-frequency = <32000>;
> +};
> +
> +&swr1 {
> + status = "okay";
> +};
> +
> +&swr2 {
> + status = "okay";
> +};
> +
> +&tlmm {
> + gpio-reserved-ranges = <32 8>;
> +
> + dsi_active: dsi-active-state {
> + pins = "gpio133";
> + function = "gpio";
> + drive-strength = <8>;
> + bias-disable;
> + };
> +
> + dsi_suspend: dsi-suspend-state {
> + pins = "gpio133";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-pull-down;
> + };
> +
> + te_active: te-active-state {
> + pins = "gpio86";
> + function = "mdp_vsync";
> + drive-strength = <2>;
> + bias-pull-down;
> + };
> +
> + te_suspend: te-suspend-state {
> + pins = "gpio86";
> + function = "mdp_vsync";
> + drive-strength = <2>;
> + bias-pull-down;
> + };
> +};
> +
> +&uart7 {
> + status = "okay";
> +};
> +
> +&usb_1 {
> + status = "okay";
> +};
> +
> +&usb_1_dwc3 {
> + dr_mode = "otg";
> + usb-role-switch;
> +};
> +
> +&usb_1_dwc3_hs {
> + remote-endpoint = <&pmic_glink_hs_in>;
> +};
> +
> +&usb_1_dwc3_ss {
> + remote-endpoint = <&usb_dp_qmpphy_usb_ss_in>;
> +};
> +
> +&usb_1_hsphy {
> + phys = <&pm8550b_eusb2_repeater>;
> +
> + vdd-supply = <&vreg_l1e_0p88>;
> + vdda12-supply = <&vreg_l3e_1p2>;
> +
> + status = "okay";
> +};
> +
> +&usb_dp_qmpphy {
> + vdda-phy-supply = <&vreg_l3e_1p2>;
> + vdda-pll-supply = <&vreg_l3f_0p88>;
> +
> + orientation-switch;
> +
> + status = "okay";
> +};
> +
> +&usb_dp_qmpphy_out {
> + remote-endpoint = <&redriver_ss_in>;
> +};
> +
> +&usb_dp_qmpphy_usb_ss_in {
> + remote-endpoint = <&usb_1_dwc3_ss>;
> +};
> +
> +&xo_board {
> + clock-frequency = <76800000>;
> +};
> --
> 2.25.1
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v6 RESEND 2/4] arm64: dts: qcom: qcs8550: introduce qcs8550 dtsi
From: Dmitry Baryshkov @ 2024-04-01 19:13 UTC (permalink / raw)
To: Tengfei Fan
Cc: andersson, konrad.dybcio, robh, krzysztof.kozlowski+dt, conor+dt,
keescook, tony.luck, gpiccoli, linux-arm-msm, devicetree,
linux-kernel, linux-hardening, kernel
In-Reply-To: <20240401093843.2591147-3-quic_tengfan@quicinc.com>
On Mon, 1 Apr 2024 at 12:40, Tengfei Fan <quic_tengfan@quicinc.com> wrote:
>
> QCS8550 is derived from SM8550. The differnece between SM8550 and
> QCS8550 is QCS8550 doesn't have modem RF system. QCS8550 is mainly used
> in IoT scenarios.
> QCS8550 firmware has different memory map with SM8550 firmware. The
> memory map will be runtime added through bootloader.
> There are 3 types of reserved memory regions here:
> 1. Firmware related regions which aren't shared with kernel.
> The device tree source in kernel doesn't need to have node to indicate
> the firmware related reserved information. OS bootloader conveys the
> information by update device tree in runtime.
> This will be described as: UEFI saves the physical address of the
> UEFI System Table to dts file's chosen node. Kernel read this table and
> add reserved memory regions to efi config table. Current reserved memory
> region may have reserved region which was not yet used, release note of
> the firmware have such kind of information.
> 2. Firmware related memory regions which are shared with Kernel
> Each region has a specific node with specific label name for later
> phandle reference from other driver dt node.
> 3. PIL regions.
> PIL regions will be reserved and then assigned to subsystem firmware
> later.
> Here is a reserved memory map for this platform:
> 0x100000000 +------------------+
> | |
> | Firmware Related |
> | |
> 0xd4d00000 +------------------+
> | |
> | Kernel Available |
> | |
> 0xa7000000 +------------------+
> | |
> | PIL Region |
> | |
> 0x8a800000 +------------------+
> | |
> | Firmware Related |
> | |
> 0x80000000 +------------------+
> Note that:
> 0xa7000000..0xA8000000 is used by bootloader, when kernel boot up,
> it is available for kernel usage. This region is not suggested to be
> used by kernel features like ramoops, suspend resume etc.
>
> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
> ---
> arch/arm64/boot/dts/qcom/qcs8550.dtsi | 169 ++++++++++++++++++++++++++
> 1 file changed, 169 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/qcs8550.dtsi
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Minor nit below.
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs8550.dtsi b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
> new file mode 100644
> index 000000000000..a3ebf3d4e16d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
> @@ -0,0 +1,169 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include "sm8550.dtsi"
> +
> +/delete-node/ &reserved_memory;
> +
> +/ {
> + reserved_memory: reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> +
> + /* These are 3 types of reserved memory regions here:
> + * 1. Firmware related regions which aren't shared with kernel.
> + * The device tree source in kernel doesn't need to have node to
> + * indicate the firmware related reserved information. OS bootloader
> + * conveys the information by update device tree in runtime.
> + * This will be described as: UEFI saves the physical address of
> + * the UEFI System Table to dts file's chosen node. Kernel read this
> + * table and add reserved memory regions to efi config table. Current
> + * reserved memory region may have reserved region which was not yet
> + * used, release note of the firmware have such kind of information.
> + * 2. Firmware related memory regions which are shared with Kernel.
> + * Each region has a specific node with specific label name for
> + * later phandle reference from other driver dt node.
> + * 3. PIL regions.
> + * PIL regions will be reserved and then assigned to subsystem
> + * firmware later.
> + * Here is a reserved memory map for this platform:
> + * 0x100000000 +------------------+
> + * | |
> + * | Firmware Related |
> + * | |
> + * 0xd4d00000 +------------------+
> + * | |
> + * | Kernel Available |
> + * | |
> + * 0xa7000000 +------------------+
> + * | |
> + * | PIL Region |
> + * | |
> + * 0x8a800000 +------------------+
> + * | |
> + * | Firmware Related |
> + * | |
> + * 0x80000000 +------------------+
> + * Note that:
> + * 0xa7000000..0xA8000000 is used by bootloader, when kernel boot up,
> + * it is available for kernel usage. This region is not suggested to
> + * be used by kernel features like ramoops, suspend resume etc.
> + */
> +
> + /*
> + * Firmware related regions, bootlader will possible reserve parts of
> + * region from 0x80000000..0x8a800000.
> + */
> + aop_image_mem: aop-image-region@81c00000 {
> + reg = <0x0 0x81c00000 0x0 0x60000>;
> + no-map;
> + };
> +
> + aop_cmd_db_mem: aop-cmd-db-region@81c60000 {
> + compatible = "qcom,cmd-db";
> + reg = <0x0 0x81c60000 0x0 0x20000>;
> + no-map;
> + };
> +
> + aop_config_mem: aop-config-region@81c80000 {
> + no-map;
> + reg = <0x0 0x81c80000 0x0 0x20000>;
> + };
> +
> + smem_mem: smem-region@81d00000 {
> + compatible = "qcom,smem";
> + reg = <0x0 0x81d00000 0x0 0x200000>;
> + hwlocks = <&tcsr_mutex 3>;
> + no-map;
> + };
> +
> + adsp_mhi_mem: adsp-mhi-region@81f00000 {
> + reg = <0x0 0x81f00000 0x0 0x20000>;
> + no-map;
> + };
> +
> + /* PIL region */
> + mpss_mem: mpss-region@8a800000 {
> + reg = <0x0 0x8a800000 0x0 0x10800000>;
> + no-map;
> + };
> +
> + q6_mpss_dtb_mem: q6-mpss-dtb-region@9b000000 {
> + reg = <0x0 0x9b000000 0x0 0x80000>;
> + no-map;
> + };
> +
> + ipa_fw_mem: ipa-fw-region@9b080000 {
> + reg = <0x0 0x9b080000 0x0 0x10000>;
> + no-map;
> + };
> +
> + ipa_gsi_mem: ipa-gsi-region@9b090000 {
> + reg = <0x0 0x9b090000 0x0 0xa000>;
> + no-map;
> + };
> +
> + gpu_micro_code_mem: gpu-micro-code-region@9b09a000 {
> + reg = <0x0 0x9b09a000 0x0 0x2000>;
> + no-map;
> + };
> +
> + spss_region_mem: spss-region@9b100000 {
> + reg = <0x0 0x9b100000 0x0 0x180000>;
> + no-map;
> + };
> +
> + spu_secure_shared_memory_mem: spu-secure-shared-memory-region@9b280000 {
> + reg = <0x0 0x9b280000 0x0 0x80000>;
> + no-map;
> + };
> +
> + camera_mem: camera-region@9b300000 {
> + reg = <0x0 0x9b300000 0x0 0x800000>;
> + no-map;
> + };
> +
> + video_mem: video-region@9bb00000 {
> + reg = <0x0 0x9bb00000 0x0 0x700000>;
> + no-map;
> + };
> +
> + cvp_mem: cvp-region@9c200000 {
> + reg = <0x0 0x9c200000 0x0 0x700000>;
> + no-map;
> + };
> +
> + cdsp_mem: cdsp-region@9c900000 {
> + reg = <0x0 0x9c900000 0x0 0x2000000>;
> + no-map;
> + };
> +
> + q6_cdsp_dtb_mem: q6-cdsp-dtb-region@9e900000 {
> + reg = <0x0 0x9e900000 0x0 0x80000>;
> + no-map;
> + };
> +
> + q6_adsp_dtb_mem: q6-adsp-dtb-region@9e980000 {
> + reg = <0x0 0x9e980000 0x0 0x80000>;
> + no-map;
> + };
> +
> + adspslpi_mem: adspslpi-region@9ea00000 {
> + reg = <0x0 0x9ea00000 0x0 0x4080000>;
> + no-map;
> + };
> +
> + /*
> + * Firmware related regions, bootlader will possible reserve parts of
Nit: bootloader will possibly...
> + * region from 0xd8000000..0x100000000.
> + */
> + mpss_dsm_mem: mpss_dsm_region@d4d00000 {
> + reg = <0x0 0xd4d00000 0x0 0x3300000>;
> + no-map;
> + };
> + };
> +};
> --
> 2.25.1
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 3/3] drm: panel: Add LG sw43408 panel driver
From: Dmitry Baryshkov @ 2024-04-01 19:11 UTC (permalink / raw)
To: Marijn Suijten
Cc: Sumit Semwal, Caleb Connolly, Neil Armstrong, Jessica Zhang,
Sam Ravnborg, David Airlie, Daniel Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, dri-devel, devicetree,
linux-kernel, linux-arm-msm, Vinod Koul, Caleb Connolly
In-Reply-To: <fn3r4ykwxvgf4ujmpevpsrcwmwzpjl5bhcp6ekyebowgf4rpz3@fyxcwjgn6abg>
On Mon, 1 Apr 2024 at 13:29, Marijn Suijten
<marijn.suijten@somainline.org> wrote:
>
> On 2024-03-30 16:37:08, Dmitry Baryshkov wrote:
> > On Sat, 30 Mar 2024 at 12:27, Marijn Suijten
> > <marijn.suijten@somainline.org> wrote:
> > >
> > > On 2024-03-30 05:59:30, Dmitry Baryshkov wrote:
> > > > From: Sumit Semwal <sumit.semwal@linaro.org>
> > > >
> > > > LG SW43408 is 1080x2160, 4-lane MIPI-DSI panel, used in some Pixel3
> > > > phones.
> > > >
> > > > Whatever init sequence we have for this panel isn't capable of
> > > > initialising it completely, toggling the reset gpio ever causes the
> > > > panel to die. Until this is resolved we avoid resetting the panel. The
> > >
> > > Are you sure it is avoided? This patch seems to be toggling reset_gpio in
> > > sw43408_prepare()?
> > >
> > > > disable/unprepare functions only put the panel to sleep mode and
> > > > disable the backlight.
> > > >
> > > > Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
> > > > [vinod: Add DSC support]
> > > > Signed-off-by: Vinod Koul <vkoul@kernel.org>
> > > > [caleb: cleanup and support turning off the panel]
> > > > Signed-off-by: Caleb Connolly <caleb@connolly.tech>
> > > > [DB: partially rewrote the driver and fixed DSC programming]
> > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > > ---
> > > > MAINTAINERS | 8 +
> > > > drivers/gpu/drm/panel/Kconfig | 11 ++
> > > > drivers/gpu/drm/panel/Makefile | 1 +
> > > > drivers/gpu/drm/panel/panel-lg-sw43408.c | 322 +++++++++++++++++++++++++++++++
> > > > 4 files changed, 342 insertions(+)
> > > >
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index 4b511a55101c..f4cf7ee97376 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -6755,6 +6755,14 @@ S: Maintained
> > > > F: Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
> > > > F: drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> > > >
> > > > +DRM DRIVER FOR LG SW43408 PANELS
> > > > +M: Sumit Semwal <sumit.semwal@linaro.org>
> > > > +M: Caleb Connolly <caleb.connolly@linaro.org>
> > > > +S: Maintained
> > > > +T: git git://anongit.freedesktop.org/drm/drm-misc
> > > > +F: Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml
> > > > +F: drivers/gpu/drm/panel/panel-lg-sw43408.c
> > > > +
> > > > DRM DRIVER FOR LOGICVC DISPLAY CONTROLLER
> > > > M: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > > > S: Supported
> > > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > > > index d037b3b8b999..f94c702735cb 100644
> > > > --- a/drivers/gpu/drm/panel/Kconfig
> > > > +++ b/drivers/gpu/drm/panel/Kconfig
> > > > @@ -335,6 +335,17 @@ config DRM_PANEL_LG_LG4573
> > > > Say Y here if you want to enable support for LG4573 RGB panel.
> > > > To compile this driver as a module, choose M here.
> > > >
> > > > +config DRM_PANEL_LG_SW43408
> > > > + tristate "LG SW43408 panel"
> > > > + depends on OF
> > > > + depends on DRM_MIPI_DSI
> > > > + depends on BACKLIGHT_CLASS_DEVICE
> > > > + help
> > > > + Say Y here if you want to enable support for LG sw43408 panel.
> > > > + The panel has a 1080x2160 resolution and uses
> > > > + 24 bit RGB per pixel. It provides a MIPI DSI interface to
> > > > + the host and has a built-in LED backlight.
> > > > +
> > > > config DRM_PANEL_MAGNACHIP_D53E6EA8966
> > > > tristate "Magnachip D53E6EA8966 DSI panel"
> > > > depends on OF && SPI
> > > > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> > > > index f156d7fa0bcc..a75687d13caf 100644
> > > > --- a/drivers/gpu/drm/panel/Makefile
> > > > +++ b/drivers/gpu/drm/panel/Makefile
> > > > @@ -34,6 +34,7 @@ obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
> > > > obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
> > > > obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
> > > > obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
> > > > +obj-$(CONFIG_DRM_PANEL_LG_SW43408) += panel-lg-sw43408.o
> > > > obj-$(CONFIG_DRM_PANEL_MAGNACHIP_D53E6EA8966) += panel-magnachip-d53e6ea8966.o
> > > > obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
> > > > obj-$(CONFIG_DRM_PANEL_NEWVISION_NV3051D) += panel-newvision-nv3051d.o
> > > > diff --git a/drivers/gpu/drm/panel/panel-lg-sw43408.c b/drivers/gpu/drm/panel/panel-lg-sw43408.c
> > > > new file mode 100644
> > > > index 000000000000..365d25e14d54
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/panel/panel-lg-sw43408.c
> > > > @@ -0,0 +1,322 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > > > + * Copyright (C) 2019-2024 Linaro Ltd
> > > > + * Author: Sumit Semwal <sumit.semwal@linaro.org>
> > > > + * Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > > + */
> > > > +
> > > > +#include <linux/backlight.h>
> > > > +#include <linux/delay.h>
> > > > +#include <linux/gpio/consumer.h>
> > > > +#include <linux/module.h>
> > > > +#include <linux/of.h>
> > > > +#include <linux/regulator/consumer.h>
> > > > +
> > > > +#include <video/mipi_display.h>
> > > > +
> > > > +#include <drm/drm_mipi_dsi.h>
> > > > +#include <drm/drm_panel.h>
> > > > +#include <drm/drm_probe_helper.h>
> > > > +#include <drm/display/drm_dsc.h>
> > > > +#include <drm/display/drm_dsc_helper.h>
> > > > +
> > > > +#define NUM_SUPPLIES 2
> > > > +
> > > > +struct sw43408_panel {
> > > > + struct drm_panel base;
> > > > + struct mipi_dsi_device *link;
> > > > +
> > > > + const struct drm_display_mode *mode;
> > > > +
> > > > + struct regulator_bulk_data supplies[NUM_SUPPLIES];
> > > > +
> > > > + struct gpio_desc *reset_gpio;
> > > > +};
> > > > +
> > > > +static inline struct sw43408_panel *to_panel_info(struct drm_panel *panel)
> > > > +{
> > > > + return container_of(panel, struct sw43408_panel, base);
> > > > +}
> > > > +
> > > > +static int sw43408_unprepare(struct drm_panel *panel)
> > > > +{
> > > > + struct sw43408_panel *ctx = to_panel_info(panel);
> > > > + int ret;
> > > > +
> > > > + ret = mipi_dsi_dcs_set_display_off(ctx->link);
> > > > + if (ret < 0)
> > > > + dev_err(panel->dev, "set_display_off cmd failed ret = %d\n", ret);
> > > > +
> > > > + ret = mipi_dsi_dcs_enter_sleep_mode(ctx->link);
> > > > + if (ret < 0)
> > > > + dev_err(panel->dev, "enter_sleep cmd failed ret = %d\n", ret);
> > > > +
> > > > + msleep(100);
> > > > +
> > > > + gpiod_set_value(ctx->reset_gpio, 1);
> > > > +
> > > > + return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> > > > +}
> > > > +
> > > > +static int sw43408_program(struct drm_panel *panel)
> > > > +{
> > > > + struct sw43408_panel *ctx = to_panel_info(panel);
> > > > + struct drm_dsc_picture_parameter_set pps;
> > > > + u8 dsc_en = 0x11;
> > >
> > > Yeah, this is completely strange. Bit 0, 0x1, is to enable DSC which is
> > > normal. 0x10 however, which is bit 4, selects PPS table 2. Do you ever set
> > > pps_identifier in struct drm_dsc_picture_parameter_set to 2? Or is the table
> > > that you send below bogus and/or not used? Maybe the Driver IC on the other
> > > end of the DSI link has a default PPS table with identifier 2 that works out of
> > > the box?
> >
> > Note, MIPI standard also requires two bytes argument. I suspect that
> > LG didn't fully follow the standard here.
>
> Have you read this command from downstream DTS, or have you tried sending 2
> bytes and seen the panel breaking? The second byte is marked as reserved and
> should be equal to 0; if the Driver IC is okay with sending either 1 or 2 bytes
> I'd strive to stick with the defined length of 2 bytes for this DCS.
>
> Have you played around with the PPS table? What if you change
> drm_dsc_picture_paremeter_set::pps_identifier to the second table, will the
> panel stop working as expected again? This could indicate that the PPS that is
> sent is incorrect (even though the information in the original DSC config was
> enough to set up the DPU and DSI correctly).
>
> According to the DSI spec it is allowed to have a pre-stored/pre-programmed
> PPS table, which could be used here making the current call to
> mipi_dsi_picture_parameter_set() useless and "confusing"?
Ok, some short summary of my tests.
Skipping PPS doesn't work at all, so there is no default.
Adding a second zero byte doesn't seem to change anything. Dropping
the 0x1 bit ('enable') doesn't seem to change anything.
If I send COMPRESSION_MODE before sending the PPS, various combinations work.
If I send COMPRESSION_MODE after sending the PPS, the follow combos work:
pps_identifier = 0x0, COMPRESSION_MODE = 0x11
pps_identifier = 0x1, COMPRESSION_MODE = 0x21
>
> > Basically that's the reason why I went for the _raw function instead
> > of adding PPS and codec arguments to the existing function.
> >
> > >
> > > > + mipi_dsi_dcs_write_seq(ctx->link, MIPI_DCS_SET_GAMMA_CURVE, 0x02);
> > > > +
> > > > + mipi_dsi_dcs_set_tear_on(ctx->link, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
> > > > +
> > > > + mipi_dsi_dcs_write_seq(ctx->link, 0x53, 0x0c, 0x30);
> > > > + mipi_dsi_dcs_write_seq(ctx->link, 0x55, 0x00, 0x70, 0xdf, 0x00, 0x70, 0xdf);
> > > > + mipi_dsi_dcs_write_seq(ctx->link, 0xf7, 0x01, 0x49, 0x0c);
> > > > +
> > > > + mipi_dsi_dcs_exit_sleep_mode(ctx->link);
> > > > +
> > > > + msleep(135);
> > > > +
> > > > + mipi_dsi_compression_mode_raw(ctx->link, &dsc_en, 1);
> > >
> > > Even though I think we should change this function to describe the known
> > > bit layout of command 0x7 per the VESA DSI spec, for now replace 1 with
> > > sizeof(dsc_en)?
> >
> > If dsc_en were an array, it would have been a proper thing. Maybe I
> > should change it to the array to remove confusion.
>
> It should work even with a single byte, just to clarify to readers that the 3rd
> argument is the byte-size of the input.
>
> > > > + mipi_dsi_dcs_write_seq(ctx->link, 0xb0, 0xac);
> > > > + mipi_dsi_dcs_write_seq(ctx->link, 0xe5,
> > > > + 0x00, 0x3a, 0x00, 0x3a, 0x00, 0x0e, 0x10);
> > > > + mipi_dsi_dcs_write_seq(ctx->link, 0xb5,
> > > > + 0x75, 0x60, 0x2d, 0x5d, 0x80, 0x00, 0x0a, 0x0b,
> > > > + 0x00, 0x05, 0x0b, 0x00, 0x80, 0x0d, 0x0e, 0x40,
> > > > + 0x00, 0x0c, 0x00, 0x16, 0x00, 0xb8, 0x00, 0x80,
> > > > + 0x0d, 0x0e, 0x40, 0x00, 0x0c, 0x00, 0x16, 0x00,
> > > > + 0xb8, 0x00, 0x81, 0x00, 0x03, 0x03, 0x03, 0x01,
> > > > + 0x01);
> > > > + msleep(85);
> > > > + mipi_dsi_dcs_write_seq(ctx->link, 0xcd,
> > > > + 0x00, 0x00, 0x00, 0x19, 0x19, 0x19, 0x19, 0x19,
> > > > + 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19,
> > > > + 0x16, 0x16);
> > > > + mipi_dsi_dcs_write_seq(ctx->link, 0xcb, 0x80, 0x5c, 0x07, 0x03, 0x28);
> > > > + mipi_dsi_dcs_write_seq(ctx->link, 0xc0, 0x02, 0x02, 0x0f);
> > > > + mipi_dsi_dcs_write_seq(ctx->link, 0x55, 0x04, 0x61, 0xdb, 0x04, 0x70, 0xdb);
> > > > + mipi_dsi_dcs_write_seq(ctx->link, 0xb0, 0xca);
> > > > +
> > > > + mipi_dsi_dcs_set_display_on(ctx->link);
> > >
> > > Any specific reason to not have the (un)blanking sequence in the enable/disable
> > > callbacks and leaving display configuration in (un)prepare?
> >
> > We are back to the question on when it's fine to send the commands. I
> > think the current agreement is to send everything in the
> > prepare/unprepare, because of some strange hosts.
>
> For my panel drivers I'm sticking with having `post-on` commands (from
> downstream) in `enable/disable`, which is typically only `set_display_on`. In
> hopes of proposing a `prepare_atomic()` some time to allow mode selection.
>
> In a short test on recent -next I am once again allowed to send DSI commands in
> both .disable and .unprepare, making both functions a "clean" inverse of .enable
> and .prepare respectively.
The world isn't limited to the MSM hosts.
>
> > > > + msleep(50);
> > > > +
> > > > + ctx->link->mode_flags &= ~MIPI_DSI_MODE_LPM;
> > > > +
> > > > + drm_dsc_pps_payload_pack(&pps, ctx->link->dsc);
> > > > + mipi_dsi_picture_parameter_set(ctx->link, &pps);
> > >
> > > I'm always surprised why this is sent _after_ turning the display on (unblanking
> > > it). Wouldn't that cause unnecessary corruption?
> >
> > No idea. I followed the dowsntream command sequences here. Most likely
> > the panel is not fully on until it receives the full frame to be
> > displayed.
>
> According to the DSI spec a PPS update is allowed to happen every frame, and
> (for cmdmode panels) will take effect after the next TE trigger. Unsure if a TE
> event happens before the first frame, otherwise this may start taking effect
> on the second frame onwards only.
>
> If there's no corruption on the first frame there might be a pre-programmed PPS
> table in slot 2, supporting the theory above.
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v3] media: dt-bindings: ovti,ov2680: Document more properties
From: Fabio Estevam @ 2024-04-01 19:05 UTC (permalink / raw)
To: sakari.ailus
Cc: rmfrfs, laurent.pinchart, hansg, robh, krzysztof.kozlowski+dt,
conor+dt, linux-media, devicetree, Fabio Estevam
From: Fabio Estevam <festevam@denx.de>
OV2680 has a single data lane MIPI interface.
Document the clock-lanes and data-lanes properties to avoid
the following dt-schema warning:
imx7s-warp.dtb: camera@36: port:endpoint: Unevaluated properties are not allowed ('clock-lanes', 'data-lanes' were unexpected)
from schema $id: http://devicetree.org/schemas/media/i2c/ovti,ov2680.yaml#
While at it, also document the link-frequencies property as recommended
by the following document:
https://www.kernel.org/doc/html/v6.9-rc1/driver-api/media/camera-sensor.html#handling-clocks
Signed-off-by: Fabio Estevam <festevam@denx.de>
---
Changes since v2:
- Use additionalProperties: false (Laurent).
- Mark link-frequencies as mandatory. (Laurent).
.../bindings/media/i2c/ovti,ov2680.yaml | 25 ++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
index cf456f8d9ddc..6ae7d4457536 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
@@ -50,9 +50,29 @@ properties:
Definition of the regulator used as digital power supply.
port:
- $ref: /schemas/graph.yaml#/properties/port
description:
A node containing an output port node.
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ additionalProperties: false
+
+ properties:
+ clock-lanes:
+ const: 0
+
+ data-lanes:
+ const: 1
+
+ link-frequencies: true
+
+ remote-endpoint: true
+
+ required:
+ - link-frequencies
required:
- compatible
@@ -89,6 +109,9 @@ examples:
port {
ov2680_to_mipi: endpoint {
remote-endpoint = <&mipi_from_sensor>;
+ clock-lanes = <0>;
+ data-lanes = <1>;
+ link-frequencies = /bits/ 64 <330000000>;
};
};
};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 0/7] arm64: dts: qcom: fix description of the Type-C signals
From: Dmitry Baryshkov @ 2024-04-01 18:48 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Luca Weiss, Conor Dooley, Bjorn Andersson,
Bryan O'Donoghue, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio
In-Reply-To: <171198916314.1093638.15006189720750656914.robh@kernel.org>
On Mon, 1 Apr 2024 at 19:36, Rob Herring <robh@kernel.org> wrote:
>
>
> On Sun, 31 Mar 2024 06:48:50 +0300, Dmitry Baryshkov wrote:
> > Rename the HS link between usb-c-connector and the DWC3 USB controller.
> > Add missing graph connection between the QMP PHY and DWC3 USB
> > controller.
> >
> > Reported-by: Luca Weiss <luca.weiss@fairphone.com>
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > ---
> > Changes in v2:
> > - Fixed other platforms in addition to sm8250 (Bryan)
> > - Link to v1: https://lore.kernel.org/r/20240322-typec-fix-sm8250-v1-0-1ac22b333ea9@linaro.org
> >
> > ---
> > Dmitry Baryshkov (7):
> > arm64: dts: qcom: sm8250: describe HS signals properly
> > arm64: dts: qcom: sm8250: add a link between DWC3 and QMP PHY
> > arm64: dts: qcom: sc8180x: switch USB+DP QMP PHYs to new bindings
> > arm64: dts: qcom: sc8180x: describe USB signals properly
> > arm64: dts: qcom: sc8280xp: describe USB signals properly
> > arm64: dts: qcom: x1e80100: describe USB signals properly
> > arm64: dts: qcom: sm8150-hdk: rename Type-C HS endpoints
> >
> > arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 8 +-
> > .../arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts | 16 +-
> > arch/arm64/boot/dts/qcom/sc8180x-primus.dts | 20 +--
> > arch/arm64/boot/dts/qcom/sc8180x.dtsi | 164 ++++++++++-----------
> > arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 20 +--
> > .../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 20 +--
> > arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 54 ++++++-
> > arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 4 +-
> > .../boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi | 8 +-
> > arch/arm64/boot/dts/qcom/sm8250.dtsi | 24 ++-
> > arch/arm64/boot/dts/qcom/x1e80100.dtsi | 149 ++++++++++++++++++-
> > 11 files changed, 340 insertions(+), 147 deletions(-)
> > ---
> > base-commit: 13ee4a7161b6fd938aef6688ff43b163f6d83e37
> > change-id: 20240322-typec-fix-sm8250-33c47a03a056
> >
> > Best regards,
> > --
> > Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> >
> >
> >
>
>
> My bot found new DTB warnings on the .dts files added or changed in this
> series.
>
> Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
> are fixed by another series. Ultimately, it is up to the platform
> maintainer whether these warnings are acceptable or not. No need to reply
> unless the platform maintainer has comments.
>
> If you already ran DT checks and didn't see these error(s), then
> make sure dt-schema is up to date:
>
> pip3 install dtschema --upgrade
>
>
> New warnings running 'make CHECK_DTBS=y qcom/qrb5165-rb5.dtb qcom/sc8180x-lenovo-flex-5g.dtb qcom/sc8180x-primus.dtb qcom/sc8280xp-crd.dtb qcom/sc8280xp-lenovo-thinkpad-x13s.dtb qcom/sm8150-hdk.dtb' for 20240331-typec-fix-sm8250-v2-0-857acb6bd88e@linaro.org:
>
> arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dtb: clock-controller@af00000: clocks: [[41, 0], [42], [95, 1], [95, 2], [99, 1], [99, 2], [125, 0], [125, 1]] is too long
> from schema $id: http://devicetree.org/schemas/clock/qcom,dispcc-sm8x50.yaml#
> arch/arm64/boot/dts/qcom/sc8180x-primus.dtb: clock-controller@af00000: clocks: [[41, 0], [42], [97, 1], [97, 2], [101, 1], [101, 2], [127, 0], [127, 1]] is too long
> from schema $id: http://devicetree.org/schemas/clock/qcom,dispcc-sm8x50.yaml#
I don' t think it's new, it just had PHY indices changed. But let's
fix it anyway.
>
>
>
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH 0/2] phy: qcom-qmp-ufs: Fix PHY QMP clocks for SC7180
From: Danila Tikhonov @ 2024-04-01 18:22 UTC (permalink / raw)
To: andersson, konrad.dybcio, vkoul, kishon, robh,
krzysztof.kozlowski+dt, conor+dt, cros-qcom-dts-watchers,
manivannan.sadhasivam, davidwronek
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Danila Tikhonov
This series of patches is based on the series from Manivannan:
https://lore.kernel.org/all/20240131-ufs-phy-clock-v3-0-58a49d2f4605@linaro.org/
Patch from David adding a UFS nodes for SC7180(SM7125):
https://lore.kernel.org/all/20240121-sm7125-upstream-v4-6-f7d1212c8ebb@gmail.com/
The patch submitted by David and a series of patches submitted by Manivannan
were both applied at approximately the same time. As a result, David's patch
did not include this change.
To: Bjorn Andersson <andersson@kernel.org>
To: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Vinod Koul <vkoul@kernel.org>
To: Kishon Vijay Abraham I <kishon@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
To: Conor Dooley <conor+dt@kernel.org>
To: cros-qcom-dts-watchers@chromium.org
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: David Wronek <davidwronek@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-phy@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
Danila Tikhonov (2):
dt-bindings: phy: qmp-ufs: Fix PHY clocks for SC7180
arm64: dts: qcom: sc7180: Fix UFS PHY clocks
.../bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 1 +
arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 ++++++---
2 files changed, 7 insertions(+), 3 deletions(-)
--
2.44.0
^ permalink raw reply
* [PATCH 2/2] arm64: dts: qcom: sc7180: Fix UFS PHY clocks
From: Danila Tikhonov @ 2024-04-01 18:22 UTC (permalink / raw)
To: andersson, konrad.dybcio, vkoul, kishon, robh,
krzysztof.kozlowski+dt, conor+dt, cros-qcom-dts-watchers,
manivannan.sadhasivam, davidwronek
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Danila Tikhonov
In-Reply-To: <20240401182240.55282-1-danila@jiaxyga.com>
QMP PHY used in SC7180 requires 3 clocks:
* ref - 19.2MHz reference clock from RPMh
* ref_aux - Auxiliary reference clock from GCC
* qref - QREF clock from GCC
While at it, let's move 'clocks' property before 'clock-names' to match
the style used commonly.
Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 2b481e20ae38..5c9ec8047f00 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1585,9 +1585,12 @@ ufs_mem_phy: phy@1d87000 {
compatible = "qcom,sc7180-qmp-ufs-phy",
"qcom,sm7150-qmp-ufs-phy";
reg = <0 0x01d87000 0 0x1000>;
- clocks = <&gcc GCC_UFS_MEM_CLKREF_CLK>,
- <&gcc GCC_UFS_PHY_PHY_AUX_CLK>;
- clock-names = "ref", "ref_aux";
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_UFS_PHY_PHY_AUX_CLK>,
+ <&gcc GCC_UFS_MEM_CLKREF_CLK>;
+ clock-names = "ref",
+ "ref_aux",
+ "qref";
power-domains = <&gcc UFS_PHY_GDSC>;
resets = <&ufs_mem_hc 0>;
reset-names = "ufsphy";
--
2.44.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: phy: qmp-ufs: Fix PHY clocks for SC7180
From: Danila Tikhonov @ 2024-04-01 18:22 UTC (permalink / raw)
To: andersson, konrad.dybcio, vkoul, kishon, robh,
krzysztof.kozlowski+dt, conor+dt, cros-qcom-dts-watchers,
manivannan.sadhasivam, davidwronek
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Danila Tikhonov
In-Reply-To: <20240401182240.55282-1-danila@jiaxyga.com>
QMP UFS PHY used in SC7180 requires 3 clocks:
* ref - 19.2MHz reference clock from RPMh
* ref_aux - Auxiliary reference clock from GCC
* qref - QREF clock from GCC
This change obviously breaks the ABI, but it is inevitable since the
clock topology needs to be accurately described in the binding.
Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
---
.../devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
index 91a6cc38ff7f..a79fde9a8cdf 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
@@ -86,6 +86,7 @@ allOf:
enum:
- qcom,msm8998-qmp-ufs-phy
- qcom,sa8775p-qmp-ufs-phy
+ - qcom,sc7180-qmp-ufs-phy
- qcom,sc7280-qmp-ufs-phy
- qcom,sc8180x-qmp-ufs-phy
- qcom,sc8280xp-qmp-ufs-phy
--
2.44.0
^ permalink raw reply related
* Re: [PATCH v2 27/27] kselftest/riscv: kselftest for user mode cfi
From: Deepak Gupta @ 2024-04-01 17:55 UTC (permalink / raw)
To: Muhammad Usama Anjum
Cc: paul.walmsley, rick.p.edgecombe, broonie, Szabolcs.Nagy,
kito.cheng, keescook, ajones, conor.dooley, cleger, atishp, alex,
bjorn, alexghiti, samuel.holland, conor, linux-doc, linux-riscv,
linux-kernel, devicetree, linux-mm, linux-arch, linux-kselftest,
corbet, tech-j-ext, palmer, aou, robh+dt, krzysztof.kozlowski+dt,
oleg, akpm, arnd, ebiederm, Liam.Howlett, vbabka, lstoakes, shuah,
brauner, andy.chiu, jerry.shih, hankuan.chen, greentime.hu, evan,
xiao.w.wang, charlie, apatel, mchitale, dbarboza, sameo,
shikemeng, willy, vincent.chen, guoren, samitolvanen,
songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy, maskray,
ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe, baruch, alx,
david, catalin.marinas, revest, josh, shr, deller, omosnace,
ojeda, jhubbard
In-Reply-To: <CAKC1njQj7GfkdE1HJD54utkoPqJXyqMeoXOxa6ActqZ-fSDuKQ@mail.gmail.com>
On Mon, Apr 1, 2024 at 10:34 AM Deepak Gupta <debug@rivosinc.com> wrote:
>
> On Mon, Apr 1, 2024 at 2:48 AM Muhammad Usama Anjum
> <usama.anjum@collabora.com> wrote:
> >
> > >>> Signed-off-by: Deepak Gupta <debug@rivosinc.com>
> > >>> ---
> > >>> tools/testing/selftests/riscv/Makefile | 2 +-
> > >>> tools/testing/selftests/riscv/cfi/Makefile | 10 +
> > >>> .../testing/selftests/riscv/cfi/cfi_rv_test.h | 85 ++++
> > >>> .../selftests/riscv/cfi/riscv_cfi_test.c | 91 +++++
> > >>> .../testing/selftests/riscv/cfi/shadowstack.c | 376 ++++++++++++++++++
> > >>> .../testing/selftests/riscv/cfi/shadowstack.h | 39 ++
> > >> Please add generated binaries in the .gitignore files.
> > >
> > > hmm...
> > > I don't see binary as part of the patch. Which file are you referring
> > > to here being binary?
> > shadowstack would be generated by the build. Create a .gitignore file and
> > add it there. For example, look at
> > tools/testing/selftests/riscv/vector/.gitignore to understand.
>
> It's `shadowstack.c` (a C source file) and not a binary file.
Nevermind. I think what you want me to do is add a rule in `.gitignore`.
I was thinking otherwise (that somehow you're seeing a binary file in
patch set).
Thanks. Will do that in the next iteration.
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: mt2701-wm8960: Convert to dtschema
From: Kartik Agarwala @ 2024-04-01 17:38 UTC (permalink / raw)
To: Rob Herring
Cc: lgirdwood, broonie, krzysztof.kozlowski+dt, conor+dt,
matthias.bgg, angelogioacchino.delregno, linux-sound, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20240401151414.GA706943-robh@kernel.org>
On 4/1/24 8:44 PM, Rob Herring wrote:
> On Mon, Apr 01, 2024 at 10:05:05AM +0530, Kartik Agarwala wrote:
>> + A list of the connections between audio components. Each entry is a
>> + pair of strings, the first being the connection's sink, the second
>> + being the connection's source.
>> +
>> + mediatek,audio-codec:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description: The phandle of the WM8960 audio codec.
>> +
>> + pinctrl-names:
>> + const: default
>> +
>> + pinctrl-0: true
>
> You can drop pinctrl properties. Those are implicitly supported.
Hi,
Thanks for the review!
Just to clarify, the removal of pinctrl properties should only apply
to this section and not to the required properties or the example,
is that correct?
Regards,
Kartik Agarwala
^ permalink raw reply
* Re: [PATCH v2 27/27] kselftest/riscv: kselftest for user mode cfi
From: Deepak Gupta @ 2024-04-01 17:34 UTC (permalink / raw)
To: Muhammad Usama Anjum
Cc: paul.walmsley, rick.p.edgecombe, broonie, Szabolcs.Nagy,
kito.cheng, keescook, ajones, conor.dooley, cleger, atishp, alex,
bjorn, alexghiti, samuel.holland, conor, linux-doc, linux-riscv,
linux-kernel, devicetree, linux-mm, linux-arch, linux-kselftest,
corbet, tech-j-ext, palmer, aou, robh+dt, krzysztof.kozlowski+dt,
oleg, akpm, arnd, ebiederm, Liam.Howlett, vbabka, lstoakes, shuah,
brauner, andy.chiu, jerry.shih, hankuan.chen, greentime.hu, evan,
xiao.w.wang, charlie, apatel, mchitale, dbarboza, sameo,
shikemeng, willy, vincent.chen, guoren, samitolvanen,
songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy, maskray,
ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe, baruch, alx,
david, catalin.marinas, revest, josh, shr, deller, omosnace,
ojeda, jhubbard
In-Reply-To: <ef72ae20-6b68-496a-a819-8818ade0d433@collabora.com>
On Mon, Apr 1, 2024 at 2:48 AM Muhammad Usama Anjum
<usama.anjum@collabora.com> wrote:
>
> >>> Signed-off-by: Deepak Gupta <debug@rivosinc.com>
> >>> ---
> >>> tools/testing/selftests/riscv/Makefile | 2 +-
> >>> tools/testing/selftests/riscv/cfi/Makefile | 10 +
> >>> .../testing/selftests/riscv/cfi/cfi_rv_test.h | 85 ++++
> >>> .../selftests/riscv/cfi/riscv_cfi_test.c | 91 +++++
> >>> .../testing/selftests/riscv/cfi/shadowstack.c | 376 ++++++++++++++++++
> >>> .../testing/selftests/riscv/cfi/shadowstack.h | 39 ++
> >> Please add generated binaries in the .gitignore files.
> >
> > hmm...
> > I don't see binary as part of the patch. Which file are you referring
> > to here being binary?
> shadowstack would be generated by the build. Create a .gitignore file and
> add it there. For example, look at
> tools/testing/selftests/riscv/vector/.gitignore to understand.
It's `shadowstack.c` (a C source file) and not a binary file.
^ permalink raw reply
* Re: [PATCH v2] media: dt-bindings: ovti,ov2680: Document more properties
From: Laurent Pinchart @ 2024-04-01 17:28 UTC (permalink / raw)
To: Fabio Estevam
Cc: sakari.ailus, rmfrfs, hansg, robh, krzysztof.kozlowski+dt,
conor+dt, linux-media, devicetree, Fabio Estevam
In-Reply-To: <20240401154341.3173872-1-festevam@gmail.com>
Hi Fabio,
Thank you for the patch.
On Mon, Apr 01, 2024 at 12:43:41PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
>
> OV2680 has a single data lane MIPI interface.
>
> Document the clock-lanes and data-lanes properties to avoid
> the following dt-schema warning:
>
> imx7s-warp.dtb: camera@36: port:endpoint: Unevaluated properties are not allowed ('clock-lanes', 'data-lanes' were unexpected)
> from schema $id: http://devicetree.org/schemas/media/i2c/ovti,ov2680.yaml#
>
> While at it, also document the link-frequencies property as recommended
> by the following document:
>
> https://www.kernel.org/doc/html/v6.9-rc1/driver-api/media/camera-sensor.html#handling-clocks
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
> Changes since v1:
> - Keep the existing 'additionalProperties: false'. (Krzysztof)
> - Also document link-frequencies.
>
> .../bindings/media/i2c/ovti,ov2680.yaml | 20 ++++++++++++++++++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
> index cf456f8d9ddc..a1cb08283818 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
> @@ -50,9 +50,24 @@ properties:
> Definition of the regulator used as digital power supply.
>
> port:
> - $ref: /schemas/graph.yaml#/properties/port
> description:
> A node containing an output port node.
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + additionalProperties: false
> +
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
I recommend using
additionalProperties: false
as the bindings shouldn't allow all the other properties defined in
video-interfaces.yaml that are not applicable for this device. It will
require adding
remote-endpoint: true
to the properties below.
> +
> + properties:
> + clock-lanes:
> + const: 0
> +
> + data-lanes:
> + const: 1
I see there's an ongoing discussion in v1 about these two properties,
I'll let Sakari and you figure it out :-)
> +
> + link-frequencies: true
I think this one should one marked as mandatory.
>
> required:
> - compatible
> @@ -89,6 +104,9 @@ examples:
> port {
> ov2680_to_mipi: endpoint {
> remote-endpoint = <&mipi_from_sensor>;
> + clock-lanes = <0>;
> + data-lanes = <1>;
> + link-frequencies = /bits/ 64 <330000000>;
> };
> };
> };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v1 1/6] dt-bindings: clock: meson: a1: pll: introduce new syspll bindings
From: Dmitry Rokosov @ 2024-04-01 17:22 UTC (permalink / raw)
To: Rob Herring
Cc: neil.armstrong, jbrunet, mturquette, sboyd,
krzysztof.kozlowski+dt, khilman, martin.blumenstingl, kernel,
rockosov, linux-amlogic, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20240401142011.GA537763-robh@kernel.org>
Hello Rob,
On Mon, Apr 01, 2024 at 09:20:11AM -0500, Rob Herring wrote:
> On Fri, Mar 29, 2024 at 11:58:41PM +0300, Dmitry Rokosov wrote:
> > The 'syspll' PLL is a general-purpose PLL designed specifically for the
> > CPU clock. It is capable of producing output frequencies within the
> > range of 768MHz to 1536MHz.
> >
> > Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> > ---
> > .../devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml | 7 +++++--
> > include/dt-bindings/clock/amlogic,a1-pll-clkc.h | 2 ++
> > 2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
> > index a59b188a8bf5..fbba57031278 100644
> > --- a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
> > +++ b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
> > @@ -26,11 +26,13 @@ properties:
> > items:
> > - description: input fixpll_in
> > - description: input hifipll_in
> > + - description: input syspll_in
> >
> > clock-names:
> > items:
> > - const: fixpll_in
> > - const: hifipll_in
> > + - const: syspll_in
>
> A new required entry is an ABI break. Please state why that's ok or make
> it optional (minItems: 2).
Unfortunatelly, it cannot be optional. I've explained here why:
https://lore.kernel.org/all/20240401171933.bqmjsuanqsjvjosn@CAB-WSD-L081021/
"""
The clock source sys_pll_div16, being one of the GEN clock parents,
plays a crucial role and cannot be tagged as "optional". Unfortunately,
it was not implemented earlier due to the cpu clock ctrl driver's
pending status on the TODO list.
"""
Could you please provide guidance on whether there is any alternative
approach that could potentially make it possible?
--
Thank you,
Dmitry
^ permalink raw reply
* [PATCH v2 4/4] arm64: dts: qcom: msm8976: Add WCNSS node
From: Adam Skladowski @ 2024-04-01 17:21 UTC (permalink / raw)
Cc: phone-devel, ~postmarketos/upstreaming, Adam Skladowski,
Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20240401172153.9231-1-a39.skl@gmail.com>
Add node describing wireless connectivity subsystem.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 104 ++++++++++++++++++++++++++
1 file changed, 104 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index 77670fce9b8f..41c748c78347 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -771,6 +771,36 @@ blsp2_i2c4_sleep: blsp2-i2c4-sleep-state {
drive-strength = <2>;
bias-disable;
};
+
+ wcss_wlan_default: wcss-wlan-default-state {
+ wcss-wlan2-pins {
+ pins = "gpio40";
+ function = "wcss_wlan2";
+ drive-strength = <6>;
+ bias-pull-up;
+ };
+
+ wcss-wlan1-pins {
+ pins = "gpio41";
+ function = "wcss_wlan1";
+ drive-strength = <6>;
+ bias-pull-up;
+ };
+
+ wcss-wlan0-pins {
+ pins = "gpio42";
+ function = "wcss_wlan0";
+ drive-strength = <6>;
+ bias-pull-up;
+ };
+
+ wcss-wlan-pins {
+ pins = "gpio43", "gpio44";
+ function = "wcss_wlan";
+ drive-strength = <6>;
+ bias-pull-up;
+ };
+ };
};
gcc: clock-controller@1800000 {
@@ -1446,6 +1476,80 @@ blsp2_i2c4: i2c@7af8000 {
status = "disabled";
};
+ wcnss: remoteproc@a204000 {
+ compatible = "qcom,pronto-v3-pil", "qcom,pronto";
+ reg = <0x0a204000 0x2000>,
+ <0x0a202000 0x1000>,
+ <0x0a21b000 0x3000>;
+ reg-names = "ccu",
+ "dxe",
+ "pmu";
+
+ memory-region = <&wcnss_fw_mem>;
+
+ interrupts-extended = <&intc GIC_SPI 149 IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack";
+
+ power-domains = <&rpmpd MSM8976_VDDCX>,
+ <&rpmpd MSM8976_VDDMX>;
+ power-domain-names = "cx", "mx";
+
+ qcom,smem-states = <&wcnss_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ pinctrl-0 = <&wcss_wlan_default>;
+ pinctrl-names = "default";
+
+ status = "disabled";
+
+ wcnss_iris: iris {
+ /* Separate chip, compatible is board-specific */
+ clocks = <&rpmcc RPM_SMD_RF_CLK2>;
+ clock-names = "xo";
+ };
+
+ smd-edge {
+ interrupts = <GIC_SPI 142 IRQ_TYPE_EDGE_RISING>;
+
+ qcom,ipc = <&apcs 8 17>;
+ qcom,smd-edge = <6>;
+ qcom,remote-pid = <4>;
+
+ label = "pronto";
+
+ wcnss_ctrl: wcnss {
+ compatible = "qcom,wcnss";
+ qcom,smd-channels = "WCNSS_CTRL";
+
+ qcom,mmio = <&wcnss>;
+
+ wcnss_bt: bluetooth {
+ compatible = "qcom,wcnss-bt";
+ };
+
+ wcnss_wifi: wifi {
+ compatible = "qcom,wcnss-wlan";
+
+ interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "tx", "rx";
+
+ qcom,smem-states = <&apps_smsm 10>, <&apps_smsm 9>;
+ qcom,smem-state-names = "tx-enable",
+ "tx-rings-empty";
+ };
+ };
+ };
+ };
+
intc: interrupt-controller@b000000 {
compatible = "qcom,msm-qgic2";
reg = <0x0b000000 0x1000>, <0x0b002000 0x1000>;
--
2.44.0
^ permalink raw reply related
* [PATCH v2 3/4] arm64: dts: qcom: msm8976: Add Adreno GPU
From: Adam Skladowski @ 2024-04-01 17:21 UTC (permalink / raw)
Cc: phone-devel, ~postmarketos/upstreaming, Adam Skladowski,
Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20240401172153.9231-1-a39.skl@gmail.com>
Add Adreno GPU node.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 65 +++++++++++++++++++++++++++
1 file changed, 65 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index 6be310079f5b..77670fce9b8f 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -1074,6 +1074,71 @@ mdss_dsi1_phy: phy@1a96a00 {
};
};
+ adreno_gpu: gpu@1c00000 {
+ compatible = "qcom,adreno-510.0", "qcom,adreno";
+
+ reg = <0x01c00000 0x40000>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "kgsl_3d0_irq";
+
+ clocks = <&gcc GCC_GFX3D_OXILI_CLK>,
+ <&gcc GCC_GFX3D_OXILI_AHB_CLK>,
+ <&gcc GCC_GFX3D_OXILI_GMEM_CLK>,
+ <&gcc GCC_GFX3D_BIMC_CLK>,
+ <&gcc GCC_GFX3D_OXILI_TIMER_CLK>,
+ <&gcc GCC_GFX3D_OXILI_AON_CLK>;
+ clock-names = "core",
+ "iface",
+ "mem",
+ "mem_iface",
+ "rbbmtimer",
+ "alwayson";
+
+ power-domains = <&gcc OXILI_GX_GDSC>;
+
+ iommus = <&gpu_iommu 0>;
+
+ status = "disabled";
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmpd_opp_svs>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ required-opps = <&rpmpd_opp_nom>;
+ };
+
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ required-opps = <&rpmpd_opp_nom_plus>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ required-opps = <&rpmpd_opp_turbo>;
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ required-opps = <&rpmpd_opp_turbo>;
+ };
+ };
+ };
+
apps_iommu: iommu@1ee0000 {
compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
reg = <0x01ee0000 0x3000>;
--
2.44.0
^ permalink raw reply related
* [PATCH v2 2/4] arm64: dts: qcom: msm8976: Add MDSS nodes
From: Adam Skladowski @ 2024-04-01 17:21 UTC (permalink / raw)
Cc: phone-devel, ~postmarketos/upstreaming, Adam Skladowski,
Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20240401172153.9231-1-a39.skl@gmail.com>
Add MDSS nodes to support displays on MSM8976 SoC.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 274 +++++++++++++++++++++++++-
1 file changed, 270 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index 8bdcc1438177..6be310079f5b 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -785,10 +785,10 @@ gcc: clock-controller@1800000 {
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
<&rpmcc RPM_SMD_XO_A_CLK_SRC>,
- <0>,
- <0>,
- <0>,
- <0>;
+ <&mdss_dsi0_phy 1>,
+ <&mdss_dsi0_phy 0>,
+ <&mdss_dsi1_phy 1>,
+ <&mdss_dsi1_phy 0>;
clock-names = "xo",
"xo_a",
"dsi0pll",
@@ -808,6 +808,272 @@ tcsr: syscon@1937000 {
reg = <0x01937000 0x30000>;
};
+ mdss: display-subsystem@1a00000 {
+ compatible = "qcom,mdss";
+
+ reg = <0x01a00000 0x1000>,
+ <0x01ab0000 0x3000>;
+ reg-names = "mdss_phys", "vbif_phys";
+
+ power-domains = <&gcc MDSS_GDSC>;
+ interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ clocks = <&gcc GCC_MDSS_AHB_CLK>,
+ <&gcc GCC_MDSS_AXI_CLK>,
+ <&gcc GCC_MDSS_VSYNC_CLK>,
+ <&gcc GCC_MDSS_MDP_CLK>;
+ clock-names = "iface",
+ "bus",
+ "vsync",
+ "core";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ status = "disabled";
+
+ mdss_mdp: display-controller@1a01000 {
+ compatible = "qcom,msm8976-mdp5", "qcom,mdp5";
+ reg = <0x01a01000 0x89000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ clocks = <&gcc GCC_MDSS_AHB_CLK>,
+ <&gcc GCC_MDSS_AXI_CLK>,
+ <&gcc GCC_MDSS_MDP_CLK>,
+ <&gcc GCC_MDSS_VSYNC_CLK>,
+ <&gcc GCC_MDP_TBU_CLK>,
+ <&gcc GCC_MDP_RT_TBU_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync",
+ "tbu",
+ "tbu_rt";
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&gcc MDSS_GDSC>;
+
+ iommus = <&apps_iommu 22>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_mdp5_intf1_out: endpoint {
+ remote-endpoint = <&mdss_dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_mdp5_intf2_out: endpoint {
+ remote-endpoint = <&mdss_dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-177780000 {
+ opp-hz = /bits/ 64 <177780000>;
+ required-opps = <&rpmpd_opp_svs>;
+ };
+
+ opp-270000000 {
+ opp-hz = /bits/ 64 <270000000>;
+ required-opps = <&rpmpd_opp_svs_plus>;
+ };
+
+ opp-320000000 {
+ opp-hz = /bits/ 64 <320000000>;
+ required-opps = <&rpmpd_opp_nom>;
+ };
+ opp-360000000 {
+ opp-hz = /bits/ 64 <360000000>;
+ required-opps = <&rpmpd_opp_turbo>;
+ };
+ };
+ };
+
+ mdss_dsi0: dsi@1a94000 {
+ compatible = "qcom,msm8976-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x01a94000 0x25c>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&gcc GCC_MDSS_MDP_CLK>,
+ <&gcc GCC_MDSS_AHB_CLK>,
+ <&gcc GCC_MDSS_AXI_CLK>,
+ <&gcc GCC_MDSS_BYTE0_CLK>,
+ <&gcc GCC_MDSS_PCLK0_CLK>,
+ <&gcc GCC_MDSS_ESC0_CLK>;
+ clock-names = "mdp_core",
+ "iface",
+ "bus",
+ "byte",
+ "pixel",
+ "core";
+
+ assigned-clocks = <&gcc GCC_MDSS_BYTE0_CLK_SRC>,
+ <&gcc GCC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&mdss_dsi0_phy 0>,
+ <&mdss_dsi0_phy 1>;
+
+ phys = <&mdss_dsi0_phy>;
+
+ operating-points-v2 = <&dsi0_opp_table>;
+ power-domains = <&gcc MDSS_GDSC>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dsi0_in: endpoint {
+ remote-endpoint = <&mdss_mdp5_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dsi0_out: endpoint {
+ };
+ };
+ };
+
+ dsi0_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-125000000 {
+ opp-hz = /bits/ 64 <125000000>;
+ required-opps = <&rpmpd_opp_svs>;
+
+ };
+
+ opp-161250000 {
+ opp-hz = /bits/ 64 <161250000>;
+ required-opps = <&rpmpd_opp_svs_plus>;
+ };
+
+ opp-187500000 {
+ opp-hz = /bits/ 64 <187500000>;
+ required-opps = <&rpmpd_opp_nom>;
+ };
+ };
+ };
+
+ mdss_dsi1: dsi@1a96000 {
+ compatible = "qcom,msm8976-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x01a96000 0x300>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <5>;
+
+ clocks = <&gcc GCC_MDSS_MDP_CLK>,
+ <&gcc GCC_MDSS_AHB_CLK>,
+ <&gcc GCC_MDSS_AXI_CLK>,
+ <&gcc GCC_MDSS_BYTE1_CLK>,
+ <&gcc GCC_MDSS_PCLK1_CLK>,
+ <&gcc GCC_MDSS_ESC1_CLK>;
+ clock-names = "mdp_core",
+ "iface",
+ "bus",
+ "byte",
+ "pixel",
+ "core";
+
+ assigned-clocks = <&gcc GCC_MDSS_BYTE1_CLK_SRC>,
+ <&gcc GCC_MDSS_PCLK1_CLK_SRC>;
+ assigned-clock-parents = <&mdss_dsi1_phy 0>,
+ <&mdss_dsi1_phy 1>;
+
+ phys = <&mdss_dsi1_phy>;
+
+ power-domains = <&gcc MDSS_GDSC>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dsi1_in: endpoint {
+ remote-endpoint = <&mdss_mdp5_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ mdss_dsi0_phy: phy@1a94a00 {
+ compatible = "qcom,dsi-phy-28nm-hpm-fam-b";
+ reg = <0x01a94a00 0xd4>,
+ <0x01a94400 0x280>,
+ <0x01a94b80 0x30>;
+ reg-names = "dsi_pll",
+ "dsi_phy",
+ "dsi_phy_regulator";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&gcc GCC_MDSS_AHB_CLK>,
+ <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "iface", "ref";
+
+ status = "disabled";
+ };
+
+ mdss_dsi1_phy: phy@1a96a00 {
+ compatible = "qcom,dsi-phy-28nm-hpm-fam-b";
+ reg = <0x01a96a00 0xd4>,
+ <0x01a96400 0x280>,
+ <0x01a96b80 0x30>;
+ reg-names = "dsi_pll",
+ "dsi_phy",
+ "dsi_phy_regulator";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&gcc GCC_MDSS_AHB_CLK>,
+ <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "iface", "ref";
+
+ status = "disabled";
+ };
+ };
+
apps_iommu: iommu@1ee0000 {
compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
reg = <0x01ee0000 0x3000>;
--
2.44.0
^ permalink raw reply related
* [PATCH v2 1/4] arm64: dts: qcom: msm8976: Add IOMMU nodes
From: Adam Skladowski @ 2024-04-01 17:21 UTC (permalink / raw)
Cc: phone-devel, ~postmarketos/upstreaming, Adam Skladowski,
Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20240401172153.9231-1-a39.skl@gmail.com>
Add the nodes describing the apps and gpu iommu and its context banks
that are found on msm8976 SoCs.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 81 +++++++++++++++++++++++++++
1 file changed, 81 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index d2bb1ada361a..8bdcc1438177 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -808,6 +808,87 @@ tcsr: syscon@1937000 {
reg = <0x01937000 0x30000>;
};
+ apps_iommu: iommu@1ee0000 {
+ compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
+ reg = <0x01ee0000 0x3000>;
+ ranges = <0 0x01e20000 0x20000>;
+
+ clocks = <&gcc GCC_SMMU_CFG_CLK>,
+ <&gcc GCC_APSS_TCU_CLK>;
+ clock-names = "iface", "bus";
+
+ qcom,iommu-secure-id = <17>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #iommu-cells = <1>;
+
+ /* VFE */
+ iommu-ctx@15000 {
+ compatible = "qcom,msm-iommu-v2-ns";
+ reg = <0x15000 0x1000>;
+ qcom,ctx-asid = <20>;
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ /* VENUS NS */
+ iommu-ctx@16000 {
+ compatible = "qcom,msm-iommu-v2-ns";
+ reg = <0x16000 0x1000>;
+ qcom,ctx-asid = <21>;
+ interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ /* MDP0 */
+ iommu-ctx@17000 {
+ compatible = "qcom,msm-iommu-v2-ns";
+ reg = <0x17000 0x1000>;
+ qcom,ctx-asid = <22>;
+ interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
+ gpu_iommu: iommu@1f08000 {
+ compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
+ ranges = <0 0x01f08000 0x8000>;
+
+ clocks = <&gcc GCC_SMMU_CFG_CLK>,
+ <&gcc GCC_GFX3D_TCU_CLK>;
+ clock-names = "iface", "bus";
+
+ power-domains = <&gcc OXILI_CX_GDSC>;
+
+ qcom,iommu-secure-id = <18>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #iommu-cells = <1>;
+
+ /* gfx3d user */
+ iommu-ctx@0 {
+ compatible = "qcom,msm-iommu-v2-ns";
+ reg = <0x0 0x1000>;
+ qcom,ctx-asid = <0>;
+ interrupts = <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ /* gfx3d secure */
+ iommu-ctx@1000 {
+ compatible = "qcom,msm-iommu-v2-sec";
+ reg = <0x1000 0x1000>;
+ qcom,ctx-asid = <2>;
+ interrupts = <GIC_SPI 241 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ /* gfx3d priv */
+ iommu-ctx@2000 {
+ compatible = "qcom,msm-iommu-v2-sec";
+ reg = <0x2000 0x1000>;
+ qcom,ctx-asid = <1>;
+ interrupts = <GIC_SPI 242 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
spmi_bus: spmi@200f000 {
compatible = "qcom,spmi-pmic-arb";
reg = <0x0200f000 0x1000>,
--
2.44.0
^ permalink raw reply related
* [PATCH v2 0/4] MSM8976 MDSS/GPU/WCNSS support
From: Adam Skladowski @ 2024-04-01 17:21 UTC (permalink / raw)
Cc: phone-devel, ~postmarketos/upstreaming, Adam Skladowski,
Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel
This patch series provide support for display subsystem, gpu
and also adds wireless connectivity subsystem support.
Changes since v1
================
1. Addressed feedback
2. Dropped already applied dt-bindings patches
3. Dropped sdc patch as it was submitted as part of other series
4. Dropped dt-bindings patch for Adreno, also separate now
Adam Skladowski (4):
arm64: dts: qcom: msm8976: Add IOMMU nodes
arm64: dts: qcom: msm8976: Add MDSS nodes
arm64: dts: qcom: msm8976: Add Adreno GPU
arm64: dts: qcom: msm8976: Add WCNSS node
arch/arm64/boot/dts/qcom/msm8976.dtsi | 524 +++++++++++++++++++++++++-
1 file changed, 520 insertions(+), 4 deletions(-)
--
2.44.0
^ permalink raw reply
* Re: [PATCH v1 3/6] dt-bindings: clock: meson: a1: peripherals: support sys_pll_div16 input
From: Dmitry Rokosov @ 2024-04-01 17:19 UTC (permalink / raw)
To: Rob Herring
Cc: neil.armstrong, jbrunet, mturquette, sboyd,
krzysztof.kozlowski+dt, khilman, martin.blumenstingl, kernel,
rockosov, linux-amlogic, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20240401142136.GA559114-robh@kernel.org>
Hello Rob,
Thank you for the quick review.
On Mon, Apr 01, 2024 at 09:21:36AM -0500, Rob Herring wrote:
> On Fri, Mar 29, 2024 at 11:58:43PM +0300, Dmitry Rokosov wrote:
> > The 'sys_pll_div16' input clock is used as one of the sources for the
> > GEN clock.
> >
> > Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> > ---
> > .../bindings/clock/amlogic,a1-peripherals-clkc.yaml | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml
> > index 6d84cee1bd75..f6668991ff1f 100644
> > --- a/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml
> > +++ b/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml
> > @@ -29,6 +29,7 @@ properties:
> > - description: input fixed pll div5
> > - description: input fixed pll div7
> > - description: input hifi pll
> > + - description: input sys pll div16
> > - description: input oscillator (usually at 24MHz)
> >
> > clock-names:
> > @@ -38,6 +39,7 @@ properties:
> > - const: fclk_div5
> > - const: fclk_div7
> > - const: hifi_pll
> > + - const: sys_pll_div16
> > - const: xtal
>
> And adding an entry in the middle is also an ABI break. New entries go
> on the end (and should be optional).
The clock source sys_pll_div16, being one of the GEN clock parents,
plays a crucial role and cannot be tagged as "optional". Unfortunately,
it was not implemented earlier due to the cpu clock ctrl driver's
pending status on the TODO list.
I would greatly appreciate your advice on the best and simplest way to
resolve this matter in an effective manner..
--
Thank you,
Dmitry
^ 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