On 01/03/2024 19:16, Tanmay Shah wrote:
> From: Radhey Shyam Pandey
>
> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> UltraScale+ platform. It will help in defining TCM in device-tree
> and make it's access platform agnostic and data-driven.
>
> Tightly-coupled
On 06/03/2024 15:40, Duje Mihanović wrote:
> IST3032C (and possibly some other models) has touch keys. Document this.
>
> Signed-off-by: Duje Mihanović
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
regulator-max-microvolt = <3300000>;
> +};
Messed indentation here and in following lines..
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 01/03/2024 17:42, abdellatif.elkhl...@arm.com wrote:
> From: Abdellatif El Khlifi
>
> introduce the bindings for Arm remoteproc support.
>
> Signed-off-by: Abdellatif El Khlifi
> ---
> .../bindings/remoteproc/arm,rproc.yaml| 69 +++
> MAINTAINERS
On 01/03/2024 17:42, abdellatif.elkhl...@arm.com wrote:
> From: Abdellatif El Khlifi
>
> add device tree node for the external system core in Corstone-1000
>
> Signed-off-by: Abdellatif El Khlifi
> ---
> arch/arm64/boot/dts/arm/corstone1000.dtsi | 10 +-
> 1 file changed, 9
On 19/02/2024 18:44, Tanmay Shah wrote:
> From: Radhey Shyam Pandey
>
> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> UltraScale+ platform. It will help in defining TCM in device-tree
> and make it's access platform agnostic and data-driven.
>
> Tightly-coupled
dtschema defines label as string, so $ref in other bindings is
redundant.
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm
TI Davinci remoteproc bindings were marked as work-in-progress /
unstable in 2017 in commit ae67b8007816 ("dt-bindings: remoteproc: Add
bindings for Davinci DSP processors"). Almost seven years is enough, so
drop the "unstable" remark and expect usual ABI rules.
Signed-off-by:
Several TI SoC clock bindings were marked as work-in-progress / unstable
between 2013-2016, for example in commit f60b1ea5ea7a ("CLK: TI: add
support for gate clock"). It was enough of time to consider them stable
and expect usual ABI rules.
Signed-off-by: Krzysztof Kozlowski
---
Doc
he
"unstable" remark and expect usual ABI rules.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/clock/keystone-gate.txt | 2 --
Documentation/devicetree/bindings/clock/keystone-pll.txt | 2 --
2 files changed, 4 deletions(-)
diff --git a/Documentation/devicetree/bi
On 21/02/2024 23:45, Pavel Machek wrote:
>>> +properties:
>>> + compatible:
>>> +const: usb-c-connector
>>> +
>>> + power-role: true
>>> +
>>> + data-role: true
>>> +
>>> + try-power-role: true
>>
>> I don't understand why do you have here properties. Do you see any
On 18/02/2024 16:10, Karel Balej wrote:
> Rob Herring, 2024-02-15T08:20:52-06:00:
>>> .../bindings/mfd/marvell,88pm88x.yaml | 74 +++
>>
>> Filename should match the compatible.
>>
>> In general, drop the 'x' wildcard.
>
> By "in general", do you mean for the drivers code
On 18/02/2024 21:57, Luca Weiss wrote:
> Follow the updated bindings and use a QCS404-specific compatible for the
> HFPLL on this SoC.
>
> Signed-off-by: Luca Weiss
> ---
> Please note that this patch should only land after the patch for the
> clock driver.
> ---
This patch should go in the
Signed-off-by: Luca Weiss
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
iommu_ops_from_fwnode() stores _spec->np->fwnode in local
variable, so use it to simplify the code (iommu_spec is not changed
between these dereferences).
Signed-off-by: Krzysztof Kozlowski
---
drivers/iommu/of_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/d
Make pointer to fwnode_handle a pointer to const for code safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/iommu/iommu.c | 2 +-
include/linux/iommu.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 26a31ba4f72d
The xlate callbacks are supposed to translate of_phandle_args to proper
provider without modifying the of_phandle_args. Make the argument
pointer to const for code safety and readability.
Signed-off-by: Krzysztof Kozlowski
---
drivers/iommu/apple-dart.c | 3 ++-
drivers/iommu
Make pointer to bus_type a pointer to const for code safety.
Signed-off-by: Krzysztof Kozlowski
---
drivers/iommu/iommu-priv.h | 5 +++--
drivers/iommu/iommu.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/iommu-priv.h b/drivers/iommu/iommu-priv.h
On 13/02/2024 21:37, Tanmay Shah wrote:
> Hello,
>
> Thanks for reviews please find my comments below.
>
> On 2/13/24 1:20 PM, Rob Herring wrote:
>> On Tue, 13 Feb 2024 09:54:48 -0800, Tanmay Shah wrote:
>>> From: Radhey Shyam Pandey
>>>
>>> Introduce bindings for TCM memory address space on
On 12/02/2024 12:02, Pavel Machek wrote:
> Hi!
>>> Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
>>> but I did best I could.
>>>
>>> Signed-off-by: Pavel Machek
>>>
>>
>> You miss proper diffstat which makes reviewing difficult.
>
>> Actually entire patch is corrupted and
On 09/02/2024 20:51, Pavel Machek wrote:
> Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
> but I did best I could.
>
> Signed-off-by: Pavel Machek
>
You miss proper diffstat which makes reviewing difficult.
Actually entire patch is corrupted and impossible to apply.
On 10/02/2024 17:28, Luca Weiss wrote:
> Add the compatible for the SAW2 for L2 cache found on MSM8226.
>
> Signed-off-by: Luca Weiss
> ---
> Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml | 1 +
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 10/02/2024 17:38, Luca Weiss wrote:
> Add the compatibles and indexes for the rpmpd in MSM8974, both with the
> standard PM8841+PM8941 PMICs but also devices found with PMA8084.
>
> Signed-off-by: Luca Weiss
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 29/01/2024 08:48, Luca Weiss wrote:
> Some SC7280-based boards crash when providing the "secure_non_pixel"
> context bank, so allow only one iommu in the bindings also.
>
> Signed-off-by: Luca Weiss
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
tions(+)
>
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 18/01/2024 11:04, Arnaud Pouliquen wrote:
> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> (TEE).
> For instance, this compatible is used in both the Linux and OP-TEE
> device-tree:
> - In
On 25/01/2024 17:42, Alexandru Elisei wrote:
> Allow the kernel to get the base address, size, block size and associated
> memory node for tag storage from the device tree blob.
>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that
On 23/01/2024 22:03, Luca Weiss wrote:
> From: Vladimir Lypak
>
> Add a new define for the GCC_MDSS_BCR found on MSM8953.
>
> Signed-off-by: Vladimir Lypak
> [luca: expand commit message]
> Signed-off-by: Luca Weiss
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 20/01/2024 22:16, Duje Mihanović wrote:
> IST3032C (and possibly some other models) has touch keys. Document this.
>
> Signed-off-by: Duje Mihanović
> ---
Please provide changelog describing what changed against v1. Cover
letter has something but it is not accurate. It says nothing about
dtschema package defines firmware-name as string-array, so individual
bindings should not make it a string but instead just narrow the number
of expected firmware file names.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 4
On 28/12/2023 10:39, Karel Balej wrote:
> diff --git a/drivers/mfd/88pm88x.c b/drivers/mfd/88pm88x.c
> index 69a8e39d43b3..999d0539b720 100644
> --- a/drivers/mfd/88pm88x.c
> +++ b/drivers/mfd/88pm88x.c
> @@ -68,6 +68,21 @@ static struct mfd_cell pm886_devs[] = {
> .num_resources =
On 07/01/2024 10:49, Karel Balej wrote:
> Mark,
>
> On Fri Jan 5, 2024 at 4:18 PM CET, Mark Brown wrote:
>> On Thu, Dec 28, 2023 at 10:39:13AM +0100, Karel Balej wrote:
>>
>>> @@ -68,6 +68,21 @@ static struct mfd_cell pm886_devs[] = {
>>> .num_resources =
On 06/01/2024 11:19, Luca Weiss wrote:
> On Dienstag, 2. Jänner 2024 11:41:26 CET Krzysztof Kozlowski wrote:
>> On 31/12/2023 15:48, Luca Weiss wrote:
>>> It doesn't appear that the configuration is for the HFPLL is generic, so
>>
>> That's ok...
>>
>>>
On 04/01/2024 10:25, Krzysztof Kozlowski wrote:
> On 28/12/2023 10:39, Karel Balej wrote:
>> From: Karel Balej
>>
>
> A nit, subject: drop second/last, redundant "documentation entry". The
> "dt-bindings" prefix is already stating that these are bindi
On 28/12/2023 10:39, Karel Balej wrote:
> From: Karel Balej
>
A nit, subject: drop second/last, redundant "documentation entry". The
"dt-bindings" prefix is already stating that these are bindings.
> The Marvell 88PM88X PMICs provide regulators among other things.
> Document how to use them.
On 31/12/2023 15:48, Luca Weiss wrote:
> It doesn't appear that the configuration is for the HFPLL is generic, so
That's ok...
> add a qcs404-specific compatible and rename the existing struct to
but why this is the solution? If the qcom,hfpll compatible was
deprecated, but it is not. This
m,hfpll";
> +reg = <0xf9016000 0x30>;
> +clocks = <_board>;
> + clock-names = "xo";
> +clock-output-names = "hfpll_l2";
> +#clock-cells = <0>;
> +};
> + # Example 2 - HFPLL for CPU0
Just keep one example, they are the same. And then drop the comment.
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 20/12/2023 11:02, Luca Weiss wrote:
> Document the QCM6490 compatible used to describe the pmic glink on this
> platform.
>
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 13/12/2023 21:33, André Apitzsch wrote:
> This dts adds support for Motorola Moto G 4G released in 2013.
>
> Add a device tree with initial support for:
>
> - GPIO keys
> - Hall sensor
> - SDHCI
> - Vibrator
>
> Signed-off-by: André Apitzsch
> ---
> arch/arm/boot/dts/qcom/Makefile
On 13/12/2023 21:33, André Apitzsch wrote:
> Document the compatible for the MSM8926-based Motorola Moto G 4G smartphone.
>
> Signed-off-by: André Apitzsch
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
ini 2")
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 24/11/2023 14:57, Jianhua Lu wrote:
> ufs node isn't in a right place, 'f' is front of 's', so move it to
> above usb node.
Please not.
If we change the order to match DTSI, then this patch would be wrong.
Best regards,
Krzysztof
Use only one and exactly one space around '=' in DTS example.
Signed-off-by: Krzysztof Kozlowski
---
Merging idea: Rob's DT.
Should apply cleanly on Rob's for-next.
---
.../devicetree/bindings/auxdisplay/hit,hd44780.yaml | 2 +-
.../devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
rtions(+), 1 deletion(-)'
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 30/10/2023 09:29, Neil Armstrong wrote:
> Ok, I fixed all that
>
>>
>>> + - if:
>>> + properties:
>>> +compatible:
>>> + enum:
>>> +- qcom,sm8650-mpss-pas
>>> +then:
>>
>> I am not sure if keeping it in the same binding as sm8550 avoids that
>> much
On 29/10/2023 12:08, Karel Balej wrote:
> Document the corresponding compatible string for the use of this driver
> with the Marvell SD8777 wireless chipset.
>
> Signed-off-by: Karel Balej
> ---
Acked-by: Krzysztof Kozlowski
---
This is an automated instruction, just in cas
t; though I cannot be sure there.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 +
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 138
> +
> 2 files changed, 143 insertions(+)
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 27/10/2023 16:20, Luca Weiss wrote:
> Add the node for the ADSP found on the SC7280 SoC, using standard
> Qualcomm firmware.
>
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
e changed, 21 insertions(+)
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
compatible is used.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/sc7280-herobrine-lte-sku.dtsi | 2 ++
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +--
> 2 files changed, 3 insertions(+), 2 deletions(-)
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
om,sc7180-pas: split into
> separate file")
> Signed-off-by: Luca Weiss
> ---
> Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 26/10/2023 15:24, Stefan Hansson wrote:
> This was not enabled in the matisse-wifi tree. Without this, it is not
> possible to use the USB port for serial debugging via a "Carkit debug
> cable".
>
> Signed-off-by: Stefan Hansson
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
-samsung-matisse-wifi.dts (85%)
> copy arch/arm/boot/dts/qcom/{qcom-apq8026-samsung-matisse-wifi.dts =>
> qcom-msm8226-samsung-matisse-common.dtsi} (86%)
Thanks. For me this diff is much more readable - I clearly see what was
removed from final DTSI file thus what I should expect in DT
>
> Signed-off-by: Stefan Hansson
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 25/10/2023 09:35, Neil Armstrong wrote:
> Document the DSP Peripheral Authentication Service on the SM8650 Platform.
>
> Signed-off-by: Neil Armstrong
> ---
> .../bindings/remoteproc/qcom,sm8550-pas.yaml | 41
> +-
> 1 file changed, 40 insertions(+), 1 deletion(-)
On 25/10/2023 10:52, Stefan Hansson wrote:
>
>
> On 2023-10-25 10:48, Krzysztof Kozlowski wrote:
>> On 25/10/2023 10:37, Stefan Hansson wrote:
>>> This series adds a common samsung-matisse dtsi and reworks
>>> samsung-matisse-wifi to use it, and introduces
On 25/10/2023 10:37, Stefan Hansson wrote:
> According to the dts from the kernel source code released by Samsung,
> matissewifi and matisselte only have minor differences in hardware, so
> use a shared dtsi to reduce duplicated code. Additionally, this should
> make adding support for matisse3g
On 25/10/2023 10:37, Stefan Hansson wrote:
> This documents Samsung Galaxy Tab 4 10.1 LTE (samsung,matisselte)
> which is a tablet by Samsung based on the MSM8926 SoC.
>
> Signed-off-by: Stefan Hansson
> ---
This is a friendly reminder during the review process.
It looks like you received a
On 25/10/2023 10:37, Stefan Hansson wrote:
> This series adds a common samsung-matisse dtsi and reworks
> samsung-matisse-wifi to use it, and introduces samsung-matisselte. I
> choose matisselte over matisse-lte as this is how most other devices
> (klte, s3ve3g) do it and it is the codename that
On 24/10/2023 22:33, Stefan Hansson wrote:
> This was not enabled in the matisse-wifi tree.
Your commit msg should explain why this should be enabled.
>
> Signed-off-by: Stefan Hansson
> ---
> .../boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi| 4
> 1 file changed, 4
On 24/10/2023 22:33, Stefan Hansson wrote:
> This documents Samsung Galaxy Tab 4 10.1 LTE (samsung,matisselte)
> which is a tablet by Samsung based on the MSM8926 SoC.
>
> Signed-off-by: Stefan Hansson
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
Revi
On 24/10/2023 22:33, Stefan Hansson wrote:
> According to the dts from the kernel source code released by Samsung,
> matissewifi and matisselte only have minor differences in hardware, so
> use a shared dtsi to reduce duplicated code. Additionally, this should
> make adding support for matisse3g
On 21/10/2023 09:16, David Wronek wrote:
> Add a compatible for the Qualcomm Kryo 465 found in SM7125.
>
> Signed-off-by: David Wronek
> ---
> Documentation/devicetree/bindings/arm/cpus.yaml | 1
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
; Signed-off-by: Luca Weiss
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 13/10/2023 10:54, Luca Weiss wrote:
>> We expect the bindings to be dual licensed. What was the license of the
>> original work?
>
> Yes, just GPL-2.0-only:
>
On 13/10/2023 10:09, Luca Weiss wrote:
> Add the defines for the ADC channels found on the PM7325. The list is
> taken from downstream msm-5.4 and adjusted for mainline.
Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE`
On 11/10/2023 18:33, Luca Weiss wrote:
> From: Matti Lehtimäki
>
> Add compatibles for the MSM8226 and MSM8974 platforms to the Qualcomm
> watchdog binding.
>
> Signed-off-by: Matti Lehtimäki
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 11/10/2023 19:02, Luca Weiss wrote:
> Add the vendor prefix for HTC (https://www.htc.com/).
>
> Signed-off-by: Luca Weiss
> ---
So it is the first HTC device in upstream? That's a surprise...
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 11/10/2023 19:02, Luca Weiss wrote:
> Document the compatible for the MSM8926-based HTC One Mini 2 smartphone.
>
> Signed-off-by: Luca Weiss
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 07/10/2023 15:58, David Wronek wrote:
> Document the Xiaomi Redmi Note 9S (curtana) smartphone, which is based
> on the Qualcomm SM7125 SoC.
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 07/10/2023 15:58, David Wronek wrote:
> Document the QMP UFS PHY compatible for SC7180
>
> Signed-off-by: David Wronek
> ---
> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
>
On 07/10/2023 15:58, David Wronek wrote:
> Document the compatible for the UFS found on SC7180.
>
> Signed-off-by: David Wronek
> ---
> Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 02/10/2023 09:00, Luca Weiss wrote:
> Use gpio@ instead of pinctrl@ as that's the name expected by the
> qcom,spmi-pmic.yaml schema. Update it to fix dt validation.
>
> Signed-off-by: Luca Weiss
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
files to
> use the plural _gpios label instead of the singular _gpio as label but
> this example wasn't updated. But since we should just drop the label
> alltogether, do that.
>
> Signed-off-by: Luca Weiss
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 02/10/2023 08:55, Luca Weiss wrote:
> Document the compatible for the CCI block found on SC7280 SoC.
>
> Reviewed-by: Bryan O'Donoghue
> Signed-off-by: Luca Weiss
> ---
Thanks, looks good now.
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 29/09/2023 10:17, Luca Weiss wrote:
> As per commit ea25d61b448a ("arm64: dts: qcom: Use plural _gpios node
> label for PMIC gpios") all dts files now use the plural _gpios instead
> of the singular _gpio as label. Update the schema example also to match.
>
> Signed-off-by: Luca Weiss
> ---
>
On 29/09/2023 10:01, Luca Weiss wrote:
> Document the compatible for the CCI block found on SC7280 SoC.
>
> Signed-off-by: Luca Weiss
> ---
> Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
Power & volume buttons
> * RTC
> * SD card
> * USB
> * Various plumbing like regulators, i2c, spi, etc
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 19/09/2023 14:46, Luca Weiss wrote:
> Fairphone 5 is a smartphone based on the QCM6490 SoC.
>
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
; ---
Matches our discussion offline today. Looks good, thank you!
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 16/09/2023 15:41, Lukas Walter wrote:
> This dts adds support for Huawei Honor 5X / GR5 (2016) smartphone
> released in 2015.
>
> Add device tree with initial support for:
>
> - GPIO keys
> - Hall sensor
> - SDHCI (internal and external storage)
> - WCNSS (BT/WIFI)
> - Sensors (accelerometer,
On 16/09/2023 15:41, Lukas Walter wrote:
> Add a compatible for Huawei Honor 5X / GR5 (2016).
>
> Signed-off-by: Lukas Walter
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 13/09/2023 14:08, Konrad Dybcio wrote:
> On 13.09.2023 09:13, Krzysztof Kozlowski wrote:
>> On 12/09/2023 15:31, Konrad Dybcio wrote:
>>> These clocks are now handled from within the icc framework and are
>>> no longer registered from within the CCF. Remove them.
&g
On 13/09/2023 14:36, Rob Herring wrote:
>
> On Wed, 13 Sep 2023 06:16:41 -0500, Hari Nagalla wrote:
>> K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
>> The remote processor's life cycle management and IPC mechanisms are
>> similar across the R5F and M4F cores from remote
On 13/09/2023 15:59, Hari Nagalla wrote:
> On 9/13/23 06:32, Krzysztof Kozlowski wrote:
>>> - Removed unrelated items from examples
>>>
>>> Changes since v4:
>>> - Rebased to the latest kernel-next tree
>>> - Added optional sram memory reg
On 13/09/2023 13:16, Hari Nagalla wrote:
> From: Martyn Welch
>
> In the next commit we will be adding the M4F driver which shares a lot of
> commonality with the DSP driver. Split this shared functionality out so
> that it can be used by both drivers.
>
> Signed-off-by: Martyn Welch
>
On 13/09/2023 13:16, Hari Nagalla wrote:
> From: Martyn Welch
>
> The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> the MCU domain. This core is typically used for safety applications in a
> stand alone mode. However, some application (non safety related) may
> want to use
On 13/09/2023 13:16, Hari Nagalla wrote:
> From: Martyn Welch
>
> The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> the MCU domain. This core is typically used for safety applications in a
> stand alone mode. However, some application (non safety related) may
> want to use
On 13/09/2023 13:16, Hari Nagalla wrote:
> From: Martyn Welch
>
> We will be adding the M4F driver which shares a lot of commonality
> with the DSP driver. Common data structures are introduced here.
>
> Signed-off-by: Martyn Welch
> Signed-off-by: Hari Nagalla
> ---
> Changes in v6:
> -
On 13/09/2023 13:16, Hari Nagalla wrote:
> K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
> The remote processor's life cycle management and IPC mechanisms are
> similar across the R5F and M4F cores from remote processor driver
> point of view. However, there are subtle
On 13/09/2023 12:48, Konrad Dybcio wrote:
> On 13.09.2023 10:53, Krzysztof Kozlowski wrote:
>> On 13/09/2023 10:47, Konrad Dybcio wrote:
>>> On 13.09.2023 09:07, Krzysztof Kozlowski wrote:
>>>> On 12/09/2023 15:31, Konrad Dybcio wrote:
>>>>> The
On 13/09/2023 10:47, Konrad Dybcio wrote:
> On 13.09.2023 09:07, Krzysztof Kozlowski wrote:
>> On 12/09/2023 15:31, Konrad Dybcio wrote:
>>> These clocks are now handled from within the icc framework and are
>>
>> That's a driver behavior, not hardware.
> I bel
On 12/09/2023 15:31, Konrad Dybcio wrote:
> The last 2 clock-names entries for the USB2 controller were swapped,
> resulting in schema warnings:
>
> ['cfg_noc', 'core', 'mock_utmi', 'sleep'] is too short
> 'iface' was expected
> 'sleep' was expected
> 'mock_utmi' was
On 12/09/2023 15:31, Konrad Dybcio wrote:
> The last 2 clock-names entries for the USB2 controller were swapped,
> resulting in schema warnings:
>
> ['cfg_noc', 'core', 'mock_utmi', 'sleep'] is too short
> 'iface' was expected
> 'sleep' was expected
> 'mock_utmi' was
On 12/09/2023 15:31, Konrad Dybcio wrote:
> The AGGRE2 clock is a clock for the entire AGGRE2 bus, managed from
> within the interconnect driver. Attaching it to SLPI was a total hack.
> Get rid of it.
>
> Signed-off-by: Konrad Dybcio
> ---
Reviewed-by: Krzysztof Kozlows
On 12/09/2023 15:31, Konrad Dybcio wrote:
> These clocks are now handled from within the icc framework and are
> no longer registered from within the CCF. Remove them.
>
> Signed-off-by: Konrad Dybcio
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 12/09/2023 15:31, Konrad Dybcio wrote:
> These clocks are now handled from within the icc framework and are
> no longer registered from within the CCF. Remove them.
>
> Signed-off-by: Konrad Dybcio
> ---
> arch/arm64/boot/dts/qcom/sdm630.dtsi | 49
> +++-
> 1
On 12/09/2023 15:31, Konrad Dybcio wrote:
> These clocks are now handled from within the icc framework and are
That's a driver behavior, not hardware.
> no longer registered from within the CCF. Remove them.
>
Changes in Linux clock drivers should not cause some clocks to disappear
from DTS...
On 12/09/2023 10:49, Iuliana Prodan wrote:
>>> Should I test this on other tree(s)?
>> You test the patch on the tree you send it. What is the point to test it
>> on some old code, cherry-pick with bugs and then send?
>>
>> If you have cross-tree dependencies between subsystem, isn't linux-next
>>
On 12/09/2023 10:13, Iuliana Prodan wrote:
> On 9/12/2023 10:07 AM, Krzysztof Kozlowski wrote:
>> On 12/09/2023 00:44, Iuliana Prodan (OSS) wrote:
>>> From: Iuliana Prodan
>>>
>>> Add the reserve-memory nodes used by DSP when the rpmsg
>>> feature is
101 - 200 of 16222 matches
Mail list logo
