On Tue, Oct 27, 2020 at 11:16:29PM +0300, Dmitry Osipenko wrote: > 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@xxxxxxxxx> > >>>> --- > >>>> .../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. I understand. Fine with me, thanks for explanation. Best regards, Krzysztof
