On Wed, Feb 17, 2021 at 1:20 AM Diego Viola wrote:
>
> This code times out on GP108, probably because the BIOS puts it into a
> bad state.
>
> Since we reset the PMU on driver load anyway, we are at no risk from
> missing a response from it since we are not waiting for one to begin
> with.
This
On Fri, Sep 20, 2019 at 9:11 AM Dave Airlie wrote:
>
> > Hmm. My merge isn't identical to that. It's close though. Different
> > order for one #define which might be just from you and me merging
> > different directions.
> >
> > But I also ended up removing the .gem_prime_export initialization to
PRIME buffers should be imported using the DMA device. To this end, use
a custom import function that mimics drm_gem_prime_import_dev(), but
passes the correct device.
Fixes: 119f5173628aa ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Alexandre Courbot
---
d
On Wed, Jul 24, 2019 at 2:49 PM CK Hu wrote:
>
> Hi, Alexandre:
>
> On Tue, 2019-07-23 at 14:34 +0900, Alexandre Courbot wrote:
> > This driver requires imported PRIME buffers to appear contiguously in
> > its IO address space. Make sure this is the case by setting the
) Using the correct DMA device when importing PRIME buffers,
2) Setting a more suitable DMA segment size on the DMA device than the
default 64KB.
Changes since v1:
- Split into two patches,
- Fixed an error path that would have returned 0.
Alexandre Courbot (2):
drm/mediatek: use correct device
This driver requires imported PRIME buffers to appear contiguously in
its IO address space. Make sure this is the case by setting the maximum
DMA segment size to a more suitable value than the default 64KB.
Signed-off-by: Alexandre Courbot
Reviewed-by: Tomasz Figa
---
drivers/gpu/drm/mediatek
This driver requires imported PRIME buffers to appear contiguously in
its IO address space. Make sure this is the case by setting the maximum
DMA segment size to a better value than the default 64K on the DMA
device, and use said DMA device when importing PRIME buffers.
Signed-off-by: Alexandre
On Sat, Mar 11, 2017 at 5:55 AM, Dan Carpenter <dan.carpen...@oracle.com> wrote:
> Hello Alexandre Courbot,
>
> The patch 5429f82f3415: "drm/nouveau/secboot: add
> gp102/gp104/gp106/gp107 support" from Jan 26, 2017, leads to the
> following static checker warni
rm that last point). Tested this patch and it
seems to work like a charm.
Reviewed-by: Alexandre Courbot <acour...@nvidia.com>
Tested-by: Alexandre Courbot <acour...@nvidia.com>
Thanks,
Thierry
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
b/drivers/gpu
On 12/17/2016 01:16 AM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Wed, Dec 14, 2016 at 11:08:20PM +0900, Alexandre Courbot wrote:
>> Forgot to add the most relevant list for this issue (linux-next).
>>
>> Stephen, maybe you will want to temporar
Forgot to add the most relevant list for this issue (linux-next).
Stephen, maybe you will want to temporarily revert this patch until this
is cleared? This probably affects other users than DRM.
On 12/13/2016 04:14 PM, Alexandre Courbot wrote:
> Hi Matthew,
>
> Trying the lat
Hi Matthew,
Trying the latest -next on the Jetson TK1 board (with two different DRM
devices and display and render), I noticed that the GPU device probe
always failed with error -ENOSPC. After investigating I figured out that
this was due to the minor device allocation failing when a second DRM
On Wed, Dec 7, 2016 at 6:53 PM, Michel Dänzer wrote:
> On 07/12/16 06:39 PM, Alexandre Courbot wrote:
>> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin wrote:
>>> That's right -- nouveau currently requires 4k page sizes to work. This is a
>>> software limitation
On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin wrote:
> That's right -- nouveau currently requires 4k page sizes to work. This is a
> software limitation, not a hardware one though.
Looking at the trace I wonder - is the limitation in Nouveau or in TTM?
>
>
> On Dec 1, 2016 5:13 PM, "Jeremy
On 11/08/2016 06:07 PM, Erik Faye-Lund wrote:
> On Tue, Nov 8, 2016 at 8:50 AM, Alexandre Courbot
> wrote:
>> Add FB modifiers to allow user-space to specify that a surface is in one
>> of the two tiling formats supported by Tegra chips, and add support in
>> the tegrad
is intended to replace the dedicated IOCTL enabled
by TEGRA_STAGING and to provide a non-staging alternative to that
solution.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/tegra/drm.c | 2 ++
drivers/gpu/drm/tegra/fb.c| 23 +++---
include/uapi/drm/drm_fourcc.h | 45
On Mon, Oct 31, 2016 at 3:35 PM, Christophe JAILLET
wrote:
> 'iommu_domain_alloc()' returns NULL in case of error, not an error pointer.
> So test it accordingly.
>
> Signed-off-by: Christophe JAILLET
Reviewed-by: Alexandre Courbot
Indeed. Thanks for the fix!
On Mon, Oct 31, 2016 at 1:34 AM, Ilia Mirkin wrote:
> Hi Alex,
>
> As you're well-aware, your commit
> 8539b37acef73949861a16808b60cb8b5b9b3bab (drm/nouveau/gr: use
> NVIDIA-provided external firmwares) broke tons of existing setups for
> people who were using extracted firmware files (stored in
On Mon, Oct 17, 2016 at 5:12 AM, Ard Biesheuvel
wrote:
> On 7 October 2016 at 09:12, Alexandre Courbot wrote:
>> On Fri, Oct 7, 2016 at 12:49 AM, Ard Biesheuvel
>> wrote:
>>> This v4 is now a 3 piece series (since v4), after Alexandre pointed out that
>>>
es, which is not
> defined on all architectures
> v2: replace incorrect comparison of dma_addr_t type var against NULL
>
> Ard Biesheuvel (3):
> drm/nouveau: set streaming DMA mask early
> drm/nouveau/fb/gf100: defer DMA mapping of scratch page to oneinit()
> hook
> drm/nouveau/fb/nv50: defer DMA mapping of scratch page to oneinit()
> hook
The series,
Reviewed-by: Alexandre Courbot
Thanks!
On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel
wrote:
> The 100c08 scratch page is mapped using dma_map_page() before the TTM
> layer has had a chance to set the DMA mask. This means we are still
> running with the default of 32 when this code executes, and this causes
> problems for platforms
On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel
wrote:
> The 100c10 scratch page is mapped using dma_map_page() before the TTM
> layer has had a chance to set the DMA mask. This means we are still
> running with the default of 32 when this code executes, and this causes
> problems for platforms
On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel
wrote:
> Some subdevices (i.e., fb/nv50.c and fb/gf100.c) map a scratch page using
> dma_map_page() way before the TTM layer has had a chance to set the DMA
> mask. This may prevent the driver from loading at all on platforms whose
> system memory
On Sat, Sep 24, 2016 at 6:06 AM, Christophe JAILLET
wrote:
> If 'ioremap()' returns 0, 'gm20b_tegra_read_wpr()' will return 0 as well,
> which means success.
> Return -ENOMEM instead
Reviewed-by: Alexandre Courbot
>
> Signed-off-by: Christophe JAILLET
> ---
> Not sure tha
On 09/14/2016 07:07 AM, Kristian H. Kristensen wrote:
> The only current user of this open codes the ioctl. Let's add an entry
> point for this to libdrm.
Tested-by: Alexandre Courbot
Replaced one custom (staging) ioctl on Tegra with FB modifiers, noticed
this was missing!
>
>
Patch 3d50d4dcb0 exposed the CPU address of DMA-allocated pages as
returned by dma_alloc_coherent because Nouveau on Tegra needed it.
This is not required anymore - as there were no other users for it,
remove it and save some memory for everyone.
Signed-off-by: Alexandre Courbot
---
drivers
tement S;
> @@
>
> *e = iommu_domain_alloc(...);
> if (IS_ERR(e)) S
>
> Signed-off-by: Amitoj Kaur Chawla
Reviewed-by: Alexandre Courbot
On Sat, Jul 16, 2016 at 4:45 AM, Ard Biesheuvel
wrote:
> On 15 July 2016 at 07:52, Alexandre Courbot wrote:
>> On Fri, Jul 8, 2016 at 1:59 AM, Ard Biesheuvel
>> wrote:
>>> The 100c08 scratch page is mapped using dma_map_page() before the TTM
>>> layer has
On Fri, Jul 8, 2016 at 1:59 AM, Ard Biesheuvel
wrote:
> The 100c08 scratch page is mapped using dma_map_page() before the TTM
> layer has had a chance to set the DMA mask. This means we are still
> running with the default of 32 when this code executes, and this causes
> problems for platforms
On Wed, Jul 6, 2016 at 7:56 AM, Joe Perches wrote:
> On Tue, 2016-07-05 at 15:36 -0700, Markus Mayer wrote:
>> On 5 July 2016 at 15:14, Joe Perches wrote:
>> > On Tue, 2016-07-05 at 13:47 -0700, Markus Mayer wrote:
>> > > This series introduces a family of generic string case conversion
>> > >
On Mon, Jul 4, 2016 at 4:19 PM, wrote:
> From: Wei Yongjun
>
> data allocated with devm_kzalloc should not be freed using kfree,
> because doing so causes a dangling pointer, and a subsequent
> double free, use devm_kfree instead.
>
> Signed-off-by: Wei Yongjun
> ---
>
On Mon, Jul 4, 2016 at 4:45 PM, Dan Carpenter
wrote:
> "brick" is allocated with devm_kzalloc() so freeing it with kfree()
> leads to a double free. We can just delete it.
That makes perfect sense.
Reviewed-by: Alexandre Courbot
On Wed, Jul 6, 2016 at 9:23 PM, wrote:
> From: Wei Yongjun
>
> In case of error, the function iommu_domain_alloc() returns NULL
> pointer not ERR_PTR(). The IS_ERR() test in the return value check
> should be replaced with NULL test.
Reviewed-by: Alexandre Courbot
Thanks!
On Mon, Jul 4, 2016 at 10:37 AM, Alexandre Courbot wrote:
> On Sun, Jul 3, 2016 at 12:21 AM, Markus Mayer
> wrote:
>> On 1 July 2016 at 18:18, Alexandre Courbot wrote:
>>> On Fri, Jul 1, 2016 at 8:50 AM, Markus Mayer wrote:
>>>> Call strtolower() rather t
On Sun, Jul 3, 2016 at 3:18 PM, Christophe JAILLET
wrote:
> This is likely that checking 'gr3d->clk_secondary' instead of 'gr3d->clk'
> is expected here.
Very likely indeed.
Reviewed-by: Alexandre Courbot
Thanks!
On Sun, Jul 3, 2016 at 12:21 AM, Markus Mayer
wrote:
> On 1 July 2016 at 18:18, Alexandre Courbot wrote:
>> On Fri, Jul 1, 2016 at 8:50 AM, Markus Mayer wrote:
>>> Call strtolower() rather than walking the string explicitly to convert
>>> it to lowercase.
>>
On Fri, Jul 1, 2016 at 8:50 AM, Markus Mayer wrote:
> Call strtolower() rather than walking the string explicitly to convert
> it to lowercase.
>
> Signed-off-by: Markus Mayer
> ---
> drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
>
d seem
> to take precedence, so revert this change until the real underlying
> problem can be fixed.
>
> Signed-off-by: Robin Murphy
> ---
>
> Alex, Ben, Dave,
>
> I know Alex was looking into this, but since we're nearly at -rc6 already
> it looks like the only thing to do for 4.6 is pick the lesser of two evils...
Hi Robin,
Sorry for the delayed reply - I was offline last week.
You are right, so let's pick this patch for now.
Reviewed-by: Alexandre Courbot
On 04/11/2016 04:22 PM, Alexandre Courbot wrote:
> Hi Robin,
>
> On 04/09/2016 03:46 AM, Robin Murphy wrote:
>> Hi Alex,
>>
>> On 08/04/16 05:47, Alexandre Courbot wrote:
>>> Hi Robin,
>>>
>>> On 04/07/2016 08:50 PM, Robin Murphy wrote:
&g
On 04/11/2016 04:22 PM, Alexandre Courbot wrote:
> ... or maybe we could just unconditionally sync all buffers and let the
> DMA API abstract this away. My concern is that on coherent architectures
> we would still need to loop over all the pages for nothing, as I don't
> think the l
Hi Robin,
On 04/09/2016 03:46 AM, Robin Murphy wrote:
> Hi Alex,
>
> On 08/04/16 05:47, Alexandre Courbot wrote:
>> Hi Robin,
>>
>> On 04/07/2016 08:50 PM, Robin Murphy wrote:
>>> Hello,
>>>
>>> With 4.6-rc2 (and -rc1) I'
Hi Robin,
On 04/07/2016 08:50 PM, Robin Murphy wrote:
> Hello,
>
> With 4.6-rc2 (and -rc1) I'm seeing Nouveau blowing up at boot, from the
> look of it by dereferencing some offset from NULL inside
> nouveau_fbcon_imageblit(). My setup is an old XFX 7600GT card plugged
> into an ARM Juno r1
The default DMA mask covers a 32 bits address range, but devices can
address more than that. Set the DMA mask to the actual addressable range
to avoid the use of unneeded bounce buffers.
Signed-off-by: Alexandre Courbot
---
Changes since v1:
- set the mask at the bus level so of_dma_configure
operations are set.
Suggested-by: Thierry Reding
Signed-off-by: Alexandre Courbot
---
Changes since v2:
- Re-roll with patch 2/2 for completeness
drivers/gpu/host1x/bus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index c2e7fba370bb
On Thu, Feb 25, 2016 at 2:34 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> The error cleanup paths aren't quite correct and will crash upon
> deferred probe.
>
> Cc: stable at vger.kernel.org # v4.3+
> Signed-off-by: Thierry Reding
Reviewed-by: Alexandre Courbot
operations are set.
Suggested-by: Thierry Reding
Signed-off-by: Alexandre Courbot
---
drivers/gpu/host1x/bus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index c2e7fba370bb..c27858ae0552 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers
On 02/24/2016 01:04 AM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Feb 23, 2016 at 03:25:54PM +0900, Alexandre Courbot wrote:
>> The default DMA mask covers a 32 bits address range, but tegradrm can
>> address more than that. Set the DMA mask to the act
On 02/24/2016 12:28 AM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Feb 23, 2016 at 03:25:53PM +0900, Alexandre Courbot wrote:
>> The current settings leaves the DRM device's dma_ops field NULL, which
>> makes it use the dummy DMA ops on arm64 and return
The default DMA mask covers a 32 bits address range, but tegradrm can
address more than that. Set the DMA mask to the actual addressable range
to avoid the use of unneeded bounce buffers.
Signed-off-by: Alexandre Courbot
---
Thierry, I am not absolutely sure whether the size is correct
() is called and sets the default ioswtlb DMA ops.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/tegra/drm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index d347188bf8f4..bc0555adecaf 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b
Hi everyone,
I know, it's about f**king time and I apologize for the time it took us
to finally put this together. m(__)m
I have pushed two git branches which enable GM200 and GM204 (GM206 to
follow soon) owners to finally load NVIDIA-provided signed firmware and
start GR:
-
On Tue, Nov 17, 2015 at 7:02 PM, Daniel Vetter wrote:
> On Thu, Nov 12, 2015 at 04:09:56PM +0900, Alexandre Courbot wrote:
>> drm_gem_object_unreference() now expects obj->dev->struct_mutex to be
>> held. Use the newly-introduced drm_gem_object_unreference_unlocked()
>
correctly.
Signed-off-by: Alexandre Courbot
Reviewed-by: Daniel Vetter
---
v2: fix commit log according to Daniel's comments, add review tag.
drivers/gpu/drm/tegra/drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
e call the SET_TILING ioctl.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/tegra/drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index cc48334ef164..c0ae89865958 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/g
On Tue, Oct 20, 2015 at 3:39 AM, Russell King - ARM Linux
wrote:
> On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote:
>> Hello,
>>
>> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
>> > It's a bit ironic that you've chosen GPIO as an example there. The
Patch has landed in -rc7, thanks David!
On Fri, Aug 14, 2015 at 12:49 PM, Alexandre Courbot wrote:
> On Wed, Aug 12, 2015 at 6:59 PM, Afzal Mohammed
> wrote:
>> Hi,
>>
>> On Wed, Aug 12, 2015 at 04:40:57PM +0900, Alexandre Courbot wrote:
>>
>>> Gr
On Wed, Aug 12, 2015 at 6:59 PM, Afzal Mohammed
wrote:
> Hi,
>
> On Wed, Aug 12, 2015 at 04:40:57PM +0900, Alexandre Courbot wrote:
>
>> Great, thanks. Are you also on an optimus configuration with the
>> NVIDIA card being the secondary GPU?
>
> Spec says graph
2015-08-12 16:37 GMT+09:00 Afzal Mohammed :
> Hi,
>
> On Wed, Aug 12, 2015 at 04:12:15PM +0900, Alexandre Courbot wrote:
>
>> Could you let me know what your card is? It may be useful to know the
>> range of affected cards when trying to fix this.
>
> grep
On Wed, Aug 12, 2015 at 3:00 PM, Afzal Mohammed
wrote:
> Hi,
>
> On Wed, Aug 12, 2015 at 01:17:38PM +0900, Alexandre Courbot wrote:
>> This reverts commit 1addc1264852
>>
>> This commit seems to cause crashes in gk104_fifo_intr_runlist() by
>> returning 0xbad0
Signed-off-by: Alexandre Courbot
---
David, it would be great if this could be merged for 4.2 since lots of
users could potentially experience this issue. Thanks!
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 29 +++-
1 file changed, 8 insertions(+), 21 deletions(-)
diff
On Tue, Jul 14, 2015 at 3:45 AM, Andrew Chew wrote:
> I apologize for my ignorance. In digging through nouveau, I've become
> a bit confused regarding the relationship between virtual address
> allocations and nouveau bo's.
>
> From my reading of the code, it seems that a nouveau_bo really
>
issue was detected by using the Coccinelle software.
The fix is correct, but the subject looks weird.
"GPU-DRM-Tegra:"should be "drm/tegra:".
Otherwise,
Acked-by: Alexandre Courbot
Maybe Thierry can take it through his tree once this issue is addressed?
Hi Thierry,
On Mon, Jun 29, 2015 at 10:30 PM, Thierry Reding wrote:
> On Mon, Jun 15, 2015 at 04:15:36PM +0900, Alexandre Courbot wrote:
>> On 06/15/2015 04:09 PM, Alexandre Courbot wrote:
>> >From: Ari Hirvonen
>> >
>> >Add new NOUVEAU_GEM_SET_TILING
Return proper pgprot for ARM64. This is required for objects like
Nouveau fences to be mapped with expected coherency.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
On 06/25/2015 08:59 AM, Ben Skeggs wrote:
> On 23 June 2015 at 16:16, Alexandre Courbot wrote:
>> Second version of this patchset. Not many changes since first version - I
>> hope
>> this means the changes are not too controversial.
>>
>> Changes since v1:
&g
Allow the platform driver to recognize GM20B.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nouveau_platform.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drm/nouveau/nouveau_platform.c b/drm/nouveau/nouveau_platform.c
index dcfbbfaf1739..7a39d449fefa 100644
--- a/drm/nouveau
Recognize GM20B and assign the right engines and subdevs.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nvkm/engine/device/gm100.c | 20
1 file changed, 20 insertions(+)
diff --git a/drm/nouveau/nvkm/engine/device/gm100.c
b/drm/nouveau/nvkm/engine/device/gm100.c
index
Add support for GM20B's graphics engine, based on GK20A. Note that this
code alone will not allow the engine to initialize on released devices
which require PMU-assisted secure boot.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/include/nvkm/engine/gr.h | 1 +
drm/nouveau/nvkm/engine/gr
GM20B has a 512-channels FIFO similar to GK104.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/include/nvkm/engine/fifo.h | 1 +
drm/nouveau/nvkm/engine/fifo/Kbuild| 1 +
drm/nouveau/nvkm/engine/fifo/gk104.h | 4
drm/nouveau/nvkm/engine/fifo/gm204.c | 2 +-
drm/nouveau/nvkm
considerably from GK104, the register packs are now loaded from
firmware files, again similarly to what is done with nvgpu.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nvkm/engine/gr/ctxgk20a.c | 65 +--
drm/nouveau/nvkm/engine/gr/gf100.c| 3 +-
drm/nouveau/nvkm/engine/gr/gf100.h
NVIDIA will officially start providing GR firmwares through
linux-firmware for GPUs that require it. Change the GR firmware lookup
function to use these files.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nvkm/engine/gr/gf100.c | 31 +++
1 file changed, 19
it
does, I have good arguments to support it. ;) Besides the GK20A rework that
probably few people care about, the point is the addition of a basic layout for
the firmwares that NVIDIA will officially release to finally support secure
boot, and I would like to make sure we get this right.
Alexandre
Increase version number so Mesa can check against it before using the
new NOUVEAU_GEM_DOMAIN_COHERENT flag.
Signed-off-by: Alexandre Courbot
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 78a0010..e48fb7e 100644
On Tue, Jun 16, 2015 at 7:07 PM, Daniel Vetter wrote:
> On Mon, Jun 15, 2015 at 06:08:21PM +0900, Alexandre Courbot wrote:
>> On 06/15/2015 04:56 PM, Daniel Vetter wrote:
>> >On Mon, Jun 15, 2015 at 04:09:29PM +0900, Alexandre Courbot wrote:
>> >>From: Ar
On Fri, Jun 19, 2015 at 1:40 PM, Ben Skeggs wrote:
> On 19 June 2015 at 00:47, Alexandre Courbot wrote:
>> NVIDIA will officially start providing signed firmwares through
>> linux-firmware. Change the GR firmware lookup function to look them up
>> in addition to the ext
On Fri, Jun 19, 2015 at 12:57 AM, Ilia Mirkin wrote:
> Why did you change request_firmware to request_firmware_direct?
request_firmware() outputs an error message if the firmware file does
not exist, whereas request_firmware_direct() doesn't. Since the
firmware file can be in one of two
Allow the platform driver to recognize GM20B.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nouveau_platform.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drm/nouveau/nouveau_platform.c b/drm/nouveau/nouveau_platform.c
index dcfbbfa..7a39d44 100644
--- a/drm/nouveau
Recognize GM20B and assign the right engines and subdevs.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nvkm/engine/device/gm100.c | 20
1 file changed, 20 insertions(+)
diff --git a/drm/nouveau/nvkm/engine/device/gm100.c
b/drm/nouveau/nvkm/engine/device/gm100.c
index
Add support for GM20B's graphics engine, based on GK20A. Note that this
code alone will not allow the engine to initialize on released devices
which require PMU-assisted secure boot.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/include/nvkm/engine/gr.h | 1 +
drm/nouveau/nvkm/engine/gr
GM20B has a 512-channels FIFO similar to GK104.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/include/nvkm/engine/fifo.h | 1 +
drm/nouveau/nvkm/engine/fifo/Kbuild| 1 +
drm/nouveau/nvkm/engine/fifo/gk104.h | 4
drm/nouveau/nvkm/engine/fifo/gm204.c | 2 +-
drm/nouveau/nvkm
considerably from GK104, the register packs are now loaded from
firmware files, again similarly to what is done with nvgpu.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nvkm/engine/gr/ctxgk20a.c | 65 +--
drm/nouveau/nvkm/engine/gr/gf100.c| 3 +-
drm/nouveau/nvkm/engine/gr/gf100.h
NVIDIA will officially start providing signed firmwares through
linux-firmware. Change the GR firmware lookup function to look them up
in addition to the extracted firmwares.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nvkm/engine/gr/gf100.c | 66 +-
1
.
Alexandre Courbot (6):
gr: support for NVIDIA-provided firmwares
gr/gk20a: use same initialization sequence as nvgpu
fifo: add GM20B fifo
gr: add GM20B support
device: recognize GM20B
platform: recognize GM20B
drm/nouveau/include/nvkm/engine/fifo.h | 1 +
drm/nouveau/include/nvkm
On 06/15/2015 04:56 PM, Daniel Vetter wrote:
> On Mon, Jun 15, 2015 at 04:09:29PM +0900, Alexandre Courbot wrote:
>> From: Ari Hirvonen
>>
>> Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling
>> mode for imported dma-bufs. This ioctl is sta
On 06/15/2015 04:09 PM, Alexandre Courbot wrote:
> From: Ari Hirvonen
>
> Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling
> mode for imported dma-bufs. This ioctl is staging for now
> and enabled with the "staging_tiling" module option.
Adding Thierry to
ream, many fixes]
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nouveau_bo.c | 18
drm/nouveau/nouveau_bo.h | 2 ++
drm/nouveau/nouveau_drm.c | 6
drm/nouveau/nouveau_gem.c | 58 ++
drm/nouveau/nouveau_gem
ed to stay there for a long time, so we
limit their number. Besides, each staging ioctls needs to be explicitly
enabled through its own module option.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nouveau_drm.c | 1 +
drm/nouveau/uapi/drm/nouveau_drm.h | 3 +++
2 files changed, 4
be called on dma-buf imported buffers
- Move the code setting nvkm_mem::memtype into its own function to avoid
duplicating code
Alexandre Courbot (1):
drm/nouveau: placeholders for staging ioctls
Ari Hirvonen (1):
drm/nouveau: add GEM_SET_TILING staging ioctl
drm/nouveau/nouveau
On 06/10/2015 03:59 PM, Uwe Kleine-König wrote:
> On Wed, Jun 10, 2015 at 11:25:25AM +0900, Alexandre Courbot wrote:
>> On 06/09/2015 06:43 PM, Uwe Kleine-König wrote:
>>> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
>>> which appeared
gt; Furthermore there is devm_gpiod_get_optional which is designed to get
> optional gpios.
>
> Simplify driver accordingly.
Nice!
Acked-by: Alexandre Courbot
his to simplify the driver. Furthermore this is one caller less
> that stops us making the flags argument to gpiod_get*() mandatory.
Acked-by: Alexandre Courbot
On Sun, May 24, 2015 at 3:26 PM, Maarten Lankhorst
wrote:
> Op 23-05-15 om 08:45 schreef Alexandre Courbot:
>> On Fri, May 22, 2015 at 3:23 AM, Martin Peres
>> wrote:
>>> On 21/05/2015 11:47, Ben Skeggs wrote:
>>>> On 21 May 2015 at 16:08, Alexandre Courb
On Wed, May 20, 2015 at 4:07 PM, Arnd Bergmann wrote:
> On Wednesday 20 May 2015 15:10:24 Alexandre Courbot wrote:
>> The lack of IOMMU API support can make nouveau_platform_probe_iommu()
>> fail to compile because struct iommu_ops is then empty. Fix this by
>> skipping IOM
On Fri, May 22, 2015 at 3:23 AM, Martin Peres wrote:
> On 21/05/2015 11:47, Ben Skeggs wrote:
>>
>> On 21 May 2015 at 16:08, Alexandre Courbot wrote:
>>>
>>> Add a flag allowing Nouveau to specify that an object should be coherent
>>> at alloca
On Thu, May 21, 2015 at 5:35 PM, Ben Skeggs wrote:
> On 21 May 2015 at 16:04, Alexandre Courbot wrote:
>> On Thu, May 21, 2015 at 2:55 PM, Ben Skeggs wrote:
>>> On 21 May 2015 at 15:49, Alexandre Courbot wrote:
>>>> On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs wro
On Wed, May 20, 2015 at 3:53 PM, Martin Peres wrote:
> On 20/05/15 08:11, Alexandre Courbot wrote:
>>
>> On Fri, May 15, 2015 at 8:39 PM, Maarten Lankhorst
>> wrote:
>>>
>>> Op 15-05-15 om 09:11 schreef Alexandre Courbot:
>>>>
>>>&
on architectures for which coherency is not guaranteed by the bus.
Signed-off-by: Alexandre Courbot
---
Changes since v1:
None, just added Martin so he can merge the patch. R-b and A-b wanted. :)
include/drm/nouveau_drm.h | 1 +
nouveau/abi16.c | 3 +++
nouveau/nouveau.h | 1 +
3 files
On Thu, May 21, 2015 at 2:55 PM, Ben Skeggs wrote:
> On 21 May 2015 at 15:49, Alexandre Courbot wrote:
>> On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs wrote:
>>> On 20 May 2015 at 15:56, Alexandre Courbot wrote:
>>>> Add a module option allowing t
On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs wrote:
> On 20 May 2015 at 15:56, Alexandre Courbot wrote:
>> Add a module option allowing to enable staging/unstable APIs. This will
>> allow us to experiment freely with experimental APIs for a while before
>> setting them in st
On Wed, May 20, 2015 at 9:01 PM, Arnd Bergmann wrote:
> On Wednesday 20 May 2015 13:32:33 Thierry Reding wrote:
>>
>> Since these are all static functions, perhaps an "if (IS_ENABLED(...))"
>> would work here? That way you'd get compile coverage of the code in all
>> cases.
>
> I had the same
1 - 100 of 364 matches
Mail list logo
