Messages in this thread | | | Subject | Re: [PATCH v6 13/52] dt-bindings: memory: tegra124: emc: Document new interconnect property | From | Dmitry Osipenko <> | Date | Tue, 27 Oct 2020 23:16:29 +0300 |
| |
27.10.2020 22:48, Krzysztof Kozlowski пишет: > On Tue, Oct 27, 2020 at 10:19:28PM +0300, Dmitry Osipenko wrote: >> 27.10.2020 13:25, Krzysztof Kozlowski пишет: >>> On Mon, Oct 26, 2020 at 01:16:56AM +0300, Dmitry Osipenko wrote: >>>> External memory controller is interconnected with memory controller and >>>> with external memory. Document new interconnect property which turns >>>> External Memory Controller into interconnect provider. >>>> >>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >>>> --- >>>> .../bindings/memory-controllers/nvidia,tegra124-emc.yaml | 7 +++++++ >>>> 1 file changed, 7 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml >>>> index 278549f9e051..ac00832ceac1 100644 >>>> --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml >>>> +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml >>>> @@ -29,6 +29,9 @@ properties: >>>> items: >>>> - const: emc >>>> >>>> + "#interconnect-cells": >>>> + const: 0 >>>> + >>>> nvidia,memory-controller: >>>> $ref: /schemas/types.yaml#/definitions/phandle >>>> description: >>>> @@ -327,6 +330,7 @@ required: >>>> - clocks >>>> - clock-names >>>> - nvidia,memory-controller >>>> + - "#interconnect-cells" >>> >>> Another required property, what about all existing users of this binding? >> >> EMC/devfreq drivers check presence of the new properties and ask users >> to upgrade the DT. The kernel will continue to work fine using older >> DTBs, but devfreq driver won't load. > > If the devfreq was working fine before (with these older DTBs and older > kernel) then you break the feature. > > If devfreq was not working or was not stable enough, then nothing is > broken so such change is accepted. > > Which one is then?
Definitely the latter. The current devfreq works okay'ish, but we rely on hardware to recover from temporal FIFO underflows and it's a user-visible problem which this series addresses.
| |