On Tue, Apr 27, 2021 at 8:32 PM Dave Airlie wrote:
>
> This is the main drm pull request for 5.13. The usual lots of work all
> over the place. [...]
>
> Mikita Lipski:
> drm/amd/display: Add MST capability to trigger_hotplug interface
Hmm. I've already merged this, but my clang build shows
On Wed, Apr 28, 2021 at 11:14 AM Daniel Vetter wrote:
>
> Maybe we're overdoing it a bit, but we're trying to not backmerge all
> the time for no reason at all.
Oh, I'm not complaining. I think it's reasonable if some particular
issue doesn't hold up further development.
So my email was more a s
On Tue, Apr 27, 2021 at 8:32 PM Dave Airlie wrote:
>
> There aren't a massive amount of conflicts, only with vmwgfx when I
> did a test merge into your master yesterday, I think you should be
> able to handle them yourself, but let me know if you want me to push a
> merged tree somewhere (or if I
On Tue, Apr 27, 2021 at 4:43 PM Linus Torvalds
wrote:
>
> I think I will make the argument type to intel_print_wm_latency() be
> just "const u16 wm[]" for now, just to avoid seeing a ton of silly
> warnings.
After fixing the trivial ones, this one remains:
driver
I've updated to Fedora 34 on one of my machines, and it causes a lot
of i915 warnings like
drivers/gpu/drm/i915/intel_pm.c: In function ‘ilk_setup_wm_latency’:
drivers/gpu/drm/i915/intel_pm.c:3059:9: note: referencing argument 3
of type ‘const u16 *’ {aka ‘const short unsigned int *’}
driver
On Sun, Apr 11, 2021 at 2:43 PM Maciej W. Rozycki wrote:
>
> So it does trigger with vgacon and my old server, which I have started
> experimenting with and for a start I have switched to a new kernel for an
> unrelated purpose (now that I have relieved it from all its usual tasks
> except for th
On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter wrote:
>
> Cc all the mailing lists ... my usual script crashed and I had to
> hand-roll the email and screwed it up ofc :-/
Oh, and you also didn't get a pr-tracker-bot response for this for the
same reason.
Even your fixed email was ignored by the
On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter wrote:
>
> Cc all the mailing lists ... my usual script crashed and I had to
> hand-roll the email and screwed it up ofc :-/
Oh, and my reply thus also became just a reply to you personally.
So repeating it here, in case somebody has comments about t
On Thu, Feb 18, 2021 at 10:06 PM Dave Airlie wrote:
>
> Let me know if there are any issues,
gcc was happy, and I obviously already pushed out my merge, but then
when I did my clang build afterwards, it reports:
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:764:2: warning:
variable 'structu
On Thu, Jan 14, 2021 at 2:01 PM Steven Rostedt wrote:
>
> Thanks, I take it, it will be going into mainline soon.
Just got merged - it might be a good idea to verify that your problem is solved.
Linus
___
dri-devel mailing list
dri-devel@li
On Wed, Dec 23, 2020 at 6:29 PM Dave Airlie wrote:
>
> Xmas eve pull request present. Just some fixes that trickled in this
> past week. Mostly amdgpu fixes, with a dma-buf/mips build fix and some
> misc komeda fixes.
Well, I already pulled and pushed out my merge, but only noticed
afterwards tha
On Mon, Dec 14, 2020 at 2:29 PM Alex Deucher wrote:
>
> The relevant fixes are:
Ok, I can confirm that applying those two patches gets my workstation
working properly again.
Would it be possible to get those submitted properly (or I can just
take them as-is, but would like to get a "please just
On Thu, Dec 10, 2020 at 7:52 PM Dave Airlie wrote:
>
> This is an early pull request for drm for 5.11 merge window. I'm going
> to be out for most of the first week of the merge window so thought
> I'd just preempt things and send this early.
Ok, I've merged this, and Dave is likely gone already,
On Wed, Nov 18, 2020 at 4:12 AM David Laight wrote:
>
> I've got the 'splat' below during boot.
> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics.
> User space is Ubuntu 20.04.
>
> Additionally the X display has all the colours and alignment slightly
> messed up.
> 5.9.0 was ok.
>
On Sun, Nov 15, 2020 at 12:41 PM Dave Airlie wrote:
>
> As mentioned I did have a fixes pull from Ben from after I'd sent you
> out stuff, it contains the fix for the regression reported in the rc1
> thread along with two others.
Thanks, pulled,
Linus
___
On Tue, Nov 3, 2020 at 2:20 PM Kirill A. Shutemov wrote:
>
> On Thu, Oct 15, 2020 at 11:33:08AM +1000, Dave Airlie wrote:
> > drm/nouveau/kms: Search for encoders' connectors properly
>
> This commit (09838c4efe9a) broke boot for me. These two hunks in
> particular:
Christ. It's been two we
On Tue, Nov 3, 2020 at 2:33 AM Thomas Gleixner wrote:
>
> +static inline void *kmap(struct page *page)
> +{
> + void *addr;
> +
> + might_sleep();
> + if (!PageHighMem(page))
> + addr = page_address(page);
> + else
> + addr = kmap_high(page);
> +
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
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/
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
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
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.
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
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
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
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
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
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
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
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
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;
>
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
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
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
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
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
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
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
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
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-
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
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
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
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
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
On Fri, Mar 6, 2020 at 7:12 AM Daniel Vetter wrote:
>
> I'll stuff it into a pull and throw that your way, that's simplest.
Thanks.
> btw we did add dri-devel to lore a while back, so should be there:
Indeed. I tried (incompetently) to look up your message ID, but I
didn't put the dri-devel par
On Fri, Mar 6, 2020 at 4:38 AM Daniel Vetter wrote:
>
> Linus, since this missed the -fixes pull from Dave maybe double check I'm
> not grossly wrong here and apply directly?
Hmm. I don't have the original email, mind just sending it to me (with
the proper added sign-off chain)?
It does strike m
On Thu, Jan 30, 2020 at 8:13 AM Linus Torvalds
wrote:
>
> That doesn't seem right. If I do that, I lose the added GEM_BUG_ON()'s.
Just for your ref: see commit ecc4d2a52df6 ("drm/i915/userptr: fix
size calculation") for the source of those debug statements, and then
2
On Wed, Jan 29, 2020 at 9:58 PM Dave Airlie wrote:
>
> It has two known conflicts, one in i915_gem_gtt, where you should juat
> take what's in the pull (it looks messier than it is),
That doesn't seem right. If I do that, I lose the added GEM_BUG_ON()'s.
I think the proper merge resolution does
On Thu, Jan 23, 2020 at 11:47 AM christophe leroy
wrote:
>
> I'm going to leave it aside, at least for the time being, and do it as a
> second step later after evaluating the real performance impact. I'll
> respin tomorrow in that way.
Ok, good.
>From a "narrow the access window type" standpoint
On Thu, Jan 23, 2020 at 4:59 AM Christophe Leroy
wrote:
>
> On 32 bits powerPC (book3s/32), only write accesses to user are
> protected and there is no point spending time on unlocking for reads.
Honestly, I'm starting to think that 32-bit ppc just needs to look
more like everybody else, than mak
Dave, Alex,
there's an odd bugreport on bugzilla, where Artem is seeing an odd
early-boot failure.
That one almost certainly has nothing to do with you guys, but see the
later odd (and apparently unrelated) report about some AMD graphics
firmware issue and a black screen.
Li
On Wed, Dec 18, 2019 at 10:37 AM Jason Gunthorpe wrote:
>
> I think this is what you are looking for?
I think that with these names, I would have had an easier time reading
the original patch that made me go "Eww", yes.
Of course, now that it's just a rename patch, it's not like the patch
is all
On Wed, Dec 18, 2019 at 6:59 AM Jason Gunthorpe wrote:
>
> Do you think calling it 'mmn_subscriptions' is clear?
Why do you want that "mmn"?
Guys, the "mmn" part is clear from the _context_. The function name is
When the function name is something like "mmu_interval_read_begin()",
and the filen
On Mon, Nov 25, 2019 at 12:42 PM Jason Gunthorpe wrote:
>
> Here is this batch of hmm updates, I think we are nearing the end of this
> project for now, although I suspect there will be some more patches related to
> hmm_range_fault() in the next cycle.
I've ended up pulling this, but I'm not ent
On Sat, Nov 30, 2019 at 10:03 AM Linus Torvalds
wrote:
>
> I'll try to figure the code out, but my initial reaction was "yeah,
> not in my VM".
Why is it ok to sometimes do
WRITE_ONCE(mni->invalidate_seq, cur_seq);
(to pair with the unlocked READ_ONCE), and
On Mon, Nov 25, 2019 at 12:42 PM Jason Gunthorpe wrote:
>
> You will probably be most interested in the patch "mm/mmu_notifier: add an
> interval tree notifier".
I'm trying to read that patch, and I'm completely unable to by the
absolutely *horrid* variable names.
There are zero excuses for name
On Thu, Nov 28, 2019 at 5:15 PM Dave Airlie wrote:
>
> This is just a separated pull for the mm pagewalking + drm/vmwgfx work
> Thomas did and you were involved in, I've left it separate in case you
> don't feel as comfortable with it as the other stuff.
Thanks, pulled (and the delay wasn't becau
On Wed, Nov 27, 2019 at 4:59 PM Dave Airlie wrote:
>
> my sample merge is here:
> https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next-5.5-merged
Hmm. I think you missed a couple: you left a duplicate
intel_update_rawclk() around (it got moved into
intel_power_domains_init_hw() by commit 2
On Sun, Oct 6, 2019 at 9:55 AM Theodore Y. Ts'o wrote:
>
> Well, one thing we *can* do is if (a) if we can create a kselftest
> branch which we know is stable and won't change, and (b) we can get
> assurances that Linus *will* accept that branch during the next merge
> window, those subsystems whi
On Fri, Oct 4, 2019 at 2:39 PM Theodore Y. Ts'o wrote:
>
> This question is primarily directed at Shuah and Linus
>
> What's the current status of the kunit series now that Brendan has
> moved it out of the top-level kunit directory as Linus has requested?
We seemed to decide to just wait for
On Mon, Sep 30, 2019 at 6:04 AM Kirill A. Shutemov wrote:
>
> Have you seen page_vma_mapped_walk()? I made it specifically for rmap code
> to cover cases when a THP is mapped with PTEs. To me it's not a big
> stretch to make it cover multiple pages too.
I agree that is closer, but it does make fo
On Fri, Sep 27, 2019 at 5:17 AM Kirill A. Shutemov wrote:
>
> > Call it "walk_page_mapping()". And talk extensively about how the
> > locking differs a lot from the usual "walk_page_vma()" things.
>
> Walking mappings of a page is what rmap does. This code thas to be
> integrated there.
Well, tha
On Thu, Sep 26, 2019 at 1:55 PM Thomas Hellström (VMware)
wrote:
>
> Well, we're working on supporting huge puds and pmds in the graphics
> VMAs, although in the write-notify cases we're looking at here, we would
> probably want to split them down to PTE level.
Well, that's what the existing walk
On Thu, Sep 26, 2019 at 1:09 PM Thomas Hellström (VMware)
wrote:
>
> That said, if people are OK with me modifying the assert in
> pud_trans_huge_lock() and make __walk_page_range non-static, it should
> probably be possible to make it work, yes.
I don't think you need to modify that assert at al
On Thu, Sep 26, 2019 at 5:03 AM Thomas Hellström (VMware)
wrote:
>
> I wonder if I can get an ack from an mm maintainer to merge this through
> DRM along with the vmwgfx patches? Andrew? Matthew?
It would have helped to actually point to the patch itself, instead of
just quoting the commit messag
On Thu, Sep 19, 2019 at 12:09 PM Dave Airlie wrote:
>
> There are a few merge conflicts across the board, we have a shared
> rerere cache which meant I hadn't noticed them until I avoided the
> cache.
> https://cgit.freedesktop.org/drm/drm/log/?h=drm-5.4-merge
> contains what we've done, none of t
On Sun, Sep 15, 2019 at 8:12 AM Dave Airlie wrote:
>
> I've been manually writing the subject lines, seems I need to fix my brain.
Note that my "find git pull requests" logic doesn't need it in the
subject line at all, so if you just change whatever script you use to
generate the email body to ha
On Thu, Sep 12, 2019 at 8:56 AM Dave Airlie wrote:
>
> Hey Linus,
>
> From the maintainer summit, just some last minute fixes for final,
> details in the tag.
So because my mailbox was more unruly than normal (because of same
maintainer summit travel), I almost missed this email entirely.
Why? B
On Tue, Aug 6, 2019 at 11:40 PM Christoph Hellwig wrote:
>
> I'm not an all that huge fan of super magic macro loops. But in this
> case I don't see how it could even work, as we get special callbacks
> for huge pages and holes, and people are trying to add a few more ops
> as well.
Yeah, in thi
On Tue, Aug 6, 2019 at 12:38 AM Christoph Hellwig wrote:
>
> Seems like no one took this up. Below is a version which I think is
> slightly better by also moving the mm_walk structure initialization
> into the helpers, with an outcome of just a handful of added lines.
Ack. Agreed, I think that's
On Sun, Jul 21, 2019 at 1:20 PM Daniel Vetter wrote:
>
> It's dead code ever since
Lovely. Ack.
Linus
On Fri, Jul 19, 2019 at 8:43 AM Daniel Vetter wrote:
>
> drm fixes for -rc1:
>
> nouveau:
> - bugfixes + TU116 enabling (minor iteration):w
Asking the important question:
- WTH is that ":w" thing?
I have a theory that it's just a "I'm confused by 'vi'" marker. Very
understandable.
But I'm al
On Mon, Jul 15, 2019 at 11:38 AM Dave Airlie wrote:
>
> The reason I was waiting for the HMM tree to land, is a single silent
> merge conflict needs to be resolved after merging this as below.
There's more than that there.
For example, the DRM_AMDGPU_USERPTR config has a
depends on ARCH
On Mon, Jul 15, 2019 at 1:07 PM Linus Torvalds
wrote:
>
> The mm_walk struct is indeed a bit similar, and is in fact a bit
> problematic exactly because it mixes function pointers with non-const
> data.
This made me look at how nasty that would be to fix.
Not too bad.
The attache
On Mon, Jul 15, 2019 at 12:36 PM Thomas Hellström (VMware)
wrote:
>
> - I've never had any kernel code more reviewed than this.
Hmm. It may have been reviewed, but that wasn't visible in the commits
themselves, so when I look at the pull request, I don't see that.
> - The combined callback / arg
On Mon, Jul 15, 2019 at 12:17 PM Jason Gunthorpe wrote:
>
> About the only thing I could concretely suggest for working with -mm
> is if there was some way the -mm quilt patches could participate in
> 'git merge' resolution at your level.
Andrew did make noises about having multiple git branches.
On Mon, Jul 15, 2019 at 11:16 AM Linus Torvalds
wrote:
>
> On Mon, Jul 15, 2019 at 5:29 AM Jason Gunthorpe wrote:
> >
> > The 'hmm' tree is something I ran to try and help workflow issues like
> > this, as it could be merged to DRM as a topic branch - mayb
On Mon, Jul 15, 2019 at 11:29 AM Dave Airlie wrote:
>
> Not that I want to defend that code, but the mm patch that conflicts
> already shows that removing the token is fine as nobody needs or
> requires it. So the fixup patch in my tree was just a bridge to that patch,
> which reduces conflicts. R
[ Ugh, I have three different threads about the drm pull because of
the subject / html confusion. So now I'm replying in separate threads
and I'm hoping the people involved have better threading than gmail
does ;/ ]
On Mon, Jul 15, 2019 at 5:29 AM Jason Gunthorpe wrote:
>
> The 'hmm' tree is some
On Mon, Jul 15, 2019 at 10:37 AM Linus Torvalds
wrote:
>
> I'm not pulling this. Why did you merge it into your tree, when
> apparently you were aware of how questionable it is judging by the drm
> pull request.
Looking at some of the fallout, I also see that you then a
On Mon, Jul 15, 2019 at 12:08 AM Dave Airlie wrote:
>
> VMware had some mm helpers go in via my tree (looking back I'm not
> sure Thomas really secured enough acks on these, but I'm going with it
> for now until I get push back).
Yeah, this is the kind of completely unacceptable stuff that I was
On Tue, Jul 9, 2019 at 12:24 PM Jason Gunthorpe wrote:
>
> I'm sending it early as it is now a dependency for several patches in
> mm's quilt.
.. but I waited to merge it until I had time to review it more
closely, because I expected the review to be painful.
I'm happy to say that I was overly p
On Fri, Jun 21, 2019 at 10:06 AM Daniel Stone wrote:
>
> > Does it work for you? I'm getting a connection reset, no data.
>
> It is quite sick indeed; it's fallen down an NFS hole and is being
> restarted. Should be back in a few minutes.
Thanks, everything does indeed look good again now,
On Thu, Jun 20, 2019 at 9:21 PM Dave Airlie wrote:
>
> Just catching up on the week since back from holidays, everything
> seems quite sane.
.. well, except for anongit.freedesktop.org itself, which seems very
sick indeed.
Does it work for you? I'm getting a connection reset, no data.
On Fri, Jun 7, 2019 at 10:20 AM Linus Torvalds
wrote:
>
> The second one has the subject, and mentions nouveau, but doesn't
> actually have the tag name or the expected diffstat and shortlog.
Hmm. I'm guessing you meant for me to pull the
'tags/drm-fixes-2019-06-0
On Fri, Jun 7, 2019 at 12:24 AM Dave Airlie wrote:
>
> I sent this out earlier, but I forgot the subject, and then Ben asked
> about some nouveau firmware fixes.
Well, the first one at least had the address to pull from, and the diffstat.
The second one has the subject, and mentions nouveau, but
On Thu, May 23, 2019 at 10:36 AM Steven Rostedt wrote:
>
> >
> > Of course, you probably want the usual "at least use 'int'" semantics,
> > in which case the "type" should be "(x)+0":
> >
> > #define round_up(x, y) size_fn((x)+0, round_up_size, x, y)
> >
> > and the 8-bit and 16-bit cases wi
On Thu, May 23, 2019 at 8:27 AM Steven Rostedt wrote:
>
> I haven't yet tested this, but what about something like the following:
So that at least handles the constant case that the normal "roundup()"
case also handles.
At the same time, in the case you are talking about, I really do
suspect tha
On Thu, May 23, 2019 at 7:00 AM Steven Rostedt wrote:
>
> +# define roundup_64(x, y) (\
> +{ \
> + typeof(y) __y = y; \
> + typeof(x) __x = (x) + (__y - 1);\
>
Dave,
On Wed, May 8, 2019 at 8:28 PM Dave Airlie wrote:
>
> This is the main drm pull request for 5.2.
Thanks. I've merged it, but I got a couple of conflicts with fixes
(reverts) to mainline in the meantime.
The one to the i915 driver you seem to have applied again (after the
function was move
On Fri, Jan 18, 2019 at 12:43 PM Dave Airlie wrote:
>
> Going to be at LCA next week in Christchurch, but should be fine for
> normal pulls.
.. hey, me too.
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-01-18
Pulled,
Linus
_
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
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,
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
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
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
On Wed, Aug 22, 2018 at 11:16 PM Zhenyu Wang wrote:
>
> yeah, that's the clear way to fix this imo. We only depend on guest
> life cycle to access guest memory properly. Here's proposed fix, will
> verify and integrate it later.
Thanks, this looks sane to me,
Linus
__
On Wed, Aug 22, 2018 at 12:44 PM Felix Kuehling wrote:
>
> You're right, but that's a bit fragile and convoluted. I'll fix KFD to
> handle this more robustly. See the attached (untested) patch.
Yes, this patch that makes the whole "has to use current mm" or uses
"get_task_mm()" looks good from a
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
201 - 300 of 743 matches
Mail list logo
