| Message ID | 20180818155430.5586-7-digetx@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | IOMMU: Tegra GART driver clean up and optimization | expand |
On Sat, Aug 18, 2018 at 06:54:17PM +0300, Dmitry Osipenko wrote: > Splitting GART and Memory Controller wasn't a good decision that was made > back in the day. Given that the GART driver hasn't ever been used by > anything in the kernel, we decided that it will be better to correct the > mistakes of the past and merge two bindings into a single one. In a result As a result... > there is a DT ABI change for the Memory Controller that allows not to > break newer kernels using older DT by introducing a new required property, > the memory clock. Adding the new clock property also puts the tegra20-mc > binding in line with the bindings of the later Tegra generations. I don't understand this part. It looks to me like you are breaking compatibility. The driver failing to probe with an old DT is okay? OS's like OpenSUSE use new DTs with older kernel versions, so you should consider how to not break them as well. I guess if all this is optional or has been unused, then there shouldn't be a problem. > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > .../bindings/iommu/nvidia,tegra20-gart.txt | 14 ----------- > .../memory-controllers/nvidia,tegra20-mc.txt | 23 ++++++++++++++----- > 2 files changed, 17 insertions(+), 20 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt > > diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt > deleted file mode 100644 > index 099d9362ebc1..000000000000 > --- a/Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt > +++ /dev/null > @@ -1,14 +0,0 @@ > -NVIDIA Tegra 20 GART > - > -Required properties: > -- compatible: "nvidia,tegra20-gart" > -- reg: Two pairs of cells specifying the physical address and size of > - the memory controller registers and the GART aperture respectively. > - > -Example: > - > - gart { > - compatible = "nvidia,tegra20-gart"; > - reg = <0x7000f024 0x00000018 /* controller registers */ > - 0x58000000 0x02000000>; /* GART aperture */ > - }; > diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt > index 7d60a50a4fa1..1564df89392a 100644 > --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt > +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt > @@ -2,25 +2,36 @@ NVIDIA Tegra20 MC(Memory Controller) > > Required properties: > - compatible : "nvidia,tegra20-mc" > -- reg : Should contain 2 register ranges(address and length); see the > - example below. Note that the MC registers are interleaved with the > - GART registers, and hence must be represented as multiple ranges. > +- reg : Should contain 2 register ranges: physical base address and length of > + the controller's registers and the GART aperture respectively. > +- clocks: Must contain an entry for each entry in clock-names. > + See ../clocks/clock-bindings.txt for details. > +- clock-names: Must include the following entries: > + - mc: the module's clock input > - interrupts : Should contain MC General interrupt. > - #reset-cells : Should be 1. This cell represents memory client module ID. > The assignments may be found in header file <dt-bindings/memory/tegra20-mc.h> > or in the TRM documentation. > +- #iommu-cells: Should be 0. This cell represents the number of cells in an > + IOMMU specifier needed to encode an address. GART supports only a single > + address space that is shared by all devices, therefore no additional > + information needed for the address encoding. > > Example: > mc: memory-controller@7000f000 { > compatible = "nvidia,tegra20-mc"; > - reg = <0x7000f000 0x024 > - 0x7000f03c 0x3c4>; > - interrupts = <0 77 0x04>; > + reg = <0x7000f000 0x400 /* controller registers */ > + 0x58000000 0x02000000>; /* GART aperture */ > + clocks = <&tegra_car TEGRA20_CLK_MC>; > + clock-names = "mc"; > + interrupts = <GIC_SPI 77 0x04>; > #reset-cells = <1>; > + #iommu-cells = <0>; > }; > > video-codec@6001a000 { > compatible = "nvidia,tegra20-vde"; > ... > resets = <&mc TEGRA20_MC_RESET_VDE>; > + iommus = <&mc>; > }; > -- > 2.18.0 >
On 20.08.2018 22:12, Rob Herring wrote: > On Sat, Aug 18, 2018 at 06:54:17PM +0300, Dmitry Osipenko wrote: >> Splitting GART and Memory Controller wasn't a good decision that was made >> back in the day. Given that the GART driver hasn't ever been used by >> anything in the kernel, we decided that it will be better to correct the >> mistakes of the past and merge two bindings into a single one. In a result > > As a result... > >> there is a DT ABI change for the Memory Controller that allows not to >> break newer kernels using older DT by introducing a new required property, >> the memory clock. Adding the new clock property also puts the tegra20-mc >> binding in line with the bindings of the later Tegra generations. > > I don't understand this part. It looks to me like you are breaking > compatibility. The driver failing to probe with an old DT is okay? Yes, DT compatibility is broken. New driver won't probe/load with the old DT, that's what we want. > OS's like OpenSUSE use new DTs with older kernel versions, so you should > consider how to not break them as well. I guess if all this is optional > or has been unused, then there shouldn't be a problem. That's interesting.. Memory Controller isn't optional, I guess we could change compatible to "nvidia,tegra20-mc-gart". Thierry, do you have any other suggestions?
On 20.08.2018 22:27, Dmitry Osipenko wrote: > On 20.08.2018 22:12, Rob Herring wrote: >> On Sat, Aug 18, 2018 at 06:54:17PM +0300, Dmitry Osipenko wrote: >>> Splitting GART and Memory Controller wasn't a good decision that was made >>> back in the day. Given that the GART driver hasn't ever been used by >>> anything in the kernel, we decided that it will be better to correct the >>> mistakes of the past and merge two bindings into a single one. In a result >> >> As a result... >> >>> there is a DT ABI change for the Memory Controller that allows not to >>> break newer kernels using older DT by introducing a new required property, >>> the memory clock. Adding the new clock property also puts the tegra20-mc >>> binding in line with the bindings of the later Tegra generations. >> >> I don't understand this part. It looks to me like you are breaking >> compatibility. The driver failing to probe with an old DT is okay? > > Yes, DT compatibility is broken. New driver won't probe/load with the old DT, > that's what we want. > >> OS's like OpenSUSE use new DTs with older kernel versions, so you should >> consider how to not break them as well. I guess if all this is optional >> or has been unused, then there shouldn't be a problem. > > That's interesting.. Memory Controller isn't optional, I guess we could change > compatible to "nvidia,tegra20-mc-gart". * I meant it's not optional in a sense that it's enabled in kernels config by default and driver is functional, but it's okay if MC driver will stop to probe with older kernels as it is used only for reporting memory errors.
On Mon, Aug 20, 2018 at 10:35:54PM +0300, Dmitry Osipenko wrote: > On 20.08.2018 22:27, Dmitry Osipenko wrote: > > On 20.08.2018 22:12, Rob Herring wrote: > >> On Sat, Aug 18, 2018 at 06:54:17PM +0300, Dmitry Osipenko wrote: > >>> Splitting GART and Memory Controller wasn't a good decision that was made > >>> back in the day. Given that the GART driver hasn't ever been used by > >>> anything in the kernel, we decided that it will be better to correct the > >>> mistakes of the past and merge two bindings into a single one. In a result > >> > >> As a result... > >> > >>> there is a DT ABI change for the Memory Controller that allows not to > >>> break newer kernels using older DT by introducing a new required property, > >>> the memory clock. Adding the new clock property also puts the tegra20-mc > >>> binding in line with the bindings of the later Tegra generations. > >> > >> I don't understand this part. It looks to me like you are breaking > >> compatibility. The driver failing to probe with an old DT is okay? > > > > Yes, DT compatibility is broken. New driver won't probe/load with the old DT, > > that's what we want. > > > >> OS's like OpenSUSE use new DTs with older kernel versions, so you should > >> consider how to not break them as well. I guess if all this is optional > >> or has been unused, then there shouldn't be a problem. > > > > That's interesting.. Memory Controller isn't optional, I guess we could change > > compatible to "nvidia,tegra20-mc-gart". > > * I meant it's not optional in a sense that it's enabled in kernels config by > default and driver is functional, but it's okay if MC driver will stop to probe > with older kernels as it is used only for reporting memory errors. Yeah, we don't really regress at runtime. The errors reported by the current driver are very rare, and even if you encounter them, they're pretty cryptic, so I think this is one of the exceptional cases where breaking the ABI "for the greater good" is acceptable. Thierry
On 28.08.2018 13:47, Thierry Reding wrote: > On Mon, Aug 20, 2018 at 10:35:54PM +0300, Dmitry Osipenko wrote: >> On 20.08.2018 22:27, Dmitry Osipenko wrote: >>> On 20.08.2018 22:12, Rob Herring wrote: >>>> On Sat, Aug 18, 2018 at 06:54:17PM +0300, Dmitry Osipenko wrote: >>>>> Splitting GART and Memory Controller wasn't a good decision that was made >>>>> back in the day. Given that the GART driver hasn't ever been used by >>>>> anything in the kernel, we decided that it will be better to correct the >>>>> mistakes of the past and merge two bindings into a single one. In a result >>>> >>>> As a result... >>>> >>>>> there is a DT ABI change for the Memory Controller that allows not to >>>>> break newer kernels using older DT by introducing a new required property, >>>>> the memory clock. Adding the new clock property also puts the tegra20-mc >>>>> binding in line with the bindings of the later Tegra generations. >>>> >>>> I don't understand this part. It looks to me like you are breaking >>>> compatibility. The driver failing to probe with an old DT is okay? >>> >>> Yes, DT compatibility is broken. New driver won't probe/load with the old DT, >>> that's what we want. >>> >>>> OS's like OpenSUSE use new DTs with older kernel versions, so you should >>>> consider how to not break them as well. I guess if all this is optional >>>> or has been unused, then there shouldn't be a problem. >>> >>> That's interesting.. Memory Controller isn't optional, I guess we could change >>> compatible to "nvidia,tegra20-mc-gart".bled in kernels config by >> default and driver is functional, but it's okay >> >> * I meant it's not optional in a sense that it's enaif MC driver will stop to probe >> with older kernels as it is used only for reporting memory errors. > > Yeah, we don't really regress at runtime. The errors reported by the > current driver are very rare, and even if you encounter them, they're > pretty cryptic, so I think this is one of the exceptional cases where > breaking the ABI "for the greater good" is acceptable. It's now became apparent that factoring out EMC from MC isn't a good idea too because MC need to interact with EMC and probably vice versa. Looks like we should consider restructuring MC for all Tegra's.
diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt deleted file mode 100644 index 099d9362ebc1..000000000000 --- a/Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt +++ /dev/null @@ -1,14 +0,0 @@ -NVIDIA Tegra 20 GART - -Required properties: -- compatible: "nvidia,tegra20-gart" -- reg: Two pairs of cells specifying the physical address and size of - the memory controller registers and the GART aperture respectively. - -Example: - - gart { - compatible = "nvidia,tegra20-gart"; - reg = <0x7000f024 0x00000018 /* controller registers */ - 0x58000000 0x02000000>; /* GART aperture */ - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt index 7d60a50a4fa1..1564df89392a 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt @@ -2,25 +2,36 @@ NVIDIA Tegra20 MC(Memory Controller) Required properties: - compatible : "nvidia,tegra20-mc" -- reg : Should contain 2 register ranges(address and length); see the - example below. Note that the MC registers are interleaved with the - GART registers, and hence must be represented as multiple ranges. +- reg : Should contain 2 register ranges: physical base address and length of + the controller's registers and the GART aperture respectively. +- clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names: Must include the following entries: + - mc: the module's clock input - interrupts : Should contain MC General interrupt. - #reset-cells : Should be 1. This cell represents memory client module ID. The assignments may be found in header file <dt-bindings/memory/tegra20-mc.h> or in the TRM documentation. +- #iommu-cells: Should be 0. This cell represents the number of cells in an + IOMMU specifier needed to encode an address. GART supports only a single + address space that is shared by all devices, therefore no additional + information needed for the address encoding. Example: mc: memory-controller@7000f000 { compatible = "nvidia,tegra20-mc"; - reg = <0x7000f000 0x024 - 0x7000f03c 0x3c4>; - interrupts = <0 77 0x04>; + reg = <0x7000f000 0x400 /* controller registers */ + 0x58000000 0x02000000>; /* GART aperture */ + clocks = <&tegra_car TEGRA20_CLK_MC>; + clock-names = "mc"; + interrupts = <GIC_SPI 77 0x04>; #reset-cells = <1>; + #iommu-cells = <0>; }; video-codec@6001a000 { compatible = "nvidia,tegra20-vde"; ... resets = <&mc TEGRA20_MC_RESET_VDE>; + iommus = <&mc>; };
Splitting GART and Memory Controller wasn't a good decision that was made back in the day. Given that the GART driver hasn't ever been used by anything in the kernel, we decided that it will be better to correct the mistakes of the past and merge two bindings into a single one. In a result there is a DT ABI change for the Memory Controller that allows not to break newer kernels using older DT by introducing a new required property, the memory clock. Adding the new clock property also puts the tegra20-mc binding in line with the bindings of the later Tegra generations. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> --- .../bindings/iommu/nvidia,tegra20-gart.txt | 14 ----------- .../memory-controllers/nvidia,tegra20-mc.txt | 23 ++++++++++++++----- 2 files changed, 17 insertions(+), 20 deletions(-) delete mode 100644 Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt