On Thu 21-11-19 00:29:59, John Hubbard wrote:
> On 11/21/19 12:03 AM, Christoph Hellwig wrote:
> > Otherwise this looks fine and might be a worthwhile cleanup to feed
> > Andrew for 5.5 independent of the gut of the changes.
> >
> > Reviewed-by: Christoph Hellwig
> >
>
> Thanks for the
On Wed 20-11-19 23:13:47, John Hubbard wrote:
> Add tracking of pages that were pinned via FOLL_PIN.
>
> As mentioned in the FOLL_PIN documentation, callers who effectively set
> FOLL_PIN are required to ultimately free such pages via put_user_page().
> The effect is similar to FOLL_GET, and may
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA mapping code is already aware of this and treats dev->bus_dma_mask
as a limit. This quirk is already used by some architectures although
still rare.
On Thu, 2019-11-21 at 08:31 +0100, Christoph Hellwig wrote:
> On Tue, Nov 19, 2019 at 05:17:03PM +, Robin Murphy wrote:
> > TBH I can't see it being a massive problem even if the DMA patch, driver
> > and DTS patch went entirely separately via the respective DMA, PCI, and
> > arm-soc trees
On 11/21/19 12:05 AM, Christoph Hellwig wrote:
So while this looks correct and I still really don't see the major
benefit of the new code organization, especially as it bloats all
put_page callers.
I'd love to see code size change stats for an allyesconfig on this
commit.
Right, I'm running
On 11/21/19 12:10 AM, Christoph Hellwig wrote:
Should this be two patches, one for th core infrastructure and one for
the user? These changes also look like another candidate to pre-load.
OK, I'll split them up.
thanks,
--
John Hubbard
NVIDIA
On 11/21/19 12:08 AM, Christoph Hellwig wrote:
On Wed, Nov 20, 2019 at 11:13:36PM -0800, John Hubbard wrote:
+static int pin_goldfish_pages(unsigned long first_page,
+ unsigned long last_page,
+ unsigned int last_page_size,
+
On 11/21/19 12:03 AM, Christoph Hellwig wrote:
On Wed, Nov 20, 2019 at 11:13:32PM -0800, John Hubbard wrote:
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the
On 11/21/19 12:06 AM, Christoph Hellwig wrote:
On Wed, Nov 20, 2019 at 11:13:31PM -0800, John Hubbard wrote:
A subsequent patch requires access to gup flags, so
pass the flags argument through to the __gup_device_*
functions.
Looks fine, but why not fold this into the patch using the flags.
Should this be two patches, one for th core infrastructure and one for
the user? These changes also look like another candidate to pre-load.
On Wed, Nov 20, 2019 at 11:13:38PM -0800, John Hubbard wrote:
> After DMA is complete, and the device and CPU caches are synchronized,
> it's still required to mark the CPU pages as dirty, if the data was
> coming from the device. However, this driver was just issuing a
> bare put_page() call,
On Wed, Nov 20, 2019 at 11:13:36PM -0800, John Hubbard wrote:
> +static int pin_goldfish_pages(unsigned long first_page,
> + unsigned long last_page,
> + unsigned int last_page_size,
> + int is_write,
> +
On Wed, Nov 20, 2019 at 11:13:37PM -0800, John Hubbard wrote:
> And get rid of the mmap_sem calls, as part of that. Note
> that get_user_pages_fast() will, if necessary, fall back to
> __gup_longterm_unlocked(), which takes the mmap_sem as needed.
>
> Reviewed-by: Jan Kara
> Reviewed-by: Jason
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Nov 20, 2019 at 11:13:31PM -0800, John Hubbard wrote:
> A subsequent patch requires access to gup flags, so
> pass the flags argument through to the __gup_device_*
> functions.
Looks fine, but why not fold this into the patch using the flags.
Also you can use up your full 73 chars per
So while this looks correct and I still really don't see the major
benefit of the new code organization, especially as it bloats all
put_page callers.
I'd love to see code size change stats for an allyesconfig on this
commit.
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Nov 20, 2019 at 11:13:32PM -0800, John Hubbard wrote:
> There are four locations in gup.c that have a fair amount of code
> duplication. This means that changing one requires making the same
> changes in four places, not to mention reading the same code four
> times, and wondering if there
On Wed, Nov 20, 2019 at 12:28:44PM +1100, Oliver O'Halloran wrote:
> Use the helper to look up the pnv_ioda_pe for the device we're configuring DMA
> for. In the VF case there's no need set pdn->pe_number since nothing looks at
> it any more.
>
> Signed-off-by: Oliver O'Halloran
> ---
>
On Wed, Nov 20, 2019 at 12:28:19PM +1100, Oliver O'Halloran wrote:
> Move this out of the PHB's dma_dev_setup() callback and into the
> ppc_md.pcibios_fixup_iov callback. This ensures that the VF PE's
> pdev pointer is always valid for the whole time the device is
> added the bus.
>
> This isn't
> +#ifdef CONFIG_PCI_IOV
> + struct pnv_ioda_pe *pe;
> +
> + /* Fix the VF pdn PE number */
> + if (pdev->is_virtfn) {
> + list_for_each_entry(pe, >ioda.pe_list, list) {
> + if (pe->rid == ((pdev->bus->number << 8) |
> +
Robin, does this mean you ACK this series for the powerpc use case?
Alexey and other ppc folks: can you take a look?
On Tue, Nov 19, 2019 at 05:17:03PM +, Robin Murphy wrote:
> TBH I can't see it being a massive problem even if the DMA patch, driver
> and DTS patch went entirely separately via the respective DMA, PCI, and
> arm-soc trees in the same cycle. Bisecting over a merge window is a big
> enough
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
> /*
> * DMA addressing mode.
> *
> * 0 : 32 bit addressing for all chips.
> * 1 : 40 bit addressing when supported by chip.
> * 2 : 64 bit addressing when supported by chip,
> * limited to 16 segments of 4 GB -> 64
On Thu, Nov 21, 2019 at 03:22:27PM +0800, Krzysztof Kozlowski wrote:
> On Thu, 21 Nov 2019 at 15:21, Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Nov 21, 2019 at 04:20:08AM +0100, Krzysztof Kozlowski wrote:
> > > Adjust indentation from spaces to tab (+optional two spaces) as in
> > > coding style
On Thu, 21 Nov 2019 at 15:21, Greg Kroah-Hartman
wrote:
>
> On Thu, Nov 21, 2019 at 04:20:08AM +0100, Krzysztof Kozlowski wrote:
> > Adjust indentation from spaces to tab (+optional two spaces) as in
> > coding style with command like:
> > $ sed -e 's/^/\t/' -i */Kconfig
> >
> >
On 11/11/19 at 01:31pm, Bhupesh Sharma wrote:
> Changes since v3:
>
> - v3 can be seen here:
> http://lists.infradead.org/pipermail/kexec/2019-March/022590.html
> - Addressed comments from James and exported TCR_EL1.T1SZ in vmcoreinfo
> instead of PTRS_PER_PGD.
> - Added a new
On Thu, Nov 21, 2019 at 04:20:08AM +0100, Krzysztof Kozlowski wrote:
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style with command like:
> $ sed -e 's/^/\t/' -i */Kconfig
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v1:
> 1.
Convert infiniband to use the new pin_user_pages*() calls.
Also, revert earlier changes to Infiniband ODP that had it using
put_user_page(). ODP is "Case 3" in
Documentation/core-api/pin_user_pages.rst, which is to say, normal
get_user_pages() and put_page() is the API to use there.
The new
And get rid of the mmap_sem calls, as part of that. Note
that get_user_pages_fast() will, if necessary, fall back to
__gup_longterm_unlocked(), which takes the mmap_sem as needed.
Reviewed-by: Jan Kara
Reviewed-by: Jason Gunthorpe
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
1. Change v4l2 from get_user_pages() to pin_user_pages().
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Acked-by: Hans Verkuil
Cc: Ira Weiny
Signed-off-by: John Hubbard
---
101 - 131 of 131 matches
Mail list logo
