search for: bar_vm

Latest patches for GK20A, taking comments received for v3 into account. Changes since v3: - use only pfn_to_page() and page_to_pfn() in GK20A's FB. These functions are present on every arch and the physical address to page frame number conversion is also consistently a shift of PAGE_SHIFT. This part will probably be replaced by something nicer in the future anyway. - fixed a warning on

Hi everyone, Way overdue v2 of the final patches that enable basic GK20A support. Hopefully all the issues raised with v1 have been addressed. Changes since v1: - Use gk20a clock driver by Ben instead of twiddling nv04's - Name new classes after gk20a instead of nvea - Addressed comments about BAR initialization code factorization - Removed non-essential code which only purpose was to avoid

Changes since v2: - Enabled software class - Removed unneeded changes to nouveau_accel_init() - Replaced use of architecture-private pfn_to_dma() and dma_to_pfn() with the portable page_to_phys()/phys_to_page() - Fixed incorrect comment/commit log talking about bytes instead of words Hope this looks good! Once this gets merged the next set will be to use this driver on Jetson and Venice2

Some BARs (like GK20A's) do not support being ioremapped write-combined. Add a boolean property to the BAR structure and handle that case in the Nouveau BO implementation. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/include/subdev/bar.h | 3 +++ drivers/gpu/drm/nouveau/nouveau_bo.c | 17 ++++++++++++----- 2 files changed, 15

...0.c >>>index ca8139b9ab27..0a44459844e3 100644 >>>--- a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c >>>+++ b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c >>>@@ -133,7 +133,7 @@ nvc0_bar_init_vm(struct nvc0_bar_priv *priv, struct >>>nvc0_bar_priv_vm *bar_vm, >>> return 0; >>> } >>> >>>-static int >>>+int >>> nvc0_bar_ctor(struct nouveau_object *parent, struct nouveau_object >>>*engine, >>> struct nouveau_oclass *oclass, void *data, u32 size, >>>...

...dev/bar/nvc0.c b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c index ca8139b9ab27..0a44459844e3 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c +++ b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c @@ -133,7 +133,7 @@ nvc0_bar_init_vm(struct nvc0_bar_priv *priv, struct nvc0_bar_priv_vm *bar_vm, return 0; } -static int +int nvc0_bar_ctor(struct nouveau_object *parent, struct nouveau_object *engine, struct nouveau_oclass *oclass, void *data, u32 size, struct nouveau_object **pobject) @@ -169,7 +169,7 @@ nvc0_bar_ctor(struct nouveau_object *parent, struct nouveau_objec...

.../core/subdev/bar/nvc0.c >>index ca8139b9ab27..0a44459844e3 100644 >>--- a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c >>+++ b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c >>@@ -133,7 +133,7 @@ nvc0_bar_init_vm(struct nvc0_bar_priv *priv, struct >>nvc0_bar_priv_vm *bar_vm, >> return 0; >> } >> >>-static int >>+int >> nvc0_bar_ctor(struct nouveau_object *parent, struct nouveau_object >>*engine, >> struct nouveau_oclass *oclass, void *data, u32 size, >> struct nouveau_object **pobject)...

Hi Ben, I've been working with an mmio-constrained pci hierarchy intended almost solely for nvme devices and switches. Binding nouveau to an NV50-based gpu results in a kernel panic as the device cannot be fully mapped. I've made modifications in nv50 and vmm to unbind the driver from this hierarchy, and modified gf100 assuming it will have the same issue. 1/4 also includes a fix where