On Thu, 2025-05-01 at 21:58 +0900, Alexandre Courbot wrote:
> +pub(crate) const FIRMWARE_VERSION: &str = "535.113.01";
This needs to change to 570.144. You can find images to use here:
https://github.com/NVIDIA/linux-firmware/commits/nvidia-staging/
On Thu, 2025-05-01 at 21:58 +0900, Alexandre Courbot wrote:
> +impl UsizeAlign for usize {
> + fn align_up(mut self, align: usize) -> usize {
> + self = (self + align - 1) & !(align - 1);
> + self
> + }
> +}
> +
> +/// Aligns `val` upwards to the nearest multiple of `align`.
>
On Thu, 2025-05-01 at 11:22 -0400, Joel Fernandes wrote:
> Also not mutating it like that matches the pattern in the rest of this file
> so
> I'd leave it as-is.
Oh I see now. One version changes a variable, and the other returns a new
value.
On Wed, 2025-04-23 at 18:53 -0400, Joel Fernandes wrote:
> +This document describes the layout of the VBIOS image which is a series of
> concatenated
> +images in the ROM of the GPU. The VBIOS is mirrored onto the BAR 0 space and
> is read
> +by both Boot ROM firmware (also known as IFR or init-f
On Tue, 2025-04-08 at 17:21 +0100, David Woodhouse wrote:
> If I set the BIOS to use the external display at boot time, that works
> and Linux starts booting using the USB-C monitor — until nouveau inits,
> at which point it stops working. Is it useful to provide the logfiles
> from debugfs and drm
On Tue, 2025-04-08 at 17:42 +0100, David Woodhouse wrote:
> ISTR you said that if the proprietary driver does manage to use that
> port, then we could at least look at why nouveau doesn't?
Yes, but that is beyond my knowledge of Nouveau and GPU drivers.
> Could it even already be fixed in the r57
On Mon, 2025-04-07 at 21:09 +0100, David Woodhouse wrote:
> It *was* working, as long as I could tolerate it being scaled to 200% like
> the internal display. It *did* light up the external display just fine.
Ok, the only thing I can think of is to do a bisect between 6.13.4 and
6.13.6 to determin
On Mon, 2025-04-07 at 20:41 +0100, David Woodhouse wrote:
> Yes. The proprietary driver (570.133.07) did manage to light up the
> external monitor over USB-C/DP.
>
> It was utterly unusable, as I couldn't make it do 100% scaling on the
> external screen and 200% on the high-DPI laptop screen, and
On Mon, 2025-04-07 at 18:01 +0100, David Woodhouse wrote:
> >
>
> Not exactly the same build (I'm on 6.14 now) but:
>
> (gdb) list *(r535_gsp_msgq_wait+0x1c4)
> 0xd24 is in r535_gsp_msgq_wait
> (drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:117).
> 112 break;
> 113
On Mon, 2025-04-07 at 19:39 +0100, David Woodhouse wrote:
> I'd already upgraded to 6.14, and have just rebooted into 6.14.1 with
> that option enabled. I now have the four files in debugfs of which you
> spoke, but I'm assuming you don't actually want them until something
> *interesting* happens,
On Mon, 2025-04-07 at 17:14 +, Timur Tabi wrote:
> What I need now are the GSP-RM logs. In your /etc/modprobe.d, see if
> there
> is a file with "options nouveau". If there isn't, create one, and then
> add
> the "keep-gsp-logging=1" pa
On Mon, 2025-04-07 at 16:28 +0100, David Woodhouse wrote:
> [608593.5728743 CPU: 15 UID: 626640614 PID: 17529 Comm: WebKitWebProces
> Taint
> [608593.576062] Tainted: [W]=WARN
What does this mean?
> C608593.579235] Hardware name: LENOVO 21FVS16V08/21FVS16V80, BIOS N3ZET45W
> (1.
> [608593.58244
On Tue, 2025-03-04 at 22:53 +0900, Alexandre Courbot wrote:
> +/// Useful operations for `u64`.
> +pub trait U64Ext {
> + /// Build a `u64` by combining its `high` and `low` parts.
> + ///
> + /// ```
> + /// use kernel::num::U64Ext;
> + /// assert_eq!(u64::from_u32s(0x01234567, 0x89
On Fri, 2025-02-28 at 07:37 +1000, Dave Airlie wrote:
> I've tried to retrofit checking 0x to drivers a lot, I'd
> prefer not to. Drivers getting stuck in wait for clear bits for ever.
That's what read_poll_timeout() is for. I'm surprised Nouveau doesn't use it.
On Tue, 2025-02-18 at 22:16 +0900, Alexandre Courbot wrote:
> > A proper struct with `high` and `low` might be more verbose, but
> > it rules out this issue.
>
> Mmm indeed, so we would have client code looking like:
>
> let SplitU64 { high, low } = some_u64.into_u32();
>
> instead of
>
>
On Fri, 2025-01-31 at 23:04 +0100, Danilo Krummrich wrote:
> +/// Structure encapsulating the firmware blobs required for the GPU to
> operate.
> +#[allow(dead_code)]
> +pub(crate) struct Firmware {
> +booter_load: firmware::Firmware,
> +booter_unload: firmware::Firmware,
> +gsp: firmw
On Fri, 2025-01-31 at 23:04 +0100, Danilo Krummrich wrote:
> +Rust abstraction for debugfs APIs.
> +
> +| Reference: Export GSP log buffers
> +| Complexity: Beginner
Seriously?
u32 repc)
> }
>
> /**
> - * create_debufgs - create a blob debugfs entry
> + * create_debugfs - create a blob debugfs entry
Ugh, I thought I caught all of these. How embarrassing.
Acked-by: Timur Tabi
On Fri, 2024-08-16 at 06:19 +1000, Dave Airlie wrote:
> Fix this by using the non-coherent allocator instead, I think there
> might be a better answer to this, but it involve ripping up some of
> APIs using sg lists.
Thanks for fixing this, but what is the relationshio between non-coherent
DMA and
On Mon, 2024-04-29 at 17:30 +0200, Linux regression tracking (Thorsten
Leemhuis) wrote:
> TWIMC, there is another report about this in this thread (sadly some of
> its post did not make it to lore):
>
> https://lore.kernel.org/all/162ef3c0-1d7b-4220-a21f-b0008657f...@redhat.com/
>
> Ciao, Thorste
On Sun, 2024-04-28 at 11:52 -0400, Lyude Paul wrote:
> But we can't get a page pointer from an allocation made by
> dma_alloc_coherent() - but we can from vmalloc(). I'll fix the patch
> explanation in the next version, I have to send out another version
> anyhow since I realized that patch #2 stil
On Fri, 2024-04-26 at 11:41 -0400, Lyude Paul wrote:
> We hit this because when initializing firmware of type
> NVKM_FIRMWARE_IMG_DMA we allocate coherent memory and then attempt to
> include that coherent memory in a scatterlist.
I'm sure this patch is a good one, and I will try to test it soon,
On Mon, 2024-04-08 at 16:42 +1000, Dave Airlie wrote:
> This reverts:
> nouveau/gsp: don't check devinit disable on GSP.
> and applies a further fix.
>
> It turns out the open gpu driver, checks this register, but only for
> display.
>
> Match that behaviour and only disable displays on turings.
On Tue, 2024-03-26 at 15:51 +0100, Arnd Bergmann wrote:
> Calling a function through an incompatible pointer type causes breaks
> kcfi, so clang warns about the assignment:
>
...
> +static void of_fini(void *p)
> +{
> + return kfree(p);
> +}
> +
I don't know anything about kfci, but shoul
On Mon, 2024-03-11 at 17:20 +1000, Dave Airlie wrote:
> Later attempts to refault the bo won't happen and the whole
> GPU does to lunch. I think Christian's refactoring of this
Typo: I think you meant "goes to lunch".
On Wed, 2024-03-06 at 02:14 +0800, kernel test robot wrote:
> > |-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-
> > parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
Could someone please apply
https://lore.kernel.org/nouveau/20240210002900.148982-1-tt...@nv
On Sun, Mar 3, 2024 at 4:46 AM Duoming Zhou wrote:
>
> The kcalloc() in nouveau_dmem_evict_chunk() will return null if
> the physical memory has run out. As a result, if we dereference
> src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs
> will happen.
>
> This patch uses stack var
On Fri, Mar 1, 2024 at 2:23 AM Sid Pranjale
wrote:
>
> Nouveau deallocates a few buffers post GPU init which are required for GPU
> suspend/resume to function correctly.
> This is likely not as big an issue on systems where the NVGPU is the only
> GPU, but on multi-GPU set ups it leads to a regr
On Mon, 2024-02-19 at 10:32 +0100, Danilo Krummrich wrote:
Looks like I spoke too soon, I just hit the problem with the drm-next tree.
Did you apply the patch to drm-next?
Ugh, you're right. I don't how I got confused, but I could have sworn that I
saw your two patches in drm-next, but they a
On Fri, 2024-02-02 at 17:14 +, Timur Tabi wrote:
> On Fri, 2024-02-02 at 01:05 +0100, Danilo Krummrich wrote:
> > nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call
> > their corresponding *_fini() counterpart. This can lead to
> > nouveau_sched_fini()
On Tue, 2024-02-13 at 16:43 +0100, Danilo Krummrich wrote:
> > +struct registry_list_entry {
> > + struct list_head list;
>
> Nit: 'head' or 'entry' might be more suitable.
Will fix in v4.
>
> > + size_t name_len;
> > + u32 type;
>
> I prefer to represent type as enum or use a define for
On Tue, 2024-02-13 at 17:57 +0100, Danilo Krummrich wrote:
+ struct debugfs_blob_wrapper blob_init;
+ struct debugfs_blob_wrapper blob_intr;
+ struct debugfs_blob_wrapper blob_rm;
+ struct debugfs_blob_wrapper blob_pmu;
+ struct dentry *debugfs_logging_dir;
I th
ignored.
Signed-off-by: Timur Tabi
---
v3: reworked r535_gsp_libos_debugfs_init, rebased for drm-next
.../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 12 +
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 215 +-
2 files changed, 223 insertions(+), 4 deletions(-)
diff --git a
.
The name and format of NVreg_RegistryDwords is the same as used by
the Nvidia driver, to maintain compatibility.
Signed-off-by: Timur Tabi
---
v3: rebased to drm-next
.../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 6 +
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 279 --
2
Two patches that were previosly posted, but now updated for drm-next.
Timur Tabi (2):
[v3] nouveau: add command-line GSP-RM registry support
[v3] drm/nouveau: expose GSP-RM logging buffers via debugfs
.../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 18 +
.../gpu/drm/nouveau/nvkm/subdev/gsp
On Fri, 2024-02-02 at 01:05 +0100, Danilo Krummrich wrote:
> nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call
> their corresponding *_fini() counterpart. This can lead to
> nouveau_sched_fini() being called without struct nouveau_sched ever
> being initialized in the first pla
On Thu, Dec 21, 2023, 10:33 PM Dave Airlie wrote:
> This should let the upper layers retry as needed on EAGAIN.
>
> There may be other values we will care about in the future, but
> this covers our present needs.
>
> Signed-off-by: Dave Airlie
>
> +static int
> +r535_rpc_status_to_errno(uint32_t
On Mon, 2023-12-11 at 08:53 -0500, Sasha Levin wrote:
> This is a hack around a bug exposed with the GSP code, I'm not sure
> what is happening exactly, but it appears some of our flushes don't
> result in proper tlb invalidation for out BAR2 and we get a BAR2
> fault from GSP and it all dies.
Do
On Tue, 2023-12-05 at 12:01 +1000, Dave Airlie wrote:
> These can happen in normal operations esp with auxch transactions.
>
> Gets rid of
> nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073 ctrl cmd:0x00731341
> failed: 0x
> in logs.
Is this something you want me to look into?
On Tue, 2023-12-05 at 10:01 +1000, Dave Airlie wrote:
> The current code prints a message when we get a callback we don't
> handle, this silences those, but maybe I should just silence them.
How about this:
In r535_gsp_msg_recv():
if (ntfy->fn && (ntfy->fn == msg->function)) {
ntfy->func
On Tue, 2023-12-05 at 08:55 +1000, Dave Airlie wrote:
> +static int
> +r535_gsp_msg_ucode_libos_print(void *priv, u32 fn, void *repv, u32 repc)
> +{
> + /* work out what we should do here. */
> + return 0;
> +}
This is part of my logrm debugfs patch. It contains the printf log from a
On Mon, 2023-12-04 at 09:51 +0100, Gert Vanhaerents wrote:
> OK i will report it to nvidia. But with the nouveau drivers it's also not
> working. Are you sure it's not a kernel problem?
> Because according to systemd it would be a kernel problem. (personaly i am
> also thinking it's a driver pro
On Sat, 2023-12-02 at 09:13 -0800, Marc MERLIN wrote:
> [ 3.184525] nouveau: unknown parameter 'modset' ignored
For starters, you misspelled "modeset"
On Sat, 2023-12-02 at 20:18 +0700, Bagas Sanjaya wrote:
>
> > When i install the proprietary Nvidia drivers, i have the following:
> >
> > [MASTER] pci::08:00.0
> > │ ├─/sys/devices/pci:00/:00:03.1/:08:00.0/drm/card0
> > │ │ [MASTER] drm:card0
> > │
On Thu, 2023-11-30 at 22:58 +0800, kernel test robot wrote:
> If you fix the issue in a separate patch/commit (i.e. not just a new
> version of
> the same patch/commit), kindly add following tags
> > Reported-by: kernel test robot
> > Closes: https://lore.kernel.org/oe-kbuild-all/202311302252.rJ0u
On Tue, Oct 31, 2023 at 12:20 AM Dave Airlie wrote:
> rpc->size = sizeof(*rpc);
> - rpc->numEntries = 1;
> - rpc->entries[0].nameOffset = offsetof(typeof(*rpc), entries[1]);
> - rpc->entries[0].type = 1;
> - rpc->entries[0].data = 0;
> - rpc->entries[0].length
ff-by: Dan Carpenter
Nice catch!
Reviewed-by: Timur Tabi
On Thu, 2023-11-16 at 20:45 +0100, Danilo Krummrich wrote:
> As I already mentioned for Timur's patch [2], I'd prefer to get a fix
> upstream
> (meaning [1] in this case). Of course, that's probably more up to Timur to
> tell
> if this will work out.
Don't count on it.
Even if I did change [0] to
On Thu, 2023-11-16 at 12:11 -0600, Gustavo A. R. Silva wrote:
typedef struct PACKED_REGISTRY_TABLE
{
-NvU32 size;
-NvU32 numEntries;
-PACKED_REGISTRY_ENTRY entries[0];
+ NvU32 size;
+ NvU32 numEntrie
On Wed, 2023-11-08 at 00:52 +0100, Danilo Krummrich wrote:
> On 11/8/23 00:47, Timur Tabi wrote:
> > Change PACKED_REGISTRY_TABLE so that its last member is a variable-
> > length
> > array instead of a zero-length array. UBSAN treats zero-length arrays
> > lite
uot;nouveau/gsp: move to 535.113.01")
Signed-off-by: Timur Tabi
---
.../include/nvrm/535.113.01/nvidia/generated/g_os_nvoc.h| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/drivers/gpu/drm/nouveau/include/nvrm/535.113.01/nvidia/generated/g_os_nvoc.h
b/drivers/gpu/dr
On Wed, 2023-11-08 at 04:54 +1000, Dave Airlie wrote:
yes that is probably the right answer for this, if we want to reuse
the structs that we get from the nvidia driver.
ok, I'll submit a patch.
On Tue, 2023-10-31 at 15:18 +1000, Dave Airlie wrote:
+ strings = (char *)&rpc->entries[NV_GSP_REG_NUM_ENTRIES];
I get a UBSAN index-out-of-bounds error on boot at this line.
[ 17.765746] nouveau :65:00.0: gsp: cmdq: wptr 1
[ 17.765748]
=
On Wed, 2023-11-01 at 05:29 +1000, Dave Airlie wrote:
> >
> > static const struct nv_gsp_registry_entries r535_registry_entries[] = {
> > { "RMSecBusResetEnable", 1 },
> > { "RMForcePcieConfigSave", 1 },
> > };
> >
> > #define NV_GSP_REG_NUM_ENTRIES ARRAY_SIZE(r535_registry_entrie
On Tue, Oct 31, 2023 at 12:20 AM Dave Airlie wrote:
> +#define NV_GSP_REG_NUM_ENTRIES 2
> +
> +static const struct nv_gsp_registry_entries
> r535_registry_entries[NV_GSP_REG_NUM_ENTRIES] = {
> + { "RMSecBusResetEnable", 1 },
> + { "RMForcePcieConfigSave", 1 },
> +};
How about :
stat
On Tue, 2023-09-19 at 17:56 -0400, Lyude Paul wrote:
> +static int
> +gt215_sor_bl_set(struct nvkm_ior *ior, int lvl)
> +{
> + struct nvkm_device *device = ior->disp->engine.subdev.device;
> + const u32 soff = nv50_ior_base(ior);
> + u32 div, val;
> +
> + div = nvkm_rd32(dev
DRM drivers), so I
can't do a thorough review, but I did look over the patches and provided
some feedback.
So, for what it's worth,
Reviewed-by: Timur Tabi
On Tue, 2023-09-19 at 17:56 -0400, Lyude Paul wrote:
> + /*
> + * FIXME: This is a hack to workaround the
> following
> + * issues:
> + *
> + *
> https://gitlab.gnome.org/GNOME/mutter/i
On Tue, 2023-09-19 at 17:56 -0400, Lyude Paul wrote:
> + NVIF_CONN_VGA,
> + NVIF_CONN_TV,
> + NVIF_CONN_DVI_I,
> + NVIF_CONN_DVI_D,
> + NVIF_CONN_LVDS,
> + NVIF_CONN_L
On Tue, Mar 7, 2023 at 2:28 AM Thomas Zimmermann wrote:
> > So after module_init is finished, mode_option_buf[] no longer exists?
>
> Does the __init attribute on a function affect the static variables in
> that function?
That is an excellent question.
https://stackoverflow.com/questions/6455861
On Mon, Mar 6, 2023 at 10:01 AM Thomas Zimmermann wrote:
>
> Assume that the driver does not own the option string or its substrings
> and hence duplicate the option string for the video mode. The driver only
> parses the option string once as part of module initialization, so use
> a static buffe
On Sun, Sep 4, 2022 at 4:48 PM Jim Cromie wrote:
>
> These 2 macros used drm_debug_enabled() on DRM_UT_{DRIVER,ATOMIC}
> respectively, replace those with drm_dbg_##cat invocations.
>
> this results in new class'd prdbg callsites:
>
> :#> grep nouveau /proc/dynamic_debug/control | grep class | wc
>
On 12/3/18 12:43 AM, Wen Yang wrote:
The null check on &info->cmap is redundant since cmap is a struct
inside fb_info and can never be null, so the check is always true.
we may remove it.
Signed-off-by: Wen Yang
Acked-by: Timur Tabi
___
dr
to me, but I'm going to
have to assume that you know what you're doing.
Acked-by: Timur Tabi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
assignments.
[1]https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
Acked-by: Timur Tabi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman
On 05/16/2018 01:23 PM, Sinan Kaya wrote:
+ win_start = window->res->start - window->offset;
Can you guarantee that window->res->start is always >= window->offset?
+ win_size = window->res->end - window->res->start + 1;
Use resource_size() instead.
--
Qualcomm D
On 11/27/17 3:00 AM, SF Markus Elfring wrote:
From: Markus Elfring
Date: Mon, 27 Nov 2017 09:56:09 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
Acked-by: Timur Tabi
67 matches
Mail list logo
