similar to: [PATCH 00/15] clk/tegra: improve code and add DFS support

This series does some refactoring in the GK20A's volt and clk drivers (fixing a few things while we are at it) to let GM20B benefit from the GK20A's logic with which it is compatible. GM20B is capable of more sophisticated (and power-efficient) reclocking which will follow later. Even after this more fancy reclocking is merged, the present logic will remain used in the lowest speedo of

This series adds support for reclocking on GK20A. The first two patches touch the clock subsystem to allow GK20A to operate, by making the presence of the thermal and voltage devices optional, and allowing pstates to be provided directly instead of being probed using the BIOS (which Tegra does not have). The last patch adds the GK20A clock device. Arguably the clock can be seen as a stripped-down

Second version of the gk20a clock patches. I have tried to keep the therm and volt devices mandatory in the clock driver, but unfortunately they are too tied to bios to allow this, at least for the moment. Consequently this version is mostly a port of the first version to Ben's tree. Ben, please let me know what I have done wrong in terms of integration to your tree, as the main purpose of

Hey Alex, Thanks. I have a couple of questions and remarks, but really, those should be treated as discussion points rather than anything else. Besides some inline comments, I was curious whether it is not necessary to pause PFIFO and the engines like done with at least NVA3-NVAF? Or is the transition smooth enough? op 10-07-14 09:34, Alexandre Courbot schreef: > Add support for

Hi, This is a try to have some simple DVFS (Dynamic Voltage and Frequency Scaling) support for GK20A. Instead of relying on other existing frequency scaling framework, we create a simple subdev in Nouveau for the same purpose. That's because we don't want to make the DVFS implementation for GK20A far more than enough in the beginning and hinder the implementation for dGPU in the future.

On Thu, Dec 18, 2014 at 8:13 PM, Vince Hsu <vinceh at nvidia.com> wrote: > Hello Ben, > > On 12/18/2014 05:34 PM, Ben Skeggs wrote: >> >> On Thu, Dec 18, 2014 at 4:28 PM, Vince Hsu <vinceh at nvidia.com> wrote: >>> >>> This patch creates a subdev for DVFS (Dynamic Voltage and Frequency >>> Scaling) >>> support in Nouveau. This

On Thu, Dec 18, 2014 at 4:28 PM, Vince Hsu <vinceh at nvidia.com> wrote: > This patch creates a subdev for DVFS (Dynamic Voltage and Frequency Scaling) > support in Nouveau. This subdev refers to the status information provided by > the NVIDIA hardware and tries to adjust the performance level based on the > calculated target. Only the GK20A is supported right now. Hey Vince,

Hi, All, I have some problem of using dvfs in Xen 3.4.1 and 2.6.18 kernel. I enabled Speed option in BIOS and add "cpufreq=xen" in the grub file. But when I entered my dom0 and type "xenpm get-cpufreq-XXX" (any xenpm argument), it returns "[CPU0] failed to get CPU P state". I am wondering if I should enable some feature of 2.6.18 during the kernel configuration.

Hi, All, I have some problem of using dvfs in Xen 3.4.1 and 2.6.18 kernel. I enabled Speed option in BIOS and add "cpufreq=xen" in the grub file. But when I entered my dom0 and type "xenpm get-cpufreq-XXX" (any xenpm argument), it returns "[CPU0] failed to get CPU P state". I am wondering if I should enable some feature of 2.6.18 during the kernel configuration.

I have looked at problem with Fermi GPUs where changing to higher clock led to really bad perfomance (with GpuTest 20x worse perfomance) and later also crashes of the nouveau. It seemed to be affected by Shader Clock in Voltage Entries in the video BIOS. Disabling BYPASS_PLL_CHECK in CLK0_CTRL seems to completely fix the issue. I have tried to search this BYPASS_PLL_CHECK in Nvidia traces but

Following a series of three patches, two of which have been sitting in my tree for a while, the third is the result of some inspection of an NV134 BIOS that seems to use the 0xaf upcode to upload training patterns. Please test! Roy Ps. Sorry they come from yet another e-mail address. My previous provider, eclipso, actively blocks users of git send-email. Inquiries fall on deaf ears, hence I

On Mon, Dec 1, 2014 at 3:48 PM, Alexandre Courbot <gnurou at gmail.com> wrote: > On Mon, Dec 1, 2014 at 3:38 PM, Terje Bergström <tbergstrom at nvidia.com> wrote: >> On 29.11.2014 10:44, Alexandre Courbot wrote: >>> On Fri, Nov 28, 2014 at 9:09 PM, Roy Spliet <seven at nimrod-online.com> wrote: >>>> I'm not sure if I completely understand your

When gk20a_clk_ctor() returns an error code, pointer "clk" should be released. It's the same when gm20b_clk_new() returns from elsewhere following this call. Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn> --- drivers/gpu/drm/nouveau/nvkm/subdev/clk/gm20b.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

On 29.11.2014 10:44, Alexandre Courbot wrote: > On Fri, Nov 28, 2014 at 9:09 PM, Roy Spliet <seven at nimrod-online.com> wrote: >> I'm not sure if I completely understand your reply, so forgive me if I am >> stating some obvious things: >> The reason why I brought this up is because, the way I see it, DTS is the >> replacement for (V)BIOS on ARM platforms,

On 07/10/2014 06:50 PM, Mikko Perttunen wrote: > Does GK20A itself have any kind of thermal protection capabilities? > Upstream SOCTHERM support is not yet available (though I have a driver > in my tree), so we are thinking of disabling CPU DVFS on boards that > don't have always-on active cooling for now. Same might be necessary for > GPU as well. There is a small thermal

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch aims to suppress 29 missing-break-in-switch false positives. Addresses-Coverity-ID: 1456891 ("Missing break in switch") Addresses-Coverity-ID: 1324063 ("Missing break in switch") Addresses-Coverity-ID: 1324063 ("Missing break in switch")

I have looked at problem with Fermi GPUs where changing to higher clock led to really bad perfomance (with GpuTest 20x worse perfomance) and later also crashes of the nouveau. It seemed to be affected by Shader Clock in Voltage Entries in the video BIOS. Disabling BYPASS_PLL_CHECK in CLK0_CTRL seems to completely fix the issue. I have tried to search this BYPASS_PLL_CHECK in Nvidia traces but

some chipset have working engine reclocking, but broken memory reclocking like Fermi. We should for now, add the functionality to allow partly reclocking for those. Allthough this doesn't give as much performance as one might wish, it is till noticeable and may improve performance enough to be noted. Karol Herbst (2): clk: seperate engine and memory reclock toggles clk: allow engine

Thanks for reaching out on the matter Ilia. I am not to be relied on. If you're lucky, I might be able to take some questions about past work, but cannot make a solid time commitment that warrants being a mentor. Of course, the mentor does not necessarily have to have the deepest understanding of the subject matter. *At the end of the GSOC* a good student should be trusted with having more

On Tue 2019-03-26 @ 10:40:49 AM, Ilia Mirkin wrote: > Just looked over the projects... they all seem valid Thank you for taking the time to have a look and provide feedback! > but are there > people who could realistically mentor a GSoC student for these? IMHO > unless mentors can be identified, these should all be archived. Attracting mentors is probably the hardest part of running