M_BITS'
Add a dependency for Nouveau to avoid broken randconfig builds.
Fixes: d2c63df2242e ("mm/hmm: make CONFIG_DEVICE_PRIVATE into a select")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/nouveau/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/
On Fri, May 8, 2020 at 5:00 PM Jason Gunthorpe wrote:
>
> On Fri, May 08, 2020 at 04:40:09PM +0200, Arnd Bergmann wrote:
> > CONFIG_DEVICE_PRIVATE cannot be selected in configurations
> > without ZONE_DEVICE:
>
> It is kind of unfortunate to lift dependencies from DEVICE_
On Fri, May 8, 2020 at 9:04 PM Jason Gunthorpe wrote:
>
> On Fri, May 08, 2020 at 05:05:03PM +0200, Arnd Bergmann wrote:
> > On Fri, May 8, 2020 at 5:00 PM Jason Gunthorpe wrote:
> > >
> > > On Fri, May 08, 2020 at 04:40:09PM +0200, Arnd Bergmann wrote:
> >
ffers'
The change seems to have been intentional, so add an explicit
dependency here but allow it to still be compiled if FBDEV
is completely disabled.
Fixes: 2dd4d163cd9c ("drm/nouveau: remove open-coded version of
remove_conflicting_pci_framebuffers()")
Signed-off-by: Arnd Bergma
On Wed, May 27, 2020 at 4:05 PM Ilia Mirkin wrote:
>
> Isn't this already fixed by
>
> https://cgit.freedesktop.org/drm/drm/commit/?id=7dbbdd37f2ae7dd4175ba3f86f4335c463b18403
Ok, I see that fixes the link error, but I when I created my fix, that did
not seem like the correct solution because it
On Thu, May 28, 2020 at 7:37 AM Dave Airlie wrote:
>
> On Thu, 28 May 2020 at 00:36, Arnd Bergmann wrote:
> >
> > On Wed, May 27, 2020 at 4:05 PM Ilia Mirkin wrote:
> > >
> > > Isn't this already fixed by
> > >
>
in softirq
> 2 maps in interrupt
>
> So a total of 16 is sufficient and probably overestimated.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Arnd Bergmann
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
From: Arnd Bergmann
I noticed a warning from 'nm' when CONFIG_TRIM_UNUSED_KSYMS is set
and IS_REACHABLE(CONFIG_AGP) is false:
drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.o: no symbols
I later found this is completely harmless and we should find a way
to suppress the warning, but at
On Fri, Jul 23, 2021 at 6:34 PM Karol Herbst wrote:
> On Fri, Jul 23, 2021 at 6:31 PM Randy Dunlap wrote:
> > On 7/23/21 8:15 AM, Karol Herbst wrote:
> > > On Fri, Jul 23, 2021 at 5:10 PM Randy Dunlap
> > > wrote:
> > >
> > > what's actually the use case of compiling with
> > > CONFIG_DRM_NOUVE
On Fri, Jul 23, 2021 at 11:25 AM Daniel Vetter wrote:
>
> On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > When the backlight support is disabled, the driver fails to build:
> >
> > drivers/gp
From: Arnd Bergmann
When the backlight support is disabled, the driver fails to build:
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 'nv50_sor_atomic_disable':
drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
nouveau_connector' has no member nam
On Sat, Jul 24, 2021 at 11:55 AM Karol Herbst wrote:
>
> On Sat, Jul 24, 2021 at 8:55 AM Arnd Bergmann wrote:
> >
> > On Sat, Jul 24, 2021 at 12:47 AM Karol Herbst wrote:
> > >
> > > In the past this only led to compilation issues. Also the small amount o
On Sat, Jul 24, 2021 at 2:52 PM Karol Herbst wrote:
>
> On Sat, Jul 24, 2021 at 2:10 PM Karol Herbst wrote:
> >
> > On Sat, Jul 24, 2021 at 1:56 PM Arnd Bergmann wrote:
> > >
> > > On Sat, Jul 24, 2021 at 11:55 AM Karol Herbst wrote:
> > >
> &g
On Sat, Jul 24, 2021 at 4:14 PM Karol Herbst wrote:
>
> we use the MXM_WMI in code. We also have to keep arm in mind and not
> break stuff there. So I will try to play around with your changes and
> see how that goes.
Ok, should find any randconfig build failures for arm, arm64 or x86 over the
we
On Sat, Jul 24, 2021 at 12:47 AM Karol Herbst wrote:
>
> In the past this only led to compilation issues. Also the small amount of
> extra .text shouldn't really matter compared to the entire nouveau driver
> anyway.
>
> select DRM_TTM_HELPER
> - select BACKLIGHT_CLASS_DEVICE if DRM
On Thu, Aug 5, 2021 at 12:01 AM Karol Herbst wrote:
>
> On Wed, Aug 4, 2021 at 11:10 PM Arnd Bergmann wrote:
> >
> > On Wed, Aug 4, 2021 at 8:59 PM Karol Herbst wrote:
> > > On Wed, Aug 4, 2021 at 4:43 PM Karol Herbst wrote:
> > > > On Wed, Aug
On Wed, Aug 4, 2021 at 4:10 PM Karol Herbst wrote:
>
> playing around a little bit with this, I think the original "select
> BACKLIGHT_CLASS_DEVICE" is fine. Atm we kind of have this weird mix of
> drivers selecting and others depending on it. We could of course convert
> everything over to depend
On Wed, Aug 4, 2021 at 8:59 PM Karol Herbst wrote:
> On Wed, Aug 4, 2021 at 4:43 PM Karol Herbst wrote:
> > On Wed, Aug 4, 2021 at 4:19 PM Arnd Bergmann wrote:
> > > On Wed, Aug 4, 2021 at 4:10 PM Karol Herbst wrote:
> > > >
> > > > playing around a
On Mon, Aug 9, 2021 at 3:20 PM Jani Nikula wrote:
>
> On Sat, 24 Jul 2021, Arnd Bergmann wrote:
> > On Sat, Jul 24, 2021 at 4:14 PM Karol Herbst wrote:
> >>
> >> we use the MXM_WMI in code. We also have to keep arm in mind and not
> >> break stuff there.
From: Arnd Bergmann
This is a follow-up on a couple of patch series I sent in the past,
enabling -Wextra (aside from stuff that is explicitly disabled),
-Wcast-function-pointer-strict and -Wrestrict.
I have tested these on 'defconfig' and 'allmodconfig' builds across
all ar
From: Arnd Bergmann
Calling a function through an incompatible pointer type causes breaks
kcfi, so clang warns about the assignment:
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c:73:10: error: cast from
'void (*)(const void *)' to 'void (*)(void *)' converts to in
On Tue, Mar 26, 2024, at 16:20, Timur Tabi wrote:
> 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_f
From: Arnd Bergmann
Calling a function through an incompatible pointer type causes breaks
kcfi, so clang warns about the assignment:
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c:73:10: error: cast from
'void (*)(const void *)' to 'void (*)(void *)' converts to in
On Mon, Apr 29, 2024, at 19:08, Timur Tabi wrote:
> 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-
On Sun, Jul 14, 2024, at 23:46, Jeff Johnson wrote:
> Andrew & Greg,
>
> I hate to bother you with such mundane patches, but the following have been
> posted for a while without any maintainer or reviewer comment or action, and
> they have not yet landed in linux-next.
>
> What is the path forward
e memory under the address
> so they can be converted to a "const" version for const-safety and
> consistency among architectures.
>
> Suggested-by: Geert Uytterhoeven
> Signed-off-by: Krzysztof Kozlowski
> Reviewed-by: Geert Uytterhoeven
Thanks for getting this done!
R
On Wed, Jan 8, 2020 at 9:36 AM Christophe Leroy wrote:
> Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :
> > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven
> > wrote:
> > I'll add to this one also changes to ioreadX_rep() and add another
> > patch for volatile for reads and writes. I guess
On Tue, Jan 7, 2020 at 5:54 PM Krzysztof Kozlowski wrote:
>
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the
> address so they can be
On Tue, Jan 7, 2020 at 5:54 PM Krzysztof Kozlowski wrote:
>
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
> so they can be
On Wed, Jan 8, 2020 at 10:15 AM Krzysztof Kozlowski wrote:
> > The __force-cast that removes the __iomem here also means that
> > the 'volatile' keyword could be dropped from the argument list,
> > as it has no real effect any more, but then there are a few drivers
> > that mark their iomem point
it a
nul-terminated string.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
index dde89a4a0f5b.
-Werror=int-in-bool-context]
Adding a temporary variable to contain the divisor helps make
it clear what is going on and avoids that warning.
Fixes: 7632b30e4b8b ("drm/nouveau/clk: namespace + nvidia gpu names (no binary
change)")
Signed-off-by: Arnd Bergmann
---
Originally submitte
nd simplify the code at the cost
of always doing the kmalloc (as we do in the current version).
Fixes: 920d2b5ef215 ("drm/nouveau/mmu: define user interfaces to mmu vmm
opertaions")
Signed-off-by: Arnd Bergmann
---
Cc: Martin Sebor
Martin: this one is interesting, I think it qualifies as
make it into mainline.
It's likely that some of these have already been fixed since
this morning's linux-next, so just ignore the ones are no
longer needed.
[resending because of missing Cc list for the actual patches,
sorry about that]
Arnd Bergmann (5):
headers_check: don'
m_object_lookup' from incompatible pointer type
[-Werror=incompatible-pointer-types]
obj = drm_gem_object_lookup(dev, file_priv, handle);
This fixes the new caller as well.
Signed-off-by: Arnd Bergmann
Fixes: a8ad0bd84f98 ("drm: Remove unused drm_device from
drm_gem_object_lookup
make it into mainline.
It's likely that some of these have already been fixed since
this morning's linux-next, so just ignore the ones are no
longer needed.
Arnd Bergmann (5):
headers_check: don't warn about c++ guards
drm: mediatek: add CONFIG_OF dependency
drm:
l
usr/include/drm/i810_drm.h:7: userspace cannot reference function or variable
defined in the kernel
This changes the headers_check.pl script to not warn about this.
I'm listing the merge commit as introducing the problem, because
there are several patches in this branch that each do this
riable 'dev'
[-Werror=unused-variable]
drm/radeon/radeon_cs.c: In function 'radeon_cs_parser_relocs':
drm/radeon/radeon_cs.c:77:21: error: unused variable 'ddev'
[-Werror=unused-variable]
This fixes all the instances I found with ARM randconfig builds so far.
Signed
inside of
an #ifdef, but some functions they call are not.
This patch removes the #ifdef and instead marks the PM functions
as __maybe_unused, which is a more reliable way to get it right.
Signed-off-by: Arnd Bergmann
Fixes: 9be7e9898444 ("drm/exynos/hdmi: clock code re-factoring"
undefined reference to
`of_find_device_by_node'
This adds an explicit Kconfig dependency.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/mediatek/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index 545973f6b74
On Tuesday 30 August 2016, Baoyou Xie wrote:
> On 30 August 2016 at 00:01, Sean Paul wrote:
>
> > On Mon, Aug 29, 2016 at 9:02 AM, Baoyou Xie wrote:
> > > We get 1 warning when build kernel with W=1:
> > > drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c:937:1: warning: no
> > previous prototyp
each part does one
thing.
After you do that, it also becomes easier to write a good subject line like
"mark
function as static" and "add missing includes", which tells you more about the
patch
than "silence warnings".
It's quite likely that the nouveau maintain
is declared in disp.h, so this patch
> add missing header dependencies
>
> Signed-off-by: Baoyou Xie
>
Acked-by: Arnd Bergmann
a few general notes:
- please use my a...@arndb.de address on patch submissions, not the linaro
address.
- for the email subject lines, have a look a
AL here is correct even if
the caller changed, and it avoids the warning on gcc-4.9 as well.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nou
21d71b324 ("drm/nouveau/drm/nouveau: add a LED driver for the NVIDIA
logo")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/nouveau/Kbuild| 2 +-
drivers/gpu/drm/nouveau/Kconfig | 8
drivers/gpu/drm/nouveau/nouveau_led.h | 2 +-
3 files changed, 10 insertion
On Tuesday, November 8, 2016 10:46:07 AM CET Ilia Mirkin wrote:
> > diff --git a/drivers/gpu/drm/nouveau/Kconfig
> > b/drivers/gpu/drm/nouveau/Kconfig
> > index 78631fb61adf..715cd6f4dc31 100644
> > --- a/drivers/gpu/drm/nouveau/Kconfig
> > +++ b/drivers/gpu/drm/nouveau/Kconfig
> > @@ -46,6 +46,14
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" or
> > "
rm/nouveau/nouveau_drm.c:730:1: error: old-style function
definition [-Werror=old-style-definition]
Fixes: 321f5c5f2c49 ("drm/nouveau: replace multiple open-coded runpm support
checks with function")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
1 file chan
al 'return'
statement.
Fixes: 7632b30e4b8b ("drm/nouveau/clk: namespace + nvidia gpu names (no binary
change)")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/g
eo driver that explicitly selects 'THERMAL'. Turning
this into a 'depends on' addresses the problem.
For completeness, I'm also removing the redundant 'select THERMAL'
from INTEL_MENLOW, so no other driver uses that statement.
Fixes: bcdfb5e56dc5 ("drm/etnaviv:
users of BACKLIGHT_CLASS_DEVICE also select
BACKLIGHT_LCD_SUPPORT, but not all of them do. This makes the remaining
ones behave like the others.
It would probably be best to rework the way those two options related
entirely, but for now this takes the simpler and safer approach to
fix the war
r dependency with X86_PLATFORM_DEVICES/NOUVEAU.
Signed-off-by: Arnd Bergmann
---
drivers/acpi/Kconfig| 5 -
drivers/gpu/drm/gma500/Kconfig | 6 +-
drivers/gpu/drm/i915/Kconfig| 7 +--
drivers/gpu/drm/nouveau/Kconfig | 10 ++
drivers/platform/x86/Kconfi
h 'depends on LCD_CLASS_DEVICE', that would clean
it up some more, but it is also a more invasive change that we
can do separately at some point.
Arnd
Arnd Bergmann (3):
backlight: always select BACKLIGHT_LCD_SUPPORT for
BACKLIGHT_CLASS_DEVICE
ACPI/DRM: rework ACPI_VIDEO
al 'return'
statement.
Fixes: 7632b30e4b8b ("drm/nouveau/clk: namespace + nvidia gpu names (no binary
change)")
Signed-off-by: Arnd Bergmann
---
Originally submitted on July 14, but no reply. This is the same
patch again. The warning is currently disabled in mainline, but
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
>> the warning. To further improve readability, I also make the
>> error case indented and leave the normal ca
On Wed, Sep 6, 2017 at 10:15 PM, Karol Herbst wrote:
> On Wed, Sep 6, 2017 at 10:11 PM, Arnd Bergmann wrote:
>>> but with a better name for "denominator".
>>
>> I don't know what M and P actually are in this function, so I couldn't
>> come u
-Werror=int-in-bool-context]
Adding a temporary variable to contain the divisor helps make
it clear what is going on and avoids that warning.
Fixes: 7632b30e4b8b ("drm/nouveau/clk: namespace + nvidia gpu names (no binary
change)")
Signed-off-by: Arnd Bergmann
---
Originally submitted
From: Arnd Bergmann
gcc-13 complains about a mismatched function declaration:
drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for
'nv50_wndw_new_' due to enum/integer mismatch; have 'int(const struct
nv50_wndw_func *, struct drm_device *, enum drm_pla
From: Arnd Bergmann
tu102_gr_load() is completely unused and can be removed to address
this warning:
drivers/gpu/drm/nouveau/dispnv50/disp.c:2517:1: error: no previous prototype
for 'nv50_display_create'
Fixes: 1cd97b5490c8 ("drm/nouveau/gr/tu102-: use sw_veid_bundle_init
From: Arnd Bergmann
nv50_display_create() is declared in another header, along with
a couple of declarations that are now outdated:
drivers/gpu/drm/nouveau/dispnv50/disp.c:2517:1: error: no previous prototype
for 'nv50_display_create'
Fixes: ba801ef068c1 ("drm/nouveau/kms:
From: Arnd Bergmann
tu102_gr_load() is completely unused and can be removed to address
this warning:
drivers/gpu/drm/nouveau/dispnv50/disp.c:2517:1: error: no previous prototype
for 'nv50_display_create'
Another patch was sent in the meantime to mark the function static but
that
From: Arnd Bergmann
After a recent change, two variables are only used in an #ifdef:
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 'nv50_sor_atomic_disable':
drivers/gpu/drm/nouveau/dispnv50/disp.c:1569:13: error: unused variable 'ret'
[-Werror=unused-variable]
15
From: Arnd Bergmann
The conversion to kvcalloc() mixed up the object size and count
arguments, causing a warning:
drivers/gpu/drm/nouveau/nouveau_svm.c: In function
'nouveau_svm_fault_buffer_ctor':
drivers/gpu/drm/nouveau/nouveau_svm.c:1010:40: error: 'kvcalloc' sizes
sp
From: Arnd Bergmann
clang-16 warns about casting between incompatible function types:
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c:161:10: error: cast from
'void (*)(const struct firmware *)' to 'void (*)(void *)' converts to
incompatible function type [-Werror,
64 matches
Mail list logo