* Re: [PATCH 1/3] dt-bindings: vendor-prefixes: Add Emcraft Systems
From: Krzysztof Kozlowski @ 2024-03-28 22:00 UTC (permalink / raw)
To: Gilles Talis, devicetree, imx, linux-arm-kernel
Cc: conor+dt, krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex
In-Reply-To: <20240328202320.187596-2-gilles.talis@gmail.com>
On 28/03/2024 21:23, Gilles Talis wrote:
> Add an entry for Emcraft Systems (https://www.emcraft.com/)
>
> Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
This is an automated instruction, just in case, because many review tags
are being ignored. If you know the process, you can skip it (please do
not feel offended by me posting it here - no bad intentions intended).
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.
https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 3/5] clk: qcom: common: Add interconnect clocks support
From: Stephen Boyd @ 2024-03-28 21:54 UTC (permalink / raw)
To: andersson, conor+dt, devicetree, djakov, dmitry.baryshkov,
konrad.dybcio, krzysztof.kozlowski+dt, linux-arm-msm, linux-clk,
linux-kernel, linux-pm, mturquette, quic_anusha, quic_varada,
robh
In-Reply-To: <20240328075936.223461-4-quic_varada@quicinc.com>
Quoting Varadarajan Narayanan (2024-03-28 00:59:34)
> diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
> index 75f09e6e057e..9fa271812373 100644
> --- a/drivers/clk/qcom/common.c
> +++ b/drivers/clk/qcom/common.c
> @@ -8,6 +8,8 @@
> #include <linux/regmap.h>
> #include <linux/platform_device.h>
> #include <linux/clk-provider.h>
> +#include <linux/interconnect-clk.h>
> +#include <linux/interconnect-provider.h>
Do we need the second include?
> #include <linux/reset-controller.h>
> #include <linux/of.h>
>
> @@ -234,6 +236,41 @@ static struct clk_hw *qcom_cc_clk_hw_get(struct of_phandle_args *clkspec,
> return cc->rclks[idx] ? &cc->rclks[idx]->hw : NULL;
> }
>
> +#if IS_ENABLED(CONFIG_INTERCONNECT_CLK)
> +static int qcom_cc_icc_register(struct device *dev,
> + const struct qcom_cc_desc *desc)
> +{
> + struct icc_clk_data *icd;
> + int i;
> +
> + if (!desc->icc_hws)
> + return 0;
> +
> + icd = devm_kcalloc(dev, desc->num_icc_hws, sizeof(*icd), GFP_KERNEL);
> + if (!icd)
> + return -ENOMEM;
> +
> + for (i = 0; i < desc->num_icc_hws; i++) {
> + icd[i].clk = devm_clk_hw_get_clk(dev, desc->icc_hws[i], "qcom");
Make the con_id "icc" instead please, so we know the consumer is
icc_clk. Even better would be for the icc_clk device itself to be the
one requesting with devm_clk_hw_get_clk() so that we associate the clk
handle with the consumer device. It would also help us make it so that
drivers defer probe until their clk isn't an orphan.
> + if (IS_ERR(icd[i].clk))
> + return dev_err_probe(dev, PTR_ERR(icd[i].clk),
> + "get clock failed (%ld)\n",
> + PTR_ERR(icd[i].clk));
> +
> + icd[i].name = clk_hw_get_name(desc->icc_hws[i]);
> + }
> +
> + return PTR_ERR_OR_ZERO(devm_icc_clk_register(dev, desc->first_id,
> + desc->num_icc_hws, icd));
> +}
> +#else
> +static int qcom_cc_icc_register(struct device *dev,
> + const struct qcom_cc_desc *desc)
> +{
> + return 0;
> +}
Instead of this please have an
if (!IS_ENABLED(CONFIG_INTERCONNECT_CLK))
return 0;
> +#endif
> +
> int qcom_cc_really_probe(struct platform_device *pdev,
> const struct qcom_cc_desc *desc, struct regmap *regmap)
> {
> @@ -303,7 +340,7 @@ int qcom_cc_really_probe(struct platform_device *pdev,
> if (ret)
> return ret;
>
> - return 0;
> + return qcom_cc_icc_register(dev, desc);
> }
> EXPORT_SYMBOL_GPL(qcom_cc_really_probe);
>
> diff --git a/drivers/clk/qcom/common.h b/drivers/clk/qcom/common.h
> index 9c8f7b798d9f..d8ac26d83f3c 100644
> --- a/drivers/clk/qcom/common.h
> +++ b/drivers/clk/qcom/common.h
> @@ -29,6 +29,9 @@ struct qcom_cc_desc {
> size_t num_gdscs;
> struct clk_hw **clk_hws;
> size_t num_clk_hws;
> + struct clk_hw **icc_hws;
> + size_t num_icc_hws;
> + unsigned int first_id;
'first_id' is gross.
^ permalink raw reply
* Re: [PATCH v5 4/5] clk: qcom: ipq9574: Use icc-clk for enabling NoC related clocks
From: Stephen Boyd @ 2024-03-28 21:51 UTC (permalink / raw)
To: andersson, conor+dt, devicetree, djakov, dmitry.baryshkov,
konrad.dybcio, krzysztof.kozlowski+dt, linux-arm-msm, linux-clk,
linux-kernel, linux-pm, mturquette, quic_anusha, quic_varada,
robh
In-Reply-To: <20240328075936.223461-5-quic_varada@quicinc.com>
Quoting Varadarajan Narayanan (2024-03-28 00:59:35)
> diff --git a/drivers/clk/qcom/gcc-ipq9574.c b/drivers/clk/qcom/gcc-ipq9574.c
> index 0a3f846695b8..187fd9dcdf49 100644
> --- a/drivers/clk/qcom/gcc-ipq9574.c
> +++ b/drivers/clk/qcom/gcc-ipq9574.c
> @@ -4301,6 +4302,56 @@ static const struct qcom_reset_map gcc_ipq9574_resets[] = {
> [GCC_WCSS_Q6_TBU_BCR] = { 0x12054, 0 },
> };
>
> +#define IPQ_APPS_ID 9574 /* some unique value */
How is this supposed to stay unique? I don't understand
icc_node_create() API quite honestly. Why can't icc_clk_register()
maintain some ida of allocated numbers? Or is there some global number
space that we can "reserve" from? I'm quite amazed this is how things
are connected in interconnect framework.
> +
> +enum {
> + ICC_ANOC_PCIE0,
> + ICC_SNOC_PCIE0,
> + ICC_ANOC_PCIE1,
> + ICC_SNOC_PCIE1,
> + ICC_ANOC_PCIE2,
> + ICC_SNOC_PCIE2,
> + ICC_ANOC_PCIE3,
> + ICC_SNOC_PCIE3,
> + ICC_SNOC_USB,
> + ICC_ANOC_USB_AXI,
> + ICC_NSSNOC_NSSCC,
> + ICC_NSSNOC_SNOC_0,
> + ICC_NSSNOC_SNOC_1,
> + ICC_NSSNOC_PCNOC_1,
> + ICC_NSSNOC_QOSGEN_REF,
> + ICC_NSSNOC_TIMEOUT_REF,
> + ICC_NSSNOC_XO_DCD,
> + ICC_NSSNOC_ATB,
> + ICC_MEM_NOC_NSSNOC,
> + ICC_NSSNOC_MEMNOC,
> + ICC_NSSNOC_MEM_NOC_1,
> +};
Are these supposed to be in a dt-binding header?
> +
> +static struct clk_hw *icc_ipq9574_hws[] = {
> + [ICC_ANOC_PCIE0] = &gcc_anoc_pcie0_1lane_m_clk.clkr.hw,
> + [ICC_SNOC_PCIE0] = &gcc_anoc_pcie1_1lane_m_clk.clkr.hw,
> + [ICC_ANOC_PCIE1] = &gcc_anoc_pcie2_2lane_m_clk.clkr.hw,
> + [ICC_SNOC_PCIE1] = &gcc_anoc_pcie3_2lane_m_clk.clkr.hw,
> + [ICC_ANOC_PCIE2] = &gcc_snoc_pcie0_1lane_s_clk.clkr.hw,
> + [ICC_SNOC_PCIE2] = &gcc_snoc_pcie1_1lane_s_clk.clkr.hw,
^ permalink raw reply
* Re: [PATCH v3 6/6] riscv: dts: starfive: add Milkv Mars board device tree
From: Heinrich Schuchardt @ 2024-03-28 21:28 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Rob Herring, Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Emil Renner Berthing, linux-riscv, devicetree,
linux-kernel, Conor Dooley, Aurelien Jarno
In-Reply-To: <20240206-magma-deem-2c88e45a545a@spud>
On 2/6/24 20:13, Conor Dooley wrote:
> On Wed, Jan 31, 2024 at 09:26:00PM +0800, Jisheng Zhang wrote:
>> The Milkv Mars is a development board based on the Starfive JH7110 SoC.
>> The board features:
>>
>> - JH7110 SoC
>> - 1/2/4/8 GiB LPDDR4 DRAM
>> - AXP15060 PMIC
>> - 40 pin GPIO header
>> - 3x USB 3.0 host port
>> - 1x USB 2.0 host port
>> - 1x M.2 E-Key
>> - 1x eMMC slot
>> - 1x MicroSD slot
>> - 1x QSPI Flash
>> - 1x 1Gbps Ethernet port
>> - 1x HDMI port
>> - 1x 2-lane DSI and 1x 4-lane DSI
>> - 1x 2-lane CSI
>>
>> Add the devicetree file describing the currently supported features,
>> namely PMIC, UART, I2C, GPIO, SD card, QSPI Flash, eMMC and Ethernet.
>>
>> Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
>
> Got a dtbs_check issue in the patchwork CI:
>
> +arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dtb: gmac1-rgmii-rxin-clock: 'clock-frequency' is a required property
> + from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
> +arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dtb: gmac1-rmii-refin-clock: 'clock-frequency' is a required property
> + from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
>
> Can you fix that please? Also, I applied some patches the other day that
> seem to conflict quite a bit with the common board dts patch. Would you
> please do a rebase on top of that please?
>
> Cheers,
> Conor.
>
>> ---
>> arch/riscv/boot/dts/starfive/Makefile | 1 +
>> .../boot/dts/starfive/jh7110-milkv-mars.dts | 35 +++++++++++++++++++
>> 2 files changed, 36 insertions(+)
>> create mode 100644 arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts
>>
>> diff --git a/arch/riscv/boot/dts/starfive/Makefile b/arch/riscv/boot/dts/starfive/Makefile
>> index 0141504c0f5c..2fa0cd7f31c3 100644
>> --- a/arch/riscv/boot/dts/starfive/Makefile
>> +++ b/arch/riscv/boot/dts/starfive/Makefile
>> @@ -8,5 +8,6 @@ DTC_FLAGS_jh7110-starfive-visionfive-2-v1.3b := -@
>> dtb-$(CONFIG_ARCH_STARFIVE) += jh7100-beaglev-starlight.dtb
>> dtb-$(CONFIG_ARCH_STARFIVE) += jh7100-starfive-visionfive-v1.dtb
>>
>> +dtb-$(CONFIG_ARCH_STARFIVE) += jh7110-milkv-mars.dtb
>> dtb-$(CONFIG_ARCH_STARFIVE) += jh7110-starfive-visionfive-2-v1.2a.dtb
>> dtb-$(CONFIG_ARCH_STARFIVE) += jh7110-starfive-visionfive-2-v1.3b.dtb
>> diff --git a/arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts b/arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts
>> new file mode 100644
>> index 000000000000..de600e799e7d
>> --- /dev/null
>> +++ b/arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts
>> @@ -0,0 +1,35 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>> +/*
>> + * Copyright (C) 2023 Jisheng Zhang <jszhang@kernel.org>
>> + */
>> +
>> +/dts-v1/;
>> +#include "jh7110-visionfive2-mars-common.dtsi"
>> +
>> +/ {
>> + model = "Milk-V Mars";
>> + compatible = "milkv,mars", "starfive,jh7110";
>> +};
>> +
>> +&gmac0 {
>> + starfive,tx-use-rgmii-clk;
>> + assigned-clocks = <&aoncrg JH7110_AONCLK_GMAC0_TX>;
>> + assigned-clock-parents = <&aoncrg JH7110_AONCLK_GMAC0_RMII_RTX>;
>> +};
>> +
>> +
>> +&phy0 {
>> + motorcomm,tx-clk-adj-enabled;
>> + motorcomm,tx-clk-10-inverted;
>> + motorcomm,tx-clk-100-inverted;
>> + motorcomm,tx-clk-1000-inverted;
>> + motorcomm,rx-clk-drv-microamp = <3970>;
>> + motorcomm,rx-data-drv-microamp = <2910>;
>> + rx-internal-delay-ps = <1500>;
>> + tx-internal-delay-ps = <1500>;
>> +};
>> +
>> +&mmc1 {
>> + disable-wp;
Due to which difference is 'disable-wp' necessary for the Mars board and
not necessary for the VisionFive 2 board?
>> + cd-gpios = <&sysgpio 41 GPIO_ACTIVE_LOW>;
On my VisionFive 2 1.2B, and 1.3A boards GPIO 41 reflects if an SD-card
is inserted (as shown in U-Boot by gpio status -a). So shouldn't this
value be moved to the common include
"jh7110-visionfive2-mars-common.dtsi" and broken-cd removed from the
VisionFive2 board?
https://doc-en.rvspace.org/VisionFive2/PDF/SCH_RV002_V1.2A_20221216.pdf
has a line
GPIO41 | SD_SDIO0_CD_GPIO41 | Micro SD：J10
Best regards
Heinrich
>> +};
>> --
>> 2.43.0
^ permalink raw reply
* [PATCH v5 0/4] Dynamic Allocation of the reserved_mem array
From: Oreoluwa Babatunde @ 2024-03-28 21:15 UTC (permalink / raw)
To: catalin.marinas, will, robh+dt, frowand.list, vgupta, arnd, olof,
soc, guoren, monstr, palmer, aou, dinguyen, chenhuacai, tsbogend,
jonas, stefan.kristiansson, shorne, mpe, ysato, dalias, glaubitz,
richard, anton.ivanov, johannes, chris, jcmvbkbc
Cc: linux-arm-kernel, linux-kernel, devicetree, linux-arm-msm, kernel,
Oreoluwa Babatunde
The reserved_mem array is used to store data for the different
reserved memory regions defined in the DT of a device. The array
stores information such as region name, node reference, start-address,
and size of the different reserved memory regions.
The array is currently statically allocated with a size of
MAX_RESERVED_REGIONS(64). This means that any system that specifies a
number of reserved memory regions greater than MAX_RESERVED_REGIONS(64)
will not have enough space to store the information for all the regions.
This can be fixed by making the reserved_mem array a dynamically sized
array which is allocated using memblock_alloc() based on the exact
number of reserved memory regions defined in the DT.
On architectures such as arm64, memblock allocated memory is not
writable until after the page tables have been setup.
This is an issue because the current implementation initializes the
reserved memory regions and stores their information in the array before
the page tables are setup. Hence, dynamically allocating the
reserved_mem array and attempting to write information to it at this
point will fail.
Therefore, the allocation of the reserved_mem array will need to be done
after the page tables have been setup, which means that the reserved
memory regions will also need to wait until after the page tables have
been setup to be stored in the array.
When processing the reserved memory regions defined in the DT, these
regions are marked as reserved by calling memblock_reserve(base, size).
Where: base = base address of the reserved region.
size = the size of the reserved memory region.
Depending on if that region is defined using the "no-map" property,
memblock_mark_nomap(base, size) is also called.
The "no-map" property is used to indicate to the operating system that a
mapping of the specified region must NOT be created. This also means
that no access (including speculative accesses) is allowed on this
region of memory except when it is coming from the device driver that
this region of memory is being reserved for.[1]
Therefore, it is important to call memblock_reserve() and
memblock_mark_nomap() on all the reserved memory regions before the
system sets up the page tables so that the system does not unknowingly
include any of the no-map reserved memory regions in the memory map.
There are two ways to define how/where a reserved memory region is
placed in memory:
i) Statically-placed reserved memory regions
i.e. regions defined with a set start address and size using the
"reg" property in the DT.
ii) Dynamically-placed reserved memory regions.
i.e. regions defined by specifying a range of addresses where they can
be placed in memory using the "alloc_ranges" and "size" properties
in the DT.
The dynamically-placed reserved memory regions get assigned a start
address only at runtime. And this needs to be done before the page
tables are setup so that memblock_reserve() and memblock_mark_nomap()
can be called on the allocated region as explained above.
Since the dynamically allocated reserved_mem array can only available
after the page tables have been setup, the information for the
dynamically-placed reserved memory regions needs to be stored somewhere
temporarily until the reserved_mem array is available.
Therefore, this series makes use of a temporary static array to store
the information of the dynamically-placed reserved memory regions until
the reserved_mem array is allocated.
Once the reserved_mem array is available, the information is copied over
from the temporary array into the reserved_mem array, and the memory for
the temporary array is freed back to the system.
The information for the statically-placed reserved memory regions does
not need to be stored in a temporary array because their starting
address is already stored in the devicetree.
Hence, the only thing that needs to be done for these regions before the
page tables are setup is to call memblock_reserve() and
memblock_mark_nomap().
Once the reserved_mem array is allocated, the information for the
statically-placed reserved memory regions is added to the array.
Note:
Because of the use of a temporary array to store the information of the
dynamically-placed reserved memory regions, there still exists a
limitation of 64 for this particular kind of reserved memory regions.
From my observation, these regions are typically small in number and
hence I expect this to not be an issue for now.
Dependency:
This series is dependent on the acceptance of the below patchset for
proper behavior on the sh architecture. The patchset has already been
sent out and is pending review from the sh maintainters.
https://lore.kernel.org/all/1707524971-146908-1-git-send-email-quic_obabatun@quicinc.com/
Patch Versions:
v5 (Current Patchset):
- Rebased changes on top of v6.9-rc1.
- Addressed minor code comments from v4.
v4:
- Move fdt_init_reserved_mem() back into the unflatten_device_tree()
function.
- Fix warnings found by Kernel test robot:
https://lore.kernel.org/all/202401281219.iIhqs1Si-lkp@intel.com/
https://lore.kernel.org/all/202401281304.tsu89Kcm-lkp@intel.com/
https://lore.kernel.org/all/202401291128.e7tdNh5x-lkp@intel.com/
v3:
https://lore.kernel.org/all/20240126235425.12233-1-quic_obabatun@quicinc.com/
- Make use of __initdata to delete the temporary static array after
dynamically allocating memory for reserved_mem array using memblock.
- Move call to fdt_init_reserved_mem() out of the
unflatten_device_tree() function and into architecture specific setup
code.
- Breaking up the changes for the individual architectures into separate
patches.
v2:
https://lore.kernel.org/all/20231204041339.9902-1-quic_obabatun@quicinc.com/
- Extend changes to all other relevant architectures by moving
fdt_init_reserved_mem() into the unflatten_device_tree() function.
- Add code to use unflatten devicetree APIs to process the reserved
memory regions.
v1:
https://lore.kernel.org/all/20231019184825.9712-1-quic_obabatun@quicinc.com/
References:
[1]
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reserved-memory/reserved-memory.yaml#L79
Oreoluwa Babatunde (4):
of: reserved_mem: Restruture how the reserved memory regions are
processed
of: reserved_mem: Add code to dynamically allocate reserved_mem array
of: reserved_mem: Use the unflatten_devicetree APIs to scan reserved
mem. nodes
of: reserved_mem: Rename fdt_* functions to refelct use of
unflatten_devicetree APIs
drivers/of/fdt.c | 5 +-
drivers/of/of_private.h | 3 +-
drivers/of/of_reserved_mem.c | 249 ++++++++++++++++++++++++--------
include/linux/of_reserved_mem.h | 2 +-
kernel/dma/coherent.c | 8 +-
kernel/dma/contiguous.c | 8 +-
kernel/dma/swiotlb.c | 10 +-
7 files changed, 209 insertions(+), 76 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v5 2/4] of: reserved_mem: Add code to dynamically allocate reserved_mem array
From: Oreoluwa Babatunde @ 2024-03-28 21:15 UTC (permalink / raw)
To: catalin.marinas, will, robh+dt, frowand.list, vgupta, arnd, olof,
soc, guoren, monstr, palmer, aou, dinguyen, chenhuacai, tsbogend,
jonas, stefan.kristiansson, shorne, mpe, ysato, dalias, glaubitz,
richard, anton.ivanov, johannes, chris, jcmvbkbc
Cc: linux-arm-kernel, linux-kernel, devicetree, linux-arm-msm, kernel,
Oreoluwa Babatunde
In-Reply-To: <20240328211543.191876-1-quic_obabatun@quicinc.com>
The reserved_mem array is statically allocated with a size of
MAX_RESERVED_REGIONS(64). Therefore, if the number of reserved_mem
regions exceeds this size, there will not be enough space to store
all the data.
Hence, extend the use of the static array by introducing a
dynamically allocated array based on the number of reserved memory
regions specified in the DT.
On architectures such as arm64, memblock allocated memory is not
writable until after the page tables have been setup. Hence, the
dynamic allocation of the reserved_mem array will need to be done only
after the page tables have been setup.
As a result, a temporary static array is still needed in the initial
stages to store the information of the dynamically-placed reserved
memory regions because the start address is selected only at run-time
and is not stored anywhere else.
It is not possible to wait until the reserved_mem array is allocated
because this is done after the page tables are setup and the reserved
memory regions need to be initialized before then.
After the reserved_mem array is allocated, all entries from the static
array is copied over to the new array, and the rest of the information
for the statically-placed reserved memory regions are read in from the
DT and stored in the new array as well.
Once the init process is completed, the temporary static array is
released back to the system because it is no longer needed. This is
achieved by marking it as __initdata.
Signed-off-by: Oreoluwa Babatunde <quic_obabatun@quicinc.com>
---
drivers/of/of_reserved_mem.c | 58 +++++++++++++++++++++++++++++++++---
1 file changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index db991de16cc0..0aba366eba59 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -27,7 +27,9 @@
#include "of_private.h"
-static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
+static struct reserved_mem reserved_mem_array[MAX_RESERVED_REGIONS] __initdata;
+static struct reserved_mem *reserved_mem __refdata = reserved_mem_array;
+static int total_reserved_mem_cnt = MAX_RESERVED_REGIONS;
static int reserved_mem_count;
static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
@@ -55,6 +57,45 @@ static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
return err;
}
+/*
+ * alloc_reserved_mem_array() - allocate memory for the reserved_mem
+ * array using memblock
+ *
+ * This function is used to allocate memory for the reserved_mem array
+ * according to the total number of reserved memory regions defined in
+ * the DT.
+ * After the new array is allocated, the information stored in the
+ * initial static array is copied over to this new array and the new
+ * array is used from this point on.
+ */
+static void __init alloc_reserved_mem_array(void)
+{
+ struct reserved_mem *new_array;
+ size_t alloc_size, copy_size, memset_size;
+
+ alloc_size = array_size(total_reserved_mem_cnt, sizeof(*new_array));
+ if (alloc_size == SIZE_MAX)
+ pr_err("Failed to allocate memory for reserved_mem array with err: %d", -EOVERFLOW);
+
+ new_array = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
+ if (!new_array)
+ pr_err("Failed to allocate memory for reserved_mem array with err: %d", -ENOMEM);
+
+ copy_size = array_size(reserved_mem_count, sizeof(*new_array));
+ if (copy_size == SIZE_MAX) {
+ memblock_free(new_array, alloc_size);
+ total_reserved_mem_cnt = MAX_RESERVED_REGIONS;
+ pr_err("Failed to allocate memory for reserved_mem array with err: %d", -EOVERFLOW);
+ }
+
+ memset_size = alloc_size - copy_size;
+
+ memcpy(new_array, reserved_mem, copy_size);
+ memset(new_array + reserved_mem_count, 0, memset_size);
+
+ reserved_mem = new_array;
+}
+
/*
* fdt_reserved_mem_save_node() - save fdt node for second pass initialization
*/
@@ -63,7 +104,7 @@ static void __init fdt_reserved_mem_save_node(unsigned long node, const char *un
{
struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
- if (reserved_mem_count == ARRAY_SIZE(reserved_mem)) {
+ if (reserved_mem_count == total_reserved_mem_cnt) {
pr_err("not enough space for all defined regions.\n");
return;
}
@@ -220,7 +261,7 @@ static int __init __reserved_mem_alloc_size(unsigned long node, const char *unam
int __init fdt_scan_reserved_mem(void)
{
int node, child;
- int dynamic_nodes_cnt = 0;
+ int dynamic_nodes_cnt = 0, count = 0;
int dynamic_nodes[MAX_RESERVED_REGIONS];
const void *fdt = initial_boot_params;
@@ -243,6 +284,8 @@ int __init fdt_scan_reserved_mem(void)
uname = fdt_get_name(fdt, child, NULL);
err = __reserved_mem_reserve_reg(child, uname);
+ if (!err)
+ count++;
/*
* Save the nodes for the dynamically-placed regions
* into an array which will be used for allocation right
@@ -257,11 +300,16 @@ int __init fdt_scan_reserved_mem(void)
}
for (int i = 0; i < dynamic_nodes_cnt; i++) {
const char *uname;
+ int err;
child = dynamic_nodes[i];
uname = fdt_get_name(fdt, child, NULL);
- __reserved_mem_alloc_size(child, uname);
+
+ err = __reserved_mem_alloc_size(child, uname);
+ if (!err)
+ count++;
}
+ total_reserved_mem_cnt = count++;
return 0;
}
@@ -494,6 +542,8 @@ void __init fdt_init_reserved_mem(void)
{
int i;
+ alloc_reserved_mem_array();
+
fdt_scan_reserved_mem_reg_nodes();
/* check for overlapping reserved regions */
--
2.34.1
^ permalink raw reply related
* [PATCH v5 3/4] of: reserved_mem: Use the unflatten_devicetree APIs to scan reserved mem. nodes
From: Oreoluwa Babatunde @ 2024-03-28 21:15 UTC (permalink / raw)
To: catalin.marinas, will, robh+dt, frowand.list, vgupta, arnd, olof,
soc, guoren, monstr, palmer, aou, dinguyen, chenhuacai, tsbogend,
jonas, stefan.kristiansson, shorne, mpe, ysato, dalias, glaubitz,
richard, anton.ivanov, johannes, chris, jcmvbkbc
Cc: linux-arm-kernel, linux-kernel, devicetree, linux-arm-msm, kernel,
Oreoluwa Babatunde
In-Reply-To: <20240328211543.191876-1-quic_obabatun@quicinc.com>
The unflatten_devicetree APIs have been setup and are available to be
used by the time the fdt_init_reserved_mem() function is called.
Since the unflatten_devicetree APIs are a more efficient way of scanning
through the DT nodes, switch to using these APIs to facilitate the rest
of the reserved memory processing.
Signed-off-by: Oreoluwa Babatunde <quic_obabatun@quicinc.com>
---
drivers/of/of_reserved_mem.c | 77 +++++++++++++++++++++------------
include/linux/of_reserved_mem.h | 2 +-
kernel/dma/coherent.c | 8 ++--
kernel/dma/contiguous.c | 8 ++--
kernel/dma/swiotlb.c | 10 ++---
5 files changed, 64 insertions(+), 41 deletions(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 0aba366eba59..68d1f4cca4bb 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -99,7 +99,7 @@ static void __init alloc_reserved_mem_array(void)
/*
* fdt_reserved_mem_save_node() - save fdt node for second pass initialization
*/
-static void __init fdt_reserved_mem_save_node(unsigned long node, const char *uname,
+static void __init fdt_reserved_mem_save_node(struct device_node *node, const char *uname,
phys_addr_t base, phys_addr_t size)
{
struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
@@ -109,7 +109,7 @@ static void __init fdt_reserved_mem_save_node(unsigned long node, const char *un
return;
}
- rmem->fdt_node = node;
+ rmem->dev_node = node;
rmem->name = uname;
rmem->base = base;
rmem->size = size;
@@ -178,11 +178,11 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
}
/*
- * __reserved_mem_check_root() - check if #size-cells, #address-cells provided
+ * __fdt_reserved_mem_check_root() - check if #size-cells, #address-cells provided
* in /reserved-memory matches the values supported by the current implementation,
* also check if ranges property has been provided
*/
-static int __init __reserved_mem_check_root(unsigned long node)
+static int __init __fdt_reserved_mem_check_root(unsigned long node)
{
const __be32 *prop;
@@ -200,6 +200,29 @@ static int __init __reserved_mem_check_root(unsigned long node)
return 0;
}
+/*
+ * __dt_reserved_mem_check_root() - check if #size-cells, #address-cells provided
+ * in /reserved-memory matches the values supported by the current implementation,
+ * also check if ranges property has been provided
+ */
+static int __init __dt_reserved_mem_check_root(struct device_node *node)
+{
+ const __be32 *prop;
+
+ prop = of_get_property(node, "#size-cells", NULL);
+ if (!prop || be32_to_cpup(prop) != dt_root_size_cells)
+ return -EINVAL;
+
+ prop = of_get_property(node, "#address-cells", NULL);
+ if (!prop || be32_to_cpup(prop) != dt_root_addr_cells)
+ return -EINVAL;
+
+ prop = of_get_property(node, "ranges", NULL);
+ if (!prop)
+ return -EINVAL;
+ return 0;
+}
+
/**
* fdt_scan_reserved_mem_reg_nodes() - Store info for the "reg" defined
* reserved memory regions.
@@ -213,33 +236,38 @@ static int __init __reserved_mem_check_root(unsigned long node)
static void __init fdt_scan_reserved_mem_reg_nodes(void)
{
int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
- const void *fdt = initial_boot_params;
+ struct device_node *node, *child;
phys_addr_t base, size;
const __be32 *prop;
- int node, child;
int len;
- node = fdt_path_offset(fdt, "/reserved-memory");
- if (node < 0) {
+ node = of_find_node_by_path("/reserved-memory");
+ if (!node) {
pr_info("Reserved memory: No reserved-memory node in the DT\n");
return;
}
- if (__reserved_mem_check_root(node)) {
+ if (__dt_reserved_mem_check_root(node)) {
pr_err("Reserved memory: unsupported node format, ignoring\n");
return;
}
- fdt_for_each_subnode(child, fdt, node) {
+ for_each_child_of_node(node, child) {
const char *uname;
+ struct reserved_mem *rmem;
- prop = of_get_flat_dt_prop(child, "reg", &len);
- if (!prop)
+ if (!of_device_is_available(child))
continue;
- if (!of_fdt_device_is_available(fdt, child))
+
+ prop = of_get_property(child, "reg", &len);
+ if (!prop) {
+ rmem = of_reserved_mem_lookup(child);
+ if (rmem)
+ rmem->dev_node = child;
continue;
+ }
- uname = fdt_get_name(fdt, child, NULL);
+ uname = of_node_full_name(child);
if (len && len % t_len != 0) {
pr_err("Reserved memory: invalid reg property in '%s', skipping node.\n",
uname);
@@ -269,7 +297,7 @@ int __init fdt_scan_reserved_mem(void)
if (node < 0)
return -ENODEV;
- if (__reserved_mem_check_root(node) != 0) {
+ if (__fdt_reserved_mem_check_root(node) != 0) {
pr_err("Reserved memory: unsupported node format, ignoring\n");
return -EINVAL;
}
@@ -447,7 +475,7 @@ static int __init __reserved_mem_alloc_size(unsigned long node, const char *unam
uname, (unsigned long)(size / SZ_1M));
return -ENOMEM;
}
- fdt_reserved_mem_save_node(node, uname, base, size);
+ fdt_reserved_mem_save_node(NULL, uname, base, size);
return 0;
}
@@ -467,7 +495,7 @@ static int __init __reserved_mem_init_node(struct reserved_mem *rmem)
reservedmem_of_init_fn initfn = i->data;
const char *compat = i->compatible;
- if (!of_flat_dt_is_compatible(rmem->fdt_node, compat))
+ if (!of_device_is_compatible(rmem->dev_node, compat))
continue;
ret = initfn(rmem);
@@ -500,11 +528,6 @@ static int __init __rmem_cmp(const void *a, const void *b)
if (ra->size > rb->size)
return 1;
- if (ra->fdt_node < rb->fdt_node)
- return -1;
- if (ra->fdt_node > rb->fdt_node)
- return 1;
-
return 0;
}
@@ -551,16 +574,16 @@ void __init fdt_init_reserved_mem(void)
for (i = 0; i < reserved_mem_count; i++) {
struct reserved_mem *rmem = &reserved_mem[i];
- unsigned long node = rmem->fdt_node;
+ struct device_node *node = rmem->dev_node;
int len;
const __be32 *prop;
int err = 0;
bool nomap;
- nomap = of_get_flat_dt_prop(node, "no-map", NULL) != NULL;
- prop = of_get_flat_dt_prop(node, "phandle", &len);
+ nomap = of_get_property(node, "no-map", NULL) != NULL;
+ prop = of_get_property(node, "phandle", &len);
if (!prop)
- prop = of_get_flat_dt_prop(node, "linux,phandle", &len);
+ prop = of_get_property(node, "linux,phandle", &len);
if (prop)
rmem->phandle = of_read_number(prop, len/4);
@@ -574,7 +597,7 @@ void __init fdt_init_reserved_mem(void)
} else {
phys_addr_t end = rmem->base + rmem->size - 1;
bool reusable =
- (of_get_flat_dt_prop(node, "reusable", NULL)) != NULL;
+ (of_get_property(node, "reusable", NULL)) != NULL;
pr_info("%pa..%pa (%lu KiB) %s %s %s\n",
&rmem->base, &end, (unsigned long)(rmem->size / SZ_1K),
diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
index 4de2a24cadc9..b6107a18d170 100644
--- a/include/linux/of_reserved_mem.h
+++ b/include/linux/of_reserved_mem.h
@@ -10,7 +10,7 @@ struct reserved_mem_ops;
struct reserved_mem {
const char *name;
- unsigned long fdt_node;
+ struct device_node *dev_node;
unsigned long phandle;
const struct reserved_mem_ops *ops;
phys_addr_t base;
diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c
index ff5683a57f77..0db0aae83102 100644
--- a/kernel/dma/coherent.c
+++ b/kernel/dma/coherent.c
@@ -362,20 +362,20 @@ static const struct reserved_mem_ops rmem_dma_ops = {
static int __init rmem_dma_setup(struct reserved_mem *rmem)
{
- unsigned long node = rmem->fdt_node;
+ struct device_node *node = rmem->dev_node;
- if (of_get_flat_dt_prop(node, "reusable", NULL))
+ if (of_get_property(node, "reusable", NULL))
return -EINVAL;
#ifdef CONFIG_ARM
- if (!of_get_flat_dt_prop(node, "no-map", NULL)) {
+ if (!of_get_property(node, "no-map", NULL)) {
pr_err("Reserved memory: regions without no-map are not yet supported\n");
return -EINVAL;
}
#endif
#ifdef CONFIG_DMA_GLOBAL_POOL
- if (of_get_flat_dt_prop(node, "linux,dma-default", NULL)) {
+ if (of_get_property(node, "linux,dma-default", NULL)) {
WARN(dma_reserved_default_memory,
"Reserved memory: region for default DMA coherent area is redefined\n");
dma_reserved_default_memory = rmem;
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 055da410ac71..22507f7d74d9 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -456,8 +456,8 @@ static const struct reserved_mem_ops rmem_cma_ops = {
static int __init rmem_cma_setup(struct reserved_mem *rmem)
{
- unsigned long node = rmem->fdt_node;
- bool default_cma = of_get_flat_dt_prop(node, "linux,cma-default", NULL);
+ struct device_node *node = rmem->dev_node;
+ bool default_cma = of_get_property(node, "linux,cma-default", NULL);
struct cma *cma;
int err;
@@ -467,8 +467,8 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
return -EBUSY;
}
- if (!of_get_flat_dt_prop(node, "reusable", NULL) ||
- of_get_flat_dt_prop(node, "no-map", NULL))
+ if (!of_get_property(node, "reusable", NULL) ||
+ of_get_property(node, "no-map", NULL))
return -EINVAL;
if (!IS_ALIGNED(rmem->base | rmem->size, CMA_MIN_ALIGNMENT_BYTES)) {
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 86fe172b5958..22cf195f652c 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -1799,12 +1799,12 @@ static const struct reserved_mem_ops rmem_swiotlb_ops = {
static int __init rmem_swiotlb_setup(struct reserved_mem *rmem)
{
- unsigned long node = rmem->fdt_node;
+ struct device_node *node = rmem->dev_node;
- if (of_get_flat_dt_prop(node, "reusable", NULL) ||
- of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
- of_get_flat_dt_prop(node, "linux,dma-default", NULL) ||
- of_get_flat_dt_prop(node, "no-map", NULL))
+ if (of_get_property(node, "reusable", NULL) ||
+ of_get_property(node, "linux,cma-default", NULL) ||
+ of_get_property(node, "linux,dma-default", NULL) ||
+ of_get_property(node, "no-map", NULL))
return -EINVAL;
rmem->ops = &rmem_swiotlb_ops;
--
2.34.1
^ permalink raw reply related
* [PATCH v5 1/4] of: reserved_mem: Restruture how the reserved memory regions are processed
From: Oreoluwa Babatunde @ 2024-03-28 21:15 UTC (permalink / raw)
To: catalin.marinas, will, robh+dt, frowand.list, vgupta, arnd, olof,
soc, guoren, monstr, palmer, aou, dinguyen, chenhuacai, tsbogend,
jonas, stefan.kristiansson, shorne, mpe, ysato, dalias, glaubitz,
richard, anton.ivanov, johannes, chris, jcmvbkbc
Cc: linux-arm-kernel, linux-kernel, devicetree, linux-arm-msm, kernel,
Oreoluwa Babatunde
In-Reply-To: <20240328211543.191876-1-quic_obabatun@quicinc.com>
The current implementation processes the reserved memory regions in two
stages which are done with two separate functions within the
early_init_fdt_scan_reserved_mem() function.
Within the two stages of processing, the reserved memory regions are
broken up into two groups which are processed differently:
i) Statically-placed reserved memory regions
i.e. regions defined with a static start address and size using the
"reg" property in the DT.
ii) Dynamically-placed reserved memory regions.
i.e. regions defined by specifying a range of addresses where they can
be placed in memory using the "alloc_ranges" and "size" properties
in the DT.
Stage 1: fdt_scan_reserved_mem()
This stage of the reserved memory processing is used to scan through the
reserved memory nodes defined in the devicetree and do the following on
each of the nodes:
1) If the node represents a statically-placed reserved memory region,
i.e. it is defined using the "reg" property:
- Call memblock_reserve() or memblock_mark_nomap() as needed.
- Add the information for the reserved region to the reserved_mem
array.
eg: fdt_reserved_mem_save_node(node, name, base, size);
2) If the node represents a dynamically-placed reserved memory region,
i.e. it is defined using "alloc-ranges" and "size" properties:
- Add the information for the region to the reserved_mem array with
the starting address and size set to 0.
eg: fdt_reserved_mem_save_node(node, name, 0, 0);
Stage 2: fdt_init_reserved_mem()
This stage of the reserved memory processing is used to iterate through
the reserved_mem array which was populated in stage 1 and do the
following on each of the entries:
1) If the entry represents a statically-placed reserved memory region:
- Call the region specific init function.
2) If the entry represents a dynamically-placed reserved memory region:
- Call __reserved_mem_alloc_size() which is used to allocate memory
for the region using memblock_phys_alloc_range(), and call
memblock_mark_nomap() on the allocated region if the region is
specified as a no-map region.
- Call the region specific init function.
On architectures such as arm64, the dynamic allocation of the
reserved_mem array needs to be done after the page tables have been
setup because memblock allocated memory is not writable until then. This
means that the reserved_mem array will not be available to store any
reserved memory information until after the page tables have been setup.
It is possible to call memblock_reserve() and memblock_mark_nomap() on
the statically-placed reserved memory regions and not need to save them
to the reserved_mem array until later. This is because all the
information we need is present in the devicetree.
Dynamically-placed reserved memory regions on the other hand get
assigned a start address only at runtime, and since memblock_reserve()
and memblock_mark_nomap() need to be called before the memory mappings
are created, the allocation needs to happen before the page tables are
setup.
To make it easier to handle dynamically-placed reserved memory regions
before the page tables are setup, this patch makes changes to the steps
above to process the reserved memory regions in the following ways:
Step 1: fdt_scan_reserved_mem()
This stage of the reserved memory processing is used to scan through the
reserved memory nodes defined in the devicetree and do the following on
each of the nodes:
1) If the node represents a statically-placed reserved memory region,
i.e. it is defined using the "reg" property:
- Call memblock_reserve() or memblock_mark_nomap() as needed.
2) If the node represents a dynamically-placed reserved memory region,
i.e. it is defined using "alloc-ranges" and "size" properties:
- Call __reserved_mem_alloc_size() which will:
i) Allocate memory for the reserved memory region.
ii) Call memblock_mark_nomap() as needed.
Note: There is no need to explicitly call memblock_reserve() here
because it is already called by memblock when the memory for the
region is being allocated.
iii) Save the information for the region in the reserved_mem array.
Step 2: fdt_init_reserved_mem()
This stage of the reserved memory processing is used to:
1) Add the information for the statically-placed reserved memory into
the reserved_mem array.
2) Iterate through all the entries in the array and call the region
specific init function for each of them.
fdt_init_reserved_mem() is also now called from within the
unflatten_device_tree() function so that this step happens after the
page tables have been setup.
Signed-off-by: Oreoluwa Babatunde <quic_obabatun@quicinc.com>
---
drivers/of/fdt.c | 5 +-
drivers/of/of_private.h | 1 +
drivers/of/of_reserved_mem.c | 134 +++++++++++++++++++++++++----------
3 files changed, 100 insertions(+), 40 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index a8a04f27915b..527e6bc1c096 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -532,8 +532,6 @@ void __init early_init_fdt_scan_reserved_mem(void)
break;
memblock_reserve(base, size);
}
-
- fdt_init_reserved_mem();
}
/**
@@ -1259,6 +1257,9 @@ void __init unflatten_device_tree(void)
of_alias_scan(early_init_dt_alloc_memory_arch);
unittest_unflatten_overlay_base();
+
+ /* initialize the reserved memory regions */
+ fdt_init_reserved_mem();
}
/**
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 485483524b7f..9ea250b80657 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -9,6 +9,7 @@
*/
#define FDT_ALIGN_SIZE 8
+#define MAX_RESERVED_REGIONS 64
/**
* struct alias_prop - Alias property in 'aliases' node
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 8236ecae2953..db991de16cc0 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -27,7 +27,6 @@
#include "of_private.h"
-#define MAX_RESERVED_REGIONS 64
static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
static int reserved_mem_count;
@@ -106,7 +105,6 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
phys_addr_t base, size;
int len;
const __be32 *prop;
- int first = 1;
bool nomap;
prop = of_get_flat_dt_prop(node, "reg", &len);
@@ -134,10 +132,6 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
uname, &base, (unsigned long)(size / SZ_1M));
len -= t_len;
- if (first) {
- fdt_reserved_mem_save_node(node, uname, base, size);
- first = 0;
- }
}
return 0;
}
@@ -165,12 +159,69 @@ static int __init __reserved_mem_check_root(unsigned long node)
return 0;
}
+/**
+ * fdt_scan_reserved_mem_reg_nodes() - Store info for the "reg" defined
+ * reserved memory regions.
+ *
+ * This function is used to scan through the DT and store the
+ * information for the reserved memory regions that are defined using
+ * the "reg" property. The region node number, name, base address, and
+ * size are all stored in the reserved_mem array by calling the
+ * fdt_reserved_mem_save_node() function.
+ */
+static void __init fdt_scan_reserved_mem_reg_nodes(void)
+{
+ int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
+ const void *fdt = initial_boot_params;
+ phys_addr_t base, size;
+ const __be32 *prop;
+ int node, child;
+ int len;
+
+ node = fdt_path_offset(fdt, "/reserved-memory");
+ if (node < 0) {
+ pr_info("Reserved memory: No reserved-memory node in the DT\n");
+ return;
+ }
+
+ if (__reserved_mem_check_root(node)) {
+ pr_err("Reserved memory: unsupported node format, ignoring\n");
+ return;
+ }
+
+ fdt_for_each_subnode(child, fdt, node) {
+ const char *uname;
+
+ prop = of_get_flat_dt_prop(child, "reg", &len);
+ if (!prop)
+ continue;
+ if (!of_fdt_device_is_available(fdt, child))
+ continue;
+
+ uname = fdt_get_name(fdt, child, NULL);
+ if (len && len % t_len != 0) {
+ pr_err("Reserved memory: invalid reg property in '%s', skipping node.\n",
+ uname);
+ continue;
+ }
+ base = dt_mem_next_cell(dt_root_addr_cells, &prop);
+ size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+ if (size)
+ fdt_reserved_mem_save_node(child, uname, base, size);
+ }
+}
+
+static int __init __reserved_mem_alloc_size(unsigned long node, const char *uname);
+
/*
* fdt_scan_reserved_mem() - scan a single FDT node for reserved memory
*/
int __init fdt_scan_reserved_mem(void)
{
int node, child;
+ int dynamic_nodes_cnt = 0;
+ int dynamic_nodes[MAX_RESERVED_REGIONS];
const void *fdt = initial_boot_params;
node = fdt_path_offset(fdt, "/reserved-memory");
@@ -192,8 +243,24 @@ int __init fdt_scan_reserved_mem(void)
uname = fdt_get_name(fdt, child, NULL);
err = __reserved_mem_reserve_reg(child, uname);
- if (err == -ENOENT && of_get_flat_dt_prop(child, "size", NULL))
- fdt_reserved_mem_save_node(child, uname, 0, 0);
+ /*
+ * Save the nodes for the dynamically-placed regions
+ * into an array which will be used for allocation right
+ * after all the statically-placed regions are reserved
+ * or marked as no-map. This is done to avoid dynamically
+ * allocating from one of the statically-placed regions.
+ */
+ if (err == -ENOENT && of_get_flat_dt_prop(child, "size", NULL)) {
+ dynamic_nodes[dynamic_nodes_cnt] = child;
+ dynamic_nodes_cnt++;
+ }
+ }
+ for (int i = 0; i < dynamic_nodes_cnt; i++) {
+ const char *uname;
+
+ child = dynamic_nodes[i];
+ uname = fdt_get_name(fdt, child, NULL);
+ __reserved_mem_alloc_size(child, uname);
}
return 0;
}
@@ -253,8 +320,7 @@ static int __init __reserved_mem_alloc_in_range(phys_addr_t size,
* __reserved_mem_alloc_size() - allocate reserved memory described by
* 'size', 'alignment' and 'alloc-ranges' properties.
*/
-static int __init __reserved_mem_alloc_size(unsigned long node,
- const char *uname, phys_addr_t *res_base, phys_addr_t *res_size)
+static int __init __reserved_mem_alloc_size(unsigned long node, const char *uname)
{
int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
phys_addr_t start = 0, end = 0;
@@ -333,10 +399,7 @@ static int __init __reserved_mem_alloc_size(unsigned long node,
uname, (unsigned long)(size / SZ_1M));
return -ENOMEM;
}
-
- *res_base = base;
- *res_size = size;
-
+ fdt_reserved_mem_save_node(node, uname, base, size);
return 0;
}
@@ -431,6 +494,8 @@ void __init fdt_init_reserved_mem(void)
{
int i;
+ fdt_scan_reserved_mem_reg_nodes();
+
/* check for overlapping reserved regions */
__rmem_check_for_overlap();
@@ -449,30 +514,23 @@ void __init fdt_init_reserved_mem(void)
if (prop)
rmem->phandle = of_read_number(prop, len/4);
- if (rmem->size == 0)
- err = __reserved_mem_alloc_size(node, rmem->name,
- &rmem->base, &rmem->size);
- if (err == 0) {
- err = __reserved_mem_init_node(rmem);
- if (err != 0 && err != -ENOENT) {
- pr_info("node %s compatible matching fail\n",
- rmem->name);
- if (nomap)
- memblock_clear_nomap(rmem->base, rmem->size);
- else
- memblock_phys_free(rmem->base,
- rmem->size);
- } else {
- phys_addr_t end = rmem->base + rmem->size - 1;
- bool reusable =
- (of_get_flat_dt_prop(node, "reusable", NULL)) != NULL;
-
- pr_info("%pa..%pa (%lu KiB) %s %s %s\n",
- &rmem->base, &end, (unsigned long)(rmem->size / SZ_1K),
- nomap ? "nomap" : "map",
- reusable ? "reusable" : "non-reusable",
- rmem->name ? rmem->name : "unknown");
- }
+ err = __reserved_mem_init_node(rmem);
+ if (err != 0 && err != -ENOENT) {
+ pr_info("node %s compatible matching fail\n", rmem->name);
+ if (nomap)
+ memblock_clear_nomap(rmem->base, rmem->size);
+ else
+ memblock_phys_free(rmem->base, rmem->size);
+ } else {
+ phys_addr_t end = rmem->base + rmem->size - 1;
+ bool reusable =
+ (of_get_flat_dt_prop(node, "reusable", NULL)) != NULL;
+
+ pr_info("%pa..%pa (%lu KiB) %s %s %s\n",
+ &rmem->base, &end, (unsigned long)(rmem->size / SZ_1K),
+ nomap ? "nomap" : "map",
+ reusable ? "reusable" : "non-reusable",
+ rmem->name ? rmem->name : "unknown");
}
}
}
--
2.34.1
^ permalink raw reply related
* [PATCH v5 4/4] of: reserved_mem: Rename fdt_* functions to refelct use of unflatten_devicetree APIs
From: Oreoluwa Babatunde @ 2024-03-28 21:15 UTC (permalink / raw)
To: catalin.marinas, will, robh+dt, frowand.list, vgupta, arnd, olof,
soc, guoren, monstr, palmer, aou, dinguyen, chenhuacai, tsbogend,
jonas, stefan.kristiansson, shorne, mpe, ysato, dalias, glaubitz,
richard, anton.ivanov, johannes, chris, jcmvbkbc
Cc: linux-arm-kernel, linux-kernel, devicetree, linux-arm-msm, kernel,
Oreoluwa Babatunde
In-Reply-To: <20240328211543.191876-1-quic_obabatun@quicinc.com>
Rename the relevant fdt_* functions to a new naming scheme, dt_*, to
reflect the use of the unflatten_devicetree APIs to scan through the
reserved memory regions defined in the DT.
Signed-off-by: Oreoluwa Babatunde <quic_obabatun@quicinc.com>
---
drivers/of/fdt.c | 2 +-
drivers/of/of_private.h | 2 +-
drivers/of/of_reserved_mem.c | 22 +++++++++++-----------
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 527e6bc1c096..7e1baf443286 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1259,7 +1259,7 @@ void __init unflatten_device_tree(void)
unittest_unflatten_overlay_base();
/* initialize the reserved memory regions */
- fdt_init_reserved_mem();
+ dt_init_reserved_mem();
}
/**
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 9ea250b80657..75726feac881 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -177,7 +177,7 @@ static inline struct device_node *__of_get_dma_parent(const struct device_node *
#endif
int fdt_scan_reserved_mem(void);
-void fdt_init_reserved_mem(void);
+void dt_init_reserved_mem(void);
bool of_fdt_device_is_available(const void *blob, unsigned long node);
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 68d1f4cca4bb..3ae5918a0024 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -97,10 +97,10 @@ static void __init alloc_reserved_mem_array(void)
}
/*
- * fdt_reserved_mem_save_node() - save fdt node for second pass initialization
+ * dt_reserved_mem_save_node() - save the device_node for second pass initialization
*/
-static void __init fdt_reserved_mem_save_node(struct device_node *node, const char *uname,
- phys_addr_t base, phys_addr_t size)
+static void __init dt_reserved_mem_save_node(struct device_node *node, const char *uname,
+ phys_addr_t base, phys_addr_t size)
{
struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
@@ -224,16 +224,16 @@ static int __init __dt_reserved_mem_check_root(struct device_node *node)
}
/**
- * fdt_scan_reserved_mem_reg_nodes() - Store info for the "reg" defined
+ * dt_scan_reserved_mem_reg_nodes() - Store info for the "reg" defined
* reserved memory regions.
*
* This function is used to scan through the DT and store the
* information for the reserved memory regions that are defined using
* the "reg" property. The region node number, name, base address, and
* size are all stored in the reserved_mem array by calling the
- * fdt_reserved_mem_save_node() function.
+ * dt_reserved_mem_save_node() function.
*/
-static void __init fdt_scan_reserved_mem_reg_nodes(void)
+static void __init dt_scan_reserved_mem_reg_nodes(void)
{
int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
struct device_node *node, *child;
@@ -277,7 +277,7 @@ static void __init fdt_scan_reserved_mem_reg_nodes(void)
size = dt_mem_next_cell(dt_root_size_cells, &prop);
if (size)
- fdt_reserved_mem_save_node(child, uname, base, size);
+ dt_reserved_mem_save_node(child, uname, base, size);
}
}
@@ -475,7 +475,7 @@ static int __init __reserved_mem_alloc_size(unsigned long node, const char *unam
uname, (unsigned long)(size / SZ_1M));
return -ENOMEM;
}
- fdt_reserved_mem_save_node(NULL, uname, base, size);
+ dt_reserved_mem_save_node(NULL, uname, base, size);
return 0;
}
@@ -559,15 +559,15 @@ static void __init __rmem_check_for_overlap(void)
}
/**
- * fdt_init_reserved_mem() - allocate and init all saved reserved memory regions
+ * dt_init_reserved_mem() - allocate and init all saved reserved memory regions
*/
-void __init fdt_init_reserved_mem(void)
+void __init dt_init_reserved_mem(void)
{
int i;
alloc_reserved_mem_array();
- fdt_scan_reserved_mem_reg_nodes();
+ dt_scan_reserved_mem_reg_nodes();
/* check for overlapping reserved regions */
__rmem_check_for_overlap();
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 22/23] drivers: media: i2c: imx258: Add support for powerdown gpio
From: Luigi311 @ 2024-03-28 21:11 UTC (permalink / raw)
To: Rob Herring
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, Ondrej Jirman
In-Reply-To: <20240328204841.GA318468-robh@kernel.org>
On 3/28/24 14:48, Rob Herring wrote:
> On Wed, Mar 27, 2024 at 05:17:08PM -0600, git@luigi311.com wrote:
>> From: Luigi311 <git@luigi311.com>
>>
>> On some boards powerdown signal needs to be deasserted for this
>> sensor to be enabled.
>>
>> Signed-off-by: Ondrej Jirman <megi@xff.cz>
>> ---
>> .../devicetree/bindings/media/i2c/sony,imx258.yaml | 4 ++++
>
> Bindings should be a separate patch.
>
Ok ill create separate patch for adding in the binding and then
a follow up patch with the other half that actually adds it to
the driver
>> drivers/media/i2c/imx258.c | 13 +++++++++++++
>> 2 files changed, 17 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>> index c7856de15ba3..0414085bf22f 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>> @@ -35,6 +35,10 @@ properties:
>> reg:
>> maxItems: 1
>>
>> + powerdown-gpios:
>> + description: |-
>
> Don't need '|-' if no formatting>
Done
>> + Reference to the GPIO connected to the PWDN pin, if any.
>> +
>> reset-gpios:
>> description: |-
>> Reference to the GPIO connected to the XCLR pin, if any.
^ permalink raw reply
* Re: [PATCH 18/23] dt-bindings: media: imx258: Add alternate compatible strings
From: Luigi311 @ 2024-03-28 21:02 UTC (permalink / raw)
To: Rob Herring
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240328204657.GA314523-robh@kernel.org>
On 3/28/24 14:46, Rob Herring wrote:
> On Thu, Mar 28, 2024 at 01:16:22PM -0600, Luigi311 wrote:
>> On 3/28/24 12:55, Rob Herring wrote:
>>> On Wed, Mar 27, 2024 at 05:17:04PM -0600, git@luigi311.com wrote:
>>>> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>>>>
>>>> There are a number of variants of the imx258 modules that can not
>>>> be differentiated at runtime, so add compatible strings for them.
>>>> But you are only adding 1 variant.
>>
>> I can not speak for Dave but as to why this was added here but looking
>> at the imx296 yaml that has something similar where there are multiple
>> variants that may not be detectable at run time but does not include
>> similar verbiage in the main description. Should I drop this from the
>> description so it matches the imx296?
>
> Just change "add compatible strings for them" to "add compatible string
> for the PDAF variant" or something.
>
Ohh i see what you mean now, this is in reference to the commit message,
it was throwing me off because the imx258 description had almost the
exact same wording. Yes that makes sense, ill change the commit
message to specify PDAF.
>>
>>>
>>>>
>>>> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
>>>> Signed-off-by: Luigi311 <git@luigi311.com>
>>>> ---
>>>> .../devicetree/bindings/media/i2c/sony,imx258.yaml | 6 +++++-
>>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>>>> index bee61a443b23..c7856de15ba3 100644
>>>> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>>>> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>>>> @@ -14,10 +14,14 @@ description: |-
>>>> type stacked image sensor with a square pixel array of size 4208 x 3120. It
>>>> is programmable through I2C interface. Image data is sent through MIPI
>>>> CSI-2.
>>>> + There are a number of variants of the sensor which cannot be detected at
>>>> + runtime, so multiple compatible strings are required to differentiate these.
>>>
>>> That's more reasoning/why for the patch than description of the h/w.
>>>
>>>> properties:
>>>> compatible:
>>>> - const: sony,imx258
>>>> + - enum:
>>>> + - sony,imx258
>>>> + - sony,imx258-pdaf
>>>
>>> How do I know which one to use? Please define what PDAF means somewhere
>>> as well as perhaps what the original/default variant is or isn't.
>>
>> Would it make sense to change the properties to include a description like so
>>
>> properties:
>> compatible:
>> enum:
>> - sony,imx258
>> - sony,imx258-pdaf
>> description:
>> The IMX258 sensor exists in two different models, a standard variant
>> (IMX258) and a variant with phase detection autofocus (IMX258-PDAF).
>> The camera module does not expose the model through registers, so the
>> exact model needs to be specified.
>
> Looks fine, but I'd move this to the top-level 'description'.
>
> Rob
Perfect ill move this to the top level description and remove that small section
that Dave added
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: Add support for Samsung Galaxy Z Fold5
From: Rob Herring @ 2024-03-28 21:01 UTC (permalink / raw)
To: Alexandru Marc Serdeliuc
Cc: Konrad Dybcio, devicetree, linux-kernel, linux-arm-msm,
Bjorn Andersson, Conor Dooley, Krzysztof Kozlowski
In-Reply-To: <20240328-arm64-dts-add-support-for-samsung-galaxy-zfold5-v1-1-9434150d0465@yahoo.com>
On Thu, 28 Mar 2024 15:57:44 +0100, Alexandru Marc Serdeliuc wrote:
> Add support for Samsung Galaxy Z Fold5 (q5q) foldable phone
>
> Currently working features:
> - Framebuffer
> - UFS
> - i2c
> - Buttons
>
> Signed-off-by: Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dts | 616 ++++++++++++++++++++++++
> 2 files changed, 617 insertions(+)
>
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/sm8550-samsung-q5q.dtb' for 20240328-arm64-dts-add-support-for-samsung-galaxy-zfold5-v1-1-9434150d0465@yahoo.com:
arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dtb: /: failed to match any schema with compatible: ['samsung,q5q', 'qcom,sm8550']
^ permalink raw reply
* Re: [PATCH 0/3] Add support for Emcraft Systems NavQ+ kit
From: Rob Herring @ 2024-03-28 21:01 UTC (permalink / raw)
To: Gilles Talis
Cc: shawnguo, linux-arm-kernel, festevam, devicetree, conor+dt, imx,
alex, krzysztof.kozlowski+dt
In-Reply-To: <20240328202320.187596-1-gilles.talis@gmail.com>
On Thu, 28 Mar 2024 16:23:17 -0400, Gilles Talis wrote:
> Hello
>
> This series adds a device tree file for the Emcraft Systems NavQ+ kit [1]
>
> The first patch adds a new vendor prefix for Emcraft Systems
> The second one adds the board to the arm/fsl.yaml DT bindings.
> Last patch adds device tree file for the kit.
>
> [1] https://www.emcraft.com/products/1222
>
>
> Gilles Talis (3):
> dt-bindings: vendor-prefixes: Add Emcraft Systems
> dt-bindings: arm: Add Emcraft Systems i.MX8M Plus NavQ+ Kit
> arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
>
> .../devicetree/bindings/arm/fsl.yaml | 1 +
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> .../arm64/boot/dts/freescale/imx8mp-navqp.dts | 435 ++++++++++++++++++
> 4 files changed, 439 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
>
>
> base-commit: 4cece764965020c22cff7665b18a012006359095
> --
> 2.39.2
>
>
>
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 freescale/imx8mp-navqp.dtb' for 20240328202320.187596-1-gilles.talis@gmail.com:
arch/arm64/boot/dts/freescale/imx8mp-navqp.dtb: pinctrl@30330000: 'pmicirq', 'usdhc2grp-100mhz', 'usdhc2grp-200mhz', 'usdhc2grp-gpio', 'usdhc3grp-100mhz', 'usdhc3grp-200mhz' do not match any of the regexes: 'grp$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/pinctrl/fsl,imx8m-pinctrl.yaml#
arch/arm64/boot/dts/freescale/imx8mp-navqp.dtb: pinctrl@30330000: usdhc2grp-gpio: {'fsl,pins': [[188, 796, 0, 5, 0, 452]], 'phandle': [[51]]} is not of type 'array'
from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer.yaml#
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: ti: Add BeagleY-AI
From: Rob Herring @ 2024-03-28 21:01 UTC (permalink / raw)
To: Robert Nelson
Cc: Jared McArthur, Jason Kridner, linux-arm-kernel, devicetree,
Nishanth Menon, Deepak Khatri, linux-kernel
In-Reply-To: <20240328191205.82295-1-robertcnelson@gmail.com>
On Thu, 28 Mar 2024 14:12:04 -0500, Robert Nelson wrote:
> This board is based on ti,j722s
>
> https://beagley-ai.org/
> https://openbeagle.org/beagley-ai/beagley-ai
>
> Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
> CC: Rob Herring <robh@kernel.org>
> CC: Nishanth Menon <nm@ti.com>
> CC: Jared McArthur <j-mcarthur@ti.com>
> CC: Jason Kridner <jkridner@beagleboard.org>
> CC: Deepak Khatri <lorforlinux@beagleboard.org>
> ---
> Documentation/devicetree/bindings/arm/ti/k3.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
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 ti/k3-j722s-beagley-ai.dtb' for 20240328191205.82295-1-robertcnelson@gmail.com:
arch/arm64/boot/dts/ti/k3-j722s-beagley-ai.dtb: pinctrl@f4000: 'vdd-3v3-sd-pins-default' does not match any of the regexes: '-pins(-[0-9]+)?$|-pin$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/pinctrl/pinctrl-single.yaml#
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx7s-warp: Pass OV2680 link-frequencies
From: Rob Herring @ 2024-03-28 21:01 UTC (permalink / raw)
To: Fabio Estevam
Cc: Fabio Estevam, linux-arm-kernel, sakari.ailus, stable, hdegoede,
devicetree, shawnguo, conor+dt, krzysztof.kozlowski+dt
In-Reply-To: <20240328151954.2517368-1-festevam@gmail.com>
On Thu, 28 Mar 2024 12:19:54 -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
>
> Since commit 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint
> property verification") the ov2680 no longer probes on a imx7s-warp7:
>
> ov2680 1-0036: error -EINVAL: supported link freq 330000000 not found
> ov2680 1-0036: probe with driver ov2680 failed with error -22
>
> Fix it by passing the required 'link-frequencies' property as
> recommended by:
>
> https://www.kernel.org/doc/html/v6.9-rc1/driver-api/media/camera-sensor.html#handling-clocks
>
> Cc: stable@vger.kernel.org
> Fixes: 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification")
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
> arch/arm/boot/dts/nxp/imx/imx7s-warp.dts | 1 +
> 1 file changed, 1 insertion(+)
>
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 nxp/imx/imx7s-warp.dtb' for 20240328151954.2517368-1-festevam@gmail.com:
arch/arm/boot/dts/nxp/imx/imx7s-warp.dtb: camera@36: port:endpoint: Unevaluated properties are not allowed ('clock-lanes', 'data-lanes', 'link-frequencies' were unexpected)
from schema $id: http://devicetree.org/schemas/media/i2c/ovti,ov2680.yaml#
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: mailbox: qcom: Add CPUCP mailbox controller bindings
From: Rob Herring @ 2024-03-28 20:54 UTC (permalink / raw)
To: Sibi Sankar
Cc: sudeep.holla, cristian.marussi, andersson, konrad.dybcio,
jassisinghbrar, krzysztof.kozlowski+dt, linux-kernel,
linux-arm-msm, devicetree, quic_rgottimu, quic_kshivnan, conor+dt,
quic_gkohli, quic_nkela, quic_psodagud
In-Reply-To: <20240328095044.2926125-2-quic_sibis@quicinc.com>
On Thu, Mar 28, 2024 at 03:20:40PM +0530, Sibi Sankar wrote:
> Add devicetree binding for CPUSS Control Processor (CPUCP) mailbox
> controller.
>
> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
> ---
>
> rfc:
rfc is not a version, but a "state of the patch" tag. This should be v2.
> * Use x1e80100 as the fallback for future SoCs using the cpucp-mbox
> controller. [Krzysztoff/Konrad/Rob]
>
> .../bindings/mailbox/qcom,cpucp-mbox.yaml | 49 +++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: display: msm: sm6350-mdss: document DP controller subnode
From: Rob Herring @ 2024-03-28 20:52 UTC (permalink / raw)
To: Luca Weiss
Cc: Rob Clark, Abhinav Kumar, Dmitry Baryshkov, Sean Paul,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter,
Krzysztof Kozlowski, Conor Dooley, Kuogee Hsieh,
Krishna Manikandan, Bjorn Andersson, Konrad Dybcio,
~postmarketos/upstreaming, phone-devel, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel
In-Reply-To: <20240328-sm6350-dp-v1-2-215ca2b81c35@fairphone.com>
On Thu, Mar 28, 2024 at 10:42:45AM +0100, Luca Weiss wrote:
> Document the displayport controller subnode of the SM6350 MDSS.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> .../devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
> index c9ba1fae8042..d91b8eca6aba 100644
> --- a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
> @@ -53,6 +53,16 @@ patternProperties:
> compatible:
> const: qcom,sm6350-dpu
>
> + "^displayport-controller@[0-9a-f]+$":
> + type: object
> + additionalProperties: true
> +
> + properties:
> + compatible:
> + items:
> + - const: qcom,sm6350-dp
> + - const: qcom,sm8350-dp
Just use 'contains' here with qcom,sm6350-dp. The full schema will check
the order.
Rob
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: display: msm: dp-controller: document SM8250 compatible
From: Rob Herring @ 2024-03-28 20:51 UTC (permalink / raw)
To: Luca Weiss
Cc: Konrad Dybcio, Krishna Manikandan, David Airlie, devicetree,
Dmitry Baryshkov, linux-arm-msm, Bjorn Andersson, Sean Paul,
Daniel Vetter, ~postmarketos/upstreaming, Rob Clark,
Maxime Ripard, dri-devel, Thomas Zimmermann, Abhinav Kumar,
Maarten Lankhorst, Krzysztof Kozlowski, Marijn Suijten,
Conor Dooley, linux-kernel, freedreno, Kuogee Hsieh, phone-devel
In-Reply-To: <20240328-sm6350-dp-v1-1-215ca2b81c35@fairphone.com>
On Thu, 28 Mar 2024 10:42:44 +0100, Luca Weiss wrote:
> Add the compatible string for the DisplayPort controller on SM6350 which
> is compatible with the one on SM8350.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 22/23] drivers: media: i2c: imx258: Add support for powerdown gpio
From: Rob Herring @ 2024-03-28 20:48 UTC (permalink / raw)
To: git
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, Ondrej Jirman
In-Reply-To: <20240327231710.53188-23-git@luigi311.com>
On Wed, Mar 27, 2024 at 05:17:08PM -0600, git@luigi311.com wrote:
> From: Luigi311 <git@luigi311.com>
>
> On some boards powerdown signal needs to be deasserted for this
> sensor to be enabled.
>
> Signed-off-by: Ondrej Jirman <megi@xff.cz>
> ---
> .../devicetree/bindings/media/i2c/sony,imx258.yaml | 4 ++++
Bindings should be a separate patch.
> drivers/media/i2c/imx258.c | 13 +++++++++++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> index c7856de15ba3..0414085bf22f 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> @@ -35,6 +35,10 @@ properties:
> reg:
> maxItems: 1
>
> + powerdown-gpios:
> + description: |-
Don't need '|-' if no formatting.
> + Reference to the GPIO connected to the PWDN pin, if any.
> +
> reset-gpios:
> description: |-
> Reference to the GPIO connected to the XCLR pin, if any.
^ permalink raw reply
* Re: [PATCH 18/23] dt-bindings: media: imx258: Add alternate compatible strings
From: Rob Herring @ 2024-03-28 20:46 UTC (permalink / raw)
To: Luigi311
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <76f999a7-55e0-4676-aa75-8fcd466e046b@luigi311.com>
On Thu, Mar 28, 2024 at 01:16:22PM -0600, Luigi311 wrote:
> On 3/28/24 12:55, Rob Herring wrote:
> > On Wed, Mar 27, 2024 at 05:17:04PM -0600, git@luigi311.com wrote:
> >> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
> >>
> >> There are a number of variants of the imx258 modules that can not
> >> be differentiated at runtime, so add compatible strings for them.
> >> But you are only adding 1 variant.
>
> I can not speak for Dave but as to why this was added here but looking
> at the imx296 yaml that has something similar where there are multiple
> variants that may not be detectable at run time but does not include
> similar verbiage in the main description. Should I drop this from the
> description so it matches the imx296?
Just change "add compatible strings for them" to "add compatible string
for the PDAF variant" or something.
>
> >
> >>
> >> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> >> Signed-off-by: Luigi311 <git@luigi311.com>
> >> ---
> >> .../devicetree/bindings/media/i2c/sony,imx258.yaml | 6 +++++-
> >> 1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> >> index bee61a443b23..c7856de15ba3 100644
> >> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> >> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> >> @@ -14,10 +14,14 @@ description: |-
> >> type stacked image sensor with a square pixel array of size 4208 x 3120. It
> >> is programmable through I2C interface. Image data is sent through MIPI
> >> CSI-2.
> >> + There are a number of variants of the sensor which cannot be detected at
> >> + runtime, so multiple compatible strings are required to differentiate these.
> >
> > That's more reasoning/why for the patch than description of the h/w.
> >
> >> properties:
> >> compatible:
> >> - const: sony,imx258
> >> + - enum:
> >> + - sony,imx258
> >> + - sony,imx258-pdaf
> >
> > How do I know which one to use? Please define what PDAF means somewhere
> > as well as perhaps what the original/default variant is or isn't.
>
> Would it make sense to change the properties to include a description like so
>
> properties:
> compatible:
> enum:
> - sony,imx258
> - sony,imx258-pdaf
> description:
> The IMX258 sensor exists in two different models, a standard variant
> (IMX258) and a variant with phase detection autofocus (IMX258-PDAF).
> The camera module does not expose the model through registers, so the
> exact model needs to be specified.
Looks fine, but I'd move this to the top-level 'description'.
Rob
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
From: Andrew Lunn @ 2024-03-28 20:42 UTC (permalink / raw)
To: Gilles Talis
Cc: devicetree, imx, linux-arm-kernel, conor+dt,
krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex
In-Reply-To: <20240328202320.187596-4-gilles.talis@gmail.com>
> +&eqos {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_eqos>;
> + phy-mode = "rgmii-id";
> + phy-handle = <ðphy0>;
> + status = "okay";
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <1000>;
> + reset-deassert-us = <10000>;
> + qca,disable-smarteee;
> + qca,disable-hibernation-mode;
> + vddio-supply = <&vddio>;
> +
> + vddio: vddio-regulator {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
Please could you explain what this last node is doing.
Andrew
^ permalink raw reply
* Re: [PATCH v5 1/1] dt-bindings: net: starfive,jh7110-dwmac: Add StarFive JH8100 support
From: Rob Herring @ 2024-03-28 20:42 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Tan Chun Hau, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Emil Renner Berthing, Krzysztof Kozlowski,
Conor Dooley, Maxime Coquelin, Alexandre Torgue, Simon Horman,
Bartosz Golaszewski, Andrew Halaney, Jisheng Zhang,
Uwe Kleine-König, Russell King, Ley Foon Tan, Jee Heng Sia,
netdev, devicetree, linux-kernel, linux-stm32, linux-arm-kernel,
linux-riscv
In-Reply-To: <31ac366d-bfa6-4c99-a04d-ab9fb029da7e@linaro.org>
On Wed, Mar 27, 2024 at 08:54:30AM +0100, Krzysztof Kozlowski wrote:
> On 27/03/2024 02:57, Tan Chun Hau wrote:
> > Add StarFive JH8100 dwmac support.
> > The JH8100 dwmac shares the same driver code as the JH7110 dwmac
> > and has only one reset signal.
> >
> > Please refer to below:
> >
> > JH8100: reset-names = "stmmaceth";
> > JH7110: reset-names = "stmmaceth", "ahb";
> > JH7100: reset-names = "ahb";
> >
> > Example usage of JH8100 in the device tree:
> >
> > gmac0: ethernet@16030000 {
> > compatible = "starfive,jh8100-dwmac",
> > "starfive,jh7110-dwmac",
> > "snps,dwmac-5.20";
> > ...
> > };
> >
> > Signed-off-by: Tan Chun Hau <chunhau.tan@starfivetech.com>
> > ---
> > .../devicetree/bindings/net/snps,dwmac.yaml | 1 +
> > .../bindings/net/starfive,jh7110-dwmac.yaml | 29 +++++++++++++++----
> > 2 files changed, 25 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > index 6b0341a8e0ea..a6d596b7dcf4 100644
> > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > @@ -97,6 +97,7 @@ properties:
> > - snps,dwxgmac-2.10
> > - starfive,jh7100-dwmac
> > - starfive,jh7110-dwmac
> > + - starfive,jh8100-dwmac
>
> I think that's not needed. You have there already your fallback.
>
> >
> > reg:
> > minItems: 1
> > diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > index 0d1962980f57..5805a58c55d1 100644
> > --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > @@ -18,6 +18,7 @@ select:
> > enum:
> > - starfive,jh7100-dwmac
> > - starfive,jh7110-dwmac
> > + - starfive,jh8100-dwmac
>
> Same here, even more obvious.
Agreed.
>
> > required:
> > - compatible
> >
> > @@ -30,6 +31,10 @@ properties:
> > - items:
> > - const: starfive,jh7110-dwmac
> > - const: snps,dwmac-5.20
> > + - items:
> > + - const: starfive,jh8100-dwmac
> > + - const: starfive,jh7110-dwmac
> > + - const: snps,dwmac-5.20
> >
> > reg:
> > maxItems: 1
> > @@ -116,11 +121,25 @@ allOf:
> > minItems: 3
> > maxItems: 3
> >
> > - resets:
> > - minItems: 2
> > -
> > - reset-names:
> > - minItems: 2
> > + if:
>
> I would personally avoid nesting if within if. It gets unreadable.
> Although Rob did not comment on this one, so I guess it is fine.
I normally agree, but here I suggested it as it looked to be the
simplest option.
With the 2 other comments addressed,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v10 2/2] dt-bindings: mtd: fixed-partition: Add binman compatibles
From: Rob Herring @ 2024-03-28 20:37 UTC (permalink / raw)
To: Simon Glass
Cc: Michael Walle, Conor Dooley, Vignesh Raghavendra, devicetree,
Krzysztof Kozlowski, U-Boot Mailing List, Rafał Miłecki,
linux-mtd, Miquel Raynal, Richard Weinberger, linux-kernel,
Tom Rini
In-Reply-To: <20240326200645.1182803-2-sjg@chromium.org>
On Tue, 26 Mar 2024 14:06:45 -0600, Simon Glass wrote:
> Add two compatibles for binman entries, as a starting point for the
> schema.
>
> Note that, after discussion on v2, we decided to keep the existing
> meaning of label so as not to require changes to existing userspace
> software when moving to use binman nodes to specify the firmware
> layout.
>
> Note also that, after discussion on v6, we decided to use the same
> 'fixed-partition' schema for the binman features, so this version
> adds a new 'binman.yaml' file providing the new compatibles to the
> existing partition.yaml binding.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v10:
> - Drop binman,entry since it is likely not necessary
> - Put the description back
>
> Changes in v8:
> - Switch the patch ordering so the partition change comes first
>
> Changes in v7:
> - Adjust MAINTAINERS entry
> - Put compatible strings into the 'fixed-partition' binding
>
> Changes in v5:
> - Add mention of why 'binman' is the vendor
> - Drop 'select: false'
> - Tidy up the compatible setings
> - Use 'tfa-bl31' instead of 'atf-bl31'
>
> Changes in v4:
> - Correct selection of multiple compatible strings
>
> Changes in v3:
> - Drop fixed-partitions from the example
> - Use compatible instead of label
>
> Changes in v2:
> - Use plain partition@xxx for the node name
>
> .../bindings/mtd/partitions/binman.yaml | 53 +++++++++++++++++++
> .../bindings/mtd/partitions/partition.yaml | 21 ++++++++
> MAINTAINERS | 5 ++
> 3 files changed, 79 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/partitions/binman.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 2/2] phy: add driver for MediaTek XFI T-PHY
From: Daniel Golle @ 2024-03-28 20:12 UTC (permalink / raw)
To: Vinod Koul
Cc: Bc-bocun Chen, Steven Liu, John Crispin, Chunfeng Yun,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Qingfang Deng, SkyLake Huang, Philipp Zabel, linux-arm-kernel,
linux-mediatek, linux-phy, devicetree, linux-kernel, netdev
In-Reply-To: <ZgW8f1Rshi28YcvA@matsya>
Hi Vinod,
thank you for taking your time to review my submission!
On Fri, Mar 29, 2024 at 12:22:47AM +0530, Vinod Koul wrote:
> On 10-02-24, 02:10, Daniel Golle wrote:
> > Add driver for MediaTek's XFI T-PHY which can be found in the MT7988
>
> What does XFI mean?
https://en.wikipedia.org/wiki/XFP_transceiver#XFI
I chose this name because names of functions dealing with the phy in
the vendor driver are prefixed "xfi_pextp_".
The register space used by the phy is called "pextp", which could be
read as "_P_CI _ex_press _T_-_P_hy", and that is quite misleading as
this phy isn't used for anything related to PCIe, so I wanted to find
a better name.
XFI is still somehow related (as in: you would find the relevant
places using grep in the vendor driver when looking for that) and
seemed to at least somehow be aligned with the function of that phy:
Dealing with (up to) 10 Gbit/s Ethernet SerDes signals.
MediaTek calls phys with more than one potential use T-PHY or X-PHY:
The capital letter 'T' graphically connects 3 points, two of them
being on the upper side representing the internal components and one
on the lower side representing the single external interface.
Other vendors (like Marvell) call such things "combo phys".
Anyway, if anyone has better ideas regarding the naming, now is the
moment to speak up ;)
>
> > SoC. The XFI T-PHY is a 10 Gigabit/s Ethernet SerDes PHY with muxes on
> > the internal side to be used with either USXGMII PCS or LynxI PCS,
> > depending on the selected PHY interface mode.
> >
> > The PHY can operates only in PHY_MODE_ETHERNET, the submode is one of
> > PHY_INTERFACE_MODE_* corresponding to the supported modes:
> >
> > * USXGMII \
> > * 10GBase-R }- USXGMII PCS - XGDM \
> > * 5GBase-R / \
> > }- Ethernet MAC
> > * 2500Base-X \ /
> > * 1000Base-X }- LynxI PCS - GDM /
> > * Cisco SGMII (MAC side) /
> >
> > In order to work-around a performance issue present on the first of
> > two XFI T-PHYs present in MT7988, special tuning is applied which can be
> > selected by adding the 'mediatek,usxgmii-performance-errata' property to
> > the device tree node.
> >
> > There is no documentation for most registers used for the
> > analog/tuning part, however, most of the registers have been partially
> > reverse-engineered from MediaTek's SDK implementation (an opaque
> > sequence of 32-bit register writes) and descriptions for all relevant
> > digital registers and bits such as resets and muxes have been supplied
> > by MediaTek.
> >
> > Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > ---
> > v3: no changes
> > v2:
> > * use IO helpers from mtk-io.h instead of rolling my own
> > * use devm_clk_bulk_get()
> > * yse devm_platform_ioremap_resource()
> > * unify name and description everywhere
> > * invert bool is_xgmii into bool use_lynxi_pcs and add comments
> > describing the meaning of each of the stack variables
> > * not much we can do about remaining magic values unless MTK provides
> > definitions for them
> >
> >
> > MAINTAINERS | 1 +
> > drivers/phy/mediatek/Kconfig | 12 +
> > drivers/phy/mediatek/Makefile | 1 +
> > drivers/phy/mediatek/phy-mtk-xfi-tphy.c | 360 ++++++++++++++++++++++++
> > 4 files changed, 374 insertions(+)
> > create mode 100644 drivers/phy/mediatek/phy-mtk-xfi-tphy.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 4be2fd097f261..616b86e3e62fd 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -13776,6 +13776,7 @@ L: netdev@vger.kernel.org
> > S: Maintained
> > F: drivers/net/phy/mediatek-ge-soc.c
> > F: drivers/net/phy/mediatek-ge.c
> > +F: drivers/phy/mediatek/phy-mtk-xfi-tphy.c
> >
> > MEDIATEK I2C CONTROLLER DRIVER
> > M: Qii Wang <qii.wang@mediatek.com>
> > diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> > index 3849b7c87d287..117d0e84c7360 100644
> > --- a/drivers/phy/mediatek/Kconfig
> > +++ b/drivers/phy/mediatek/Kconfig
> > @@ -13,6 +13,18 @@ config PHY_MTK_PCIE
> > callback for PCIe GEN3 port, it supports software efuse
> > initialization.
> >
> > +config PHY_MTK_XFI_TPHY
> > + tristate "MediaTek 10GE SerDes XFI T-PHY driver"
> > + depends on ARCH_MEDIATEK || COMPILE_TEST
> > + depends on OF && OF_ADDRESS
>
> why both, is OF not enough?
As we are already also depending on HAS_IOMEM what is left there is
basically just a !SPARC dependency.
And that is probably a historic left-over and (according to commit
5ab5fc7e35705c from 2010...) should be re-evaluated. I'm happy to drop
OF_ADDRESS and keep only HAS_IOMEM, and we shall see if any of the
COMPILE_TESTs actually fails, given that everyone is fine with that.
>
> > + depends on HAS_IOMEM
> > + select GENERIC_PHY
> > + help
> > + Say 'Y' here to add support for MediaTek XFI T-PHY driver.
> > + The driver provides access to the Ethernet SerDes T-PHY supporting
> > + 1GE and 2.5GE modes via the LynxI PCS, and 5GE and 10GE modes
> > + via the USXGMII PCS found in MediaTek SoCs with 10G Ethernet.
> > +
> > config PHY_MTK_TPHY
> > tristate "MediaTek T-PHY Driver"
> > depends on ARCH_MEDIATEK || COMPILE_TEST
> > diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> > index f6e24a47e0815..1b8088df71e84 100644
> > --- a/drivers/phy/mediatek/Makefile
> > +++ b/drivers/phy/mediatek/Makefile
> > @@ -8,6 +8,7 @@ obj-$(CONFIG_PHY_MTK_PCIE) += phy-mtk-pcie.o
> > obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
> > obj-$(CONFIG_PHY_MTK_UFS) += phy-mtk-ufs.o
> > obj-$(CONFIG_PHY_MTK_XSPHY) += phy-mtk-xsphy.o
> > +obj-$(CONFIG_PHY_MTK_XFI_TPHY) += phy-mtk-xfi-tphy.o
> >
> > phy-mtk-hdmi-drv-y := phy-mtk-hdmi.o
> > phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt2701.o
> > diff --git a/drivers/phy/mediatek/phy-mtk-xfi-tphy.c b/drivers/phy/mediatek/phy-mtk-xfi-tphy.c
> > new file mode 100644
> > index 0000000000000..551d6cee33f94
> > --- /dev/null
> > +++ b/drivers/phy/mediatek/phy-mtk-xfi-tphy.c
> > @@ -0,0 +1,360 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/* MediaTek 10GE SerDes XFI T-PHY driver
> > + *
> > + * Copyright (c) 2024 Daniel Golle <daniel@makrotopia.org>
> > + * Bc-bocun Chen <bc-bocun.chen@mediatek.com>
> > + * based on mtk_usxgmii.c and mtk_sgmii.c found in MediaTek's SDK (GPL-2.0)
> > + * Copyright (c) 2022 MediaTek Inc.
> > + * Author: Henry Yen <henry.yen@mediatek.com>
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/of.h>
> > +#include <linux/io.h>
> > +#include <linux/clk.h>
> > +#include <linux/reset.h>
> > +#include <linux/phy.h>
> > +#include <linux/phy/phy.h>
> > +
> > +#include "phy-mtk-io.h"
> > +
> > +#define MTK_XFI_TPHY_NUM_CLOCKS 2
> > +
> > +#define REG_DIG_GLB_70 0x0070
> > +#define XTP_PCS_RX_EQ_IN_PROGRESS(x) FIELD_PREP(GENMASK(25, 24), (x))
> > +#define XTP_PCS_MODE_MASK GENMASK(17, 16)
> > +#define XTP_PCS_MODE(x) FIELD_PREP(GENMASK(17, 16), (x))
> > +#define XTP_PCS_RST_B BIT(15)
> > +#define XTP_FRC_PCS_RST_B BIT(14)
> > +#define XTP_PCS_PWD_SYNC_MASK GENMASK(13, 12)
> > +#define XTP_PCS_PWD_SYNC(x) FIELD_PREP(XTP_PCS_PWD_SYNC_MASK, (x))
> > +#define XTP_PCS_PWD_ASYNC_MASK GENMASK(11, 10)
> > +#define XTP_PCS_PWD_ASYNC(x) FIELD_PREP(XTP_PCS_PWD_ASYNC_MASK, (x))
> > +#define XTP_FRC_PCS_PWD_ASYNC BIT(8)
> > +#define XTP_PCS_UPDT BIT(4)
> > +#define XTP_PCS_IN_FR_RG BIT(0)
> > +
> > +#define REG_DIG_GLB_F4 0x00f4
> > +#define XFI_DPHY_PCS_SEL BIT(0)
> > +#define XFI_DPHY_PCS_SEL_SGMII FIELD_PREP(XFI_DPHY_PCS_SEL, 1)
> > +#define XFI_DPHY_PCS_SEL_USXGMII FIELD_PREP(XFI_DPHY_PCS_SEL, 0)
> > +#define XFI_DPHY_AD_SGDT_FRC_EN BIT(5)
> > +
> > +#define REG_DIG_LN_TRX_40 0x3040
> > +#define XTP_LN_FRC_TX_DATA_EN BIT(29)
> > +#define XTP_LN_TX_DATA_EN BIT(28)
> > +
> > +#define REG_DIG_LN_TRX_B0 0x30b0
> > +#define XTP_LN_FRC_TX_MACCK_EN BIT(5)
> > +#define XTP_LN_TX_MACCK_EN BIT(4)
> > +
> > +#define REG_ANA_GLB_D0 0x90d0
> > +#define XTP_GLB_USXGMII_SEL_MASK GENMASK(3, 1)
> > +#define XTP_GLB_USXGMII_SEL(x) FIELD_PREP(GENMASK(3, 1), (x))
> > +#define XTP_GLB_USXGMII_EN BIT(0)
> > +
> > +struct mtk_xfi_tphy {
> > + void __iomem *base;
> > + struct device *dev;
> > + struct reset_control *reset;
> > + struct clk_bulk_data clocks[MTK_XFI_TPHY_NUM_CLOCKS];
> > + bool da_war;
> > +};
> > +
> > +static void mtk_xfi_tphy_setup(struct mtk_xfi_tphy *xfi_tphy,
> > + phy_interface_t interface)
> > +{
> > + /* Override 10GBase-R tuning value if work-around is selected */
> > + bool da_war = (xfi_tphy->da_war && (interface == PHY_INTERFACE_MODE_10GBASER));
>
> why do you need braces around this?
Just for readability. They can safely be removed.
>
> > + /* Bools to make setting up values for specific PHY speeds easier */
> > + bool is_2p5g = (interface == PHY_INTERFACE_MODE_2500BASEX);
> > + bool is_1g = (interface == PHY_INTERFACE_MODE_1000BASEX ||
> > + interface == PHY_INTERFACE_MODE_SGMII);
> > + bool is_10g = (interface == PHY_INTERFACE_MODE_10GBASER ||
> > + interface == PHY_INTERFACE_MODE_USXGMII);
> > + bool is_5g = (interface == PHY_INTERFACE_MODE_5GBASER);
> > + /* Bool to configure input mux to either
> > + * - USXGMII PCS (64b/66b coding) for 5G/10G
> > + * - LynxI PCS (8b/10b coding) for 1G/2.5G
> > + */
> > + bool use_lynxi_pcs = (is_1g || is_2p5g);
>
> This is quite terrible to read, how about declaring variables first and
> then doing the initialization?
Ack.
>
> > +
> > + dev_dbg(xfi_tphy->dev, "setting up for mode %s\n", phy_modes(interface));
> > +
> > + /* Setup PLL setting */
> > + mtk_phy_update_bits(xfi_tphy->base + 0x9024, 0x100000, is_10g ? 0x0 : 0x100000);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x2020, 0x202000, is_5g ? 0x202000 : 0x0);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x2030, 0x500, is_1g ? 0x0 : 0x500);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x2034, 0xa00, is_1g ? 0x0 : 0xa00);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x2040, 0x340000, is_1g ? 0x200000 : 0x140000);
>
> magic numbers?
Yes, and not much we can do about them. According to MTK engineers (in
Cc) they also don't know what those numbers really mean in detail and
have only been given sequences of magic register writes for each
interface mode ([1], [2], [3], [4], [5]) by the upstream IP supplier
of the PHY. I then compared those write sequences with each others,
and observed the behavior of each register (as in: read their value
before and after the write operation; all of them read back the value
written to them) and rewrote the initialization as one function only
changing the bits actually needed (instead of always writing the complete
32-bit value). I've made sure that everything still works and Bc-bocun
Chen of MediaTek (also in Cc) then helped to label at least some of
the registers and bits there in as far as they are understood by
MediaTek.
[1]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/refs/heads/master/21.02/files/target/linux/mediatek/files-5.4/drivers/net/ethernet/mediatek/mtk_sgmii.c#172
[2]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/refs/heads/master/21.02/files/target/linux/mediatek/files-5.4/drivers/net/ethernet/mediatek/mtk_sgmii.c#284
[3]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/refs/heads/master/21.02/files/target/linux/mediatek/files-5.4/drivers/net/ethernet/mediatek/mtk_usxgmii.c#132
[4]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/refs/heads/master/21.02/files/target/linux/mediatek/files-5.4/drivers/net/ethernet/mediatek/mtk_usxgmii.c#246
[5]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/refs/heads/master/21.02/files/target/linux/mediatek/files-5.4/drivers/net/ethernet/mediatek/mtk_usxgmii.c#360
>
> > +
> > + /* Setup RXFE BW setting */
> > + mtk_phy_update_bits(xfi_tphy->base + 0x50f0, 0xc10, is_1g ? 0x410 : is_5g ? 0x800 : 0x400);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x50e0, 0x4000, is_5g ? 0x0 : 0x4000);
> > +
> > + /* Setup RX CDR setting */
> > + mtk_phy_update_bits(xfi_tphy->base + 0x506c, 0x30000, is_5g ? 0x0 : 0x30000);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x5070, 0x670000, is_5g ? 0x620000 : 0x50000);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x5074, 0x180000, is_5g ? 0x180000 : 0x0);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x5078, 0xf000400, is_5g ? 0x8000000 :
> > + 0x7000400);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x507c, 0x5000500, is_5g ? 0x4000400 :
> > + 0x1000100);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x5080, 0x1410, is_1g ? 0x400 : is_5g ? 0x1010 : 0x0);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x5084, 0x30300, is_1g ? 0x30300 :
> > + is_5g ? 0x30100 :
> > + 0x100);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x5088, 0x60200, is_1g ? 0x20200 :
> > + is_5g ? 0x40000 :
> > + 0x20000);
> > +
> > + /* Setting RXFE adaptation range setting */
> > + mtk_phy_update_bits(xfi_tphy->base + 0x50e4, 0xc0000, is_5g ? 0x0 : 0xc0000);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x50e8, 0x40000, is_5g ? 0x0 : 0x40000);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x50ec, 0xa00, is_1g ? 0x200 : 0x800);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x50a8, 0xee0000, is_5g ? 0x800000 :
> > + 0x6e0000);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x6004, 0x190000, is_5g ? 0x0 : 0x190000);
> > +
> > + if (is_10g)
> > + writel(0x01423342, xfi_tphy->base + 0x00f8);
> > + else if (is_5g)
> > + writel(0x00a132a1, xfi_tphy->base + 0x00f8);
> > + else if (is_2p5g)
> > + writel(0x009c329c, xfi_tphy->base + 0x00f8);
> > + else
> > + writel(0x00fa32fa, xfi_tphy->base + 0x00f8);
> > +
> > + /* Force SGDT_OUT off and select PCS */
> > + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_F4,
> > + XFI_DPHY_AD_SGDT_FRC_EN | XFI_DPHY_PCS_SEL,
> > + XFI_DPHY_AD_SGDT_FRC_EN |
> > + (use_lynxi_pcs ? XFI_DPHY_PCS_SEL_SGMII :
> > + XFI_DPHY_PCS_SEL_USXGMII));
> > +
> > + /* Force GLB_CKDET_OUT */
> > + mtk_phy_set_bits(xfi_tphy->base + 0x0030, 0xc00);
> > +
> > + /* Force AEQ on */
> > + writel(XTP_PCS_RX_EQ_IN_PROGRESS(2) | XTP_PCS_PWD_SYNC(2) | XTP_PCS_PWD_ASYNC(2),
> > + xfi_tphy->base + REG_DIG_GLB_70);
> > +
> > + usleep_range(1, 5);
> > +
> > + /* Setup TX DA default value */
> > + mtk_phy_update_bits(xfi_tphy->base + 0x30b0, 0x30, 0x20);
> > + writel(0x00008a01, xfi_tphy->base + 0x3028);
> > + writel(0x0000a884, xfi_tphy->base + 0x302c);
> > + writel(0x00083002, xfi_tphy->base + 0x3024);
> > +
> > + /* Setup RG default value */
> > + if (use_lynxi_pcs) {
> > + writel(0x00011110, xfi_tphy->base + 0x3010);
> > + writel(0x40704000, xfi_tphy->base + 0x3048);
> > + } else {
> > + writel(0x00022220, xfi_tphy->base + 0x3010);
> > + writel(0x0f020a01, xfi_tphy->base + 0x5064);
> > + writel(0x06100600, xfi_tphy->base + 0x50b4);
> > + if (interface == PHY_INTERFACE_MODE_USXGMII)
> > + writel(0x40704000, xfi_tphy->base + 0x3048);
> > + else
> > + writel(0x47684100, xfi_tphy->base + 0x3048);
> > + }
> > +
> > + if (is_1g)
> > + writel(0x0000c000, xfi_tphy->base + 0x3064);
> > +
> > + /* Setup RX EQ initial value */
> > + mtk_phy_update_bits(xfi_tphy->base + 0x3050, 0xa8000000,
> > + (interface != PHY_INTERFACE_MODE_10GBASER) ? 0xa8000000 : 0x0);
> > + mtk_phy_update_bits(xfi_tphy->base + 0x3054, 0xaa,
> > + (interface != PHY_INTERFACE_MODE_10GBASER) ? 0xaa : 0x0);
> > +
> > + if (!use_lynxi_pcs)
> > + writel(0x00000f00, xfi_tphy->base + 0x306c);
> > + else if (is_2p5g)
> > + writel(0x22000f00, xfi_tphy->base + 0x306c);
> > + else
> > + writel(0x20200f00, xfi_tphy->base + 0x306c);
> > +
> > + mtk_phy_update_bits(xfi_tphy->base + 0xa008, 0x10000, da_war ? 0x10000 : 0x0);
> > +
> > + mtk_phy_update_bits(xfi_tphy->base + 0xa060, 0x50000, use_lynxi_pcs ? 0x50000 : 0x40000);
> > +
> > + /* Setup PHYA speed */
> > + mtk_phy_update_bits(xfi_tphy->base + REG_ANA_GLB_D0,
> > + XTP_GLB_USXGMII_SEL_MASK | XTP_GLB_USXGMII_EN,
> > + is_10g ? XTP_GLB_USXGMII_SEL(0) :
> > + is_5g ? XTP_GLB_USXGMII_SEL(1) :
> > + is_2p5g ? XTP_GLB_USXGMII_SEL(2) :
> > + XTP_GLB_USXGMII_SEL(3));
> > + mtk_phy_set_bits(xfi_tphy->base + REG_ANA_GLB_D0, XTP_GLB_USXGMII_EN);
> > +
> > + /* Release reset */
> > + mtk_phy_set_bits(xfi_tphy->base + REG_DIG_GLB_70,
> > + XTP_PCS_RST_B | XTP_FRC_PCS_RST_B);
> > + usleep_range(150, 500);
> > +
> > + /* Switch to P0 */
> > + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_70,
> > + XTP_PCS_IN_FR_RG |
> > + XTP_FRC_PCS_PWD_ASYNC |
> > + XTP_PCS_PWD_ASYNC_MASK |
> > + XTP_PCS_PWD_SYNC_MASK |
> > + XTP_PCS_UPDT,
> > + XTP_PCS_IN_FR_RG |
> > + XTP_FRC_PCS_PWD_ASYNC |
> > + XTP_PCS_UPDT);
> > + usleep_range(1, 5);
> > +
> > + mtk_phy_clear_bits(xfi_tphy->base + REG_DIG_GLB_70, XTP_PCS_UPDT);
> > + usleep_range(15, 50);
> > +
> > + if (use_lynxi_pcs) {
> > + /* Switch to Gen2 */
> > + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_70,
> > + XTP_PCS_MODE_MASK | XTP_PCS_UPDT,
> > + XTP_PCS_MODE(1) | XTP_PCS_UPDT);
> > + } else {
> > + /* Switch to Gen3 */
> > + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_70,
> > + XTP_PCS_MODE_MASK | XTP_PCS_UPDT,
> > + XTP_PCS_MODE(2) | XTP_PCS_UPDT);
> > + }
> > + usleep_range(1, 5);
> > +
> > + mtk_phy_clear_bits(xfi_tphy->base + REG_DIG_GLB_70, XTP_PCS_UPDT);
> > +
> > + usleep_range(100, 500);
> > +
> > + /* Enable MAC CK */
> > + mtk_phy_set_bits(xfi_tphy->base + REG_DIG_LN_TRX_B0, XTP_LN_TX_MACCK_EN);
> > + mtk_phy_clear_bits(xfi_tphy->base + REG_DIG_GLB_F4, XFI_DPHY_AD_SGDT_FRC_EN);
> > +
> > + /* Enable TX data */
> > + mtk_phy_set_bits(xfi_tphy->base + REG_DIG_LN_TRX_40,
> > + XTP_LN_FRC_TX_DATA_EN | XTP_LN_TX_DATA_EN);
> > + usleep_range(400, 1000);
> > +}
> > +
> > +static int mtk_xfi_tphy_set_mode(struct phy *phy, enum phy_mode mode, int
> > + submode)
> > +{
> > + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> > +
> > + if (mode != PHY_MODE_ETHERNET)
> > + return -EINVAL;
> > +
> > + switch (submode) {
> > + case PHY_INTERFACE_MODE_1000BASEX:
> > + case PHY_INTERFACE_MODE_2500BASEX:
> > + case PHY_INTERFACE_MODE_SGMII:
> > + case PHY_INTERFACE_MODE_5GBASER:
> > + case PHY_INTERFACE_MODE_10GBASER:
> > + case PHY_INTERFACE_MODE_USXGMII:
> > + mtk_xfi_tphy_setup(xfi_tphy, submode);
> > + return 0;
> > + default:
> > + return -EINVAL;
> > + }
> > +}
> > +
> > +static int mtk_xfi_tphy_reset(struct phy *phy)
> > +{
> > + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> > +
> > + reset_control_assert(xfi_tphy->reset);
> > + usleep_range(100, 500);
> > + reset_control_deassert(xfi_tphy->reset);
> > + usleep_range(1, 10);
> > +
> > + return 0;
> > +}
> > +
> > +static int mtk_xfi_tphy_power_on(struct phy *phy)
> > +{
> > + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> > +
> > + return clk_bulk_prepare_enable(MTK_XFI_TPHY_NUM_CLOCKS, xfi_tphy->clocks);
> > +}
> > +
> > +static int mtk_xfi_tphy_power_off(struct phy *phy)
> > +{
> > + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> > +
> > + clk_bulk_disable_unprepare(MTK_XFI_TPHY_NUM_CLOCKS, xfi_tphy->clocks);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct phy_ops mtk_xfi_tphy_ops = {
> > + .power_on = mtk_xfi_tphy_power_on,
> > + .power_off = mtk_xfi_tphy_power_off,
> > + .set_mode = mtk_xfi_tphy_set_mode,
> > + .reset = mtk_xfi_tphy_reset,
> > + .owner = THIS_MODULE,
> > +};
> > +
> > +static int mtk_xfi_tphy_probe(struct platform_device *pdev)
> > +{
> > + struct device_node *np = pdev->dev.of_node;
> > + struct phy_provider *phy_provider;
> > + struct mtk_xfi_tphy *xfi_tphy;
> > + struct phy *phy;
> > + int ret;
> > +
> > + if (!np)
> > + return -ENODEV;
> > +
> > + xfi_tphy = devm_kzalloc(&pdev->dev, sizeof(*xfi_tphy), GFP_KERNEL);
> > + if (!xfi_tphy)
> > + return -ENOMEM;
> > +
> > + xfi_tphy->base = devm_platform_ioremap_resource(pdev, 0);
> > + if (IS_ERR(xfi_tphy->base))
> > + return PTR_ERR(xfi_tphy->base);
> > +
> > + xfi_tphy->dev = &pdev->dev;
> > + xfi_tphy->clocks[0].id = "topxtal";
> > + xfi_tphy->clocks[1].id = "xfipll";
> > + ret = devm_clk_bulk_get(&pdev->dev, MTK_XFI_TPHY_NUM_CLOCKS, xfi_tphy->clocks);
> > + if (ret)
> > + return ret;
> > +
> > + xfi_tphy->reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> > + if (IS_ERR(xfi_tphy->reset))
> > + return PTR_ERR(xfi_tphy->reset);
> > +
> > + xfi_tphy->da_war = of_property_read_bool(np, "mediatek,usxgmii-performance-errata");
> > +
> > + phy = devm_phy_create(&pdev->dev, NULL, &mtk_xfi_tphy_ops);
> > + if (IS_ERR(phy))
> > + return PTR_ERR(phy);
> > +
> > + phy_set_drvdata(phy, xfi_tphy);
> > + phy_provider = devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
> > +
> > + return PTR_ERR_OR_ZERO(phy_provider);
> > +}
> > +
> > +static const struct of_device_id mtk_xfi_tphy_match[] = {
> > + { .compatible = "mediatek,mt7988-xfi-tphy", },
> > + { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, mtk_xfi_tphy_match);
> > +
> > +static struct platform_driver mtk_xfi_tphy_driver = {
> > + .probe = mtk_xfi_tphy_probe,
> > + .driver = {
> > + .name = "mtk-xfi-tphy",
> > + .of_match_table = mtk_xfi_tphy_match,
> > + },
> > +};
> > +module_platform_driver(mtk_xfi_tphy_driver);
> > +
> > +MODULE_DESCRIPTION("MediaTek 10GE SerDes XFI T-PHY driver");
> > +MODULE_AUTHOR("Daniel Golle <daniel@makrotopia.org>");
> > +MODULE_AUTHOR("Bc-bocun Chen <bc-bocun.chen@mediatek.com>");
> > +MODULE_LICENSE("GPL");
> > --
> > 2.43.0
>
> --
> ~Vinod
^ permalink raw reply
* [PATCH 3/3] arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
From: Gilles Talis @ 2024-03-28 20:23 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel
Cc: conor+dt, krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex,
Gilles Talis
In-Reply-To: <20240328202320.187596-1-gilles.talis@gmail.com>
The Emcraft Systems NavQ+ kit is a mobile robotics platform
based on NXP i.MX8 MPlus SoC.
The following interfaces and devices are enabled:
- eMMC
- Gigabit Ethernet
- RTC
- SD-Card
- UART console
Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../arm64/boot/dts/freescale/imx8mp-navqp.dts | 435 ++++++++++++++++++
2 files changed, 436 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 045250d0a040..bf99864c0bc4 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -166,6 +166,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-pdk3.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-icore-mx8mp-edimm2.2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-msc-sm2s-ep1.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-navqp.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-phyboard-pollux-rdk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-hdmi.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-lt6.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts b/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
new file mode 100644
index 000000000000..8182e71008f8
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
@@ -0,0 +1,435 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2021 Emcraft Systems
+ * Copyright 2024 Gilles Talis <gilles.talis@gmail.com>
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "imx8mp.dtsi"
+
+/ {
+ model = "Emcraft Systems i.MX8MPlus NavQ+ Kit";
+ compatible = "emcraft,imx8mp-navqp", "fsl,imx8mp";
+
+ chosen {
+ stdout-path = &uart2;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_led>;
+
+ status {
+ label = "status";
+ gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ regulator-name = "VSD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ startup-delay-us = <100>;
+ off-on-delay-us = <12000>;
+ };
+};
+
+&A53_0 {
+ cpu-supply = <&buck2>;
+};
+
+&A53_1 {
+ cpu-supply = <&buck2>;
+};
+
+&A53_2 {
+ cpu-supply = <&buck2>;
+};
+
+&A53_3 {
+ cpu-supply = <&buck2>;
+};
+
+&eqos {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eqos>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <1000>;
+ reset-deassert-us = <10000>;
+ qca,disable-smarteee;
+ qca,disable-hibernation-mode;
+ vddio-supply = <&vddio>;
+
+ vddio: vddio-regulator {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ pmic@25 {
+ compatible = "nxp,pca9450c";
+ reg = <0x25>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ nxp,dvs-run-voltage = <950000>;
+ nxp,dvs-standby-voltage = <850000>;
+ };
+
+ BUCK4 {
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ BUCK5 {
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO2 {
+ regulator-name = "LDO2";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1150000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO3 {
+ regulator-name = "LDO3";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO5 {
+ regulator-name = "LDO5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&i2c3 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+};
+
+&i2c4 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ status = "okay";
+
+ rtc@53 {
+ compatible = "nxp,pcf2131";
+ reg = <0x53>;
+ };
+};
+
+&uart2 {
+ /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+/* SD Card */
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ bus-width = <4>;
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc3 {
+ assigned-clocks = <&clk IMX8MP_CLK_USDHC3>;
+ assigned-clock-rates = <400000000>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_eqos: eqosgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_ENET_MDC__ENET_QOS_MDC 0x3
+ MX8MP_IOMUXC_ENET_MDIO__ENET_QOS_MDIO 0x3
+ MX8MP_IOMUXC_ENET_RD0__ENET_QOS_RGMII_RD0 0x91
+ MX8MP_IOMUXC_ENET_RD1__ENET_QOS_RGMII_RD1 0x91
+ MX8MP_IOMUXC_ENET_RD2__ENET_QOS_RGMII_RD2 0x91
+ MX8MP_IOMUXC_ENET_RD3__ENET_QOS_RGMII_RD3 0x91
+ MX8MP_IOMUXC_ENET_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x91
+ MX8MP_IOMUXC_ENET_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x91
+ MX8MP_IOMUXC_ENET_TD0__ENET_QOS_RGMII_TD0 0x1f
+ MX8MP_IOMUXC_ENET_TD1__ENET_QOS_RGMII_TD1 0x1f
+ MX8MP_IOMUXC_ENET_TD2__ENET_QOS_RGMII_TD2 0x1f
+ MX8MP_IOMUXC_ENET_TD3__ENET_QOS_RGMII_TD3 0x1f
+ MX8MP_IOMUXC_ENET_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x1f
+ MX8MP_IOMUXC_ENET_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x1f
+ MX8MP_IOMUXC_SAI2_RXC__GPIO4_IO22 0x110
+ >;
+ };
+
+ pinctrl_gpio_led: gpioledgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_READY_B__GPIO3_IO16 0x19
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL 0x400001c3
+ MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001c3
+ MX8MP_IOMUXC_I2C2_SDA__I2C2_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C3_SCL__I2C3_SCL 0x400001c3
+ MX8MP_IOMUXC_I2C3_SDA__I2C3_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C4_SCL__I2C4_SCL 0x400001c3
+ MX8MP_IOMUXC_I2C4_SDA__I2C4_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c6: i2c6grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_UART4_RXD__I2C6_SCL 0x400001c3
+ MX8MP_IOMUXC_UART4_TXD__I2C6_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_pmic: pmicirq {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ >;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_RESET_B__GPIO2_IO19 0x41
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x49
+ MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x49
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x190
+ MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d0
+ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d0
+ MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d0
+ MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d0
+ MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d0
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2grp-100mhz {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x194
+ MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d4
+ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d4
+ MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d4
+ MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d4
+ MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d4
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2grp-200mhz {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x196
+ MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d6
+ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d6
+ MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d6
+ MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d6
+ MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d6
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2grp-gpio {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CD_B__GPIO2_IO12 0x1c4
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x190
+ MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d0
+ MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d0
+ MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d0
+ MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d0
+ MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d0
+ MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d0
+ MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d0
+ MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d0
+ MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d0
+ MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x190
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3grp-100mhz {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x194
+ MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d4
+ MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d4
+ MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d4
+ MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d4
+ MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d4
+ MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d4
+ MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d4
+ MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d4
+ MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d4
+ MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x194
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3grp-200mhz {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x196
+ MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d6
+ MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d6
+ MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d6
+ MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d6
+ MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d6
+ MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d6
+ MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d6
+ MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d6
+ MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d6
+ MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x196
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO02__WDOG1_WDOG_B 0xc6
+ >;
+ };
+};
--
2.39.2
^ permalink raw reply related
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