Re: Linux 6.3-rc3

On Mon, Mar 20, 2023 at 1:05 PM Guenter Roeck wrote: > > I have noticed that gcc doesn't always warn about uninitialized variables > in most architectures. Yeah, I'm getting the feeling that when the gcc people were trying to make -Wmaybe-uninitialized work better (when moving it into "-Wall"), t

Re: Linux 6.3-rc3

On Mon, Mar 20, 2023 at 3:06 PM Nathan Chancellor wrote: > > Right, this seems like a subtle difference in semantics between > -Wuninitialized between clang and GCC. I guess it's a bit ambiguous whether it's "X may be USED uninitialized" or whether it is "X may BE uninitialized" and then de

Re: Linux 6.3-rc3

On Wed, Mar 22, 2023 at 9:40 AM Sedat Dilek wrote: > > You have to pass `make LLVM=1` in any case... to `oldconfig` or when > adding any MAKEFLAGS like -j${number-of-available-cpus}. I actually think we should look (again) at just making the compiler choice (and the prefix) be a Kconfig option.

Re: [pull] amdgpu drm-fixes-6.4

On Fri, 23 Jun 2023 at 14:18, Alex Deucher wrote: > > are available in the Git repository at: > > https://gitlab.freedesktop.org/agd5f/linux.git > tags/amd-drm-fixes-6.4-2023-06-23 That's not a valid signed tag. Yes, it's a tag. But it doesn't actually have any cryptographic signing, and I'm

Re: [git pull] drm fixes for 6.5-rc4

On Thu, 27 Jul 2023 at 19:20, Dave Airlie wrote: > > Regular scheduled fixes, msm and amdgpu leading the way, with some > i915 and a single misc fbdev, all seems fine. Pulled. Tangentially related: where do you keep your pgp key? The one I have is long expired, and doing a refresh doesn't get an

[git pull] drm for 4.8

What's the status of the 4.9 merge window pull request? The GPU side is the main remaining pile for this merge window according to linux-next. I'd hate to get a last-minute pull at the end of the week ... Linus

[git pull] drm pull for v4.9

On Tue, Oct 11, 2016 at 2:14 PM, Dave Airlie wrote: > > this email is all in small letters because my gpg key expired so I couldn't > sign the tag, and it's too early in the morning for me to go do gpg stuff. I'm happy that you have found alternative identity management model, but I'm not sure th

Re: [PATCH 0/2] drm/i915: Backport vma fixes for 4.10-rc6

On Tue, Jan 31, 2017 at 1:21 AM, Maarten Lankhorst wrote: > > This is marked for rc6 because it seems the issue is triggerable on > mainline and resulting in an oops. So I did apply my obvious "avoid the oops and just warn about it" patch: commit 39cb2c9a316e ("drm/i915: Check for NULL i915_vma i

Re: [git pull] drm for v4.11 - main pull request

On Thu, Feb 23, 2017 at 4:01 PM, Dave Airlie wrote: > > This is the main drm pull request for v4.11. > > Nothing too major, the tinydrm and mmu-less support should make writing > smaller drivers easier for some of the simpler platforms, and there are > a bunch of documentation updates. The tinydr

Re: [git pull] drm for v4.11 - main pull request

On Thu, Feb 23, 2017 at 5:44 PM, Linus Torvalds wrote: > > AND WHY THE HELL WAS THIS UTTER SHITE SENT TO ME IF IT WAS COMMITTED > YESTERDAY? .. and a slightly less annoying piece of crap in this pull request: that "PRIME_NUMBERS" config thing is utter garbage too. Why w

[git pull] drm fixes for 4.9-rc4

On Wed, Nov 2, 2016 at 5:31 PM, Dave Airlie wrote: > > There are a set of fixes for an oops we've been seeing around MST > display unplug, Side note: I heard from a couple of people at the KS that said that they had had problems with suspend/resume after plugging in to a 4k display (but _only_ a

Re: [git pull] drm fixes for 4.12-rc8

On Wed, Jun 28, 2017 at 12:18 AM, Dave Airlie wrote: > > git://people.freedesktop.org/~airlied/linux drm-fixes-for-v4.12-rc8 That tag does not exist. However: > for you to fetch changes up to 9ff1beb1d19ffe2b26bf9cd2d33e6073d4f4b5fe: That commit 9ff1beb1d19f _is_ the head of the 'drm-fixes'

Re: [git pull] drm fixes for 4.12-rc8

On Wed, Jun 28, 2017 at 12:18 AM, Dave Airlie wrote: > > I've got next locked down, so whenever you open the merge > window and I get back I'll send it to you. Just checking in on this part.. I think the drm stuff it the major missing piece for 4.13 now. Linus

Re: [git pull] drm for v4.13

On Sun, Jul 9, 2017 at 8:01 PM, Dave Airlie wrote: > > Forgot to add, because I just checked now, there are 2 conflicts, > the drm one with patches from Al, and one in i915_gem_execbuffer.c > which I think resolves best by just taking the code from the pull in place > of code in your tree. Heh. I

Re: [git pull] drm pull for v4.12

On Tue, May 2, 2017 at 8:44 PM, Dave Airlie wrote: > > i915: > vblank evasion improvements These may be "improvements", but they end up being very noisy. I geta fair amount of messages like [drm] Atomic update on pipe (A) took 161 us, max time under evasion is 100 us on my desktop (i7-6700K)

Re: [git pull] drm fixes for v4.12-rc1

.. and here's the email repeated for the new dri-devel list, since apparently Dave sent the pull request to the old no-longer-working one that just sends annoying bounces. Dave, time to update your scripts and address book.. Linus On Fri, May 12, 2017 at 11:54 AM, Linus Tor

Re: [git pull] drm fixes for v4.12-rc1

On May 12, 2017 12:30 PM, "Dave Airlie" wrote: > > Dave, time to update your scripts and address book.. wierd gmail failed me. I think gmail is sometimes too smart for its own good. It takes the other recipients into account when auto-completing the recipients list, so even if you *normally* s

Re: [git pull] drm fixes for v4.12-rc1

On Thu, May 11, 2017 at 11:00 PM, Dave Airlie wrote: > > It also has an amdgpu fixes pull, with lots of ongoing work on Vega10 > which is new in this kernel and is preliminary support so may have a > fair bit of movement. Note: I will *not* be taking these kinds of pull requests after rc1. If Ve

[git pull] drm fixes for rc5

On Thu, Sep 1, 2016 at 10:59 PM, Dave Airlie wrote: > > I've tried using a signed tag, let's see if works. Worked fine. But your email was once again marked as spam. Google hates you, and your email habits. Linus

[git pull] drm fixes for 4.8-rc6

On Fri, Sep 16, 2016 at 3:15 PM, Dave Airlie wrote: > > I've sent this from my gmail address to see if I can avoid > the spam folders. You were successful. Thanks, Linus

[PULL] drm-intel-fixes

On Thu, Jan 5, 2017 at 3:19 AM, Jani Nikula wrote: > > Hi Dave, or Linus if Dave's on vacation, I'm a bit unsure, I'm going to ignore this on the assumption that Dave is around. But if nothing happens for a few days, ping me again and I'll pull it directly. Ok? Linus

[git pull] drm for v4.7

On Sun, May 22, 2016 at 11:41 PM, Dave Airlie wrote: > > Here's the main drm pull request for 4.7, it's been > a busy one, and I've been a bit more distracted in > real life this merge window. Hmm. I pulled this, but I think I'll have to unpull again. Neither the diffstat not the shortlog match

[git pull] drm for v4.7

On Mon, May 23, 2016 at 11:59 AM, Linus Torvalds wrote: > > I'll test this out and look what happens, but I hate getting different > results than what I'm told to expect. Hmm. I also get a lot of ./usr/include/drm/amdgpu_drm.h:38: userspace cannot reference function or vari

[git pull] drm for v4.7

On Wed, May 25, 2016 at 1:28 AM, Jani Nikula wrote: > > There may be better ones out there, but Artem's "aiaiai" has some > helpers [1] for diffing build logs, if you want something simple to > integrate into existing scripts. It would be lovely to have some kind of warning detection, but quite f

objtool warning: "duplicate frame pointer save"

Josh, my current git version (with gcc 5.3.1) makes objtool warn about "duplicate frame pointer save" in drivers/gpu/drm/vmwgfx/vmwgfx_msg.c for both vmw_send_msg() and vmw_host_get_guestinfo(). The reason is that VMW_PORT_HB_OUT() uses a magic instruction sequence (a "rep outsb") to communicate

objtool warning: "duplicate frame pointer save"

On Wed, May 25, 2016 at 10:56 AM, Josh Poimboeuf wrote: > > I used to have a STACKTOOL_IGNORE_INSN macro that would tell the tool to > skip warnings for specific instructions in inline asm: > > Here's an example of it how it was used: Ok, looking at that, I'm starting to suspect that it is simple

[PATCH] drm/vmwgfx: fix "duplicate frame pointer save" warning

On Thu, May 26, 2016 at 11:43 AM, Josh Poimboeuf wrote: > > That's fine with me, it is indeed a rare case. We can always add the > per-instruction macro later if needed. Here's a patch. Ingo, I can take this directly, unless you have other things pending that you want to send anyway and would

[git pull] drm fixes

On Thu, Feb 25, 2016 at 6:20 PM, Dave Airlie wrote: > > This is a bit larger than Id like, but I asked the Intel guys to pull in > some Skylake fixes in the possibly vain hope that Skylake might be more > functional now that I'm seeing production hardware shipping. > > For i915, it's mostly the sa

[PULL] drm-intel-fixes

On Jan 3, 2016 18:06, "Dave Airlie" wrote: > > can you pull this directly, baby has arrived, but I'm not back at work yet. Assumed so, and already did. It's in rc8, Linus -- next part -- An HTML attachment was scrubbed... URL:

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Mon, Jan 11, 2016 at 3:28 AM, Chris Wilson wrote: > > Bizarrely, > > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c > index 6000ad7..cf074400 100644 > --- a/arch/x86/mm/pageattr.c > +++ b/arch/x86/mm/pageattr.c > @@ -141,6 +141,7 @@ void clflush_cache_range(void *vaddr, unsigned

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Tue, Jan 12, 2016 at 8:37 AM, Chris Wilson wrote: > On Mon, Jan 11, 2016 at 09:05:06PM +, Chris Wilson wrote: >> I can narrow down the principal buggy path by doing the clflush(vend-1) >> in the callers at least. > > That leads to the suspect path being a read back of a cache line from > m

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Tue, Jan 12, 2016 at 1:13 PM, Chris Wilson wrote: > > That is a continual worry. To try and assuage that fear, I sent 8x > flush gpu writes between the end of the copy and setting the "I'm done" > flag. The definition of the GPU flush is that it both flushes all > previous writes before it com

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Tue, Jan 12, 2016 at 4:55 PM, Chris Wilson wrote: > > The double clflush() remains a mystery. Actually, I think it's explainable. It's wrong to do the clflush *after* the GPU has done the write, which seems to be what you are doing. Why? If the GPU really isn't cache coherent, what can hap

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Tue, Jan 12, 2016 at 6:42 PM, Andy Lutomirski wrote: > > Since barriers are on my mind: how strong a barrier is needed to > prevent cache fills from being speculated across the barrier? I don't think there are *any* architectural guarantees. I suspect that a real serializing instruction shoul

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Wed, Jan 13, 2016 at 4:34 AM, Chris Wilson wrote: > > Forgive me for being dense, but if we overwrite the GPU data in the > backing struct page with the cacheline from the CPU, how do we see the > results from the GPU afterwards? Hmm. Good point. Ok, all the symptoms just say "writes from GP

[git pull] drm for 4.5-rc1

On Sun, Jan 17, 2016 at 1:35 PM, Dave Airlie wrote: > > This is the main drm pull request for 4.5. I don't think I've missed anything > too > major, I'm mostly back at work now but I'll probably get some sleep in 5 > years time. Good luck with that. > I think it should fix the i915 warning fro

Re: [git pull] drm fixes for 5.8-rc8

On Tue, Jul 28, 2020 at 9:44 PM Dave Airlie wrote: > > If you feel this is too much I'm happy to respin with the > core/drm_fb_helper and nouveau fixes. we have one outstanding nouveau > regression fix, that I'll follow this up with in the next day or so > once Ben and James get it reviewed. This

Re: [git pull] drm next pull for 5.10-rc1

On Wed, Oct 14, 2020 at 6:33 PM Dave Airlie wrote: > > There are a bunch of conflicts but none of them seemed overly scary, > and sfr has provided resolutions for them all. I've put a tree up with > my merge results, so you can tell me I did it wrong here: > https://cgit.freedesktop.org/~airlied/

Re: [git pull] drm next pull for 5.10-rc1

On Thu, Oct 15, 2020 at 10:51 AM Linus Torvalds wrote: > > Thanks, looks good to me [..] Uhhuh. I already pushed things out, but my clang build (which I don't do between each merge) shows a problem: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:650:8

Re: [PATCH 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles

On Tue, Mar 24, 2020 at 1:49 AM Masahiro Yamada wrote: > > If it is OK to queue this up to Kbuild tree, > I will send a pull request to Linus. Looks fine to me, assuming we didn't now get some confusion due to duplicate patches (I think Jason got his tree added to -next already). And yeah, that

Re: [git pull] drm for 5.7-rc1

On Thu, Apr 2, 2020 at 1:33 PM Nathan Chancellor wrote: > > This fixes it but I am not sure if it is proper or not (could be > problematic if CONFIG_PHYS_ADDR_T_64BIT is set but > CONFIG_ARCH_DMA_ADDR_T_64BIT is not, not sure if that is possible) so I > figured I'd report it and let you guys deal

Re: [PATCH] drm/legacy: Fix type for drm_local_map.offset

On Fri, Apr 3, 2020 at 1:29 AM Daniel Vetter wrote: > > > Tested-by: Nathan Chancellor # build > > This works too, missed it when replying to Linus > > Reviewed-by: Daniel Vetter > > Linus I guess this one is better, but like I explained it really > doesn't matter what we do with drm legacy code

Re: [git pull] drm fixes for 5.7-rc2

On Fri, Apr 17, 2020 at 9:24 PM Dave Airlie wrote: > > amdgpu: > - Fix a regression in a previous s/r fix Side note: if I hadn't been cc'd on the problem, I'd never have had a clue what s/r stood for. I'd have assumed that it's some special amdgpu term. And the language in the actual commit mess

Re: [patch 00/13] preempt: Make preempt count unconditional

On Mon, Sep 14, 2020 at 1:45 PM Thomas Gleixner wrote: > > Recently merged code does: > > gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC; > > Looks obviously correct, except for the fact that preemptible() is > unconditionally false for CONFIF_PREEMPT_COUNT=n, i.e. all allocations in > tha

Re: [patch 00/13] preempt: Make preempt count unconditional

On Mon, Sep 14, 2020 at 2:55 PM Thomas Gleixner wrote: > > Yes it does generate better code, but I tried hard to spot a difference > in various metrics exposed by perf. It's all in the noise and I only > can spot a difference when the actual preemption check after the > decrement I'm somewhat mor

Re: [patch 00/13] preempt: Make preempt count unconditional

On Mon, Sep 14, 2020 at 3:24 PM Linus Torvalds wrote: > > Ard and Herbert added to participants: see > chacha20poly1305_crypt_sg_inplace(), which does > > flags = SG_MITER_TO_SG; > if (!preemptible()) > flags |= SG_MITER_ATOMIC; >

Re: [patch 00/13] preempt: Make preempt count unconditional

On Mon, Sep 14, 2020 at 11:24 PM Herbert Xu wrote: > > On Tue, Sep 15, 2020 at 09:20:59AM +0300, Ard Biesheuvel wrote: > > > > The documentation of kmap_atomic() states the following: > > > > * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap > > * gives a more generic (and cach

Re: [patch 00/13] preempt: Make preempt count unconditional

On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner wrote: > > OTOH, having a working 'preemptible()' or maybe better named > 'can_schedule()' check makes tons of sense to make decisions about > allocation modes or other things. No. I think that those kinds of decisions about actual behavior are alwa

Re: [patch 00/13] preempt: Make preempt count unconditional

On Tue, Sep 15, 2020 at 12:24 AM Thomas Gleixner wrote: > > Alternatively we just make highmem a bit more expensive by making these > maps preemptible. RT is doing this for a long time and it's not that > horrible. Ack. In fact, I've wanted to start just removing kmap support entirely. At some p

Re: [patch 00/13] preempt: Make preempt count unconditional

On Wed, Sep 16, 2020 at 8:29 AM Paul E. McKenney wrote: > > All fair, but some of us need to write code that must handle being > invoked from a wide variety of contexts. Note that I think that core functionality is different from random drivers. Of course core code can (and will) look at things

Re: [patch 00/13] preempt: Make preempt count unconditional

On Tue, Sep 15, 2020 at 12:57 PM Thomas Gleixner wrote: > > You wish. I just found a 7 year old bug in a 10G network driver which > surely would have been found if people would enable debug configs and > not just run the crap on their PREEMPT_NONE, all debug off kernel. And > that driver is not su

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote: > > this provides a preemptible variant of kmap_atomic & related > interfaces. This is achieved by: Ack. This looks really nice, even apart from the new capability. The only thing I really reacted to is that the name doesn't make sense to me

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sat, Sep 19, 2020 at 10:39 AM Matthew Wilcox wrote: > > My concern with that is people might use kmap() and then pass the address > to a different task. So we need to audit the current users of kmap() > and convert any that do that into using vmap() instead. Ahh. Yes, I guess they might do th

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sun, Sep 20, 2020 at 1:49 AM Thomas Gleixner wrote: > > Actually most usage sites of kmap atomic do not need page faults to be > disabled at all. Right. I think the pagefault disabling has (almost) nothing at all to do with the kmap() itself - it comes from the "atomic" part, not the "kmap" pa

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sun, Sep 20, 2020 at 10:40 AM Thomas Gleixner wrote: > > I think the more obvious solution is to split the whole exercise: > > schedule() > prepare_switch() > unmap() > > switch_to() > > finish_switch() > map() Yeah, that looks much easier to explain. Ack.

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Sun, Sep 20, 2020 at 10:42 AM Linus Torvalds wrote: > > Yeah, that looks much easier to explain. Ack. Btw, one thing that might be a good idea at least initially is to add a check for p->kmap_ctrl.idx being zero at fork, exit and maybe syscall return time (but that last one m

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote: > > If a task is migrated to a different CPU then the mapping address will > change which will explode in colourful ways. Heh. Right you are. Maybe we really *could* call this new kmap functionality something like "kmap_percpu()" (or maybe

Re: [git pull] drm fixes for 5.9-rc4

On Thu, Sep 3, 2020 at 8:53 PM Dave Airlie wrote: > > Not much going on this week, nouveau has a display hw bug workaround, > amdgpu has some PM fixes and CIK regression fixes, one single radeon > PLL fix, and a couple of i915 display fixes. Any movement on the i915 relocation issue? I've only se

Re: [git pull] drm fixes for 5.9-rc4

On Fri, Sep 4, 2020 at 2:51 PM Harald Arnesen wrote: > > Still doesn't work without the three reverts > (763fedd6a216, 9e0f9464e2ab, 7ac2d2536dfa)... So this didn't make rc4, but it's in my tree now. Harald, I'm assuming things work for you again now with the current git tree, but it is always g

Re: [git pull] drm fixes for 5.7-rc8/final

On Thu, May 28, 2020 at 5:21 PM Dave Airlie wrote: > > Seems to have wound down nicely, a couple of i915 fixes, amdgpu fixes > and minor ingenic fixes. Dave, this doesn't even build. WTF? In drivers/gpu/drm/i915/gt/selftest_lrc.c, there's a engine_heartbeat_disable() function that takes two argu

Re: [git pull] drm for 5.8-rc1

On Mon, Jun 1, 2020 at 11:06 PM Dave Airlie wrote: > > This tree is a bit conflicty, the i915 ones are probably the hairy > ones, but amdgpu has a bunch as well, along with smattering of others. Hmm. Some of them are due to your previous mis-merges. Your commit 937eea297e26 ("Merge tag 'amd-drm-

Re: [git pull] drm for 5.8-rc1

On Tue, Jun 2, 2020 at 2:21 PM Linus Torvalds wrote: > > Hmm. Some of them are due to your previous mis-merges. > > Your commit 937eea297e26 ("Merge tag 'amd-drm-next-5.8-2020-04-24' of > git://people.freedesktop.org/~agd5f/linux into drm-next") seems to &g

Re: [git pull] drm for 5.8-rc1

On Tue, Jun 2, 2020 at 2:21 PM Linus Torvalds wrote: > > I'm still working through the rest of the merge, so far that was the > only one that made me go "Whaa?". Hmm. I'm also ending up effectively reverting the drm commit b28ad7deb2f2 ("drm/tidss: U

Re: [git pull] drm for 5.8-rc1

On Mon, Jun 1, 2020 at 11:06 PM Dave Airlie wrote: > > I've pushed a merged by me tree here, which I think gets them all > correct, but please let me know if you think different. > https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-5.8-merged Ok, I get the same result, except my resolution to

[git pull] drm fixes

On Thu, May 21, 2015 at 8:39 PM, Dave Airlie wrote: > > radeon has two displayport fixes, one for a regressions, > i915 regression flicker fix needed to 4.0 can get fixed. Ok, I'm used to fixing up your whitespace and lack of capitalization, but you're getting so incoherent that I can no longer e

[git pull] drm fixes

On Fri, May 22, 2015 at 4:20 PM, Dave Airlie wrote: > > Really ^to^so Ahh. That simple one-letter substitution makes all the difference, now it's suddenly parseable. Thanks, Linus

[PATCH 1/1] Revert "drm/i915: drop i915_ prefix from enable_rc6, enable_fbc, enable_ppgtt parameters"

Sorry for the top post, I'm on the road.. In wondering if we couldn't just keep both the old an the new names and have them both point at the same variable? Remove the description for the old name, but keep it working? Linus On Jul 16, 2014 8:34 AM, "Amit Shah" wrote: > This reverts commit

[git pull] drm merge tree

On Wed, Jun 11, 2014 at 5:58 PM, Dave Airlie wrote: > > This is the main drm merge window pull request, changes all over the place, > mostly normal levels of churn. Hmm. I just had the machine reboot on me when booting this and starting X, leaving nothing in the logs. This is on a bog-standard

[git pull] drm merge tree

On Thu, Jun 12, 2014 at 12:06 PM, Linus Torvalds wrote: > > I just had the machine reboot on me when booting this and starting X, > leaving nothing in the logs. Ok, I can't recreate it, and as such I can't be sure that it was even the drm merge that causes it (although the ti

WARNING: CPU: 1 PID: 2846 at drivers/gpu/drm/i915/intel_sdvo.c:1378

This one may have been going on for some time - I haven't updated the old Intel Mac Mini in a while. And by "not updated" I also mean that it's some really old user-space: the machine is running F14, and cannot be updated to anything newer without having to reinstall everything because of a stupid

Re: [git pull] drm build fix

On Sat, Aug 3, 2013 at 6:08 PM, Dave Airlie wrote: > > Alex Deucher (1): > drm/radeon: fix 64 bit divide in SI spm code That code is stupid. You're asking for a 64-by-64 divide, when the divisor is clearly an "int" (100 and 1000 respectively). Why is it doing "div64_s64()" instead of the s

Re: [Intel-gfx] WARNING: CPU: 1 PID: 2846 at drivers/gpu/drm/i915/intel_sdvo.c:1378

On Fri, Aug 2, 2013 at 2:26 AM, Ville Syrjälä wrote: > > Looks like this could happen when you go to DPMS_OFF. After we've turned > off the the pipe, get_pipe_config() gives a mostly zeroed pipe_config > (including pixel_multiplier), and then in the case of SDVO, we go and > check it against the e

Re: [git pull] drm fixes

On Thu, Aug 29, 2013 at 4:08 PM, Dave Airlie wrote: > > ssh://people.freedesktop.org/~airlied/linux drm-fixes Please people! When you post ssh addresses, always remember to also post your user name and password or private key with the pull request. Ok? Linus _

Re: [git pull] drm fixes

Hmm. I just updated my machine to a i7-4770S (kept everything else the same, just switched out motherboards), and now when my display goes to sleep, it seems to never come back. Any known issues with DVI on Haswell (it seems to show up as "HDMI1" as the output, but it's a DVI cable)? I need to get

Re: [git pull] drm fixes

On Sat, Aug 31, 2013 at 4:02 PM, Linus Torvalds wrote: > > Any known issues with DVI on Haswell (it seems to show up as "HDMI1" > as the output, but it's a DVI cable)? With a DP cable and the same monitor, the problem doesn't seem to occur. So it does seem to someho

Re: [git pull] drm fixes

On Sun, Sep 1, 2013 at 11:54 PM, Daniel Vetter wrote: > On Sat, Aug 31, 2013 at 04:02:16PM -0700, Linus Torvalds wrote: >> Hmm. I just updated my machine to a i7-4770S (kept everything else the >> same, just switched out motherboards), and now when my display goes to >> sle

Re: [git pull] drm tree for 3.12-rc1

On Thu, Sep 5, 2013 at 3:41 AM, Dave Airlie wrote: > > i915: Haswell PC8+ support and eLLC support, HDMI 4K support, initial > per-process VMA pieces, > watermark reworks, convert to generic hdmi infoframes, encoder > reworking, fastboot support, Hmm. The first time I booted this, I just

Re: [git pull] drm tree for 3.12-rc1

On Thu, Sep 5, 2013 at 3:51 PM, Linus Torvalds wrote: > > I've booted a few times since (it's the merge window, so I boot fairly > frequently), and it hasn't happened again... .. and of course, after I say that, on the very next boot it then happened three times in

Re: [git pull] drm tree for 3.12-rc1

On Thu, Sep 5, 2013 at 3:32 PM, Jesse Barnes wrote: > On Thu, 5 Sep 2013 12:18:32 -0700 >> >> The first time I booted this, I just got a black screen on my Haswell >> desktop when X11 started up. I could ctrl-alt-BS and ctrl-alt-del to >> reboot the machine, and neither the Xorg.0.log nor the dme

Re: [git pull] drm tree for 3.12-rc1

On Thu, Sep 5, 2013 at 3:51 PM, Linus Torvalds wrote: > > Looking more closely at the log-file, I notice that the oops, pressed the send-button a bit too early.. Anyway, looking more closely at the log-file, I notice that while it has zero errors, it does seem to end just where a successf

Re: [git pull] drm tree for 3.12-rc1

On Thu, Sep 5, 2013 at 4:19 PM, Linus Torvalds wrote: > > So I've decided I'm going to try to bisect this after all. I've done > enough pulls for today anyway, I guess. Let's see if I can bisect it > by just trying to boot many times each try. Ok, it's no

Re: [git pull] drm tree for 3.12-rc1

[ Dave - your linux.ie email generates bounces for me, trying redhat instead ] On Mon, Sep 9, 2013 at 11:25 PM, Sean V Kelley wrote: >> >> I'm also a bit bummed that hw acceleration of video doesn't seem to >> work on Haswell, meaning that full-screen is now a jerky mess. I fear >> that that is u

Re: [git pull] drm radeon/nouveau/core fixes

On Wed, Sep 18, 2013 at 9:07 PM, Dave Airlie wrote: > > mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix > for AST driver. Ugh. I hope things calm down from here. Linus ___ dri-devel mailing list dri-devel@lists.freedesk

[git pull] drm fixes for rc4 or 5

On Sun, Aug 28, 2016 at 2:00 PM, Dave Airlie wrote: > > I probably missed -rc4 by minutes, but maybe pointless GPL enforcement > debates are distracting you enough! Hey, they must be good for _something_. Anyway, the real problem was that this was in my spam-box. Which I've learnt to check relig

[git pull] drm fixes for rc4 or 5

On Sun, Aug 28, 2016 at 2:31 PM, Linus Torvalds wrote: > > Anyway, the real problem was that this was in my spam-box. Which I've > learnt to check religiously, so I noticed almost immediately. Btw, on a totally unrelated issue: you make thes pull points tags (good), but they

[git pull] drm amd acp audio support - optional

On Wed, Feb 3, 2016 at 4:04 PM, Dave Airlie wrote: > > I'm happy enough it shouldn't cause any problems, just wanted to > check if you'd take it now or not. Honestly, this feels like "might as well wait for 4.6" to me. I'm generally ok with taking completely new drivers later in the rc if there'

Stupid NVIDIA 3D vgaarb.c patch

Adding proper people and mailing lists.. The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is appropriate, but hopefully somebody does. The fact that it makes things work certainly argues fairly convincingly for it, but I want

[git pull] drm fixes

On Thu, Apr 21, 2016 at 5:57 PM, Dave Airlie wrote: > > git://people.freedesktop.org/~airlied/linux drm-fixes Hmm. freedesktop.org seems to be feeling a bit under the weather. It's not just the git part - it's not doing web either, and doesn't seem to answer to pings either (I saw _one_ ping re

[git pull] drm fixes

On Fri, Apr 22, 2016 at 10:23 AM, Daniel Vetter wrote: > > Works all fine here, http, ssh & git protocols all up&running well. > Maybe temporary, or just your part of the interwebs fell off? It's up for me now too, so something temporary. I don't think it was at my end, everything else seemed to

Re: [GIT PULL] VLA removal for v4.20-rc1

On Sun, Oct 28, 2018 at 10:24 AM Kees Cook wrote: > > Please pull these VLA removal changes for v4.20-rc1. Pulled, Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-de

Re: [git pull] drm pull for 4.20-rc1

On Sun, Oct 28, 2018 at 4:47 PM Dave Airlie wrote: > > I was just about to ask if I'd gotten a reply that require Linus > filtering, then I realised I hadn't sent this to you, but the mailing > list by mistake. Heh. And _I_ was just about to send you a query about where the pull request was, sinc

Re: [git pull] drm pull for 4.20-rc1

On Sun, Oct 28, 2018 at 4:47 PM Dave Airlie wrote: > > This is the main drm pull request for 4.20-rc1. .. pulled. I'm not sure I love the new list helper, but it's not wrong. I think it would probably have been cleaner to do this as a "cut out first->last" followed by "splice to tail" pair (we

Re: [GIT PULL] fbdev changes for v4.20

On Wed, Oct 31, 2018 at 7:31 AM Bartlomiej Zolnierkiewicz wrote: > > Please pull fbdev changes for v4.20. No major changes to the subsystem > itself, mainly fb drivers fixes & cleanups (atyfb & udlfb updates stand > out from the rest) + removal of no longer needed old clps711xfb driver. Pulled,

Re: [git pull] drm for v4.18-rc1

On Tue, Jun 5, 2018 at 8:50 PM Dave Airlie wrote: > > First up I've moved the drm tree to a new location on freedesktop.org. The > main > reason was to explore using Daniel's maintainer tools (dim-tools) to manage > pull requests and possibly open the drm to having co-maintainers at the top > lev

Re: Kernel and ADM hardware roulette ( was AMD graphics performance regression in 4.15 and later )

On Mon, Jun 11, 2018 at 12:07 AM Christoph Hellwig wrote: > > For now I'd say revert this commit for 4.17/4.18-rc and I'll look into > addressing these issues properly. Ok, reverted in my tree, and marked for stable (for 4.17). Thanks, Linus _

Re: [git pull] drm next fixes for 4.20-rc1

On Thu, Nov 1, 2018 at 10:32 PM Dave Airlie wrote: > > Pretty much a normal fixes pull pre-rc1, mostly amdgpu fixes, one i915 > link training regression fix, and a couple of minor panel/bridge fixes > and a panel quirk. Pulled, Linus

Possible use_mm() mis-uses

Guys and gals, this is a *very* random list of people on the recipients list, but we had a subtle TLB shootdown issue in the VM, and that brought up some issues when people then went through the code more carefully. I think we have a handle on the TLB shootdown bug itself. But when people were di

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 11:21 AM Paolo Bonzini wrote: > > Yes, KVM is correct but the i915 bits are at least fishy. It's probably > as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init > and kvmgt_guest_exit, or maybe mmget_not_zero. Definitely mmget_not_zero(). If it was just

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 11:33 AM Linus Torvalds wrote: > > On Wed, Aug 22, 2018 at 11:21 AM Paolo Bonzini wrote: > > > > Yes, KVM is correct but the i915 bits are at least fishy. It's probably > > as simple as adding a mmget/mmput pair respectively in kvmgt_guest_

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 12:37 PM Oded Gabbay wrote: > > Having said that, I think we *are* protected by the mmu_notifier > release because if the process suddenly dies, we will gracefully clean > the process's data in our driver and on the H/W before returning to > the mm core code. And before we

<    1   2   3   4   5   6   7   8   >