search for: rd32

...********************************/ static struct nouveau_oclass nv98_bsp_cclass = { .handle = NV_ENGCTX(BSP, 0x98), .ofuncs = &(struct nouveau_ofuncs) { - .ctor = _nouveau_engctx_ctor, - .dtor = _nouveau_engctx_dtor, - .init = _nouveau_engctx_init, - .fini = _nouveau_engctx_fini, - .rd32 = _nouveau_engctx_rd32, - .wr32 = _nouveau_engctx_wr32, + .ctor = _nouveau_falcon_context_ctor, + .dtor = _nouveau_falcon_context_dtor, + .init = _nouveau_falcon_context_init, + .fini = _nouveau_falcon_context_fini, + .rd32 = _nouveau_falcon_context_rd32, + .wr32 = _nouveau_falcon_context_wr...

...ndex 0f53416..0483cbd 100644 --- a/drivers/gpu/drm/nouveau/nv50_evo.c +++ b/drivers/gpu/drm/nouveau/nv50_evo.c @@ -33,17 +33,22 @@ #include <subdev/timer.h> #include <subdev/fb.h> +struct evo_object { + struct nouveau_object parent; + void __iomem *iomem; +}; + static u32 nv50_evo_rd32(struct nouveau_object *object, u32 addr) { - void __iomem *iomem = object->oclass->ofuncs->rd08; + void __iomem *iomem = ((struct evo_object *)object)->iomem; return ioread32_native(iomem + addr); } static void nv50_evo_wr32(struct nouveau_object *object, u32 addr, u32 data) {...

...t. For example I think we'll eventually need to have barriers to ensure that the CPU write buffers are flushed, etc. It also seems like most users of the FIFO channel object will just go and map its buffer once and then only access it via the virtual mapping only, without going through the ->rd32()/->wr32() callbacks nor unmapping via ->unmap(). That means we effectively don't have a good point where we could emit the memory barriers. I see two possibilities here: 1) make all accesses go through the accessors or 2) guard each series of accesses with a pair of nvkm_map() and nvkm_...

...km-y += nvkm/subdev/pci/gf106.o nvkm-y += nvkm/subdev/pci/gk104.o diff --git a/drm/nouveau/nvkm/subdev/pci/g92.c b/drm/nouveau/nvkm/subdev/pci/g92.c index 654607e0..48874359 100644 --- a/drm/nouveau/nvkm/subdev/pci/g92.c +++ b/drm/nouveau/nvkm/subdev/pci/g92.c @@ -37,7 +37,7 @@ g92_pci_func = { .rd32 = nv40_pci_rd32, .wr08 = nv40_pci_wr08, .wr32 = nv40_pci_wr32, - .msi_rearm = nv40_pci_msi_rearm, + .msi_rearm = nv46_pci_msi_rearm, .pcie.init = g84_pcie_init, .pcie.set_link = g84_pcie_set_link, diff --git a/drm/nouveau/nvkm/subdev/pci/g94.c b/drm/nouveau/nvkm/subdev/pci/g94.c new file...

...; @@ -368,8 +348,8 @@ gk20a_instobj_func_dma = { .target = gk20a_instobj_target, .addr = gk20a_instobj_addr, .size = gk20a_instobj_size, - .acquire = gk20a_instobj_acquire, - .release = gk20a_instobj_release, + .acquire = gk20a_instobj_acquire_dma, + .release = gk20a_instobj_release_dma, .rd32 = gk20a_instobj_rd32, .wr32 = gk20a_instobj_wr32, .map = gk20a_instobj_map, @@ -381,8 +361,8 @@ gk20a_instobj_func_iommu = { .target = gk20a_instobj_target, .addr = gk20a_instobj_addr, .size = gk20a_instobj_size, - .acquire = gk20a_instobj_acquire, - .release = gk20a_instobj_release, + .a...

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 +++++++++++------------

...0x00000007, 0x00000000, - 0x000006e1, + 0x000006df, /* 0x03c4: memx_func_tail */ /* 0x03c4: memx_ts_start */ 0x00000000, @@ -916,7 +916,7 @@ static uint32_t gf100_pmu_data[] = { 0x00000000, }; -static uint32_t gf100_pmu_code[] = { +uint32_t gf100_pmu_code[] = { 0x03920ef5, /* 0x0004: rd32 */ 0x07a007f1, @@ -1372,432 +1372,432 @@ static uint32_t gf100_pmu_code[] = { /* 0x065b: memx_func_wait_vblank */ 0x9800f840, 0x66b00016, - 0x130bf400, + 0x120bf400, 0xf40166b0, 0x0ef4060b, /* 0x066d: memx_func_wait_vblank_head1 */ - 0x2077f12e, - 0x070ef400, -/* 0x0674: memx_func_wait_...

...0x00000000, - 0x00000658, + 0x0000065b, 0x00000007, 0x00000000, - 0x000006de, + 0x000006e1, /* 0x03c4: memx_func_tail */ /* 0x03c4: memx_ts_start */ 0x00000000, @@ -917,887 +917,887 @@ uint32_t gf100_pmu_data[] = { }; uint32_t gf100_pmu_code[] = { - 0x03930ef5, + 0x03920ef5, /* 0x0004: rd32 */ 0x07a007f1, 0xd00604b6, 0x04bd000e, - 0xf001d7f0, - 0x07f101d3, - 0x04b607ac, - 0x000dd006, -/* 0x0022: rd32_wait */ - 0xd7f104bd, - 0xd4b607ac, - 0x00ddcf06, - 0x7000d4f1, - 0xf1f21bf4, - 0xb607a4d7, - 0xddcf06d4, -/* 0x003f: wr32 */ - 0xf100f800, - 0xb607a007, - 0x0ed00604, - 0xf104bd00,...

...nc_dma = { > .target = gk20a_instobj_target, > .addr = gk20a_instobj_addr, > .size = gk20a_instobj_size, > - .acquire = gk20a_instobj_acquire, > - .release = gk20a_instobj_release, > + .acquire = gk20a_instobj_acquire_dma, > + .release = gk20a_instobj_release_dma, > .rd32 = gk20a_instobj_rd32, > .wr32 = gk20a_instobj_wr32, > .map = gk20a_instobj_map, > @@ -381,8 +361,8 @@ gk20a_instobj_func_iommu = { > .target = gk20a_instobj_target, > .addr = gk20a_instobj_addr, > .size = gk20a_instobj_size, > - .acquire = gk20a_instobj_acquire, >...

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

Hi Martin, I'm not very familiar with the function naming scheme but shouldn't nouveau_fuse_rd32 use the same prefix as xxxx_fuse_ctor instead of nouveau? Christian Le 24/08/2014 23:15, Martin Peres a ?crit : > We will use this subdev to disable temperature reading on cards that did not > get a sensor calibration in the factory. > > Signed-off-by: Martin Peres <martin.peres at...

...ISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + * + * Authors: Martin Peres + */ + +#include "priv.h" + +struct g80_fuse_priv { + struct nouveau_fuse base; + + spinlock_t fuse_enable_lock; +}; + +static u32 +nouveau_fuse_rd32(struct nouveau_object *object, u64 addr) +{ + struct g80_fuse_priv *priv = (void *)object; + unsigned long flags; + u32 fuse_enable, val; + + spin_lock_irqsave(&priv->fuse_enable_lock, flags); + + /* racy if another part of nouveau start writing to this reg */ + fuse_enable = nv_mask(priv, 0...

...* +nvea_grctx_oclass = &(struct nvc0_grctx_oclass) { + .base.handle = NV_ENGCTX(GR, 0xea), + .base.ofuncs = &(struct nouveau_ofuncs) { + .ctor = nvc0_graph_context_ctor, + .dtor = nvc0_graph_context_dtor, + .init = _nouveau_graph_context_init, + .fini = _nouveau_graph_context_fini, + .rd32 = _nouveau_graph_context_rd32, + .wr32 = _nouveau_graph_context_wr32, + }, + .main = nve4_grctx_generate_main, + .mods = nve4_grctx_generate_mods, + .unkn = nve4_grctx_generate_unkn, + .hub = nve4_grctx_init_hub, + .gpc = nve4_grctx_init_gpc, + .icmd = nve4_grctx_init_icmd, + .mthd = nvea_grctx_...

..., 0x00000000, - 0x0000056f, + 0x0000054c, 0x00000007, 0x00000000, - 0x000005b7, + 0x00000594, /* 0x03c4: memx_func_tail */ /* 0x03c4: memx_ts_start */ 0x00000000, @@ -916,7 +916,7 @@ uint32_t gk208_pmu_data[] = { }; uint32_t gk208_pmu_code[] = { - 0x03100ef5, + 0x03000ef5, /* 0x0004: rd32 */ 0xf607a040, 0x04bd000e, @@ -972,7 +972,7 @@ uint32_t gk208_pmu_code[] = { 0x0a98280b, 0x029abb9a, 0x0d0e1cf4, - 0x02557e01, + 0x02457e01, 0xf494bd00, /* 0x00c2: intr_watchdog_next_time */ 0x0a98140e, @@ -1017,7 +1017,7 @@ uint32_t gk208_pmu_code[] = { 0xc0f900cc, 0xf14f484e,...

overall it is for the most part the same as my older version. I cleaned up some copyright things, so that it is more like the others. Also I moved the print about the max speed supported into preinit and did some other minor cleanups in the 3rd commit. Happy testing (and performance for prime offloading setups) Karol Herbst (9): pci: add gk104 variant pci: add gf106 variant pci: implement

...(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +#include <core/xtensa.h> + +u32 +_nouveau_xtensa_rd32(struct nouveau_object *object, u64 addr) +{ + struct nouveau_xtensa *xtensa = (void *)object; + return nv_rd32(xtensa, xtensa->addr + addr); +} + +void +_nouveau_xtensa_wr32(struct nouveau_object *object, u64 addr, u32 data) +{ + struct nouveau_xtensa *xtensa = (void *)object; + nv_wr32(xtensa,...

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

one rename and one enable patch. Tested on hardware and confirmed with traces Karol Herbst (2): pci: Rename g94 to g92 pci/g92: Enable changing pcie link speeds drm/nouveau/include/nvkm/subdev/pci.h | 2 +- drm/nouveau/nvkm/engine/device/base.c | 22 +++++++++++----------- drm/nouveau/nvkm/subdev/pci/Kbuild | 2 +- drm/nouveau/nvkm/subdev/pci/{g94.c => g92.c} |

overall the same as the old stuff, but with better namings and tirivialy improved code here and there Karol Herbst (9): pci: add gk104 variant pci: add gf106 variant pci: implement generic code for PCIe speed change pci: implement pcie speed change for tesla pci: implement pcie speed change on Fermi pci: implement PCIe speed change for kepler+ bios/perf: parse the pci speed from the

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c b/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c index c190043..5c54aa1 100644 --- a/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c +++