* [PATCH] net/ucc_geth: some fix in current kernel
From: Xie Xiaobo @ 2011-12-27 9:48 UTC (permalink / raw)
To: linuxppc-dev, netdev, leoli; +Cc: Xie Xiaobo
* Revert commit "ucc_geth: Fix hangs after switching from full to half duplex"
This commit impacted the driver in all link state change more than
duplex change.
* Change some parameters.
Increased the BD ring length.
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
---
drivers/net/ethernet/freescale/ucc_geth.c | 41 ++++------------------------
drivers/net/ethernet/freescale/ucc_geth.h | 6 ++--
2 files changed, 9 insertions(+), 38 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index b5dc027..3e18902 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006-2009 Freescale Semicondutor, Inc. All rights reserved.
+ * Copyright (C) 2006-2010 Freescale Semiconductor, Inc. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
* Li Yang <leoli@freescale.com>
@@ -1570,28 +1570,6 @@ static int ugeth_disable(struct ucc_geth_private *ugeth, enum comm_dir mode)
return 0;
}
-static void ugeth_quiesce(struct ucc_geth_private *ugeth)
-{
- /* Prevent any further xmits, plus detach the device. */
- netif_device_detach(ugeth->ndev);
-
- /* Wait for any current xmits to finish. */
- netif_tx_disable(ugeth->ndev);
-
- /* Disable the interrupt to avoid NAPI rescheduling. */
- disable_irq(ugeth->ug_info->uf_info.irq);
-
- /* Stop NAPI, and possibly wait for its completion. */
- napi_disable(&ugeth->napi);
-}
-
-static void ugeth_activate(struct ucc_geth_private *ugeth)
-{
- napi_enable(&ugeth->napi);
- enable_irq(ugeth->ug_info->uf_info.irq);
- netif_device_attach(ugeth->ndev);
-}
-
/* Called every time the controller might need to be made
* aware of new link state. The PHY code conveys this
* information through variables in the ugeth structure, and this
@@ -1605,11 +1583,14 @@ static void adjust_link(struct net_device *dev)
struct ucc_geth __iomem *ug_regs;
struct ucc_fast __iomem *uf_regs;
struct phy_device *phydev = ugeth->phydev;
+ unsigned long flags;
int new_state = 0;
ug_regs = ugeth->ug_regs;
uf_regs = ugeth->uccf->uf_regs;
+ spin_lock_irqsave(&ugeth->lock, flags);
+
if (phydev->link) {
u32 tempval = in_be32(&ug_regs->maccfg2);
u32 upsmr = in_be32(&uf_regs->upsmr);
@@ -1666,21 +1647,9 @@ static void adjust_link(struct net_device *dev)
}
if (new_state) {
- /*
- * To change the MAC configuration we need to disable
- * the controller. To do so, we have to either grab
- * ugeth->lock, which is a bad idea since 'graceful
- * stop' commands might take quite a while, or we can
- * quiesce driver's activity.
- */
- ugeth_quiesce(ugeth);
- ugeth_disable(ugeth, COMM_DIR_RX_AND_TX);
-
out_be32(&ug_regs->maccfg2, tempval);
out_be32(&uf_regs->upsmr, upsmr);
- ugeth_enable(ugeth, COMM_DIR_RX_AND_TX);
- ugeth_activate(ugeth);
}
} else if (ugeth->oldlink) {
new_state = 1;
@@ -1691,6 +1660,8 @@ static void adjust_link(struct net_device *dev)
if (new_state && netif_msg_link(ugeth))
phy_print_status(phydev);
+
+ spin_unlock_irqrestore(&ugeth->lock, flags);
}
/* Initialize TBI PHY interface for communicating with the
diff --git a/drivers/net/ethernet/freescale/ucc_geth.h b/drivers/net/ethernet/freescale/ucc_geth.h
index d12fcad..b0b42b4 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.h
+++ b/drivers/net/ethernet/freescale/ucc_geth.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) Freescale Semicondutor, Inc. 2006-2009. All rights reserved.
+ * Copyright (C) 2006-2010 Freescale Semiconductor, Inc. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
*
@@ -875,8 +875,8 @@ struct ucc_geth_hardware_statistics {
#define UCC_GETH_SIZE_OF_BD QE_SIZEOF_BD
/* Driver definitions */
-#define TX_BD_RING_LEN 0x10
-#define RX_BD_RING_LEN 0x10
+#define TX_BD_RING_LEN 64
+#define RX_BD_RING_LEN 64
#define TX_RING_MOD_MASK(size) (size-1)
#define RX_RING_MOD_MASK(size) (size-1)
--
1.7.5.1
^ permalink raw reply related
* RE: [PATCH 00/14] DMA-mapping framework redesign preparation
From: Marek Szyprowski @ 2011-12-27 8:25 UTC (permalink / raw)
To: 'Matthew Wilcox'
Cc: linux-mips, linux-ia64, linux-sh, linux-mm, sparclinux,
linux-arch, 'Stephen Rothwell', 'Jonathan Corbet',
x86, 'Arnd Bergmann', microblaze-uclinux, linaro-mm-sig,
Andrzej Pietrasiewicz, 'Thomas Gleixner',
linux-arm-kernel, discuss, linux-kernel, 'Kyungmin Park',
linux-alpha, 'Andrew Morton', linuxppc-dev
In-Reply-To: <20111223163516.GO20129@parisc-linux.org>
Hello,
On Friday, December 23, 2011 5:35 PM Matthew Wilcox wrote:
> On Fri, Dec 23, 2011 at 01:27:19PM +0100, Marek Szyprowski wrote:
> > The first issue we identified is the fact that on some platform (again,
> > mainly ARM) there are several functions for allocating DMA buffers:
> > dma_alloc_coherent, dma_alloc_writecombine and dma_alloc_noncoherent
>
> Is this write-combining from the point of view of the device (ie iommu),
> or from the point of view of the CPU, or both?
It is about write-combining from the CPU point of view. Right now there are
no devices with such advanced memory interface to do write combining on the
DMA side, but I believe that they might appear at some point in the future
as well.
> > The next step in dma mapping framework update is the introduction of
> > dma_mmap/dma_mmap_attrs() function. There are a number of drivers
> > (mainly V4L2 and ALSA) that only exports the DMA buffers to user space.
> > Creating a userspace mapping with correct page attributes is not an easy
> > task for the driver. Also the DMA-mapping framework is the only place
> > where the complete information about the allocated pages is available,
> > especially if the implementation uses IOMMU controller to provide a
> > contiguous buffer in DMA address space which is scattered in physical
> > memory space.
>
> Surely we only need a helper which drivrs can call from their mmap routine
> to solve this?
On ARM architecture it is already implemented this way and a bunch of drivers
use dma_mmap_coherent/dma_mmap_writecombine calls. We would like to standardize
these calls across all architectures.
> > Usually these drivers don't touch the buffer data at all, so the mapping
> > in kernel virtual address space is not needed. We can introduce
> > DMA_ATTRIB_NO_KERNEL_MAPPING attribute which lets kernel to skip/ignore
> > creation of kernel virtual mapping. This way we can save previous
> > vmalloc area and simply some mapping operation on a few architectures.
>
> I really think this wants to be a separate function. dma_alloc_coherent
> is for allocating memory to be shared between the kernel and a driver;
> we already have dma_map_sg for mapping userspace I/O as an alternative
> interface. This feels like it's something different again rather than
> an option to dma_alloc_coherent.
That is just a starting point for the discussion.
I thought about this API a bit and came to conclusion that there is no much
difference between a dma_alloc_coherent which creates a mapping in kernel
virtual space and the one that does not. It is just a hint from the driver
that it will not use that mapping at all. Of course this attribute makes sense
only together with adding a dma_mmap_attrs() call, because otherwise drivers
won't be able to get access to the buffer data.
On coherent architectures where dma_alloc_coherent is just a simple wrapper
around alloc_pages_exact() such attribute can be simply ignored without any
impact on the drivers (that's the main idea behind dma attributes!).
However such hint will help a lot on non-coherent architectures where
additional work need to be done to provide a cohenent mapping in kernel
address space. It also saves some precious kernel resources like vmalloc
address range.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH] dmaengine: async_xor, fix zero address issue when xor highmem page
From: b29237 @ 2011-12-27 6:30 UTC (permalink / raw)
To: vinod.koul, dan.j.williams, linuxppc-dev, linux-kernel, r58472
Cc: Forrest shi
From: Forrest shi <b29237@freescale.com>
we may do_sync_xor high mem pages, in this case, page_address will
return zero address which cause a failure.
this patch uses kmap_atomic before xor the pages and kunmap_atomic
after it.
Signed-off-by: b29237@freescale.com <xuelin.shi@freescale.com>
---
crypto/async_tx/async_xor.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c
index bc28337..5b416d1 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -26,6 +26,7 @@
#include <linux/kernel.h>
#include <linux/interrupt.h>
#include <linux/mm.h>
+#include <linux/highmem.h>
#include <linux/dma-mapping.h>
#include <linux/raid/xor.h>
#include <linux/async_tx.h>
@@ -126,7 +127,7 @@ do_sync_xor(struct page *dest, struct page **src_list, unsigned int offset,
int src_cnt, size_t len, struct async_submit_ctl *submit)
{
int i;
- int xor_src_cnt = 0;
+ int xor_src_cnt = 0, kmap_cnt=0;
int src_off = 0;
void *dest_buf;
void **srcs;
@@ -138,11 +139,13 @@ do_sync_xor(struct page *dest, struct page **src_list, unsigned int offset,
/* convert to buffer pointers */
for (i = 0; i < src_cnt; i++)
- if (src_list[i])
- srcs[xor_src_cnt++] = page_address(src_list[i]) + offset;
+ if (src_list[i]) {
+ srcs[xor_src_cnt++] = kmap_atomic(src_list[i], KM_USER1) + offset;
+ }
+ kmap_cnt = xor_src_cnt;
src_cnt = xor_src_cnt;
/* set destination address */
- dest_buf = page_address(dest) + offset;
+ dest_buf = kmap_atomic(dest, KM_USER0) + offset;
if (submit->flags & ASYNC_TX_XOR_ZERO_DST)
memset(dest_buf, 0, len);
@@ -157,6 +160,11 @@ do_sync_xor(struct page *dest, struct page **src_list, unsigned int offset,
src_off += xor_src_cnt;
}
+ kunmap_atomic(dest_buf, KM_USER0);
+ for (i = 0; i < kmap_cnt; i++)
+ if (src_list[i])
+ kunmap_atomic(srcs[i], KM_USER1);
+
async_tx_sync_epilog(submit);
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] KVM: Move gfn_to_memslot() to kvm_host.h
From: Avi Kivity @ 2011-12-26 13:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc, kvm
In-Reply-To: <20111220092102.GA5626@bloggs.ozlabs.ibm.com>
On 12/20/2011 11:21 AM, Paul Mackerras wrote:
> This moves gfn_to_memslot(), and the functions it calls, that is,
> search_memslots() and __gfn_to_memslot(), from kvm_main.c to kvm_host.h
> so that gfn_to_memslot() can be called from non-modular code even
> when KVM is a module. On powerpc, the Book3S HV style of KVM has
> code that is called from real mode which needs to call gfn_to_memslot()
> and thus needs this. (Module code is allocated in the vmalloc region,
> which can't be accessed in real mode.)
>
> With this, we can remove builtin_gfn_to_memslot() from book3s_hv_rm_mmu.c
> and thus eliminate a little bit of duplication.
Those functions are too big to be inlined IMO. How about moving them to
another C file, and making it builtin for ppc?
The only issue is what to call it. virt/kvm/builtin-for-ppc seems silly.
Or we could move the implementation into a header file, with an extra __
prefix, and have the C stubs call those inlines, so we have exactly on
instantiation. Your real mode code can then call the inlines.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* RE: [PATCH 3/3] powerpc/44x: Add support PCI-E for APM821xx SoC and Bluestone board
From: Vinh Huu Tuong Nguyen @ 2011-12-26 8:00 UTC (permalink / raw)
To: Josh Boyer
Cc: Ayman El-Khashab, Dave Kleikamp, Lucas De Marchi, Rob Herring,
Paul Gortmaker, Paul Mackerras, Anton Blanchard, Jiri Kosina,
linuxppc-dev, linux-kernel
In-Reply-To: <CA+5PVA4cjiUvn4YavkFs6Jx87YpO8yHZZbm4pcPJQn1r1cggUA@mail.gmail.com>
-----Original Message-----
From: Josh Boyer [mailto:jwboyer@gmail.com]
Sent: Thursday, December 22, 2011 3:20 AM
To: Vinh Huu Tuong Nguyen
Cc: Benjamin Herrenschmidt; Paul Mackerras; Matt Porter; Kumar Gala; Paul
Gortmaker; Anton Blanchard; Dave Kleikamp; Grant Likely; Tony Breeds; Rob
Herring; Jiri Kosina; Lucas De Marchi; Ayman El-Khashab;
linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] powerpc/44x: Add support PCI-E for APM821xx SoC
and Bluestone board
On Tue, Dec 20, 2011 at 11:47 PM, Vinh Huu Tuong Nguyen
<vhtnguyen@apm.com> wrote:
>> +
>> + =A0 =A0 =A0 mtdcri(SDR0, port->sdr_base + PESDRn_RCSSET,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mfdcri(SDR0, port->sdr_base + PESDRn_RCSSE=
T) |
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (PESDRx_RCSSET_RSTGU | PESDRx_RCSSET_RSTPY=
N));
>> +
>> + =A0 =A0 =A0 /* Poll for PHY reset */
>> + =A0 =A0 =A0 timeout =3D 0;
>> + =A0 =A0 =A0 while ((!(mfdcri(SDR0, PESDR0_460EX_RSTSTA +
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (port->index * 0x55)) & 0x=
1)) &&
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(timeout < PCIE_PHY_RESET_TIMEOUT)) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(10);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 timeout++;
>> + =A0 =A0 =A0 }
>> +
>> + =A0 =A0 =A0 if (timeout < PCIE_PHY_RESET_TIMEOUT) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mtdcri(SDR0, port->sdr_base + PESDRn_RCSSE=
T,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (mfdcri(SDR0, port->sdr_ba=
se + PESDRn_RCSSET) &
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ~(PESDRx_RCSSET_RSTGU | PE=
SDRx_RCSSET_RSTDL)) |
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PESDRx_RCSSET_RSTPYN);
>> +
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 port->has_ibpre =3D 1;
>> +
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0;
>> + =A0 =A0 =A0 } else {
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk(KERN_INFO "PCIE: Can't reset PHY\n"=
);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -1;
>> + =A0 =A0 =A0 }
>
> If we can't reset the PHY, does this whole function essentially fail?
> Do the devices not get renumbered, etc? =A0If so, you probably want to
> make that KERN_ERR.
> [Vinh Nguyen] if we can't reset the PHY, maybe the device can't work
> properly. I will update codes to return the error in case PHY can't
reset.
OK.
>> @@ -1751,9 +1856,9 @@ static void __init
> ppc4xx_configure_pciex_PIMs(struct ppc4xx_pciex_port *port,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * if it works
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0out_le32(mbase + PECFG_PIM0LAL, 0x0000000=
0);
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_le32(mbase + PECFG_PIM0LAH, 0x00000000=
);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_le32(mbase + PECFG_PIM0LAH, 0x00000008=
); /* Moving
> on HB */
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0out_le32(mbase + PECFG_PIM1LAL, 0x0000000=
0);
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_le32(mbase + PECFG_PIM1LAH, 0x00000000=
);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_le32(mbase + PECFG_PIM1LAH, 0x0000000c=
); /* Moving
> on HB */
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0out_le32(mbase + PECFG_PIM01SAH, 0xffff00=
00);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0out_le32(mbase + PECFG_PIM01SAL, 0x000000=
00);
>
> Why are these values changed, and are those changes only needed on
> APM821xx?
> [Vinh Nguyen] In system memory map of 460EX chip, we have an "alias DDR
> SDRAM" area that is Local Memory Alias for HB(high bandwidth), so we
tried
> to initialize it for speedup. For APM821xx, although we didn't mention
> about this area, this configuration still works well. So we keep it.
This function isn't just called for 460EX or APM821xx SoCs. It's
called on any 4xx SoC with PCIe configured.
Is this change going to work on them all? If not, it needs to be
conditionalized.
[Vinh Nguyen] I will update my codes as your comments. Please see next
submitted codes.
>> diff --git a/arch/powerpc/sysdev/ppc4xx_pci.h
> b/arch/powerpc/sysdev/ppc4xx_pci.h
>> index 32ce763..faf3017 100644
>> --- a/arch/powerpc/sysdev/ppc4xx_pci.h
>> +++ b/arch/powerpc/sysdev/ppc4xx_pci.h
>> @@ -441,6 +441,7 @@
>> =A0/*
>> =A0* Config space register offsets
>> =A0*/
>> +#define PECFG_ECDEVCTL =A0 =A0 =A0 =A0 0x060
>> =A0#define PECFG_ECRTCTL =A0 =A0 =A0 =A0 =A00x074
>>
>> =A0#define PECFG_BAR0LMPA =A0 =A0 =A0 =A0 0x210
>> @@ -448,6 +449,7 @@
>> =A0#define PECFG_BAR1MPA =A0 =A0 =A0 =A0 =A00x218
>> =A0#define PECFG_BAR2LMPA =A0 =A0 =A0 =A0 0x220
>> =A0#define PECFG_BAR2HMPA =A0 =A0 =A0 =A0 0x224
>> +#define PECFG_ECDEVCAPPA =A0 =A0 =A0 0x25c
>>
>> =A0#define PECFG_PIMEN =A0 =A0 =A0 =A0 =A0 =A00x33c
>> =A0#define PECFG_PIM0LAL =A0 =A0 =A0 =A0 =A00x340
>> @@ -494,5 +496,7 @@ enum
>> =A0 =A0 =A0 =A0LNKW_X8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0x8
>> =A0};
>>
>> +/* Timout for reset phy */
>> +#define PCIE_PHY_RESET_TIMEOUT 10
>
> Is this value applicable to all the 44x devices with PCI-e?
> [Vinh Nguyen] At this time, we only checked this on APM821xx chips.
Then it should probably be conditionalized somehow. Or put as a
worst-case value that will work for them all.
[Vinh Nguyen] At this time, this definition is called in
apm821xx_pciex_init_port_hw function that is used only for apm821xx chip.
So I think it's ok, but as your recommendation, I'll check with various
boards that I have to get the best value and update it in next submitted
codes.
Best regards,
Vinh Nguyen.
^ permalink raw reply
* [PATCH] fsldma: fix performance degradation by optimizing spinlock use.
From: b29237 @ 2011-12-26 6:01 UTC (permalink / raw)
To: iws, vinod.koul, dan.j.williams, linuxppc-dev, linux-kernel; +Cc: Forrest shi
From: Forrest shi <b29237@freescale.com>
dma status check function fsl_tx_status is heavily called in
a tight loop and the desc lock in fsl_tx_status contended by
the dma status update function. this caused the dma performance
degrades much.
this patch releases the lock in the fsl_tx_status function, and
introduce the smp_mb() to avoid possible memory inconsistency.
Signed-off-by: Forrest Shi <xuelin.shi@freescale.com>
---
drivers/dma/fsldma.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 8a78154..008fb5e 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -986,15 +986,11 @@ static enum dma_status fsl_tx_status(struct dma_chan *dchan,
struct fsldma_chan *chan = to_fsl_chan(dchan);
dma_cookie_t last_complete;
dma_cookie_t last_used;
- unsigned long flags;
-
- spin_lock_irqsave(&chan->desc_lock, flags);
last_complete = chan->completed_cookie;
+ smp_mb();
last_used = dchan->cookie;
- spin_unlock_irqrestore(&chan->desc_lock, flags);
-
dma_set_tx_state(txstate, last_complete, last_used, 0);
return dma_async_is_complete(cookie, last_complete, last_used);
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 4/5] KVM: PPC: Book3s HV: Implement get_dirty_log using hardware changed bit
From: Takuya Yoshikawa @ 2011-12-26 5:05 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, Takuya Yoshikawa, Alexander Graf, kvm-ppc, KVM list
In-Reply-To: <20111225233524.GA5348@sammy.paulus.ozlabs.org>
(2011/12/26 8:35), Paul Mackerras wrote:
> On Fri, Dec 23, 2011 at 02:23:30PM +0100, Alexander Graf wrote:
>
>> So if I read things correctly, this is the only case you're setting
>> pages as dirty. What if you have the following:
>>
>> guest adds HTAB entry x
>> guest writes to page mapped by x
>> guest removes HTAB entry x
>> host fetches dirty log
>
> In that case the dirtiness is preserved in the setting of the
> KVMPPC_RMAP_CHANGED bit in the rmap entry. kvm_test_clear_dirty()
> returns 1 if that bit is set (and clears it). Using the rmap entry
> for this is convenient because (a) we also use it for saving the
> referenced bit when a HTAB entry is removed, and we can transfer both
> R and C over in one operation; (b) we need to be able to save away the
> C bit in real mode, and we already need to get the real-mode address
> of the rmap entry -- if we wanted to save it in a dirty bitmap we'd
> have to do an extra translation to get the real-mode address of the
> dirty bitmap word; (c) to avoid SMP races, if we were asynchronously
> setting bits in the dirty bitmap we'd have to do the double-buffering
> thing that x86 does, which seems more complicated than using the rmap
> entry (which we already have a lock bit for).
From my x86 dirty logging experience I have some concern about your code:
your code looks slow even when there is no/few dirty pages in the slot.
+ for (i = 0; i < memslot->npages; ++i) {
+ if (kvm_test_clear_dirty(kvm, rmapp))
+ __set_bit_le(i, map);
+ ++rmapp;
+ }
The check is being done for each page and this can be very expensive because
the number of pages is not small.
When we scan the dirty_bitmap 64 pages are checked at once and
the problem is not so significant.
Though I do not know well what kvm-ppc's dirty logging is aiming at, I guess
reporting cleanliness without noticeable delay to the user-space is important.
E.g. for VGA most of the cases are clean. For live migration, the
chance of seeing complete clean slot is small but almost all cases
are sparse.
>
>> PS: Always CC kvm@vger for stuff that other might want to review
>> (basically all patches)
(Though I sometimes check kvm-ppc on the archives,)
GET_DIRTY_LOG thing will be welcome.
Takuya
>
> So why do we have a separate kvm-ppc list then? :)
^ permalink raw reply
* Re: [PATCH 4/5] KVM: PPC: Book3s HV: Implement get_dirty_log using hardware changed bit
From: Paul Mackerras @ 2011-12-25 23:35 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <C59FE93D-AD1B-4382-BE8B-FF2DDD22930E@suse.de>
On Fri, Dec 23, 2011 at 02:23:30PM +0100, Alexander Graf wrote:
> So if I read things correctly, this is the only case you're setting
> pages as dirty. What if you have the following:
>
> guest adds HTAB entry x
> guest writes to page mapped by x
> guest removes HTAB entry x
> host fetches dirty log
In that case the dirtiness is preserved in the setting of the
KVMPPC_RMAP_CHANGED bit in the rmap entry. kvm_test_clear_dirty()
returns 1 if that bit is set (and clears it). Using the rmap entry
for this is convenient because (a) we also use it for saving the
referenced bit when a HTAB entry is removed, and we can transfer both
R and C over in one operation; (b) we need to be able to save away the
C bit in real mode, and we already need to get the real-mode address
of the rmap entry -- if we wanted to save it in a dirty bitmap we'd
have to do an extra translation to get the real-mode address of the
dirty bitmap word; (c) to avoid SMP races, if we were asynchronously
setting bits in the dirty bitmap we'd have to do the double-buffering
thing that x86 does, which seems more complicated than using the rmap
entry (which we already have a lock bit for).
> PS: Always CC kvm@vger for stuff that other might want to review
> (basically all patches)
So why do we have a separate kvm-ppc list then? :)
Paul.
^ permalink raw reply
* Re: p1020 unstable with 3.2
From: Alexander Graf @ 2011-12-25 10:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev, Fleming Andy-AFLEMING
In-Reply-To: <1324709633.6632.20.camel@pasglop>
On 24.12.2011, at 07:53, Benjamin Herrenschmidt wrote:
> On Fri, 2011-12-23 at 17:54 +0100, Alexander Graf wrote:
>> Hi guys,
>>
>> While trying to test my latest patch queue for ppc kvm, I realized
>> that even though the device trees got updated, the p1020 box still is
>> unstable. The trace below is the one I've seen the most. It only
>> occurs during network I/O which happens a lot on that box, since I'm
>> running it using NFS root.
>>
>> As for configuration, I use kumar's "merge" branch from today and the
>> p1020rdb.dts device tree provided in that tree.
>>
>> The last known good configuration I'm aware of is 3.0.
>>
>> Any ideas what's going wrong here?
>
> Try SLAB instead of SLUB and let me know. It -could- be a bogon in SLUB
> that should be fixed upstream now but I think did hit 3.2
Yup, things seem a lot more stable with SLAB now :).
Alex
^ permalink raw reply
* Re: [PATCH 00/14] DMA-mapping framework redesign preparation
From: Benjamin Herrenschmidt @ 2011-12-24 7:00 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-mips, linux-ia64, linux-sh, linux-mm, sparclinux,
Marek Szyprowski, linux-arch, Stephen Rothwell, Jonathan Corbet,
x86, Arnd Bergmann, microblaze-uclinux, linaro-mm-sig,
Andrzej Pietrasiewicz, Thomas Gleixner, linux-arm-kernel, discuss,
linux-kernel, Kyungmin Park, linux-alpha, Andrew Morton,
linuxppc-dev
In-Reply-To: <20111223163516.GO20129@parisc-linux.org>
On Fri, 2011-12-23 at 09:35 -0700, Matthew Wilcox wrote:
> I really think this wants to be a separate function.
> dma_alloc_coherent
> is for allocating memory to be shared between the kernel and a driver;
> we already have dma_map_sg for mapping userspace I/O as an alternative
> interface. This feels like it's something different again rather than
> an option to dma_alloc_coherent.
Depends. There can be some interesting issues with some of the ARM stuff
out there (and to a lesser extent older ppc embedded stuff).
For example, some devices really want a physically contiguous chunk, and
are not cache coherent. In that case, you can't keep the linear mapping
around. But you also don't waste your precious kernel virtual space
creating a separate non-cachable mapping for those.
In general, dma mapping attributes as a generic feature make sense,
whether this specific attribute does or not though. And we probably want
space for platform specific attributes, for example, FSL embedded
iommu's have "interesting" features for directing data toward a specific
core cache etc... that we might want to expose using such attributes.
Cheers,
Ben.
^ permalink raw reply
* Re: p1020 unstable with 3.2
From: Benjamin Herrenschmidt @ 2011-12-24 6:53 UTC (permalink / raw)
To: Alexander Graf; +Cc: Scott Wood, linuxppc-dev, Fleming Andy-AFLEMING
In-Reply-To: <0048E411-D82D-4EA4-B9BA-EF233AC6ED34@suse.de>
On Fri, 2011-12-23 at 17:54 +0100, Alexander Graf wrote:
> Hi guys,
>
> While trying to test my latest patch queue for ppc kvm, I realized
> that even though the device trees got updated, the p1020 box still is
> unstable. The trace below is the one I've seen the most. It only
> occurs during network I/O which happens a lot on that box, since I'm
> running it using NFS root.
>
> As for configuration, I use kumar's "merge" branch from today and the
> p1020rdb.dts device tree provided in that tree.
>
> The last known good configuration I'm aware of is 3.0.
>
> Any ideas what's going wrong here?
Try SLAB instead of SLUB and let me know. It -could- be a bogon in SLUB
that should be fixed upstream now but I think did hit 3.2
Cheers,
Ben.
> Alex
>
> ---
>
> Unable to handle kernel paging request for data at address 0x00000004
> Faulting instruction address: 0xc00eb38c
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=2 P1020 RDB
> Modules linked in:
> NIP: c00eb38c LR: c00eb278 CTR: c0340e48
> REGS: effedc70 TRAP: 0300 Not tainted
> (3.2.0-rc3-00013-gaca3173-dirty)
> MSR: 00021000 <ME,CE> CR: 28842422 XER: 00000000
> DEAR: 00000004, ESR: 00800000
> TASK = ef4bd900[4816] 'cc1' THREAD: ee4c4000 CPU: 0
> GPR00: 00004080 effedd20 ef4bd900 ef001180 c15e5700 ffffffff c03e7448
> 00100021
> GPR08: 00100020 00010001 00000000 00000000 28842442 10a3e610 00210d00
> 00200200
> GPR16: 00100100 00000001 c06d6748 ef002670 00000000 c03e7448 ffffffff
> 00000020
> GPR24: effec000 ffffffec 00029000 ef001188 00000000 ef002600 c18079e0
> ef001180
> NIP [c00eb38c] __slab_alloc+0x3d4/0x4f8
> LR [c00eb278] __slab_alloc+0x2c0/0x4f8
> Call Trace:
> [effedd20] [c06d6b78] hashrnd+0x0/0x4 (unreliable)
> [effeddc0] [c00eb680] __kmalloc_track_caller+0x1d0/0x200
> [effedde0] [c03e6064] __alloc_skb+0x74/0x150
> [effede00] [c03e7448] __netdev_alloc_skb+0x28/0x60
> [effede10] [c03408f0] gfar_new_skb+0x50/0x7c
> [effede20] [c0340acc] gfar_clean_rx_ring+0x1b0/0x52c
> [effede90] [c03412d0] gfar_poll+0x488/0x624
> [effedf60] [c03f062c] net_rx_action+0x140/0x1e8
> [effedfa0] [c0061aa0] __do_softirq+0x124/0x210
> [effedff0] [c000e0fc] call_do_softirq+0x14/0x24
> [ee4c5c40] [c000564c] do_softirq+0xb4/0xe0
> [ee4c5c60] [c006170c] irq_exit+0x94/0xb4
> [ee4c5c70] [c000591c] do_IRQ+0xb0/0x1ac
> [ee4c5ca0] [c000fc5c] ret_from_except+0x0/0x18
> --- Exception: 501 at do_lookup+0x118/0x3cc
> LR = do_lookup+0xec/0x3cc
> [ee4c5db0] [c00ff898] link_path_walk+0x308/0xc78
> [ee4c5e30] [c0103cb0] path_openat+0xc8/0x3ec
> [ee4c5e90] [c01040f4] do_filp_open+0x44/0xb0
> [ee4c5f10] [c00efcf8] do_sys_open+0x198/0x24c
> [ee4c5f40] [c000f604] ret_from_syscall+0x0/0x3c
> --- Exception: c01 at 0xfdb6658
> LR = 0xfe50be8
> Instruction dump:
> 8004000c 7f880000 409effa8 91240008 9164000c 7c0004ac 80040000
> 2f8a0000
> 81240018 81640014 5400003c 90040000 <912b0004> 91690000 92040014
> 91e40018
> Kernel panic - not syncing: Fatal exception in interrupt
> Rebooting in 180 seconds..
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH 8/9] arch/powerpc/sysdev/fsl_rmu.c: introduce missing kfree
From: Julia Lawall @ 2011-12-23 17:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree-discuss, kernel-janitors, linux-kernel, Rob Herring,
Paul Mackerras, linuxppc-dev
rmu needs to be freed before leaving the function in an error case.
A simplified version of the semantic match that finds the problem is as
follows: (http://coccinelle.lip6.fr)
// <smpl>
@r exists@
local idexpression x;
statement S;
identifier f1;
position p1,p2;
expression *ptr != NULL;
@@
x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
x->f1
...>
(
return \(0\|<+...x...+>\|ptr\);
|
return@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/sysdev/fsl_rmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/fsl_rmu.c b/arch/powerpc/sysdev/fsl_rmu.c
index 02445a5..1548578 100644
--- a/arch/powerpc/sysdev/fsl_rmu.c
+++ b/arch/powerpc/sysdev/fsl_rmu.c
@@ -1081,6 +1081,7 @@ int fsl_rio_setup_rmu(struct rio_mport *mport, struct device_node *node)
if (!msg_addr) {
pr_err("%s: unable to find 'reg' property of message-unit\n",
node->full_name);
+ kfree(rmu);
return -ENOMEM;
}
msg_start = of_read_number(msg_addr, aw);
^ permalink raw reply related
* p1020 unstable with 3.2
From: Alexander Graf @ 2011-12-23 16:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Fleming Andy-AFLEMING
Hi guys,
While trying to test my latest patch queue for ppc kvm, I realized that =
even though the device trees got updated, the p1020 box still is =
unstable. The trace below is the one I've seen the most. It only occurs =
during network I/O which happens a lot on that box, since I'm running it =
using NFS root.
As for configuration, I use kumar's "merge" branch from today and the =
p1020rdb.dts device tree provided in that tree.
The last known good configuration I'm aware of is 3.0.
Any ideas what's going wrong here?
Alex
---
Unable to handle kernel paging request for data at address 0x00000004
Faulting instruction address: 0xc00eb38c
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=3D2 P1020 RDB
Modules linked in:
NIP: c00eb38c LR: c00eb278 CTR: c0340e48
REGS: effedc70 TRAP: 0300 Not tainted =
(3.2.0-rc3-00013-gaca3173-dirty)
MSR: 00021000 <ME,CE> CR: 28842422 XER: 00000000
DEAR: 00000004, ESR: 00800000
TASK =3D ef4bd900[4816] 'cc1' THREAD: ee4c4000 CPU: 0
GPR00: 00004080 effedd20 ef4bd900 ef001180 c15e5700 ffffffff c03e7448 =
00100021=20
GPR08: 00100020 00010001 00000000 00000000 28842442 10a3e610 00210d00 =
00200200=20
GPR16: 00100100 00000001 c06d6748 ef002670 00000000 c03e7448 ffffffff =
00000020=20
GPR24: effec000 ffffffec 00029000 ef001188 00000000 ef002600 c18079e0 =
ef001180=20
NIP [c00eb38c] __slab_alloc+0x3d4/0x4f8
LR [c00eb278] __slab_alloc+0x2c0/0x4f8
Call Trace:
[effedd20] [c06d6b78] hashrnd+0x0/0x4 (unreliable)
[effeddc0] [c00eb680] __kmalloc_track_caller+0x1d0/0x200
[effedde0] [c03e6064] __alloc_skb+0x74/0x150
[effede00] [c03e7448] __netdev_alloc_skb+0x28/0x60
[effede10] [c03408f0] gfar_new_skb+0x50/0x7c
[effede20] [c0340acc] gfar_clean_rx_ring+0x1b0/0x52c
[effede90] [c03412d0] gfar_poll+0x488/0x624
[effedf60] [c03f062c] net_rx_action+0x140/0x1e8
[effedfa0] [c0061aa0] __do_softirq+0x124/0x210
[effedff0] [c000e0fc] call_do_softirq+0x14/0x24
[ee4c5c40] [c000564c] do_softirq+0xb4/0xe0
[ee4c5c60] [c006170c] irq_exit+0x94/0xb4
[ee4c5c70] [c000591c] do_IRQ+0xb0/0x1ac
[ee4c5ca0] [c000fc5c] ret_from_except+0x0/0x18
--- Exception: 501 at do_lookup+0x118/0x3cc
LR =3D do_lookup+0xec/0x3cc
[ee4c5db0] [c00ff898] link_path_walk+0x308/0xc78
[ee4c5e30] [c0103cb0] path_openat+0xc8/0x3ec
[ee4c5e90] [c01040f4] do_filp_open+0x44/0xb0
[ee4c5f10] [c00efcf8] do_sys_open+0x198/0x24c
[ee4c5f40] [c000f604] ret_from_syscall+0x0/0x3c
--- Exception: c01 at 0xfdb6658
LR =3D 0xfe50be8
Instruction dump:
8004000c 7f880000 409effa8 91240008 9164000c 7c0004ac 80040000 2f8a0000=20=
81240018 81640014 5400003c 90040000 <912b0004> 91690000 92040014 =
91e40018=20
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 180 seconds..=
^ permalink raw reply
* Re: [PATCH 00/14] DMA-mapping framework redesign preparation
From: Matthew Wilcox @ 2011-12-23 16:35 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-mips, linux-ia64, linux-sh, linux-mm, sparclinux,
linux-arch, Stephen Rothwell, Jonathan Corbet, x86, Arnd Bergmann,
microblaze-uclinux, linaro-mm-sig, Andrzej Pietrasiewicz,
Thomas Gleixner, linux-arm-kernel, discuss, linux-kernel,
Kyungmin Park, linux-alpha, Andrew Morton, linuxppc-dev
In-Reply-To: <1324643253-3024-1-git-send-email-m.szyprowski@samsung.com>
On Fri, Dec 23, 2011 at 01:27:19PM +0100, Marek Szyprowski wrote:
> The first issue we identified is the fact that on some platform (again,
> mainly ARM) there are several functions for allocating DMA buffers:
> dma_alloc_coherent, dma_alloc_writecombine and dma_alloc_noncoherent
Is this write-combining from the point of view of the device (ie iommu),
or from the point of view of the CPU, or both?
> The next step in dma mapping framework update is the introduction of
> dma_mmap/dma_mmap_attrs() function. There are a number of drivers
> (mainly V4L2 and ALSA) that only exports the DMA buffers to user space.
> Creating a userspace mapping with correct page attributes is not an easy
> task for the driver. Also the DMA-mapping framework is the only place
> where the complete information about the allocated pages is available,
> especially if the implementation uses IOMMU controller to provide a
> contiguous buffer in DMA address space which is scattered in physical
> memory space.
Surely we only need a helper which drivrs can call from their mmap routine to solve this?
> Usually these drivers don't touch the buffer data at all, so the mapping
> in kernel virtual address space is not needed. We can introduce
> DMA_ATTRIB_NO_KERNEL_MAPPING attribute which lets kernel to skip/ignore
> creation of kernel virtual mapping. This way we can save previous
> vmalloc area and simply some mapping operation on a few architectures.
I really think this wants to be a separate function. dma_alloc_coherent
is for allocating memory to be shared between the kernel and a driver;
we already have dma_map_sg for mapping userspace I/O as an alternative
interface. This feels like it's something different again rather than
an option to dma_alloc_coherent.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Kernel not booting when supplying boot parameter mem
From: Arshad, Farrukh @ 2011-12-23 15:07 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 691 bytes --]
Greetings All,
I have a basic question. I have 512 MB memory. I want my kernel to use only last 128 MB of memory starting from address 0x10000000. I have configured the kernel CONFIG_PHYSICAL_START=0x10000000 and in kernel boot parameter I have set mem=128M. In this scenario my kernel is not booting and it just stuck after uncompressing it. If I do not provide mem=128M boot parameter my kernel boots fine, but in that case I can not restrict kernel to use only 128M memory. Why supplying mem=128M causing kernel to fail.
Best Regards
Farrukh Arshad
Sr. Software Development Engineer
Mentor Graphics Pakistan
Ph: +92 - 423 - 609 - 92 - 09
Cell: +92 - 303 - 444 - 77 - 05
[-- Attachment #2: Type: text/html, Size: 3301 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] Make use of hardware reference and change bits in HPT
From: Alexander Graf @ 2011-12-23 13:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <20111215120018.GA20629@bloggs.ozlabs.ibm.com>
On 15.12.2011, at 13:00, Paul Mackerras wrote:
> This series of patches builds on top of my previous series and
> modifies the Book3S HV memory management code to use the hardware
> reference and change bits in the guest hashed page table. This makes
> kvm_age_hva() more efficient, lets us implement the dirty page
> tracking properly (which in turn means that things like VGA emulation
> in qemu can work), and also means that we can supply hardware
> reference and change information to the guest -- not that Linux guests
> currently use that information, but possibly they will want it in
> future, and there is an interface defined in PAPR for it.
I applied Patches 1-4 to kvm-ppc-next.
Alex
^ permalink raw reply
* Re: [PATCH] arch/powerpc/kvm/e500: Additional module.h => export.h fixup
From: Alexander Graf @ 2011-12-23 13:35 UTC (permalink / raw)
To: Kyle Moffett
Cc: KVM list, Marcelo Tosatti, linux-kernel@vger.kernel.org List,
kvm-ppc, Paul Mackerras, Avi Kivity, Scott Wood, linuxppc-dev
In-Reply-To: <1324570863-11447-1-git-send-email-Kyle.D.Moffett@boeing.com>
On 22.12.2011, at 17:21, Kyle Moffett wrote:
> This file, like many others, needs to include <linux/export.h>.
>
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
Thanks, I already applied a patch from Scott that addresses the same issue.
Alex
^ permalink raw reply
* Re: [PATCH] KVM: Move gfn_to_memslot() to kvm_host.h
From: Alexander Graf @ 2011-12-23 13:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, KVM list, kvm-ppc, Avi Kivity
In-Reply-To: <20111220092102.GA5626@bloggs.ozlabs.ibm.com>
On 20.12.2011, at 10:21, Paul Mackerras wrote:
> This moves gfn_to_memslot(), and the functions it calls, that is,
> search_memslots() and __gfn_to_memslot(), from kvm_main.c to kvm_host.h
> so that gfn_to_memslot() can be called from non-modular code even
> when KVM is a module. On powerpc, the Book3S HV style of KVM has
> code that is called from real mode which needs to call gfn_to_memslot()
> and thus needs this. (Module code is allocated in the vmalloc region,
> which can't be accessed in real mode.)
>
> With this, we can remove builtin_gfn_to_memslot() from book3s_hv_rm_mmu.c
> and thus eliminate a little bit of duplication.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
Avi, please ack.
Alex
^ permalink raw reply
* Re: [PATCH 5/5] KVM: PPC: Book3s HV: Implement H_CLEAR_REF and H_CLEAR_MOD hcalls
From: Alexander Graf @ 2011-12-23 13:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <20111215120417.GF20629@bloggs.ozlabs.ibm.com>
On 15.12.2011, at 13:04, Paul Mackerras wrote:
> This adds implementations for the H_CLEAR_REF (test and clear =
reference
> bit) and H_CLEAR_MOD (test and clear changed bit) hypercalls. These
> hypercalls are not used by Linux guests at this stage, and these
> implementations are only compile tested.
Do we need them then? Are they mandatory in PAPR? I don't feel all that =
great having unused / untested code accessible from the guest.
Alex
^ permalink raw reply
* Re: [PATCH 4/5] KVM: PPC: Book3s HV: Implement get_dirty_log using hardware changed bit
From: Alexander Graf @ 2011-12-23 13:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <20111215120322.GE20629@bloggs.ozlabs.ibm.com>
On 15.12.2011, at 13:03, Paul Mackerras wrote:
> This changes the implementation of kvm_vm_ioctl_get_dirty_log() for
> Book3s HV guests to use the hardware C (changed) bits in the guest
> hashed page table. Since this makes the implementation quite =
different
> from the Book3s PR case, this moves the existing implementation from
> book3s.c to book3s_pr.c and creates a new implementation in =
book3s_hv.c.
> That implementation calls kvmppc_hv_get_dirty_log() to do the actual
> work by calling kvm_test_clear_dirty on each page. It iterates over
> the HPTEs, clearing the C bit if set, and returns 1 if any C bit was
> set (including the saved C bit in the rmap entry).
>=20
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> arch/powerpc/include/asm/kvm_book3s.h | 2 +
> arch/powerpc/kvm/book3s.c | 39 ------------------
> arch/powerpc/kvm/book3s_64_mmu_hv.c | 69 =
+++++++++++++++++++++++++++++++++
> arch/powerpc/kvm/book3s_hv.c | 37 +++++++++++++++++
> arch/powerpc/kvm/book3s_pr.c | 39 ++++++++++++++++++
> 5 files changed, 147 insertions(+), 39 deletions(-)
>=20
> diff --git a/arch/powerpc/include/asm/kvm_book3s.h =
b/arch/powerpc/include/asm/kvm_book3s.h
> index 6ececb4..aa795cc 100644
> --- a/arch/powerpc/include/asm/kvm_book3s.h
> +++ b/arch/powerpc/include/asm/kvm_book3s.h
> @@ -158,6 +158,8 @@ extern long kvmppc_virtmode_h_enter(struct =
kvm_vcpu *vcpu, unsigned long flags,
> long pte_index, unsigned long pteh, unsigned =
long ptel);
> extern long kvmppc_h_enter(struct kvm_vcpu *vcpu, unsigned long flags,
> long pte_index, unsigned long pteh, unsigned =
long ptel);
> +extern long kvmppc_hv_get_dirty_log(struct kvm *kvm,
> + struct kvm_memory_slot *memslot);
>=20
> extern void kvmppc_entry_trampoline(void);
> extern void kvmppc_hv_entry_trampoline(void);
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index 6bf7e05..7d54f4e 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -477,45 +477,6 @@ int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu =
*vcpu,
> return 0;
> }
>=20
> -/*
> - * Get (and clear) the dirty memory log for a memory slot.
> - */
> -int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm,
> - struct kvm_dirty_log *log)
> -{
> - struct kvm_memory_slot *memslot;
> - struct kvm_vcpu *vcpu;
> - ulong ga, ga_end;
> - int is_dirty =3D 0;
> - int r;
> - unsigned long n;
> -
> - mutex_lock(&kvm->slots_lock);
> -
> - r =3D kvm_get_dirty_log(kvm, log, &is_dirty);
> - if (r)
> - goto out;
> -
> - /* If nothing is dirty, don't bother messing with page tables. =
*/
> - if (is_dirty) {
> - memslot =3D id_to_memslot(kvm->memslots, log->slot);
> -
> - ga =3D memslot->base_gfn << PAGE_SHIFT;
> - ga_end =3D ga + (memslot->npages << PAGE_SHIFT);
> -
> - kvm_for_each_vcpu(n, vcpu, kvm)
> - kvmppc_mmu_pte_pflush(vcpu, ga, ga_end);
> -
> - n =3D kvm_dirty_bitmap_bytes(memslot);
> - memset(memslot->dirty_bitmap, 0, n);
> - }
> -
> - r =3D 0;
> -out:
> - mutex_unlock(&kvm->slots_lock);
> - return r;
> -}
> -
> void kvmppc_decrementer_func(unsigned long data)
> {
> struct kvm_vcpu *vcpu =3D (struct kvm_vcpu *)data;
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c =
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index 926e2b9..783cd35 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> @@ -870,6 +870,75 @@ void kvm_set_spte_hva(struct kvm *kvm, unsigned =
long hva, pte_t pte)
> kvm_handle_hva(kvm, hva, kvm_unmap_rmapp);
> }
>=20
> +static int kvm_test_clear_dirty(struct kvm *kvm, unsigned long =
*rmapp)
> +{
> + struct revmap_entry *rev =3D kvm->arch.revmap;
> + unsigned long head, i, j;
> + unsigned long *hptep;
> + int ret =3D 0;
> +
> + retry:
> + lock_rmap(rmapp);
> + if (*rmapp & KVMPPC_RMAP_CHANGED) {
> + *rmapp &=3D ~KVMPPC_RMAP_CHANGED;
> + ret =3D 1;
> + }
> + if (!(*rmapp & KVMPPC_RMAP_PRESENT)) {
> + unlock_rmap(rmapp);
> + return ret;
> + }
> +
> + i =3D head =3D *rmapp & KVMPPC_RMAP_INDEX;
> + do {
> + hptep =3D (unsigned long *) (kvm->arch.hpt_virt + (i << =
4));
> + j =3D rev[i].forw;
> +
> + if (!(hptep[1] & HPTE_R_C))
> + continue;
> +
> + if (!try_lock_hpte(hptep, HPTE_V_HVLOCK)) {
> + /* unlock rmap before spinning on the HPTE lock =
*/
> + unlock_rmap(rmapp);
> + while (hptep[0] & HPTE_V_HVLOCK)
> + cpu_relax();
> + goto retry;
> + }
> +
> + /* Now check and modify the HPTE */
> + if ((hptep[0] & HPTE_V_VALID) && (hptep[1] & HPTE_R_C)) =
{
> + /* need to make it temporarily absent to clear C =
*/
> + hptep[0] |=3D HPTE_V_ABSENT;
> + kvmppc_invalidate_hpte(kvm, hptep, i);
> + hptep[1] &=3D ~HPTE_R_C;
> + eieio();
> + hptep[0] =3D (hptep[0] & ~HPTE_V_ABSENT) | =
HPTE_V_VALID;
> + rev[i].guest_rpte |=3D HPTE_R_C;
> + ret =3D 1;
> + }
> + hptep[0] &=3D ~HPTE_V_HVLOCK;
> + } while ((i =3D j) !=3D head);
> +
> + unlock_rmap(rmapp);
> + return ret;
> +}
> +
> +long kvmppc_hv_get_dirty_log(struct kvm *kvm, struct kvm_memory_slot =
*memslot)
> +{
> + unsigned long i;
> + unsigned long *rmapp, *map;
> +
> + preempt_disable();
> + rmapp =3D memslot->rmap;
> + map =3D memslot->dirty_bitmap;
> + for (i =3D 0; i < memslot->npages; ++i) {
> + if (kvm_test_clear_dirty(kvm, rmapp))
> + __set_bit_le(i, map);
So if I read things correctly, this is the only case you're setting =
pages as dirty. What if you have the following:
guest adds HTAB entry x
guest writes to page mapped by x
guest removes HTAB entry x
host fetches dirty log
You can replace "removes" by "is overwritten by another mapping" if you =
like.
Alex
PS: Always CC kvm@vger for stuff that other might want to review =
(basically all patches)
^ permalink raw reply
* [PATCH 14/14] common: DMA-mapping: add NON-CONSISTENT attribute
From: Marek Szyprowski @ 2011-12-23 12:27 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, linux-ia64, linux-sh, linux-mm, sparclinux,
Marek Szyprowski, linux-arch, Stephen Rothwell, Jonathan Corbet,
x86, Arnd Bergmann, microblaze-uclinux, linaro-mm-sig,
Andrzej Pietrasiewicz, Thomas Gleixner, linux-arm-kernel, discuss,
Kyungmin Park, linux-alpha, Andrew Morton, linuxppc-dev
In-Reply-To: <1324643253-3024-1-git-send-email-m.szyprowski@samsung.com>
DMA_ATTR_NON_CONSISTENT lets the platform to choose to return either
consistent or non-consistent memory as it sees fit. By using this API,
you are guaranteeing to the platform that you have all the correct and
necessary sync points for this memory in the driver should it choose to
return non-consistent memory.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
Documentation/DMA-attributes.txt | 9 +++++++++
include/linux/dma-attrs.h | 1 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index 811a5d4..9120de2 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -41,3 +41,12 @@ buffered to improve performance.
Since it is optional for platforms to implement DMA_ATTR_WRITE_COMBINE,
those that do not will simply ignore the attribute and exhibit default
behavior.
+
+DMA_ATTR_NON_CONSISTENT
+-----------------------
+
+DMA_ATTR_NON_CONSISTENT lets the platform to choose to return either
+consistent or non-consistent memory as it sees fit. By using this API,
+you are guaranteeing to the platform that you have all the correct and
+necessary sync points for this memory in the driver should it choose to
+return non-consistent memory.
diff --git a/include/linux/dma-attrs.h b/include/linux/dma-attrs.h
index ada61e1..547ab56 100644
--- a/include/linux/dma-attrs.h
+++ b/include/linux/dma-attrs.h
@@ -14,6 +14,7 @@ enum dma_attr {
DMA_ATTR_WRITE_BARRIER,
DMA_ATTR_WEAK_ORDERING,
DMA_ATTR_WRITE_COMBINE,
+ DMA_ATTR_NON_CONSISTENT,
DMA_ATTR_MAX,
};
--
1.7.1.569.g6f426
^ permalink raw reply related
* [PATCH 10/14] Unicore32: adapt for dma_map_ops changes
From: Marek Szyprowski @ 2011-12-23 12:27 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, linux-ia64, linux-sh, linux-mm, sparclinux,
Marek Szyprowski, linux-arch, Stephen Rothwell, Jonathan Corbet,
x86, Arnd Bergmann, microblaze-uclinux, linaro-mm-sig,
Andrzej Pietrasiewicz, Thomas Gleixner, linux-arm-kernel, discuss,
Kyungmin Park, linux-alpha, Andrew Morton, linuxppc-dev
In-Reply-To: <1324643253-3024-1-git-send-email-m.szyprowski@samsung.com>
From: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Adapt core Unicore32 architecture code for dma_map_ops changes: replace
alloc/free_coherent with generic alloc/free methods.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
arch/unicore32/include/asm/dma-mapping.h | 18 ++++++++++++------
arch/unicore32/mm/dma-swiotlb.c | 4 ++--
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/unicore32/include/asm/dma-mapping.h b/arch/unicore32/include/asm/dma-mapping.h
index 9258e59..366460a 100644
--- a/arch/unicore32/include/asm/dma-mapping.h
+++ b/arch/unicore32/include/asm/dma-mapping.h
@@ -82,20 +82,26 @@ static inline int dma_set_mask(struct device *dev, u64 dma_mask)
return 0;
}
-static inline void *dma_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t flag)
+#define dma_alloc_coherent(d,s,h,f) dma_alloc_attrs(d,s,h,f,NULL)
+
+static inline void *dma_alloc_attrs(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag,
+ struct dma_attrs *attrs)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
- return dma_ops->alloc_coherent(dev, size, dma_handle, flag);
+ return dma_ops->alloc(dev, size, dma_handle, flag, attrs);
}
-static inline void dma_free_coherent(struct device *dev, size_t size,
- void *cpu_addr, dma_addr_t dma_handle)
+#define dma_free_coherent(d,s,c,h) dma_free_attrs(d,s,c,h,NULL)
+
+static inline void dma_free_attrs(struct device *dev, size_t size,
+ void *cpu_addr, dma_addr_t dma_handle,
+ struct dma_attrs *attrs)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
- dma_ops->free_coherent(dev, size, cpu_addr, dma_handle);
+ dma_ops->free(dev, size, cpu_addr, dma_handle, attrs);
}
#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
diff --git a/arch/unicore32/mm/dma-swiotlb.c b/arch/unicore32/mm/dma-swiotlb.c
index bfa9fbb..ff70c2d 100644
--- a/arch/unicore32/mm/dma-swiotlb.c
+++ b/arch/unicore32/mm/dma-swiotlb.c
@@ -18,8 +18,8 @@
#include <asm/dma.h>
struct dma_map_ops swiotlb_dma_map_ops = {
- .alloc_coherent = swiotlb_alloc_coherent,
- .free_coherent = swiotlb_free_coherent,
+ .alloc = swiotlb_alloc_coherent,
+ .free = swiotlb_free_coherent,
.map_sg = swiotlb_map_sg_attrs,
.unmap_sg = swiotlb_unmap_sg_attrs,
.dma_supported = swiotlb_dma_supported,
--
1.7.1.569.g6f426
^ permalink raw reply related
* [PATCH 11/14] common: dma-mapping: remove old alloc_coherent and free_coherent methods
From: Marek Szyprowski @ 2011-12-23 12:27 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, linux-ia64, linux-sh, linux-mm, sparclinux,
Marek Szyprowski, linux-arch, Stephen Rothwell, Jonathan Corbet,
x86, Arnd Bergmann, microblaze-uclinux, linaro-mm-sig,
Andrzej Pietrasiewicz, Thomas Gleixner, linux-arm-kernel, discuss,
Kyungmin Park, linux-alpha, Andrew Morton, linuxppc-dev
In-Reply-To: <1324643253-3024-1-git-send-email-m.szyprowski@samsung.com>
Remove old, unused alloc_coherent and free_coherent methods from
dma_map_ops structure.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
include/linux/dma-mapping.h | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 8cc7f95..2fc413a 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -9,10 +9,6 @@
#include <linux/scatterlist.h>
struct dma_map_ops {
- void* (*alloc_coherent)(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t gfp);
- void (*free_coherent)(struct device *dev, size_t size,
- void *vaddr, dma_addr_t dma_handle);
void* (*alloc)(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp,
struct dma_attrs *attrs);
--
1.7.1.569.g6f426
^ permalink raw reply related
* [PATCH 06/14] SPARC: adapt for dma_map_ops changes
From: Marek Szyprowski @ 2011-12-23 12:27 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, linux-ia64, linux-sh, linux-mm, sparclinux,
Marek Szyprowski, linux-arch, Stephen Rothwell, Jonathan Corbet,
x86, Arnd Bergmann, microblaze-uclinux, linaro-mm-sig,
Andrzej Pietrasiewicz, Thomas Gleixner, linux-arm-kernel, discuss,
Kyungmin Park, linux-alpha, Andrew Morton, linuxppc-dev
In-Reply-To: <1324643253-3024-1-git-send-email-m.szyprowski@samsung.com>
From: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Adapt core SPARC architecture code for dma_map_ops changes: replace
alloc/free_coherent with generic alloc/free methods.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
arch/sparc/include/asm/dma-mapping.h | 18 ++++++++++++------
arch/sparc/kernel/iommu.c | 10 ++++++----
arch/sparc/kernel/ioport.c | 18 ++++++++++--------
arch/sparc/kernel/pci_sun4v.c | 9 +++++----
4 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/arch/sparc/include/asm/dma-mapping.h b/arch/sparc/include/asm/dma-mapping.h
index 8c0e4f7..48a7c65 100644
--- a/arch/sparc/include/asm/dma-mapping.h
+++ b/arch/sparc/include/asm/dma-mapping.h
@@ -26,24 +26,30 @@ static inline struct dma_map_ops *get_dma_ops(struct device *dev)
#include <asm-generic/dma-mapping-common.h>
-static inline void *dma_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t flag)
+#define dma_alloc_coherent(d,s,h,f) dma_alloc_attrs(d,s,h,f,NULL)
+
+static inline void *dma_alloc_attrs(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag,
+ struct dma_attrs *attrs)
{
struct dma_map_ops *ops = get_dma_ops(dev);
void *cpu_addr;
- cpu_addr = ops->alloc_coherent(dev, size, dma_handle, flag);
+ cpu_addr = ops->alloc(dev, size, dma_handle, flag, attrs);
debug_dma_alloc_coherent(dev, size, *dma_handle, cpu_addr);
return cpu_addr;
}
-static inline void dma_free_coherent(struct device *dev, size_t size,
- void *cpu_addr, dma_addr_t dma_handle)
+#define dma_free_coherent(d,s,c,h) dma_free_attrs(d,s,c,h,NULL)
+
+static inline void dma_free_attrs(struct device *dev, size_t size,
+ void *cpu_addr, dma_addr_t dma_handle,
+ struct dma_attrs *attrs)
{
struct dma_map_ops *ops = get_dma_ops(dev);
debug_dma_free_coherent(dev, size, cpu_addr, dma_handle);
- ops->free_coherent(dev, size, cpu_addr, dma_handle);
+ ops->free(dev, size, cpu_addr, dma_handle, attrs);
}
static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
diff --git a/arch/sparc/kernel/iommu.c b/arch/sparc/kernel/iommu.c
index 4643d68..070ed14 100644
--- a/arch/sparc/kernel/iommu.c
+++ b/arch/sparc/kernel/iommu.c
@@ -280,7 +280,8 @@ static inline void iommu_free_ctx(struct iommu *iommu, int ctx)
}
static void *dma_4u_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t *dma_addrp, gfp_t gfp)
+ dma_addr_t *dma_addrp, gfp_t gfp,
+ struct dma_attrs *attrs)
{
unsigned long flags, order, first_page;
struct iommu *iommu;
@@ -330,7 +331,8 @@ static void *dma_4u_alloc_coherent(struct device *dev, size_t size,
}
static void dma_4u_free_coherent(struct device *dev, size_t size,
- void *cpu, dma_addr_t dvma)
+ void *cpu, dma_addr_t dvma,
+ struct dma_attrs *attrs)
{
struct iommu *iommu;
unsigned long flags, order, npages;
@@ -825,8 +827,8 @@ static void dma_4u_sync_sg_for_cpu(struct device *dev,
}
static struct dma_map_ops sun4u_dma_ops = {
- .alloc_coherent = dma_4u_alloc_coherent,
- .free_coherent = dma_4u_free_coherent,
+ .alloc = dma_4u_alloc_coherent,
+ .free = dma_4u_free_coherent,
.map_page = dma_4u_map_page,
.unmap_page = dma_4u_unmap_page,
.map_sg = dma_4u_map_sg,
diff --git a/arch/sparc/kernel/ioport.c b/arch/sparc/kernel/ioport.c
index d0479e2..21bd739 100644
--- a/arch/sparc/kernel/ioport.c
+++ b/arch/sparc/kernel/ioport.c
@@ -261,7 +261,8 @@ EXPORT_SYMBOL(sbus_set_sbus64);
* CPU may access them without any explicit flushing.
*/
static void *sbus_alloc_coherent(struct device *dev, size_t len,
- dma_addr_t *dma_addrp, gfp_t gfp)
+ dma_addr_t *dma_addrp, gfp_t gfp,
+ struct dma_attrs *attrs)
{
struct platform_device *op = to_platform_device(dev);
unsigned long len_total = PAGE_ALIGN(len);
@@ -315,7 +316,7 @@ err_nopages:
}
static void sbus_free_coherent(struct device *dev, size_t n, void *p,
- dma_addr_t ba)
+ dma_addr_t ba, struct dma_attrs *attrs)
{
struct resource *res;
struct page *pgv;
@@ -407,8 +408,8 @@ static void sbus_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
}
struct dma_map_ops sbus_dma_ops = {
- .alloc_coherent = sbus_alloc_coherent,
- .free_coherent = sbus_free_coherent,
+ .alloc = sbus_alloc_coherent,
+ .free = sbus_free_coherent,
.map_page = sbus_map_page,
.unmap_page = sbus_unmap_page,
.map_sg = sbus_map_sg,
@@ -436,7 +437,8 @@ arch_initcall(sparc_register_ioport);
* hwdev should be valid struct pci_dev pointer for PCI devices.
*/
static void *pci32_alloc_coherent(struct device *dev, size_t len,
- dma_addr_t *pba, gfp_t gfp)
+ dma_addr_t *pba, gfp_t gfp,
+ struct dma_attrs *attrs)
{
unsigned long len_total = PAGE_ALIGN(len);
void *va;
@@ -489,7 +491,7 @@ err_nopages:
* past this call are illegal.
*/
static void pci32_free_coherent(struct device *dev, size_t n, void *p,
- dma_addr_t ba)
+ dma_addr_t ba, struct dma_attrs *attrs)
{
struct resource *res;
@@ -645,8 +647,8 @@ static void pci32_sync_sg_for_device(struct device *device, struct scatterlist *
}
struct dma_map_ops pci32_dma_ops = {
- .alloc_coherent = pci32_alloc_coherent,
- .free_coherent = pci32_free_coherent,
+ .alloc = pci32_alloc_coherent,
+ .free = pci32_free_coherent,
.map_page = pci32_map_page,
.unmap_page = pci32_unmap_page,
.map_sg = pci32_map_sg,
diff --git a/arch/sparc/kernel/pci_sun4v.c b/arch/sparc/kernel/pci_sun4v.c
index b272cda..a8756e3 100644
--- a/arch/sparc/kernel/pci_sun4v.c
+++ b/arch/sparc/kernel/pci_sun4v.c
@@ -128,7 +128,8 @@ static inline long iommu_batch_end(void)
}
static void *dma_4v_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t *dma_addrp, gfp_t gfp)
+ dma_addr_t *dma_addrp, gfp_t gfp,
+ struct dma_attrs *attrs)
{
unsigned long flags, order, first_page, npages, n;
struct iommu *iommu;
@@ -198,7 +199,7 @@ range_alloc_fail:
}
static void dma_4v_free_coherent(struct device *dev, size_t size, void *cpu,
- dma_addr_t dvma)
+ dma_addr_t dvma, struct dma_attrs *attrs)
{
struct pci_pbm_info *pbm;
struct iommu *iommu;
@@ -527,8 +528,8 @@ static void dma_4v_unmap_sg(struct device *dev, struct scatterlist *sglist,
}
static struct dma_map_ops sun4v_dma_ops = {
- .alloc_coherent = dma_4v_alloc_coherent,
- .free_coherent = dma_4v_free_coherent,
+ .alloc = dma_4v_alloc_coherent,
+ .free = dma_4v_free_coherent,
.map_page = dma_4v_map_page,
.unmap_page = dma_4v_unmap_page,
.map_sg = dma_4v_map_sg,
--
1.7.1.569.g6f426
^ permalink raw reply related
* [PATCH 12/14] common: dma-mapping: introduce mmap method
From: Marek Szyprowski @ 2011-12-23 12:27 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, linux-ia64, linux-sh, linux-mm, sparclinux,
Marek Szyprowski, linux-arch, Stephen Rothwell, Jonathan Corbet,
x86, Arnd Bergmann, microblaze-uclinux, linaro-mm-sig,
Andrzej Pietrasiewicz, Thomas Gleixner, linux-arm-kernel, discuss,
Kyungmin Park, linux-alpha, Andrew Morton, linuxppc-dev
In-Reply-To: <1324643253-3024-1-git-send-email-m.szyprowski@samsung.com>
Introduce new generic mmap method with attributes argument.
This method lets drivers to create a userspace mapping for a DMA buffer
in generic, architecture independent way.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
include/linux/dma-mapping.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 2fc413a..b903a20 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -15,6 +15,9 @@ struct dma_map_ops {
void (*free)(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle,
struct dma_attrs *attrs);
+ int (*mmap)(struct device *, struct vm_area_struct *,
+ void *, dma_addr_t, size_t, struct dma_attrs *attrs);
+
dma_addr_t (*map_page)(struct device *dev, struct page *page,
unsigned long offset, size_t size,
enum dma_data_direction dir,
--
1.7.1.569.g6f426
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox