Re: remove alloc_vm_area v2
On Wed, Sep 30, 2020 at 4:48 PM Christoph Hellwig wrote: > > On Tue, Sep 29, 2020 at 03:43:30PM +0300, Joonas Lahtinen wrote: > > Hmm, those are both committed after our last -next pull request, so they > > would normally only target next merge window. drm-next closes the merge > > window around -rc5 already. > > > > But, in this specific case those are both Fixes: patches with Cc: stable, > > so they should be pulled into drm-intel-next-fixes PR. > > > > Rodrigo, can you cherry-pick those patches to -next-fixes that you send > > to Dave? > > They still haven't made it to linux-next. I think for now I'll just > rebase without them again and then you can handle the conflicts for > 5.11. Yeah after -rc6 drm is frozen for features, so anything that's stuck in subordinate trees rolls over to the next merge cycle. To avoid upsetting sfr from linux-next we keep those -next branches out of linux-next until after -rc1 again. iow, rebasing onto linux-next and smashing this into 5.10 sounds like the right approach (since everyone else freezes a bunch later afaik). Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: remove alloc_vm_area v2
On Tue, Sep 29, 2020 at 03:43:30PM +0300, Joonas Lahtinen wrote: > Hmm, those are both committed after our last -next pull request, so they > would normally only target next merge window. drm-next closes the merge > window around -rc5 already. > > But, in this specific case those are both Fixes: patches with Cc: stable, > so they should be pulled into drm-intel-next-fixes PR. > > Rodrigo, can you cherry-pick those patches to -next-fixes that you send > to Dave? They still haven't made it to linux-next. I think for now I'll just rebase without them again and then you can handle the conflicts for 5.11.
Re: remove alloc_vm_area v2
Quoting Christoph Hellwig (2020-09-28 15:37:41) > On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote: > > I think we have a gap that after splitting the drm-intel-next pull requests > > into > > two the drm-intel/for-linux-next branch is now missing material from > > drm-intel/drm-intel-gt-next. > > > > I think a simple course of action might be to start including > > drm-intel-gt-next > > in linux-next, which would mean that we should update DIM tooling to add > > extra branch "drm-intel/gt-for-linux-next" or so. > > > > Which specific patches are missing in this case? > > The two dependencies required by my series not in mainline are: > > drm/i915/gem: Avoid implicit vmap for highmem on x86-32 > drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported > > so it has to be one or both of those. Hmm, those are both committed after our last -next pull request, so they would normally only target next merge window. drm-next closes the merge window around -rc5 already. But, in this specific case those are both Fixes: patches with Cc: stable, so they should be pulled into drm-intel-next-fixes PR. Rodrigo, can you cherry-pick those patches to -next-fixes that you send to Dave? Regards, Joonas
Re: remove alloc_vm_area v2
On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote: > I think we have a gap that after splitting the drm-intel-next pull requests > into > two the drm-intel/for-linux-next branch is now missing material from > drm-intel/drm-intel-gt-next. > > I think a simple course of action might be to start including > drm-intel-gt-next > in linux-next, which would mean that we should update DIM tooling to add > extra branch "drm-intel/gt-for-linux-next" or so. > > Which specific patches are missing in this case? The two dependencies required by my series not in mainline are: drm/i915/gem: Avoid implicit vmap for highmem on x86-32 drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported so it has to be one or both of those.
Re: remove alloc_vm_area v2
+ Dave and Daniel + Stephen Quoting Christoph Hellwig (2020-09-26 09:29:59) > On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote: > > On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote: > > > > > this series removes alloc_vm_area, which was left over from the big > > > vmalloc interface rework. It is a rather arkane interface, basicaly > > > the equivalent of get_vm_area + actually faulting in all PTEs in > > > the allocated area. It was originally addeds for Xen (which isn't > > > modular to start with), and then grew users in zsmalloc and i915 > > > which seems to mostly qualify as abuses of the interface, especially > > > for i915 as a random driver should not set up PTE bits directly. > > > > > > Note that the i915 patches apply to the drm-tip branch of the drm-tip > > > tree, as that tree has recent conflicting commits in the same area. > > > > Is the drm-tip material in linux-next yet? I'm still seeing a non-trivial > > reject in there at present. > > I assumed it was, but the reject imply that they aren't. Tvrtko, do you > know the details? I think we have a gap that after splitting the drm-intel-next pull requests into two the drm-intel/for-linux-next branch is now missing material from drm-intel/drm-intel-gt-next. I think a simple course of action might be to start including drm-intel-gt-next in linux-next, which would mean that we should update DIM tooling to add extra branch "drm-intel/gt-for-linux-next" or so. Which specific patches are missing in this case? Regards, Joonas
Re: remove alloc_vm_area v2
On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote: > On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote: > > > this series removes alloc_vm_area, which was left over from the big > > vmalloc interface rework. It is a rather arkane interface, basicaly > > the equivalent of get_vm_area + actually faulting in all PTEs in > > the allocated area. It was originally addeds for Xen (which isn't > > modular to start with), and then grew users in zsmalloc and i915 > > which seems to mostly qualify as abuses of the interface, especially > > for i915 as a random driver should not set up PTE bits directly. > > > > Note that the i915 patches apply to the drm-tip branch of the drm-tip > > tree, as that tree has recent conflicting commits in the same area. > > Is the drm-tip material in linux-next yet? I'm still seeing a non-trivial > reject in there at present. I assumed it was, but the reject imply that they aren't. Tvrtko, do you know the details?
Re: remove alloc_vm_area v2
On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote: > this series removes alloc_vm_area, which was left over from the big > vmalloc interface rework. It is a rather arkane interface, basicaly > the equivalent of get_vm_area + actually faulting in all PTEs in > the allocated area. It was originally addeds for Xen (which isn't > modular to start with), and then grew users in zsmalloc and i915 > which seems to mostly qualify as abuses of the interface, especially > for i915 as a random driver should not set up PTE bits directly. > > Note that the i915 patches apply to the drm-tip branch of the drm-tip > tree, as that tree has recent conflicting commits in the same area. Is the drm-tip material in linux-next yet? I'm still seeing a non-trivial reject in there at present.
