Displaying 20 results from an estimated 700 matches similar to: "[PATCH] ltc/gf100: use more reasonable timeout value"
2015 Sep 03
2
[PATCH 2/3] ltc/gf100: add flush/invalidate functions
On 3 September 2015 at 16:42, Alexandre Courbot <acourbot at nvidia.com> wrote:
> Allow clients to manually flush and invalidate L2. This will be useful
> for Tegra systems for which we want to write instmem using the CPU.
>
> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com>
> ---
> drm/nouveau/include/nvkm/subdev/ltc.h | 1 +
>
2015 Sep 03
2
[PATCH 2/3] ltc/gf100: add flush/invalidate functions
On 3 September 2015 at 17:13, Alexandre Courbot <gnurou at gmail.com> wrote:
> On Thu, Sep 3, 2015 at 4:09 PM, Ben Skeggs <skeggsb at gmail.com> wrote:
>> On 3 September 2015 at 16:42, Alexandre Courbot <acourbot at nvidia.com> wrote:
>>> Allow clients to manually flush and invalidate L2. This will be useful
>>> for Tegra systems for which we want to
2016 Jan 15
0
[PATCH] ltc/gm107: wait on relevant bit in gm107_ltc_cbc_wait
Patch "ltc/gm107: use nvkm_mask to set cbc_ctrl1" sets the 3rd bit
of the CTRL1 register instead of writing it entirely in
gm107_ltc_cbc_clear(). As a counterpart, gm107_ltc_cbc_wait() must also
be modified to wait on that single bit only, otherwise a timeout may
occur if some other bit of that register is set. This happened at least
on GM206 when running glmark2-drm.
While we are at
2015 Sep 03
3
[PATCH 0/3] New instmem implementation for Tegra
Due to the lack of implicit synchronization between CPU and GPU on Tegra systems
(like what PCI provides for dGPUs), the 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
2017 Jul 29
0
[PATCH] nouveau: Fix declarations with incorrect variables.
Signed-off by: Rosen Penev <rosenp at gmail.com>
---
drm/nouveau/dispnv04/disp.h | 4 ++--
drm/nouveau/dispnv04/hw.h | 2 +-
drm/nouveau/nouveau_bo.h | 2 +-
drm/nouveau/nouveau_display.h | 4 ++--
drm/nouveau/nvkm/engine/dma/user.h | 2 +-
drm/nouveau/nvkm/subdev/clk/pll.h | 2 +-
drm/nouveau/nvkm/subdev/fb/priv.h | 2 +-
2019 Sep 16
0
[PATCH 04/11] drm/nouveau: gp10b: Add custom L2 cache implementation
On Mon, Sep 16, 2019 at 04:35:30PM +0100, Ben Dooks wrote:
> On 16/09/2019 16:04, Thierry Reding wrote:
> > From: Thierry Reding <treding at nvidia.com>
> >
> > There are extra registers that need to be programmed to make the level 2
> > cache work on GP10B, such as the stream ID register that is used when an
> > SMMU is used to translate memory addresses.
2019 Sep 16
1
[PATCH 04/11] drm/nouveau: gp10b: Add custom L2 cache implementation
On Mon, Sep 16, 2019 at 05:49:46PM +0200, Thierry Reding wrote:
> On Mon, Sep 16, 2019 at 04:35:30PM +0100, Ben Dooks wrote:
> > On 16/09/2019 16:04, Thierry Reding wrote:
> > > From: Thierry Reding <treding at nvidia.com>
> > >
> > > There are extra registers that need to be programmed to make the level 2
> > > cache work on GP10B, such as the
2015 Oct 26
2
[PATCH] instmem/gk20a: exclusively acquire instobjs
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
2015 Nov 11
0
[PATCH] instmem/gk20a: use DMA API CPU mapping
On 11/11/2015 06:07 PM, Alexandre Courbot wrote:
> Commit 69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access")
> tried to be smart while using the DMA-API by managing the CPU mappings of
> buffers allocated with the DMA-API by itself. In doing so, it relied
> on dma_to_phys() which is an architecture-private function not
> available everywhere. This broke the
2015 Nov 04
0
[PATCH] instmem/gk20a: exclusively acquire instobjs
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
2017 Feb 23
0
[PATCH] drm/nouveau: gk20a: Turn instmem lock into mutex
On Mon, Jan 30, 2017 at 09:03:07PM +0100, Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
>
> The gk20a implementation of instance memory uses vmap()/vunmap() to map
> memory regions into the kernel's virtual address space. These functions
> may sleep, so protecting them by a spin lock is not safe. This triggers
> a warning if the
2017 Jan 30
2
[PATCH] drm/nouveau: gk20a: Turn instmem lock into mutex
From: Thierry Reding <treding at nvidia.com>
The gk20a implementation of instance memory uses vmap()/vunmap() to map
memory regions into the kernel's virtual address space. These functions
may sleep, so protecting them by a spin lock is not safe. This triggers
a warning if the DEBUG_ATOMIC_SLEEP Kconfig option is enabled. Fix this
by using a mutex instead.
Signed-off-by: Thierry Reding
2017 Feb 24
1
[PATCH] drm/nouveau: gk20a: Turn instmem lock into mutex
On 02/24/2017 01:20 AM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Mon, Jan 30, 2017 at 09:03:07PM +0100, Thierry Reding wrote:
>> From: Thierry Reding <treding at nvidia.com>
>>
>> The gk20a implementation of instance memory uses vmap()/vunmap() to map
>> memory regions into the kernel's virtual address space. These functions
>>
2015 Nov 11
2
[PATCH] instmem/gk20a: use DMA API CPU mapping
Commit 69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access")
tried to be smart while using the DMA-API by managing the CPU mappings of
buffers allocated with the DMA-API by itself. In doing so, it relied
on dma_to_phys() which is an architecture-private function not
available everywhere. This broke the build on several architectures.
Since there is no reliable and portable
2016 Feb 19
0
[PATCH v2 1/4] subdev/iccsense: add new subdev for power sensors
From: Martin Peres <martin.peres at free.fr>
Signed-off-by: Karol Herbst <nouveau at karolherbst.de>
---
drm/nouveau/include/nvkm/core/device.h | 83 +++++++++----------
drm/nouveau/include/nvkm/subdev/iccsense.h | 10 +++
drm/nouveau/nvkm/core/subdev.c | 83 +++++++++----------
drm/nouveau/nvkm/engine/device/base.c | 124 +++++++++++++++--------------
2016 Feb 20
0
[PATCH v4 1/6] subdev/iccsense: add new subdev for power sensors
From: Martin Peres <martin.peres at free.fr>
Signed-off-by: Karol Herbst <nouveau at karolherbst.de>
---
drm/nouveau/include/nvkm/core/device.h | 83 +++++++++----------
drm/nouveau/include/nvkm/subdev/iccsense.h | 10 +++
drm/nouveau/nvkm/core/subdev.c | 83 +++++++++----------
drm/nouveau/nvkm/engine/device/base.c | 124 +++++++++++++++--------------
2016 Feb 17
0
[PATCH 1/2] power sensor support
From: Martin Peres <martin.peres at free.fr>
v2 (Karol Herbst <nouveau at karolherbst.de>):
fix power_rail mapping for ina3221
minor code cleanups
Signed-off-by: Karol Herbst <nouveau at karolherbst.de>
---
drm/nouveau/include/nvkm/core/device.h | 83 +++++++-------
drm/nouveau/include/nvkm/subdev/bios/extdev.h | 4 +
2016 Mar 03
0
[PATCH] instmem/gk20a: add write barrier when releasing DMA object
When using the DMA-API for instmem, we may obtain a write-combined
mapping. For such cases, add a write barrier in
gk20a_instobj_release_dma() to make sure that all writes have reached
memory at this time.
Signed-off-by: Alexandre Courbot <acourbot at nvidia.com>
---
drm/nouveau/nvkm/subdev/instmem/gk20a.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
2019 Nov 02
13
[PATCH v2 0/9] drm/nouveau: Various fixes for GP10B
From: Thierry Reding <treding at nvidia.com>
Hi Ben,
here's a revised subset of the patches I had sent out a couple of weeks
ago. I've reworked the BAR2 accesses in the way that you had suggested,
which at least for GP10B turned out to be fairly trivial to do. I have
not looked in detail at this for GV11B yet, but a cursory look showed
that BAR2 is accessed in more places, so the
2019 Dec 09
11
[PATCH v3 0/9] drm/nouveau: Various fixes for GP10B
From: Thierry Reding <treding at nvidia.com>
Hi Ben,
here's a revised subset of the patches I had sent out a couple of weeks
ago. I've reworked the BAR2 accesses in the way that you had suggested,
which at least for GP10B turned out to be fairly trivial to do. I have
not looked in detail at this for GV11B yet, but a cursory look showed
that BAR2 is accessed in more places, so the