mbox series

[v6,00/52] Introduce memory interconnect for NVIDIA Tegra SoCs

Message ID 20201025221735.3062-1-digetx@gmail.com (mailing list archive)
Headers show
Series Introduce memory interconnect for NVIDIA Tegra SoCs | expand

Message

Dmitry Osipenko Oct. 25, 2020, 10:16 p.m. UTC
Hello,

This series brings initial support for memory interconnect to Tegra20,
Tegra30 and Tegra124 SoCs.

For the starter only display controllers and devfreq devices are getting
interconnect API support, others could be supported later on. The display
controllers have the biggest demand for interconnect API right now because
dynamic memory frequency scaling can't be done safely without taking into
account bandwidth requirement from the displays. In particular this series
fixes distorted display output on T30 Ouya and T124 TK1 devices.

Changelog:

v6: - This series was massively reworked in comparison to v5, most of the
      patches that previously got r-b need a new round of a review (!).

    - Added missed clk-rounding to the set() callback of EMC ICC providers.
      Now clk_set_min_rate() doesn't error out on rate overflow.

    - Now peak bandwidth is properly taken into account by the set() callback
      of EMC ICC providers.

    - EMC runs at 2x of the DRAM bus only on Tegra20, this now taken in account
      properly by the EMC ICC set() callbacks.

    - ICC drivers use new icc_sync_state() and xlate_extended().

    - ICC drivers support new TEGRA_MC_ICC_TAG_ISO for ICC paths, which
      conveys to ICC driver that memory path uses isochronous transfers.

    - Added support for memory latency scaling to Tegra30 ICC provider.
      It's required for fixing display FIFO underflows on T30.

    - Added basic interconnect support to Tegra124 drivers.

    - Tegra20/30/124 EMC drivers now support voltage scaling using generic
      OPP API.

    - The display bandwidth management is reworked and improved. It now
      supports both bandwidth and latency allocations. The nv-display is
      now also taken into account properly, i.e. it's kept untouched.
      The extra bandwidth reservation required for ISO clients is moved
      from DC driver to the ICC drivers.

    - Dropped patch that tuned T20 display controller memory client because
      turned out that it kills ~30% of memory bandwidth. It should be possible
      to support client tuning, but it's too complicated for now.

    - Corrected display's cursor and winb-vfilter ICC clients.
      The winb-vfilter was erroneously used in place of cursor's client
      in device-trees.

    - Added devm_tegra_get_memory_controller() and switched drivers to
      use it.

    - Device-tree OPP tables are now supported by memory and devfreq
      drivers.

    - Tegra20-devfeq driver is reworked and now uses EMC-stats instead
      of IMC-stats (which are nearly identical modules) because previously
      I failed to understand how EMC-stats work and succeeded this time,
      thinking that it simply doesn't work. This removes a bit icky dependency
      on using both EMC and MC drivers simultaneously by the devfreq driver.

    - Tegra20-devfeq driver now is a sub-device of the EMC, it also now uses
      interconnect API for driving memory bandwidth.

    - Tegra30-devfreq got interconnect support.

    - Devfreq patches now use dev_err_probe(), which was suggested by
      Chanwoo Choi.

    - Added acks from Chanwoo Choi and Rob Herring to the reviewed and
      unchanged patches.

    - Added tested-by from Peter Geis and Nicolas Chauvet, who tested this
      series on Ouya and TK1 devices, reporting that it fixes display
      corruption on these devices which happened due to insufficient memory
      bandwidth.

    - Added patches to fix T20 EMC registers size.

    - Fixed missing LA entry for PTC in the Tegra MC drivers.

    - New and updated patches in v6:

        dt-bindings: memory: tegra20: emc: Correct registers range in example
        dt-bindings: memory: tegra20: emc: Document nvidia,memory-controller property
        dt-bindings: memory: tegra20: emc: Document OPP table and voltage regulator
        dt-bindings: memory: tegra20: emc: Document mfd-simple compatible and statistics sub-device
        dt-bindings: memory: tegra30: emc: Document OPP table and voltage regulator
        dt-bindings: memory: tegra124: mc: Document new interconnect property
        dt-bindings: memory: tegra124: emc: Document new interconnect property
        dt-bindings: memory: tegra124: emc: Document OPP table and voltage regulator
        dt-bindings: tegra30-actmon: Document OPP and interconnect properties
        dt-bindings: memory: tegra124: Add memory client IDs
        ARM: tegra: Correct EMC registers size in Tegra20 device-tree
        ARM: tegra: Add interconnect properties to Tegra124 device-tree
        ARM: tegra: Add nvidia,memory-controller phandle to Tegra20 EMC device-tree
        ARM: tegra: Add DVFS properties to Tegra20 EMC device-tree node
        ARM: tegra: Add DVFS properties to Tegra30 EMC and ACTMON device-tree nodes
        ARM: tegra: Add DVFS properties to Tegra124 EMC and ACTMON device-tree nodes
        memory: tegra: Add and use devm_tegra_get_memory_controller()
        memory: tegra-mc: Add interconnect framework
        memory: tegra20: Support interconnect framework
        memory: tegra20-emc: Skip parsing of emc-stats DT sub-node
        memory: tegra: Add missing latency allowness entry for Page Table Cache
        memory: tegra: Add FIFO sizes to Tegra30 memory clients
        memory: tegra30: Support interconnect framework
        memory: tegra124-emc: Make driver modular
        memory: tegra124: Support interconnect framework
        memory: tegra: Remove superfluous error messages around platform_get_irq()
        drm/tegra: dc: Support memory bandwidth management
        drm/tegra: dc: Extend debug stats with total number of events
        PM / devfreq: tegra20: Convert to EMC_STAT driver, support interconnect and device-tree
        PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
        PM / devfreq: tegra30: Separate configurations per-SoC generation
        opp: Put interconnect paths outside of opp_table_lock

v5: - The devfreq drivers now won't probe if memory timings aren't specified
      in a device-tree, like was suggested by Chanwoo Choi in a review comment
      to v4. Initially I wanted to always probe the driver even with a single
      fixed memory freq, but after a closer look turned out it can't be done
      easily for Tegra20 driver.

    - The "interconnect: Relax requirement in of_icc_get_from_provider()"
      patch was already applied, hence one less patch in comparison to v4.

    - Renamed display interconnect paths in accordance to the names that
      were used by Thierry Reding in one of his recent patches that supposed
      to update the Host1x's DT binding.

    - Added acks from Chanwoo Choi.

    - Added clarifying comment to tegra_mc_icc_set() about why it's a dummy
      function, this is done in a response to the review comment made by
      Georgi Djakov to v4.

v4: - All drivers that use interconnect API now select it in the Kconfig in
      order to properly express the build dependency.

    - The IS_ENABLED(CONFIG_INTERCONNECT) is dropped now from all patches.

    - Added MODULE_AUTHOR() to the modularized drivers, for completeness.

    - Added missed TEGRA_MC Kconfig dependency for the Tegra20 EMC driver.

    - Added more acks from Rob Herring that I accidentally missed to add in v3.

v3: - Added acks from Rob Herring that were given to some of the v2 patches.

    - Specified name of the TRM documentation chapter in the patch
      "dt-bindings: host1x: Document new interconnect properties", which was
      suggested by Rob Herring in the review comment to v2.

    - Added patches that allow EMC drivers to be compiled as a loadable kernel
      modules. This came up during of the v2 review when Georgi Djakov pointed
      out that interconnect-core could be compiled as a kernel module. Please
      note that the Tegra124 EMC driver is compile-tested only, I don't have
      Tegra124 HW.

    - In the review comment to [1] Stephen Boyd suggested that it will be
      better not to make changes to clk API, which was needed in order to
      avoid clashing of the interconnect driver with the devfreq in regards
      to memory clk-rate rounding.

      [1] https://patchwork.ozlabs.org/project/linux-tegra/patch/20200330231617.17079-3-digetx@gmail.com/

      Stephen Boyd suggested that instead we should provide OPP table via DT.
      I tried to investigate whether this could be done and turned out
      it's a bit complicated. Technically it should be doable, but:

        1. For now we don't fully support voltage scaling of the CORE regulator
           and so OPP table in the DT isn't really needed today. We can
           generate table from the memory timings, which is what Tegra devfreq
           drivers already do.

        2. The OPP table should be defined in the DT for the Memory Controller
           node and then its usage somehow should be shared by both interconnect
           and devfreq drivers. It's not obvious what's the best way to do it.

      So, it will be much better to postpone the DT OPP table addition
      until these questions are resolved. We can infer OPPs from the
      memory timings and we could get the memory rates from the memory
      driver directly, avoiding the problems induced by the clk API usage.
      This idea is implemented in v3, see these patches:

        PM / devfreq: tegra20: Use MC timings for building OPP table
        PM / devfreq: tegra30: Use MC timings for building OPP table

v2: - Instead of a single dma-mem interconnect path, the paths are now
      defined per memory client.

    - The EMC provider now uses #interconnect-cells=<0>.

    - Dropped Tegra124 because there is no enough information about how to
      properly calculate required EMC clock rate for it and I don't have
      hardware for testing. Somebody else will have to work on it.

    - Moved interconnect providers code into drivers/memory/tegra/*.

    - Added "Create tegra20-devfreq device" patch because interconnect
      is not very usable without the devfreq memory auto-scaling since
      memory freq will be fixed to the display's requirement.

Dmitry Osipenko (52):
  clk: tegra: Export Tegra20 EMC kernel symbols
  soc/tegra: fuse: Export tegra_read_ram_code()
  dt-bindings: memory: tegra20: emc: Correct registers range in example
  dt-bindings: memory: tegra20: emc: Document nvidia,memory-controller
    property
  dt-bindings: memory: tegra20: mc: Document new interconnect property
  dt-bindings: memory: tegra20: emc: Document new interconnect property
  dt-bindings: memory: tegra20: emc: Document OPP table and voltage
    regulator
  dt-bindings: memory: tegra20: emc: Document mfd-simple compatible and
    statistics sub-device
  dt-bindings: memory: tegra30: mc: Document new interconnect property
  dt-bindings: memory: tegra30: emc: Document new interconnect property
  dt-bindings: memory: tegra30: emc: Document OPP table and voltage
    regulator
  dt-bindings: memory: tegra124: mc: Document new interconnect property
  dt-bindings: memory: tegra124: emc: Document new interconnect property
  dt-bindings: memory: tegra124: emc: Document OPP table and voltage
    regulator
  dt-bindings: tegra30-actmon: Document OPP and interconnect properties
  dt-bindings: host1x: Document new interconnect properties
  dt-bindings: memory: tegra20: Add memory client IDs
  dt-bindings: memory: tegra30: Add memory client IDs
  dt-bindings: memory: tegra124: Add memory client IDs
  ARM: tegra: Correct EMC registers size in Tegra20 device-tree
  ARM: tegra: Add interconnect properties to Tegra20 device-tree
  ARM: tegra: Add interconnect properties to Tegra30 device-tree
  ARM: tegra: Add interconnect properties to Tegra124 device-tree
  ARM: tegra: Add nvidia,memory-controller phandle to Tegra20 EMC
    device-tree
  ARM: tegra: Add DVFS properties to Tegra20 EMC device-tree node
  ARM: tegra: Add DVFS properties to Tegra30 EMC and ACTMON device-tree
    nodes
  ARM: tegra: Add DVFS properties to Tegra124 EMC and ACTMON device-tree
    nodes
  memory: tegra: Add and use devm_tegra_get_memory_controller()
  memory: tegra-mc: Add interconnect framework
  memory: tegra20-emc: Make driver modular
  memory: tegra20-emc: Use devm_platform_ioremap_resource()
  memory: tegra20-emc: Continue probing if timings are missing in
    device-tree
  memory: tegra20: Support interconnect framework
  memory: tegra20-emc: Don't parse emc-stats node
  memory: tegra: Add missing latency allowness entry for Page Table
    Cache
  memory: tegra: Add FIFO sizes to Tegra30 memory clients
  memory: tegra30-emc: Make driver modular
  memory: tegra30-emc: Continue probing if timings are missing in
    device-tree
  memory: tegra30: Support interconnect framework
  memory: tegra124-emc: Make driver modular
  memory: tegra124-emc: Use devm_platform_ioremap_resource()
  memory: tegra124: Support interconnect framework
  memory: tegra: Remove superfluous error messages around
    platform_get_irq()
  drm/tegra: dc: Support memory bandwidth management
  drm/tegra: dc: Extend debug stats with total number of events
  opp: Put interconnect paths outside of opp_table_lock
  PM / devfreq: tegra20: Silence deferred probe error
  PM / devfreq: tegra20: Relax Kconfig dependency
  PM / devfreq: tegra20: Convert to EMC_STAT driver, support
    interconnect and device-tree
  PM / devfreq: tegra30: Silence deferred probe error
  PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
  PM / devfreq: tegra30: Separate configurations per-SoC generation

 .../arm/tegra/nvidia,tegra30-actmon.txt       |  25 ++
 .../display/tegra/nvidia,tegra20-host1x.txt   |  68 +++
 .../nvidia,tegra124-emc.yaml                  |  18 +
 .../nvidia,tegra124-mc.yaml                   |   5 +
 .../memory-controllers/nvidia,tegra20-emc.txt |  63 ++-
 .../memory-controllers/nvidia,tegra20-mc.txt  |   3 +
 .../nvidia,tegra30-emc.yaml                   |  18 +
 .../memory-controllers/nvidia,tegra30-mc.yaml |   5 +
 arch/arm/boot/dts/tegra124-apalis-emc.dtsi    |   8 +
 .../arm/boot/dts/tegra124-jetson-tk1-emc.dtsi |   8 +
 arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi  |  10 +
 .../boot/dts/tegra124-peripherals-opp.dtsi    | 419 ++++++++++++++++++
 arch/arm/boot/dts/tegra124.dtsi               |  31 ++
 .../boot/dts/tegra20-acer-a500-picasso.dts    |  12 +
 arch/arm/boot/dts/tegra20-colibri.dtsi        |   8 +
 arch/arm/boot/dts/tegra20-paz00.dts           |  10 +
 .../arm/boot/dts/tegra20-peripherals-opp.dtsi | 181 ++++++++
 arch/arm/boot/dts/tegra20.dtsi                |  42 +-
 .../tegra30-asus-nexus7-grouper-common.dtsi   |  16 +
 .../arm/boot/dts/tegra30-peripherals-opp.dtsi | 383 ++++++++++++++++
 arch/arm/boot/dts/tegra30.dtsi                |  33 +-
 drivers/clk/tegra/Makefile                    |   2 +-
 drivers/clk/tegra/clk-tegra124-emc.c          |  41 +-
 drivers/clk/tegra/clk-tegra124.c              |  27 +-
 drivers/clk/tegra/clk-tegra20-emc.c           |   3 +
 drivers/clk/tegra/clk.h                       |  16 +-
 drivers/devfreq/Kconfig                       |   3 +-
 drivers/devfreq/tegra20-devfreq.c             | 186 ++++----
 drivers/devfreq/tegra30-devfreq.c             | 166 ++++---
 drivers/gpu/drm/tegra/Kconfig                 |   1 +
 drivers/gpu/drm/tegra/dc.c                    | 340 ++++++++++++++
 drivers/gpu/drm/tegra/dc.h                    |  11 +
 drivers/gpu/drm/tegra/drm.c                   |  14 +
 drivers/gpu/drm/tegra/hub.c                   |   3 +
 drivers/gpu/drm/tegra/plane.c                 | 122 +++++
 drivers/gpu/drm/tegra/plane.h                 |  15 +
 drivers/memory/tegra/Kconfig                  |  12 +-
 drivers/memory/tegra/mc.c                     | 184 +++++++-
 drivers/memory/tegra/mc.h                     |  20 +
 drivers/memory/tegra/tegra114.c               |   6 +
 drivers/memory/tegra/tegra124-emc.c           | 235 ++++++++--
 drivers/memory/tegra/tegra124.c               |  37 ++
 drivers/memory/tegra/tegra20-emc.c            | 244 ++++++++--
 drivers/memory/tegra/tegra20.c                |  34 ++
 drivers/memory/tegra/tegra210-emc-core.c      |  39 +-
 drivers/memory/tegra/tegra30-emc.c            | 245 ++++++++--
 drivers/memory/tegra/tegra30.c                | 191 ++++++++
 drivers/opp/core.c                            |  21 +-
 drivers/soc/tegra/fuse/tegra-apbmisc.c        |   2 +
 include/dt-bindings/memory/tegra124-mc.h      |  68 +++
 include/dt-bindings/memory/tegra20-mc.h       |  53 +++
 include/dt-bindings/memory/tegra30-mc.h       |  67 +++
 include/linux/clk/tegra.h                     |   9 +
 include/soc/tegra/emc.h                       |  16 -
 include/soc/tegra/mc.h                        |  26 ++
 55 files changed, 3477 insertions(+), 348 deletions(-)
 create mode 100644 arch/arm/boot/dts/tegra124-peripherals-opp.dtsi
 create mode 100644 arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
 create mode 100644 arch/arm/boot/dts/tegra30-peripherals-opp.dtsi
 delete mode 100644 include/soc/tegra/emc.h

Comments

Krzysztof Kozlowski Oct. 26, 2020, 3:08 p.m. UTC | #1
On Mon, Oct 26, 2020 at 01:16:43AM +0300, Dmitry Osipenko wrote:
> Hello,
> 
> This series brings initial support for memory interconnect to Tegra20,
> Tegra30 and Tegra124 SoCs.
> 
> For the starter only display controllers and devfreq devices are getting
> interconnect API support, others could be supported later on. The display
> controllers have the biggest demand for interconnect API right now because
> dynamic memory frequency scaling can't be done safely without taking into
> account bandwidth requirement from the displays. In particular this series
> fixes distorted display output on T30 Ouya and T124 TK1 devices.

Hi,

You introduced in v6 multiple new patches. Could you describe the
dependencies, if any?

Best regards,
Krzysztof

> Changelog:
> 
> v6: - This series was massively reworked in comparison to v5, most of the
>       patches that previously got r-b need a new round of a review (!).
> 
>     - Added missed clk-rounding to the set() callback of EMC ICC providers.
>       Now clk_set_min_rate() doesn't error out on rate overflow.
> 
>     - Now peak bandwidth is properly taken into account by the set() callback
>       of EMC ICC providers.
> 
>     - EMC runs at 2x of the DRAM bus only on Tegra20, this now taken in account
>       properly by the EMC ICC set() callbacks.
> 
>     - ICC drivers use new icc_sync_state() and xlate_extended().
> 
>     - ICC drivers support new TEGRA_MC_ICC_TAG_ISO for ICC paths, which
>       conveys to ICC driver that memory path uses isochronous transfers.
> 
>     - Added support for memory latency scaling to Tegra30 ICC provider.
>       It's required for fixing display FIFO underflows on T30.
> 
>     - Added basic interconnect support to Tegra124 drivers.
> 
>     - Tegra20/30/124 EMC drivers now support voltage scaling using generic
>       OPP API.
> 
>     - The display bandwidth management is reworked and improved. It now
>       supports both bandwidth and latency allocations. The nv-display is
>       now also taken into account properly, i.e. it's kept untouched.
>       The extra bandwidth reservation required for ISO clients is moved
>       from DC driver to the ICC drivers.
> 
>     - Dropped patch that tuned T20 display controller memory client because
>       turned out that it kills ~30% of memory bandwidth. It should be possible
>       to support client tuning, but it's too complicated for now.
> 
>     - Corrected display's cursor and winb-vfilter ICC clients.
>       The winb-vfilter was erroneously used in place of cursor's client
>       in device-trees.
> 
>     - Added devm_tegra_get_memory_controller() and switched drivers to
>       use it.
> 
>     - Device-tree OPP tables are now supported by memory and devfreq
>       drivers.
> 
>     - Tegra20-devfeq driver is reworked and now uses EMC-stats instead
>       of IMC-stats (which are nearly identical modules) because previously
>       I failed to understand how EMC-stats work and succeeded this time,
>       thinking that it simply doesn't work. This removes a bit icky dependency
>       on using both EMC and MC drivers simultaneously by the devfreq driver.
> 
>     - Tegra20-devfeq driver now is a sub-device of the EMC, it also now uses
>       interconnect API for driving memory bandwidth.
> 
>     - Tegra30-devfreq got interconnect support.
> 
>     - Devfreq patches now use dev_err_probe(), which was suggested by
>       Chanwoo Choi.
> 
>     - Added acks from Chanwoo Choi and Rob Herring to the reviewed and
>       unchanged patches.
> 
>     - Added tested-by from Peter Geis and Nicolas Chauvet, who tested this
>       series on Ouya and TK1 devices, reporting that it fixes display
>       corruption on these devices which happened due to insufficient memory
>       bandwidth.
> 
>     - Added patches to fix T20 EMC registers size.
> 
>     - Fixed missing LA entry for PTC in the Tegra MC drivers.
> 
>     - New and updated patches in v6:
> 
>         dt-bindings: memory: tegra20: emc: Correct registers range in example
>         dt-bindings: memory: tegra20: emc: Document nvidia,memory-controller property
>         dt-bindings: memory: tegra20: emc: Document OPP table and voltage regulator
>         dt-bindings: memory: tegra20: emc: Document mfd-simple compatible and statistics sub-device
>         dt-bindings: memory: tegra30: emc: Document OPP table and voltage regulator
>         dt-bindings: memory: tegra124: mc: Document new interconnect property
>         dt-bindings: memory: tegra124: emc: Document new interconnect property
>         dt-bindings: memory: tegra124: emc: Document OPP table and voltage regulator
>         dt-bindings: tegra30-actmon: Document OPP and interconnect properties
>         dt-bindings: memory: tegra124: Add memory client IDs
>         ARM: tegra: Correct EMC registers size in Tegra20 device-tree
>         ARM: tegra: Add interconnect properties to Tegra124 device-tree
>         ARM: tegra: Add nvidia,memory-controller phandle to Tegra20 EMC device-tree
>         ARM: tegra: Add DVFS properties to Tegra20 EMC device-tree node
>         ARM: tegra: Add DVFS properties to Tegra30 EMC and ACTMON device-tree nodes
>         ARM: tegra: Add DVFS properties to Tegra124 EMC and ACTMON device-tree nodes
>         memory: tegra: Add and use devm_tegra_get_memory_controller()
>         memory: tegra-mc: Add interconnect framework
>         memory: tegra20: Support interconnect framework
>         memory: tegra20-emc: Skip parsing of emc-stats DT sub-node
>         memory: tegra: Add missing latency allowness entry for Page Table Cache
>         memory: tegra: Add FIFO sizes to Tegra30 memory clients
>         memory: tegra30: Support interconnect framework
>         memory: tegra124-emc: Make driver modular
>         memory: tegra124: Support interconnect framework
>         memory: tegra: Remove superfluous error messages around platform_get_irq()
>         drm/tegra: dc: Support memory bandwidth management
>         drm/tegra: dc: Extend debug stats with total number of events
>         PM / devfreq: tegra20: Convert to EMC_STAT driver, support interconnect and device-tree
>         PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
>         PM / devfreq: tegra30: Separate configurations per-SoC generation
>         opp: Put interconnect paths outside of opp_table_lock
Dmitry Osipenko Oct. 26, 2020, 7:14 p.m. UTC | #2
26.10.2020 18:08, Krzysztof Kozlowski пишет:
> On Mon, Oct 26, 2020 at 01:16:43AM +0300, Dmitry Osipenko wrote:
>> Hello,
>>
>> This series brings initial support for memory interconnect to Tegra20,
>> Tegra30 and Tegra124 SoCs.
>>
>> For the starter only display controllers and devfreq devices are getting
>> interconnect API support, others could be supported later on. The display
>> controllers have the biggest demand for interconnect API right now because
>> dynamic memory frequency scaling can't be done safely without taking into
>> account bandwidth requirement from the displays. In particular this series
>> fixes distorted display output on T30 Ouya and T124 TK1 devices.
> 
> Hi,
> 
> You introduced in v6 multiple new patches. Could you describe the
> dependencies, if any?

Hello,

The v6 dropped some older patches and replaced them with the new
patches. Previously I wanted to postpone the more complex changes for
later times, like supporting OPP tables and DVFS, but then the review
started to take more time than was expected and there was enough time to
complete those features.

There are five basic sets of patches:

	1. DT bindings
	2. DT changes
	3. SoC, clk and memory
	4. devfreq
	5. DRM

Each set could be applied separately.

Memory patches have a build dependency on the SoC and clk patches.

The "tegra-mc: Add interconnect framework" and "Add and use
devm_tegra_get_memory_controller()" are the root build dependencies for
all memory/ patches. Other patches are grouped per SoC generation
(Tegra20/30/124), patches within a SoC-gen group are interdependent.

I suppose the best variant would be to merge the whole series via
tegra-tree in order to preserve logical order of the patches. Although,
merging each set of patches separately also should be okay to do.
Krzysztof Kozlowski Oct. 27, 2020, 8:52 a.m. UTC | #3
On Mon, Oct 26, 2020 at 10:14:10PM +0300, Dmitry Osipenko wrote:
> 26.10.2020 18:08, Krzysztof Kozlowski пишет:
> > On Mon, Oct 26, 2020 at 01:16:43AM +0300, Dmitry Osipenko wrote:
> >> Hello,
> >>
> >> This series brings initial support for memory interconnect to Tegra20,
> >> Tegra30 and Tegra124 SoCs.
> >>
> >> For the starter only display controllers and devfreq devices are getting
> >> interconnect API support, others could be supported later on. The display
> >> controllers have the biggest demand for interconnect API right now because
> >> dynamic memory frequency scaling can't be done safely without taking into
> >> account bandwidth requirement from the displays. In particular this series
> >> fixes distorted display output on T30 Ouya and T124 TK1 devices.
> > 
> > Hi,
> > 
> > You introduced in v6 multiple new patches. Could you describe the
> > dependencies, if any?
> 
> Hello,
> 
> The v6 dropped some older patches and replaced them with the new
> patches. Previously I wanted to postpone the more complex changes for
> later times, like supporting OPP tables and DVFS, but then the review
> started to take more time than was expected and there was enough time to
> complete those features.
> 
> There are five basic sets of patches:
> 
> 	1. DT bindings
> 	2. DT changes
> 	3. SoC, clk and memory
> 	4. devfreq
> 	5. DRM
> 
> Each set could be applied separately.
> 
> Memory patches have a build dependency on the SoC and clk patches.
> 
> The "tegra-mc: Add interconnect framework" and "Add and use
> devm_tegra_get_memory_controller()" are the root build dependencies for
> all memory/ patches. Other patches are grouped per SoC generation
> (Tegra20/30/124), patches within a SoC-gen group are interdependent.
> 
> I suppose the best variant would be to merge the whole series via
> tegra-tree in order to preserve logical order of the patches. Although,
> merging each set of patches separately also should be okay to do.

Thanks for explanation. I already have three patches for Tegra MC (and
probably two more will be respun) so this might be conflict-prone. The
easiest in such case is to provide me soc and clk patches on the branch,
so I could keep all Tegra MC together.

Best regards,
Krzysztof
Dmitry Osipenko Oct. 27, 2020, 8:31 p.m. UTC | #4
27.10.2020 11:52, Krzysztof Kozlowski пишет:
> On Mon, Oct 26, 2020 at 10:14:10PM +0300, Dmitry Osipenko wrote:
>> 26.10.2020 18:08, Krzysztof Kozlowski пишет:
>>> On Mon, Oct 26, 2020 at 01:16:43AM +0300, Dmitry Osipenko wrote:
>>>> Hello,
>>>>
>>>> This series brings initial support for memory interconnect to Tegra20,
>>>> Tegra30 and Tegra124 SoCs.
>>>>
>>>> For the starter only display controllers and devfreq devices are getting
>>>> interconnect API support, others could be supported later on. The display
>>>> controllers have the biggest demand for interconnect API right now because
>>>> dynamic memory frequency scaling can't be done safely without taking into
>>>> account bandwidth requirement from the displays. In particular this series
>>>> fixes distorted display output on T30 Ouya and T124 TK1 devices.
>>>
>>> Hi,
>>>
>>> You introduced in v6 multiple new patches. Could you describe the
>>> dependencies, if any?
>>
>> Hello,
>>
>> The v6 dropped some older patches and replaced them with the new
>> patches. Previously I wanted to postpone the more complex changes for
>> later times, like supporting OPP tables and DVFS, but then the review
>> started to take more time than was expected and there was enough time to
>> complete those features.
>>
>> There are five basic sets of patches:
>>
>> 	1. DT bindings
>> 	2. DT changes
>> 	3. SoC, clk and memory
>> 	4. devfreq
>> 	5. DRM
>>
>> Each set could be applied separately.
>>
>> Memory patches have a build dependency on the SoC and clk patches.
>>
>> The "tegra-mc: Add interconnect framework" and "Add and use
>> devm_tegra_get_memory_controller()" are the root build dependencies for
>> all memory/ patches. Other patches are grouped per SoC generation
>> (Tegra20/30/124), patches within a SoC-gen group are interdependent.
>>
>> I suppose the best variant would be to merge the whole series via
>> tegra-tree in order to preserve logical order of the patches. Although,
>> merging each set of patches separately also should be okay to do.
> 
> Thanks for explanation. I already have three patches for Tegra MC (and
> probably two more will be respun) so this might be conflict-prone. The
> easiest in such case is to provide me soc and clk patches on the branch,
> so I could keep all Tegra MC together.

Okay, but those T210 patches don't touch the same code, neither same
source files. For now there should be no merge conflicts.