search for: instobj

On Wed, Nov 11, 2015 at 9:19 AM, Ben Skeggs <skeggsb at gmail.com> wrote: > On 11/09/2015 05:37 PM, Alexandre Courbot wrote: >> The LRU list used for recycling CPU mappings was handling concurrency >> very poorly. For instance, if an instobj was acquired twice before being >> released once, it would end up into the LRU list even though there is >> still a client accessing it. >> >> This patch fixes this by properly counting how many clients are >> currently using a given instobj. > Out of curiosity, whi...

On Thu, Nov 5, 2015 at 6:19 AM, Ben Skeggs <skeggsb at gmail.com> wrote: > On 10/26/2015 03:54 PM, Alexandre Courbot wrote: >> Although I would not have expected this to happen, we seem to run into >> race conditions if instobjs are accessed concurrently. Use a global lock >> for safety. > I wouldn't expect this to be an issue either. > > Before merging such a large hammer of a fix, I'd strongly prefer to see > at least a better justification for why this is happening rather than > potentially...

Although I would not have expected this to happen, we seem to run into race conditions if instobjs are accessed concurrently. Use a global lock for safety. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/instmem/gk20a.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/instmem/gk20a.c b/drm/n...

On 10/26/2015 03:54 PM, Alexandre Courbot wrote: > Although I would not have expected this to happen, we seem to run into > race conditions if instobjs are accessed concurrently. Use a global lock > for safety. I wouldn't expect this to be an issue either. Before merging such a large hammer of a fix, I'd strongly prefer to see at least a better justification for why this is happening rather than potentially papering over a larger issu...

The LRU list used for recycling CPU mappings was handling concurrency very poorly. For instance, if an instobj was acquired twice before being released once, it would end up into the LRU list even though there is still a client accessing it. This patch fixes this by properly counting how many clients are currently using a given instobj. While at it, we also raise errors when inconsistencies are detected,...

This should fix some unaligned access warnings. This is also likely to fix non-descript issues on nv30/nv34 as a result of incorrect channel setup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96836 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drm/nouveau/nvkm/engine/gr/nv30.c | 4 ++-- drm/nouveau/nvkm/engine/gr/nv34.c | 4 ++-- 2 files changed, 4 insertions(+), 4

On 08/12/2023 10:46, Thierry Reding wrote: > From: Thierry Reding <treding at nvidia.com> > > Commit 12c9b05da918 ("drm/nouveau/imem: support allocations not > preserved across suspend") uses container_of() to cast from struct > nvkm_memory to struct nvkm_instobj, assuming that all instance objects > are derived from struct nvkm_instobj. For the gk20a family that's not > the case and they are derived from struct nvkm_memory instead. This > causes some subtle data corruption (nvkm_instobj.preserve ends up > mapping to gk20a_instobj.vaddr) tha...

From: Thierry Reding <treding at nvidia.com> Commit 12c9b05da918 ("drm/nouveau/imem: support allocations not preserved across suspend") uses container_of() to cast from struct nvkm_memory to struct nvkm_instobj, assuming that all instance objects are derived from struct nvkm_instobj. For the gk20a family that's not the case and they are derived from struct nvkm_memory instead. This causes some subtle data corruption (nvkm_instobj.preserve ends up mapping to gk20a_instobj.vaddr) that causes a NULL poin...

On 11/09/2015 05:37 PM, Alexandre Courbot wrote: > The LRU list used for recycling CPU mappings was handling concurrency > very poorly. For instance, if an instobj was acquired twice before being > released once, it would end up into the LRU list even though there is > still a client accessing it. > > This patch fixes this by properly counting how many clients are > currently using a given instobj. Out of curiosity, which instobjs are being ac...

...anged, 62 insertions(+), 92 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/instmem/gk20a.c b/drm/nouveau/nvkm/subdev/instmem/gk20a.c index 681b2541229a..4c20fec64d96 100644 --- a/drm/nouveau/nvkm/subdev/instmem/gk20a.c +++ b/drm/nouveau/nvkm/subdev/instmem/gk20a.c @@ -56,9 +56,6 @@ struct gk20a_instobj { /* CPU mapping */ u32 *vaddr; - struct list_head vaddr_node; - /* How many clients are using vaddr? */ - u32 use_cpt; }; #define gk20a_instobj(p) container_of((p), struct gk20a_instobj, memory) @@ -68,7 +65,6 @@ struct gk20a_instobj { struct gk20a_instobj_dma { struct gk20a_instobj b...

Am Samstag, den 01.02.2014, 18:28 -0500 schrieb Ilia Mirkin: > On Sat, Feb 1, 2014 at 8:40 AM, Lucas Stach <dev at lynxeye.de> wrote: > > Am Samstag, den 01.02.2014, 12:16 +0900 schrieb Alexandre Courbot: > >> Add a clumsy-but-working FB support for GK20A. This chip only uses system > >> memory, so we allocate a big chunk using CMA and let the existing memory >

...MEM, 0x50), > + .base.ofuncs = &(struct nouveau_ofuncs) { > + .ctor = gk20a_instmem_ctor, > + .dtor = _nouveau_instmem_dtor, > + .init = gk20a_instmem_init, > + .fini = gk20a_instmem_fini, > + }, > + .instobj = &nv50_instobj_oclass.base, > +}.base; > -- > 1.9.1 > > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau

...letions(-) > > diff --git a/drm/nouveau/nvkm/subdev/instmem/gk20a.c b/drm/nouveau/nvkm/subdev/instmem/gk20a.c > index 681b2541229a..4c20fec64d96 100644 > --- a/drm/nouveau/nvkm/subdev/instmem/gk20a.c > +++ b/drm/nouveau/nvkm/subdev/instmem/gk20a.c > @@ -56,9 +56,6 @@ struct gk20a_instobj { > > /* CPU mapping */ > u32 *vaddr; > - struct list_head vaddr_node; > - /* How many clients are using vaddr? */ > - u32 use_cpt; > }; > #define gk20a_instobj(p) container_of((p), struct gk20a_instobj, memory) > > @@ -68,7 +65,6 @@ struct gk20a_instobj { &g...

...he instmem implementation of GK20A/GM20B relied on the slow, legacy PRAMIN so that CPU accesses used the same path as GPU, making sure we see the same data on both ends. The recent Nouveau refactoring introduced acquire/release functions on instmem that help us understand the bounds of accesses to instobjs. We can now use these to perform any needed synchronization, and use direct CPU accesses. For Tegra, provided that we use a write-combined CPU mapping, we just need to make sure the GPU L2 cache is flushed before we access instobjs and invalidated after. This patch series first introduces flush/i...

...eau_oclass * +gk20a_instmem_oclass = &(struct nouveau_instmem_impl) { + .base.handle = NV_SUBDEV(INSTMEM, 0x50), + .base.ofuncs = &(struct nouveau_ofuncs) { + .ctor = gk20a_instmem_ctor, + .dtor = _nouveau_instmem_dtor, + .init = gk20a_instmem_init, + .fini = gk20a_instmem_fini, + }, + .instobj = &nv50_instobj_oclass.base, +}.base; -- 1.9.1

...ing. + */ + #include <subdev/fb.h> #include <core/mm.h> #include <core/device.h> #ifdef __KERNEL__ #include <linux/dma-attrs.h> +#include <linux/iommu.h> +#include <nouveau_platform.h> #endif #include "priv.h" @@ -36,18 +56,51 @@ struct gk20a_instobj_priv { struct nvkm_mem *mem; /* Pointed by mem */ struct nvkm_mem _mem; +}; + +/* + * Used for objects allocated using the DMA API + */ +struct gk20a_instobj_dma { + struct gk20a_instobj_priv base; + void *cpuaddr; dma_addr_t handle; struct dma_attrs attrs; struct nvkm_mm_node r; };...

...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 <subdev/fb.h> +#include <core/mm.h> +#include <core/device.h> + +#include "priv.h" + +struct gk20a_instobj_priv { + struct nvkm_instobj base; + /* Must be second member here - see nouveau_gpuobj_map_vm() */ + struct nvkm_mem *mem; + /* Pointed by mem */ + struct nvkm_mem _mem; + void *cpuaddr; + dma_addr_t handle; + struct nvkm_mm_node r; +}; + +struct gk20a_instmem_priv { + struct nvkm_instmem base; +...

Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into nouveau_display.c and nv84_fence.c. Original cover letter: Patches 1-3 make the presence of a RAM device optional, and remove GK20A's dummy RAM driver we were using so far. On chips using shared memory, such a device can confuse the driver into moving objects where there is no need to, and can trick

https://bugs.freedesktop.org/show_bug.cgi?id=96836 Bug ID: 96836 Summary: Kernel unaligned access at TPC[105d9fb4] nvkm_instobj_wr32+0x14/0x20 [nouveau] Product: xorg Version: unspecified Hardware: SPARC OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at lists.freedeskt...

Hi, This series includes some pieces of fixes to complete the GK20A power on/off sequences and add the suspend/resume support. The patches 1/11 - 4/11 are based on the linux-next-20141219. The patches 5/11 - 11/11 are based on the branch "linux-3.19" of Ben Skeggs's tree (http://cgit.freedesktop.org/~darktama/nouveau). Thanks, Vince Vince Hsu (4): (linux-next-20141219) ARM: