leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
c9582455ab
linux/drivers/gpu/drm/nouveau/include/nvkm/subdev/bus.h

25 lines
885 B
C
Raw Normal View History

drm/nouveau/bus: namespace + nvidia gpu names (no binary change) The namespace of NVKM is being changed to nvkm_ instead of nouveau_, which will be used for the DRM part of the driver. This is being done in order to make it very clear as to what part of the driver a given symbol belongs to, and as a minor step towards splitting the DRM driver out to be able to stand on its own (for virt). Because there's already a large amount of churn here anyway, this is as good a time as any to also switch to NVIDIA's device and chipset naming to ease collaboration with them. A comparison of objdump disassemblies proves no code changes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-01-14 04:40:22 +00:00
#ifndef __NVKM_BUS_H__
#define __NVKM_BUS_H__
drm/nouveau/pbus: add a PBUS subdev that hands IRQs to the right subdevs We are going to use PTHERM's IRQs for thermal monitoring but we need to route them first. On nv31-50, PBUS's IRQ line is shared with GPIOs IRQs. It seems like nv10-31 GPIO interruptions aren't well handled. I kept the original behaviour but it is wrong and may lead to an IRQ storm. Since we enable all PBUS IRQs, we need a way to avoid being stormed if we don't handle them. The solution I used was to mask the IRQs that have not been handled. This will also print one message in the logs to let us know. v2: drop the shared intr handler because of was racy v3: style fixes v4: drop a useless construct in the chipset-dependent INTR v5: add BUS to the disable mask v6 (Ben Skeggs): - general tidy to match the rest of the driver's style - nva3->nvc0, nva3 can be serviced just fine with nv50.c, rnndb even notes that the THERM_ALARM bit got left in the hw until fermi anyway.. so, it's not going to conflict - removed the peephole and user stuff, for the moment.. will handle them later if we find a good reason to actually care.. - limited INTR_EN to just what we can handle for now, mostly to prevent spam of unknown status bits (seen on at least nv4x) Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
2012-11-04 00:01:53 +00:00
#include <core/subdev.h>
drm/nouveau/bus: namespace + nvidia gpu names (no binary change) The namespace of NVKM is being changed to nvkm_ instead of nouveau_, which will be used for the DRM part of the driver. This is being done in order to make it very clear as to what part of the driver a given symbol belongs to, and as a minor step towards splitting the DRM driver out to be able to stand on its own (for virt). Because there's already a large amount of churn here anyway, this is as good a time as any to also switch to NVIDIA's device and chipset naming to ease collaboration with them. A comparison of objdump disassemblies proves no code changes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-01-14 04:40:22 +00:00
struct nvkm_bus {
drm/nouveau/bus: convert to new-style nvkm_subdev Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-20 04:54:20 +00:00
const struct nvkm_bus_func *func;
drm/nouveau/bus: cosmetic changes This is purely preparation for upcoming commits, there should be no code changes here. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-20 04:54:06 +00:00
struct nvkm_subdev subdev;
drm/nouveau/pbus: add a PBUS subdev that hands IRQs to the right subdevs We are going to use PTHERM's IRQs for thermal monitoring but we need to route them first. On nv31-50, PBUS's IRQ line is shared with GPIOs IRQs. It seems like nv10-31 GPIO interruptions aren't well handled. I kept the original behaviour but it is wrong and may lead to an IRQ storm. Since we enable all PBUS IRQs, we need a way to avoid being stormed if we don't handle them. The solution I used was to mask the IRQs that have not been handled. This will also print one message in the logs to let us know. v2: drop the shared intr handler because of was racy v3: style fixes v4: drop a useless construct in the chipset-dependent INTR v5: add BUS to the disable mask v6 (Ben Skeggs): - general tidy to match the rest of the driver's style - nva3->nvc0, nva3 can be serviced just fine with nv50.c, rnndb even notes that the THERM_ALARM bit got left in the hw until fermi anyway.. so, it's not going to conflict - removed the peephole and user stuff, for the moment.. will handle them later if we find a good reason to actually care.. - limited INTR_EN to just what we can handle for now, mostly to prevent spam of unknown status bits (seen on at least nv4x) Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
2012-11-04 00:01:53 +00:00
};
drm/nouveau/bus: add interfaces/helpers for sequencer Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-10-15 00:49:39 +00:00
/* interface to sequencer */
drm/nouveau/bus: namespace + nvidia gpu names (no binary change) The namespace of NVKM is being changed to nvkm_ instead of nouveau_, which will be used for the DRM part of the driver. This is being done in order to make it very clear as to what part of the driver a given symbol belongs to, and as a minor step towards splitting the DRM driver out to be able to stand on its own (for virt). Because there's already a large amount of churn here anyway, this is as good a time as any to also switch to NVIDIA's device and chipset naming to ease collaboration with them. A comparison of objdump disassemblies proves no code changes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-01-14 04:40:22 +00:00
struct nvkm_hwsq;
drm/nouveau/bus: convert to new-style nvkm_subdev Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-20 04:54:20 +00:00
int nvkm_hwsq_init(struct nvkm_subdev *, struct nvkm_hwsq **);
drm/nouveau/bus: namespace + nvidia gpu names (no binary change) The namespace of NVKM is being changed to nvkm_ instead of nouveau_, which will be used for the DRM part of the driver. This is being done in order to make it very clear as to what part of the driver a given symbol belongs to, and as a minor step towards splitting the DRM driver out to be able to stand on its own (for virt). Because there's already a large amount of churn here anyway, this is as good a time as any to also switch to NVIDIA's device and chipset naming to ease collaboration with them. A comparison of objdump disassemblies proves no code changes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-01-14 04:40:22 +00:00
int nvkm_hwsq_fini(struct nvkm_hwsq **, bool exec);
void nvkm_hwsq_wr32(struct nvkm_hwsq *, u32 addr, u32 data);
void nvkm_hwsq_setf(struct nvkm_hwsq *, u8 flag, int data);
void nvkm_hwsq_wait(struct nvkm_hwsq *, u8 flag, u8 data);
void nvkm_hwsq_nsec(struct nvkm_hwsq *, u32 nsec);
drm/nouveau/bus: convert to new-style nvkm_subdev Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-20 04:54:20 +00:00
int nv04_bus_new(struct nvkm_device *, int, struct nvkm_bus **);
int nv31_bus_new(struct nvkm_device *, int, struct nvkm_bus **);
int nv50_bus_new(struct nvkm_device *, int, struct nvkm_bus **);
int g94_bus_new(struct nvkm_device *, int, struct nvkm_bus **);
int gf100_bus_new(struct nvkm_device *, int, struct nvkm_bus **);
drm/nouveau/pbus: add a PBUS subdev that hands IRQs to the right subdevs We are going to use PTHERM's IRQs for thermal monitoring but we need to route them first. On nv31-50, PBUS's IRQ line is shared with GPIOs IRQs. It seems like nv10-31 GPIO interruptions aren't well handled. I kept the original behaviour but it is wrong and may lead to an IRQ storm. Since we enable all PBUS IRQs, we need a way to avoid being stormed if we don't handle them. The solution I used was to mask the IRQs that have not been handled. This will also print one message in the logs to let us know. v2: drop the shared intr handler because of was racy v3: style fixes v4: drop a useless construct in the chipset-dependent INTR v5: add BUS to the disable mask v6 (Ben Skeggs): - general tidy to match the rest of the driver's style - nva3->nvc0, nva3 can be serviced just fine with nv50.c, rnndb even notes that the THERM_ALARM bit got left in the hw until fermi anyway.. so, it's not going to conflict - removed the peephole and user stuff, for the moment.. will handle them later if we find a good reason to actually care.. - limited INTR_EN to just what we can handle for now, mostly to prevent spam of unknown status bits (seen on at least nv4x) Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
2012-11-04 00:01:53 +00:00
#endif
Reference in New Issue Copy Permalink