| Message ID | 20201104164923.21238-1-digetx@gmail.com |
|---|---|
| Headers | show |
| Series | Introduce memory interconnect for NVIDIA Tegra SoCs | expand |
Hi Dmitry, On 11/5/20 1:49 AM, Dmitry Osipenko wrote: > This patch moves ACTMON driver away from generating OPP table by itself, > transitioning it to use the table which comes from device-tree. This > change breaks compatibility with older device-trees in order to bring > support for the interconnect framework to the driver. This is a mandatory > change which needs to be done in order to implement interconnect-based > memory DVFS. Users of legacy device-trees will get a message telling that > theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request > using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly. > > Tested-by: Peter Geis <pgwipeout@gmail.com> > Tested-by: Nicolas Chauvet <kwizart@gmail.com> > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > drivers/devfreq/tegra30-devfreq.c | 96 +++++++++++++++++-------------- > 1 file changed, 54 insertions(+), 42 deletions(-) > > diff --git a/drivers/devfreq/tegra30-devfreq.c b/drivers/devfreq/tegra30-devfreq.c > index 38cc0d014738..4db027ca17e1 100644 > --- a/drivers/devfreq/tegra30-devfreq.c > +++ b/drivers/devfreq/tegra30-devfreq.c > @@ -19,6 +19,8 @@ > #include <linux/reset.h> > #include <linux/workqueue.h> > > +#include <soc/tegra/fuse.h> > + > #include "governor.h" > > #define ACTMON_GLB_STATUS 0x0 > @@ -155,6 +157,7 @@ struct tegra_devfreq_device { > > struct tegra_devfreq { > struct devfreq *devfreq; > + struct opp_table *opp_table; > > struct reset_control *reset; > struct clk *clock; > @@ -612,34 +615,19 @@ static void tegra_actmon_stop(struct tegra_devfreq *tegra) > static int tegra_devfreq_target(struct device *dev, unsigned long *freq, > u32 flags) > { > - struct tegra_devfreq *tegra = dev_get_drvdata(dev); > - struct devfreq *devfreq = tegra->devfreq; > struct dev_pm_opp *opp; > - unsigned long rate; > - int err; > + int ret; > > opp = devfreq_recommended_opp(dev, freq, flags); > if (IS_ERR(opp)) { > dev_err(dev, "Failed to find opp for %lu Hz\n", *freq); > return PTR_ERR(opp); > } > - rate = dev_pm_opp_get_freq(opp); > - dev_pm_opp_put(opp); > - > - err = clk_set_min_rate(tegra->emc_clock, rate * KHZ); > - if (err) > - return err; > - > - err = clk_set_rate(tegra->emc_clock, 0); > - if (err) > - goto restore_min_rate; > - > - return 0; > > -restore_min_rate: > - clk_set_min_rate(tegra->emc_clock, devfreq->previous_freq); > + ret = dev_pm_opp_set_bw(dev, opp); > + dev_pm_opp_put(opp); > > - return err; > + return ret; > } > > static int tegra_devfreq_get_dev_status(struct device *dev, > @@ -655,7 +643,7 @@ static int tegra_devfreq_get_dev_status(struct device *dev, > stat->private_data = tegra; > > /* The below are to be used by the other governors */ > - stat->current_frequency = cur_freq; > + stat->current_frequency = cur_freq * KHZ; > > actmon_dev = &tegra->devices[MCALL]; > > @@ -705,7 +693,12 @@ static int tegra_governor_get_target(struct devfreq *devfreq, > target_freq = max(target_freq, dev->target_freq); > } > > - *freq = target_freq; > + /* > + * tegra-devfreq driver operates with KHz units, while OPP table > + * entries use Hz units. Hence we need to convert the units for the > + * devfreq core. > + */ > + *freq = target_freq * KHZ; > > return 0; > } > @@ -774,13 +767,22 @@ static struct devfreq_governor tegra_devfreq_governor = { > > static int tegra_devfreq_probe(struct platform_device *pdev) > { > + u32 hw_version = BIT(tegra_sku_info.soc_speedo_id); > struct tegra_devfreq_device *dev; > struct tegra_devfreq *tegra; > + struct opp_table *opp_table; > struct devfreq *devfreq; > unsigned int i; > long rate; > int err; > > + /* legacy device-trees don't have OPP table and must be updated */ > + if (!device_property_present(&pdev->dev, "operating-points-v2")) { > + dev_err(&pdev->dev, > + "OPP table not found, please update your device tree\n"); > + return -ENODEV; > + } > + > tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL); > if (!tegra) > return -ENOMEM; > @@ -822,11 +824,31 @@ static int tegra_devfreq_probe(struct platform_device *pdev) > return err; > } > > + tegra->opp_table = dev_pm_opp_get_opp_table(&pdev->dev); > + err = PTR_ERR_OR_ZERO(tegra->opp_table); > + if (err) { > + dev_err(&pdev->dev, "Failed to prepare OPP table: %d\n", err); > + return err; > + } > + > + opp_table = dev_pm_opp_set_supported_hw(&pdev->dev, &hw_version, 1); > + err = PTR_ERR_OR_ZERO(opp_table); > + if (err) { > + dev_err(&pdev->dev, "Failed to set supported HW: %d\n", err); > + goto put_table; > + } > + > + err = dev_pm_opp_of_add_table(&pdev->dev); > + if (err) { > + dev_err(&pdev->dev, "Failed to add OPP table: %d\n", err); > + goto put_hw; > + } > + > err = clk_prepare_enable(tegra->clock); > if (err) { > dev_err(&pdev->dev, > "Failed to prepare and enable ACTMON clock\n"); > - return err; > + goto remove_table; > } > > err = reset_control_reset(tegra->reset); > @@ -850,23 +872,6 @@ static int tegra_devfreq_probe(struct platform_device *pdev) > dev->regs = tegra->regs + dev->config->offset; > } > > - for (rate = 0; rate <= tegra->max_freq * KHZ; rate++) { > - rate = clk_round_rate(tegra->emc_clock, rate); > - > - if (rate < 0) { > - dev_err(&pdev->dev, > - "Failed to round clock rate: %ld\n", rate); > - err = rate; > - goto remove_opps; > - } > - > - err = dev_pm_opp_add(&pdev->dev, rate / KHZ, 0); > - if (err) { > - dev_err(&pdev->dev, "Failed to add OPP: %d\n", err); > - goto remove_opps; > - } > - } > - > platform_set_drvdata(pdev, tegra); > > tegra->clk_rate_change_nb.notifier_call = tegra_actmon_clk_notify_cb; > @@ -882,7 +887,6 @@ static int tegra_devfreq_probe(struct platform_device *pdev) > } > > tegra_devfreq_profile.initial_freq = clk_get_rate(tegra->emc_clock); > - tegra_devfreq_profile.initial_freq /= KHZ; > > devfreq = devfreq_add_device(&pdev->dev, &tegra_devfreq_profile, > "tegra_actmon", NULL); > @@ -902,6 +906,12 @@ static int tegra_devfreq_probe(struct platform_device *pdev) > reset_control_reset(tegra->reset); > disable_clk: > clk_disable_unprepare(tegra->clock); > +remove_table: > + dev_pm_opp_of_remove_table(&pdev->dev); > +put_hw: > + dev_pm_opp_put_supported_hw(tegra->opp_table); > +put_table: > + dev_pm_opp_put_opp_table(tegra->opp_table); > > return err; > } > @@ -913,11 +923,13 @@ static int tegra_devfreq_remove(struct platform_device *pdev) > devfreq_remove_device(tegra->devfreq); > devfreq_remove_governor(&tegra_devfreq_governor); > > - dev_pm_opp_remove_all_dynamic(&pdev->dev); > - > reset_control_reset(tegra->reset); > clk_disable_unprepare(tegra->clock); > > + dev_pm_opp_of_remove_table(&pdev->dev); > + dev_pm_opp_put_supported_hw(tegra->opp_table); > + dev_pm_opp_put_opp_table(tegra->opp_table); > + > return 0; > } > > Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
On Wed, Nov 04, 2020 at 07:48:39PM +0300, Dmitry Osipenko wrote: > Drivers that use tegra_sku_info and have COMPILE_TEST are failing to be > build due to the missing stub for tegra_sku_info, thus add the missing > stub. > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > include/soc/tegra/fuse.h | 4 ++++ Thanks, applied. Best regards, Krzysztof
On Wed, Nov 04, 2020 at 07:48:40PM +0300, Dmitry Osipenko wrote: > There is superfluous zero in the registers base address and registers > size should be twice bigger. > > Acked-by: Rob Herring <robh@kernel.org> > Acked-by: Thierry Reding <treding@nvidia.com> > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > .../bindings/memory-controllers/nvidia,tegra20-emc.txt | 2 +- Thanks, applied. Best regards, Krzysztof
On Wed, Nov 04, 2020 at 07:48:41PM +0300, Dmitry Osipenko wrote: > Tegra20 External Memory Controller talks to DRAM chips and it needs to be > reprogrammed when memory frequency changes. Tegra Memory Controller sits > behind EMC and these controllers are tightly coupled. This patch adds the > new phandle property which allows to properly express connection of EMC > and MC hardware in a device-tree, it also put the Tegra20 EMC binding on > par with Tegra30+ EMC bindings, which is handy to have. > > Acked-by: Rob Herring <robh@kernel.org> > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > .../bindings/memory-controllers/nvidia,tegra20-emc.txt | 2 ++ Thanks, applied. Best regards, Krzysztof
On Wed, Nov 04, 2020 at 07:48:43PM +0300, Dmitry Osipenko wrote: > External Memory Controller is interconnected with memory controller and > with external memory. Document new interconnect property which turns EMC > into interconnect provider. > > Acked-by: Rob Herring <robh@kernel.org> > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > .../bindings/memory-controllers/nvidia,tegra20-emc.txt | 2 ++ Thanks, applied. Best regards, Krzysztof
On Wed, Nov 04, 2020 at 07:48:47PM +0300, Dmitry Osipenko wrote: > Document new OPP table and voltage regulator properties which are needed > for supporting dynamic voltage-frequency scaling of the memory controller. > Some boards may have a fixed core voltage regulator, hence it's optional > because frequency scaling still may be desired. > > Reviewed-by: Rob Herring <robh@kernel.org> > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > .../memory-controllers/nvidia,tegra30-emc.yaml | 12 ++++++++++++ > 1 file changed, 12 insertions(+) Thanks, applied. Best regards, Krzysztof
On Wed, Nov 04, 2020 at 07:48:49PM +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. > > Reviewed-by: Rob Herring <robh@kernel.org> > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > .../bindings/memory-controllers/nvidia,tegra124-emc.yaml | 6 ++++++ Thanks, applied. Best regards, Krzysztof
On Wed, Nov 04, 2020 at 07:48:52PM +0300, Dmitry Osipenko wrote: > Most of Host1x devices have at least one memory client. These clients > are directly connected to the memory controller. The new interconnect > properties represent the memory client's connection to the memory > controller. > > Reviewed-by: Rob Herring <robh@kernel.org> > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > .../display/tegra/nvidia,tegra20-host1x.txt | 68 +++++++++++++++++++ > 1 file changed, 68 insertions(+) Does not look like patch for memory controller drivers but I guess better to keep it with others. Let me know if it should go via different tree. Thanks, applied. Best regards, Krzysztof
On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote: > Each memory client has unique hardware ID, add these IDs. > > Acked-by: Rob Herring <robh@kernel.org> > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > include/dt-bindings/memory/tegra20-mc.h | 53 +++++++++++++++++++++++++ > 1 file changed, 53 insertions(+) Thanks, applied. Best regards, Krzysztof
On Wed, Nov 04, 2020 at 07:49:05PM +0300, Dmitry Osipenko wrote: > Use devm_platform_ioremap_resource() helper which makes code a bit > cleaner. > > Acked-by: Thierry Reding <treding@nvidia.com> > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > drivers/memory/tegra/tegra124-emc.c | 4 +--- > drivers/memory/tegra/tegra20-emc.c | 4 +--- > 2 files changed, 2 insertions(+), 6 deletions(-) Thanks, applied. Best regards, Krzysztof
On Wed, Nov 04, 2020 at 07:49:11PM +0300, Dmitry Osipenko wrote: > Now Internal and External Memory Controllers are memory interconnection > providers. This allows us to use interconnect API for tuning of memory > configuration. EMC driver now supports OPPs and DVFS. > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > drivers/memory/tegra/Kconfig | 3 +- > drivers/memory/tegra/tegra20-emc.c | 310 ++++++++++++++++++++++++++++- > drivers/memory/tegra/tegra20.c | 77 +++++++ > 3 files changed, 386 insertions(+), 4 deletions(-) Thanks, applied. Best regards, Krzysztof
On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote: > Each memory client has unique hardware ID, add these IDs. > > Acked-by: Rob Herring <robh@kernel.org> > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > include/dt-bindings/memory/tegra20-mc.h | 53 +++++++++++++++++++++++++ > 1 file changed, 53 insertions(+) Is there any chance you could drop these dt-bindings include patches (17, 18 and 19) so that I can pick them up into the Tegra tree? The device tree changes that I was going to pick up depend on this and fail to build if applied as-is. I was looking at your linux-mem-ctrl tree and had initially thought I could just pull in one of the branches to get these dependencies, but it looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch, which the ARM SoC maintainers wouldn't like to see me pull in for a dependency on device tree changes. If this is all fixed at this point, I'll just have to push back the device tree changes to v5.12, or perhaps see if the ARM SoC maintainers are willing to take a late pull request that's based on v5.11-rc1. Thierry
On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote: > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote: > > Each memory client has unique hardware ID, add these IDs. > > > > Acked-by: Rob Herring <robh@kernel.org> > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > --- > > include/dt-bindings/memory/tegra20-mc.h | 53 +++++++++++++++++++++++++ > > 1 file changed, 53 insertions(+) > > Is there any chance you could drop these dt-bindings include patches > (17, 18 and 19) so that I can pick them up into the Tegra tree? The > device tree changes that I was going to pick up depend on this and > fail to build if applied as-is. > > I was looking at your linux-mem-ctrl tree and had initially thought I > could just pull in one of the branches to get these dependencies, but it > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch, > which the ARM SoC maintainers wouldn't like to see me pull in for a > dependency on device tree changes. Partially you answered here. :) Since you should not pull my branch into a DT branch, you also should not put these include/dt-bindings patches there. SoC guys will complain about this as well. These patches are also needed for the driver, so if you take them, I would need them back in a pull request. SoC folks could spot it as well and point that such merge should not happen. > If this is all fixed at this point, I'll just have to push back the > device tree changes to v5.12, or perhaps see if the ARM SoC maintainers > are willing to take a late pull request that's based on v5.11-rc1. Yeah, that's a known problem. I asked about this Arnd and Olof in the past and got reply with two solutions: 1. Apply current version of patch without defines, just hard-coded numbers. After merging to Linus, replace the numbers with defines. 2. Wait with DTS till dependencies reach Linus. Best regards, Krzysztof
On Thu, 26 Nov 2020 at 18:39, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote: > > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote: > > > Each memory client has unique hardware ID, add these IDs. > > > > > > Acked-by: Rob Herring <robh@kernel.org> > > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > > --- > > > include/dt-bindings/memory/tegra20-mc.h | 53 +++++++++++++++++++++++++ > > > 1 file changed, 53 insertions(+) > > > > Is there any chance you could drop these dt-bindings include patches > > (17, 18 and 19) so that I can pick them up into the Tegra tree? The > > device tree changes that I was going to pick up depend on this and > > fail to build if applied as-is. > > > > I was looking at your linux-mem-ctrl tree and had initially thought I > > could just pull in one of the branches to get these dependencies, but it > > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch, > > which the ARM SoC maintainers wouldn't like to see me pull in for a > > dependency on device tree changes. > > Partially you answered here. :) Since you should not pull my branch into > a DT branch, you also should not put these include/dt-bindings patches > there. SoC guys will complain about this as well. > > These patches are also needed for the driver, so if you take them, I > would need them back in a pull request. SoC folks could spot it as well > and point that such merge should not happen. It seems I was wrong - these patches are not needed for the driver code. Neither in applied parts nor in upcoming Dmitry's work. In such case I could rework my branches and send a new pull request. The patches would stay only in your tree. Best regards, Krzysztof
On Thu, Nov 26, 2020 at 06:45:51PM +0100, Krzysztof Kozlowski wrote: > On Thu, 26 Nov 2020 at 18:39, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote: > > > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote: > > > > Each memory client has unique hardware ID, add these IDs. > > > > > > > > Acked-by: Rob Herring <robh@kernel.org> > > > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > > > --- > > > > include/dt-bindings/memory/tegra20-mc.h | 53 +++++++++++++++++++++++++ > > > > 1 file changed, 53 insertions(+) > > > > > > Is there any chance you could drop these dt-bindings include patches > > > (17, 18 and 19) so that I can pick them up into the Tegra tree? The > > > device tree changes that I was going to pick up depend on this and > > > fail to build if applied as-is. > > > > > > I was looking at your linux-mem-ctrl tree and had initially thought I > > > could just pull in one of the branches to get these dependencies, but it > > > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch, > > > which the ARM SoC maintainers wouldn't like to see me pull in for a > > > dependency on device tree changes. > > > > Partially you answered here. :) Since you should not pull my branch into > > a DT branch, you also should not put these include/dt-bindings patches > > there. SoC guys will complain about this as well. > > > > These patches are also needed for the driver, so if you take them, I > > would need them back in a pull request. SoC folks could spot it as well > > and point that such merge should not happen. > > It seems I was wrong - these patches are not needed for the driver > code. Neither in applied parts nor in upcoming Dmitry's work. In such > case I could rework my branches and send a new pull request. The > patches would stay only in your tree. Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Best regards, Krzysztof
On Wed, Nov 04, 2020 at 07:48:54PM +0300, Dmitry Osipenko wrote: > Each memory client has unique hardware ID, add these IDs. > > Acked-by: Rob Herring <robh@kernel.org> > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > include/dt-bindings/memory/tegra30-mc.h | 67 +++++++++++++++++++++++++ > 1 file changed, 67 insertions(+) > Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Best regards, Krzysztof
On Thu, Nov 26, 2020 at 06:45:51PM +0100, Krzysztof Kozlowski wrote: > On Thu, 26 Nov 2020 at 18:39, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote: > > > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote: > > > > Each memory client has unique hardware ID, add these IDs. > > > > > > > > Acked-by: Rob Herring <robh@kernel.org> > > > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > > > --- > > > > include/dt-bindings/memory/tegra20-mc.h | 53 +++++++++++++++++++++++++ > > > > 1 file changed, 53 insertions(+) > > > > > > Is there any chance you could drop these dt-bindings include patches > > > (17, 18 and 19) so that I can pick them up into the Tegra tree? The > > > device tree changes that I was going to pick up depend on this and > > > fail to build if applied as-is. > > > > > > I was looking at your linux-mem-ctrl tree and had initially thought I > > > could just pull in one of the branches to get these dependencies, but it > > > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch, > > > which the ARM SoC maintainers wouldn't like to see me pull in for a > > > dependency on device tree changes. > > > > Partially you answered here. :) Since you should not pull my branch into > > a DT branch, you also should not put these include/dt-bindings patches > > there. SoC guys will complain about this as well. > > > > These patches are also needed for the driver, so if you take them, I > > would need them back in a pull request. SoC folks could spot it as well > > and point that such merge should not happen. > > It seems I was wrong - these patches are not needed for the driver > code. Neither in applied parts nor in upcoming Dmitry's work. In such > case I could rework my branches and send a new pull request. The > patches would stay only in your tree. Oh yeah, I forgot to mention that the driver doesn't actually need these. I'll take your Acked-bys and put these three patches into the Tegra tree, then. Thanks, Thierry
On Thu, Nov 26, 2020 at 06:39:22PM +0100, Krzysztof Kozlowski wrote: > On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote: > > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote: > > > Each memory client has unique hardware ID, add these IDs. > > > > > > Acked-by: Rob Herring <robh@kernel.org> > > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > > --- > > > include/dt-bindings/memory/tegra20-mc.h | 53 +++++++++++++++++++++++++ > > > 1 file changed, 53 insertions(+) > > > > Is there any chance you could drop these dt-bindings include patches > > (17, 18 and 19) so that I can pick them up into the Tegra tree? The > > device tree changes that I was going to pick up depend on this and > > fail to build if applied as-is. > > > > I was looking at your linux-mem-ctrl tree and had initially thought I > > could just pull in one of the branches to get these dependencies, but it > > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch, > > which the ARM SoC maintainers wouldn't like to see me pull in for a > > dependency on device tree changes. > > Partially you answered here. :) Since you should not pull my branch into > a DT branch, you also should not put these include/dt-bindings patches > there. SoC guys will complain about this as well. > > These patches are also needed for the driver, so if you take them, I > would need them back in a pull request. SoC folks could spot it as well > and point that such merge should not happen. > > > If this is all fixed at this point, I'll just have to push back the > > device tree changes to v5.12, or perhaps see if the ARM SoC maintainers > > are willing to take a late pull request that's based on v5.11-rc1. > > Yeah, that's a known problem. I asked about this Arnd and Olof in the > past and got reply with two solutions: > 1. Apply current version of patch without defines, just hard-coded > numbers. After merging to Linus, replace the numbers with defines. > > 2. Wait with DTS till dependencies reach Linus. What I've done occasionally in the past was to put these kinds of patches into a separate "dt-bindings" branch that I could use to resolve dependencies from device tree files. The ARM SoC maintainers never had any issues with that approach. I guess this is a bit of a special case, because the DT includes are ultimately really a part of the device tree, so mixing them both isn't problematic. Thierry
On Thu, Nov 26, 2020 at 07:02:55PM +0100, Thierry Reding wrote: > On Thu, Nov 26, 2020 at 06:39:22PM +0100, Krzysztof Kozlowski wrote: > > On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote: > > > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote: > > > > Each memory client has unique hardware ID, add these IDs. > > > > > > > > Acked-by: Rob Herring <robh@kernel.org> > > > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > > > --- > > > > include/dt-bindings/memory/tegra20-mc.h | 53 +++++++++++++++++++++++++ > > > > 1 file changed, 53 insertions(+) > > > > > > Is there any chance you could drop these dt-bindings include patches > > > (17, 18 and 19) so that I can pick them up into the Tegra tree? The > > > device tree changes that I was going to pick up depend on this and > > > fail to build if applied as-is. > > > > > > I was looking at your linux-mem-ctrl tree and had initially thought I > > > could just pull in one of the branches to get these dependencies, but it > > > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch, > > > which the ARM SoC maintainers wouldn't like to see me pull in for a > > > dependency on device tree changes. > > > > Partially you answered here. :) Since you should not pull my branch into > > a DT branch, you also should not put these include/dt-bindings patches > > there. SoC guys will complain about this as well. > > > > These patches are also needed for the driver, so if you take them, I > > would need them back in a pull request. SoC folks could spot it as well > > and point that such merge should not happen. > > > > > If this is all fixed at this point, I'll just have to push back the > > > device tree changes to v5.12, or perhaps see if the ARM SoC maintainers > > > are willing to take a late pull request that's based on v5.11-rc1. > > > > Yeah, that's a known problem. I asked about this Arnd and Olof in the > > past and got reply with two solutions: > > 1. Apply current version of patch without defines, just hard-coded > > numbers. After merging to Linus, replace the numbers with defines. > > > > 2. Wait with DTS till dependencies reach Linus. > > What I've done occasionally in the past was to put these kinds of > patches into a separate "dt-bindings" branch that I could use to resolve > dependencies from device tree files. The ARM SoC maintainers never had > any issues with that approach. > > I guess this is a bit of a special case, because the DT includes are > ultimately really a part of the device tree, so mixing them both isn't > problematic. Indeed, that way could work... and no one would spot it. :) Many times these headers were for clock symbols so if they go via SoC/DT tree, merge back to clock tree could be accepted. Best regards, Krzysztof
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: v7: - Corrected example in "dt-bindings: host1x: Document new interconnect properties". - Added "obj-$(CONFIG_ARCH_TEGRA_132_SOC) += clk-tegra124-emc.o" to "memory: tegra124-emc: Make driver modular" in order to fix ARM64 kernel compilation reported by kernel test robot. - Fixed build error reported by kernel test robot which happened due to a missing stub for tegra_sku_info for COMPILE_TEST drivers. Added this new patch: soc/tegra: fuse: Add stub for tegra_sku_info - Fixed minor W=1 warning reported by kernel test robot for the "drm/tegra: dc: Support memory bandwidth management" patch. - Changed TEGRA_MC_ICC_TAG type from a enum to bitmask in order to have tags more extensible in the future. - Fixed dt_binding_check warning in "dt-bindings: memory: tegra124: mc: Document new interconnect property", was reported by kernel bot. - Added acks/r-b from Rob Herring, Thierry Reding and Krzysztof Kozlowski to the reviewed patches. - The EMC "core-supply" property is now explicitly optional in the DT bindings. This change was suggested by Krzysztof Kozlowski. - Removed unnecessary white-spaces in the device-tree example of the patch: dt-bindings: memory: tegra20: emc: Document new interconnect property This change was suggested by Krzysztof Kozlowski. - Explicitly documented that core-supply is an optional property in patch: dt-bindings: memory: tegra20: emc: Document new interconnect property This change was suggested by Krzysztof Kozlowski. - Replaced underscores with hyphens in the DT node names. Suggested by Krzysztof Kozlowski. - Added operating-points-v2 to the required properties of the patch: dt-bindings: memory: tegra124: emc: Document OPP table and voltage regulator This was missed by accident in the v6. - Renamed get_memory_controller() to memory_controller_get(). Suggested by Krzysztof Kozlowski. - Changed internal ICC IDs like it was suggested by Thierry Reding in review comment to "memory: tegra-mc: Add interconnect framework". - The MC's ICC xlate_extended() now is a per-SoC hook. Suggested by Thierry Reding. - Corrected and improved the debugfs of the EMC drivers which transitioned to OPP table usage. The debug code now uses OPP API, which is must-have for voltage scaling, and min/max rate limits aren't changed using the clk API because OPP API should be used. - The tegra20-devfeq driver is removed and replaced with the EMC_STAT driver, which is now a part of the T20 EMC driver. Suggested by Thierry Reding. Implemented in these patches: memory: tegra20-emc: Add devfreq support PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver - Reordered patches, like it was suggested by Krzysztof Kozlowski by having patches which make smaller improvements before patches which add new features. - The EMC drivers now query actual DRAM bus width from hardware instead of hardcoding the default-expected value. - The EMC drivers now properly account clock rate requests from different internal sources (ICC, debugfs, etc) by selecting the fastest clock rate. - There are lots of miscellaneous minor clean-ups and improvements. All patches were fully re-tested. - Rebased patches on a recent linux-next. Fixed merge conflicts with the recent Tegra DRM driver changes. - Improved tegra30-devfeq patches by implementing suggestions from Chanwoo Choi. Removed unnecessary EPROBE_DEFER handling, added clarifying comment for the KHz conversions, improved code that touches ARRAY_SIZE. 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 (47): clk: tegra: Export Tegra20 EMC kernel symbols soc/tegra: fuse: Export tegra_read_ram_code() soc/tegra: fuse: Add stub for tegra_sku_info 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: 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_memory_controller_get() memory: tegra: Use devm_platform_ioremap_resource() memory: tegra: Remove superfluous error messages around platform_get_irq() memory: tegra: Add missing latency allowness entry for Page Table Cache memory: tegra-mc: Add interconnect framework memory: tegra20-emc: Make driver modular memory: tegra20-emc: Continue probing if timings are missing in device-tree memory: tegra20: Support interconnect framework memory: tegra20-emc: Add devfreq support memory: tegra30: Add FIFO sizes to 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: 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/nvidia,tegra30-actmon.txt | 25 + .../display/tegra/nvidia,tegra20-host1x.txt | 68 +++ .../nvidia,tegra124-emc.yaml | 19 + .../nvidia,tegra124-mc.yaml | 5 + .../memory-controllers/nvidia,tegra20-emc.txt | 22 +- .../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 + .../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 | 7 + arch/arm/boot/dts/tegra20-colibri.dtsi | 4 + arch/arm/boot/dts/tegra20-paz00.dts | 6 + .../arm/boot/dts/tegra20-peripherals-opp.dtsi | 92 ++++ arch/arm/boot/dts/tegra20.dtsi | 33 +- .../tegra30-asus-nexus7-grouper-common.dtsi | 4 + ...30-asus-nexus7-grouper-memory-timings.dtsi | 12 + .../arm/boot/dts/tegra30-peripherals-opp.dtsi | 383 +++++++++++++++ arch/arm/boot/dts/tegra30.dtsi | 33 +- drivers/clk/tegra/Makefile | 3 +- 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 | 10 - drivers/devfreq/Makefile | 1 - drivers/devfreq/tegra20-devfreq.c | 210 -------- drivers/devfreq/tegra30-devfreq.c | 164 ++++--- 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 | 14 +- drivers/memory/tegra/mc.c | 155 +++++- drivers/memory/tegra/mc.h | 22 + drivers/memory/tegra/tegra114.c | 6 + drivers/memory/tegra/tegra124-emc.c | 378 +++++++++++++-- drivers/memory/tegra/tegra124.c | 88 +++- drivers/memory/tegra/tegra20-emc.c | 458 ++++++++++++++++-- drivers/memory/tegra/tegra20.c | 77 +++ drivers/memory/tegra/tegra210-emc-core.c | 39 +- drivers/memory/tegra/tegra30-emc.c | 353 ++++++++++++-- drivers/memory/tegra/tegra30.c | 245 +++++++++- 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 | 8 + include/soc/tegra/emc.h | 16 - include/soc/tegra/fuse.h | 4 + include/soc/tegra/mc.h | 27 ++ 58 files changed, 3852 insertions(+), 460 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