Reorganize the K1 SoC device tree to better reflect the hardware topology
by introducing a dedicated dma_bus node that groups devices sharing
the same address translation scheme. This change aligns with the actual
hardware organization where devices are physically connected to different
bus segments with different address translation characteristics.
The changes include:
- New dma_bus node with:
* DMA address translation ranges:
- First range: 0x0_00000000 -> 0x0_00000000 (size: 2GB)
- Second range: 0x1_00000000 -> 0x1_80000000 (size: 12GB)
* All UART devices moved under this bus to reflect their shared address
translation domain
- New PDMA controller node under dma_bus with:
* Base address and interrupt configuration
* Clock and reset controls
* 16 DMA channels
* Required DMA cell properties
The PDMA node is marked as disabled by default, allowing board-specific
device trees to enable it as needed.
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
arch/riscv/boot/dts/spacemit/k1.dtsi | 234 +++++++++++++++------------
1 file changed, 128 insertions(+), 106 deletions(-)
diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
index dead05a3c816..557feac860de 100644
--- a/arch/riscv/boot/dts/spacemit/k1.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
@@ -369,112 +369,13 @@ syscon_apbc: system-controller@d4015000 {
#reset-cells = <1>;
};
- uart0: serial@d4017000 {
- compatible = "spacemit,k1-uart", "intel,xscale-uart";
- reg = <0x0 0xd4017000 0x0 0x100>;
- clocks = <&syscon_apbc CLK_UART0>,
- <&syscon_apbc CLK_UART0_BUS>;
- clock-names = "core", "bus";
- interrupts = <42>;
- reg-shift = <2>;
- reg-io-width = <4>;
- status = "disabled";
- };
-
- uart2: serial@d4017100 {
- compatible = "spacemit,k1-uart", "intel,xscale-uart";
- reg = <0x0 0xd4017100 0x0 0x100>;
- clocks = <&syscon_apbc CLK_UART2>,
- <&syscon_apbc CLK_UART2_BUS>;
- clock-names = "core", "bus";
- interrupts = <44>;
- reg-shift = <2>;
- reg-io-width = <4>;
- status = "disabled";
- };
-
- uart3: serial@d4017200 {
- compatible = "spacemit,k1-uart", "intel,xscale-uart";
- reg = <0x0 0xd4017200 0x0 0x100>;
- clocks = <&syscon_apbc CLK_UART3>,
- <&syscon_apbc CLK_UART3_BUS>;
- clock-names = "core", "bus";
- interrupts = <45>;
- reg-shift = <2>;
- reg-io-width = <4>;
- status = "disabled";
- };
-
- uart4: serial@d4017300 {
- compatible = "spacemit,k1-uart", "intel,xscale-uart";
- reg = <0x0 0xd4017300 0x0 0x100>;
- clocks = <&syscon_apbc CLK_UART4>,
- <&syscon_apbc CLK_UART4_BUS>;
- clock-names = "core", "bus";
- interrupts = <46>;
- reg-shift = <2>;
- reg-io-width = <4>;
- status = "disabled";
- };
-
- uart5: serial@d4017400 {
- compatible = "spacemit,k1-uart", "intel,xscale-uart";
- reg = <0x0 0xd4017400 0x0 0x100>;
- clocks = <&syscon_apbc CLK_UART5>,
- <&syscon_apbc CLK_UART5_BUS>;
- clock-names = "core", "bus";
- interrupts = <47>;
- reg-shift = <2>;
- reg-io-width = <4>;
- status = "disabled";
- };
-
- uart6: serial@d4017500 {
- compatible = "spacemit,k1-uart", "intel,xscale-uart";
- reg = <0x0 0xd4017500 0x0 0x100>;
- clocks = <&syscon_apbc CLK_UART6>,
- <&syscon_apbc CLK_UART6_BUS>;
- clock-names = "core", "bus";
- interrupts = <48>;
- reg-shift = <2>;
- reg-io-width = <4>;
- status = "disabled";
- };
-
- uart7: serial@d4017600 {
- compatible = "spacemit,k1-uart", "intel,xscale-uart";
- reg = <0x0 0xd4017600 0x0 0x100>;
- clocks = <&syscon_apbc CLK_UART7>,
- <&syscon_apbc CLK_UART7_BUS>;
- clock-names = "core", "bus";
- interrupts = <49>;
- reg-shift = <2>;
- reg-io-width = <4>;
- status = "disabled";
- };
-
- uart8: serial@d4017700 {
- compatible = "spacemit,k1-uart", "intel,xscale-uart";
- reg = <0x0 0xd4017700 0x0 0x100>;
- clocks = <&syscon_apbc CLK_UART8>,
- <&syscon_apbc CLK_UART8_BUS>;
- clock-names = "core", "bus";
- interrupts = <50>;
- reg-shift = <2>;
- reg-io-width = <4>;
- status = "disabled";
- };
-
- uart9: serial@d4017800 {
- compatible = "spacemit,k1-uart", "intel,xscale-uart";
- reg = <0x0 0xd4017800 0x0 0x100>;
- clocks = <&syscon_apbc CLK_UART9>,
- <&syscon_apbc CLK_UART9_BUS>;
- clock-names = "core", "bus";
- interrupts = <51>;
- reg-shift = <2>;
- reg-io-width = <4>;
- status = "disabled";
+ dma_bus: bus@4 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ dma-ranges = <0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>,
+ <0x1 0x00000000 0x1 0x80000000 0x3 0x00000000>;
+ ranges;
};
gpio: gpio@d4019000 {
@@ -792,3 +693,124 @@ pwm19: pwm@d4022c00 {
};
};
};
+
+&dma_bus {
+ pdma0: dma-controller@d4000000 {
+ compatible = "spacemit,pdma-1.0";
+ reg = <0x0 0xd4000000 0x0 0x4000>;
+ interrupts = <72>;
+ clocks = <&syscon_apmu CLK_DMA>;
+ resets = <&syscon_apmu RESET_DMA>;
+ #dma-cells= <2>;
+ #dma-channels = <16>;
+ status = "disabled";
+ };
+
+ uart0: serial@d4017000 {
+ compatible = "spacemit,k1-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017000 0x0 0x100>;
+ clocks = <&syscon_apbc CLK_UART0>,
+ <&syscon_apbc CLK_UART0_BUS>;
+ clock-names = "core", "bus";
+ interrupts = <42>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart2: serial@d4017100 {
+ compatible = "spacemit,k1-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017100 0x0 0x100>;
+ clocks = <&syscon_apbc CLK_UART2>,
+ <&syscon_apbc CLK_UART2_BUS>;
+ clock-names = "core", "bus";
+ interrupts = <44>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart3: serial@d4017200 {
+ compatible = "spacemit,k1-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017200 0x0 0x100>;
+ clocks = <&syscon_apbc CLK_UART3>,
+ <&syscon_apbc CLK_UART3_BUS>;
+ clock-names = "core", "bus";
+ interrupts = <45>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart4: serial@d4017300 {
+ compatible = "spacemit,k1-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017300 0x0 0x100>;
+ clocks = <&syscon_apbc CLK_UART4>,
+ <&syscon_apbc CLK_UART4_BUS>;
+ clock-names = "core", "bus";
+ interrupts = <46>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart5: serial@d4017400 {
+ compatible = "spacemit,k1-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017400 0x0 0x100>;
+ clocks = <&syscon_apbc CLK_UART5>,
+ <&syscon_apbc CLK_UART5_BUS>;
+ clock-names = "core", "bus";
+ interrupts = <47>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart6: serial@d4017500 {
+ compatible = "spacemit,k1-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017500 0x0 0x100>;
+ clocks = <&syscon_apbc CLK_UART6>,
+ <&syscon_apbc CLK_UART6_BUS>;
+ clock-names = "core", "bus";
+ interrupts = <48>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart7: serial@d4017600 {
+ compatible = "spacemit,k1-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017600 0x0 0x100>;
+ clocks = <&syscon_apbc CLK_UART7>,
+ <&syscon_apbc CLK_UART7_BUS>;
+ clock-names = "core", "bus";
+ interrupts = <49>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart8: serial@d4017700 {
+ compatible = "spacemit,k1-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017700 0x0 0x100>;
+ clocks = <&syscon_apbc CLK_UART8>,
+ <&syscon_apbc CLK_UART8_BUS>;
+ clock-names = "core", "bus";
+ interrupts = <50>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart9: serial@d4017800 {
+ compatible = "spacemit,k1-uart", "intel,xscale-uart";
+ reg = <0x0 0xd4017800 0x0 0x100>;
+ clocks = <&syscon_apbc CLK_UART9>,
+ <&syscon_apbc CLK_UART9_BUS>;
+ clock-names = "core", "bus";
+ interrupts = <51>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+}; /* &dma_bus */
--
2.43.0Hi Guodong,
On 6/11/25 20:57, Guodong Xu wrote:
> <snip>
>
> - status = "disabled";
> + dma_bus: bus@4 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + dma-ranges = <0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>,
> + <0x1 0x00000000 0x1 0x80000000 0x3 0x00000000>;
> + ranges;
> };
Can the addition of dma_bus and movement of nodes under it be extracted
into a separate patch, and ideally, taken up by Yixun Lan without going
through dmaengine? Not specifically "dram_range4", but all of these
translations affects many devices on the SoC, including ethernet and
USB3. See:
https://lore.kernel.org/all/20250526-b4-k1-dwc3-v3-v4-2-63e4e525e5cb@whut.edu.cn/
https://lore.kernel.org/all/20250613-net-k1-emac-v1-0-cc6f9e510667@iscas.ac.cn/
(I haven't put eth{0,1} under dma_bus5 because in 6.16-rc1 there is
none, but ideally we should fix this.)
DMA address translation does not depend on PDMA. It would be best if we
get all the possible dma-ranges buses handled in one place, instead of
everyone moving nodes around.
@Ze Huang: This affects your "MBUS" changes as well. Please take a look,
thanks.
>
> gpio: gpio@d4019000 {
> @@ -792,3 +693,124 @@ pwm19: pwm@d4022c00 {
> };
> };
> };
> +
> +&dma_bus {
>
> <snip>
On Fri, Jun 13, 2025 at 11:07 AM Vivian Wang <uwu@dram.page> wrote:
>
> Hi Guodong,
>
> On 6/11/25 20:57, Guodong Xu wrote:
> > <snip>
> >
> > - status = "disabled";
> > + dma_bus: bus@4 {
> > + compatible = "simple-bus";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + dma-ranges = <0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>,
> > + <0x1 0x00000000 0x1 0x80000000 0x3 0x00000000>;
> > + ranges;
> > };
>
> Can the addition of dma_bus and movement of nodes under it be extracted
> into a separate patch, and ideally, taken up by Yixun Lan without going
> through dmaengine? Not specifically "dram_range4", but all of these
> translations affects many devices on the SoC, including ethernet and
It was not my intention to add all the separate memory mapping buses into
one patch. I'd prefer to add them when there is at least one user.
The k1.dtsi at this moment, as I checked, has no real user beside the
so-called "dram_range4" in downstream vendor kernel (ie. dma_bus in this
patch). And that is what I did: grouping devices which share the same
dma address mapping as pdma0 into one single separated bus.
The other buses, even if I add them, would be empty.
What the SpacemiT team agreed upon so far, is the naming of these separated
buses. I listed them here for future reference purposes.
If needed, I can send that in a RFC patchset, of course; or as a normal
PATCH, if Yixun is ok with that. However, please note, that would mean more
merging dependencies: PDMA dts, ethernet dts, usb dts, will have to depend
on this base 'buses' PATCH.
Again, I prefer we add our own 'bus' when there is a need.
+ soc {
+ storage_bus: bus@0 {
+ /* USB, SDH storage controllers */
+ dma-ranges = <0x0 0x00000000 0x0 0x00000000
0x0 0x80000000>;
+ };
+
+ multimedia_bus: bus@1 {
+ /* VPU, GPU, DPU */
+ dma-ranges = <0x0 0x00000000 0x0 0x00000000
0x0 0x80000000>,
+ <0x0 0x80000000 0x1 0x00000000
0x3 0x80000000>;
+ };
+
+ pcie_bus: bus@2 {
+ /* PCIe controllers */
+ dma-ranges = <0x0 0x00000000 0x0 0x00000000
0x0 0x80000000>,
+ <0x0 0xb8000000 0x1 0x38000000
0x3 0x48000000>;
+ };
+
+ camera_bus: bus@3 {
+ /* ISP, CSI, imaging devices */
+ dma-ranges = <0x0 0x00000000 0x0 0x00000000
0x0 0x80000000>,
+ <0x0 0x80000000 0x1 0x00000000
0x1 0x80000000>;
+ };
+
+ dma_bus: bus@4 {
+ /* DMA controller, and users */
+ dma-ranges = <0x0 0x00000000 0x0 0x00000000
0x0 0x80000000>,
+ <0x1 0x00000000 0x1 0x80000000
0x3 0x00000000>;
+ };
+
+ network_bus: bus@5 {
+ /* Ethernet, Crypto, JPU */
+ dma-ranges = <0x0 0x00000000 0x0 0x00000000
0x0 0x80000000>,
+ <0x0 0x80000000 0x1 0x00000000
0x0 0x80000000>;
+ };
+
+ }; /* soc */
> USB3. See:
>
> https://lore.kernel.org/all/20250526-b4-k1-dwc3-v3-v4-2-63e4e525e5cb@whut.edu.cn/
> https://lore.kernel.org/all/20250613-net-k1-emac-v1-0-cc6f9e510667@iscas.ac.cn/
>
> (I haven't put eth{0,1} under dma_bus5 because in 6.16-rc1 there is
> none, but ideally we should fix this.)
So, as you are submitting the first node(s) under network_bus: bus@5, you
should have this added into your patchset, instead of sending out with none.
The same logic goes to USB too, Ze Huang was in the same offline call, and
I would prefer that we move in a coordinated way.
>
> DMA address translation does not depend on PDMA. It would be best if we
> get all the possible dma-ranges buses handled in one place, instead of
> everyone moving nodes around.
No, you should do it in your patchset, when you add the eth0 and eth1 nodes,
they will be the first in, as I said, "network_bus". I don't expect
any 'moving nodes around'.
>
> @Ze Huang: This affects your "MBUS" changes as well. Please take a look,
> thanks.
>
> >
> > gpio: gpio@d4019000 {
> > @@ -792,3 +693,124 @@ pwm19: pwm@d4022c00 {
> > };
> > };
> > };
> > +
> > +&dma_bus {
> >
> > <snip>
>
[Resent to get rid of HTML. This is my last try.]
On 6/14/25 10:53, Guodong Xu wrote:
> On Fri, Jun 13, 2025 at 11:07 AM Vivian Wang<uwu@dram.page> wrote:
>> Hi Guodong,
>>
>> On 6/11/25 20:57, Guodong Xu wrote:
>>> <snip>
>>>
>>> - status = "disabled";
>>> + dma_bus: bus@4 {
>>> + compatible = "simple-bus";
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + dma-ranges = <0x0 0x00000000 0x0 0x00000000
>>> 0x0 0x80000000>,
>>> + <0x1 0x00000000 0x1 0x80000000
>>> 0x3 0x00000000>;
>>> + ranges;
>>> };
>> Can the addition of dma_bus and movement of nodes under it be extracted
>> into a separate patch, and ideally, taken up by Yixun Lan without going
>> through dmaengine? Not specifically "dram_range4", but all of these
>> translations affects many devices on the SoC, including ethernet and
> It was not my intention to add all the separate memory mapping buses into
> one patch. I'd prefer to add them when there is at least one user.
> The k1.dtsi at this moment, as I checked, has no real user beside the
> so-called "dram_range4" in downstream vendor kernel (ie. dma_bus in this
> patch). And that is what I did: grouping devices which share the same
> dma address mapping as pdma0 into one single separated bus.
>
> The other buses, even if I add them, would be empty.
>
> What the SpacemiT team agreed upon so far, is the naming of these
> separated
> buses. I listed them here for future reference purposes.
>
> If needed, I can send that in a RFC patchset, of course; or as a normal
> PATCH, if Yixun is ok with that. However, please note, that would mean
> more
> merging dependencies: PDMA dts, ethernet dts, usb dts, will have to
> depend
> on this base 'buses' PATCH.
>
> Again, I prefer we add our own 'bus' when there is a need.
>
> + soc {
> + storage_bus: bus@0 {
> + /* USB, SDH storage controllers */
> + dma-ranges = <0x0 0x00000000 0x0 0x00000000
> 0x0 0x80000000>;
> + };
> +
> + multimedia_bus: bus@1 {
> + /* VPU, GPU, DPU */
> + dma-ranges = <0x0 0x00000000 0x0 0x00000000
> 0x0 0x80000000>,
> + <0x0 0x80000000 0x1 0x00000000
> 0x3 0x80000000>;
> + };
> +
> + pcie_bus: bus@2 {
> + /* PCIe controllers */
> + dma-ranges = <0x0 0x00000000 0x0 0x00000000
> 0x0 0x80000000>,
> + <0x0 0xb8000000 0x1 0x38000000
> 0x3 0x48000000>;
> + };
> +
> + camera_bus: bus@3 {
> + /* ISP, CSI, imaging devices */
> + dma-ranges = <0x0 0x00000000 0x0 0x00000000
> 0x0 0x80000000>,
> + <0x0 0x80000000 0x1 0x00000000
> 0x1 0x80000000>;
> + };
> +
> + dma_bus: bus@4 {
> + /* DMA controller, and users */
> + dma-ranges = <0x0 0x00000000 0x0 0x00000000
> 0x0 0x80000000>,
> + <0x1 0x00000000 0x1 0x80000000
> 0x3 0x00000000>;
> + };
> +
> + network_bus: bus@5 {
> + /* Ethernet, Crypto, JPU */
> + dma-ranges = <0x0 0x00000000 0x0 0x00000000
> 0x0 0x80000000>,
> + <0x0 0x80000000 0x1 0x00000000
> 0x0 0x80000000>;
> + };
> +
> + }; /* soc */
Ah, I didn't know the names were already decided.
However, I still think we should at least separate the patch into two in
the same series, one adding the bus node and handling existing nodes,
and another adding the new node under it. This way, say someone starts
working on Crypto, they can simply depends on the first bus patch
without having to pull in the new node.
I still prefer having a canonical buses patch though.
If we're going to agree here on what the buses should look, I also have
two nitpicks, just so we get this sorted: Firstly, I think storage_bus
should be removed. Anything using storage_bus is already handled by
simply using 32-bit-only DMA, which is the default anyway. @Ze Huang:
Your USB controller falls under it, what do you think?
Also, as suggested the node names must not have a made up unit address.
"bus@1" is inappropriate because they have no reg. The simple-bus schema
allows the node name to have a prefix like "foo-bus" [1] [2], so it
should be like:
/* DMA controller, and users */
dma_bus: dma-bus {
compatible = "simple-bus";
ranges;
#address-cells = <2>;
#size-cells = <2>;
dma-ranges = <0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>,
<0x1 0x00000000 0x1 0x80000000 0x3 0x00000000>;
};
(Pardon the formatting; I don't know if the tabs survived Thunderbird.)
[1]:https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/simple-bus.yaml
[2]:https://github.com/devicetree-org/dt-schema/commit/bab67075926b8bdc4093edbb9888aaa5bd8befd5
Well, that is the reason I wanted the bus things to be its own patch: I
think the DT maintainers should review these once and for all, not six
separate times as the drivers come in.
>> USB3. See:
>>
>> https://lore.kernel.org/all/20250526-b4-k1-dwc3-v3-v4-2-63e4e525e5cb@whut.edu.cn/
>>
>> https://lore.kernel.org/all/20250613-net-k1-emac-v1-0-cc6f9e510667@iscas.ac.cn/
>>
>>
>> (I haven't put eth{0,1} under dma_bus5 because in 6.16-rc1 there is
>> none, but ideally we should fix this.)
> So, as you are submitting the first node(s) under network_bus: bus@5, you
> should have this added into your patchset, instead of sending out with
> none.
I hope we can agree on what the bus nodes look like before we do that
separately.
> The same logic goes to USB too, Ze Huang was in the same offline call,
> and
> I would prefer that we move in a coordinated way.
I hope so as well, but "we" here should include DT maintainers.
Please consider my suggestions.
Vivian "dramforever" Wang
>> DMA address translation does not depend on PDMA. It would be best if we
>> get all the possible dma-ranges buses handled in one place, instead of
>> everyone moving nodes around.
> No, you should do it in your patchset, when you add the eth0 and eth1
> nodes,
> they will be the first in, as I said, "network_bus". I don't expect
> any 'moving nodes around'.
>
>> @Ze Huang: This affects your "MBUS" changes as well. Please take a look,
>> thanks.
>>
>>> gpio: gpio@d4019000 {
>>> @@ -792,3 +693,124 @@ pwm19: pwm@d4022c00 {
>>> };
>>> };
>>> };
>>> +
>>> +&dma_bus {
>>>
>>> <snip>
On Fri, Jun 13, 2025 at 11:06:43AM +0800, Vivian Wang wrote:
> Hi Guodong,
>
> On 6/11/25 20:57, Guodong Xu wrote:
> > <snip>
> >
> > - status = "disabled";
> > + dma_bus: bus@4 {
> > + compatible = "simple-bus";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + dma-ranges = <0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>,
> > + <0x1 0x00000000 0x1 0x80000000 0x3 0x00000000>;
> > + ranges;
> > };
>
> Can the addition of dma_bus and movement of nodes under it be extracted
> into a separate patch, and ideally, taken up by Yixun Lan without going
> through dmaengine? Not specifically "dram_range4", but all of these
> translations affects many devices on the SoC, including ethernet and
> USB3. See:
>
> https://lore.kernel.org/all/20250526-b4-k1-dwc3-v3-v4-2-63e4e525e5cb@whut.edu.cn/
> https://lore.kernel.org/all/20250613-net-k1-emac-v1-0-cc6f9e510667@iscas.ac.cn/
>
> (I haven't put eth{0,1} under dma_bus5 because in 6.16-rc1 there is
> none, but ideally we should fix this.)
>
> DMA address translation does not depend on PDMA. It would be best if we
> get all the possible dma-ranges buses handled in one place, instead of
> everyone moving nodes around.
Agree
>
> @Ze Huang: This affects your "MBUS" changes as well. Please take a look,
> thanks.
Thanks for reminding. I would drop MBUS and follow the "dma_bus" approach.
>
> >
> > gpio: gpio@d4019000 {
> > @@ -792,3 +693,124 @@ pwm19: pwm@d4022c00 {
> > };
> > };
> > };
> > +
> > +&dma_bus {
> >
> > <snip>
Hi Vivian, Guodong,
On 11:06 Fri 13 Jun , Vivian Wang wrote:
> Hi Guodong,
>
> On 6/11/25 20:57, Guodong Xu wrote:
> > <snip>
> >
> > - status = "disabled";
> > + dma_bus: bus@4 {
> > + compatible = "simple-bus";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + dma-ranges = <0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>,
> > + <0x1 0x00000000 0x1 0x80000000 0x3 0x00000000>;
> > + ranges;
> > };
>
> Can the addition of dma_bus and movement of nodes under it be extracted
> into a separate patch, and ideally, taken up by Yixun Lan without going
> through dmaengine? Not specifically "dram_range4", but all of these
> translations affects many devices on the SoC, including ethernet and
> USB3. See:
Right, we've had an offline discussion, and agreed on this - have *bus
patches separated and let other patches depend on it.
But seems Guodong failed to do this or just sent out an old version
of the PDMA patch?
>
> https://lore.kernel.org/all/20250526-b4-k1-dwc3-v3-v4-2-63e4e525e5cb@whut.edu.cn/
> https://lore.kernel.org/all/20250613-net-k1-emac-v1-0-cc6f9e510667@iscas.ac.cn/
>
> (I haven't put eth{0,1} under dma_bus5 because in 6.16-rc1 there is
> none, but ideally we should fix this.)
>
> DMA address translation does not depend on PDMA. It would be best if we
> get all the possible dma-ranges buses handled in one place, instead of
> everyone moving nodes around.
>
I agree
> @Ze Huang: This affects your "MBUS" changes as well. Please take a look,
> thanks.
>
> >
> > gpio: gpio@d4019000 {
> > @@ -792,3 +693,124 @@ pwm19: pwm@d4022c00 {
> > };
> > };
> > };
> > +
> > +&dma_bus {
> >
> > <snip>
>
--
Yixun Lan (dlan)
Hi, Yixun
On Fri, Jun 13, 2025 at 9:22 PM Yixun Lan <dlan@gentoo.org> wrote:
>
> Hi Vivian, Guodong,
>
> On 11:06 Fri 13 Jun , Vivian Wang wrote:
> > Hi Guodong,
> >
> > On 6/11/25 20:57, Guodong Xu wrote:
> > > <snip>
> > >
> > > - status = "disabled";
> > > + dma_bus: bus@4 {
> > > + compatible = "simple-bus";
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + dma-ranges = <0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>,
> > > + <0x1 0x00000000 0x1 0x80000000 0x3 0x00000000>;
> > > + ranges;
> > > };
> >
> > Can the addition of dma_bus and movement of nodes under it be extracted
> > into a separate patch, and ideally, taken up by Yixun Lan without going
> > through dmaengine? Not specifically "dram_range4", but all of these
> > translations affects many devices on the SoC, including ethernet and
> > USB3. See:
> Right, we've had an offline discussion, and agreed on this - have *bus
> patches separated and let other patches depend on it.
>
> But seems Guodong failed to do this or just sent out an old version
> of the PDMA patch?
Hi, Yixun
I realized that there is some sort of discrepancy between our understanding
from the offline discussion. With the information I put in the other email
earlier today, do you still think we should submit one patch which
covers all 6 seperated memory mapping buses for k1.dtsi?
Let me know what do you think. Thank you.
BR,
Guodong
>
> >
> > https://lore.kernel.org/all/20250526-b4-k1-dwc3-v3-v4-2-63e4e525e5cb@whut.edu.cn/
> > https://lore.kernel.org/all/20250613-net-k1-emac-v1-0-cc6f9e510667@iscas.ac.cn/
> >
> > (I haven't put eth{0,1} under dma_bus5 because in 6.16-rc1 there is
> > none, but ideally we should fix this.)
> >
> > DMA address translation does not depend on PDMA. It would be best if we
> > get all the possible dma-ranges buses handled in one place, instead of
> > everyone moving nodes around.
> >
> I agree
>
> > @Ze Huang: This affects your "MBUS" changes as well. Please take a look,
> > thanks.
> >
> > >
> > > gpio: gpio@d4019000 {
> > > @@ -792,3 +693,124 @@ pwm19: pwm@d4022c00 {
> > > };
> > > };
> > > };
> > > +
> > > +&dma_bus {
> > >
> > > <snip>
> >
>
> --
> Yixun Lan (dlan)
© 2016 - 2025 Red Hat, Inc.