* [PATCH 47/51] ARM: 7794/1: block: Rename parameter dma_mask to max_addr for blk_queue_bounce_limit()
From: Russell King @ 2013-09-19 23:40 UTC (permalink / raw)
To: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel
Cc: Jens Axboe
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
The blk_queue_bounce_limit() API parameter 'dma_mask' is actually the
maximum address the device can handle rather than a dma_mask. Rename
it accordingly to avoid it being interpreted as dma_mask.
No functional change.
The idea is to fix the bad assumptions about dma_mask wherever it could
be miss-interpreted.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
block/blk-settings.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/block/blk-settings.c b/block/blk-settings.c
index c50ecf0..026c151 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -195,17 +195,17 @@ EXPORT_SYMBOL(blk_queue_make_request);
/**
* blk_queue_bounce_limit - set bounce buffer limit for queue
* @q: the request queue for the device
- * @dma_mask: the maximum address the device can handle
+ * @max_addr: the maximum address the device can handle
*
* Description:
* Different hardware can have different requirements as to what pages
* it can do I/O directly to. A low level driver can call
* blk_queue_bounce_limit to have lower memory pages allocated as bounce
- * buffers for doing I/O to pages residing above @dma_mask.
+ * buffers for doing I/O to pages residing above @max_addr.
**/
-void blk_queue_bounce_limit(struct request_queue *q, u64 dma_mask)
+void blk_queue_bounce_limit(struct request_queue *q, u64 max_addr)
{
- unsigned long b_pfn = dma_mask >> PAGE_SHIFT;
+ unsigned long b_pfn = max_addr >> PAGE_SHIFT;
int dma = 0;
q->bounce_gfp = GFP_NOIO;
--
1.7.4.4
^ permalink raw reply related
* [PATCH 48/51] ARM: 7795/1: mm: dma-mapping: Add dma_max_pfn(dev) helper function
From: Russell King @ 2013-09-19 23:41 UTC (permalink / raw)
To: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel
Cc: Vinod Koul, Jens Axboe, Dan Williams
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Most of the kernel assumes that PFN0 is the start of the physical
memory (RAM). This assumptions is not true on most of the ARM SOCs
and hence and if one try to update the ARM port to follow the assumptions,
we end of breaking the dma bounce limit for few block layer drivers.
One such example is trying to unify the meaning of max*_pfn on ARM
as the bootmem layer expects, breaks few block layer driver dma
bounce limit.
To fix this problem, we introduce dma_max_pfn(dev) generic helper with
a possibility of override from the architecture code. The helper converts
a DMA bitmask of bits to a block PFN number. In all the generic cases,
it is just "dev->dma_mask >> PAGE_SHIFT" and hence default behavior
is maintained as is.
Subsequent patches will make use of the helper. No functional change.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
include/linux/dma-mapping.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 27d1421..fd4aee2 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -153,6 +153,13 @@ static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask)
return -EIO;
}
+#ifndef dma_max_pfn
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+ return *dev->dma_mask >> PAGE_SHIFT;
+}
+#endif
+
static inline void *dma_zalloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
--
1.7.4.4
^ permalink raw reply related
* [PATCH 49/51] ARM: 7796/1: scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations
From: Russell King @ 2013-09-19 23:42 UTC (permalink / raw)
To: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel
Cc: James E.J. Bottomley
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/scsi/scsi_lib.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index d1549b7..7bd7f0d 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1684,7 +1684,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
host_dev = scsi_get_device(shost);
if (host_dev && host_dev->dma_mask)
- bounce_limit = *host_dev->dma_mask;
+ bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;
return bounce_limit;
}
--
1.7.4.4
^ permalink raw reply related
* [PATCH 50/51] ARM: 7797/1: mmc: Use dma_max_pfn(dev) helper for bounce_limit calculations
From: Russell King @ 2013-09-19 23:43 UTC (permalink / raw)
To: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel
Cc: Chris Ball
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. MMC queue layr
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/mmc/card/queue.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index fa9632e..357bbc5 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -15,6 +15,7 @@
#include <linux/freezer.h>
#include <linux/kthread.h>
#include <linux/scatterlist.h>
+#include <linux/dma-mapping.h>
#include <linux/mmc/card.h>
#include <linux/mmc/host.h>
@@ -196,7 +197,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
struct mmc_queue_req *mqrq_prev = &mq->mqrq[1];
if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask)
- limit = *mmc_dev(host)->dma_mask;
+ limit = dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT;
mq->card = card;
mq->queue = blk_init_queue(mmc_request_fn, lock);
--
1.7.4.4
^ permalink raw reply related
* [PATCH 51/51] ARM: 7805/1: mm: change max*pfn to include the physical offset of memory
From: Russell King @ 2013-09-19 23:44 UTC (permalink / raw)
To: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel
Cc: Nicolas Pitre, Catalin Marinas, Will Deacon
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Most of the kernel code assumes that max*pfn is maximum pfns because
the physical start of memory is expected to be PFN0. Since this
assumption is not true on ARM architectures, the meaning of max*pfn
is number of memory pages. This is done to keep drivers happy which
are making use of of these variable to calculate the dma bounce limit
using dma_mask.
Now since we have a architecture override possibility for DMAable
maximum pfns, lets make meaning of max*pfns as maximum pnfs on ARM
as well.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/include/asm/dma-mapping.h | 8 ++++++++
arch/arm/mm/init.c | 10 ++++------
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 5b579b9..863cd84 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -64,6 +64,7 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
{
return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
}
+
#else
static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
{
@@ -86,6 +87,13 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
}
#endif
+/* The ARM override for dma_max_pfn() */
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+ return PHYS_PFN_OFFSET + dma_to_pfn(dev, *dev->dma_mask);
+}
+#define dma_max_pfn(dev) dma_max_pfn(dev)
+
/*
* DMA errors are defined by all-bits-set in the DMA address.
*/
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 8aab24f..d50533c 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -426,12 +426,10 @@ void __init bootmem_init(void)
* This doesn't seem to be used by the Linux memory manager any
* more, but is used by ll_rw_block. If we can get rid of it, we
* also get rid of some of the stuff above as well.
- *
- * Note: max_low_pfn and max_pfn reflect the number of _pages_ in
- * the system, not the maximum PFN.
*/
- max_low_pfn = max_low - PHYS_PFN_OFFSET;
- max_pfn = max_high - PHYS_PFN_OFFSET;
+ min_low_pfn = min;
+ max_low_pfn = max_low;
+ max_pfn = max_high;
}
/*
@@ -537,7 +535,7 @@ static inline void free_area_high(unsigned long pfn, unsigned long end)
static void __init free_highpages(void)
{
#ifdef CONFIG_HIGHMEM
- unsigned long max_low = max_low_pfn + PHYS_PFN_OFFSET;
+ unsigned long max_low = max_low_pfn;
struct memblock_region *mem, *res;
/* set highmem page free */
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 1/2][v3] powerpc/fsl-booke: Add initial T104x_QDS board support
From: Prabhakar Kushwaha @ 2013-09-20 8:46 UTC (permalink / raw)
To: Timur Tabi, Kushwaha Prabhakar-B32579
Cc: Wood Scott-B07421, Jain Priyanka-B32167, Aggrwal Poonam-B10812,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <523BBC15.8030607@tabi.org>
On 09/20/2013 08:38 AM, Timur Tabi wrote:
> Kushwaha Prabhakar-B32579 wrote:
>> My primary object is to put base patch in Linux. once it done other
>> things can be enabled one by one.
>
> Any features which are not enabled must be specified in the patch
> description. The patch says that the board supports DIU, but the code
> doesn't, so that's misleading.
>
>> Also, I am not familiar with DIU driver:(.
>
> I can help you with the DIU driver.
>
>> shall I remove the DIU node, and while adding support of DIU, all
>> modification will be sent.
>
> I think it should be okay to leave the DIU node. I think the kernel
> will crash if you try to enable a DIU console (video= on the kernel
> command line), but I think it's okay to ignore that for the moment.
>
Got it.
I think patch set is OK for now. No need to send v4.
DIU support will be added later.
Regards,
Prabhakar
^ permalink raw reply
* Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
From: Alexander Gordeev @ 2013-09-20 8:24 UTC (permalink / raw)
To: Michael Ellerman
Cc: Joerg Roedel, x86@kernel.org, linux-kernel@vger.kernel.org,
linux-ide@vger.kernel.org, Jan Beulich, linux-pci@vger.kernel.org,
Bjorn Helgaas, Tejun Heo, linuxppc-dev, Ingo Molnar
In-Reply-To: <20130918165045.GB2353@dhcp-26-207.brq.redhat.com>
Michael et al.
The identifiable options sounded so far were:
* Do not change anything
* Make pci_enable_msix() return 0/-errno
* Make pci_enable_msix() return 0/-errno and introduce arch_get_msix_limit()/
arch_get_msi_limit()
* Make pci_enable_msix() return 0/-errno and introduce pci_get_msix_limit()/
pci_get_msi_limit() and arch_get_msix_limit()/arch_get_msi_limit() so that:
pci_get_msix_limit() = min(arch_get_msix_limit(), pci_msix_table_size())
pci_get_msi_limit() = min(arch_get_msi_limit(), pci_get_msi_cap())
Can we have a conclusion here?
Thanks!
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* [PATCH 5/6 v6] kvm: booke: clear host tlb reference flag on guest tlb invalidation
From: Bharat Bhushan @ 2013-09-20 4:25 UTC (permalink / raw)
To: benh, agraf, paulus, kvm, kvm-ppc, linuxppc-dev, scottwood; +Cc: Bharat Bhushan
On booke, "struct tlbe_ref" contains host tlb mapping information
(pfn: for guest-pfn to pfn, flags: attribute associated with this mapping)
for a guest tlb entry. So when a guest creates a TLB entry then
"struct tlbe_ref" is set to point to valid "pfn" and set attributes in
"flags" field of the above said structure. When a guest TLB entry is
invalidated then flags field of corresponding "struct tlbe_ref" is
updated to point that this is no more valid, also we selectively clear
some other attribute bits, example: if E500_TLB_BITMAP was set then we clear
E500_TLB_BITMAP, if E500_TLB_TLB0 is set then we clear this.
Ideally we should clear complete "flags" as this entry is invalid and does not
have anything to re-used. The other part of the problem is that when we use
the same entry again then also we do not clear (started doing or-ing etc).
So far it was working because the selectively clearing mentioned above
actually clears "flags" what was set during TLB mapping. But the problem
starts coming when we add more attributes to this then we need to selectively
clear them and which is not needed.
This patch we do both
- Clear "flags" when invalidating;
- Clear "flags" when reusing same entry later
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
---
v5->v6
- Fix flag clearing comment
arch/powerpc/kvm/e500_mmu_host.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
index 1c6a9d7..7370e1c 100644
--- a/arch/powerpc/kvm/e500_mmu_host.c
+++ b/arch/powerpc/kvm/e500_mmu_host.c
@@ -230,15 +230,15 @@ void inval_gtlbe_on_host(struct kvmppc_vcpu_e500 *vcpu_e500, int tlbsel,
ref->flags &= ~(E500_TLB_TLB0 | E500_TLB_VALID);
}
- /* Already invalidated in between */
- if (!(ref->flags & E500_TLB_VALID))
- return;
-
- /* Guest tlbe is backed by at most one host tlbe per shadow pid. */
- kvmppc_e500_tlbil_one(vcpu_e500, gtlbe);
+ /*
+ * Check whether TLB entry is already invalidated in between
+ * Guest tlbe is backed by at most one host tlbe per shadow pid.
+ */
+ if (ref->flags & E500_TLB_VALID)
+ kvmppc_e500_tlbil_one(vcpu_e500, gtlbe);
/* Mark the TLB as not backed by the host anymore */
- ref->flags &= ~E500_TLB_VALID;
+ ref->flags = 0;
}
static inline int tlbe_is_writable(struct kvm_book3e_206_tlb_entry *tlbe)
@@ -251,7 +251,7 @@ static inline void kvmppc_e500_ref_setup(struct tlbe_ref *ref,
pfn_t pfn)
{
ref->pfn = pfn;
- ref->flags |= E500_TLB_VALID;
+ ref->flags = E500_TLB_VALID;
if (tlbe_is_writable(gtlbe))
kvm_set_pfn_dirty(pfn);
--
1.7.0.4
^ permalink raw reply related
* RE: [PATCH 5/6 v5] kvm: booke: clear host tlb reference flag on guest tlb invalidation
From: Bhushan Bharat-R65777 @ 2013-09-20 4:19 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: kvm@vger.kernel.org, agraf@suse.de, kvm-ppc@vger.kernel.org,
paulus@samba.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1379624878.16231.3.camel@aoeu.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjAsIDIwMTMgMjozOCBBTQ0KPiBUbzogQmh1
c2hhbiBCaGFyYXQtUjY1Nzc3DQo+IENjOiBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IGFncmFm
QHN1c2UuZGU7IHBhdWx1c0BzYW1iYS5vcmc7DQo+IGt2bUB2Z2VyLmtlcm5lbC5vcmc7IGt2bS1w
cGNAdmdlci5rZXJuZWwub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsNCj4gQmh1
c2hhbiBCaGFyYXQtUjY1Nzc3DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggNS82IHY1XSBrdm06IGJv
b2tlOiBjbGVhciBob3N0IHRsYiByZWZlcmVuY2UgZmxhZyBvbiBndWVzdA0KPiB0bGIgaW52YWxp
ZGF0aW9uDQo+IA0KPiBPbiBUaHUsIDIwMTMtMDktMTkgYXQgMTE6MzIgKzA1MzAsIEJoYXJhdCBC
aHVzaGFuIHdyb3RlOg0KPiA+IE9uIGJvb2tlLCAic3RydWN0IHRsYmVfcmVmIiBjb250YWlucyBo
b3N0IHRsYiBtYXBwaW5nIGluZm9ybWF0aW9uDQo+ID4gKHBmbjogZm9yIGd1ZXN0LXBmbiB0byBw
Zm4sIGZsYWdzOiBhdHRyaWJ1dGUgYXNzb2NpYXRlZCB3aXRoIHRoaXMNCj4gPiBtYXBwaW5nKSBm
b3IgYSBndWVzdCB0bGIgZW50cnkuIFNvIHdoZW4gYSBndWVzdCBjcmVhdGVzIGEgVExCIGVudHJ5
DQo+ID4gdGhlbiAic3RydWN0IHRsYmVfcmVmIiBpcyBzZXQgdG8gcG9pbnQgdG8gdmFsaWQgInBm
biIgYW5kIHNldA0KPiA+IGF0dHJpYnV0ZXMgaW4gImZsYWdzIiBmaWVsZCBvZiB0aGUgYWJvdmUg
c2FpZCBzdHJ1Y3R1cmUuIFdoZW4gYSBndWVzdA0KPiA+IFRMQiBlbnRyeSBpcyBpbnZhbGlkYXRl
ZCB0aGVuIGZsYWdzIGZpZWxkIG9mIGNvcnJlc3BvbmRpbmcgInN0cnVjdA0KPiA+IHRsYmVfcmVm
IiBpcyB1cGRhdGVkIHRvIHBvaW50IHRoYXQgdGhpcyBpcyBubyBtb3JlIHZhbGlkLCBhbHNvIHdl
DQo+ID4gc2VsZWN0aXZlbHkgY2xlYXIgc29tZSBvdGhlciBhdHRyaWJ1dGUgYml0cywgZXhhbXBs
ZTogaWYNCj4gPiBFNTAwX1RMQl9CSVRNQVAgd2FzIHNldCB0aGVuIHdlIGNsZWFyIEU1MDBfVExC
X0JJVE1BUCwgaWYgRTUwMF9UTEJfVExCMCBpcyBzZXQNCj4gdGhlbiB3ZSBjbGVhciB0aGlzLg0K
PiA+DQo+ID4gSWRlYWxseSB3ZSBzaG91bGQgY2xlYXIgY29tcGxldGUgImZsYWdzIiBhcyB0aGlz
IGVudHJ5IGlzIGludmFsaWQgYW5kDQo+ID4gZG9lcyBub3QgaGF2ZSBhbnl0aGluZyB0byByZS11
c2VkLiBUaGUgb3RoZXIgcGFydCBvZiB0aGUgcHJvYmxlbSBpcw0KPiA+IHRoYXQgd2hlbiB3ZSB1
c2UgdGhlIHNhbWUgZW50cnkgYWdhaW4gdGhlbiBhbHNvIHdlIGRvIG5vdCBjbGVhciAoc3RhcnRl
ZCBkb2luZw0KPiBvci1pbmcgZXRjKS4NCj4gPg0KPiA+IFNvIGZhciBpdCB3YXMgd29ya2luZyBi
ZWNhdXNlIHRoZSBzZWxlY3RpdmVseSBjbGVhcmluZyBtZW50aW9uZWQgYWJvdmUNCj4gPiBhY3R1
YWxseSBjbGVhcnMgImZsYWdzIiB3aGF0IHdhcyBzZXQgZHVyaW5nIFRMQiBtYXBwaW5nLiBCdXQg
dGhlDQo+ID4gcHJvYmxlbSBzdGFydHMgY29taW5nIHdoZW4gd2UgYWRkIG1vcmUgYXR0cmlidXRl
cyB0byB0aGlzIHRoZW4gd2UgbmVlZA0KPiA+IHRvIHNlbGVjdGl2ZWx5IGNsZWFyIHRoZW0gYW5k
IHdoaWNoIGlzIG5vdCBuZWVkZWQuDQo+ID4NCj4gPiBUaGlzIHBhdGNoIHdlIGRvIGJvdGgNCj4g
PiAgICAgICAgIC0gQ2xlYXIgImZsYWdzIiB3aGVuIGludmFsaWRhdGluZzsNCj4gPiAgICAgICAg
IC0gQ2xlYXIgImZsYWdzIiB3aGVuIHJldXNpbmcgc2FtZSBlbnRyeSBsYXRlcg0KPiA+DQo+ID4g
U2lnbmVkLW9mZi1ieTogQmhhcmF0IEJodXNoYW4gPGJoYXJhdC5iaHVzaGFuQGZyZWVzY2FsZS5j
b20+DQo+ID4gLS0tDQo+ID4gdjMtPiB2NQ0KPiA+ICAtIE5ldyBwYXRjaCAoZm91bmQgdGhpcyBp
c3N1ZSB3aGVuIGRvaW5nIHZmaW8tcGNpIGRldmVsb3BtZW50KQ0KPiA+DQo+ID4gIGFyY2gvcG93
ZXJwYy9rdm0vZTUwMF9tbXVfaG9zdC5jIHwgICAxMiArKysrKysrLS0tLS0NCj4gPiAgMSBmaWxl
cyBjaGFuZ2VkLCA3IGluc2VydGlvbnMoKyksIDUgZGVsZXRpb25zKC0pDQo+ID4NCj4gPiBkaWZm
IC0tZ2l0IGEvYXJjaC9wb3dlcnBjL2t2bS9lNTAwX21tdV9ob3N0LmMNCj4gPiBiL2FyY2gvcG93
ZXJwYy9rdm0vZTUwMF9tbXVfaG9zdC5jDQo+ID4gaW5kZXggMWM2YTlkNy4uNjBmNWEzYyAxMDA2
NDQNCj4gPiAtLS0gYS9hcmNoL3Bvd2VycGMva3ZtL2U1MDBfbW11X2hvc3QuYw0KPiA+ICsrKyBi
L2FyY2gvcG93ZXJwYy9rdm0vZTUwMF9tbXVfaG9zdC5jDQo+ID4gQEAgLTIxNyw3ICsyMTcsOCBA
QCB2b2lkIGludmFsX2d0bGJlX29uX2hvc3Qoc3RydWN0IGt2bXBwY192Y3B1X2U1MDANCj4gKnZj
cHVfZTUwMCwgaW50IHRsYnNlbCwNCj4gPiAgCQl9DQo+ID4gIAkJbWIoKTsNCj4gPiAgCQl2Y3B1
X2U1MDAtPmcyaF90bGIxX21hcFtlc2VsXSA9IDA7DQo+ID4gLQkJcmVmLT5mbGFncyAmPSB+KEU1
MDBfVExCX0JJVE1BUCB8IEU1MDBfVExCX1ZBTElEKTsNCj4gPiArCQkvKiBDbGVhciBmbGFncyBh
cyBUTEIgaXMgbm90IGJhY2tlZCBieSB0aGUgaG9zdCBhbnltb3JlICovDQo+ID4gKwkJcmVmLT5m
bGFncyA9IDA7DQo+ID4gIAkJbG9jYWxfaXJxX3Jlc3RvcmUoZmxhZ3MpOw0KPiA+ICAJfQ0KPiAN
Cj4gVGhpcyBicmVha3Mgd2hlbiB5b3UgaGF2ZSBib3RoIEU1MDBfVExCX0JJVE1BUCBhbmQgRTUw
MF9UTEJfVExCMCBzZXQuDQoNCkkgZG8gbm90IHNlZSBhbnkgY2FzZSB3aGVyZSB3ZSBzZXQgYm90
aCBFNTAwX1RMQl9CSVRNQVAgYW5kIEU1MDBfVExCX1RMQjAuIEFsc28gd2UgaGF2ZSBub3Qgb3B0
aW1pemVkIHRoYXQgeWV0IChrZWVwaW5nIHRyYWNrIG9mIG11bHRpcGxlIHNoYWRvdyBUTEIwIGVu
dHJpZXMgZm9yIG9uZSBndWVzdCBUTEIxIGVudHJ5KQ0KDQpXZSB1c2VzIHRoZXNlIGJpdCBmbGFn
cyBvbmx5IGZvciBUTEIxIGFuZCBpZiBzaXplIG9mIHN0bGJlIGlzIDRLIHRoZW4gd2Ugc2V0IEU1
MDBfVExCX1RMQjAgIG90aGVyd2lzZSB3ZSBzZXQgRTUwMF9UTEJfQklUTUFQLiBBbHRob3VnaCBJ
IHRoaW5rIHRoYXQgRTUwMF9UTEJfQklUTUFQIHNob3VsZCBiZSBzZXQgb25seSBpZiBzdGxiZSBz
aXplIGlzIGxlc3MgdGhhbiBndGxiZSBzaXplLg0KDQo+IA0KPiBJbnN0ZWFkLCBqdXN0IGNvbnZl
cnQgdGhlIGZpbmFsIEU1MDBfVExCX1ZBTElEIGNsZWFyaW5nIGF0IHRoZSBlbmQgaW50bw0KPiBy
ZWYtPmZsYWdzID0gMCwgYW5kIGNvbnZlcnQgdGhlIGVhcmx5IHJldHVybiBhIGZldyBsaW5lcyBl
YXJsaWVyIGludG8NCj4gY29uZGl0aW9uYWwgZXhlY3V0aW9uIG9mIHRoZSB0bGJpbF9vbmUoKS4N
Cg0KVGhpcyBsb29rcyBiZXR0ZXIsIHdpbGwgc2VuZCB0aGUgcGF0Y2ggc2hvcnRseS4NCg0KVGhh
bmtzDQotQmhhcmF0DQoNCj4gDQo+IC1TY290dA0KPiANCg0K
^ permalink raw reply
* Re: [PATCH 1/2][v3] powerpc/fsl-booke: Add initial T104x_QDS board support
From: Timur Tabi @ 2013-09-20 3:08 UTC (permalink / raw)
To: Kushwaha Prabhakar-B32579
Cc: Wood Scott-B07421, Jain Priyanka-B32167, Aggrwal Poonam-B10812,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <071A08F2C6A57E4E94D980ECA553F874F9CF8D@039-SN1MPN1-005.039d.mgd.msft.net>
Kushwaha Prabhakar-B32579 wrote:
> My primary object is to put base patch in Linux. once it done other things can be enabled one by one.
Any features which are not enabled must be specified in the patch
description. The patch says that the board supports DIU, but the code
doesn't, so that's misleading.
> Also, I am not familiar with DIU driver:(.
I can help you with the DIU driver.
> shall I remove the DIU node, and while adding support of DIU, all modification will be sent.
I think it should be okay to leave the DIU node. I think the kernel
will crash if you try to enable a DIU console (video= on the kernel
command line), but I think it's okay to ignore that for the moment.
^ permalink raw reply
* RE: [PATCH 1/2][v3] powerpc/fsl-booke: Add initial T104x_QDS board support
From: Kushwaha Prabhakar-B32579 @ 2013-09-20 1:38 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, Jain Priyanka-B32167, Aggrwal Poonam-B10812,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXVBV0LvEwTua_eyTHXJdOcHZKQCjiTrYocqfcQY5hosUw@mail.gmail.com>
Hi Tabi,
> -----Original Message-----
> From: Timur Tabi [mailto:timur@tabi.org]
> Sent: Friday, September 20, 2013 2:03 AM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Jain Priyanka-
> B32167; Aggrwal Poonam-B10812
> Subject: Re: [PATCH 1/2][v3] powerpc/fsl-booke: Add initial T104x_QDS
> board support
>=20
> On Thu, Sep 19, 2013 at 4:00 AM, Prabhakar Kushwaha
> <prabhakar@freescale.com> wrote:
>=20
> > - Video
> > - DIU supports video at up to 1280x1024x32bpp
>=20
> You mention DIU support, except there's no DIU enablement in the platform
> file. You need the T104x equivalent of
> p1022ds_set_pixel_clock() and the other functions.
My primary object is to put base patch in Linux. once it done other things =
can be enabled one by one.
Also, I am not familiar with DIU driver :(.=20
or
shall I remove the DIU node, and while adding support of DIU, all modifica=
tion will be sent.
Please advice.=20
Regards,
Prabhakar
^ permalink raw reply
* Re: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
From: Ben Hutchings @ 2013-09-20 1:21 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
Dan Williams, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
Vinod Koul, linux-crypto, Rob Landley, uclinux-dist-devel,
linuxppc-dev
In-Reply-To: <E1VMlja-0007fA-HU@rmk-PC.arm.linux.org.uk>
On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
> Provide a helper to set both the DMA and coherent DMA masks to the
> same value - this avoids duplicated code in a number of drivers,
> sometimes with buggy error handling, and also allows us identify
> which drivers do things differently.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> Documentation/DMA-API-HOWTO.txt | 37 ++++++++++++++++++++++---------------
> Documentation/DMA-API.txt | 8 ++++++++
> include/linux/dma-mapping.h | 14 ++++++++++++++
> 3 files changed, 44 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
> index 14129f1..5e98303 100644
> --- a/Documentation/DMA-API-HOWTO.txt
> +++ b/Documentation/DMA-API-HOWTO.txt
[...]
> -dma_set_coherent_mask() will always be able to set the same or a
> -smaller mask as dma_set_mask(). However for the rare case that a
> +The coherent coherent mask will always be able to set the same or a
> +smaller mask as the streaming mask. However for the rare case that a
[...]
The new wording doesn't make sense; a mask doesn't set itself. I would
suggest:
"The coherent mask can always be set to the same or a smaller mask than
the streaming mask."
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Preliminary kexec support for Linux/m68k
From: Simon Horman @ 2013-09-19 21:00 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: kexec, linux-kernel@vger.kernel.org, linux-m68k, Anton Blanchard,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAMuHMdW8y9_=LXQ1PXjFaPyq-nYTPe+FodE5hQh4P3QSdnP_dg@mail.gmail.com>
On Thu, Sep 19, 2013 at 11:20:22AM +0200, Geert Uytterhoeven wrote:
> On Tue, Sep 17, 2013 at 12:01 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > This is a preliminary set of patches to add kexec support for m68k.
>
> > - [PATCH 1/3] m68k: Add preliminary kexec support
> > - [PATCH 2/3] m68k: Add support to export bootinfo in procfs
> > - [PATCH 3/3] [RFC] m68k: Add System RAM to /proc/iomem
> >
> > Notes:
> > - The bootinfo is now saved and exported to /proc/bootinfo, so kexec-tools
> > can read it and pass it (possibly after modification) to the new kernel.
> > This is similar to /proc/atags on ARM.
>
> > - I based [PATCH 3/3] on the PowerPC version, but it's no longer needed as we
> > now get this information from the bootinfo.
> > Does anyone think this is nice to have anyway?
>
> It seems kexec/kdump on ppc don't use /proc/iomem anymore, and only rely on
> /proc/device-tree these days?
I think thats entirely a matter for the m68k kernel maintainers to decide.
But my personal opinion is that it is nice not to add it if it isn't needed.
^ permalink raw reply
* [PATCH 08/51] DMA-API: net: intel/ixgbevf: fix 32-bit DMA mask handling
From: Russell King @ 2013-09-19 21:32 UTC (permalink / raw)
To: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel
Cc: Alex Duyck, Don Skidmore, Peter P Waskiewicz Jr, Bruce Allan,
Jesse Brandeburg, Greg Rose, John Ronciak, Jeff Kirsher,
Carolyn Wyborny, Tushar Dave
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(&pdev->dev, "No usable DMA "
"configuration, aborting\n");
goto err_dma;
}
}
pci_using_dac = 0;
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 15 +++++----------
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 59a62bb..e34c2da 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -3326,19 +3326,14 @@ static int ixgbevf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (err)
return err;
- if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
- !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(&pdev->dev, "No usable DMA "
- "configuration, aborting\n");
- goto err_dma;
- }
+ dev_err(&pdev->dev, "No usable DMA "
+ "configuration, aborting\n");
+ goto err_dma;
}
pci_using_dac = 0;
}
--
1.7.4.4
^ permalink raw reply related
* [PATCH 07/51] DMA-API: net: intel/ixgbe: fix 32-bit DMA mask handling
From: Russell King @ 2013-09-19 21:31 UTC (permalink / raw)
To: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel
Cc: Alex Duyck, Don Skidmore, Peter P Waskiewicz Jr, Bruce Allan,
Jesse Brandeburg, Greg Rose, John Ronciak, Jeff Kirsher,
Carolyn Wyborny, Tushar Dave
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(&pdev->dev,
"No usable DMA configuration, aborting\n");
goto err_dma;
}
}
pci_using_dac = 0;
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 15 +++++----------
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 7aba452..b1dc844 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7475,19 +7475,14 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (err)
return err;
- if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
- !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(&pdev->dev,
- "No usable DMA configuration, aborting\n");
- goto err_dma;
- }
+ dev_err(&pdev->dev,
+ "No usable DMA configuration, aborting\n");
+ goto err_dma;
}
pci_using_dac = 0;
}
--
1.7.4.4
^ permalink raw reply related
* [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
From: Russell King @ 2013-09-19 21:25 UTC (permalink / raw)
To: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel
Cc: Vinod Koul, Dan Williams, Rob Landley
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
Provide a helper to set both the DMA and coherent DMA masks to the
same value - this avoids duplicated code in a number of drivers,
sometimes with buggy error handling, and also allows us identify
which drivers do things differently.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
Documentation/DMA-API-HOWTO.txt | 37 ++++++++++++++++++++++---------------
Documentation/DMA-API.txt | 8 ++++++++
include/linux/dma-mapping.h | 14 ++++++++++++++
3 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 14129f1..5e98303 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -101,14 +101,23 @@ style to do this even if your device holds the default setting,
because this shows that you did think about these issues wrt. your
device.
-The query is performed via a call to dma_set_mask():
+The query is performed via a call to dma_set_mask_and_coherent():
- int dma_set_mask(struct device *dev, u64 mask);
+ int dma_set_mask_and_coherent(struct device *dev, u64 mask);
-The query for consistent allocations is performed via a call to
-dma_set_coherent_mask():
+which will query the mask for both streaming and coherent APIs together.
+If you have some special requirements, then the following two separate
+queries can be used instead:
- int dma_set_coherent_mask(struct device *dev, u64 mask);
+ The query for streaming mappings is performed via a call to
+ dma_set_mask():
+
+ int dma_set_mask(struct device *dev, u64 mask);
+
+ The query for consistent allocations is performed via a call
+ to dma_set_coherent_mask():
+
+ int dma_set_coherent_mask(struct device *dev, u64 mask);
Here, dev is a pointer to the device struct of your device, and mask
is a bit mask describing which bits of an address your device
@@ -137,7 +146,7 @@ exactly why.
The standard 32-bit addressing device would do something like this:
- if (dma_set_mask(dev, DMA_BIT_MASK(32))) {
+ if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
printk(KERN_WARNING
"mydev: No suitable DMA available.\n");
goto ignore_this_device;
@@ -171,22 +180,20 @@ If a card is capable of using 64-bit consistent allocations as well,
int using_dac, consistent_using_dac;
- if (!dma_set_mask(dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
using_dac = 1;
consistent_using_dac = 1;
- dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
- } else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
+ } else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
using_dac = 0;
consistent_using_dac = 0;
- dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
} else {
printk(KERN_WARNING
"mydev: No suitable DMA available.\n");
goto ignore_this_device;
}
-dma_set_coherent_mask() will always be able to set the same or a
-smaller mask as dma_set_mask(). However for the rare case that a
+The coherent coherent mask will always be able to set the same or a
+smaller mask as the streaming mask. However for the rare case that a
device driver only uses consistent allocations, one would have to
check the return value from dma_set_coherent_mask().
@@ -199,9 +206,9 @@ Finally, if your device can only drive the low 24-bits of
goto ignore_this_device;
}
-When dma_set_mask() is successful, and returns zero, the kernel saves
-away this mask you have provided. The kernel will use this
-information later when you make DMA mappings.
+When dma_set_mask() or dma_set_mask_and_coherent() is successful, and
+returns zero, the kernel saves away this mask you have provided. The
+kernel will use this information later when you make DMA mappings.
There is a case which we are aware of at this time, which is worth
mentioning in this documentation. If your device supports multiple
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 78a6c56..e865279 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -142,6 +142,14 @@ internal API for use by the platform than an external API for use by
driver writers.
int
+dma_set_mask_and_coherent(struct device *dev, u64 mask)
+
+Checks to see if the mask is possible and updates the device
+streaming and coherent DMA mask parameters if it is.
+
+Returns: 0 if successful and a negative error if not.
+
+int
dma_set_mask(struct device *dev, u64 mask)
Checks to see if the mask is possible and updates the device
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 3a8d0a2..ec951f9 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -97,6 +97,20 @@ static inline int dma_set_coherent_mask(struct device *dev, u64 mask)
}
#endif
+/*
+ * Set both the DMA mask and the coherent DMA mask to the same thing.
+ * Note that we don't check the return value from dma_set_coherent_mask()
+ * as the DMA API guarantees that the coherent DMA mask can be set to
+ * the same or smaller than the streaming DMA mask.
+ */
+static inline int dma_set_mask_and_coherent(struct device *dev, u64 mask)
+{
+ int rc = dma_set_mask(dev, mask);
+ if (rc == 0)
+ dma_set_coherent_mask(dev, mask);
+ return rc;
+}
+
extern u64 dma_get_required_mask(struct device *dev);
static inline unsigned int dma_get_max_seg_size(struct device *dev)
--
1.7.4.4
^ permalink raw reply related
* [PATCH 05/51] DMA-API: net: intel/igbvf: fix 32-bit DMA mask handling
From: Russell King @ 2013-09-19 21:29 UTC (permalink / raw)
To: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel
Cc: Alex Duyck, Don Skidmore, Peter P Waskiewicz Jr, Bruce Allan,
Jesse Brandeburg, Greg Rose, John Ronciak, Jeff Kirsher,
Carolyn Wyborny, Tushar Dave
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(&pdev->dev, "No usable DMA "
"configuration, aborting\n");
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/net/ethernet/intel/igbvf/netdev.c | 18 ++++++------------
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index 93eb7ee..4e6b02f 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -2638,21 +2638,15 @@ static int igbvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(&pdev->dev, "No usable DMA "
- "configuration, aborting\n");
- goto err_dma;
- }
+ dev_err(&pdev->dev, "No usable DMA "
+ "configuration, aborting\n");
+ goto err_dma;
}
}
--
1.7.4.4
^ permalink raw reply related
* [PATCH 02/51] DMA-API: net: brocade/bna/bnad.c: fix 32-bit DMA mask handling
From: Russell King @ 2013-09-19 21:26 UTC (permalink / raw)
To: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel
Cc: Rasesh Mody
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err)
goto release_regions;
}
This means we only try and set the coherent DMA mask if we failed to
set a 32-bit DMA mask, and only if both fail do we fail the driver.
Adjust this so that if either setting fails, we fail the driver - and
thereby end up properly setting both the DMA mask and the coherent
DMA mask in the fallback case.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/net/ethernet/brocade/bna/bnad.c | 13 ++++---------
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index b78e69e..45ce6e2 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -3300,17 +3300,12 @@ bnad_pci_init(struct bnad *bnad,
err = pci_request_regions(pdev, BNAD_NAME);
if (err)
goto disable_device;
- if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
- !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
- if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err)
- goto release_regions;
- }
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+ if (err)
+ goto release_regions;
*using_dac = false;
}
pci_set_master(pdev);
--
1.7.4.4
^ permalink raw reply related
* [PATCH 06/51] DMA-API: net: intel/ixgb: fix 32-bit DMA mask handling
From: Russell King @ 2013-09-19 21:30 UTC (permalink / raw)
To: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel
Cc: Alex Duyck, Don Skidmore, Peter P Waskiewicz Jr, Bruce Allan,
Jesse Brandeburg, Greg Rose, John Ronciak, Jeff Kirsher,
Carolyn Wyborny, Tushar Dave
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err) {
pr_err("No usable DMA configuration, aborting\n");
goto err_dma_mask;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 +++++-----------
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
index 9f6b236..57e390c 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
@@ -408,20 +408,14 @@ ixgb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err) {
- pr_err("No usable DMA configuration, aborting\n");
- goto err_dma_mask;
- }
+ pr_err("No usable DMA configuration, aborting\n");
+ goto err_dma_mask;
}
}
--
1.7.4.4
^ permalink raw reply related
* [PATCH 03/51] DMA-API: net: intel/e1000e: fix 32-bit DMA mask handling
From: Russell King @ 2013-09-19 21:27 UTC (permalink / raw)
To: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel
Cc: Alex Duyck, Don Skidmore, Peter P Waskiewicz Jr, Bruce Allan,
Jesse Brandeburg, Greg Rose, John Ronciak, Jeff Kirsher,
Carolyn Wyborny, Tushar Dave
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(&pdev->dev,
"No usable DMA configuration, aborting\n");
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 18 ++++++------------
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index e87e9b0..519e293 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6553,21 +6553,15 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(&pdev->dev,
- "No usable DMA configuration, aborting\n");
- goto err_dma;
- }
+ dev_err(&pdev->dev,
+ "No usable DMA configuration, aborting\n");
+ goto err_dma;
}
}
--
1.7.4.4
^ permalink raw reply related
* [PATCH 04/51] DMA-API: net: intel/igb: fix 32-bit DMA mask handling
From: Russell King @ 2013-09-19 21:28 UTC (permalink / raw)
To: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel
Cc: Alex Duyck, Don Skidmore, Peter P Waskiewicz Jr, Bruce Allan,
Jesse Brandeburg, Greg Rose, John Ronciak, Jeff Kirsher,
Carolyn Wyborny, Tushar Dave
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(&pdev->dev,
"No usable DMA configuration, aborting\n");
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/net/ethernet/intel/igb/igb_main.c | 18 ++++++------------
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 8cf44f2..7579383 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -2034,21 +2034,15 @@ static int igb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(&pdev->dev,
- "No usable DMA configuration, aborting\n");
- goto err_dma;
- }
+ dev_err(&pdev->dev,
+ "No usable DMA configuration, aborting\n");
+ goto err_dma;
}
}
--
1.7.4.4
^ permalink raw reply related
* [PATCH 00/51] DMA mask changes
From: Russell King - ARM Linux @ 2013-09-19 21:22 UTC (permalink / raw)
To: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel
This started out as a request to look at the DMA mask situation, and how
to solve the issues which we have on ARM - notably how the DMA mask
should be setup.
However, I started off reviewing how the dma_mask and coherent_dma_mask
was being used, and what I found was rather messy, and in some cases
rather buggy. I tried to get some of the bug fixes in before the last
merge window, but it seems that the maintainers preferred to have the
full solution rather than a simple -rc suitable bug fix.
So, this is an attempt to clean things up.
The first point here is that drivers performing DMA should be calling
dma_set_mask()/dma_set_coherent_mask() in their probe function to verify
that DMA can be performed. Lots of ARM drivers omit this step; please
refer to the DMA API documentation on this subject.
What this means is that the DMA mask provided by bus code is a default
value - nothing more. It doesn't have to accurately reflect what the
device is actually capable of. Apart from the storage for dev->dma_mask
being initialised for any device which is DMA capable, there is no other
initialisation which is strictly necessary at device creation time.
Now, these cleanups address two major areas:
1. The setting of DMA masks, particularly when both the coherent and
streaming DMA masks are set together.
2. The initialisation of DMA masks by drivers - this seems to be becoming
a popular habbit, one which may not be entirely the right solution.
Rather than having this scattered throughout the tree, I've pulled
that into a central location (and called it coercing the DMA mask -
because it really is about forcing the DMA mask to be that value.)
3. Finally, addressing the long held misbelief that DMA masks somehow
correspond with physical addresses. We already have established
long ago that dma_addr_t values returned from the DMA API are the
values which you program into the DMA controller, and so are the
bus addresses. It is _only_ sane that DMA masks are also bus
related too, and not related to physical address spaces.
(3) is a very important point for LPAE systems, which may still have
less than 4GB of memory, but this memory is all located above the 4GB
physical boundary. This means with the current model, any device
using a 32-bit DMA mask fails - even though the DMA controller is
still only a 32-bit DMA controller but the 32-bit bus addresses map
to system memory. To put it another way, the bus addresses have a
4GB physical offset on them.
This email is only being sent to the mailing lists in question, not to
anyone personally. The list of individuals is far to great to do that.
I'm hoping no mailing lists reject the patches based on the number of
recipients.
Patches based on v3.12-rc1.
Documentation/DMA-API-HOWTO.txt | 37 +++++++++------
Documentation/DMA-API.txt | 8 +++
arch/arm/include/asm/dma-mapping.h | 8 +++
arch/arm/mm/dma-mapping.c | 49 ++++++++++++++++++--
arch/arm/mm/init.c | 12 +++---
arch/arm/mm/mm.h | 2 +
arch/powerpc/kernel/vio.c | 3 +-
block/blk-settings.c | 8 ++--
drivers/amba/bus.c | 6 +--
drivers/ata/pata_ixp4xx_cf.c | 5 ++-
drivers/ata/pata_octeon_cf.c | 5 +-
drivers/block/nvme-core.c | 10 ++---
drivers/crypto/ixp4xx_crypto.c | 48 ++++++++++----------
drivers/dma/amba-pl08x.c | 5 ++
drivers/dma/dw/platform.c | 8 +--
drivers/dma/edma.c | 6 +--
drivers/dma/pl330.c | 4 ++
drivers/firmware/dcdbas.c | 23 +++++-----
drivers/firmware/google/gsmi.c | 13 +++--
drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 ++-
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 5 +-
drivers/media/platform/omap3isp/isp.c | 6 +-
drivers/media/platform/omap3isp/isp.h | 3 -
drivers/mmc/card/queue.c | 3 +-
drivers/mmc/host/sdhci-acpi.c | 5 +-
drivers/net/ethernet/broadcom/b44.c | 3 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 8 +---
drivers/net/ethernet/brocade/bna/bnad.c | 13 ++----
drivers/net/ethernet/emulex/benet/be_main.c | 12 +----
drivers/net/ethernet/intel/e1000/e1000_main.c | 9 +---
drivers/net/ethernet/intel/e1000e/netdev.c | 18 +++-----
drivers/net/ethernet/intel/igb/igb_main.c | 18 +++-----
drivers/net/ethernet/intel/igbvf/netdev.c | 18 +++-----
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 ++-----
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 15 ++----
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 15 ++----
drivers/net/ethernet/nxp/lpc_eth.c | 6 ++-
drivers/net/ethernet/octeon/octeon_mgmt.c | 5 +-
drivers/net/ethernet/sfc/efx.c | 12 +-----
drivers/net/wireless/b43/dma.c | 9 +---
drivers/net/wireless/b43legacy/dma.c | 9 +---
drivers/of/platform.c | 3 -
drivers/parport/parport_pc.c | 8 +++-
drivers/scsi/scsi_lib.c | 2 +-
drivers/staging/dwc2/platform.c | 5 +-
drivers/staging/et131x/et131x.c | 17 +------
drivers/staging/imx-drm/imx-drm-core.c | 8 +++-
drivers/staging/imx-drm/ipuv3-crtc.c | 4 +-
drivers/staging/media/dt3155v4l/dt3155v4l.c | 5 +--
drivers/usb/chipidea/ci_hdrc_imx.c | 7 +--
drivers/usb/dwc3/dwc3-exynos.c | 7 +--
drivers/usb/gadget/lpc32xx_udc.c | 4 +-
drivers/usb/host/bcma-hcd.c | 3 +-
drivers/usb/host/ehci-atmel.c | 7 +--
drivers/usb/host/ehci-octeon.c | 4 +-
drivers/usb/host/ehci-omap.c | 10 ++--
drivers/usb/host/ehci-orion.c | 7 +--
drivers/usb/host/ehci-platform.c | 10 ++--
drivers/usb/host/ehci-s5p.c | 7 +--
drivers/usb/host/ehci-spear.c | 7 +--
drivers/usb/host/ehci-tegra.c | 7 +--
drivers/usb/host/ohci-at91.c | 9 ++--
drivers/usb/host/ohci-exynos.c | 7 +--
drivers/usb/host/ohci-nxp.c | 5 +-
drivers/usb/host/ohci-octeon.c | 5 +-
drivers/usb/host/ohci-omap3.c | 10 ++--
drivers/usb/host/ohci-pxa27x.c | 8 ++--
drivers/usb/host/ohci-sa1111.c | 6 +++
drivers/usb/host/ohci-spear.c | 7 +--
drivers/usb/host/ssb-hcd.c | 3 +-
drivers/usb/host/uhci-platform.c | 7 +--
drivers/usb/musb/am35x.c | 50 +++++++--------------
drivers/usb/musb/da8xx.c | 49 +++++++-------------
drivers/usb/musb/davinci.c | 48 +++++++-------------
drivers/usb/musb/tusb6010.c | 49 +++++++-------------
drivers/video/amba-clcd.c | 5 ++
include/linux/amba/bus.h | 2 -
include/linux/dma-mapping.h | 31 +++++++++++++
sound/arm/pxa2xx-pcm.c | 9 +---
sound/soc/atmel/atmel-pcm.c | 11 ++---
sound/soc/blackfin/bf5xx-ac97-pcm.c | 11 ++---
sound/soc/blackfin/bf5xx-i2s-pcm.c | 10 ++---
sound/soc/davinci/davinci-pcm.c | 9 +---
sound/soc/fsl/fsl_dma.c | 9 +---
sound/soc/fsl/mpc5200_dma.c | 10 ++---
sound/soc/jz4740/jz4740-pcm.c | 12 ++---
sound/soc/kirkwood/kirkwood-dma.c | 9 +---
sound/soc/nuc900/nuc900-pcm.c | 9 ++--
sound/soc/omap/omap-pcm.c | 11 ++---
sound/soc/pxa/pxa2xx-pcm.c | 11 ++---
sound/soc/s6000/s6000-pcm.c | 9 +---
sound/soc/samsung/dma.c | 11 ++---
sound/soc/samsung/idma.c | 11 ++---
93 files changed, 493 insertions(+), 566 deletions(-)
^ permalink raw reply
* Re: [PATCH 5/6 v5] kvm: booke: clear host tlb reference flag on guest tlb invalidation
From: Scott Wood @ 2013-09-19 21:07 UTC (permalink / raw)
To: Bharat Bhushan; +Cc: kvm, agraf, kvm-ppc, Bharat Bhushan, paulus, linuxppc-dev
In-Reply-To: <1379570566-3715-6-git-send-email-Bharat.Bhushan@freescale.com>
On Thu, 2013-09-19 at 11:32 +0530, Bharat Bhushan wrote:
> On booke, "struct tlbe_ref" contains host tlb mapping information
> (pfn: for guest-pfn to pfn, flags: attribute associated with this mapping)
> for a guest tlb entry. So when a guest creates a TLB entry then
> "struct tlbe_ref" is set to point to valid "pfn" and set attributes in
> "flags" field of the above said structure. When a guest TLB entry is
> invalidated then flags field of corresponding "struct tlbe_ref" is
> updated to point that this is no more valid, also we selectively clear
> some other attribute bits, example: if E500_TLB_BITMAP was set then we clear
> E500_TLB_BITMAP, if E500_TLB_TLB0 is set then we clear this.
>
> Ideally we should clear complete "flags" as this entry is invalid and does not
> have anything to re-used. The other part of the problem is that when we use
> the same entry again then also we do not clear (started doing or-ing etc).
>
> So far it was working because the selectively clearing mentioned above
> actually clears "flags" what was set during TLB mapping. But the problem
> starts coming when we add more attributes to this then we need to selectively
> clear them and which is not needed.
>
> This patch we do both
> - Clear "flags" when invalidating;
> - Clear "flags" when reusing same entry later
>
> Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
> ---
> v3-> v5
> - New patch (found this issue when doing vfio-pci development)
>
> arch/powerpc/kvm/e500_mmu_host.c | 12 +++++++-----
> 1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
> index 1c6a9d7..60f5a3c 100644
> --- a/arch/powerpc/kvm/e500_mmu_host.c
> +++ b/arch/powerpc/kvm/e500_mmu_host.c
> @@ -217,7 +217,8 @@ void inval_gtlbe_on_host(struct kvmppc_vcpu_e500 *vcpu_e500, int tlbsel,
> }
> mb();
> vcpu_e500->g2h_tlb1_map[esel] = 0;
> - ref->flags &= ~(E500_TLB_BITMAP | E500_TLB_VALID);
> + /* Clear flags as TLB is not backed by the host anymore */
> + ref->flags = 0;
> local_irq_restore(flags);
> }
This breaks when you have both E500_TLB_BITMAP and E500_TLB_TLB0 set.
Instead, just convert the final E500_TLB_VALID clearing at the end into
ref->flags = 0, and convert the early return a few lines earlier into
conditional execution of the tlbil_one().
-Scott
^ permalink raw reply
* Re: [PATCH 1/2][v3] powerpc/fsl-booke: Add initial T104x_QDS board support
From: Timur Tabi @ 2013-09-19 20:32 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: Scott Wood, Priyanka Jain, linuxppc-dev@lists.ozlabs.org,
Poonam Aggrwal
In-Reply-To: <1379581205-24424-1-git-send-email-prabhakar@freescale.com>
On Thu, Sep 19, 2013 at 4:00 AM, Prabhakar Kushwaha
<prabhakar@freescale.com> wrote:
> - Video
> - DIU supports video at up to 1280x1024x32bpp
You mention DIU support, except there's no DIU enablement in the
platform file. You need the T104x equivalent of
p1022ds_set_pixel_clock() and the other functions.
^ permalink raw reply
* Does iommu_init_table need to use GFP_ATOMIC allocations?
From: Nishanth Aravamudan @ 2013-09-19 16:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Mackerras, linuxppc-dev, Thadeu Lima de Souza Cascardo,
Anton Blanchard
Under heavy (DLPAR?) stress, we tripped this panic() in
arch/powerpc/kernel/iommu.c::iommu_init_table():
page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
if (!page)
panic("iommu_init_table: Can't allocate %ld bytes\n",
sz);
Before the panic() we got a page allocation failure for an order-2
allocation. There appears to be memory free, but perhaps not in the
ATOMIC context. I looked through all the call-sites of
iommu_init_table() and didn't see any obvious reason to need an ATOMIC
allocation. Most call-sites in fact have an explicit GFP_KERNEL
allocation shortly before the call to iommu_init_table(), indicating we
are not in an atomic context. There is some indirection for some paths,
but I didn't see any locks indicating that GFP_KERNEL is inappropriate.
Does anyone know if/why ATOMIC allocations are necessary here?
Thanks,
Nish
^ permalink raw reply
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