drivers/gpu/drm/nouveau/dispnv50/disp.c: In function nv50_pior_enable:
drivers/gpu/drm/nouveau/dispnv50/disp.c:1672:28: warning:
variable nv_connector set but not used [-Wunused-but-set-variable]
commit ac2d9275f371 ("drm/nouveau/kms/nv50-: Store the
bpc we're using in nv50_head_atom") left
drivers/gpu/drm/nouveau/dispnv04/arb.c: In function nv04_calc_arb:
drivers/gpu/drm/nouveau/dispnv04/arb.c:56:21: warning:
variable width set but not used [-Wunused-but-set-variable]
'width' is never used, so remove it.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
On Thu, Jan 16, 2020 at 12:16:30PM -0800, Ralph Campbell wrote:
> Can you point me to the latest ODP code? Seems like my understanding is
> quite off.
https://elixir.bootlin.com/linux/v5.5-rc6/source/drivers/infiniband/hw/mlx5/odp.c
Look for the word 'implicit'
mlx5_ib_invalidate_range()
On 1/16/20 8:00 AM, Jason Gunthorpe wrote:
On Wed, Jan 15, 2020 at 02:09:47PM -0800, Ralph Campbell wrote:
I don't understand the lifetime/membership issue. The driver is the only thing
that allocates, inserts, or removes struct mmu_interval_notifier and thus
completely controls the
From: Colin Ian King
[ Upstream commit b1d03fc36ec9834465a08c275c8d563e07f6f6bf ]
Currently the uninitialized values in the array reply are printed out
when exec is false and nvkm_pmu_send has not updated the array. Avoid
confusion by only dumping out these values if they have been actually
From: Colin Ian King
[ Upstream commit 13649101a25c53c87f4ab98a076dfe61f3636ab1 ]
Currently, the expression for calculating RON is always going to result
in zero no matter the value of ram->mr[1] because the ! operator has
higher precedence than the shift >> operator. I believe the missing
From: Colin Ian King
[ Upstream commit b1d03fc36ec9834465a08c275c8d563e07f6f6bf ]
Currently the uninitialized values in the array reply are printed out
when exec is false and nvkm_pmu_send has not updated the array. Avoid
confusion by only dumping out these values if they have been actually
From: Colin Ian King
[ Upstream commit 13649101a25c53c87f4ab98a076dfe61f3636ab1 ]
Currently, the expression for calculating RON is always going to result
in zero no matter the value of ram->mr[1] because the ! operator has
higher precedence than the shift >> operator. I believe the missing
From: Colin Ian King
[ Upstream commit b1d03fc36ec9834465a08c275c8d563e07f6f6bf ]
Currently the uninitialized values in the array reply are printed out
when exec is false and nvkm_pmu_send has not updated the array. Avoid
confusion by only dumping out these values if they have been actually
From: Colin Ian King
[ Upstream commit 13649101a25c53c87f4ab98a076dfe61f3636ab1 ]
Currently, the expression for calculating RON is always going to result
in zero no matter the value of ram->mr[1] because the ! operator has
higher precedence than the shift >> operator. I believe the missing
From: Colin Ian King
[ Upstream commit b1d03fc36ec9834465a08c275c8d563e07f6f6bf ]
Currently the uninitialized values in the array reply are printed out
when exec is false and nvkm_pmu_send has not updated the array. Avoid
confusion by only dumping out these values if they have been actually
From: Colin Ian King
[ Upstream commit 785cf1eeafa23ec63f426d322401054d13abe2a3 ]
The NOUVEAU_GETPARAM_PCI_DEVICE case is missing a break statement and falls
through to the following NOUVEAU_GETPARAM_BUS_TYPE case and may end up
re-assigning the getparam->value to an undesired value. Fix this
From: Colin Ian King
[ Upstream commit 13649101a25c53c87f4ab98a076dfe61f3636ab1 ]
Currently, the expression for calculating RON is always going to result
in zero no matter the value of ram->mr[1] because the ! operator has
higher precedence than the shift >> operator. I believe the missing
On Wed, Jan 15, 2020 at 02:09:47PM -0800, Ralph Campbell wrote:
> I don't understand the lifetime/membership issue. The driver is the only thing
> that allocates, inserts, or removes struct mmu_interval_notifier and thus
> completely controls the lifetime.
If the returned value is on the defered
On Wed, Jan 15, 2020 at 02:05:24PM -0800, Ralph Campbell wrote:
>
> On 1/14/20 4:49 AM, Jason Gunthorpe wrote:
> > On Mon, Jan 13, 2020 at 02:47:01PM -0800, Ralph Campbell wrote:
> > > diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> > > index 47ad9cc89aab..4efecc0f13cb 100644
> > > +++
The name is weird, normally we call functions like this _locked.
Additionally it will need a lockdep_assert_held to ensure the caller
actually holds the lock.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
16 matches
Mail list logo
