All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: "DRI Development" <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"Jan Kara" <jack@suse.cz>, "Kees Cook" <keescook@chromium.org>,
	"KVM list" <kvm@vger.kernel.org>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Linux PCI" <linux-pci@vger.kernel.org>,
	"Linux MM" <linux-mm@kvack.org>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>
Subject: Re: [PATCH v2 17/17] drm/i915: Properly request PCI BARs
Date: Fri, 9 Oct 2020 16:18:53 +0200	[thread overview]
Message-ID: <CAKMK7uEp71+B3EVTezog8U3VY=DUYAbe1QeqZH9NEG8T37M_Cw@mail.gmail.com> (raw)
In-Reply-To: <20201009104154.GR6112@intel.com>

On Fri, Oct 9, 2020 at 12:42 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Fri, Oct 09, 2020 at 12:01:39PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> > > > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> > > > do nothing for i915. Because i915 doesn't request any regions, like
> > > > pretty much all drm pci drivers. I guess this is some very old
> > > > remnants from the userspace modesetting days, when we wanted to
> > > > co-exist with the fbdev driver. Which usually requested these
> > > > resources.
> > > >
> > > > But makes me wonder why the pci subsystem doesn't just request
> > > > resource automatically when we map a bar and a pci driver is bound?
> > > >
> > > > Knowledge about which pci bars we need kludged together from
> > > > intel_uncore.c and intel_gtt.c from i915 and intel-gtt.c over in the
> > > > fake agp driver.
> > > >
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > Cc: Jason Gunthorpe <jgg@ziepe.ca>
> > > > Cc: Kees Cook <keescook@chromium.org>
> > > > Cc: Dan Williams <dan.j.williams@intel.com>
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > Cc: John Hubbard <jhubbard@nvidia.com>
> > > > Cc: Jérôme Glisse <jglisse@redhat.com>
> > > > Cc: Jan Kara <jack@suse.cz>
> > > > Cc: Dan Williams <dan.j.williams@intel.com>
> > > > Cc: linux-mm@kvack.org
> > > > Cc: linux-arm-kernel@lists.infradead.org
> > > > Cc: linux-samsung-soc@vger.kernel.org
> > > > Cc: linux-media@vger.kernel.org
> > > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > > Cc: linux-pci@vger.kernel.org
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_uncore.c | 25 +++++++++++++++++++++++--
> > > >  1 file changed, 23 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> > > > index 54e201fdeba4..ce39049d8919 100644
> > > > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > > > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > > > @@ -1692,10 +1692,13 @@ static int uncore_mmio_setup(struct intel_uncore *uncore)
> > > >       struct pci_dev *pdev = i915->drm.pdev;
> > > >       int mmio_bar;
> > > >       int mmio_size;
> > > > +     int bar_selection;
> > >
> > > Signed bitmasks always make me uneasy. But looks like
> > > that's what it is in the pci api. So meh.
> >
> > Yeah it's surprising.
> >
> > > > +     int ret;
> > > >
> > > >       mmio_bar = IS_GEN(i915, 2) ? 1 : 0;
> > > > +     bar_selection = BIT (2) | BIT(mmio_bar);
> > >                            ^
> > > spurious space
> > >
> > > That's also not correct for gen2 I think.
> > >
> > > gen2:
> > > 0 = GMADR
> > > 1 = MMADR
> > > 2 = IOBAR
> > >
> > > gen3:
> > > 0 = MMADR
> > > 1 = IOBAR
> > > 2 = GMADR
> > > 3 = GTTADR
> > >
> > > gen4+:
> > > 0+1 = GTTMMADR
> > > 2+3 = GMADR
> > > 4 = IOBAR
> > >
> > > Maybe we should just have an explicit list of bars like that in a
> > > comment?
> > >
> > > I'd also suggest sucking this bitmask calculation into a small helper
> > > so you can reuse it for the release.
> >
> > tbh I just hacked this up for testing. Given how almost no other drm
> > driver does this, I'm wondering whether we should or not.
> >
> > Also the only reason why I didn't just use the pci_request_regions
> > helper is to avoid the vga ioport range, since that's managed by
> > vgaarbiter.
>
> VGA io range isn't part of any bar. Or do you mean just the io decode
> enable bit in the pci command register? That should be just a matter
> or pci_enable_device() vs. pci_enable_device_mem() I think. So nothing
> to do with which bars we've requested IIRC.
>
> >
> > So I think if we go for this for real we should:
> > - register the vga ioport range in the vgaarbiter
> > - have a pci_request_iomem_regions helper that grabs all mem bars
> > - roll that out to all drm pci drivers
> >
> > Or something like that. The other complication is when we resize the
> > iobar. So not really sure what to do here.
>
> We resize it?

By default I thought firmware puts everything (well, squeezes) into
the lower 32bit. Maybe they stopped doing that. So when we want the
full bar (for discrete at least) we need to resize it and put it
somewhere in the 64bit range above end of system memory.

So I guess correct phrasing is "we will resize it" :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: linux-s390 <linux-s390@vger.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"Jan Kara" <jack@suse.cz>, "Kees Cook" <keescook@chromium.org>,
	"KVM list" <kvm@vger.kernel.org>, "Linux MM" <linux-mm@kvack.org>,
	"Linux PCI" <linux-pci@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>
Subject: Re: [PATCH v2 17/17] drm/i915: Properly request PCI BARs
Date: Fri, 9 Oct 2020 16:18:53 +0200	[thread overview]
Message-ID: <CAKMK7uEp71+B3EVTezog8U3VY=DUYAbe1QeqZH9NEG8T37M_Cw@mail.gmail.com> (raw)
In-Reply-To: <20201009104154.GR6112@intel.com>

On Fri, Oct 9, 2020 at 12:42 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Fri, Oct 09, 2020 at 12:01:39PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> > > > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> > > > do nothing for i915. Because i915 doesn't request any regions, like
> > > > pretty much all drm pci drivers. I guess this is some very old
> > > > remnants from the userspace modesetting days, when we wanted to
> > > > co-exist with the fbdev driver. Which usually requested these
> > > > resources.
> > > >
> > > > But makes me wonder why the pci subsystem doesn't just request
> > > > resource automatically when we map a bar and a pci driver is bound?
> > > >
> > > > Knowledge about which pci bars we need kludged together from
> > > > intel_uncore.c and intel_gtt.c from i915 and intel-gtt.c over in the
> > > > fake agp driver.
> > > >
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > Cc: Jason Gunthorpe <jgg@ziepe.ca>
> > > > Cc: Kees Cook <keescook@chromium.org>
> > > > Cc: Dan Williams <dan.j.williams@intel.com>
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > Cc: John Hubbard <jhubbard@nvidia.com>
> > > > Cc: Jérôme Glisse <jglisse@redhat.com>
> > > > Cc: Jan Kara <jack@suse.cz>
> > > > Cc: Dan Williams <dan.j.williams@intel.com>
> > > > Cc: linux-mm@kvack.org
> > > > Cc: linux-arm-kernel@lists.infradead.org
> > > > Cc: linux-samsung-soc@vger.kernel.org
> > > > Cc: linux-media@vger.kernel.org
> > > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > > Cc: linux-pci@vger.kernel.org
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_uncore.c | 25 +++++++++++++++++++++++--
> > > >  1 file changed, 23 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> > > > index 54e201fdeba4..ce39049d8919 100644
> > > > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > > > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > > > @@ -1692,10 +1692,13 @@ static int uncore_mmio_setup(struct intel_uncore *uncore)
> > > >       struct pci_dev *pdev = i915->drm.pdev;
> > > >       int mmio_bar;
> > > >       int mmio_size;
> > > > +     int bar_selection;
> > >
> > > Signed bitmasks always make me uneasy. But looks like
> > > that's what it is in the pci api. So meh.
> >
> > Yeah it's surprising.
> >
> > > > +     int ret;
> > > >
> > > >       mmio_bar = IS_GEN(i915, 2) ? 1 : 0;
> > > > +     bar_selection = BIT (2) | BIT(mmio_bar);
> > >                            ^
> > > spurious space
> > >
> > > That's also not correct for gen2 I think.
> > >
> > > gen2:
> > > 0 = GMADR
> > > 1 = MMADR
> > > 2 = IOBAR
> > >
> > > gen3:
> > > 0 = MMADR
> > > 1 = IOBAR
> > > 2 = GMADR
> > > 3 = GTTADR
> > >
> > > gen4+:
> > > 0+1 = GTTMMADR
> > > 2+3 = GMADR
> > > 4 = IOBAR
> > >
> > > Maybe we should just have an explicit list of bars like that in a
> > > comment?
> > >
> > > I'd also suggest sucking this bitmask calculation into a small helper
> > > so you can reuse it for the release.
> >
> > tbh I just hacked this up for testing. Given how almost no other drm
> > driver does this, I'm wondering whether we should or not.
> >
> > Also the only reason why I didn't just use the pci_request_regions
> > helper is to avoid the vga ioport range, since that's managed by
> > vgaarbiter.
>
> VGA io range isn't part of any bar. Or do you mean just the io decode
> enable bit in the pci command register? That should be just a matter
> or pci_enable_device() vs. pci_enable_device_mem() I think. So nothing
> to do with which bars we've requested IIRC.
>
> >
> > So I think if we go for this for real we should:
> > - register the vga ioport range in the vgaarbiter
> > - have a pci_request_iomem_regions helper that grabs all mem bars
> > - roll that out to all drm pci drivers
> >
> > Or something like that. The other complication is when we resize the
> > iobar. So not really sure what to do here.
>
> We resize it?

By default I thought firmware puts everything (well, squeezes) into
the lower 32bit. Maybe they stopped doing that. So when we want the
full bar (for discrete at least) we need to resize it and put it
somewhere in the 64bit range above end of system memory.

So I guess correct phrasing is "we will resize it" :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: linux-s390 <linux-s390@vger.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"Jan Kara" <jack@suse.cz>, "Kees Cook" <keescook@chromium.org>,
	"KVM list" <kvm@vger.kernel.org>, "Linux MM" <linux-mm@kvack.org>,
	"Linux PCI" <linux-pci@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>
Subject: Re: [PATCH v2 17/17] drm/i915: Properly request PCI BARs
Date: Fri, 9 Oct 2020 16:18:53 +0200	[thread overview]
Message-ID: <CAKMK7uEp71+B3EVTezog8U3VY=DUYAbe1QeqZH9NEG8T37M_Cw@mail.gmail.com> (raw)
In-Reply-To: <20201009104154.GR6112@intel.com>

On Fri, Oct 9, 2020 at 12:42 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Fri, Oct 09, 2020 at 12:01:39PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> > > > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> > > > do nothing for i915. Because i915 doesn't request any regions, like
> > > > pretty much all drm pci drivers. I guess this is some very old
> > > > remnants from the userspace modesetting days, when we wanted to
> > > > co-exist with the fbdev driver. Which usually requested these
> > > > resources.
> > > >
> > > > But makes me wonder why the pci subsystem doesn't just request
> > > > resource automatically when we map a bar and a pci driver is bound?
> > > >
> > > > Knowledge about which pci bars we need kludged together from
> > > > intel_uncore.c and intel_gtt.c from i915 and intel-gtt.c over in the
> > > > fake agp driver.
> > > >
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > Cc: Jason Gunthorpe <jgg@ziepe.ca>
> > > > Cc: Kees Cook <keescook@chromium.org>
> > > > Cc: Dan Williams <dan.j.williams@intel.com>
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > Cc: John Hubbard <jhubbard@nvidia.com>
> > > > Cc: Jérôme Glisse <jglisse@redhat.com>
> > > > Cc: Jan Kara <jack@suse.cz>
> > > > Cc: Dan Williams <dan.j.williams@intel.com>
> > > > Cc: linux-mm@kvack.org
> > > > Cc: linux-arm-kernel@lists.infradead.org
> > > > Cc: linux-samsung-soc@vger.kernel.org
> > > > Cc: linux-media@vger.kernel.org
> > > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > > Cc: linux-pci@vger.kernel.org
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_uncore.c | 25 +++++++++++++++++++++++--
> > > >  1 file changed, 23 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> > > > index 54e201fdeba4..ce39049d8919 100644
> > > > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > > > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > > > @@ -1692,10 +1692,13 @@ static int uncore_mmio_setup(struct intel_uncore *uncore)
> > > >       struct pci_dev *pdev = i915->drm.pdev;
> > > >       int mmio_bar;
> > > >       int mmio_size;
> > > > +     int bar_selection;
> > >
> > > Signed bitmasks always make me uneasy. But looks like
> > > that's what it is in the pci api. So meh.
> >
> > Yeah it's surprising.
> >
> > > > +     int ret;
> > > >
> > > >       mmio_bar = IS_GEN(i915, 2) ? 1 : 0;
> > > > +     bar_selection = BIT (2) | BIT(mmio_bar);
> > >                            ^
> > > spurious space
> > >
> > > That's also not correct for gen2 I think.
> > >
> > > gen2:
> > > 0 = GMADR
> > > 1 = MMADR
> > > 2 = IOBAR
> > >
> > > gen3:
> > > 0 = MMADR
> > > 1 = IOBAR
> > > 2 = GMADR
> > > 3 = GTTADR
> > >
> > > gen4+:
> > > 0+1 = GTTMMADR
> > > 2+3 = GMADR
> > > 4 = IOBAR
> > >
> > > Maybe we should just have an explicit list of bars like that in a
> > > comment?
> > >
> > > I'd also suggest sucking this bitmask calculation into a small helper
> > > so you can reuse it for the release.
> >
> > tbh I just hacked this up for testing. Given how almost no other drm
> > driver does this, I'm wondering whether we should or not.
> >
> > Also the only reason why I didn't just use the pci_request_regions
> > helper is to avoid the vga ioport range, since that's managed by
> > vgaarbiter.
>
> VGA io range isn't part of any bar. Or do you mean just the io decode
> enable bit in the pci command register? That should be just a matter
> or pci_enable_device() vs. pci_enable_device_mem() I think. So nothing
> to do with which bars we've requested IIRC.
>
> >
> > So I think if we go for this for real we should:
> > - register the vga ioport range in the vgaarbiter
> > - have a pci_request_iomem_regions helper that grabs all mem bars
> > - roll that out to all drm pci drivers
> >
> > Or something like that. The other complication is when we resize the
> > iobar. So not really sure what to do here.
>
> We resize it?

By default I thought firmware puts everything (well, squeezes) into
the lower 32bit. Maybe they stopped doing that. So when we want the
full bar (for discrete at least) we need to resize it and put it
somewhere in the 64bit range above end of system memory.

So I guess correct phrasing is "we will resize it" :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-10-09 14:19 UTC|newest]

Thread overview: 214+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-09  7:59 [PATCH v2 00/17] follow_pfn and other iomap races Daniel Vetter
2020-10-09  7:59 ` Daniel Vetter
2020-10-09  7:59 ` Daniel Vetter
2020-10-09  7:59 ` [PATCH v2 01/17] drm/exynos: Stop using frame_vector helpers Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-16  7:42   ` John Hubbard
2020-10-16  7:42     ` John Hubbard
2020-10-16  7:42     ` John Hubbard
2020-10-09  7:59 ` [PATCH v2 02/17] drm/exynos: Use FOLL_LONGTERM for g2d cmdlists Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59 ` [PATCH v2 03/17] misc/habana: Stop using frame_vector helpers Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-10 20:26   ` Oded Gabbay
2020-10-10 20:26     ` Oded Gabbay
2020-10-10 20:26     ` Oded Gabbay
2020-10-10 21:32     ` Daniel Vetter
2020-10-10 21:32       ` Daniel Vetter
2020-10-10 21:32       ` Daniel Vetter
2020-10-10 21:41       ` Daniel Vetter
2020-10-10 21:41         ` Daniel Vetter
2020-10-10 21:41         ` Daniel Vetter
2020-10-10 21:47         ` Oded Gabbay
2020-10-10 21:47           ` Oded Gabbay
2020-10-10 21:47           ` Oded Gabbay
2020-10-16  7:45   ` John Hubbard
2020-10-16  7:45     ` John Hubbard
2020-10-16  7:45     ` John Hubbard
2020-10-09  7:59 ` [PATCH v2 04/17] misc/habana: Use FOLL_LONGTERM for userptr Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59 ` [PATCH v2 05/17] mm/frame-vector: Use FOLL_LONGTERM Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-16  7:54   ` John Hubbard
2020-10-16  7:54     ` John Hubbard
2020-10-16  7:54     ` John Hubbard
2020-10-16  8:03     ` Daniel Vetter
2020-10-16  8:03       ` Daniel Vetter
2020-10-16  8:03       ` Daniel Vetter
2020-10-09  7:59 ` [PATCH v2 06/17] media: videobuf2: Move frame_vector into media subsystem Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09 10:14   ` Mauro Carvalho Chehab
2020-10-09 10:14     ` Mauro Carvalho Chehab
2020-10-09 10:14     ` Mauro Carvalho Chehab
2020-10-09 16:57     ` Daniel Vetter
2020-10-09 16:57       ` Daniel Vetter
2020-10-09 16:57       ` Daniel Vetter
2020-10-09 16:57       ` Daniel Vetter
2020-10-09  7:59 ` [PATCH v2 07/17] mm: Close race in generic_access_phys Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59 ` [PATCH v2 08/17] s390/pci: Remove races against pte updates Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-12 14:03   ` Niklas Schnelle
2020-10-12 14:03     ` Niklas Schnelle
2020-10-12 14:03     ` Niklas Schnelle
2020-10-12 14:19     ` Daniel Vetter
2020-10-12 14:19       ` Daniel Vetter
2020-10-12 14:19       ` Daniel Vetter
2020-10-12 14:19       ` Daniel Vetter
2020-10-12 14:39       ` Niklas Schnelle
2020-10-12 14:39         ` Niklas Schnelle
2020-10-12 14:39         ` Niklas Schnelle
2020-10-21  7:55       ` Niklas Schnelle
2020-10-21  7:55         ` Niklas Schnelle
2020-10-21  7:55         ` Niklas Schnelle
2020-10-22  7:39         ` Daniel Vetter
2020-10-22  7:39           ` Daniel Vetter
2020-10-22  7:39           ` Daniel Vetter
2020-10-22  7:39           ` Daniel Vetter
2020-10-09  7:59 ` [PATCH v2 09/17] mm: Add unsafe_follow_pfn Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09 10:34   ` Mauro Carvalho Chehab
2020-10-09 10:34     ` Mauro Carvalho Chehab
2020-10-09 10:34     ` Mauro Carvalho Chehab
2020-10-09 12:21     ` Jason Gunthorpe
2020-10-09 12:21       ` Jason Gunthorpe
2020-10-09 12:21       ` Jason Gunthorpe
2020-10-09 12:37       ` Mauro Carvalho Chehab
2020-10-09 12:37         ` Mauro Carvalho Chehab
2020-10-09 12:37         ` Mauro Carvalho Chehab
2020-10-09 12:39         ` Mauro Carvalho Chehab
2020-10-09 12:39           ` Mauro Carvalho Chehab
2020-10-09 12:39           ` Mauro Carvalho Chehab
2020-10-09 12:48         ` Jason Gunthorpe
2020-10-09 12:48           ` Jason Gunthorpe
2020-10-09 12:48           ` Jason Gunthorpe
2020-10-09 17:52           ` Daniel Vetter
2020-10-09 17:52             ` Daniel Vetter
2020-10-09 17:52             ` Daniel Vetter
2020-10-09 18:01             ` Jason Gunthorpe
2020-10-09 18:01               ` Jason Gunthorpe
2020-10-09 18:01               ` Jason Gunthorpe
2020-10-09 19:31               ` Daniel Vetter
2020-10-09 19:31                 ` Daniel Vetter
2020-10-09 19:31                 ` Daniel Vetter
2020-10-10  9:21             ` Mauro Carvalho Chehab
2020-10-10  9:21               ` Mauro Carvalho Chehab
2020-10-10  9:21               ` Mauro Carvalho Chehab
2020-10-10 10:53               ` Daniel Vetter
2020-10-10 10:53                 ` Daniel Vetter
2020-10-10 10:53                 ` Daniel Vetter
2020-10-10 11:39                 ` Mauro Carvalho Chehab
2020-10-10 11:39                   ` Mauro Carvalho Chehab
2020-10-10 11:39                   ` Mauro Carvalho Chehab
2020-10-10 11:56                   ` Daniel Vetter
2020-10-10 11:56                     ` Daniel Vetter
2020-10-10 11:56                     ` Daniel Vetter
2020-10-10 17:22             ` Tomasz Figa
2020-10-10 17:22               ` Tomasz Figa
2020-10-10 17:22               ` Tomasz Figa
2020-10-10 21:35               ` Laurent Pinchart
2020-10-10 21:35                 ` Laurent Pinchart
2020-10-10 21:35                 ` Laurent Pinchart
2020-10-10 21:50                 ` Daniel Vetter
2020-10-10 21:50                   ` Daniel Vetter
2020-10-10 21:50                   ` Daniel Vetter
2020-10-11  6:27                   ` Mauro Carvalho Chehab
2020-10-11  6:27                     ` Mauro Carvalho Chehab
2020-10-11  6:27                     ` Mauro Carvalho Chehab
2020-10-11  6:36                     ` Mauro Carvalho Chehab
2020-10-11  6:36                       ` Mauro Carvalho Chehab
2020-10-11  6:36                       ` Mauro Carvalho Chehab
2020-10-10 21:11             ` Laurent Pinchart
2020-10-10 21:11               ` Laurent Pinchart
2020-10-10 21:11               ` Laurent Pinchart
2020-10-12 10:46           ` Marek Szyprowski
2020-10-12 10:46             ` Marek Szyprowski
2020-10-12 10:46             ` Marek Szyprowski
2020-10-12 13:49             ` Daniel Vetter
2020-10-12 13:49               ` Daniel Vetter
2020-10-12 13:49               ` Daniel Vetter
2020-10-10 17:30         ` Tomasz Figa
2020-10-10 17:30           ` Tomasz Figa
2020-10-10 17:30           ` Tomasz Figa
2020-10-09  7:59 ` [PATCH v2 10/17] media/videbuf1|2: Mark follow_pfn usage as unsafe Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-10  9:24   ` Mauro Carvalho Chehab
2020-10-10  9:24     ` Mauro Carvalho Chehab
2020-10-10  9:24     ` Mauro Carvalho Chehab
2020-10-09  7:59 ` [PATCH v2 11/17] vfio/type1: Mark follow_pfn " Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59 ` [PATCH v2 12/17] PCI: Obey iomem restrictions for procfs mmap Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59 ` [PATCH v2 13/17] /dev/mem: Only set filp->f_mapping Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59 ` [PATCH v2 14/17] resource: Move devmem revoke code to resource framework Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09 10:59   ` Greg Kroah-Hartman
2020-10-09 10:59     ` Greg Kroah-Hartman
2020-10-09 10:59     ` Greg Kroah-Hartman
2020-10-09 10:59     ` Greg Kroah-Hartman
2020-10-09 12:31   ` Jason Gunthorpe
2020-10-09 12:31     ` Jason Gunthorpe
2020-10-09 12:31     ` Jason Gunthorpe
2020-10-09 14:24     ` Daniel Vetter
2020-10-09 14:24       ` Daniel Vetter
2020-10-09 14:24       ` Daniel Vetter
2020-10-09 14:32       ` Jason Gunthorpe
2020-10-09 14:32         ` Jason Gunthorpe
2020-10-09 14:32         ` Jason Gunthorpe
2020-10-09 18:28         ` Dan Williams
2020-10-09 18:28           ` Dan Williams
2020-10-09 18:28           ` Dan Williams
2020-10-15  0:09           ` Jason Gunthorpe
2020-10-15  0:09             ` Jason Gunthorpe
2020-10-15  0:09             ` Jason Gunthorpe
2020-10-15  7:52             ` Daniel Vetter
2020-10-15  7:52               ` Daniel Vetter
2020-10-15  7:52               ` Daniel Vetter
2020-10-15  7:55               ` Daniel Vetter
2020-10-15  7:55                 ` Daniel Vetter
2020-10-15  7:55                 ` Daniel Vetter
2020-10-15 15:29             ` Daniel Vetter
2020-10-15 15:29               ` Daniel Vetter
2020-10-15 15:29               ` Daniel Vetter
2020-10-09  7:59 ` [PATCH v2 15/17] sysfs: Support zapping of binary attr mmaps Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09 10:58   ` Greg Kroah-Hartman
2020-10-09 10:58     ` Greg Kroah-Hartman
2020-10-09 10:58     ` Greg Kroah-Hartman
2020-10-09 10:58     ` Greg Kroah-Hartman
2020-10-09  7:59 ` [PATCH v2 16/17] PCI: Revoke mappings like devmem Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59 ` [PATCH v2 17/17] drm/i915: Properly request PCI BARs Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  7:59   ` Daniel Vetter
2020-10-09  9:47   ` Ville Syrjälä
2020-10-09  9:47     ` Ville Syrjälä
2020-10-09  9:47     ` Ville Syrjälä
2020-10-09  9:47     ` Ville Syrjälä
2020-10-09 10:01     ` Daniel Vetter
2020-10-09 10:01       ` Daniel Vetter
2020-10-09 10:01       ` Daniel Vetter
2020-10-09 10:41       ` Ville Syrjälä
2020-10-09 10:41         ` Ville Syrjälä
2020-10-09 10:41         ` Ville Syrjälä
2020-10-09 10:41         ` Ville Syrjälä
2020-10-09 14:18         ` Daniel Vetter [this message]
2020-10-09 14:18           ` Daniel Vetter
2020-10-09 14:18           ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKMK7uEp71+B3EVTezog8U3VY=DUYAbe1QeqZH9NEG8T37M_Cw@mail.gmail.com' \
    --to=daniel.vetter@ffwll.ch \
    --cc=akpm@linux-foundation.org \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jack@suse.cz \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=keescook@chromium.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=ville.syrjala@linux.intel.com \
    --subject='Re: [PATCH v2 17/17] drm/i915: Properly request PCI BARs' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.