Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c:2599:1: warning: no previous
> prototype for ‘nv50_display_create’ [-Wmissing-prototypes]
>
> Cc: Be
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand *
> file mga_ioc32.c
>
> Cc: Ben Skeggs
> Cc: David Airlie
&
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or
> member 'filp' not described in 'nouveau_compat_ioc
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_svm.c: In function ‘nouveau_pfns_map’:
> drivers/gpu/drm/nouveau/nouveau_svm.c:810:6: warning: variable ‘ret’ set but
> not used [-Wunused-but-set-variable]
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following build error:
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c:2530:1: error: conflicting types for
> ‘nv50_display_fini’
> In file included from drivers/gpu/drm/nouveau/
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous
> prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
>
> Cc: Be
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_mstm_cleanup’:
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1357:6: warning: variable ‘ret’ set
> but not used [-Wunused-but-set-vari
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or
> member 'crtc' not described in 'nv_crtc_mode_set_re
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘nouveau_ttm_tt_populate’:
> drivers/gpu/drm/nouveau/nouveau_bo.c:1228:17: warning: variable ‘
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function
> parameter or member 'speedo' not described in 'gk20a_vo
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:992: warning: Function
> parameter or member 'gr' not described in 'gf100_gr_wait_
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1381:6: warning: variable ‘ret’ set
> but not used [-Wunused-but-set-variable]
>
not a big fan of just ignoring return codes, I'd rather see it handl
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function
> parameter or member 'init' not described in 'init_reserv
On Tue, Apr 13, 2021 at 1:17 PM Roy Spliet wrote:
>
> Op 13-04-2021 om 10:48 schreef Karol Herbst:
> > On Tue, Apr 13, 2021 at 10:24 AM Roy Spliet wrote:
> >>
> >> Op 13-04-2021 om 01:10 schreef Karol Herbst:
> >>> On Mon, Apr 12, 2021 at 9:36 PM Ro
On Tue, Apr 13, 2021 at 10:24 AM Roy Spliet wrote:
>
> Op 13-04-2021 om 01:10 schreef Karol Herbst:
> > On Mon, Apr 12, 2021 at 9:36 PM Roy Spliet wrote:
> >>
> >> Hello Aaron,
> >>
> >> Thanks for your insights. A follow-up query and some observ
On Mon, Apr 12, 2021 at 9:36 PM Roy Spliet wrote:
>
> Hello Aaron,
>
> Thanks for your insights. A follow-up query and some observations in-line.
>
> Op 12-04-2021 om 20:06 schreef Aaron Plattner:
> > On 4/10/21 1:48 PM, Roy Spliet wrote:
> >> Op 10-04-2021 om 20:23 schreef Lukas Wunner:
> >>> On
ize != 1024)
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Reviewed-by: Karol Herbst
m_framebuffer *old_fb)
> return ret;
> }
>
> -/**
> +/*
> * Sets up registers for the given mode/adjusted_mode pair.
> *
> * The clocks, CRTCs and outputs attached to this CRTC must be off.
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Reviewed-by: Karol Herbst
e "nouveau_ioctl.h"
>
> -/**
> +/*
> * Called whenever a 32-bit process running under a 64-bit kernel
> * performs an ioctl on /dev/dri/card.
> *
> --
> 2.27.0
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Reviewed-by: Karol Herbst
; *
> * 32-bit ioctl compatibility routines for the MGA DRM.
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Reviewed-by: Karol Herbst
; TTM_PAGE_FLAG_SG);
>
> if (slave)
> return;
>
> drm = nouveau_bdev(bdev);
> - dev = drm->dev->dev;
>
> return ttm_pool_free(&drm->ttm.bdev.pool, ttm);
> }
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Reviewed-by: Karol Herbst
gt; _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Reviewed-by: Karol Herbst
c0)
> */
> static inline int
> @@ -58,7 +58,7 @@ gk20a_volt_get_cvb_voltage(int speedo, int s_scale, const
> struct cvb_coef *coef)
> return mv;
> }
>
> -/**
> +/*
> * cvb_t_mv =
> * ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0) +
> * ((c3 * speedo / s_scale + c4 + c5 * T / t_scale) * T / t_scale)
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Reviewed-by: Karol Herbst
t;
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Reviewed-by: Karol Herbst
Reviewed-by: Karol Herbst
On Fri, Mar 19, 2021 at 9:24 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function
> parameter or member 'init' not described in 'init_reserv
fyi, there is a patch which solves a maybe related issue on your GPU,
mind giving it a try before we dig further?
https://gitlab.freedesktop.org/drm/nouveau/-/issues/14#note_767791
On Thu, Jan 21, 2021 at 3:33 AM Jamie Heilman
wrote:
>
> Karol Herbst wrote:
> > On Wed, Jan 6, 202
Reviewed-by: Karol Herbst
On Fri, Jan 15, 2021 at 11:51 PM wrote:
>
> From: Tom Rix
>
> Defining DEBUG should only be done in development.
> So remove DEBUG.
>
> Signed-off-by: Tom Rix
> ---
> kernel/trace/trace_mmiotrace.c | 2 --
> 1 file changed, 2 deleti
Fixes a crash when trying to create a channel on e.g. Turing GPUs when
NOUVEAU_SVM_INIT was called before.
Fixes: eeaf06ac1a558 ("drm/nouveau/svm: initial support for shared virtual
memory")
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 4
1 file
Fixes a crash when trying to create a channel on e.g. Turing GPUs when
NOUVEAU_SVM_INIT was called before.
Fixes: eeaf06ac1a558 ("drm/nouveau/svm: initial support for shared virtual
memory")
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 4
1 file
On Wed, Jan 6, 2021 at 4:25 AM Jamie Heilman
wrote:
>
> Jamie Heilman wrote:
> > Jamie Heilman wrote:
> > > Karol Herbst wrote:
> > > > do you think you'd be able to do a kernel bisect in order to pinpoint
> > > > the actual commit causing it? Tha
do you think you'd be able to do a kernel bisect in order to pinpoint
the actual commit causing it? Thanks
On Sun, Dec 27, 2020 at 8:16 PM Jamie Heilman
wrote:
>
> Something between v5.8 and v5.9 has resulted in periodically losing video.
> Unfortunately, I can't reliably reproduce it, it seems t
On Tue, Dec 22, 2020 at 3:50 AM Kai-Heng Feng
wrote:
>
> On Tue, Dec 22, 2020 at 1:56 AM Ilia Mirkin wrote:
> >
> > On Mon, Dec 21, 2020 at 11:33 AM Kai-Heng Feng
> > wrote:
> > >
> > > [+Cc nouveau]
> > >
> > > On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai wrote:
> > > [snip]
> > > > > Quite po
On Thu, Nov 26, 2020 at 4:28 PM Geert Uytterhoeven wrote:
>
> Hi Miguel,
>
> On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda
> wrote:
> > On Wed, Nov 25, 2020 at 11:44 PM Edward Cree wrote:
> > > To make the intent clear, you have to first be certain that you
> > > understand the intent; otherwise
On Fri, Nov 6, 2020 at 3:17 AM Jeremy Cline wrote:
>
> Make use of the devm_drm_dev_alloc() API to bind the lifetime of
> nouveau_drm structure to the drm_device. This is important because a
> reference to nouveau_drm is accessible from drm_device, which is
> provided to a number of DRM layer call
I sent a patch to the mailing list and wanted to have some review on
that from at least Ben, but no idea if Ben already picked it and if
it's good enough for sending it to stable yet.
On Thu, Oct 15, 2020 at 6:32 PM Karol Herbst wrote:
>
> Ben, I think this is like the 5th patch tackling this issue, I think
> we should merge one of those.
>
maybe I just confused that with reports, but it seems to turn up quite
a bit and maybe I should have pushed more of it as wel
Ben, I think this is like the 5th patch tackling this issue, I think
we should merge one of those.
On Thu, Oct 15, 2020 at 6:23 AM Keita Suzuki
wrote:
>
> struct pw_rail_t is allocated as an array in function nvios_iccsense_parse,
> and stored to a struct member of local variable. However, the ar
On Sat, Oct 10, 2020 at 12:23 AM Ilia Mirkin wrote:
>
> On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst wrote:
> >
> > On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary wrote:
> > >
> > > Hello,
> > > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped
On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary wrote:
>
> Hello,
> I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working:
> [0.00] Linux version 5.9.0-rc8+ (zary@gsql) (gcc (Debian 8.3.0-6)
> 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #326 SMP Fri Oct 9 22:31:40
> CEST 2020
>
other drivers seems to do something similar
Signed-off-by: Karol Herbst
Cc: dri-devel
Cc: Dave Airlie
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/nouveau_mem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c
b/drivers/gpu/drm/nouveau
Previously the code relied on device->pri to be NULL and to fail probing
later. We really should just return an error inside nvkm_device_ctor for
unsupported GPUs.
Fixes: 24d5ff40a732 ("drm/nouveau/device: rework mmio mapping code to get rid
of second map")
Signed-off-by: Karol Her
On Thu, Sep 17, 2020 at 4:11 PM Jeremy Cline wrote:
>
> On Wed, Sep 16, 2020 at 10:03:22PM +0200, Karol Herbst wrote:
> > On Wed, Sep 16, 2020 at 10:01 PM Karol Herbst wrote:
> > >
> > > On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline wrote:
> > > >
On Wed, Sep 16, 2020 at 10:01 PM Karol Herbst wrote:
>
> On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline wrote:
> >
> > The temp_get() function currently returns negative error numbers or a
> > temperature. However, the thermal sensors can (in theory) measure
> &g
On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline wrote:
>
> The temp_get() function currently returns negative error numbers or a
> temperature. However, the thermal sensors can (in theory) measure
> negative temperatures. Some implementations of temp_get() correctly
> clamp negative temperature readi
On Wed, Sep 9, 2020 at 6:06 AM Ben Skeggs wrote:
>
> On Thu, 13 Aug 2020 at 06:50, Jeremy Cline wrote:
> >
> > Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of
> > new gp1xx temperature sensor") added support for reading finer-grain
> > temperatures, but continued to repor
On Mon, Sep 7, 2020 at 10:58 PM Marc MERLIN wrote:
>
> On Mon, Sep 07, 2020 at 09:14:03PM +0200, Karol Herbst wrote:
> > > - changes in the nouveau driver. Mika told me the PCIe regression
> > > "pcieport :00:01.0: PME: Spurious native interrupt!" is suppos
On Sun, Sep 6, 2020 at 8:52 PM Marc MERLIN wrote:
>
> Ok, I have an update to this problem. I added the nouveau list because
> I can't quite tell if the issue is:
> - the PCIe changes that went in 5.6 I think (or 5.5?), referenced below
>
> - a new issue with thunderbold on thinkpad P73, that seem
Reviewed-by: Karol Herbst
On Wed, Aug 12, 2020 at 10:50 PM Jeremy Cline wrote:
>
> Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of
> new gp1xx temperature sensor") added support for reading finer-grain
> temperatures, but continued to report te
Reviewed-by: Karol Herbst
On Mon, Aug 3, 2020 at 5:46 AM Jing Xiangfeng wrote:
>
> This patch performs the following changes:
> 1. remove a redundant parentheses around the nvkm_acr_lsfw_add() calls
> 2. do assignment before this if condition, it is more readable
>
> S
On Wed, Jul 22, 2020 at 11:25 AM Mika Westerberg
wrote:
>
> On Tue, Jul 21, 2020 at 01:37:12PM -0500, Patrick Volkerding wrote:
> > On 7/21/20 10:27 AM, Mika Westerberg wrote:
> > > On Tue, Jul 21, 2020 at 11:01:55AM -0400, Lyude Paul wrote:
> > >> Sure thing. Also, feel free to let me know if you
On Mon, Jul 20, 2020 at 3:19 AM Alex Hung wrote:
>
> On 2020-07-19 1:50 p.m., Karol Herbst wrote:
> > On Fri, Jul 17, 2020 at 9:52 PM Alex Hung wrote:
> >>
> >> On 2020-07-17 1:05 p.m., Karol Herbst wrote:
> >>> It's hard to figure out wha
On Fri, Jul 17, 2020 at 9:52 PM Alex Hung wrote:
>
> On 2020-07-17 1:05 p.m., Karol Herbst wrote:
> > It's hard to figure out what systems are actually affected and right now I
> > don't see a good way of removing those...
> >
> > But I'd like to see t
do a proper bug report and we can
look into it and come up with a proper fix (and keep this patch out until
we resolve all of those).
Signed-off-by: Karol Herbst
CC: Alex Hung
CC: "Rafael J. Wysocki"
CC: Len Brown
CC: Lyude Paul
CC: linux-kernel@vger.kernel.org
CC:
Filed at https://bugzilla.kernel.org/show_bug.cgi?id=208597
oddly enough I wasn't able to reproduce it on my XPS 9560, will ping
once something breaks.
On Fri, Jul 17, 2020 at 2:43 AM Karol Herbst wrote:
>
> On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote:
> >
> &g
On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote:
>
> [+cc Sasha -- stable kernel regression]
> [+cc Patrick, Kai-Heng, LKML]
>
> On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> > On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote:
> > >
> >
On Wed, Jul 1, 2020 at 7:37 PM James Jones wrote:
>
> On 7/1/20 10:04 AM, Karol Herbst wrote:
> > On Wed, Jul 1, 2020 at 6:01 PM Daniel Vetter wrote:
> >>
> >> On Wed, Jul 1, 2020 at 5:51 PM James Jones wrote:
> >>>
> >>> On 7/1/20 4:24 AM,
On Wed, Jul 1, 2020 at 6:01 PM Daniel Vetter wrote:
>
> On Wed, Jul 1, 2020 at 5:51 PM James Jones wrote:
> >
> > On 7/1/20 4:24 AM, Karol Herbst wrote:
> > > On Wed, Jul 1, 2020 at 6:45 AM James Jones wrote:
> > >>
> > >> Thi
On Wed, Jul 1, 2020 at 6:45 AM James Jones wrote:
>
> This implies something is trying to use one of the old
> DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifiers with DRM-KMS without
> first checking whether it is supported by the kernel. I had tried to
> force an Xorg+Mesa stack without my users
On Tue, Oct 22, 2019 at 2:45 PM Mika Westerberg
wrote:
>
> On Tue, Oct 22, 2019 at 11:16:14AM +0200, Karol Herbst wrote:
> > I think there is something I totally forgot about:
> >
> > When there was never a driver bound to the GPU, and if runtime power
> > manageme
On Mon, Oct 21, 2019 at 4:09 PM Mika Westerberg
wrote:
>
> On Mon, Oct 21, 2019 at 03:54:09PM +0200, Karol Herbst wrote:
> > > I really would like to provide you more information about such
> > > workaround but I'm not aware of any ;-) I have not seen any issues l
On Wed, Oct 16, 2019 at 11:37 PM Bjorn Helgaas wrote:
>
> [+cc linux-acpi]
>
> On Wed, Oct 16, 2019 at 09:18:32PM +0200, Karol Herbst wrote:
> > but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the
> > platform means of putting the device into D3cold, right?
On Tue, Oct 1, 2019 at 11:11 AM Mika Westerberg
wrote:
>
> On Tue, Oct 01, 2019 at 10:56:39AM +0200, Karol Herbst wrote:
> > On Tue, Oct 1, 2019 at 10:47 AM Mika Westerberg
> > wrote:
> > >
> > > On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote:
On Tue, Oct 1, 2019 at 10:47 AM Mika Westerberg
wrote:
>
> On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote:
> > On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg
> > wrote:
> > >
> > > On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote:
&
On Thu, Aug 15, 2019 at 4:30 PM wrote:
>
> > On Thu, Aug 15, 2019 at 10:15 AM Karol Herbst wrote:
> > >
> > > On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher
> > wrote:
> > > >
> > > > On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst
> &
Patches 1-5 are Reviewed-by: Karol Herbst
I think it might be worth to test those patches on a system without
any backlight devices just to verify we don't break things, but the
code looked good already, so maybe we don't really need to test.
On Thu, Aug 23, 2018 at 3:21 AM, Lyude P
On Fri, Jan 26, 2018 at 4:35 AM, Lyude Paul wrote:
> This adds support for enabling automatic clockgating on nvidia GPUs for
> Kepler1. While this is not technically a clockgating level, it does
> enable clockgating using the clockgating values initially set by the
> vbios (which should be safe to
Reviewed-by: Karol Herbst
On Wed, Jan 17, 2018 at 7:53 PM, Luis de Bethencourt wrote:
> The trailing semicolon is an empty statement that does no operation.
> Removing it since it doesn't do anything.
>
> Signed-off-by: Luis de Bethencourt
> ---
>
> Hi,
>
>
-0800, tip-bot for Karol Herbst wrote:
>> > Commit-ID: 6d60ce384d1d5ca32b595244db4077a419acc687
>> > Gitweb:
>> > https://git.kernel.org/tip/6d60ce384d1d5ca32b595244db4077a419acc687
>> > Author: Karol Herbst
>> > AuthorDate: Mon, 27 Nov 2017
Commit-ID: 6d60ce384d1d5ca32b595244db4077a419acc687
Gitweb: https://git.kernel.org/tip/6d60ce384d1d5ca32b595244db4077a419acc687
Author: Karol Herbst
AuthorDate: Mon, 27 Nov 2017 08:51:39 +0100
Committer: Ingo Molnar
CommitDate: Mon, 11 Dec 2017 15:35:18 +0100
x86/mm/kmmio: Fix
Reviewed-by: Karol Herbst
On Thu, Nov 30, 2017 at 8:53 PM, Christoph Böhmwalder
wrote:
> The kbuild test bot complained about a new coccinelle warning nearby,
> which sparked a discussion about the assignment to 'memory' inside of
> the conditional expression. See Link bel
Hi julia,
I think it would be better to extract the assignment out of the if
clause. Then you'll get something like this:
memory = ...;
if (IS_ERR(memory)) {
}
so, to answer your question: no, it isn't necessary.
On Tue, Nov 28, 2017 at 1:56 PM, Julia Lawall wrote:
> This is a false posit
Rostedt
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Pekka Paalanen
Cc: nouv...@lists.freedesktop.org
Cc: x...@kernel.org
Acked-by: Pekka Paalanen
Tested-by: Lyude
Signed-off-by: Karol Herbst
---
arch/x86/mm/ioremap.c | 4 ++--
arch/x86/mm/kmmio.c | 12 +++-
2 files changed, 9 insertions
On Wed, Sep 6, 2017 at 10:11 PM, Arnd Bergmann wrote:
> On Wed, Sep 6, 2017 at 4:20 PM, Karol Herbst wrote:
>>> In this instance, I think using multiplication is more intuitive
>>> than '&&', so I'm adding a comparison to zero instead to shut up
>&g
On Wed, Sep 6, 2017 at 3:56 PM, Arnd Bergmann wrote:
> gcc thinks that interpreting a multiplication result as a bool
> is confusing:
>
> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll':
> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean
> conte
Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE
usage we could convert to WARN_ONCE?
Reviewed-By: Karol Herbst
On Fri, Jul 14, 2017 at 5:05 PM, Tobias Klausmann
wrote:
> On 7/14/17 3:41 PM, Mike Galbraith wrote:
>>
>> On Fri, 2017-07-14 at 15:36 +0200,
Hi Lyude,
thanks for the great work. Just a view comments inline.
2017-04-25 20:38 GMT+02:00 Lyude :
> This adds support for enabling automatic clockgating on nvidia GPUs for
> Fermi and later generations. This saves a little bit of power, bringing
> my fermi GPU's power consumption from ~28.3W o
we already have that included in 4.10
2016-12-12 12:26 GMT+01:00 Chris Chiu :
> Nouveau driver shows unknown chipset (136000a1) for GTX 1060, so it
> only gives VGA resolution on screen. Use the same chipset as nv134
> then it shows FullHD. This commit copies fields from nv134_chipset
> to nv136_c
sorry for that, but I forgot the patch
2016-11-19 11:56 GMT+01:00 Karol Herbst :
> this is odd, I found a bug related to nouveau (modprobe/bind doesn't
> return), but that isn't related to your issue at all or maybe it is
> exactly this, cause the binding of the device
> weekend. I think I might know where the issue is, but didn't confirm
>> it yet.
>
> Thanks.I'm still using revert. Feel free to Cc me when you will have
> some material to test.
>
>>
>> Again, sorry for the delay.
>>
>> Karol
>>
>> 2016
2016-11-08 17:12 GMT+01:00 Arnd Bergmann :
> On Tuesday, November 8, 2016 5:07:01 PM CET Lukas Wunner wrote:
>> On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote:
>> > The underlying problem is that we already have a number of other
>> > symbols that either have "depends on LEDS_CLASS"
2016-11-08 16:46 GMT+01:00 Ilia Mirkin :
> On Tue, Nov 8, 2016 at 8:56 AM, Arnd Bergmann wrote:
>> The newly introduced LED handling for nouveau fails to link when the
>> driver is built-in but the LED subsystem is a loadable module:
>>
>> drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do
Thanks for the pointer.
But I don't like this patch. If you find a bug, make a bug report or
just fix it if you know the fix already. Or write something in IRC. Or
write on the Mailing list as a general question or something else
But I really don't agree on doing it this way. You would have neede
uhh, that function looks so odd, ... yeah. Change looks fine.
Reviewed-By: Karol Herbst
2016-10-24 17:30 GMT+02:00 Arnd Bergmann :
> gcc-4.9 notices that the validate_init() function returns unintialized
> data when called with a zero 'nr_buffers' argument, when called wi
2016-10-24 9:13 GMT+02:00 Baoyou Xie :
>
>
> On 23 October 2016 at 01:32, Karol Herbst wrote:
>>
>> I think it would be better to squash those commits:
>> 1. for the includes
>> 2. for static declerations
>>
> OK, I have resent new patch that squash tho
I think it would be better to squash those commits:
1. for the includes
2. for static declerations
2016-10-22 11:41 GMT+02:00 Baoyou Xie :
> We get 2 warnings when building kernel with W=1:
> drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous
> prototype for 'nvkm_firmware_ge
ain, sorry for the delay.
Karol
2016-08-19 22:46 GMT+02:00 Karol Herbst :
> Hi again,
>
> I was able to get a crash/freeze/something while unbinding/binding my
> nvidia gpu from nouveau.
>
> Guess that means something is odd. I will investigate this more over
> the weekend.
Hi again,
I was able to get a crash/freeze/something while unbinding/binding my
nvidia gpu from nouveau.
Guess that means something is odd. I will investigate this more over
the weekend.
2016-08-19 17:35 GMT+02:00 Andy Shevchenko :
> On Fri, Aug 19, 2016 at 6:08 PM, karol herbst wrote:
>
2016-08-19 17:35 GMT+02:00 Andy Shevchenko :
> On Fri, Aug 19, 2016 at 6:08 PM, karol herbst wrote:
>> 2016-08-19 15:02 GMT+02:00 Andy Shevchenko :
>>> On Fri, Aug 19, 2016 at 1:35 PM, karol herbst wrote:
>>>> is there any update on that issue I missed somehow? I r
2016-08-19 15:02 GMT+02:00 Andy Shevchenko :
> On Fri, Aug 19, 2016 at 1:35 PM, karol herbst wrote:
>> is there any update on that issue I missed somehow? I really don't
>> want to leave the mmiotracer in a state, where it breaks something
>> while fixing other issues
Hi everybody,
is there any update on that issue I missed somehow? I really don't
want to leave the mmiotracer in a state, where it breaks something
while fixing other issues.
But for now, without being able to even reproduce the issue, I can't
really do much, because the code in the current state
hi all,
mhhh exactly this commit fixed mmiotrace for me and a few other
nouveau devs on x86_64.
Also the error log doesn't really show a problem inside the tracer?
Maybe it would be helpful to provide full dmesg in the case of error,
just to rule silly things out.
I will try to figure out how th
Hi Colin,
thanks for pointing this out, but I am quite sure this continue
statement won't ever be hit, ever.
check the nvkm_iccsense_create_sensor function. A sensor object will
only be created for one of those three types and others don't exist.
I've just added that default statement to shut GCC
2016-05-06 12:16 GMT+02:00 Pekka Paalanen :
> On Wed, 4 May 2016 14:17:13 -0500
> Bjorn Helgaas wrote:
>
>> 138295373ccf ("ftrace: mmiotrace update, #2") added this use of
>> pci_resource_to_user():
>>
>> +static int mmio_print_pcidev(struct trace_seq *s, const struct pci_dev
>> *dev)
>> +{
>
fe this check is probably not required"
> > and kfreeaddr.cocci by Julia Lawall.
> >
> > Generated by: scripts/coccinelle/free/ifnullfree.cocci
> >
> > CC: Karol Herbst
> > Signed-off-by: Fengguang Wu
> Signed-off-by: Martin Peres
Signed-off-by: Karol Herbst
> >
> > Generated by: scripts/coccinelle/misc/semicolon.cocci
> >
> > CC: Martin Peres
> > Signed-off-by: Fengguang Wu
> Signed-off-by: Martin Peres
Signed-off-by: Karol Herbst
one note though:
I am not _really_ sure it is the right flag. I've contacted somebody at nvidia
and asked for documentation regarding this mmio reg.
I still get some random wakeups and I don't know where they are comming from.
> Karol Herbst hat am 10. März 2016 um 15:5
From: Karol Herbst
I want to use my mac mini as a local server, but put it to sleep automatically
therefore wol p, and because wol g is a mess if you want to wakeup the target
machine automagically :)
Karol Herbst (2):
net/forcedeth: refactor wol support to make it easier adding more
Signed-off-by: Karol Herbst
---
drivers/net/ethernet/nvidia/forcedeth.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c
b/drivers/net/ethernet/nvidia/forcedeth.c
index 75e88f4..bdce33b 100644
--- a
REd on my mac mini. No idea if that also works on other ethernet cards
supported by forcedeth, but I doubt anybody cares at all, otherwise somebody
else would have REd it already.
Signed-off-by: Karol Herbst
---
drivers/net/ethernet/nvidia/forcedeth.c | 9 -
1 file changed, 8 insertions
Commit-ID: cfa52c0cfa4d727aa3e457bf29aeff296c528a08
Gitweb: http://git.kernel.org/tip/cfa52c0cfa4d727aa3e457bf29aeff296c528a08
Author: Karol Herbst
AuthorDate: Thu, 3 Mar 2016 02:03:11 +0100
Committer: Ingo Molnar
CommitDate: Sat, 5 Mar 2016 13:24:41 +0100
x86/mm/kmmio: Fix mmiotrace
1 - 100 of 102 matches
Mail list logo
