from:"Joe"

Re: [PATCH] drm/nouveau/nvif: Avoid build error due to potential integer overflows

2024-05-18 Thread Joe Perches

On Sat, 2024-05-18 at 11:23 -0700, Guenter Roeck wrote:
> On 5/18/24 10:32, Kees Cook wrote:
> 
[]
> > I think the INT_MAX test is actually better in this case because
> > nvif_object_ioctl()'s size argument is u32:
> > 
> > ret = nvif_object_ioctl(object, args, sizeof(*args) + size, NULL);
> >
> > 
> > So that could wrap around, even though the allocation may not.
> > 
> > Better yet, since "sizeof(*args) + size" is repeated 3 times in the
> > function, I'd recommend:
> > 
> > ...
> > u32 args_size;
> > 
> > if (check_add_overflow(sizeof(*args), size, _size))
> > return -ENOMEM;
> > if (args_size > sizeof(stack)) {
> > if (!(args = kmalloc(args_size, GFP_KERNEL)))

trivia:

More typical kernel style would use separate alloc and test

args = kmalloc(args_size, GFP_KERNEL);
if (!args)

> > return -ENOMEM;
> >  } else {
> >  args = (void *)stack;
> >  }
> > ...
> >  ret = nvif_object_ioctl(object, args, args_size, NULL);
> > 
> > This will catch the u32 overflow to nvif_object_ioctl(), catch an
> > allocation underflow on 32-bits systems, and make the code more
> > readable. :)
> > 
> 
> Makes sense. I'll change that and send v2.
> 
> Thanks,
> Guenter
> 
>

Re: [Nouveau] [PATCH] drm/nouveau/mmu: Fix a typo

2022-06-21 Thread Joe Perches

On Wed, 2022-06-22 at 09:52 +0800, Zhang Jiaming wrote:
> There is a typo in comments. Change 'neeed' to 'need'.
[]
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
[]
> @@ -280,7 +280,7 @@ nvkm_vmm_unref_ptes(struct nvkm_vmm_iter *it, bool pfn, 
> u32 ptei, u32 ptes)
>   if (desc->type == SPT && (pgt->refs[0] || pgt->refs[1]))
>   nvkm_vmm_unref_sptes(it, pgt, desc, ptei, ptes);
>  
> - /* PT no longer neeed?  Destroy it. */
> + /* PT no longer need?  Destroy it. */

needed

Re: [Nouveau] Hardware decoding in video playback with Nvidia GT 218 (NVA8)

2022-05-30 Thread Joe

First of all really thanks for your quick reply!
I followed your suggests:
--
$ cat /etc/X11/xorg.conf.d/20-nouveau.conf
Section "Device"
Identifier "Nvidia card"
Driver "nouveau"
Option   "DRI" "3"
EndSection


After rebooting, I test various ways, by using mpv, with -vo=vdpau
-hwdec=vdpau",
using mplayer string you suggested in your link:

mplayer -vo vdpau -vc
ffmpeg12vdpau,ffwmv3vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau, 

But without luck...
With Option "DRI" "3", I also noticed a worse response during playback, video
colors not proper and after a bit it is blocked. I can't close mplayer window,
after pressing "q" whole system results crashed and have to hard power off
for rebooting again.

If you need more details about video file format used to test please
let me know,
anyway I tried with a 1080p video and 50 FPS, so that it should be a
bit lighter to
decode and manage by the low budget chip of my card.

I also would ask for a question: in your testing experience are you used same
GPU of mine GT218 (see details in my previous message) ?
Is it known it should be working on hardware video decoding with
nouveau drivers?

If some other tests or some involved software recompile could be solve
this issue,
I'm ready to follow your instructions for what are my skills (poor
skills!  ;) ).
Otherwise I'll give up and re-switch to nvidia closed drivers.

Thanks again!

On Mon, May 30, 2022 at 1:26 AM Ilia Mirkin  wrote:
>
> Hi Joe,
>
> On Sun, May 29, 2022 at 6:58 PM Joe  wrote:
> >
> > Hi all, I'm trying to make running hardware acceleration decoding on
> > my old GeForce 210 (AKA GT-218, or NVA8 / NV-50 Tesla family).
> > --
> > 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218
> > [GeForce 210] [10de:0a65] (rev a2)
> > --
> > [ ... ]
> >
> > But when I touch something, for instance "f" to enlarge to fullscreen,
> > or "q" to quit MPV...
> > Surprise!
> >
> > My system freeze, nothing work again, just the mouse cursor can still
> > be moved around.
> >
> > [ ... ]
> >
> > I'd like to use open drivers, but I'd like to take advantage of
> > hardware decoding too, so that my CPU rests as quiet and fresh as
> > possible. Is there some other suggest to configure some other aspect
> > and try to achieve my scope?
> > Or my tests are all I can do?
> > So for hwdec is better to switch back to closed source nvidia driver
> > legacy 340.108 ?
>
> Proprietary driver will definitely work better for hwdec than nouveau.
> Forgetting about any stability/performance issues, there are some
> reference frame ordering issues in H.264 decoding that were never
> addressed. This leads to occasional corruption in some videos.
>
> FWIW I've mostly tested with mplayer, and I didn't run into problems
> there. There should be instructions on using mplayer at
> https://nouveau.freedesktop.org/VideoAcceleration.html. The thing you
> esp want to avoid is using VDPAU + GL in the same process -- so things
> like "-vo vdpau" are much more likely to work than "-vo gpu" or "-vo
> gl". You can try enabling DRI3 -- perhaps something broke in the DRI2
> paths. You can add
>
> Option "DRI" "3"
>
> into the Driver section of the xorg.conf to expose it. It's not on by
> default because there are some annoying corner cases that some window
> managers run into with it (KDE as I recall).
>
> I'm also not sure why VA-API is corrupted for you, it has worked in
> the past. But it gets a lot of changes only reviewed by AMD
> developers, so it can get broken pretty easily with AMD-specific
> assumptions which don't hold on NVIDIA. I suspect it should be easy to
> fix by someone who is interested in investigating -- probably a bisect
> to sort out what broke it, and then revert or get the person who wrote
> it to fix it.
>
> Cheers,
>
>   -ilia

[Nouveau] Hardware decoding in video playback with Nvidia GT 218 (NVA8)

2022-05-29 Thread Joe

Hi all, I'm trying to make running hardware acceleration decoding on
my old GeForce 210 (AKA GT-218, or NVA8 / NV-50 Tesla family).
--
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218
[GeForce 210] [10de:0a65] (rev a2)
--

I usually used proprietary nvidia-legacy340.108 driver and it works
quite well even if I noticed some A-V sync (or a bit of frame
dropping) issues during video playback of some videos having 1080p and
60 FPS (h264 encoded). Those issues seem solved by turn off hardware
decoding.
With MPV player and closed nvidia driver I used options:

"-vo=gpu -hwdec=auto"

And it automatically chooses "vdpau" decoding. CPU rests on 5% of load
and so on...

But I read about good if not better performances of some nvidia cards
by using Nouveau open drivers, especially for old GPUs which could
have poorly updated/maintained proprietary driver. So I decided to
switch to open ones.

I'm using Slackware64-15.0 with multilib support.
It runs kernel 5.15.38.

I read on nouveau page about the need of some files extracted from
proprietary driver, a closed firmware for video hardware decoding. On
slackware it is provided by SlackBuilds community:

https://slackbuilds.org/repository/15.0/system/nvidia-firmware/

It populated /lib/firmware/nouveau with variuos files I think related to my GPU:
--
$ file /lib/firmware/nouveau/nva{3_{b,p,v},8}*
/lib/firmware/nouveau/nva3_bsp:data
/lib/firmware/nouveau/nva3_ppp:data
/lib/firmware/nouveau/nva3_vp: data
/lib/firmware/nouveau/nva8_fuc084: symbolic link to nva3_bsp
/lib/firmware/nouveau/nva8_fuc085: symbolic link to nva3_vp
/lib/firmware/nouveau/nva8_fuc086: symbolic link to nva3_ppp


I also enable "nouveau" in /etc/X11/xorg.conf.d/20-nouveau
--
$ cat /etc/X11/xorg.conf.d/20-nouveau.conf
Section "Device"
Identifier "Nvidia card"
Driver "nouveau"
EndSection
--

Here is env-var VDPAU_DRIVER defined to "nouveau"
--
$ grep -v "^#\|^$" /etc/profile.d/vdpau.sh
export VDPAU_LOG=0
export VDPAU_DRIVER="nouveau"
-

On my system are installed:
-
libvdpau-1.4-x86_64-3
libvdpau-compat32-1.4-x86_64-3compat32
--

The second one is related to multilib environment.

Now some infos about vdpau:
---
$ vdpauinfo
display: :0   screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name   width height types
---
420 8192  8192  NV12 YV12
422 8192  8192  UYVY YUYV
444 8192  8192  Y8U8V8A8 V8U8Y8A8
420_16  8192  8192
422_16  8192  8192
444_16  8192  8192

Decoder capabilities:

namelevel macbs width height

MPEG1   0  8192  2048  2048
MPEG2_SIMPLE3  8192  2048  2048
MPEG2_MAIN  3  8192  2048  2048
H264_BASELINE  41  8192  2048  2048
H264_MAIN  41  8192  2048  2048
H264_HIGH  41  8192  2048  2048
VC1_SIMPLE  1  8190  2048  2048
VC1_MAIN2  8190  2048  2048
VC1_ADVANCED4  8190  2048  2048
MPEG4_PART2_SP  3  8192  2048  2048
MPEG4_PART2_ASP 5  8192  2048  2048
DIVX4_QMOBILE  --- not supported ---
DIVX4_MOBILE   --- not supported ---
DIVX4_HOME_THEATER --- not supported ---
DIVX4_HD_1080P --- not supported ---
DIVX5_QMOBILE  --- not supported ---
DIVX5_MOBILE   --- not supported ---
DIVX5_HOME_THEATER --- not supported ---
DIVX5_HD_1080P --- not supported ---
H264_CONSTRAINED_BASELINE  41  8192  2048  2048
H264_EXTENDED  --- not supported ---
H264_PROGRESSIVE_HIGH  --- not supported ---
H264_CONSTRAINED_HIGH  --- not supported ---
H264_HIGH_444_PREDICTIVE   --- not supported ---
VP9_PROFILE_0  --- not supported ---
VP9_PROFILE_1  --- not supported ---
VP9_PROFILE_2  --- not supported ---
VP9_PROFILE_3  --- not supported ---
HEVC_MAIN  --- not supported ---
HEVC_MAIN_10   --- not supported ---
HEVC_MAIN_STILL--- not supported ---
HEVC_MAIN_12   --- not supported ---
HEVC_MAIN_444  --- not supported ---
HEVC_MAIN_444_10   --- not supported ---
HEVC_MAIN_444_12   --- not supported ---

Output surface:

name  width height nat types

Re: [Nouveau] [PATCH 1/6] drivers: usb: remove usage of list iterator past the loop body

2022-02-28 Thread Joe Perches

On Mon, 2022-02-28 at 14:24 +0300, Dan Carpenter wrote:

> a multi-line indent gets curly braces for readability even though
> it's not required by C.  And then both sides would get curly braces.

That's more your personal preference than a coding style guideline.

Re: [Nouveau] [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation

2022-01-20 Thread Joe Perches

On Wed, 2022-01-19 at 16:00 -0500, Steven Rostedt wrote:
> On Wed, 19 Jan 2022 21:25:08 +0200
> Andy Shevchenko  wrote:
> 
> > > I say keep it one line!
> > > 
> > > Reviewed-by: Steven Rostedt (Google)   
> > 
> > I believe Sakari strongly follows the 80 rule, which means...
> 
> Checkpatch says "100" I think we need to simply update the docs (the
> documentation always lags the code ;-)

checkpatch doesn't say anything normally, it's a stupid script.
It just mindlessly bleats a message when a line exceeds 100 chars...

Just fyi: I think it's nicer on a single line too.

Re: [Nouveau] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Joe Perches

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Joe Perches

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-22 Thread Joe Perches

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-22 Thread Joe Perches

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-20 Thread Joe Perches

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC] treewide: cleanup unreachable breaks

2020-10-20 Thread Joe Perches

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH  wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > From: Tom Rix 
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by 
> > > collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks

2020-10-18 Thread Joe Perches

On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote:
> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > clang has a number of useful, new warnings see
> > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$
> >  
> 
> Please get your IT department to remove that stupidity.  If you can't,
> please send email from a non-Red Hat email address.

I didn't get it this way, neither did lore.
It's on your end.

https://lore.kernel.org/lkml/20201017160928.12698-1-t...@redhat.com/

> I don't understand why this is a useful warning to fix.

Precision in coding style intent and code minimization
would be the biggest factors IMO.

> What actual problem is caused by the code below?

Obviously none.


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [Cocci] [RFC] treewide: cleanup unreachable breaks

2020-10-17 Thread Joe Perches

On Sat, 2020-10-17 at 20:21 +0200, Julia Lawall wrote:
> On Sat, 17 Oct 2020, Joe Perches wrote:
> > On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote:
> > > From: Tom Rix 
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by 
> > > collecting
> > > early acks.
> > > 
> > > clang has a number of useful, new warnings see
> > > https://clang.llvm.org/docs/DiagnosticsReference.html
> > > 
> > > This change cleans up -Wunreachable-code-break
> > > https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break
> > > for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64.
> > 
> > Early acks/individual patches by subsystem would be good.
> > Better still would be an automated cocci script.
> 
> Coccinelle is not especially good at this, because it is based on control
> flow, and a return or goto diverts the control flow away from the break.
> A hack to solve the problem is to put an if around the return or goto, but
> that gives the break a meaningless file name and line number.  I collected
> the following list, but it only has 439 results, so fewer than clang.  But
> maybe there are some files that are not considered by clang in the x86
> allyesconfig configuration.
> 
> Probably checkpatch is the best solution here, since it is not
> configuration sensitive and doesn't care about control flow.

Likely the clang compiler is the best option here.

It might be useful to add -Wunreachable-code-break to W=1
or just always enable it if it isn't already enabled.

diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index 95e4cdb94fe9..3819787579d5 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -32,6 +32,7 @@ KBUILD_CFLAGS += $(call cc-option, -Wunused-but-set-variable)
 KBUILD_CFLAGS += $(call cc-option, -Wunused-const-variable)
 KBUILD_CFLAGS += $(call cc-option, -Wpacked-not-aligned)
 KBUILD_CFLAGS += $(call cc-option, -Wstringop-truncation)
+KBUILD_CFLAGS += $(call cc-option, -Wunreachable-code-break)
 # The following turn off the warnings enabled by -Wextra
 KBUILD_CFLAGS += -Wno-missing-field-initializers
 KBUILD_CFLAGS += -Wno-sign-compare

(and thank you Tom for pushing this forward)

checkpatch can't find instances like:

case FOO:
if (foo)
return 1;
else
return 2;
break;

As it doesn't track flow and relies on the number
of tabs to be the same for any goto/return and break;

checkpatch will warn on:

case FOO:
...
goto bar;
break;


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC] treewide: cleanup unreachable breaks

2020-10-17 Thread Joe Perches

On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote:
> From: Tom Rix 
> 
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
> early acks.
> 
> clang has a number of useful, new warnings see
> https://clang.llvm.org/docs/DiagnosticsReference.html
> 
> This change cleans up -Wunreachable-code-break
> https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break
> for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64.

Early acks/individual patches by subsystem would be good.
Better still would be an automated cocci script.

The existing checkpatch test for UNNECESSARY_BREAK
has a few too many false positives.

>From a script run on next on July 28th:

arch/arm/mach-s3c24xx/mach-rx1950.c:266: WARNING:UNNECESSARY_BREAK: break is 
not useful after a goto or return
arch/arm/nwfpe/fpa11_cprt.c:38: WARNING:UNNECESSARY_BREAK: break is not useful 
after a goto or return
arch/arm/nwfpe/fpa11_cprt.c:41: WARNING:UNNECESSARY_BREAK: break is not useful 
after a goto or return
arch/mips/include/asm/mach-au1x00/au1000.h:684: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/mips/include/asm/mach-au1x00/au1000.h:687: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/mips/include/asm/mach-au1x00/au1000.h:690: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/mips/include/asm/mach-au1x00/au1000.h:693: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/mips/include/asm/mach-au1x00/au1000.h:697: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/mips/include/asm/mach-au1x00/au1000.h:700: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:276: 
WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return
arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:279: 
WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return
arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:282: 
WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return
arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:287: 
WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return
arch/mips/loongson2ef/common/cs5536/cs5536_isa.c:290: 
WARNING:UNNECESSARY_BREAK: break is not useful after a goto or return
arch/mips/rb532/setup.c:76: WARNING:UNNECESSARY_BREAK: break is not useful 
after a goto or return
arch/mips/rb532/setup.c:79: WARNING:UNNECESSARY_BREAK: break is not useful 
after a goto or return
arch/powerpc/include/asm/kvm_book3s_64.h:231: WARNING:UNNECESSARY_BREAK: break 
is not useful after a goto or return
arch/powerpc/include/asm/kvm_book3s_64.h:234: WARNING:UNNECESSARY_BREAK: break 
is not useful after a goto or return
arch/powerpc/include/asm/kvm_book3s_64.h:237: WARNING:UNNECESSARY_BREAK: break 
is not useful after a goto or return
arch/powerpc/include/asm/kvm_book3s_64.h:240: WARNING:UNNECESSARY_BREAK: break 
is not useful after a goto or return
arch/powerpc/net/bpf_jit_comp.c:455: WARNING:UNNECESSARY_BREAK: break is not 
useful after a goto or return
arch/powerpc/platforms/cell/spufs/switch.c:2047: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/powerpc/platforms/cell/spufs/switch.c:2077: WARNING:UNNECESSARY_BREAK: 
break is not useful after a goto or return
arch/sh/boards/mach-landisk/gio.c:111: WARNING:UNNECESSARY_BREAK: break is not 
useful after a goto or return
arch/x86/kernel/cpu/mce/core.c:1734: WARNING:UNNECESSARY_BREAK: break is not 
useful after a goto or return
arch/x86/kernel/cpu/mce/core.c:1738: WARNING:UNNECESSARY_BREAK: break is not 
useful after a goto or return
arch/x86/kernel/cpu/microcode/amd.c:218: WARNING:UNNECESSARY_BREAK: break is 
not useful after a goto or return
drivers/acpi/utils.c:107: WARNING:UNNECESSARY_BREAK: break is not useful after 
a goto or return
drivers/acpi/utils.c:132: WARNING:UNNECESSARY_BREAK: break is not useful after 
a goto or return
drivers/acpi/utils.c:147: WARNING:UNNECESSARY_BREAK: break is not useful after 
a goto or return
drivers/acpi/utils.c:158: WARNING:UNNECESSARY_BREAK: break is not useful after 
a goto or return
drivers/ata/libata-scsi.c:3973: WARNING:UNNECESSARY_BREAK: break is not useful 
after a goto or return
drivers/base/power/main.c:366: WARNING:UNNECESSARY_BREAK: break is not useful 
after a goto or return
drivers/block/xen-blkback/blkback.c:1272: WARNING:UNNECESSARY_BREAK: break is 
not useful after a goto or return
drivers/char/ipmi/ipmi_devintf.c:493: WARNING:UNNECESSARY_BREAK: break is not 
useful after a goto or return
drivers/char/lp.c:625: WARNING:UNNECESSARY_BREAK: break is not useful after a 
goto or return
drivers/char/mwave/mwavedd.c:406: WARNING:UNNECESSARY_BREAK: break is not 
useful after a goto or return

Re: [Nouveau] [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

2020-09-11 Thread Joe Perches

On Thu, 2020-09-10 at 15:21 +0100, Robin Murphy wrote:
> On 2020-09-09 21:06, Joe Perches wrote:
> > fallthrough to a separate case/default label break; isn't very readable.
> > 
> > Convert pseudo-keyword fallthrough; statements to a simple break; when
> > the next label is case or default and the only statement in the next
> > label block is break;
> > 
> > Found using:
> > 
> > $ grep-2.5.4 -rP --include=*.[ch] -n 
> > "fallthrough;(\s*(case\s+\w+|default)\s*:\s*){1,7}break;" *
> > 
> > Miscellanea:
> > 
> > o Move or coalesce a couple label blocks above a default: block.
> > 
> > Signed-off-by: Joe Perches 
> > ---
> > 
> > Compiled allyesconfig x86-64 only.
> > A few files for other arches were not compiled.
> > 
> 
> [...]
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c 
> > b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > index c192544e874b..743db1abec40 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > @@ -3777,7 +3777,7 @@ static int arm_smmu_device_hw_probe(struct 
> > arm_smmu_device *smmu)
> > switch (FIELD_GET(IDR0_TTF, reg)) {
> > case IDR0_TTF_AARCH32_64:
> > smmu->ias = 40;
> > -   fallthrough;
> > +   break;
> > case IDR0_TTF_AARCH64:
> > break;
> > default:
> 
> I have to say I don't really agree with the readability argument for 
> this one - a fallthrough is semantically correct here, since the first 
> case is a superset of the second. It just happens that anything we would 
> do for the common subset is implicitly assumed (there are other 
> potential cases we simply haven't added support for at the moment), thus 
> the second case is currently empty.
> This change actively obfuscates that distinction.

Then perhaps comments should be added to usefully
describe the mechanisms.

case IDR0_TTF_AARCH32_64:
smmu->ias = 40;
fallthrough;/* and still do the 64 bit processing */
case IDR0_TTF_AARCH64:
/* Nothing specific yet */
break;

> Robin.

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

2020-09-09 Thread Joe Perches

On Wed, 2020-09-09 at 19:36 -0300, Jason Gunthorpe wrote:
> On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
> > fallthrough to a separate case/default label break; isn't very readable.
> > 
> > Convert pseudo-keyword fallthrough; statements to a simple break; when
> > the next label is case or default and the only statement in the next
> > label block is break;
> > 
> > Found using:
> > 
> > $ grep-2.5.4 -rP --include=*.[ch] -n 
> > "fallthrough;(\s*(case\s+\w+|default)\s*:\s*){1,7}break;" *
> > 
> > Miscellanea:
> > 
> > o Move or coalesce a couple label blocks above a default: block.
> > 
> > Signed-off-by: Joe Perches 
> > ---
> > 
> > Compiled allyesconfig x86-64 only.
> > A few files for other arches were not compiled.
> 
> IB part looks OK, I prefer it like this
> 
> You could do the same for continue as well, I saw a few of those..

I saw some continue uses as well but wasn't sure
and didn't look to see if the switch/case with
continue was in a for/while loop.


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

2020-09-09 Thread Joe Perches

fallthrough to a separate case/default label break; isn't very readable.

Convert pseudo-keyword fallthrough; statements to a simple break; when
the next label is case or default and the only statement in the next
label block is break;

Found using:

$ grep-2.5.4 -rP --include=*.[ch] -n 
"fallthrough;(\s*(case\s+\w+|default)\s*:\s*){1,7}break;" *

Miscellanea:

o Move or coalesce a couple label blocks above a default: block.

Signed-off-by: Joe Perches 
---

Compiled allyesconfig x86-64 only.
A few files for other arches were not compiled.

 arch/arm/mach-mmp/pm-pxa910.c |  2 +-
 arch/arm64/kvm/handle_exit.c  |  2 +-
 arch/mips/kernel/cpu-probe.c  |  2 +-
 arch/mips/math-emu/cp1emu.c   |  2 +-
 arch/s390/pci/pci.c   |  2 +-
 crypto/tcrypt.c   |  4 ++--
 drivers/ata/sata_mv.c |  2 +-
 drivers/atm/lanai.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_sprite.c   |  2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmi.c   |  2 +-
 drivers/hid/wacom_wac.c   |  2 +-
 drivers/i2c/busses/i2c-i801.c |  2 +-
 drivers/infiniband/ulp/rtrs/rtrs-clt.c| 14 +++---
 drivers/infiniband/ulp/rtrs/rtrs-srv.c|  6 +++---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   |  2 +-
 drivers/irqchip/irq-vic.c |  4 ++--
 drivers/md/dm.c   |  2 +-
 drivers/media/dvb-frontends/drxd_hard.c   |  2 +-
 drivers/media/i2c/ov5640.c|  2 +-
 drivers/media/i2c/ov6650.c|  5 ++---
 drivers/media/i2c/smiapp/smiapp-core.c|  2 +-
 drivers/media/i2c/tvp5150.c   |  2 +-
 drivers/media/pci/ddbridge/ddbridge-core.c|  2 +-
 drivers/media/usb/cpia2/cpia2_core.c  |  2 +-
 drivers/mfd/iqs62x.c  |  3 +--
 drivers/mmc/host/atmel-mci.c  |  2 +-
 drivers/mtd/nand/raw/nandsim.c|  2 +-
 drivers/net/ethernet/intel/e1000e/phy.c   |  2 +-
 drivers/net/ethernet/intel/fm10k/fm10k_pf.c   |  2 +-
 drivers/net/ethernet/intel/i40e/i40e_adminq.c |  2 +-
 drivers/net/ethernet/intel/i40e/i40e_txrx.c   |  2 +-
 drivers/net/ethernet/intel/iavf/iavf_txrx.c   |  2 +-
 drivers/net/ethernet/intel/igb/e1000_phy.c|  2 +-
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c|  2 +-
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |  2 +-
 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c|  2 +-
 drivers/net/ethernet/intel/ixgbevf/vf.c   |  2 +-
 drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c |  2 +-
 drivers/net/ethernet/qlogic/qed/qed_mcp.c |  2 +-
 drivers/net/ethernet/sfc/falcon/farch.c   |  2 +-
 drivers/net/ethernet/sfc/farch.c  |  2 +-
 drivers/net/phy/adin.c|  3 +--
 drivers/net/usb/pegasus.c |  4 ++--
 drivers/net/usb/usbnet.c  |  2 +-
 drivers/net/wireless/ath/ath5k/eeprom.c   |  2 +-
 drivers/net/wireless/mediatek/mt7601u/dma.c   |  8 
 drivers/nvme/host/core.c  | 12 ++--
 drivers/pcmcia/db1xxx_ss.c|  4 ++--
 drivers/power/supply/abx500_chargalg.c|  2 +-
 drivers/power/supply/charger-manager.c|  2 +-
 drivers/rtc/rtc-pcf85063.c|  2 +-
 drivers/s390/scsi/zfcp_fsf.c  |  2 +-
 drivers/scsi/aic7xxx/aic79xx_core.c   |  4 ++--
 drivers/scsi/aic94xx/aic94xx_tmf.c|  2 +-
 drivers/scsi/lpfc/lpfc_sli.c  |  2 +-
 drivers/scsi/smartpqi/smartpqi_init.c |  2 +-
 drivers/scsi/sr.c |  2 +-
 drivers/tty/serial/sunsu.c|  2 +-
 drivers/tty/serial/sunzilog.c |  2 +-
 drivers/tty/vt/vt_ioctl.c |  2 +-
 drivers/usb/dwc3/core.c   |  2 +-
 drivers/usb/gadget/legacy/inode.c |  2 +-
 drivers/usb/gadget/udc/pxa25x_udc.c   |  4 ++--
 drivers/usb/host/ohci-hcd.c   |  2 +-
 drivers/usb/isp1760/isp1760-hcd.c |  2 +-
 drivers/usb/musb/

Re: [Nouveau] [PATCH][next] drm/nouveau: Use fallthrough pseudo-keyword

2020-07-07 Thread Joe Perches

On Wed, 2020-07-08 at 13:22 +1000, Ben Skeggs wrote:
> On Wed, 8 Jul 2020 at 03:31, Gustavo A. R. Silva  
> wrote:
> > Replace the existing /* fall through */ comments and its variants with
> > the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
> > fall-through markings when it is the case.
> I really like this!  I was not a fan of explicitly marking those with 
> comments.
> 
> Thank you, taken in my tree.
[]
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
[]
> > @@ -932,7 +932,7 @@ nv50_dp_bpc_to_depth(unsigned int bpc)
> > switch (bpc) {
> > case  6: return 0x2;
> > case  8: return 0x5;
> > -   case 10: /* fall-through */
> > +   case 10: fallthrough;

IMO: this comment/fallthrough should be removed instead.


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH -next 000/491] treewide: use fallthrough;

2020-03-30 Thread Joe Perches

There is a new fallthrough pseudo-keyword macro that can be used
to replace the various /* fallthrough */ style comments that are
used to indicate a case label code block is intended to fallthrough
to the next case label block.

See commit 294f69e662d1 ("compiler_attributes.h: Add 'fallthrough'
pseudo keyword for switch/case use")

These patches are intended to allow clang to detect missing
switch/case fallthrough uses.

Do a depth-first pass on the MAINTAINERS file and find the various
F: pattern files and convert the fallthrough comments to fallthrough;
for all files matched by all  F: patterns in in each section.

Done via the perl script below and the previously posted
cvt_fallthrough.pl script.

Link: 
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/

These patches are based on next-20200310 and are available in

git://repo.or.cz/linux-2.6/trivial-mods.git in branch 20200310_fallthrough_2

$ cat commit_fallthrough.pl
#!/usr/bin/env perl

use sort 'stable';

#
# Reorder a sorted array so file entries are before directory entries
# depends on a trailing / for directories
# so:
#   foo/
#   foo/bar.c
# becomes
#   foo/bar.c
#   foo/
#
sub file_before_directory {
my ($array_ref) = (@_);

my $count = scalar(@$array_ref);

for (my $i = 1; $i < $count; $i++) {
if (substr(@$array_ref[$i - 1], -1) eq '/' &&
substr(@$array_ref[$i], 0, length(@$array_ref[$i - 1])) eq 
@$array_ref[$i - 1]) {
my $string = @$array_ref[$i - 1];
@$array_ref[$i - 1] = @$array_ref[$i];
@$array_ref[$i] = $string;
}
}
}

sub uniq {
my (@parms) = @_;

my %saw;
@parms = grep(!$saw{$_}++, @parms);

return @parms;
}

# Get all the F: file patterns in MAINTAINERS that could be a .[ch] file
my $maintainer_patterns = `grep -P '^F:\\s+' MAINTAINERS`;
my @patterns = split('\n', $maintainer_patterns);
s/^F:\s*// for @patterns;
@patterns = grep(!/^(?:Documentation|tools|scripts)\//, @patterns);
@patterns = grep(!/\.(?:dtsi?|rst|config)$/, @patterns);
@patterns = sort @patterns;
@patterns = sort { $b =~ tr/\//\// cmp $a =~ tr/\//\// } @patterns;
file_before_directory(\@patterns);

my %sections_done;

foreach my $pattern (@patterns) {

# Find the files the pattern matches
my $pattern_files = `git ls-files -- $pattern`;
my @new_patterns = split('\n', $pattern_files);
$pattern_files = join(' ', @new_patterns);
next if ($pattern_files =~ /^\s*$/);

# Find the section the first file matches
my $pattern_file = @new_patterns[0];
my $section_output = `./scripts/get_maintainer.pl --nogit --nogit-fallback 
--sections --pattern-depth=1 $pattern_file`;
my @section = split('\n', $section_output);
my $section_header = @section[0];

print("Section: <$section_header>\n");

# Skip the section if it's already done
print("Already done '$section_header'\n") if 
($sections_done{$section_header});
next if ($sections_done{$section_header}++);

# Find all the .[ch] files in all F: lines in that section
my @new_section;
foreach my $line (@section) {
last if ($line =~ /^\s*$/);
push(@new_section, $line);
}
@section = grep(/^F:/, @new_section);
s/^F:\s*// for @section;

@section = grep(!/^(?:Documentation|tools|scripts)\//, @section);
@section = grep(!/\.(?:dtsi?|rst|config)$/, @section);
@section = sort @section;
@section = uniq(@section);

my $section_files = join(' ', @section);

print("section_files: <$section_files>\n");

next if ($section_files =~ /^\s*$/);

my $cvt_files = `git ls-files -- $section_files`;
my @files = split('\n', $cvt_files);

@files = grep(!/^(?:Documentation|tools|scripts)\//, @files);
@files = grep(!/\.(?:dtsi?|rst|config)$/, @files);
@files = grep(/\.[ch]$/, @files);
@files = sort @files;
@files = uniq(@files);

$cvt_files = join(' ', @files);
print("files: <$cvt_files>\n");

next if (scalar(@files) < 1);

# Convert fallthroughs for all [.ch] files in the section
print("doing cvt_fallthrough.pl -- $cvt_files\n");

`cvt_fallthrough.pl -- $cvt_files`;

# If nothing changed, nothing to commit
`git diff-index --quiet HEAD --`;
next if (!$?);

# Commit the changes
my $fh;

open($fh, "+>", "cvt_fallthrough.commit_msg") or die "$0: can't create 
temporary file: $!\n";
print $fh <https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git@perches.com/
EOF
;
close $fh;

`git commit -s -a -F cvt_fallthrough.commit_msg`;
}

Joe Perches (491):
  MELLANOX ETHERNET INNOVA DRIVERS: Use fallthrough;
  MARVELL OCTEONTX2 RVU ADMIN FUNCTION DRIVER: Use fallthrough;
  MELLANOX MLX5 core VPI driver: Use fallthrough;
  PERFORMANCE EVENTS SUBSYSTEM: Use fallthrough;
  ARM/UNI

Re: [Nouveau] [PATCH v4 2/6] drm/nouveau: Add NV_PRINTK_ONCE and variants

2018-09-06 Thread Joe Perches

On Thu, 2018-09-06 at 17:43 -0400, Lyude Paul wrote:
> Since we're about to use this in nouveau_backlight.c. Same thing as
> DRM_WARN_ONCE, DRM_INFO_ONCE, etc...

Can you redefine this in terms of the patches I submitted
instead?

https://lore.kernel.org/patchwork/patch/979598/
https://lore.kernel.org/patchwork/patch/979601/


> Signed-off-by: Lyude Paul 
> Cc: Karol Herbst 
> ---
>  drivers/gpu/drm/nouveau/nouveau_drv.h | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
> b/drivers/gpu/drm/nouveau/nouveau_drv.h
> index 6e1acaec3400..d9d687916553 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> @@ -244,10 +244,12 @@ void nouveau_drm_device_remove(struct drm_device *dev);
>   struct nouveau_cli *_cli = (c);\
>   dev_##l(_cli->drm->dev->dev, "%s: "f, _cli->name, ##a);\
>  } while(0)
> +
>  #define NV_FATAL(drm,f,a...) NV_PRINTK(crit, &(drm)->client, f, ##a)
>  #define NV_ERROR(drm,f,a...) NV_PRINTK(err, &(drm)->client, f, ##a)
>  #define NV_WARN(drm,f,a...) NV_PRINTK(warn, &(drm)->client, f, ##a)
>  #define NV_INFO(drm,f,a...) NV_PRINTK(info, &(drm)->client, f, ##a)
> +
>  #define NV_DEBUG(drm,f,a...) do {
>   \
>   if (unlikely(drm_debug & DRM_UT_DRIVER))   \
>   NV_PRINTK(info, &(drm)->client, f, ##a);   \
> @@ -257,6 +259,12 @@ void nouveau_drm_device_remove(struct drm_device *dev);
>   NV_PRINTK(info, &(drm)->client, f, ##a);   \
>  } while(0)
>  
> +#define NV_PRINTK_ONCE(l,c,f,a...) NV_PRINTK(l##_once,c,f, ##a)
> +
> +#define NV_ERROR_ONCE(drm,f,a...) NV_PRINTK_ONCE(err, &(drm)->client, f, ##a)
> +#define NV_WARN_ONCE(drm,f,a...) NV_PRINTK_ONCE(warn, &(drm)->client, f, ##a)
> +#define NV_INFO_ONCE(drm,f,a...) NV_PRINTK_ONCE(info, &(drm)->client, f, ##a)
> +
>  extern int nouveau_modeset;
>  
>  #endif
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 1/2] drm/nouveau: Add new logging function nv_cli_printk

2018-08-30 Thread Joe Perches

NV_PRINTK is a macro that adds the "%s: ", nouveau_cli.name to
logging output.

Save a few KB by creating a specific function to add that name
and change the users of theh NV_PRINTK macros to use the new
logging function.

(size -t drivers/gpu/drm/nouveau/built-in.a x86/64 defconfig with nouveau)
   textdata bss dec hex filename
1737254  1084841048 1846786  1c2e02 (TOTALS) (new)
1740706  1084841048 1850238  1c3b7e (TOTALS) (old)

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 21 +
 drivers/gpu/drm/nouveau/nouveau_drv.h | 34 ++
 2 files changed, 43 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index c7ec86d6c3c9..aeca2ea3c4d1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1153,6 +1153,27 @@ nouveau_platform_device_create(const struct 
nvkm_device_tegra_func *func,
return ERR_PTR(err);
 }
 
+void nouveau_cli_printk(struct nouveau_cli *cli, const char *fmt, ...)
+{
+   struct va_format vaf;
+   va_list args;
+   char level[2] = {KERN_SOH_ASCII, 0};
+
+   level[1] = printk_get_level(fmt);
+   if (level[1] == 0)
+   level[1] = 'd';
+
+   va_start(args, fmt);
+
+   vaf.fmt = printk_skip_headers(fmt);
+   vaf.va = 
+
+   dev_printk(level, cli->drm->dev->dev, "%s: %pV",
+  cli->name, );
+
+   va_end(args);
+}
+
 static int __init
 nouveau_drm_init(void)
 {
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 6e1acaec3400..6110730d5df0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -244,18 +244,28 @@ void nouveau_drm_device_remove(struct drm_device *dev);
struct nouveau_cli *_cli = (c);\
dev_##l(_cli->drm->dev->dev, "%s: "f, _cli->name, ##a);\
 } while(0)
-#define NV_FATAL(drm,f,a...) NV_PRINTK(crit, &(drm)->client, f, ##a)
-#define NV_ERROR(drm,f,a...) NV_PRINTK(err, &(drm)->client, f, ##a)
-#define NV_WARN(drm,f,a...) NV_PRINTK(warn, &(drm)->client, f, ##a)
-#define NV_INFO(drm,f,a...) NV_PRINTK(info, &(drm)->client, f, ##a)
-#define NV_DEBUG(drm,f,a...) do {  
\
-   if (unlikely(drm_debug & DRM_UT_DRIVER))   \
-   NV_PRINTK(info, &(drm)->client, f, ##a);   \
-} while(0)
-#define NV_ATOMIC(drm,f,a...) do { 
\
-   if (unlikely(drm_debug & DRM_UT_ATOMIC))   \
-   NV_PRINTK(info, &(drm)->client, f, ##a);   \
-} while(0)
+
+__printf(2, 3)
+void nouveau_cli_printk(struct nouveau_cli *cli, const char *fmt, ...);
+
+#define NV_FATAL(drm, fmt, ...)
\
+   nouveau_cli_printk(&(drm)->client, KERN_CRIT fmt, ##__VA_ARGS__)
+#define NV_ERROR(drm, fmt, ...)
\
+   nouveau_cli_printk(&(drm)->client, KERN_ERR fmt, ##__VA_ARGS__)
+#define NV_WARN(drm, fmt, ...) \
+   nouveau_cli_printk(&(drm)->client, KERN_WARNING fmt, ##__VA_ARGS__)
+#define NV_INFO(drm, fmt, ...) \
+   nouveau_cli_printk(&(drm)->client, KERN_INFO fmt, ##__VA_ARGS__)
+#define NV_DEBUG(drm, fmt, ...)
\
+do {   \
+   if (unlikely(drm_debug & DRM_UT_DRIVER))\
+   NV_INFO(drm, fmt, ##__VA_ARGS__);   \
+} while (0)
+#define NV_ATOMIC(drm, fmt, ...)   \
+do {   \
+   if (unlikely(drm_debug & DRM_UT_ATOMIC))\
+   NV_INFO(drm, fmt, ##__VA_ARGS__);   \
+} while (0)
 
 extern int nouveau_modeset;
 
-- 
2.15.0

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 2/2] drm/nouveau: Convert NV_PRINTK macros and uses to new nv_cli_ macros

2018-08-30 Thread Joe Perches

Use a more common logging style and reduce object size by calling
the nouveau_cli_printk function.

(size -t drivers/gpu/drm/nouveau/built-in.a x86/64 defconfig with nouveau)
   textdata bss dec hex filename
1736437  1084841048 1845969  1c2ad1 (TOTALS) (new)
1737254  1084841048 1846786  1c2e02 (TOTALS) (old)

Miscellanea:

o Add nv_cli_ macros that use nouveau_cli_printk
o Convert the NV_PRINTK uses to the new nv_cli_ macros
o Realign arguments of the conversions

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/nouveau/nouveau_abi16.c |  2 +-
 drivers/gpu/drm/nouveau/nouveau_chan.c  | 12 +++
 drivers/gpu/drm/nouveau/nouveau_drv.h   | 12 ---
 drivers/gpu/drm/nouveau/nouveau_gem.c   | 62 -
 4 files changed, 45 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c 
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index e67a471331b5..8196c5417dde 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -236,7 +236,7 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
getparam->value = nvkm_gr_units(gr);
break;
default:
-   NV_PRINTK(dbg, cli, "unknown parameter %lld\n", 
getparam->param);
+   nv_cli_dbg(cli, "unknown parameter %lld\n", getparam->param);
return -EINVAL;
}
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index 92d3115f96b5..0c9c6172ea29 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -51,7 +51,7 @@ nouveau_channel_killed(struct nvif_notify *ntfy)
 {
struct nouveau_channel *chan = container_of(ntfy, typeof(*chan), kill);
struct nouveau_cli *cli = (void *)chan->user.client;
-   NV_PRINTK(warn, cli, "channel %d killed!\n", chan->chid);
+   nv_cli_warn(cli, "channel %d killed!\n", chan->chid);
atomic_set(>killed, 1);
return NVIF_NOTIFY_DROP;
 }
@@ -71,8 +71,8 @@ nouveau_channel_idle(struct nouveau_channel *chan)
}
 
if (ret) {
-   NV_PRINTK(err, cli, "failed to idle channel %d [%s]\n",
- chan->chid, nvxx_client(>base)->name);
+   nv_cli_err(cli, "failed to idle channel %d [%s]\n",
+  chan->chid, nvxx_client(>base)->name);
return ret;
}
}
@@ -460,17 +460,17 @@ nouveau_channel_new(struct nouveau_drm *drm, struct 
nvif_device *device,
 
ret = nouveau_channel_ind(drm, device, arg0, pchan);
if (ret) {
-   NV_PRINTK(dbg, cli, "ib channel create, %d\n", ret);
+   nv_cli_dbg(cli, "ib channel create, %d\n", ret);
ret = nouveau_channel_dma(drm, device, pchan);
if (ret) {
-   NV_PRINTK(dbg, cli, "dma channel create, %d\n", ret);
+   nv_cli_dbg(cli, "dma channel create, %d\n", ret);
goto done;
}
}
 
ret = nouveau_channel_init(*pchan, arg0, arg1);
if (ret) {
-   NV_PRINTK(err, cli, "channel failed to initialise, %d\n", ret);
+   nv_cli_err(cli, "channel failed to initialise, %d\n", ret);
nouveau_channel_del(pchan);
}
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 6110730d5df0..a45bd44ac782 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -240,14 +240,16 @@ nouveau_platform_device_create(const struct 
nvkm_device_tegra_func *,
   struct platform_device *, struct nvkm_device **);
 void nouveau_drm_device_remove(struct drm_device *dev);
 
-#define NV_PRINTK(l,c,f,a...) do { 
\
-   struct nouveau_cli *_cli = (c);\
-   dev_##l(_cli->drm->dev->dev, "%s: "f, _cli->name, ##a);\
-} while(0)
-
 __printf(2, 3)
 void nouveau_cli_printk(struct nouveau_cli *cli, const char *fmt, ...);
 
+#define nv_cli_err(cli, fmt, ...)  \
+   nouveau_cli_printk(cli, KERN_ERR fmt, ##__VA_ARGS__)
+#define nv_cli_warn(cli, fmt, ...) \
+   nouveau_cli_printk(cli, KERN_WARNING fmt, ##__VA_ARGS__)
+#define nv_cli_dbg(cli, fmt, ...)  \
+   dev_dbg((cli)->drm->dev->dev, "%s: " fmt, (cli)->name, ##__VA_ARGS__)
+
 #define NV_FATAL(drm, fmt, ...)
\
nouveau_cli_printk(&(drm)->client,

[Nouveau] [PATCH 0/2] drm/nouveau: Use more standard logging styles

2018-08-30 Thread Joe Perches

Reduces object size ~4kb

Joe Perches (2):
  drm/nouveau: Add new logging function nv_cli_printk
  drm/nouveau: Convert NV_PRINTK macros and uses to new nv_cli_ macros

 drivers/gpu/drm/nouveau/nouveau_abi16.c |  2 +-
 drivers/gpu/drm/nouveau/nouveau_chan.c  | 12 +++
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 21 +++
 drivers/gpu/drm/nouveau/nouveau_drv.h   | 44 ++-
 drivers/gpu/drm/nouveau/nouveau_gem.c   | 62 -
 5 files changed, 87 insertions(+), 54 deletions(-)

-- 
2.15.0

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH] gpu: Consistently use octal not symbolic permissions

2018-06-06 Thread Joe Perches

There is currently a mixture of octal and symbolic permissions uses
in files in drivers/gpu/drm and one file in drivers/gpu.

There are ~270 existing octal uses and ~115 S_ uses.

Convert all the S_ symbolic permissions to their octal equivalents
as using octal and not symbolic permissions is preferred by many as more
readable.

see: https://lkml.org/lkml/2016/8/2/1945

Done with automated conversion via:
$ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace 

Miscellanea:

o Wrapped modified multi-line calls to a single line where appropriate
o Realign modified multi-line calls to open parenthesis
o drivers/gpu/drm/msm/adreno/a5xx_debugfs.c has a world-writeable
  debug permission for "reset" - perhaps that should be modified

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 98 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  9 +-
 drivers/gpu/drm/armada/armada_debugfs.c|  4 +-
 drivers/gpu/drm/drm_debugfs.c  |  6 +-
 drivers/gpu/drm/drm_debugfs_crc.c  |  4 +-
 drivers/gpu/drm/drm_sysfs.c|  2 +-
 drivers/gpu/drm/i915/gvt/firmware.c|  2 +-
 drivers/gpu/drm/i915/i915_debugfs.c|  8 +-
 drivers/gpu/drm/i915/i915_perf.c   |  2 +-
 drivers/gpu/drm/i915/i915_sysfs.c  | 22 ++---
 drivers/gpu/drm/i915/intel_pipe_crc.c  |  2 +-
 drivers/gpu/drm/msm/adreno/a5xx_debugfs.c  |  5 +-
 drivers/gpu/drm/msm/msm_perf.c |  4 +-
 drivers/gpu/drm/msm/msm_rd.c   |  4 +-
 drivers/gpu/drm/nouveau/nouveau_debugfs.c  |  2 +-
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c| 11 ++-
 .../drm/omapdrm/displays/panel-sony-acx565akm.c|  6 +-
 .../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 10 +--
 drivers/gpu/drm/radeon/radeon_pm.c | 26 +++---
 drivers/gpu/drm/radeon/radeon_ttm.c|  4 +-
 drivers/gpu/drm/sti/sti_drv.c  |  2 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c |  4 +-
 drivers/gpu/drm/ttm/ttm_bo.c   |  2 +-
 drivers/gpu/drm/ttm/ttm_memory.c   | 12 +--
 drivers/gpu/drm/ttm/ttm_page_alloc.c   |  6 +-
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c   |  6 +-
 drivers/gpu/drm/udl/udl_fb.c   |  4 +-
 drivers/gpu/host1x/debug.c | 12 +--
 30 files changed, 138 insertions(+), 146 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index f5fb93795a69..7b29febff511 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -830,7 +830,7 @@ int amdgpu_debugfs_regs_init(struct amdgpu_device *adev)
 
for (i = 0; i < ARRAY_SIZE(debugfs_regs); i++) {
ent = debugfs_create_file(debugfs_regs_names[i],
- S_IFREG | S_IRUGO, root,
+ S_IFREG | 0444, root,
  adev, debugfs_regs[i]);
if (IS_ERR(ent)) {
for (j = 0; j < i; j++) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index b455da487782..fa55d7e9e784 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -905,39 +905,39 @@ static ssize_t amdgpu_set_pp_power_profile_mode(struct 
device *dev,
return -EINVAL;
 }
 
-static DEVICE_ATTR(power_dpm_state, S_IRUGO | S_IWUSR, amdgpu_get_dpm_state, 
amdgpu_set_dpm_state);
-static DEVICE_ATTR(power_dpm_force_performance_level, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(power_dpm_state, 0644, amdgpu_get_dpm_state, 
amdgpu_set_dpm_state);
+static DEVICE_ATTR(power_dpm_force_performance_level, 0644,
   amdgpu_get_dpm_forced_performance_level,
   amdgpu_set_dpm_forced_performance_level);
-static DEVICE_ATTR(pp_num_states, S_IRUGO, amdgpu_get_pp_num_states, NULL);
-static DEVICE_ATTR(pp_cur_state, S_IRUGO, amdgpu_get_pp_cur_state, NULL);
-static DEVICE_ATTR(pp_force_state, S_IRUGO | S_IWUSR,
-   amdgpu_get_pp_force_state,
-   amdgpu_set_pp_force_state);
-static DEVICE_ATTR(pp_table, S_IRUGO | S_IWUSR,
-   amdgpu_get_pp_table,
-   amdgpu_set_pp_table);
-static DEVICE_ATTR(pp_dpm_sclk, S_IRUGO | S_IWUSR,
-   amdgpu_get_pp_dpm_sclk,
-   amdgpu_set_pp_dpm_sclk);
-static DEVICE_ATTR(pp_dpm_mclk, S_IRUGO | S_IWUSR,
-   amdgpu_get_pp_dpm_mclk,
-   amdgpu_set_pp_dpm_mclk);
-static DEVICE_ATTR(pp_dpm_pcie, S_IRUGO | S_IWUSR,
-   amdgpu

Re: [Nouveau] [PATCH] gpu: Consistently use octal not symbolic permissions

2018-06-06 Thread Joe Perches

On Fri, 2018-05-25 at 09:41 +0300, Jani Nikula wrote:
> On Thu, 24 May 2018, Joe Perches  wrote:
> > There is currently a mixture of octal and symbolic permissions uses
> > in files in drivers/gpu/drm and one file in drivers/gpu.
> > 
> > There are ~270 existing octal uses and ~115 S_ uses.
> > 
> > Convert all the S_ symbolic permissions to their octal equivalents
> > as using octal and not symbolic permissions is preferred by many as more
> > readable.
> > 
> > see: https://lkml.org/lkml/2016/8/2/1945
> > 
> > Done with automated conversion via:
> > $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace 
> > 
> > Miscellanea:
> > 
> > o Wrapped modified multi-line calls to a single line where appropriate
> > o Realign modified multi-line calls to open parenthesis
> > o drivers/gpu/drm/msm/adreno/a5xx_debugfs.c has a world-writeable
> >   debug permission for "reset" - perhaps that should be modified
> > Signed-off-by: Joe Perches 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c|  2 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 98 
> > +++---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  3 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  9 +-
> >  drivers/gpu/drm/armada/armada_debugfs.c|  4 +-
> >  drivers/gpu/drm/drm_debugfs.c  |  6 +-
> >  drivers/gpu/drm/drm_debugfs_crc.c  |  4 +-
> >  drivers/gpu/drm/drm_sysfs.c|  2 +-
> >  drivers/gpu/drm/i915/gvt/firmware.c|  2 +-
> >  drivers/gpu/drm/i915/i915_debugfs.c|  8 +-
> >  drivers/gpu/drm/i915/i915_perf.c   |  2 +-
> >  drivers/gpu/drm/i915/i915_sysfs.c  | 22 ++---
> >  drivers/gpu/drm/i915/intel_pipe_crc.c  |  2 +-
> 
> Please send at least i915 changes separately. There's zero reason to
> make our lives harder for this change.

The idea is to avoid unnecessary multiple patches for
individual trees.

But you could do that via something like:

$ git am --include='drivers/gpu/drm/i915/*' 

cheers, Joe

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".

2017-08-10 Thread Joe Kniss

On Wed, Aug 9, 2017 at 4:13 PM, Joe Kniss <d...@google.com> wrote:
> On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes <nor...@tronnes.org> wrote:
>>
>> Den 09.08.2017 01.42, skrev Joe Kniss:
>>>
>>> Because all drivers currently use gem objects for framebuffer planes,
>>> the virtual create_handle() is not required.  This change adds a
>>> struct drm_gem_object *gems[4] field to drm_framebuffer and removes
>>> create_handle() function pointer from drm_framebuffer_funcs.  The
>>> corresponding *_create_handle() function is removed from each driver.
>>>
>>> In many cases this change eliminates a struct *_framebuffer object,
>>> as the only need for the derived struct is the addition of the gem
>>> object pointer.
>>>
>>> TESTED: compiled: allyesconfig ARCH=x86,arm platforms:i915, rockchip
>>>
>>> Signed-off-by: Joe Kniss <d...@google.com>
>>> ---
>>
>>
>> Hi Joe,
>>
>> I'm also looking into adding gem objs to drm_framebuffer in this patch:
>> [PATCH v2 01/22] drm: Add GEM backed framebuffer library
>> https://lists.freedesktop.org/archives/dri-devel/2017-August/149782.html
>>
>
> Great.  There's only minimal overlap here.  I'll rebase this change on yours
> once it's in.
>
>> [...]
>>
>>> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
>>> b/drivers/gpu/drm/drm_fb_cma_helper.c
>>> index ade319d10e70..f5f011b910b1 100644
>>> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
>>> @@ -31,14 +31,9 @@
>>> #define DEFAULT_FBDEFIO_DELAY_MS 50
>>>   -struct drm_fb_cma {
>>> -   struct drm_framebuffer  fb;
>>> -   struct drm_gem_cma_object   *obj[4];
>>> -};
>>> -
>>>   struct drm_fbdev_cma {
>>> struct drm_fb_helperfb_helper;
>>> -   struct drm_fb_cma   *fb;
>>> +   struct drm_framebuffer  *fb;
>>
>>
>> This fb pointer isn't necessary, since fb_helper already has one.
>>

So, looking deeper into this, it seems that the struct
drm_framebuffer_funcs *fb_funcs is also redundant here?  In which case
this whole struct can go...

>
> I'll remove it... but I am sure when I look deeper there will be more
> of these in the various drivers too.
>
>> Noralf.
>>
>>
>
> -joe
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".

2017-08-09 Thread Joe Kniss

On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes <nor...@tronnes.org> wrote:
>
> Den 09.08.2017 01.42, skrev Joe Kniss:
>>
>> Because all drivers currently use gem objects for framebuffer planes,
>> the virtual create_handle() is not required.  This change adds a
>> struct drm_gem_object *gems[4] field to drm_framebuffer and removes
>> create_handle() function pointer from drm_framebuffer_funcs.  The
>> corresponding *_create_handle() function is removed from each driver.
>>
>> In many cases this change eliminates a struct *_framebuffer object,
>> as the only need for the derived struct is the addition of the gem
>> object pointer.
>>
>> TESTED: compiled: allyesconfig ARCH=x86,arm platforms:i915, rockchip
>>
>> Signed-off-by: Joe Kniss <d...@google.com>
>> ---
>
>
> Hi Joe,
>
> I'm also looking into adding gem objs to drm_framebuffer in this patch:
> [PATCH v2 01/22] drm: Add GEM backed framebuffer library
> https://lists.freedesktop.org/archives/dri-devel/2017-August/149782.html
>

Great.  There's only minimal overlap here.  I'll rebase this change on yours
once it's in.

> [...]
>
>> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
>> b/drivers/gpu/drm/drm_fb_cma_helper.c
>> index ade319d10e70..f5f011b910b1 100644
>> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
>> @@ -31,14 +31,9 @@
>> #define DEFAULT_FBDEFIO_DELAY_MS 50
>>   -struct drm_fb_cma {
>> -   struct drm_framebuffer  fb;
>> -   struct drm_gem_cma_object   *obj[4];
>> -};
>> -
>>   struct drm_fbdev_cma {
>> struct drm_fb_helperfb_helper;
>> -   struct drm_fb_cma   *fb;
>> +       struct drm_framebuffer  *fb;
>
>
> This fb pointer isn't necessary, since fb_helper already has one.
>

I'll remove it... but I am sure when I look deeper there will be more
of these in the various drivers too.

> Noralf.
>
>

-joe
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] Known bug? Two adjacent letters randomly not rendered or painted over

2017-05-26 Thread Joe Kesselman (via Android)

Hi, folks. Using the Noveau drivers on my RHEL7 Thinkpad (which is how our IS 
shop supplies these machines), I will see it drop two letters out of a window 
full of text (as if rendering them in the background color or drawing a 
rectangle  of that color over them).

 This happens in everything from Eclipse mouse-over syntax pop-up windows to 
Libre Office word processing screens. I haven't found and pattern yet in what 
gets stepped on or when.

I have occasionally been able to get it to paint just the bottom few pixels of 
these characters, but I can't provoke that reliably yet.

I have seen some archived discussion of a similar effect, so this may be a 
Solved Problem. If so please let me know and point me to upgrade process. If 
not, I'm willing to do some additional data gathering if anyone can suggest 
useful experiments.

--
OMG GOP WTF ?!?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

2017-03-03 Thread Joe Perches

On Thu, 2017-02-23 at 17:41 +, Emil Velikov wrote:
> On 23 February 2017 at 17:18, Joe Perches <j...@perches.com> wrote:
> > On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
> > > On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches <j...@perches.com> wrote:
> > > > There are ~4300 uses of pr_warn and ~250 uses of the older
> > > > pr_warning in the kernel source tree.
> > > > 
> > > > Make the use of pr_warn consistent across all kernel files.
> > > > 
> > > > This excludes all files in tools/ as there is a separate
> > > > define pr_warning for that directory tree and pr_warn is
> > > > not used in tools/.
> > > > 
> > > > Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
> > 
> > []
> > > Where's the removal of pr_warning so we don't have more sneak in?
> > 
> > After all of these actually get applied,
> > and maybe a cycle or two later, one would
> > get sent.
> > 
> 
> By which point you'll get a few reincarnation of it. So you'll have to
> do the same exercise again :-(

Maybe to one or two files.  Not a big deal.

> I guess the question is - are you expecting to get the series merged
> all together/via one tree ?

No.  The only person that could do that effectively is Linus.

> If not, your plan is perfectly reasonable.

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 2/2] gpu: drm: Convert printk(KERN_ to pr_

2017-03-03 Thread Joe Perches

Use a more common logging style.

Miscellanea:

o Coalesce formats and realign arguments
o Neaten a few macros now using pr_

Signed-off-by: Joe Perches <j...@perches.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c   |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c   |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_test.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/atom.c  | 44 -
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  4 +-
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 ++--
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 ++--
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  4 +-
 drivers/gpu/drm/amd/include/amd_pcie_helpers.h |  4 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  2 +-
 drivers/gpu/drm/amd/powerplay/inc/pp_debug.h   |  2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c|  4 +-
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 14 +++---
 .../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c   |  4 +-
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c   |  4 +-
 drivers/gpu/drm/drm_cache.c| 12 ++---
 drivers/gpu/drm/drm_edid.c |  4 +-
 drivers/gpu/drm/drm_ioc32.c|  3 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c|  9 ++--
 drivers/gpu/drm/gma500/oaktrail_lvds.c | 18 +++
 drivers/gpu/drm/gma500/psb_drv.h   |  5 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c|  7 ++-
 drivers/gpu/drm/i915/i915_sw_fence.c   |  8 ++--
 drivers/gpu/drm/mgag200/mgag200_mode.c |  2 +-
 drivers/gpu/drm/msm/msm_drv.c  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_acpi.c |  7 +--
 drivers/gpu/drm/nouveau/nouveau_vga.c  |  4 +-
 drivers/gpu/drm/nouveau/nv50_display.c | 22 -
 drivers/gpu/drm/nouveau/nvkm/core/mm.c | 10 ++--
 drivers/gpu/drm/omapdrm/dss/dsi.c  | 17 ---
 drivers/gpu/drm/omapdrm/dss/dss.c  |  3 +-
 drivers/gpu/drm/omapdrm/dss/dss.h  | 15 +++---
 drivers/gpu/drm/omapdrm/omap_gem.c |  5 +-
 drivers/gpu/drm/r128/r128_cce.c|  7 ++-
 drivers/gpu/drm/radeon/atom.c  | 46 --
 drivers/gpu/drm/radeon/cik.c   | 56 --
 drivers/gpu/drm/radeon/evergreen.c |  2 +-
 drivers/gpu/drm/radeon/evergreen_cs.c  |  7 ++-
 drivers/gpu/drm/radeon/ni.c| 22 +++--
 drivers/gpu/drm/radeon/r100.c  | 18 +++
 drivers/gpu/drm/radeon/r200.c  |  3 +-
 drivers/gpu/drm/radeon/r300.c  | 13 ++---
 drivers/gpu/drm/radeon/r420.c  |  9 ++--
 drivers/gpu/drm/radeon/r520.c  |  3 +-
 drivers/gpu/drm/radeon/r600.c  | 21 +++-
 drivers/gpu/drm/radeon/r600_cs.c   |  7 ++-
 drivers/gpu/drm/radeon/radeon.h|  3 +-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c   |  4 +-
 drivers/gpu/drm/radeon/radeon_audio.c  |  4 +-
 drivers/gpu/drm/radeon/radeon_clocks.c |  2 +-
 drivers/gpu/drm/radeon/radeon_device.c |  8 ++--
 drivers/gpu/drm/radeon/radeon_fb.c |  3 +-
 drivers/gpu/drm/radeon/radeon_gem.c|  4 +-
 drivers/gpu/drm/radeon/radeon_test.c   |  6 +--
 drivers/gpu/drm/radeon/rs400.c |  4 +-
 drivers/gpu/drm/radeon/rs690.c |  3 +-
 drivers/gpu/drm/radeon/rv515.c |  9 ++--
 drivers/gpu/drm/radeon/si.c| 45 ++---
 drivers/gpu/drm/ttm/ttm_bo.c   |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c  |  6 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c  |  3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   |  4 +-
 69 files changed, 253 insertions(+), 362 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index c1b913541739..3f636632c289 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1515,7 +1515,8 @@ void amdgpu_mm_wdoorbell(struct amdgpu_device *adev, u32 
index, u32 v);
  */
 #define RREG32(reg) amdgpu_mm_rreg(adev, (reg), false)
 #define RREG32_IDX(reg) amdgpu_mm_rreg(adev, (reg), true)
-#define DREG32(reg) printk(KERN_INFO "REGIS

Re: [Nouveau] [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

2017-03-03 Thread Joe Perches

On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
> On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches <j...@perches.com> wrote:
> > There are ~4300 uses of pr_warn and ~250 uses of the older
> > pr_warning in the kernel source tree.
> > 
> > Make the use of pr_warn consistent across all kernel files.
> > 
> > This excludes all files in tools/ as there is a separate
> > define pr_warning for that directory tree and pr_warn is
> > not used in tools/.
> > 
> > Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
[]
> Where's the removal of pr_warning so we don't have more sneak in?

After all of these actually get applied,
and maybe a cycle or two later, one would
get sent.

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_

2017-02-28 Thread Joe Perches

Use a more common logging style.

Miscellanea:

o Coalesce formats and realign arguments
o Neaten a few macros now using pr_

Signed-off-by: Joe Perches <j...@perches.com>
---
 drivers/gpu/drm/gma500/cdv_intel_lvds.c   |  9 -
 drivers/gpu/drm/gma500/oaktrail_lvds.c| 18 +-
 drivers/gpu/drm/gma500/psb_drv.h  |  5 ++---
 drivers/gpu/drm/gma500/psb_intel_lvds.c   |  7 +++
 drivers/gpu/drm/i915/i915_sw_fence.c  |  8 
 drivers/gpu/drm/mgag200/mgag200_mode.c|  2 +-
 drivers/gpu/drm/msm/msm_drv.c |  2 +-
 drivers/gpu/drm/nouveau/nouveau_acpi.c|  7 ---
 drivers/gpu/drm/nouveau/nouveau_vga.c |  4 ++--
 drivers/gpu/drm/nouveau/nv50_display.c| 22 +++---
 drivers/gpu/drm/nouveau/nvkm/core/mm.c| 10 +-
 drivers/gpu/drm/omapdrm/dss/dsi.c | 17 -
 drivers/gpu/drm/omapdrm/dss/dss.c |  3 +--
 drivers/gpu/drm/omapdrm/dss/dss.h | 15 ++-
 drivers/gpu/drm/omapdrm/omap_gem.c|  5 ++---
 drivers/gpu/drm/r128/r128_cce.c   |  7 +++
 drivers/gpu/drm/ttm/ttm_bo.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |  6 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  3 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |  4 ++--
 20 files changed, 72 insertions(+), 84 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index 5efdb7fbb7ee..e64960db3224 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -284,8 +284,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder 
*encoder,
head) {
if (tmp_encoder != encoder
&& tmp_encoder->crtc == encoder->crtc) {
-   printk(KERN_ERR "Can't enable LVDS and another "
-  "encoder on the same pipe\n");
+   pr_err("Can't enable LVDS and another encoder on the 
same pipe\n");
return false;
}
}
@@ -756,13 +755,13 @@ void cdv_intel_lvds_init(struct drm_device *dev,
 
 failed_find:
mutex_unlock(>mode_config.mutex);
-   printk(KERN_ERR "Failed find\n");
+   pr_err("Failed find\n");
psb_intel_i2c_destroy(gma_encoder->ddc_bus);
 failed_ddc:
-   printk(KERN_ERR "Failed DDC\n");
+   pr_err("Failed DDC\n");
psb_intel_i2c_destroy(gma_encoder->i2c_bus);
 failed_blc_i2c:
-   printk(KERN_ERR "Failed BLC\n");
+   pr_err("Failed BLC\n");
drm_encoder_cleanup(encoder);
drm_connector_cleanup(connector);
kfree(lvds_priv);
diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c 
b/drivers/gpu/drm/gma500/oaktrail_lvds.c
index f7038f12ac76..e6943fef0611 100644
--- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
+++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
@@ -255,15 +255,15 @@ static void oaktrail_lvds_get_configuration_mode(struct 
drm_device *dev,
((ti->vblank_hi << 8) | ti->vblank_lo);
mode->clock = ti->pixel_clock * 10;
 #if 0
-   printk(KERN_INFO "hdisplay is %d\n", mode->hdisplay);
-   printk(KERN_INFO "vdisplay is %d\n", mode->vdisplay);
-   printk(KERN_INFO "HSS is %d\n", mode->hsync_start);
-   printk(KERN_INFO "HSE is %d\n", mode->hsync_end);
-   printk(KERN_INFO "htotal is %d\n", mode->htotal);
-   printk(KERN_INFO "VSS is %d\n", mode->vsync_start);
-   printk(KERN_INFO "VSE is %d\n", mode->vsync_end);
-   printk(KERN_INFO "vtotal is %d\n", mode->vtotal);
-   printk(KERN_INFO "clock is %d\n", mode->clock);
+   pr_info("hdisplay is %d\n", mode->hdisplay);
+   pr_info("vdisplay is %d\n", mode->vdisplay);
+   pr_info("HSS is %d\n", mode->hsync_start);
+   pr_info("HSE is %d\n", mode->hsync_end);
+   pr_info("htotal is %d\n", mode->htotal);
+   pr_info("VSS is %d\n", mode->vsync_start);
+   pr_info("VSE is %d\n", mode->vsync_end);
+   pr_info("vtotal is %d\n", mode->vtotal);
+   pr_info("clock is %d\n", mode->clock);
 #endif
mode_dev->panel_fixed_mode = mode;
}
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 83e22fd4cfc0..83667087d6e5 100644
--- a/drivers/gpu/drm/gma500/psb_drv

[Nouveau] [PATCH 0/3] gpu: drm: Convert printk(KERN_ to pr_

2017-02-28 Thread Joe Perches

Broken up for Daniel Vetter

Joe Perches (3):
  gpu: drm: amd/radeon: Convert printk(KERN_ to pr_
  gpu: drm: core: Convert printk(KERN_ to pr_
  gpu: drm: drivers: Convert printk(KERN_ to pr_

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c   |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c   |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_test.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/atom.c  | 44 -
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  4 +-
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 ++--
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 ++--
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  4 +-
 drivers/gpu/drm/amd/include/amd_pcie_helpers.h |  4 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  2 +-
 drivers/gpu/drm/amd/powerplay/inc/pp_debug.h   |  2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c|  4 +-
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 14 +++---
 .../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c   |  4 +-
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c   |  4 +-
 drivers/gpu/drm/drm_cache.c| 12 ++---
 drivers/gpu/drm/drm_edid.c |  4 +-
 drivers/gpu/drm/drm_ioc32.c|  3 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c|  9 ++--
 drivers/gpu/drm/gma500/oaktrail_lvds.c | 18 +++
 drivers/gpu/drm/gma500/psb_drv.h   |  5 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c|  7 ++-
 drivers/gpu/drm/i915/i915_sw_fence.c   |  8 ++--
 drivers/gpu/drm/mgag200/mgag200_mode.c |  2 +-
 drivers/gpu/drm/msm/msm_drv.c  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_acpi.c |  7 +--
 drivers/gpu/drm/nouveau/nouveau_vga.c  |  4 +-
 drivers/gpu/drm/nouveau/nv50_display.c | 22 -
 drivers/gpu/drm/nouveau/nvkm/core/mm.c | 10 ++--
 drivers/gpu/drm/omapdrm/dss/dsi.c  | 17 ---
 drivers/gpu/drm/omapdrm/dss/dss.c  |  3 +-
 drivers/gpu/drm/omapdrm/dss/dss.h  | 15 +++---
 drivers/gpu/drm/omapdrm/omap_gem.c |  5 +-
 drivers/gpu/drm/r128/r128_cce.c|  7 ++-
 drivers/gpu/drm/radeon/atom.c  | 46 --
 drivers/gpu/drm/radeon/cik.c   | 56 --
 drivers/gpu/drm/radeon/evergreen.c |  2 +-
 drivers/gpu/drm/radeon/evergreen_cs.c  |  7 ++-
 drivers/gpu/drm/radeon/ni.c| 22 +++--
 drivers/gpu/drm/radeon/r100.c  | 18 +++
 drivers/gpu/drm/radeon/r200.c  |  3 +-
 drivers/gpu/drm/radeon/r300.c  | 13 ++---
 drivers/gpu/drm/radeon/r420.c  |  9 ++--
 drivers/gpu/drm/radeon/r520.c  |  3 +-
 drivers/gpu/drm/radeon/r600.c  | 21 +++-
 drivers/gpu/drm/radeon/r600_cs.c   |  7 ++-
 drivers/gpu/drm/radeon/radeon.h|  3 +-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c   |  4 +-
 drivers/gpu/drm/radeon/radeon_audio.c  |  4 +-
 drivers/gpu/drm/radeon/radeon_clocks.c |  2 +-
 drivers/gpu/drm/radeon/radeon_device.c |  8 ++--
 drivers/gpu/drm/radeon/radeon_fb.c |  3 +-
 drivers/gpu/drm/radeon/radeon_gem.c|  4 +-
 drivers/gpu/drm/radeon/radeon_test.c   |  6 +--
 drivers/gpu/drm/radeon/rs400.c |  4 +-
 drivers/gpu/drm/radeon/rs690.c |  3 +-
 drivers/gpu/drm/radeon/rv515.c |  9 ++--
 drivers/gpu/drm/radeon/si.c| 45 ++---
 drivers/gpu/drm/ttm/ttm_bo.c   |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c  |  6 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c  |  3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   |  4 +-
 69 files changed, 253 insertions(+), 362 deletions(-)

-- 
2.10.0.rc2.1.g053435c

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 0/2] gpu: drm: Use pr_cont and neaten logging

2017-02-27 Thread Joe Perches

Joe Perches (2):
  drm: Use pr_cont where appropriate
  gpu: drm: Convert printk(KERN_ to pr_

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c   |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c   |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c| 70 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_test.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/atom.c  | 44 ++
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  4 +-
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 +--
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 +--
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  4 +-
 drivers/gpu/drm/amd/include/amd_pcie_helpers.h |  4 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  2 +-
 drivers/gpu/drm/amd/powerplay/inc/pp_debug.h   |  2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c|  4 +-
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 14 ++---
 .../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c   |  4 +-
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c   |  4 +-
 drivers/gpu/drm/drm_cache.c| 12 ++--
 drivers/gpu/drm/drm_edid.c |  4 +-
 drivers/gpu/drm/drm_ioc32.c|  3 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c|  9 ++-
 drivers/gpu/drm/gma500/oaktrail_lvds.c | 18 +++---
 drivers/gpu/drm/gma500/psb_drv.h   |  5 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c|  7 +--
 drivers/gpu/drm/i915/i915_sw_fence.c   |  8 +--
 drivers/gpu/drm/mgag200/mgag200_mode.c |  2 +-
 drivers/gpu/drm/msm/msm_drv.c  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_acpi.c |  7 ++-
 drivers/gpu/drm/nouveau/nouveau_vga.c  |  4 +-
 drivers/gpu/drm/nouveau/nv50_display.c | 22 +++
 drivers/gpu/drm/nouveau/nvkm/core/mm.c | 10 +--
 drivers/gpu/drm/omapdrm/dss/dsi.c  | 17 +++---
 drivers/gpu/drm/omapdrm/dss/dss.c  |  3 +-
 drivers/gpu/drm/omapdrm/dss/dss.h  | 15 ++---
 drivers/gpu/drm/omapdrm/omap_gem.c |  5 +-
 drivers/gpu/drm/r128/r128_cce.c|  7 +--
 drivers/gpu/drm/radeon/atom.c  | 46 ++
 drivers/gpu/drm/radeon/cik.c   | 56 ++---
 drivers/gpu/drm/radeon/evergreen.c |  2 +-
 drivers/gpu/drm/radeon/evergreen_cs.c  |  7 +--
 drivers/gpu/drm/radeon/ni.c| 22 +++
 drivers/gpu/drm/radeon/r100.c  | 18 ++
 drivers/gpu/drm/radeon/r200.c  |  3 +-
 drivers/gpu/drm/radeon/r300.c  | 13 ++--
 drivers/gpu/drm/radeon/r420.c  |  9 +--
 drivers/gpu/drm/radeon/r520.c  |  3 +-
 drivers/gpu/drm/radeon/r600.c  | 21 +++
 drivers/gpu/drm/radeon/r600_cs.c   |  7 +--
 drivers/gpu/drm/radeon/r600_dpm.c  | 71 +++---
 drivers/gpu/drm/radeon/radeon.h|  3 +-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c   |  4 +-
 drivers/gpu/drm/radeon/radeon_audio.c  |  4 +-
 drivers/gpu/drm/radeon/radeon_clocks.c |  2 +-
 drivers/gpu/drm/radeon/radeon_device.c |  8 +--
 drivers/gpu/drm/radeon/radeon_fb.c |  3 +-
 drivers/gpu/drm/radeon/radeon_gem.c|  4 +-
 drivers/gpu/drm/radeon/radeon_test.c   |  6 +-
 drivers/gpu/drm/radeon/rs400.c |  4 +-
 drivers/gpu/drm/radeon/rs690.c |  3 +-
 drivers/gpu/drm/radeon/rv515.c |  9 +--
 drivers/gpu/drm/radeon/si.c| 45 +-
 drivers/gpu/drm/ttm/ttm_bo.c   |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c  |  6 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c  |  3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   |  4 +-
 71 files changed, 326 insertions(+), 430 deletions(-)

-- 
2.10.0.rc2.1.g053435c

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

2017-02-17 Thread Joe Perches

There are ~4300 uses of pr_warn and ~250 uses of the older
pr_warning in the kernel source tree.

Make the use of pr_warn consistent across all kernel files.

This excludes all files in tools/ as there is a separate
define pr_warning for that directory tree and pr_warn is
not used in tools/.

Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.

Miscellanea:

o Coalesce formats and realign arguments

Some files not compiled - no cross-compilers

Joe Perches (35):
  alpha: Convert remaining uses of pr_warning to pr_warn
  ARM: ep93xx: Convert remaining uses of pr_warning to pr_warn
  arm64: Convert remaining uses of pr_warning to pr_warn
  arch/blackfin: Convert remaining uses of pr_warning to pr_warn
  ia64: Convert remaining use of pr_warning to pr_warn
  powerpc: Convert remaining uses of pr_warning to pr_warn
  sh: Convert remaining uses of pr_warning to pr_warn
  sparc: Convert remaining use of pr_warning to pr_warn
  x86: Convert remaining uses of pr_warning to pr_warn
  drivers/acpi: Convert remaining uses of pr_warning to pr_warn
  block/drbd: Convert remaining uses of pr_warning to pr_warn
  gdrom: Convert remaining uses of pr_warning to pr_warn
  drivers/char: Convert remaining use of pr_warning to pr_warn
  clocksource: Convert remaining use of pr_warning to pr_warn
  drivers/crypto: Convert remaining uses of pr_warning to pr_warn
  fmc: Convert remaining use of pr_warning to pr_warn
  drivers/gpu: Convert remaining uses of pr_warning to pr_warn
  drivers/ide: Convert remaining uses of pr_warning to pr_warn
  drivers/input: Convert remaining uses of pr_warning to pr_warn
  drivers/isdn: Convert remaining uses of pr_warning to pr_warn
  drivers/macintosh: Convert remaining uses of pr_warning to pr_warn
  drivers/media: Convert remaining use of pr_warning to pr_warn
  drivers/mfd: Convert remaining uses of pr_warning to pr_warn
  drivers/mtd: Convert remaining uses of pr_warning to pr_warn
  drivers/of: Convert remaining uses of pr_warning to pr_warn
  drivers/oprofile: Convert remaining uses of pr_warning to pr_warn
  drivers/platform: Convert remaining uses of pr_warning to pr_warn
  drivers/rapidio: Convert remaining use of pr_warning to pr_warn
  drivers/scsi: Convert remaining use of pr_warning to pr_warn
  drivers/sh: Convert remaining use of pr_warning to pr_warn
  drivers/tty: Convert remaining uses of pr_warning to pr_warn
  drivers/video: Convert remaining uses of pr_warning to pr_warn
  kernel/trace: Convert remaining uses of pr_warning to pr_warn
  lib: Convert remaining uses of pr_warning to pr_warn
  sound/soc: Convert remaining uses of pr_warning to pr_warn

 arch/alpha/kernel/perf_event.c |  4 +-
 arch/arm/mach-ep93xx/core.c|  4 +-
 arch/arm64/include/asm/syscall.h   |  8 ++--
 arch/arm64/kernel/hw_breakpoint.c  |  8 ++--
 arch/arm64/kernel/smp.c|  4 +-
 arch/blackfin/kernel/nmi.c |  2 +-
 arch/blackfin/kernel/ptrace.c  |  2 +-
 arch/blackfin/mach-bf533/boards/stamp.c|  2 +-
 arch/blackfin/mach-bf537/boards/cm_bf537e.c|  2 +-
 arch/blackfin/mach-bf537/boards/cm_bf537u.c|  2 +-
 arch/blackfin/mach-bf537/boards/stamp.c|  2 +-
 arch/blackfin/mach-bf537/boards/tcm_bf537.c|  2 +-
 arch/blackfin/mach-bf561/boards/cm_bf561.c |  2 +-
 arch/blackfin/mach-bf561/boards/ezkit.c|  2 +-
 arch/blackfin/mm/isram-driver.c|  4 +-
 arch/ia64/kernel/setup.c   |  6 +--
 arch/powerpc/kernel/pci-common.c   |  4 +-
 arch/powerpc/mm/init_64.c  |  5 +--
 arch/powerpc/mm/mem.c  |  3 +-
 arch/powerpc/platforms/512x/mpc512x_shared.c   |  4 +-
 arch/powerpc/platforms/85xx/socrates_fpga_pic.c|  7 ++--
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |  2 +-
 arch/powerpc/platforms/pasemi/dma_lib.c|  4 +-
 arch/powerpc/platforms/powernv/opal.c  |  8 ++--
 arch/powerpc/platforms/powernv/pci-ioda.c  | 10 ++---
 arch/powerpc/platforms/ps3/device-init.c   | 14 +++
 arch/powerpc/platforms/ps3/mm.c|  4 +-
 arch/powerpc/platforms/ps3/os-area.c   |  2 +-
 arch/powerpc/platforms/pseries/iommu.c |  8 ++--
 arch/powerpc/platforms/pseries/setup.c |  4 +-
 arch/powerpc/sysdev/fsl_pci.c  |  9 ++---
 arch/powerpc/sysdev/mpic.c | 10 ++---
 arch/powerpc/sysdev/xics/icp-native.c  | 10 ++---
 arch/powerpc/sysdev/xics/ics-opal.c|  4 +-
 arch/powerpc/sysdev/xics/ics-rtas.c|  4 +-
 arch/powerpc/sysdev/xics/xics-common.c |  8 ++--
 arch/sh/boards/mach-sdk7786/nmi.c  |  2 +-
 arch/sh/drivers/pci/fixups-sdk7786.c   |  2 +-
 arch/sh/kernel/io_trapped.c

[Nouveau] [PATCH 09/35] x86: Convert remaining uses of pr_warning to pr_warn

2017-02-16 Thread Joe Perches

To enable eventual removal of pr_warning

This makes pr_warn use consistent for arch/x86

Prior to this patch, there were 46 uses of pr_warning and
122 uses of pr_warn in arch/x86

Miscellanea:

o Coalesce a few formats and realign arguments
o Convert a couple of multiple line printks to single line

Signed-off-by: Joe Perches <j...@perches.com>
---
 arch/x86/kernel/amd_gart_64.c  | 12 +++--
 arch/x86/kernel/apic/apic.c| 46 --
 arch/x86/kernel/apic/apic_noop.c   |  2 +-
 arch/x86/kernel/setup_percpu.c |  4 +--
 arch/x86/kernel/tboot.c| 15 ++-
 arch/x86/kernel/tsc_sync.c |  8 +++---
 arch/x86/mm/kmmio.c|  8 +++---
 arch/x86/mm/mmio-mod.c |  5 ++--
 arch/x86/mm/numa.c | 12 -
 arch/x86/mm/numa_emulation.c   |  6 ++---
 arch/x86/mm/testmmiotrace.c|  5 ++--
 arch/x86/oprofile/op_x86_model.h   |  6 ++---
 arch/x86/platform/olpc/olpc-xo15-sci.c |  2 +-
 arch/x86/platform/sfi/sfi.c|  3 +--
 arch/x86/xen/debugfs.c |  2 +-
 arch/x86/xen/setup.c   |  2 +-
 16 files changed, 63 insertions(+), 75 deletions(-)

diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
index 63ff468a7986..6bb37027cd70 100644
--- a/arch/x86/kernel/amd_gart_64.c
+++ b/arch/x86/kernel/amd_gart_64.c
@@ -535,10 +535,8 @@ static __init unsigned long check_iommu_size(unsigned long 
aper, u64 aper_size)
iommu_size -= round_up(a, PMD_PAGE_SIZE) - a;
 
if (iommu_size < 64*1024*1024) {
-   pr_warning(
-   "PCI-DMA: Warning: Small IOMMU %luMB."
-   " Consider increasing the AGP aperture in BIOS\n",
-   iommu_size >> 20);
+   pr_warn("PCI-DMA: Warning: Small IOMMU %luMB. Consider 
increasing the AGP aperture in BIOS\n",
+   iommu_size >> 20);
}
 
return iommu_size;
@@ -690,8 +688,7 @@ static __init int init_amd_gatt(struct agp_kern_info *info)
 
  nommu:
/* Should not happen anymore */
-   pr_warning("PCI-DMA: More than 4GB of RAM and no IOMMU\n"
-  "falling back to iommu=soft.\n");
+   pr_warn("PCI-DMA: More than 4GB of RAM and no IOMMU - falling back to 
iommu=soft\n");
return -1;
 }
 
@@ -756,8 +753,7 @@ int __init gart_iommu_init(void)
!gart_iommu_aperture ||
(no_agp && init_amd_gatt() < 0)) {
if (max_pfn > MAX_DMA32_PFN) {
-   pr_warning("More than 4GB of memory but GART IOMMU not 
available.\n");
-   pr_warning("falling back to iommu=soft.\n");
+   pr_warn("More than 4GB of memory but GART IOMMU not 
available - falling back to iommu=soft\n");
}
return 0;
}
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 4261b3282ad9..37e9129da8b3 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -685,8 +685,8 @@ calibrate_by_pmtimer(long deltapm, long *delta, long 
*deltatsc)
 
res = (((u64)deltapm) *  mult) >> 22;
do_div(res, 100);
-   pr_warning("APIC calibration not consistent "
-  "with PM-Timer: %ldms instead of 100ms\n",(long)res);
+   pr_warn("APIC calibration not consistent with PM-Timer: %ldms instead 
of 100ms\n",
+   (long)res);
 
/* Correct the lapic counter value */
res = (((u64)(*delta)) * pm_100ms);
@@ -805,7 +805,7 @@ static int __init calibrate_APIC_clock(void)
 */
if (lapic_timer_frequency < (100 / HZ)) {
local_irq_enable();
-   pr_warning("APIC frequency too slow, disabling apic timer\n");
+   pr_warn("APIC frequency too slow, disabling apic timer\n");
return -1;
}
 
@@ -848,8 +848,8 @@ static int __init calibrate_APIC_clock(void)
local_irq_enable();
 
if (levt->features & CLOCK_EVT_FEAT_DUMMY) {
-   pr_warning("APIC timer disabled due to verification failure\n");
-   return -1;
+   pr_warn("APIC timer disabled due to verification failure\n");
+   return -1;
}
 
return 0;
@@ -923,7 +923,7 @@ static void local_apic_timer_interrupt(void)
 * spurious.
 */
if (!evt->event_handler) {
-   pr_warning("Spurious LAPIC timer interrupt on cpu %d\n", cpu);
+   pr_warn("Spurious LAPIC timer interrupt on cpu %d\n", cpu);
/* Switch it off */
lapic_timer_shutdown(evt);
retur

Re: [Nouveau] [PATCH v2 0/7] lib: string: add functions to case-convert strings

2016-07-05 Thread Joe Perches

On Tue, 2016-07-05 at 15:36 -0700, Markus Mayer wrote:
> On 5 July 2016 at 15:14, Joe Perches <j...@perches.com> wrote:
> > On Tue, 2016-07-05 at 13:47 -0700, Markus Mayer wrote:
> > > This series introduces a family of generic string case conversion
> > > functions. This kind of functionality is needed in several places in
> > > the kernel. Right now, everybody seems to be implementing their own
> > > copy of this functionality.
> > > 
> > > Based on the discussion of the previous version of this series[1] and
> > > the use cases found in the kernel, it does look like having several
> > > flavours of case conversion functions is beneficial. The use cases fall
> > > into three categories:
> > > - copying a string and converting the case while specifying a
> > >   maximum length to mimic strncpy()
> > > - copying a string and converting the case without specifying a
> > >   length to mimic strcpy()
> > > - converting the case of a string in-place (i.e. modifying the
> > >   string that was passed in)
> > > 
> > > Consequently, I am proposing these new functions:
> > > char *strncpytoupper(char *dst, const char *src, size_t len);
> > > char *strncpytolower(char *dst, const char *src, size_t len);
> > > char *strcpytoupper(char *dst, const char *src);
> > > char *strcpytolower(char *dst, const char *src);
> > > char *strtoupper(char *s);
> > > char *strtolower(char *s);
> > I think there isn't much value in anything other
> > than strto.
> > 
> > Using str[n]cpy followed by strto is
> > pretty obvious and rarely used anyway.
> First time around, folks were proposing the "copy" variants when I
> submitted just strtolower() by itself[1]. They just asked for source
> and destination parameters to strtolower(), but looking at the use
> cases that wouldn't have worked so well. Hence it evolved into these 6
> functions.
> 
> Here's a breakdown of how the functions are being used (patches 2-7),
> see also [2]:
> 
> Patch 2: strncpytolower()
> Patch 3: strtolower()
> Patch 4: strncpytolower() and strtolower()
> Patch 5: strtolower()
> Patch 6: strcpytoupper()
> Patch 7: strcpytoupper()
> 
> So it does look like the copy + change case variant is more frequently
> used than just strto.

Are these functions useful?   Not to me, not so much.

None of the functions would have the strcpy performance of
the arch / asm
versions of strcpy and the savings in overall
code isn't significant (or
measured?).

Of course none of the uses are runtime performance important.

This patch also adds always compiled functions that aren't used
in many .configs.

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2 0/7] lib: string: add functions to case-convert strings

2016-07-05 Thread Joe Perches

On Tue, 2016-07-05 at 13:47 -0700, Markus Mayer wrote:
> This series introduces a family of generic string case conversion
> functions. This kind of functionality is needed in several places in
> the kernel. Right now, everybody seems to be implementing their own
> copy of this functionality.
> 
> Based on the discussion of the previous version of this series[1] and
> the use cases found in the kernel, it does look like having several
> flavours of case conversion functions is beneficial. The use cases fall
> into three categories:
> - copying a string and converting the case while specifying a
>   maximum length to mimic strncpy()
> - copying a string and converting the case without specifying a
>   length to mimic strcpy()
> - converting the case of a string in-place (i.e. modifying the
>   string that was passed in)
> 
> Consequently, I am proposing these new functions:
> char *strncpytoupper(char *dst, const char *src, size_t len);
> char *strncpytolower(char *dst, const char *src, size_t len);
> char *strcpytoupper(char *dst, const char *src);
> char *strcpytolower(char *dst, const char *src);
> char *strtoupper(char *s);
> char *strtolower(char *s);

I think there isn't much value in anything other
than strto.

Using str[n]cpy followed by strto is
pretty obvious and rarely used anyway.

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] nouveau lockdep splat

2013-03-15 Thread Joe Perches

On Wed, 2013-03-06 at 12:31 -0700, Stephen Warren wrote:
 On 03/06/2013 12:14 PM, Marcin Slusarz wrote:
  On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote:
  On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
  Dropping Tegra ML, it's not the place where Nouveau mails should go.
 
  $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c
  ...
  linux-te...@vger.kernel.org (open list:TEGRA SUPPORT)
 
  Maybe get_maintainer.pl patterns need correction...
  
  That's new feature (introduced in commit eb90d0855b75f8 get_maintainer: 
  allow
  keywords to match filenames) of get_maintainer.pl which now can look at 
  file
  contents...
 
 get_maintainer.pl could always look at file contents IIRC. The change
 was that I added keyword tegra to the Tegra section that now matches
 this file's contents.
 
 ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau
 
 ... might be a better invocation, although perhaps I should add an
 explicit exclusion for nouveau to the Tegra section in MAINTAINERS.

Another option might be avoid overloading the K:
entry and use a different letter for the file name
pattern match (maybe N) and avoid looking for
tegra in the file or patch without another specific
K: keyword match.

Maybe:
---
 MAINTAINERS   | 10 +++---
 scripts/get_maintainer.pl |  2 +-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e95b1e9..76e0223 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -96,10 +96,14 @@ Descriptions of section entries:
   F:   net/
   X:   net/ipv6/
   matches all files in and below net excluding net/ipv6/
+   N: Filename wildcard pattern match, for instance:
+  N:   (?i)[^a-z]tegra
+  matches any filename with case insensitive tegra but not
+  any other word like integrate
K: Keyword perl extended regex pattern to match content in a
-  patch or file, or an affected filename.  For instance:
+  patch or file.  For instance:
   K: of_get_profile
- matches patch or file content, or filenames, that contain
+ matches patch or file content, that contain
  of_get_profile
   K: \b(printk|pr_(info|err))\b
  matches patch or file content, or filenames, that contain one or
@@ -7866,7 +7870,7 @@ L:linux-te...@vger.kernel.org
 Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
 T: git
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
 S: Supported
-K: (?i)[^a-z]tegra
+N: (?i)[^a-z]tegra
 
 TEHUTI ETHERNET DRIVER
 M: Andy Gospodarek a...@greyhouse.net
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index ce4cc83..5e4fb14 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -611,7 +611,7 @@ sub get_maintainers {
$hash{$tvi} = $value_pd;
}
}
-   } elsif ($type eq 'K') {
+   } elsif ($type eq 'N') {
if ($file =~ m/$value/x) {
$hash{$tvi} = 0;
}



___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 1/2] get_maintainer: create filename-only regex match type

2013-03-15 Thread Joe Perches

On Wed, 2013-03-06 at 16:36 -0700, Stephen Warren wrote:
 From: Stephen Warren swar...@nvidia.com
 
 Create a new N: entry type in MAINTAINERS which performs a regex match
 against filenames; either those extracted from patch +++ or --- lines,
 or those specified on the command-line using the -f option.

NAK

At least get the prefix right and remove the
now incorrect filename matches in K:

 diff --git a/MAINTAINERS b/MAINTAINERS
 index 9561658..1671842 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -90,6 +90,9 @@ Descriptions of section entries:
  F:   drivers/net/*   all files in drivers/net, but not below
  F:   */net/* all files in any top level directory/net
  One pattern per line.  Multiple F: lines acceptable.
 + N: Files and directories with regex patterns.
 +K:   [^a-z]tegra all files whose patch contains the word tegra

N: not K:

 +One pattern per line.  Multiple N: lines acceptable.
   X: Files and directories that are NOT maintained, same rules as F:
  Files exclusions are tested before file matches.
  Can be useful for excluding a specific subdirectory, for instance:

and remove the K: descriptions that show filename too.

 diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
 index ce4cc83..27dc5cb 100755
 --- a/scripts/get_maintainer.pl
 +++ b/scripts/get_maintainer.pl
 @@ -611,7 +611,7 @@ sub get_maintainers {
   $hash{$tvi} = $value_pd;
   }
   }
 - } elsif ($type eq 'K') {
 + } elsif ($type eq 'K' || $type eq 'N') {
   if ($file =~ m/$value/x) {
   $hash{$tvi} = 0;
   }

Remove K:  It has no value here.



___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames

2013-03-15 Thread Joe Perches

On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote:
 From: Stephen Warren swar...@nvidia.com
 
 This reverts most of eb90d08 get_maintainer: allow keywords to match
 filenames; all except the parts that are required to implement the new
 N: entry type.

Just combine patches 1 and 3 into a single patch.


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames

2013-03-15 Thread Joe Perches

On Wed, 2013-03-06 at 17:34 -0700, Stephen Warren wrote:
 On 03/06/2013 05:30 PM, Joe Perches wrote:
  On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote:
  From: Stephen Warren swar...@nvidia.com
 
  This reverts most of eb90d08 get_maintainer: allow keywords to match
  filenames; all except the parts that are required to implement the new
  N: entry type.
  
  Just combine patches 1 and 3 into a single patch.
 
 That would break bisectability; using MAINTAINERS after applying a
 squashed 1+3 but without patch 2 applied would not operate as desired.

smile

Which is why I showed the whole thing in a single patch.
No worries if it's simply to increase the patch count...

cheers, Joe

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH V2 3/3] get_maintainer: prevent keywords from matching filenames

2013-03-15 Thread Joe Perches

On Wed, 2013-03-06 at 23:47 -0700, Stephen Warren wrote:
 On 03/06/2013 05:40 PM, Joe Perches wrote:
  Which is why I showed the whole thing in a single patch.
  No worries if it's simply to increase the patch count...
 
 I'm not sure what showed refers to?

The changes I posted with the suggestion
https://lkml.org/lkml/2013/3/6/468

 I guess if I squashed /everything/ into a single commit (i.e. the change
 to the Tegra section in MAINTAINERS too) then there wouldn't be any
 bisect issues. I really don't care about patch count. The reason for 1
 patch is that there's often push-back if doing logically separate things
 (adding N: feature, modifying a MAINTAINERS entry to use it, removing
 part of K: feature) in a single patch...

Not from me anyway.

I think it's a single logical change and
it's trivial too.

No worries whatever happens.

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH V3] get_maintainer: use filename-only regex match for Tegra

2013-03-15 Thread Joe Perches

On Mon, 2013-03-11 at 14:19 -0600, Stephen Warren wrote:
 Create a new N: entry type in MAINTAINERS which performs a regex match
 against filenames; either those extracted from patch +++ or --- lines,
 or those specified on the command-line using the -f option.
[]
 Switch the Tegra entry from using K: to N:

Acked-by: Joe Perches j...@perches.com


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] More on getting Nouveau to work

2010-06-12 Thread Joe Zeff

I installed Fluxbox, killed Xorg and logged in again.  I got a usable 
desktop, rather than a blank white screen.  Progress, sort of.  I 
brought up Gnome's configuration editor, and told it to use metacity, 
not compiz, logged out, and back in.  No change.  Checking, however, 
it's still using compiz, not metacity, and metacity is known to be 
installed.  Weird!  However, this does point to Gnome and/or compiz as 
being the culprit.

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

46 matches

Mail list logo