search for: mulu32_32_64

.../nouveau/nvkm/subdev/pmu/fuc/kernel.fuc index d1ca3c7..6839f88 100644 --- a/drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc +++ b/drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc @@ -252,7 +252,7 @@ ticks_from_ns: /* try not losing precision (multiply then divide) */ imm32($r13, HW_TICKS_PER_US) - call #mulu32_32_64 + call(mulu32_32_64) /* use an immeditate, it's ok because HW_TICKS_PER_US < 16 bits */ div $r12 $r12 1000 @@ -264,7 +264,7 @@ ticks_from_ns: /* let's divide then multiply, too bad for the precision! */ div $r14 $r14 1000 imm32($r13, HW_TICKS_PER_US) - call #mulu32_32_64 + ca...

this series fixes the PMU on falcons v5 which fixes memory recklocking on kepler2 and would also allow us to enable memory recklocking on maxwell Karol Herbst (4): pmu/fuc: fix imm32 for gk208+ pmu/fuc: replace mov+sethi with imm32 pmu/fuc: use the call macro instead of using the call instruction directly pmu/fuc: use imm32 in ld/st macros

while trying out my pmu_counter patches on a gk208 gpu, I notived that the pmu is pretty much screwed up there. Karol Herbst (4): pmu/fuc: fix imm32 for gk208+ pmu/fuc: replace mov+sethi with imm32 pmu/fuc: call# seems to be broken on gk208 pmu/fuc: movw is somewhat weird on gk208, use mov instead drm/nouveau/nvkm/subdev/pmu/fuc/gf100.fuc3.h | 1598 +++++++++++------------

...xfe0814b6, + 0x17f10014, + 0x13f000e0, + 0x1c07f000, + 0xd00604b6, + 0x04bd0001, + 0xf0ff17f0, + 0x04b61407, + 0x0001d006, + 0x17f004bd, + 0x0015f102, + 0x1007f008, 0xd00604b6, 0x04bd0001, -/* 0x03f7: init_proc */ - 0x9858f7f0, - 0x16b001f1, - 0xfa0bf400, - 0xf0b615f9, - 0xf20ef458, -/* 0x0408: mulu32_32_64 */ - 0x20f910f9, - 0x40f930f9, - 0x9510e195, - 0xc4bd10d2, - 0xedffb4bd, - 0x301dffc0, - 0xf10234b9, - 0xb6ffff34, - 0x45b61034, - 0x00c3bb10, - 0xff01b4bb, - 0x34b930e2, - 0xff34f102, - 0x1034b6ff, - 0xbb1045b6, - 0xb4bb00c3, - 0x3012ff01, - 0xfc00b3bb, - 0xfc30fc40, - 0xf810fc20, -/* 0x0459: host...

...fc, -/* 0x0310: init */ +/* 0x0300: init */ 0xcf010841, 0x11e70011, 0x14b60109, @@ -1165,12 +1161,12 @@ uint32_t gk208_pmu_code[] = { 0x011031f4, 0xf6380001, 0x04bd0001, -/* 0x035a: init_proc */ +/* 0x034a: init_proc */ 0xf198580f, 0x0016b001, 0xf9fa0bf4, 0x58f0b615, -/* 0x036b: mulu32_32_64 */ +/* 0x035b: mulu32_32_64 */ 0xf9f20ef4, 0xf920f910, 0x9540f930, @@ -1191,7 +1187,7 @@ uint32_t gk208_pmu_code[] = { 0x00b3bb30, 0x30fc40fc, 0x10fc20fc, -/* 0x03ba: host_send */ +/* 0x03aa: host_send */ 0xb04100f8, 0x0011cf04, 0xcf04a042, @@ -1202,18 +1198,18 @@ uint32_t gk208_p...

Re-use the therm-exported fan structure with only two minor modifications: - pwm_freq: u16 -> u32; - add fan_type (toggle or PWM) v2: - Do not memset the table to 0 as it erases the pre-set default values Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/Kbuild | 1 + drm/core/include/subdev/bios/fan.h | 1 + drm/core/subdev/bios/fan.c | 1

...x1c07f000, + 0xbd0001d0, + 0xff17f004, + 0xd01407f0, + 0x04bd0001, + 0xf10217f0, + 0xf0080015, + 0x01d01007, + 0xf104bd00, + 0xf000f617, + 0x10fe0013, + 0x1031f400, + 0xf00117f0, + 0x01d03807, + 0xf004bd00, +/* 0x03a2: init_proc */ + 0xf19858f7, + 0x0016b001, + 0xf9fa0bf4, + 0x58f0b615, +/* 0x03b3: mulu32_32_64 */ + 0xf9f20ef4, + 0xf920f910, + 0x9540f930, + 0xd29510e1, + 0xbdc4bd10, + 0xc0edffb4, + 0xb9301dff, + 0x34f10234, + 0x34b6ffff, + 0x1045b610, + 0xbb00c3bb, + 0xe2ff01b4, + 0x0234b930, + 0xffff34f1, + 0xb61034b6, + 0xc3bb1045, + 0x01b4bb00, + 0xbb3012ff, + 0x40fc00b3, + 0x20fc30fc, + 0x00f810fc, +/...

these are usually used for dynamic reclocking on gt215 and newer The counters are used to get the load of the core, memory, video and pcie loads currently I expose the loads through a debugfs "current_load" file, but I want to move that to nvif and just add a wrapper around that in debugfs for convenience Anyway there are still some issues I would like to discuss: 1. currently the

these are usually used for dynamic reclocking on gt215 and newer The counters are used to get the load of the core, memory, video and pcie loads currently I expose the loads through a debugfs "current_load" file, but I want to move that to nvif and just add a wrapper around that in debugfs for convenience. Using nvif would have the advantage, that userspace tools can easily get loads

this series makes use of the load counters we can use to get information about the current load of the gpu. This series includes the needed pmu bits and a debugfs interface to read them out. Currently the values are between 0 and 255, because it is much easier to implement it this way on the pmu. Karol Herbst (4): subdev/pmu/fuc: add gk104 pmu/fuc: add macros for pdaemon pwr counters