search for: nv_clk_src_max

...ck/base.c @@ -411,6 +411,7 @@ _nouveau_clock_init(struct nouveau_object *object) memset(&clk->bstate, 0x00, sizeof(clk->bstate)); INIT_LIST_HEAD(&clk->bstate.list); clk->bstate.pstate = 0xff; + if (!clock) return 0; while (clock->name != nv_clk_src_max) { ret = clk->read(clk, clock->name);

..., bool adjust, static bool nvkm_cstate_valid(struct nvkm_clk *clk, struct nvkm_cstate *cstate, u32 max_volt, int temp) { + const struct nvkm_domain *domain = clk->domains; struct nvkm_volt *volt = clk->subdev.device->volt; int voltage; + while (domain && domain->name != nv_clk_src_max) { + if (domain->flags & NVKM_CLK_DOM_FLAG_BASECLK) { + u32 freq = cstate->domain[domain->name]; + switch (clk->boost_mode) { + case NVKM_CLK_BOOST_NONE: + if (clk->base_khz && freq > clk->base_khz) + return false; + case NVKM_CLK_BOOST_AVG: + if...

This series contains a lot of groundwork to finally fix reclocking issues on Kepler+ gpus. There shouldn't be any functional changes with the first patch being the only exception (fixes some voltage table parsing issues with of few kepler gpus) The most interessting thing is the tool in the last patch, which can be ran alongside the nvidia driver to test nouveaus volting code and print the

Last update here: https://lists.freedesktop.org/archives/nouveau/2017-September/028848.html Basically big cleanup, reordering, simplifications and some renaming to make the code easier to read and to review. I also moved some bugfixes to the front so they can be merged prior the other patches. There was also a bug related to the therm daemon triggering a pstate change leading to PMU lockups,

Following a series of patches to improve nouveaus clock tree parsing. Reclocking these engines (all but memory) is pretty stable on the cards I've tested. Please review and merge when approved. These patches do not solve the problem that core/shader engine doesn't like to be clocked up too far without fb following, with visible corruption as a result. I suspect this problem is unrelated

...+ +static struct nouveau_clocks +nvaa_domains[] = { + { nv_clk_src_crystal, 0xff }, + { nv_clk_src_href , 0xff }, + { nv_clk_src_core , 0xff, 0, "core", 1000 }, + { nv_clk_src_shader , 0xff, 0, "shader", 1000 }, + { nv_clk_src_vdec , 0xff, 0, "vdec", 1000 }, + { nv_clk_src_max } +}; + +struct nouveau_oclass * +nvaa_clock_oclass = &(struct nv50_clock_oclass) { + .base.handle = NV_SUBDEV(CLOCK, 0xaa), + .base.ofuncs = &(struct nouveau_ofuncs) { + .ctor = nvaa_clock_ctor, + .dtor = _nouveau_clock_dtor, + .init = _nouveau_clock_init, + .fini = _nouveau_clock_fini...

...+ +static struct nouveau_clocks +nvaa_domains[] = { + { nv_clk_src_crystal, 0xff }, + { nv_clk_src_href , 0xff }, + { nv_clk_src_core , 0xff, 0, "core", 1000 }, + { nv_clk_src_shader , 0xff, 0, "shader", 1000 }, + { nv_clk_src_vdec , 0xff, 0, "vdec", 1000 }, + { nv_clk_src_max } +}; + +struct nouveau_oclass * +nvaa_clock_oclass = &(struct nv50_clock_oclass) { + .base.handle = NV_SUBDEV(CLOCK, 0xaa), + .base.ofuncs = &(struct nouveau_ofuncs) { + .ctor = nvaa_clock_ctor, + .dtor = _nouveau_clock_dtor, + .init = _nouveau_clock_init, + .fini = _nouveau_clock_fini...

...bling it */ + nv_mask(priv, SEL_VCO, BIT(SEL_VCO_GPC2CLK_OUT_SHIFT), 0); + + _gk20a_pllg_disable(priv); +} + +#define GK20A_CLK_GPC_MDIV 1000 + +static struct nouveau_clocks +gk20a_domains[] = { + { nv_clk_src_crystal, 0xff }, + { nv_clk_src_gpc, 0xff, 0, "core", GK20A_CLK_GPC_MDIV }, + { nv_clk_src_max } +}; + +static struct nouveau_pstate +gk20a_pstates[] = { + { + .base = { + .domain[nv_clk_src_gpc] = 72000, + }, + }, + { + .base = { + .domain[nv_clk_src_gpc] = 108000, + }, + }, + { + .base = { + .domain[nv_clk_src_gpc] = 180000, + }, + }, + { + .base = { + .domain[nv_clk_src_gpc...

Reclocking of NVAA/NVAC is substantially different from NV50+, enough to justify a separate clock implementation. This code is a forward-port of reclocking code that has been sitting in a branch for a while, and has been tested on my NVAC. Traces show no significant reasons why this shouldn't work on NVAA, but testers are always welcome. And since these are IGPs without dedicated RAM to

This series fixes most of the issues regarding volting on GPUs with any form of GPU Boost inside their vbios, which is mainly Kepler and newer, but we find some boosting related tables in Fermi vbios' already In the end reclocking should work on most Kepler cards without any issues v2: boost_mode can now be changed at runtime minor fixups Karol Herbst (22): bios/volt: handle voltage

I've splitted my big series between the part which actually fixes the engine reclocking bits and the part handling voltage/clock updates on temperature change, so that the more reviewed parts can be merged in faster. This series fixes a lot of Engine reclocking issues found on Fermi, Kepler and all Maxwell generation GPUs. It does _not_ fix memory reclocking on Fermi. It mostly contains of

...K_OUT_SHIFT), 0); > + > + _gk20a_pllg_disable(priv); > +} > + > +#define GK20A_CLK_GPC_MDIV 1000 > + > +static struct nouveau_clocks > +gk20a_domains[] = { > + { nv_clk_src_crystal, 0xff }, > + { nv_clk_src_gpc, 0xff, 0, "core", GK20A_CLK_GPC_MDIV }, > + { nv_clk_src_max } > +}; > + > +static struct nouveau_pstate > +gk20a_pstates[] = { > + { > + .base = { > + .domain[nv_clk_src_gpc] = 72000, > + }, > + }, > + { > + .base = { > + .domain[nv_clk_src_gpc] = 108000, > + }, > + }, > + { > + .base = { > + .do...

This is an updated series for the old clocking improvement one. I think I got everything needed in place and also a simple update mechanism for updating the cstates/voltage on temperature changes. If anything is unclear how I REed or got the information, please leave a note so that I can provide additional information in the commits. Besides that I think we are pretty close now and only some

This series fixes most of the issues regarding volting on GPUs with any form of GPU Boost inside their vbios, which is mainly Kepler and newer, but we find some boosting related tables in Fermi vbios' already In the end reclocking should work on most Kepler cards without any issues Karol Herbst (19): bios/volt: handle voltage table version 0x50 with 0ed header volt: properly detect entry

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

Just wanted to post updated versions of my last series/patches. Reviews welcomed. It would be also nice if we agree on features I should focus upstreaming, so that this work can be better splitted or reordered. Sadly most of my patches depend on the rather big clk subdev rework and I think those patches shows best, why I think this rework is actually needed and makes things much easier to add

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

We are slowly getting there! v4 of the series with some realy good improvements, so I am sure this is like 95% done and only needs some proper polishing and proper Reviews! I also added the NvVoltOffsetmV module parameter, so that a user is able to over and !under!-volt the GPU. Overvolting makes sense, when there are still some reclocking issues left, which might be solved by a higher voltage.

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 GM20B PLL's Maxwell features, namely glitchless switch and (more importantly) DFS support. DFS lets the PLL lower its output speed according to input current variations, making the clock more stable and allowing it to run safely at lower voltage. All GM20B additions are done in the last patch, which consequently ends up being considerably big ; fortunately, it