| Message ID | 20190414175939.12368-1-digetx@gmail.com |
|---|---|
| Headers | show |
| Series | Introduce machine-specific regulators coupling API | expand |
14.04.2019 20:59, Dmitry Osipenko пишет: > Hello, > > I was looking into how to properly implement regulators coupling for > NVIDIA Tegra SoC's and ended up with this patchset that introduces > machine-specific regulators coupling. Upstream kernel now has support > for a simple variants of regulators coupling in a form of limiting > maximum voltage spreading between two regulators, but that's not enough > for the case of Tegra SoC's. It's a bit difficult to support universally > all possible coupling restrictions in a form of device-tree description, > so here comes the machine-specific coupling API which allow platforms > to customize coupling algorithms. Hello people, I want to point out that the CPUFreq patches are currently blocked because of the missing support for a regulators coupling on Tegra and we want to switch to a proper-generic OPP voltage/freq API. The other thing that I also forgot to mention that we will need a way to keep on hold CORE voltage changes until all relevant peripheral drivers are loaded and claimed the required voltage level. That is needed because some of the critical peripherals are left in a running state after bootloader. Currently, in this patchset, we are not allowing CORE voltage to go lower than the level left after bootloader and once all the relevant drivers will get support for the voltage management, we should be able to unhold the lower CORE voltages around late_init(). Will be great if you could take a look at this series and tell your opinion on the approach, I'll be happy to put more effort into it all if will be needed. There is now a bit more advanced version of the series that adds more error-checking and makes use of max-spread and max-step values from the regular constraints (i.e. values defined in device-tree) instead of hardcoding them in the code.
On Sun, May 05, 2019 at 05:57:42PM +0300, Dmitry Osipenko wrote: > after bootloader. Currently, in this patchset, we are not allowing CORE > voltage to go lower than the level left after bootloader and once all > the relevant drivers will get support for the voltage management, we > should be able to unhold the lower CORE voltages around late_init(). That's going to break as soon as someone like a distro builds drivers as modules, you can't rely on things getting done at any particular point in initialization or indeed on any given set of drivers being available in the particular kernel that the user chooses to run - if they decide not to build drivers for devices that they don't use on their particular system that should work. Overall this feels like an abstraction failure and you've not really said what the constraints you're trying to implement here are so it's hard to tell if that's the case or not.
08.05.2019 11:05, Mark Brown пишет: > On Sun, May 05, 2019 at 05:57:42PM +0300, Dmitry Osipenko wrote: > >> after bootloader. Currently, in this patchset, we are not allowing CORE >> voltage to go lower than the level left after bootloader and once all >> the relevant drivers will get support for the voltage management, we >> should be able to unhold the lower CORE voltages around late_init(). > > That's going to break as soon as someone like a distro builds drivers as > modules, you can't rely on things getting done at any particular point > in initialization or indeed on any given set of drivers being available > in the particular kernel that the user chooses to run - if they decide > not to build drivers for devices that they don't use on their particular > system that should work. Yes, this is not really well-thought yet. Although I guess it should be fine to assume that all the relevant hardware units are blocked by the CLK framework that disables the orphaned clocks (by default). Probably we'll have to better define what drivers are system-critical for the platform, making sure that they are always included in the kernel build and complied as built-in. But I also guess there could be other (better) variants as well. For now I'm primarily focused on getting the CPU voltage scaling to work. The CORE minimum voltage is kept limited for now to the boot-level. I'm assuming that the boot-stage voltages are at reasonable levels for all boards because otherwise likely that there is a trouble already (constraint violations). > Overall this feels like an abstraction failure and you've not really > said what the constraints you're trying to implement here are so it's > hard to tell if that's the case or not. > I described the coupling voltage constraints in the replies to the relevant patches. The CORE regulator supplies multiple peripherals in the SoC, each peripheral has it's own demand for a minimum CORE voltage depending on a clock rate and hardware version. Tegra20 has the RTC (real-time-clock domain) regulator being coupled in addition to the CORE. It doesn't supply any peripherals in the SoC that have specific demands for minimum RTC voltage. Please let me know if there is a need to explain anything else in a more detail.
Hello, I was looking into how to properly implement regulators coupling for NVIDIA Tegra SoC's and ended up with this patchset that introduces machine-specific regulators coupling. Upstream kernel now has support for a simple variants of regulators coupling in a form of limiting maximum voltage spreading between two regulators, but that's not enough for the case of Tegra SoC's. It's a bit difficult to support universally all possible coupling restrictions in a form of device-tree description, so here comes the machine-specific coupling API which allow platforms to customize coupling algorithms. Dmitry Osipenko (6): regulator: core: Introduce API for machine-specific regulators coupling regulator: core: Parse max-spread value per regulator couple regulator: core: Expose some of core functions regulator: core Bump MAX_COUPLED to 3 soc/tegra: regulators: Add regulators coupler for Tegra20 soc/tegra: regulators: Add regulators coupler for Tegra30 drivers/regulator/core.c | 89 +++++--- drivers/regulator/of_regulator.c | 49 ++-- drivers/soc/tegra/Kconfig | 12 + drivers/soc/tegra/Makefile | 2 + drivers/soc/tegra/regulators-tegra20.c | 304 +++++++++++++++++++++++++ drivers/soc/tegra/regulators-tegra30.c | 256 +++++++++++++++++++++ include/linux/regulator/driver.h | 14 +- include/linux/regulator/machine.h | 22 +- 8 files changed, 694 insertions(+), 54 deletions(-) create mode 100644 drivers/soc/tegra/regulators-tegra20.c create mode 100644 drivers/soc/tegra/regulators-tegra30.c