Re: [PATCH] media: dvb: get rid of VIDEO_SET_SPU_PALETTE

good, Reviewed-by: Christoph Hellwig

Re: [Linaro-mm-sig] noveau vs arm dma ops

On Thu, Apr 26, 2018 at 11:20:44AM +0200, Daniel Vetter wrote: > The above is already what we're implementing in i915, at least > conceptually (it all boils down to clflush instructions because those > both invalidate and flush). The clwb instruction that just writes back dirty cache lines might

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 11:54:43PM +0100, Russell King - ARM Linux wrote: > > if the memory was previously dirty (iow, CPU has written), you need to > flush the dirty cache lines _before_ the GPU writes happen, but you > don't know whether the CPU has speculatively prefetched, so you need > to

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote: > > get_required_mask() is supposed to tell you if you are safe. However > > we are missing lots of implementations of it for iommus so you might get > > some false negatives, improvements welcome. It's been on my list of > > things

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: > > Coordinating the backport of a trivial helper in the arm tree is not > > the end of the world. Really, this cowboy attitude is a good reason > > why graphics folks have such a bad rep. You keep poking into random > > kernel

Re: [PATCH] media: zoran: move to dma-mapping interface

On Wed, Apr 25, 2018 at 01:15:18PM +0200, Arnd Bergmann wrote: > That thought had occurred to me as well. I removed the oldest ISDN > drivers already some years ago, and the OSS sound drivers > got removed as well, and comedi got converted to the dma-mapping > interfaces, so there isn't much left

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 09:56:43AM +0200, Thierry Reding wrote: > And to add to the confusion, none of this seems to be an issue on 64-bit > ARM where the generic DMA/IOMMU code from drivers/iommu/dma-iommu.c is > used. In the long term I want everyone to use that code. Help welcome!

noveau vs arm dma ops

[discussion about this patch, which should have been cced to the iommu and linux-arm-kernel lists, but wasn't: https://www.spinics.net/lists/dri-devel/msg173630.html] On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry Reding wrote: > > API from the iommu/dma-mapping code. Drivers have no

Re: [PATCH] media: zoran: move to dma-mapping interface

On Wed, Apr 25, 2018 at 09:08:13AM +0200, Arnd Bergmann wrote: > > That probably also means it can use dma_mmap_coherent instead of the > > handcrafted remap_pfn_range loop and the PageReserved abuse. > > I'd rather not touch that code. How about adding a comment about > the fact that it should

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 09:02:17AM +0200, Daniel Vetter wrote: > Can we please not nack everything right away? Doesn't really motivate > me to show you all the various things we're doing in gpu to make the > dma layer work for us. That kind of noodling around in lower levels to > get them to do

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 08:23:15AM +0200, Daniel Vetter wrote: > For more fun: > > https://www.spinics.net/lists/dri-devel/msg173630.html > > Yeah, sometimes we want to disable the iommu because the on-gpu > pagetables are faster ... I am not on this list, but remote NAK from here. This needs

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote: > > It has a non-coherent transaction mode (which the chipset can opt to > > not implement and still flush), to make sure the AGP horror show > > doesn't happen again and GPU folks are happy with PCIe. That's at > > least my

Re: [PATCH] media: zoran: move to dma-mapping interface

On Tue, Apr 24, 2018 at 10:40:45PM +0200, Arnd Bergmann wrote: > No drivers should use virt_to_bus() any more. This converts > one of the few remaining ones to the DMA mapping interface. > > Signed-off-by: Arnd Bergmann > --- > drivers/media/pci/zoran/Kconfig| 2 +- >

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote: > Out of curiosity, how much virtual flushing stuff is there still out > there? At least in drm we've pretty much ignore this, and seem to be > getting away without a huge uproar (at least from driver developers > and users, core folks

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote: > > At the very lowest level they will need to be handled differently for > > many architectures, the questions is at what point we'll do the > > branching out. > > Having at least struct page also in that list with (dma_addr_t,

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote: > > > What we need is an sg_alloc_table_from_resources(dev, resources, > > > num_resources) which does the handling common to all drivers. > > A structure that contains > > > > {page,offset,len} + {dma_addr+dma_len} > > > > is not

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote: > > Yes there's a bit a layering violation insofar that drivers really > > shouldn't each have their own copy of "how do I convert a piece of dma > > memory into dma-buf", but that doesn't render the interface a bad idea. > >

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote: > We've broken that assumption in i915 years ago. Not struct page backed > gpu memory is very real. > > Of course we'll never feed such a strange sg table to a driver which > doesn't understand it, but allowing sg_page == NULL works

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Tue, Apr 03, 2018 at 08:08:32PM +0200, Daniel Vetter wrote: > I did not mean you should dma_map_sg/page. I just meant that using > dma_map_resource to fill only the dma address part of the sg table seems > perfectly sufficient. But that is not how the interface work, especially facing

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote: > dma_map_resource() is the right API (thought its current implementation > is fill with x86 assumptions). So i would argue that arch can decide to > implement it or simply return dma error address which trigger fallback > path into

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote: > From: "wda...@nvidia.com" > > Add an interface to find the first device which is upstream of both > devices. Please work with Logan and base this on top of the outstanding peer to peer patchset.

Re: [PATCH 1/8] lib/scatterlist: add sg_set_dma_addr() helper

On Sun, Mar 25, 2018 at 12:59:53PM +0200, Christian König wrote: > Use this function to set an sg entry to point to device resources mapped > using dma_map_resource(). The page pointer is set to NULL and only the DMA > address, length and offset values are valid. NAK. Please provide a higher

Re: [PATCH 3/4] tsi108_eth: use dma API properly

On Wed, Jan 10, 2018 at 10:09:20PM +0200, Andy Shevchenko wrote: > > + struct platform_device *pdev; > > Do you really need platform_defice reference? > > Perhaps > > struct device *hdev; // hardware device > > > data->hdev = >dev; > > Another idea > > dev->dev.parent = >dev; > > No

remove pci_dma_* abuses and workarounds V2

Back before the dawn of time pci_dma_* with a NULL pci_dev argument was used for all kinds of things, e.g. dma mapping for non-PCI devices. All this has been long removed, but it turns out we still care for a NULL pci_dev in the wrappers, and we still have two odd USB drivers that use

[PATCH 1/4] media/ttusb-budget: remove pci_zalloc_coherent abuse

Switch to a plain kzalloc instead of pci_zalloc_coherent to allocate memory for the USB DMA. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c | 18 -- 1 file changed, 4 insertions(+), 14 deletions(-) diff --git a/drivers

[PATCH 2/4] media/ttusb-dev: remove pci_zalloc_coherent abuse

Switch to a plain kzalloc instead of pci_zalloc_coherent to allocate memory for the USB DMA. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/usb/ttusb-dec/ttusb_dec.c | 18 -- 1 file changed, 4 insertions(+), 14 deletions(-) diff --git a/drivers/media/usb

[PATCH 3/4] tsi108_eth: use dma API properly

with the driver. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/net/ethernet/tundra/tsi108_eth.c | 36 ++-- 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/drivers/net/ethernet/tundra/tsi108_eth.c b/drivers/net/ethernet/tundra/tsi108_eth.c

[PATCH 4/4] PCI: Remove NULL device handling from PCI DMA API

Historically some ISA drivers used the old PCI DMA API with a NULL pdev argument, but these days this isn't used and not too useful due to the per-device DMA ops, so remove it. Signed-off-by: Christoph Hellwig <h...@lst.de> --- include/linux/pci-dma-compat.h | 27 +---

Re: [PATCH 1/3] media/ttusb-budget: remove pci_zalloc_coherent abuse

On Tue, Jan 09, 2018 at 12:49:26PM -0800, Joe Perches wrote: > This message doesn't make sense anymore and it might as well > be deleted. > > And it might be better to use kcalloc > > ttusb->iso_buffer = kcalloc(FRAMES_PER_ISO_BUF * ISO_BUF_COUNT, >

Re: [PATCH 3/3] pci-dma-compat: remove handling of NULL pdev arguments

ng that with PCI is pretty horrible. I'll add a conversion of that driver to the next resend. > > Signed-off-by: Christoph Hellwig <h...@lst.de> > > With Mauro's ack on the media/ttusb-dev patches, I could merge the > whole series via the PCI tree? Fine with me.

[PATCH 2/3] media/ttusb-dev: remove pci_zalloc_coherent abuse

Switch to a plain kzalloc instea of pci_zalloc_coherent to allocate memory for the USB DMA. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/usb/ttusb-dec/ttusb_dec.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/drivers/media/usb/ttu

[PATCH 1/3] media/ttusb-budget: remove pci_zalloc_coherent abuse

Switch to a plain kzalloc instea of pci_zalloc_coherent to allocate memory for the USB DMA. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/drivers/med

[PATCH 3/3] pci-dma-compat: remove handling of NULL pdev arguments

Historically some ISA drivers used the old pci DMA API with a NULL pdev argument, but these days this isn't used and not too useful due to the per-device DMA ops, so remove it. Signed-off-by: Christoph Hellwig <h...@lst.de> --- include/linux/pci-dma-compat.h | 27 +---

remove pci_dma_* abuses and workarounds

Back before the dawn of time pci_dma_* with a NULL pci_dev argument was used for all kinds of things, e.g. dma mapping for non-PCI devices. All this has been long removed, but it turns out we still care for a NULL pci_dev in the wrappers, and we still have two odd USB drivers that use

Re: [PATCH v4 00/12] Intel IPU3 ImgU patchset

Please keep everyone on CC for all the patches, othervise they are complete unreviable and will be ignored.

Re: [PATCH v3 0/2] [media] videobuf2-dc: Add support for cacheable MMAP

On Thu, Jul 13, 2017 at 02:21:53PM +0100, Russell King - ARM Linux wrote: > My conclusion of the dma_alloc_noncoherent() and dma_cache_sync() API > when it was introduced is that it's basically a completely broken > interface, and I've never seen any point to it. Maybe some of that is > because

Re: [PATCH v3 0/2] [media] videobuf2-dc: Add support for cacheable MMAP

On Mon, Jul 03, 2017 at 11:27:32AM +0200, Marek Szyprowski wrote: > The main question here if we want to merge incomplete solution or not. As > for now, there is no support in ARM/ARM64 for NON_CONSISTENT attribute. > Also none of the v4l2 drivers use it. Sadly support for NON_CONSISTENT >

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On Wed, Apr 26, 2017 at 12:11:33PM -0600, Logan Gunthorpe wrote: > Ok, well for starters I think you are mistaken about kmap being able to > fail. I'm having a hard time finding many users of that function that > bother to check for an error when calling it. A quick audit of the arch code shows

Re: [PATCH v2 02/21] libiscsi: Add an internal error code

On Tue, Apr 25, 2017 at 12:20:49PM -0600, Logan Gunthorpe wrote: > This is a prep patch to add a new error code to libiscsi. We want to > rework some kmap calls to be able to fail. When we do, we'd like to > use this error code. The kmap case in iscsi_tcp_segment_map can already fail. Please add

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On Tue, Apr 25, 2017 at 12:20:48PM -0600, Logan Gunthorpe wrote: > This patch introduces functions which kmap the pages inside an sgl. > These functions replace a common pattern of kmap(sg_page(sg)) that is > used in more than 50 places within the kernel. > > The motivation for this work is to

Re: [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote: > Very straightforward conversion to the new function in all four spots. I think the right fix here is to switch dm-crypt to the ahash API that takes a scatterlist.

Re: [PATCH 03/22] libiscsi: Make use of new the sg_map helper function

On Thu, Apr 13, 2017 at 04:05:16PM -0600, Logan Gunthorpe wrote: > Convert the kmap and kmap_atomic uses to the sg_map function. We now > store the flags for the kmap instead of a boolean to indicate > atomicitiy. We also propogate a possible kmap error down and create > a new

Re: [PATCH 01/22] scatterlist: Introduce sg_map helper functions

> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 0007b79..b95934b 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -37,6 +37,9 @@ > > #include > > +/* Prevent the highmem.h macro from aliasing ops->kunmap_atomic */ > +#undef

Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

On Thu, Apr 13, 2017 at 11:06:16PM -0600, Logan Gunthorpe wrote: > Or maybe I'll just send a patch for that > separately seeing it doesn't depend on anything and is pretty simple. I > can do that next week. Yes, please just send that patch linux-nvme, we should be able to get it into 4.12.

Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote: > This is a straight forward conversion in two places. Should kmap fail, > the code will return an INVALD_DATA error in the completion. It really should be using nvmet_copy_from_sgl to make things safer, as we don't want to rely on

Re: kill off pci_enable_msi_{exact,range}

On Fri, Jan 13, 2017 at 11:13:21AM -0600, Bjorn Helgaas wrote: > I dropped the empty commit and replaced the xgbe patch with the one below. > Can you take a look at [1] and make sure it's what you expected? This looks great, thanks! -- To unsubscribe from this list: send the line "unsubscribe

Re: kill off pci_enable_msi_{exact,range}

On Fri, Jan 13, 2017 at 08:55:03AM +0100, Christoph Hellwig wrote: > On Thu, Jan 12, 2017 at 03:29:00PM -0600, Bjorn Helgaas wrote: > > Applied all three (with Tom's ack on the amd-xgbe patch) to pci/msi for > > v4.11, thanks! > > Tom had just send me an event better vers

Re: kill off pci_enable_msi_{exact,range}

On Thu, Jan 12, 2017 at 03:29:00PM -0600, Bjorn Helgaas wrote: > Applied all three (with Tom's ack on the amd-xgbe patch) to pci/msi for > v4.11, thanks! Tom had just send me an event better version of the xgbe patch. Tom, maybe you can resend that relative to the PCI tree [1], so that we don't

Re: [PATCH 2/3] xgbe: switch to pci_irq_alloc_vectors

On Tue, Jan 10, 2017 at 12:40:10PM -0600, Tom Lendacky wrote: > On 1/9/2017 2:37 PM, Christoph Hellwig wrote: > > The newly added xgbe drivers uses the deprecated pci_enable_msi_exact > > and pci_enable_msix_range interfaces. Switch it to use > > pci_irq_alloc_vectors ins

[PATCH 3/3] PCI/msi: remove pci_enable_msi_{exact,range}

All multi-MSI allocations are now done through pci_irq_alloc_vectors, so remove the old interface. Signed-off-by: Christoph Hellwig <h...@lst.de> --- Documentation/PCI/MSI-HOWTO.txt | 6 ++ drivers/pci/msi.c | 26 +- include/linux/pci.h

[PATCH 2/3] xgbe: switch to pci_irq_alloc_vectors

The newly added xgbe drivers uses the deprecated pci_enable_msi_exact and pci_enable_msix_range interfaces. Switch it to use pci_irq_alloc_vectors instead. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/net/ethernet/amd/xgbe/xgbe-pci.c | 47 +--- d

[PATCH 1/3] media/cobalt: use pci_irq_allocate_vectors

Simply the interrupt setup by using the new PCI layer helpers. Despite using pci_enable_msi_range, this driver was only requesting a single MSI vector anyway. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/pci/cobalt/cobalt-driver.c | 8 ++-- drivers/media/pci/

kill off pci_enable_msi_{exact,range}

I had hope that we could kill these old interfaces of for 4.10-rc, but as of today Linus tree still has two users: (1) the cobalt media driver, for which I sent a patch long time ago, it got missed in the merge window. (2) the new xgbe driver was merged in 4.10-rc but used the old

Re: [PATCH v2 7/7] uapi: export all headers under uapi directories

On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote: > Regularly, when a new header is created in include/uapi/, the developer > forgets to add it in the corresponding Kbuild file. This error is usually > detected after the release is out. > > In fact, all headers under uapi

Re: [PATCH 6/6] media/cobalt: use pci_irq_allocate_vectors

On Wed, Dec 14, 2016 at 11:37:17AM +0100, Hans Verkuil wrote: > Completely forgot this. Is it OK to queue it for 4.11? Or is it blocking > other follow-up work you want to do for 4.10? My plan was to see if Bjorn would take the patch to do the trivial removal of pci_enable_msix_exact and

Re: [PATCH 6/6] media/cobalt: use pci_irq_allocate_vectors

Hi Hans, just checked the current Linux tree and cobalt still uses the old pci_enable_msi_range call. Did you queue this patch up for 4.10? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: Enabling peer to peer device transactions for PCIe devices

On Tue, Dec 06, 2016 at 09:38:50AM -0700, Jason Gunthorpe wrote: > > > I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial > > > to accomplish in sysfs through /sys/dev/char to find the sysfs path of the > > > device-dax instance under the nvme device, or if you already have the

Re: Enabling peer to peer device transactions for PCIe devices

On Mon, Dec 05, 2016 at 12:46:14PM -0700, Jason Gunthorpe wrote: > In any event the allocator still needs to track which regions are in > use and be able to hook 'free' from userspace. That does suggest it > should be integrated into the nvme driver and not a bolt on driver.. Two totally

Re: Enabling peer to peer device transactions for PCIe devices

On Thu, Nov 24, 2016 at 11:11:34AM -0700, Logan Gunthorpe wrote: > * Regular DAX in the FS doesn't work at this time because the FS can > move the file you think your transfer to out from under you. Though I > understand there's been some work with XFS to solve that issue. The file system will

Re: [PATCH 00/28] Reenable maybe-uninitialized warnings

On Tue, Oct 18, 2016 at 12:03:28AM +0200, Arnd Bergmann wrote: > This is a set of patches that I hope to get into v4.9 in some form > in order to turn on the -Wmaybe-uninitialized warnings again. Hi Arnd, I jsut complained to Geert that I was introducing way to many bugs or pointless warnings

Re: [PATCH 4/6] vfio_pci: use pci_irq_allocate_vectors

On Thu, Sep 29, 2016 at 01:21:01PM -0600, Alex Williamson wrote: > Sorry for the delay, slipped by me. Overall a really nice cleanup. > One tiny nit, the commit log mis-names the function as > pci_irq_allocate_vectors instead of pci_alloc_irq_vectors. With that, > > Acked-by: Alex Williamson

Re: [PATCH 5/6] genwqe: use pci_irq_allocate_vectors

On Thu, Sep 29, 2016 at 03:45:29PM -0300, Gabriel Krisman Bertazi wrote: > I'm stepping up to assist with the genwqe_card driver just now, since we > (ibm) missed some of the last patches that went in. I'll add myself to > maintainers file. Can your forward it to Greg together with whatever

Re: [PATCH 5/6] genwqe: use pci_irq_allocate_vectors

On Thu, Sep 29, 2016 at 03:28:02PM -0300, Gabriel Krisman Bertazi wrote: > Christoph Hellwig <h...@lst.de> writes: > > > Simply the interrupt setup by using the new PCI layer helpers. > > Good clean up. Tested and: > > Acked-by: Gabriel Krisman Bertazi <kris..

Re: [PATCH 2/6] ipr: use pci_irq_allocate_vectors

On Thu, Sep 29, 2016 at 09:01:44AM -0500, Brian King wrote: > Thanks Christoph. Very nice. As I was reviewing the patch, I noticed > the additional PCI_IRQ_AFFINITY flag, which is currently not being set > in this patch. Is the intention to set that globally by default, or > should I follow up

Re: [PATCH 6/6] media/cobalt: use pci_irq_allocate_vectors

On Fri, Sep 16, 2016 at 10:01:42AM +0200, Hans Verkuil wrote: > PCI_IRQ_MSI is unknown, I assume that this will appear in 4.9? The flag is in 4.8-rc. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info

[PATCH 2/6] ipr: use pci_irq_allocate_vectors

iterate over a single line in the non MSI-X case. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/ipr.c | 173 - drivers/scsi/ipr.h | 7 +-- 2 files changed, 52 insertions(+), 128 deletions(-) diff --git a/drivers/scsi/i

[PATCH 5/6] genwqe: use pci_irq_allocate_vectors

Simply the interrupt setup by using the new PCI layer helpers. One odd thing about this driver is that it looks like it could request multiple MSI vectors, but it will then only ever use a single one. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/misc/genwqe/card_base.h

[PATCH 6/6] media/cobalt: use pci_irq_allocate_vectors

Simply the interrupt setup by using the new PCI layer helpers. Despite using pci_enable_msi_range, this driver was only requesting a single MSI vector anyway. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/pci/cobalt/cobalt-driver.c | 8 ++-- drivers/media/pci/

[PATCH 1/6] arcmsr: use pci_alloc_irq_vectors

to only iterate over a single line in the non MSI-X case. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/arcmsr/arcmsr.h | 5 +-- drivers/scsi/arcmsr/arcmsr_hba.c | 82 2 files changed, 33 insertions(+), 54 deletions(-) diff

[PATCH 4/6] vfio_pci: use pci_irq_allocate_vectors

Simply the interrupt setup by using the new PCI layer helpers. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/vfio/pci/vfio_pci_intrs.c | 45 + drivers/vfio/pci/vfio_pci_private.h | 1 - 2 files changed, 10 insertions(+), 36 deletions(-)

replace pci_enable_msi_{exact_range} with pci_alloc_irq_vectors

Hi all, this series switch the remaining users of pci_enable_msi_{exact_range} (accounting for ahci and nvme being done through other channels) to use the pci_alloc_irq_vectors helper instead and thus simplify the interrupt code in those drivers a lot. I decided to post it as a series to

[PATCH 3/6] skd: use pci_alloc_irq_vectors

Switch the skd driver to use pci_alloc_irq_vectors. We need to two calls to pci_alloc_irq_vectors as skd only supports multiple MSI-X vectors, but not multiple MSI vectors. Otherwise this cleans up a lot of cruft and allows to a lot more common code. Signed-off-by: Christoph Hellwig &l

Re: cx23885: use pci_set_dma_mask insted of pci_dma_supported

Hi Tycho, please try the patch below - Andrew should be sending it on to Linux soon. --- >From 4c03a9f77104b04af45833e0424954191ca94a12 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig <h...@lst.de> Date: Wed, 11 Nov 2015 18:13:09 +0100 Subject: various: fix pci_set_dma_mask ret

[PATCH 05/15] cx88: use pci_set_dma_mask insted of pci_dma_supported

This ensures the dma mask that is supported by the driver is recorded in the device structure. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/pci/cx88/cx88-alsa.c | 2 +- drivers/media/pci/cx88/cx88-mpeg.c | 2 +- drivers/media/pci/cx88/cx88-video.c | 2 +- 3 files chan

[PATCH 02/15] tw68-core: use pci_set_dma_mask insted of pci_dma_supported

This ensures the dma mask that is supported by the driver is recorded in the device structure. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/pci/tw68/tw68-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/pci/tw68/tw68-core.c b/d

remove dma_supported and pci_dma_supported as public APIs

All driver should be using dma_set_mask / pci_set_dma_mask to try to set the dma mask instead of just querying it. Without that some iommu implementations may not work. pci_dma_supported is removed entirely, but dma_supported stays for dma_ops implementations for now. -- To unsubscribe from

[PATCH 06/15] cx25821: use pci_set_dma_mask insted of pci_dma_supported

This ensures the dma mask that is supported by the driver is recorded in the device structure. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/pci/cx25821/cx25821-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/pci/cx25821/cx25821-

[PATCH 03/15] saa7164: use pci_set_dma_mask insted of pci_dma_supported

This ensures the dma mask that is supported by the driver is recorded in the device structure. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/pci/saa7164/saa7164-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/pci/saa7164/saa7164-

[PATCH 04/15] saa7134: use pci_set_dma_mask insted of pci_dma_supported

This ensures the dma mask that is supported by the driver is recorded in the device structure. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/pci/saa7134/saa7134-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/pci/saa7134/saa7134-

[PATCH 01/15] pcnet32: use pci_set_dma_mask insted of pci_dma_supported

This ensures the dma mask that is supported by the driver is recorded in the device structure. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/net/ethernet/amd/pcnet32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/amd/pcnet32.c b/d

[PATCH 14/15] pci: remove pci_dma_supported

Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/parisc/ccio-dma.c| 2 -- include/asm-generic/pci-dma-compat.h | 6 -- 2 files changed, 8 deletions(-) diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c index 957b421..8e11fb2 100644 --- a/drivers/

[PATCH 15/15] dma: remove external references to dma_supported

Signed-off-by: Christoph Hellwig <h...@lst.de> --- Documentation/DMA-API.txt | 13 - drivers/usb/host/ehci-hcd.c | 2 +- drivers/usb/host/fotg210-hcd.c | 2 +- drivers/usb/host/fusbh200-hcd.c | 2 +- drivers/usb/host/oxu210hp-hcd.c | 2 +- 5 files changed, 4 inse

[PATCH 13/15] usbnet: remove ifdefed out call to dma_supported

Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/net/usb/usbnet.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c index b4cf107..9497d51 100644 --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -1661,12 +

[PATCH 08/15] netup_unidvb: use pci_set_dma_mask insted of pci_dma_supported

This ensures the dma mask that is supported by the driver is recorded in the device structure. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/pci/netup_unidvb/netup_unidvb_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/pci/netup_

[PATCH 12/15] kaweth: remove ifdefed out call to dma_supported

Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/net/usb/kaweth.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/net/usb/kaweth.c b/drivers/net/usb/kaweth.c index 1e9cdca..f64b25c 100644 --- a/drivers/net/usb/kaweth.c +++ b/drivers/net/usb/kaweth.c @@ -1177,12 +

[PATCH 07/15] cx23885: use pci_set_dma_mask insted of pci_dma_supported

This ensures the dma mask that is supported by the driver is recorded in the device structure. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/pci/cx23885/cx23885-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/pci/cx23885/cx23885-

[PATCH 10/15] nouveau: don't call pci_dma_supported

Just try to set a 64-bit DMA mask first and retry with the smaller dma_mask if dma_set_mask failed. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/gpu/drm/nouveau/nouveau_ttm.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/n

[PATCH 11/15] sfc: don't call dma_supported

dma_set_mask already checks for a supported DMA mask before updating it, the call to dma_supported is redundant. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/net/ethernet/sfc/efx.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethern

[PATCH 09/15] mpsc: use dma_set_mask insted of dma_supported

This ensures the dma mask that is supported by the driver is recorded in the device structure. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/tty/serial/mpsc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/mpsc.c b/drivers/tty/serial/

Re: [PATCH 29/31] parisc: handle page-less SG entries

On Wed, Aug 12, 2015 at 09:01:02AM -0700, Linus Torvalds wrote: I'm assuming that anybody who wants to use the page-less scatter-gather lists always does so on memory that isn't actually virtually mapped at all, or only does so on sane architectures that are cache coherent at a physical level,

Re: [PATCH 31/31] dma-mapping-common: skip kmemleak checks for page-less SG entries

On Wed, Aug 12, 2015 at 09:05:15AM -0700, Linus Torvalds wrote: [ Again, I'm responding to one random patch - this pattern was in other patches too. ] A question: do we actually expect to mix page-less and pageful SG entries in the same SG list? How does that happen? Both for DAX and

Re: RFC: prepare for struct scatterlist entries without page backing

On Thu, Aug 13, 2015 at 09:37:37AM +1000, Julian Calaby wrote: I.e. ~90% of this patch set seems to be just mechanically dropping BUG_ON()s and converting open coded stuff to use accessor functions (which should be macros or get inlined, right?) - and the remaining bit is not flushing if we

Re: RFC: prepare for struct scatterlist entries without page backing

On Wed, Aug 12, 2015 at 03:42:47PM +0300, Boaz Harrosh wrote: The support I have suggested and submitted for zone-less sections. (In my add_persistent_memory() patchset) Would work perfectly well and transparent for all such multimedia cases. (All hacks removed). In fact I have loaded pmem

[PATCH 16/31] s390: handle page-less SG entries

Use sg_phys() instead of page_to_phys(sg_page(sg)) so that we don't require a page structure for all DMA memory. Signed-off-by: Christoph Hellwig h...@lst.de --- arch/s390/pci/pci_dma.c | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/arch/s390/pci

[PATCH 17/31] ia64/sba_iommu: remove sba_sg_address

Signed-off-by: Christoph Hellwig h...@lst.de --- arch/ia64/hp/common/sba_iommu.c | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c index 344387a..9e5aa8e 100644 --- a/arch/ia64/hp/common

[PATCH 18/31] nios2: handle page-less SG entries

Make all cache invalidation conditional on sg_has_page() and use sg_phys to get the physical address directly. Signed-off-by: Christoph Hellwig h...@lst.de --- arch/nios2/mm/dma-mapping.c | 29 +++-- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/arch

RFC: prepare for struct scatterlist entries without page backing

Dan Williams started to look into addressing I/O to and from Persistent Memory in his series from June: http://thread.gmane.org/gmane.linux.kernel.cross-arch/27944 I've started looking into DMA mapping of these SGLs specifically instead of the map_pfn method in there. In addition to

[PATCH 03/31] dma-debug: handle page-less SG entries

Use sg_pfn to get a the PFN and skip checks that require a kernel virtual address. Signed-off-by: Christoph Hellwig h...@lst.de --- lib/dma-debug.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/dma-debug.c b/lib/dma-debug.c index dace71f..a215a80 100644

[PATCH 01/31] scatterlist: add sg_pfn and sg_has_page helpers

Signed-off-by: Christoph Hellwig h...@lst.de --- include/linux/scatterlist.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h index 9b1ef0c..b1056bf 100644 --- a/include/linux/scatterlist.h +++ b/include/linux/scatterlist.h

[PATCH 02/31] scatterlist: use sg_phys()

From: Dan Williams dan.j.willi...@intel.com Coccinelle cleanup to replace open coded sg to physical address translations. This is in preparation for introducing scatterlists that reference __pfn_t. // sg_phys.cocci: convert usage page_to_phys(sg_page(sg)) to sg_phys(sg) // usage: make

  1   2   >