This patchset is another sequel to my patchset to fix iommu segment
boundary problems, IOMMUs allocate memory areas without considering a
low level driver's segment boundary limits:
http://www.mail-archive.com/[email protected]/msg11919.html
This patchset fixes the PARISC IOMMU code (sbc and ccio).
There are three patches in this patchset. The first patch is for the
IOMMU helper (lib/iommu-helper.c) to enable PARISC IOMMUs use it.
The second and third patches are for PARISC IOMMUs, the second one is
preparation for the third patch, which fixes the IOMMU segment
boundary problem.
The third patch assumes that ioc->ibase is on IOVP_SIZE boundary. If
not, please let me know. I'll fix the patch.
iommu_is_span_boundary is used internally in the IOMMU helper
(lib/iommu-helper.c), a primitive function that judges whether a
memory area spans LLD's segment boundary or not.
It's difficult to convert some IOMMUs to use the IOMMU helper but
iommu_is_span_boundary is still useful for them. So this patch exports
it.
Signed-off-by: FUJITA Tomonori <[email protected]>
Cc: Andrew Morton <[email protected]>
---
include/linux/iommu-helper.h | 3 +++
lib/iommu-helper.c | 10 ++++++----
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/include/linux/iommu-helper.h b/include/linux/iommu-helper.h
index 4dd4c04..c975caf 100644
--- a/include/linux/iommu-helper.h
+++ b/include/linux/iommu-helper.h
@@ -1,3 +1,6 @@
+extern int iommu_is_span_boundary(unsigned int index, unsigned int nr,
+ unsigned long shift,
+ unsigned long boundary_size);
extern unsigned long iommu_area_alloc(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr,
unsigned long shift,
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
index 495575a..a3b8d4c 100644
--- a/lib/iommu-helper.c
+++ b/lib/iommu-helper.c
@@ -40,10 +40,12 @@ static inline void set_bit_area(unsigned long *map, unsigned long i,
}
}
-static inline int is_span_boundary(unsigned int index, unsigned int nr,
- unsigned long shift,
- unsigned long boundary_size)
+int iommu_is_span_boundary(unsigned int index, unsigned int nr,
+ unsigned long shift,
+ unsigned long boundary_size)
{
+ BUG_ON(!is_power_of_2(boundary_size));
+
shift = (shift + index) & (boundary_size - 1);
return shift + nr > boundary_size;
}
@@ -57,7 +59,7 @@ unsigned long iommu_area_alloc(unsigned long *map, unsigned long size,
again:
index = find_next_zero_area(map, size, start, nr, align_mask);
if (index != -1) {
- if (is_span_boundary(index, nr, shift, boundary_size)) {
+ if (iommu_is_span_boundary(index, nr, shift, boundary_size)) {
/* we could do more effectively */
start = index + 1;
goto again;
--
1.5.3.7
This adds struct device argument to sba_alloc_range and
ccio_alloc_range, a preparation for modifications to fix the IOMMU
segment boundary problem. This change enables ccio_alloc_range to
access to LLD's segment boundary limits.
Signed-off-by: FUJITA Tomonori <[email protected]>
Cc: Kyle McMartin <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Grant Grundler <[email protected]>
Cc: Andrew Morton <[email protected]>
---
drivers/parisc/ccio-dma.c | 4 ++--
drivers/parisc/iommu-helpers.h | 4 ++--
drivers/parisc/sba_iommu.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
index d08b284..1695fac 100644
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -341,7 +341,7 @@ static int ioc_count;
* of available pages for the requested size.
*/
static int
-ccio_alloc_range(struct ioc *ioc, size_t size)
+ccio_alloc_range(struct ioc *ioc, struct device *dev, size_t size)
{
unsigned int pages_needed = size >> IOVP_SHIFT;
unsigned int res_idx;
@@ -760,7 +760,7 @@ ccio_map_single(struct device *dev, void *addr, size_t size,
ioc->msingle_pages += size >> IOVP_SHIFT;
#endif
- idx = ccio_alloc_range(ioc, size);
+ idx = ccio_alloc_range(ioc, dev, size);
iovp = (dma_addr_t)MKIOVP(idx);
pdir_start = &(ioc->pdir_base[idx]);
diff --git a/drivers/parisc/iommu-helpers.h b/drivers/parisc/iommu-helpers.h
index 97ba828..3cc6930 100644
--- a/drivers/parisc/iommu-helpers.h
+++ b/drivers/parisc/iommu-helpers.h
@@ -97,7 +97,7 @@ iommu_fill_pdir(struct ioc *ioc, struct scatterlist *startsg, int nents,
static inline unsigned int
iommu_coalesce_chunks(struct ioc *ioc, struct device *dev,
struct scatterlist *startsg, int nents,
- int (*iommu_alloc_range)(struct ioc *, size_t))
+ int (*iommu_alloc_range)(struct ioc *, struct device *, size_t))
{
struct scatterlist *contig_sg; /* contig chunk head */
unsigned long dma_offset, dma_len; /* start/len of DMA stream */
@@ -166,7 +166,7 @@ iommu_coalesce_chunks(struct ioc *ioc, struct device *dev,
dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
sg_dma_address(contig_sg) =
PIDE_FLAG
- | (iommu_alloc_range(ioc, dma_len) << IOVP_SHIFT)
+ | (iommu_alloc_range(ioc, dev, dma_len) << IOVP_SHIFT)
| dma_offset;
n_mappings++;
}
diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c
index d06627c..7d58bd2 100644
--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -404,7 +404,7 @@ sba_search_bitmap(struct ioc *ioc, unsigned long bits_wanted)
* resource bit map.
*/
static int
-sba_alloc_range(struct ioc *ioc, size_t size)
+sba_alloc_range(struct ioc *ioc, struct device *dev, size_t size)
{
unsigned int pages_needed = size >> IOVP_SHIFT;
#ifdef SBA_COLLECT_STATS
@@ -710,7 +710,7 @@ sba_map_single(struct device *dev, void *addr, size_t size,
ioc->msingle_calls++;
ioc->msingle_pages += size >> IOVP_SHIFT;
#endif
- pide = sba_alloc_range(ioc, size);
+ pide = sba_alloc_range(ioc, dev, size);
iovp = (dma_addr_t) pide << IOVP_SHIFT;
DBG_RUN("%s() 0x%p -> 0x%lx\n",
--
1.5.3.7
This patch makes PARISC's two IOMMU implementations not allocate a
memory area spanning LLD's segment boundary.
Signed-off-by: FUJITA Tomonori <[email protected]>
Cc: Kyle McMartin <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Grant Grundler <[email protected]>
Cc: Andrew Morton <[email protected]>
---
drivers/parisc/Kconfig | 5 ++++
drivers/parisc/ccio-dma.c | 13 ++++++++++-
drivers/parisc/sba_iommu.c | 48 +++++++++++++++++++++++++++++++++----------
3 files changed, 53 insertions(+), 13 deletions(-)
diff --git a/drivers/parisc/Kconfig b/drivers/parisc/Kconfig
index 1d3b84b..553a990 100644
--- a/drivers/parisc/Kconfig
+++ b/drivers/parisc/Kconfig
@@ -103,6 +103,11 @@ config IOMMU_SBA
depends on PCI_LBA
default PCI_LBA
+config IOMMU_HELPER
+ bool
+ depends on IOMMU_SBA || IOMMU_CCIO
+ default y
+
#config PCI_EPIC
# bool "EPIC/SAGA PCI support"
# depends on PCI
diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
index 1695fac..2f3b364 100644
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -43,6 +43,7 @@
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
#include <linux/scatterlist.h>
+#include <linux/iommu-helper.h>
#include <asm/byteorder.h>
#include <asm/cache.h> /* for L1_CACHE_BYTES */
@@ -302,9 +303,13 @@ static int ioc_count;
*/
#define CCIO_SEARCH_LOOP(ioc, res_idx, mask, size) \
for(; res_ptr < res_end; ++res_ptr) { \
- if(0 == (*res_ptr & mask)) { \
+ int ret;\
+ unsigned int idx;\
+ idx = (unsigned int)((unsigned long)res_ptr - (unsigned long)ioc->res_map); \
+ ret = iommu_is_span_boundary(idx << 3, pages_needed, 0, boundary_size);\
+ if((0 == (*res_ptr & mask)) && !ret) { \
*res_ptr |= mask; \
- res_idx = (unsigned int)((unsigned long)res_ptr - (unsigned long)ioc->res_map); \
+ res_idx = idx;\
ioc->res_hint = res_idx + (size >> 3); \
goto resource_found; \
} \
@@ -345,6 +350,7 @@ ccio_alloc_range(struct ioc *ioc, struct device *dev, size_t size)
{
unsigned int pages_needed = size >> IOVP_SHIFT;
unsigned int res_idx;
+ unsigned long boundary_size;
#ifdef CCIO_SEARCH_TIME
unsigned long cr_start = mfctl(16);
#endif
@@ -360,6 +366,9 @@ ccio_alloc_range(struct ioc *ioc, struct device *dev, size_t size)
** ggg sacrifices another 710 to the computer gods.
*/
+ boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1, 1 << IOVP_SHIFT);
+ boundary_size >>= IOVP_SHIFT;
+
if (pages_needed <= 8) {
/*
* LAN traffic will not thrash the TLB IFF the same NIC
diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c
index 7d58bd2..e834127 100644
--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -29,6 +29,7 @@
#include <linux/string.h>
#include <linux/pci.h>
#include <linux/scatterlist.h>
+#include <linux/iommu-helper.h>
#include <asm/byteorder.h>
#include <asm/io.h>
@@ -313,6 +314,12 @@ sba_dump_sg( struct ioc *ioc, struct scatterlist *startsg, int nents)
#define RESMAP_MASK(n) (~0UL << (BITS_PER_LONG - (n)))
#define RESMAP_IDX_MASK (sizeof(unsigned long) - 1)
+unsigned long ptr_to_pide(struct ioc *ioc, unsigned long *res_ptr,
+ unsigned int bitshiftcnt)
+{
+ return (((unsigned long)res_ptr - (unsigned long)ioc->res_map) << 3)
+ + bitshiftcnt;
+}
/**
* sba_search_bitmap - find free space in IO PDIR resource bitmap
@@ -324,19 +331,36 @@ sba_dump_sg( struct ioc *ioc, struct scatterlist *startsg, int nents)
* Cool perf optimization: search for log2(size) bits at a time.
*/
static SBA_INLINE unsigned long
-sba_search_bitmap(struct ioc *ioc, unsigned long bits_wanted)
+sba_search_bitmap(struct ioc *ioc, struct device *dev,
+ unsigned long bits_wanted)
{
unsigned long *res_ptr = ioc->res_hint;
unsigned long *res_end = (unsigned long *) &(ioc->res_map[ioc->res_size]);
- unsigned long pide = ~0UL;
+ unsigned long pide = ~0UL, tpide;
+ unsigned long boundary_size;
+ unsigned long shift;
+ int ret;
+
+ boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1, 1 << IOVP_SHIFT);
+ boundary_size >>= IOVP_SHIFT;
+
+#if defined(ZX1_SUPPORT)
+ BUG_ON(ioc->ibase & ~IOVP_MASK);
+ shift = ioc->ibase >> IOVP_SHIFT;
+#else
+ shift = 0;
+#endif
if (bits_wanted > (BITS_PER_LONG/2)) {
/* Search word at a time - no mask needed */
for(; res_ptr < res_end; ++res_ptr) {
- if (*res_ptr == 0) {
+ tpide = ptr_to_pide(ioc, res_ptr, 0);
+ ret = iommu_is_span_boundary(tpide, bits_wanted,
+ shift,
+ boundary_size);
+ if ((*res_ptr == 0) && !ret) {
*res_ptr = RESMAP_MASK(bits_wanted);
- pide = ((unsigned long)res_ptr - (unsigned long)ioc->res_map);
- pide <<= 3; /* convert to bit address */
+ pide = tpide;
break;
}
}
@@ -365,11 +389,13 @@ sba_search_bitmap(struct ioc *ioc, unsigned long bits_wanted)
{
DBG_RES(" %p %lx %lx\n", res_ptr, mask, *res_ptr);
WARN_ON(mask == 0);
- if(((*res_ptr) & mask) == 0) {
+ tpide = ptr_to_pide(ioc, res_ptr, bitshiftcnt);
+ ret = iommu_is_span_boundary(tpide, bits_wanted,
+ shift,
+ boundary_size);
+ if ((((*res_ptr) & mask) == 0) && !ret) {
*res_ptr |= mask; /* mark resources busy! */
- pide = ((unsigned long)res_ptr - (unsigned long)ioc->res_map);
- pide <<= 3; /* convert to bit address */
- pide += bitshiftcnt;
+ pide = tpide;
break;
}
mask >>= o;
@@ -412,9 +438,9 @@ sba_alloc_range(struct ioc *ioc, struct device *dev, size_t size)
#endif
unsigned long pide;
- pide = sba_search_bitmap(ioc, pages_needed);
+ pide = sba_search_bitmap(ioc, dev, pages_needed);
if (pide >= (ioc->res_size << 3)) {
- pide = sba_search_bitmap(ioc, pages_needed);
+ pide = sba_search_bitmap(ioc, dev, pages_needed);
if (pide >= (ioc->res_size << 3))
panic("%s: I/O MMU @ %p is out of mapping resources\n",
__FILE__, ioc->ioc_hpa);
--
1.5.3.7
On Sun, Mar 02, 2008 at 03:10:25PM +0900, FUJITA Tomonori wrote:
> This patchset is another sequel to my patchset to fix iommu segment
> boundary problems, IOMMUs allocate memory areas without considering a
> low level driver's segment boundary limits:
>
> http://www.mail-archive.com/[email protected]/msg11919.html
>
This looks fine. Are you able to test this? If not, we can set you up
with an account on a machine with remote console and all that jazz, if
you'd like to.
cheers, Kyle
> On Sun, Mar 02, 2008 at 03:10:25PM +0900, FUJITA Tomonori wrote:
> > This patchset is another sequel to my patchset to fix iommu segment
> > boundary problems, IOMMUs allocate memory areas without considering a
> > low level driver's segment boundary limits:
> >
> > http://www.mail-archive.com/[email protected]/msg11919.html
> >
>
> This looks fine. Are you able to test this? If not, we can set you up
> with an account on a machine with remote console and all that jazz, if
> you'd like to.
>
> cheers, Kyle
> --
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Dear *,
I have access to 3 kind of boxes which needed one of those drivers: a b2k and
mainly a c110 and a d380 for which I hope a lot of this patch ;-)
I will so try the patch asap and let you know the results.
hth,
r.
---
Scarlet One, ADSL 6 Mbps + Telephone, from EUR 29,95...
http://www.scarlet.be/
> On Sun, Mar 02, 2008 at 03:10:25PM +0900, FUJITA Tomonori wrote:
> > This patchset is another sequel to my patchset to fix iommu segment
> > boundary problems, IOMMUs allocate memory areas without considering a
> > low level driver's segment boundary limits:
> >
> > http://www.mail-archive.com/[email protected]/msg11919.html
> >
>
> This looks fine. Are you able to test this? If not, we can set you up
> with an account on a machine with remote console and all that jazz, if
> you'd like to.
>
> cheers, Kyle
> --
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Sorry for bad news but using a kernel known to work fine on my b2k (kyle's
parisc-2.6.git date 2008_02_21) against which I applied those patches, this
new kernel 32bit up failled to boot with this panic message:
Linux Tulip driver version 1.1.15 (Feb 27, 2007)
------------[ cut here ]------------
Kernel BUG at 1029520c [verbose debug info unavailable]
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001110 Not tainted
r00-03 0004ff0e 1054c010 1029e774 80000000
r04-07 1fc2b020 00000100 00000000 00000001
r08-11 1fc1d454 1fc2c000 00000000 80000000
r12-15 00000001 00000001 1fc10858 0001a000
r16-19 00000011 104a23d0 00000000 ffffffff
r20-23 00001000 00000000 1fdb6a00 00000000
r24-27 00000000 00000001 00000100 10507010
r28-31 00000100 00100000 1fc205c0 00000000
sr00-03 00000000 00000000 00000000 00000000
sr04-07 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ: 1029520c 10295210
IIR: 03ffe01f ISR: 1024003f IOR: 0802056c
CPU: 0 CR30: 1fc20000 CR31: 11111111
ORIG_R28: 0000000f
IAOQ[0]: iommu_is_span_boundary+0x28/0x30
IAOQ[1]: iommu_is_span_boundary+0x2c/0x30
RP(r2): sba_alloc_range+0x23c/0x4f8
Backtrace:
[<10107938>] show_regs+0x2c8/0x450
[<10107c64>] die_if_kernel+0x98/0x1b0
[<101083a0>] handle_interruption+0x624/0x6b4
[<1010b078>] intr_check_sig+0x0/0x34
[<1015d07c>] rmqueue_bulk+0x44/0x9c
[<1015e778>] __alloc_pages+0xc4/0x388
[<1015ea74>] __get_free_pages+0x38/0x74
[<1029ed64>] sba_alloc_consistent+0x60/0xd4
[<105852f0>] tulip_init_one+0x2ac/0xd10
[<1029acb0>] pci_device_probe+0x70/0xa8
[<102dad50>] driver_probe_device+0xa4/0x1bc
[<102db01c>] __driver_attach+0x60/0xf4
[<102da1dc>] bus_for_each_dev+0x58/0xa0
[<102da978>] bus_add_driver+0xd4/0x1e0
[<102db34c>] driver_register+0x48/0x108
[<10565880>] kernel_init+0x120/0x33c
Backtrace:
[<10107c6c>] die_if_kernel+0xa0/0x1b0
[<101083a0>] handle_interruption+0x624/0x6b4
[<1010b078>] intr_check_sig+0x0/0x34
[<1015d07c>] rmqueue_bulk+0x44/0x9c
[<1015e778>] __alloc_pages+0xc4/0x388
[<1015ea74>] __get_free_pages+0x38/0x74
[<1029ed64>] sba_alloc_consistent+0x60/0xd4
[<105852f0>] tulip_init_one+0x2ac/0xd10
[<1029acb0>] pci_device_probe+0x70/0xa8
[<102dad50>] driver_probe_device+0xa4/0x1bc
[<102db01c>] __driver_attach+0x60/0xf4
[<102da1dc>] bus_for_each_dev+0x58/0xa0
[<102da978>] bus_add_driver+0xd4/0x1e0
[<102db34c>] driver_register+0x48/0x108
[<10565880>] kernel_init+0x120/0x33c
[<1010ac5c>] ret_from_kernel_thread+0x1c/0x24
Kernel panic - not syncing: Attempted to kill init!
(I haven't a lot a spare time right now, but I will do my best to help as much
as I can).
r.
---
Scarlet One, ADSL 6 Mbps + Telephone, from EUR 29,95...
http://www.scarlet.be/
On Mon, 3 Mar 2008 12:04:00 +0100
"rubisher" <[email protected]> wrote:
> > On Sun, Mar 02, 2008 at 03:10:25PM +0900, FUJITA Tomonori wrote:
> > > This patchset is another sequel to my patchset to fix iommu segment
> > > boundary problems, IOMMUs allocate memory areas without considering a
> > > low level driver's segment boundary limits:
> > >
> > > http://www.mail-archive.com/[email protected]/msg11919.html
> > >
> >
> > This looks fine. Are you able to test this? If not, we can set you up
> > with an account on a machine with remote console and all that jazz, if
> > you'd like to.
> >
> > cheers, Kyle
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> Sorry for bad news but using a kernel known to work fine on my b2k (kyle's
> parisc-2.6.git date 2008_02_21) against which I applied those patches, this
> new kernel 32bit up failled to boot with this panic message:
>
> Linux Tulip driver version 1.1.15 (Feb 27, 2007)
> ------------[ cut here ]------------
> Kernel BUG at 1029520c [verbose debug info unavailable]
>
> YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001001111111100001110 Not tainted
> r00-03 0004ff0e 1054c010 1029e774 80000000
> r04-07 1fc2b020 00000100 00000000 00000001
> r08-11 1fc1d454 1fc2c000 00000000 80000000
> r12-15 00000001 00000001 1fc10858 0001a000
> r16-19 00000011 104a23d0 00000000 ffffffff
> r20-23 00001000 00000000 1fdb6a00 00000000
> r24-27 00000000 00000001 00000100 10507010
> r28-31 00000100 00100000 1fc205c0 00000000
> sr00-03 00000000 00000000 00000000 00000000
> sr04-07 00000000 00000000 00000000 00000000
> IASQ: 00000000 00000000 IAOQ: 1029520c 10295210
> IIR: 03ffe01f ISR: 1024003f IOR: 0802056c
> CPU: 0 CR30: 1fc20000 CR31: 11111111
> ORIG_R28: 0000000f
> IAOQ[0]: iommu_is_span_boundary+0x28/0x30
> IAOQ[1]: iommu_is_span_boundary+0x2c/0x30
> RP(r2): sba_alloc_range+0x23c/0x4f8
Thanks a lot for testing!
Really sorry about the bug. Can you try the following patch? It's on
the top of the patchset.
Thanks,
diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
index 2f3b364..d0855a1 100644
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -366,8 +366,8 @@ ccio_alloc_range(struct ioc *ioc, struct device *dev, size_t size)
** ggg sacrifices another 710 to the computer gods.
*/
- boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1, 1 << IOVP_SHIFT);
- boundary_size >>= IOVP_SHIFT;
+ boundary_size = ALIGN((unsigned long long)dma_get_seg_boundary(dev) + 1,
+ 1ULL << IOVP_SHIFT) >> IOVP_SHIFT;
if (pages_needed <= 8) {
/*
diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c
index e834127..bdbe780 100644
--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -341,8 +341,8 @@ sba_search_bitmap(struct ioc *ioc, struct device *dev,
unsigned long shift;
int ret;
- boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1, 1 << IOVP_SHIFT);
- boundary_size >>= IOVP_SHIFT;
+ boundary_size = ALIGN((unsigned long long)dma_get_seg_boundary(dev) + 1,
+ 1ULL << IOVP_SHIFT) >> IOVP_SHIFT;
#if defined(ZX1_SUPPORT)
BUG_ON(ioc->ibase & ~IOVP_MASK);
> On Mon, 3 Mar 2008 12:04:00 +0100
> "rubisher" <[email protected]> wrote:
>
> > > On Sun, Mar 02, 2008 at 03:10:25PM +0900, FUJITA Tomonori wrote:
> > > > This patchset is another sequel to my patchset to fix iommu segment
> > > > boundary problems, IOMMUs allocate memory areas without considering a
> > > > low level driver's segment boundary limits:
> > > >
> > > > http://www.mail-archive.com/[email protected]/msg11919.html
> > > >
> > >
> > > This looks fine. Are you able to test this? If not, we can set you up
> > > with an account on a machine with remote console and all that jazz, if
> > > you'd like to.
> > >
> > > cheers, Kyle
> > > --
[snip]
> Thanks a lot for testing!
>
Always welcome ;-)
> Really sorry about the bug.
Don't worry, those boxes are there for my fun...
> Can you try the following patch? It's on the top of the patchset.
>
Good catch: now this first testing system (I mean the b2k) is up and running ;-)
I will now try the ccio_dma driver on a d380 ...
hth,
r.
> Thanks,
>
> diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
> index 2f3b364..d0855a1 100644
> --- a/drivers/parisc/ccio-dma.c
> +++ b/drivers/parisc/ccio-dma.c
> @@ -366,8 +366,8 @@ ccio_alloc_range(struct ioc *ioc, struct device *dev,
size_t size)
> ** ggg sacrifices another 710 to the computer gods.
> */
>
> - boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1, 1 << IOVP_SHIFT);
> - boundary_size >>= IOVP_SHIFT;
> + boundary_size = ALIGN((unsigned long long)dma_get_seg_boundary(dev) + 1,
> + 1ULL << IOVP_SHIFT) >> IOVP_SHIFT;
>
> if (pages_needed <= 8) {
> /*
> diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c
> index e834127..bdbe780 100644
> --- a/drivers/parisc/sba_iommu.c
> +++ b/drivers/parisc/sba_iommu.c
> @@ -341,8 +341,8 @@ sba_search_bitmap(struct ioc *ioc, struct device *dev,
> unsigned long shift;
> int ret;
>
> - boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1, 1 << IOVP_SHIFT);
> - boundary_size >>= IOVP_SHIFT;
> + boundary_size = ALIGN((unsigned long long)dma_get_seg_boundary(dev) + 1,
> + 1ULL << IOVP_SHIFT) >> IOVP_SHIFT;
>
> #if defined(ZX1_SUPPORT)
> BUG_ON(ioc->ibase & ~IOVP_MASK);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
---
Scarlet One, ADSL 6 Mbps + Telephone, from EUR 29,95...
http://www.scarlet.be/
[snip]
> > Can you try the following patch? It's on the top of the patchset.
> >
> Good catch: now this first testing system (I mean the b2k) is up and running ;-)
>
> I will now try the ccio_dma driver on a d380 ...
>
Yes, it works too on a d380 boxe running a 32bit up kernel.
Btw (it was a long time ago), I also resurrect my 64 config for the b2k model
and it also works fine.
Many tx again,
r.
> hth,
> r.
>
> > Thanks,
> >
> > diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
> > index 2f3b364..d0855a1 100644
> > --- a/drivers/parisc/ccio-dma.c
> > +++ b/drivers/parisc/ccio-dma.c
> > @@ -366,8 +366,8 @@ ccio_alloc_range(struct ioc *ioc, struct device *dev,
> size_t size)
> > ** ggg sacrifices another 710 to the computer gods.
> > */
> >
> > - boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1, 1 << IOVP_SHIFT);
> > - boundary_size >>= IOVP_SHIFT;
> > + boundary_size = ALIGN((unsigned long long)dma_get_seg_boundary(dev) + 1,
> > + 1ULL << IOVP_SHIFT) >> IOVP_SHIFT;
> >
> > if (pages_needed <= 8) {
> > /*
> > diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c
> > index e834127..bdbe780 100644
> > --- a/drivers/parisc/sba_iommu.c
> > +++ b/drivers/parisc/sba_iommu.c
> > @@ -341,8 +341,8 @@ sba_search_bitmap(struct ioc *ioc, struct device *dev,
> > unsigned long shift;
> > int ret;
> >
> > - boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1, 1 << IOVP_SHIFT);
> > - boundary_size >>= IOVP_SHIFT;
> > + boundary_size = ALIGN((unsigned long long)dma_get_seg_boundary(dev) + 1,
> > + 1ULL << IOVP_SHIFT) >> IOVP_SHIFT;
> >
> > #if defined(ZX1_SUPPORT)
> > BUG_ON(ioc->ibase & ~IOVP_MASK);
> > --
---
Scarlet One, ADSL 6 Mbps + Telephone, from EUR 29,95...
http://www.scarlet.be/
On Tue, 4 Mar 2008 17:13:55 +0100
"rubisher" <[email protected]> wrote:
> [snip]
> > > Can you try the following patch? It's on the top of the patchset.
> > >
> > Good catch: now this first testing system (I mean the b2k) is up and running ;-)
> >
> > I will now try the ccio_dma driver on a d380 ...
> >
> Yes, it works too on a d380 boxe running a 32bit up kernel.
Great, thanks a lot for testing both IOMMUs!
> Btw (it was a long time ago), I also resurrect my 64 config for the b2k model
> and it also works fine.
Nice, and sorry about the bug on 32bits boxes.
Thanks again,
On Sun, 2 Mar 2008 12:13:11 -0500
Kyle McMartin <[email protected]> wrote:
> On Sun, Mar 02, 2008 at 03:10:25PM +0900, FUJITA Tomonori wrote:
> > This patchset is another sequel to my patchset to fix iommu segment
> > boundary problems, IOMMUs allocate memory areas without considering a
> > low level driver's segment boundary limits:
> >
> > http://www.mail-archive.com/[email protected]/msg11919.html
> >
>
> This looks fine. Are you able to test this? If not, we can set you up
> with an account on a machine with remote console and all that jazz, if
> you'd like to.
Thanks for the offer!
I don't have any parisc hardware. If -mm kernels are tested well with
parisc, I'd be happy to leave it in your guys' hands since I've never
used parisc and the patches seem to work (with the bug fix for 32bits
boxes).
I'd like to try if there are not people who try -mm kernels with
parisc or a bug that I can't fix easily will be found.
Thanks,
On Sun, Mar 02, 2008 at 03:10:25PM +0900, FUJITA Tomonori wrote:
> This patchset is another sequel to my patchset to fix iommu segment
> boundary problems, IOMMUs allocate memory areas without considering a
> low level driver's segment boundary limits:
>
> http://www.mail-archive.com/[email protected]/msg11919.html
>
> This patchset fixes the PARISC IOMMU code (sbc and ccio).
>
> There are three patches in this patchset. The first patch is for the
> IOMMU helper (lib/iommu-helper.c) to enable PARISC IOMMUs use it.
>
> The second and third patches are for PARISC IOMMUs, the second one is
> preparation for the third patch, which fixes the IOMMU segment
> boundary problem.
>
> The third patch assumes that ioc->ibase is on IOVP_SIZE boundary. If
> not, please let me know. I'll fix the patch.
Please add
Acked-by: Grant Grundler <[email protected]>
This includes the 4th patch posted on march 3, 2008.
Thanks for posting this series. I've reviewed the code and it looks fine
to me as well (kyle already acked it).
And thanks to Joel Soete (rubisher) for testing. I tried to test the
sba_iommu code on my local box but had issues with the unpatched kernel
(using kyle's parisc-2.6.git tree) that I have yet to resolve (could be
HW problems).
thanks,
grant
> And thanks to Joel Soete (rubisher) for testing. I tried to test the
> sba_iommu code on my local box but had issues with the unpatched kernel
> (using kyle's parisc-2.6.git tree) that I have yet to resolve (could be
> HW problems).
I built two kernels today using kyle's parisc-2.6.git tree (UP 32 bit
and SMP 64 bit). Aside from some section mismatch warnings, they both
seem to work fine.
Dave
--
J. David Anglin [email protected]
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)