Message ID | 20201123002723.28463-1-digetx@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Introduce memory interconnect for NVIDIA Tegra SoCs | expand |
On 23-11-20, 03:27, Dmitry Osipenko wrote: > 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: > > v10 - In a longer run it will be much nicer if we could support EMC > hardware versioning on Tegra20 and it's not late to support it now. > Hence I added these new patches: > > dt-bindings: memory: tegra20: emc: Document opp-supported-hw property > memory: tegra20: Support hardware versioning and clean up OPP table initialization > > - Removed error message from tegra30-devfreq driver about missing OPP > properties in a device-tree because EMC driver already prints that > message and it uses OPP API error code instead of checking DT directly, > which is a more correct way of doing that. Looks good to me (from OPP APIs usage perspective). Thanks for continuing with this and fixing all the issues Dmitry.
23.11.2020 09:17, Viresh Kumar пишет: > On 23-11-20, 03:27, Dmitry Osipenko wrote: >> 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: >> >> v10 - In a longer run it will be much nicer if we could support EMC >> hardware versioning on Tegra20 and it's not late to support it now. >> Hence I added these new patches: >> >> dt-bindings: memory: tegra20: emc: Document opp-supported-hw property >> memory: tegra20: Support hardware versioning and clean up OPP table initialization >> >> - Removed error message from tegra30-devfreq driver about missing OPP >> properties in a device-tree because EMC driver already prints that >> message and it uses OPP API error code instead of checking DT directly, >> which is a more correct way of doing that. > > Looks good to me (from OPP APIs usage perspective). Thanks for > continuing with this and fixing all the issues Dmitry. > Hello Viresh, Thank you for all the clarifications and for reviewing of the patches!
On Mon, Nov 30, 2020 at 05:44:39PM +0900, Chanwoo Choi wrote: > Hi Dmitry, > > The v5.10-rc6 was released from linus git tree. > Generally, I will send the pull-quest about devfreq to linux-pm.git maintainer > after releasing the v5.1-rc7 for the integration test on linux-pm.git. > > The icc patches in this patch have not yet merged. If these patches > are not merged before v5.10-rc7, Maybe, I'll apply the devfreq patches > for v5.12-rc1. None of the patches here are going to be merged to Linus' in the current cycle. They will only go to the next so if there is dependency, everything will be broken and non-bisectable. However no such dependencies or merging requirements were mention in the cover letter. Best regards, Krzysztof
Hi Dmitry, The v5.10-rc6 was released from linus git tree. Generally, I will send the pull-quest about devfreq to linux-pm.git maintainer after releasing the v5.1-rc7 for the integration test on linux-pm.git. The icc patches in this patch have not yet merged. If these patches are not merged before v5.10-rc7, Maybe, I'll apply the devfreq patches for v5.12-rc1. Best Regards, Chanwoo Choi On 11/23/20 9:27 AM, Dmitry Osipenko wrote: > 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: > > v10 - In a longer run it will be much nicer if we could support EMC > hardware versioning on Tegra20 and it's not late to support it now. > Hence I added these new patches: > > dt-bindings: memory: tegra20: emc: Document opp-supported-hw property > memory: tegra20: Support hardware versioning and clean up OPP table initialization > > - Removed error message from tegra30-devfreq driver about missing OPP > properties in a device-tree because EMC driver already prints that > message and it uses OPP API error code instead of checking DT directly, > which is a more correct way of doing that. > > v9: - Squashed "memory: tegra30-emc: Factor out clk initialization" into > patch "tegra30: Support interconnect framework". > Suggested by Krzysztof Kozlowski. > > - Improved Kconfig in the patch "memory: tegra124-emc: Make driver modular" > by adding CONFIG_TEGRA124_CLK_EMC entry, which makes clk-driver changes > to look a bit more cleaner. Suggested by Krzysztof Kozlowski. > > - Dropped voltage regulator support from ICC and DT patches for now > because there is a new discussion about using a power domain abstraction > for controlling the regulator, which is likely to happen. > > - Replaced direct "operating-points-v2" property checking in EMC drivers > with checking of a returned error code from dev_pm_opp_of_add_table(). > Note that I haven't touched T20 EMC driver because it's very likely > that we'll replace that code with a common helper soon anyways. > Suggested by Viresh Kumar. > > - The T30 DT patches now include EMC OPP changes for Ouya board, which > is available now in linux-next. > > Dmitry Osipenko (19): > dt-bindings: memory: tegra20: emc: Document opp-supported-hw property > memory: tegra20: Support hardware versioning and clean up OPP table > initialization > memory: tegra30: Support interconnect framework > memory: tegra124-emc: Make driver modular > memory: tegra124-emc: Continue probing if timings are missing in > device-tree > memory: tegra124: Support interconnect framework > drm/tegra: dc: Support memory bandwidth management > drm/tegra: dc: Extend debug stats with total number of events > PM / devfreq: tegra30: Support interconnect and OPPs from device-tree > PM / devfreq: tegra30: Separate configurations per-SoC generation > PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver > 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 EMC OPP properties to Tegra20 device-trees > ARM: tegra: Add EMC OPP and ICC properties to Tegra30 EMC and ACTMON > device-tree nodes > ARM: tegra: Add EMC OPP and ICC properties to Tegra124 EMC and ACTMON > device-tree nodes > > .../memory-controllers/nvidia,tegra20-emc.txt | 6 + > MAINTAINERS | 1 - > 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 + > .../arm/boot/dts/tegra124-nyan-blaze-emc.dtsi | 10 + > .../boot/dts/tegra124-peripherals-opp.dtsi | 419 ++++++++++++++++++ > arch/arm/boot/dts/tegra124.dtsi | 31 ++ > .../boot/dts/tegra20-acer-a500-picasso.dts | 5 + > arch/arm/boot/dts/tegra20-colibri.dtsi | 4 + > arch/arm/boot/dts/tegra20-paz00.dts | 4 + > .../arm/boot/dts/tegra20-peripherals-opp.dtsi | 109 +++++ > arch/arm/boot/dts/tegra20.dtsi | 33 +- > ...30-asus-nexus7-grouper-memory-timings.dtsi | 12 + > arch/arm/boot/dts/tegra30-ouya.dts | 8 + > .../arm/boot/dts/tegra30-peripherals-opp.dtsi | 383 ++++++++++++++++ > arch/arm/boot/dts/tegra30.dtsi | 33 +- > drivers/clk/tegra/Kconfig | 3 + > drivers/clk/tegra/Makefile | 2 +- > drivers/clk/tegra/clk-tegra124-emc.c | 41 +- > drivers/clk/tegra/clk-tegra124.c | 26 +- > drivers/clk/tegra/clk.h | 18 +- > drivers/devfreq/Kconfig | 10 - > drivers/devfreq/Makefile | 1 - > drivers/devfreq/tegra20-devfreq.c | 210 --------- > drivers/devfreq/tegra30-devfreq.c | 147 +++--- > drivers/gpu/drm/tegra/Kconfig | 1 + > drivers/gpu/drm/tegra/dc.c | 359 +++++++++++++++ > drivers/gpu/drm/tegra/dc.h | 19 + > drivers/gpu/drm/tegra/drm.c | 14 + > drivers/gpu/drm/tegra/hub.c | 3 + > drivers/gpu/drm/tegra/plane.c | 121 +++++ > drivers/gpu/drm/tegra/plane.h | 15 + > drivers/memory/tegra/Kconfig | 5 +- > drivers/memory/tegra/tegra124-emc.c | 377 ++++++++++++++-- > drivers/memory/tegra/tegra124.c | 82 +++- > drivers/memory/tegra/tegra20-emc.c | 48 +- > drivers/memory/tegra/tegra30-emc.c | 344 +++++++++++++- > drivers/memory/tegra/tegra30.c | 173 +++++++- > include/linux/clk/tegra.h | 8 + > include/soc/tegra/emc.h | 16 - > 41 files changed, 2725 insertions(+), 402 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 drivers/devfreq/tegra20-devfreq.c > delete mode 100644 include/soc/tegra/emc.h >
On 11/30/20 5:36 PM, Krzysztof Kozlowski wrote: > On Mon, Nov 30, 2020 at 05:44:39PM +0900, Chanwoo Choi wrote: >> Hi Dmitry, >> >> The v5.10-rc6 was released from linus git tree. >> Generally, I will send the pull-quest about devfreq to linux-pm.git maintainer >> after releasing the v5.1-rc7 for the integration test on linux-pm.git. >> >> The icc patches in this patch have not yet merged. If these patches >> are not merged before v5.10-rc7, Maybe, I'll apply the devfreq patches >> for v5.12-rc1. > > None of the patches here are going to be merged to Linus' in the current > cycle. They will only go to the next so if there is dependency, > everything will be broken and non-bisectable. > > However no such dependencies or merging requirements were mention in the > cover letter. Thanks for reply. The devfreq patch depends on the icc changes. I'll apply the devfreq patches on next time (v5.12-rc1). Thanks.