[Linux-ia64] Missing files in to-linus-2.5 BK tree; build problems

[Linux-ia64] Missing files in to-linus-2.5 BK tree; build problems

[Peter Chubb]

Hi David,
   The files perfmon_itanium.h, perfmon_generic.h and
perfmon_mckinley.h are missing from the bk archive. I believe they
should have been added at:
      ChangeSet@1.552.24.3 2002-05-24 18:45:43-0700 eranian@hp.com


Also, what did you decide to do with the scatter-gather list changes
(member `address' no longer exists)?   The changes to sb_iommu.c are
non-trivial, because it looks as if the address field was
overloaded...

Peter C

Re: [Linux-ia64] Missing files in to-linus-2.5 BK tree; build

[Andreas Schwab]

Peter Chubb <peter@chubb.wattle.id.au> writes:

|> Also, what did you decide to do with the scatter-gather list changes
|> (member `address' no longer exists)?   The changes to sb_iommu.c are
|> non-trivial, because it looks as if the address field was
|> overloaded...

Just look at how lib/swiotlb.c is handling this and replace all references
to the address member by zero.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Linux-ia64] Missing files in to-linus-2.5 BK tree; build problems

[Grant Grundler]

Peter Chubb wrote:
> Also, what did you decide to do with the scatter-gather list changes
> (member `address' no longer exists)?   The changes to sb_iommu.c are
> non-trivial, because it looks as if the address field was
> overloaded...

Peter,
I promised David I would resolve that. I wrote the original code
for parisc-linux and Alex Williamson ported that to HP ZX1 chipset.

My excuses are I don't muck with bk, don't have a 2.5
tree lying around, and have been fighting 2.4-related fires
that relate to HP shipping a revenue generating product.

If someone has a tarball of the current to-linus tree I could d/l,
I could look at this sooner.

apologies,
grant

Re: [Linux-ia64] Missing files in to-linus-2.5 BK tree; build problems

[David Mosberger]

>>>>> On Wed, 29 May 2002 12:29:00 -0700, Grant Grundler <grundler@cup.hp.com> said:

  Grant> My excuses are I don't muck with bk, don't have a 2.5 tree
  Grant> lying around, and have been fighting 2.4-related fires that
  Grant> relate to HP shipping a revenue generating product.

  Grant> If someone has a tarball of the current to-linus tree I could
  Grant> d/l, I could look at this sooner.

Note that the to-linus-2.5 tree is intended for Linus only.  It's not
complete in any fashion (well, some day it will be...).  I am working
on the latest 2.5 patch, but keep getting delayed (and of course Linus
keeps cranking out new versions...).

	--david

Re: [Linux-ia64] Missing files in to-linus-2.5 BK tree; build problems

[Peter Chubb]

>>>>> On Wed, 29 May 2002 12:29:00 -0700, Grant Grundler <grundler@cup.hp.com> said:

Grant> If someone has a tarball of the current to-linus tree I could
Grant> d/l, I could look at this sooner.

Can you take a look at this and see if you think it's sane?
I'm only doing this to get a clean compilation

--- /tmp/geta3892	Thu May 30 14:53:10 2002
+++ sba_iommu.c	Thu May 30 14:53:05 2002
@@ -216,9 +216,10 @@
 static int reserve_sba_gart = 1;
 static struct pci_dev sac_only_dev;
 
-#define sba_sg_iova(sg) (sg->address)
+#define sba_sg_iova(sg) (page_address((sg)->page) + (sg)->offset)
 #define sba_sg_len(sg) (sg->length)
 #define sba_sg_buffer(sg) (sg->orig_address)
+#define sba_sg_clear_iova(sg) (sg->page = NULL,sg->offset = 0)
 
 /* REVISIT - fix me for multiple SBAs/IOCs */
 #define GET_IOC(dev) (sba_list->ioc)
@@ -229,8 +230,8 @@
 ** DMA_CHUNK_SIZE is used by the SCSI mid-layer to break up
 ** (or rather not merge) DMA's into managable chunks.
 ** On parisc, this is more of the software/tuning constraint
-** rather than the HW. I/O MMU allocation alogorithms can be
-** faster with smaller size is (to some degree).
+** rather than the HW. I/O MMU allocation algorithms can be
+** faster with smaller sizes (to some degree).
 */
 #define DMA_CHUNK_SIZE  (BITS_PER_LONG*PAGE_SIZE)
 
@@ -1037,10 +1038,12 @@
 		*/
 		if ((u64)sba_sg_iova(startsg) & PIDE_FLAG) {
 			u32 pide = (u64)sba_sg_iova(startsg) & ~PIDE_FLAG;
+			char *vaddr;
 			dma_offset = (unsigned long) pide & ~IOVP_MASK;
-			sba_sg_iova(startsg) = 0;
 			dma_sg++;
-			sba_sg_iova(dma_sg) = (char *)(pide | ioc->ibase);
+			vaddr = (char *)(pide | ioc->ibase);
+			dma_sg->page = virt_to_page(vaddr);
+			dma_sg->offset = (u64)vaddr * ~PAGE_MASK;
 			pdirp = &(ioc->pdir_base[pide >> IOVP_SHIFT]);
 			n_mappings++;
 		}
@@ -1115,7 +1118,8 @@
 	int n_mappings = 0;
 
 	while (nents > 0) {
-		unsigned long vaddr = (unsigned long) (startsg->address); 
+		unsigned long vaddr = (unsigned long) sba_sg_iova(startsg);
+						       
 
 		/*
 		** Prepare for first/next DMA stream
@@ -1127,7 +1131,7 @@
 
 		/* PARANOID: clear entries */
 		sba_sg_buffer(startsg) = sba_sg_iova(startsg);
-		sba_sg_iova(startsg) = 0;
+		sba_sg_clear_iova(startsg);
 		sba_sg_len(startsg) = 0;
 
 		/*
@@ -1162,7 +1166,7 @@
 				vcontig_end += sba_sg_len(startsg);
 				dma_len     += sba_sg_len(startsg);
 				sba_sg_buffer(startsg) = (char *)vaddr;
-				sba_sg_iova(startsg) = 0;
+				sba_sg_clear_iova(startsg);
 				sba_sg_len(startsg) = 0;
 				continue;
 			}
@@ -1178,9 +1182,9 @@
 			**
 			** Once we start a new VCONTIG chunk, dma_offset
 			** can't change. And we need the offset from the first
-			** chunk - not the last one. Ergo Successive chunks
-			** must start on page boundaries and dove tail
-			** with it's predecessor.
+			** chunk - not the last one. Ergo each successive chunk
+			** must start on a page boundary and dove-tail
+			** with its predecessor.
 			*/
 			sba_sg_len(vcontig_sg) = vcontig_len;
 
@@ -1196,7 +1200,7 @@
 				vcontig_end = vcontig_len + vaddr;
 				dma_len += vcontig_len;
 				sba_sg_buffer(startsg) = (char *)vaddr;
-				sba_sg_iova(startsg) = 0;
+				sba_sg_clear_iova(startsg);
 				continue;
 			} else {
 				break;
@@ -1211,9 +1215,13 @@
 		sba_sg_len(vcontig_sg) = vcontig_len;
 		dma_len = (dma_len + dma_offset + ~IOVP_MASK) & IOVP_MASK;
 		ASSERT(dma_len <= DMA_CHUNK_SIZE);
-		sba_sg_iova(dma_sg) = (char *) (PIDE_FLAG 
+		{ 
+			u64 vaddr = (PIDE_FLAG 
 			| (sba_alloc_range(ioc, dma_len) << IOVP_SHIFT)
 			| dma_offset);
+			dma_sg->page = virt_to_page(vaddr);
+			dma_sg->offset = vaddr & ~PAGE_MASK;
+		}
 		n_mappings++;
 	}
 
@@ -1248,7 +1256,8 @@
 	if (dev->dma_mask >= ioc->dma_mask) {
 		for (sg = sglist ; filled < nents ; filled++, sg++){
 			sba_sg_buffer(sg) = sba_sg_iova(sg);
-			sba_sg_iova(sg) = (char *)virt_to_phys(sba_sg_buffer(sg));
+			sg->page = virt_to_page(sba_sg_buffer(sg));
+			sg->offset = (u64)sba_sg_buffer(sg) & ~PAGE_MASK;
 		}
 #ifdef CONFIG_PROC_FS
 		spin_lock_irqsave(&ioc->res_lock, flags);
@@ -1260,10 +1269,13 @@
 #endif
 	/* Fast path single entry scatterlists. */
 	if (nents = 1) {
+		dma_addr_t vaddr;
 		sba_sg_buffer(sglist) = sba_sg_iova(sglist);
-		sba_sg_iova(sglist) = (char *)sba_map_single(dev,
+		vaddr = sba_map_single(dev,
 						sba_sg_buffer(sglist),
 						sba_sg_len(sglist), direction);
+		sglist->page = virt_to_page(vaddr);
+		sglist->offset = (u64)vaddr & ~PAGE_MASK;
 #ifdef CONFIG_PROC_FS
 		/*
 		** Should probably do some stats counting, but trying to
@@ -1628,7 +1640,7 @@
 			sba_dev->ioc[i].pdir_base[0] = 0x8000badbadc0ffeeULL;
 
 			for (reserved_iov = 0xA0000 ; reserved_iov < 0xC0000 ; reserved_iov += IOVP_SIZE) {
-				u64 *res_ptr = sba_dev->ioc[i].res_map;
+				u64 *res_ptr = (u64 *)sba_dev->ioc[i].res_map;
 				int index = PDIR_INDEX(reserved_iov);
 				int res_word;
 				u64 mask;
@@ -1759,7 +1771,7 @@
 
 	for (i = 0; i < PCI_NUM_RESOURCES; i++) {
 		if (pci_resource_flags(device, i) = IORESOURCE_MEM) {
-			hpa = ioremap(pci_resource_start(device, i),
+			hpa = (u64)ioremap(pci_resource_start(device, i),
 				pci_resource_len(device, i));
 			break;
 		}


--
Peter Chubb				    peterc@gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all almost the same.

Re: [Linux-ia64] Missing files in to-linus-2.5 BK tree; build problems

[Peter Chubb]

>>>>> "David" = David Mosberger <davidm@napali.hpl.hp.com> writes:

David> Note that the to-linus-2.5 tree is intended for Linus only.
David> It's not complete in any fashion (well, some day it will
David> be...).  I am working on the latest 2.5 patch, but keep getting
David> delayed (and of course Linus keeps cranking out new
David> versions...).

Doesn't he just!

It seems to me that there are several categories of things in the
patches you've been cranking out.

1. Support for devices not in the main tree (e.g., the i460GX, the
  qlogic 2200, etc)

2. Extra features (like the early printk support) that in their 
  current form are too ugly to go into the mainline, but are really
  useful for IA64.

3. Changes in architecture specific code for
  -- matching changes in mainline code (e.g., the scatterlist change,
  the TLB shootdown change, etc)
  -- enhancements to IA64-specific code (like the new perfmon support)
  -- New subarchitectures (e.g., SN1, ZX1)


4. Changes in mainline to fix things that break on IA64.
   (e.g., ACPI)

It seems to me that it *should* be possible to get all except category
2 synced into the mainline code.  One of the things I've been trying
to do occasionally is to compile a ia64-patched kernel on different
architectures to see what breaks.  Surprisingly little does.

BTW, I upgraded the BIOS on lemon.gelato.unsw.edu.au, the machine that
had the time haring off into the future.  It seems OK now.

One of the BIOS notes said that the AGP aperture for the I460GX was
fixed not to overlap the PCI space.  Does this mean that some of the
hacks in the DRM are no longer necessary?

--
Peter C					    peterc@gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all almost the same.

Re: [Linux-ia64] Missing files in to-linus-2.5 BK tree; build problems

[David Mosberger]

>>>>> On Thu, 30 May 2002 15:49:57 +1000, Peter Chubb <peter@chubb.wattle.id.au> said:

  Peter> It seems to me that it *should* be possible to get all except
  Peter> category 2 synced into the mainline code.  One of the things
  Peter> I've been trying to do occasionally is to compile a
  Peter> ia64-patched kernel on different architectures to see what
  Peter> breaks.  Surprisingly little does.

Yes, absolutely.  I'm working on that, but it's slower than I'd like
it to be.  The DRM patches are next, but not being a DRM expert
doesn't help.  Of course, I always appreciate help (as long as I'm
informed on who's submitting what).

  Peter> BTW, I upgraded the BIOS on lemon.gelato.unsw.edu.au, the
  Peter> machine that had the time haring off into the future.  It
  Peter> seems OK now.

Great!

  Peter> One of the BIOS notes said that the AGP aperture for the
  Peter> I460GX was fixed not to overlap the PCI space.  Does this
  Peter> mean that some of the hacks in the DRM are no longer
  Peter> necessary?

I don't think so.  The "hacks" are not workarounds; they reflect the
fact that on Itanium, CPU accesses to (AGP) memory do not go through
AGP GART translation (somebody please correct me if I got the details
wrong...).

	--david

Re: [Linux-ia64] Missing files in to-linus-2.5 BK tree; build problems

[Grant Grundler]

Peter Chubb wrote:
> Can you take a look at this and see if you think it's sane?
> I'm only doing this to get a clean compilation

Peter,
certainly.

> --- /tmp/geta3892	Thu May 30 14:53:10 2002
> +++ sba_iommu.c	Thu May 30 14:53:05 2002
> @@ -216,9 +216,10 @@
>  static int reserve_sba_gart = 1;
>  static struct pci_dev sac_only_dev;
>  
> -#define sba_sg_iova(sg) (sg->address)
> +#define sba_sg_iova(sg) (page_address((sg)->page) + (sg)->offset)
>  #define sba_sg_len(sg) (sg->length)
>  #define sba_sg_buffer(sg) (sg->orig_address)
> +#define sba_sg_clear_iova(sg) (sg->page = NULL,sg->offset = 0)

This isn't going to work. Later in the code:
		if ((u64)sba_sg_iova(startsg) & PIDE_FLAG) {
			u32 pide = (u64)sba_sg_iova(startsg) & ~PIDE_FLAG;
...


PIDE_FLAG was stuffed into address field in order to "mark" contiguous
DMA chunks. DMA coalescing was done in two passes on PARISC because DMA
coherency required knowing the virtual address each DMA was going to.
Obviously not true for ia64.

Maybe a single pass coalescing algorithm would obsolete
PIDE_FLAG (and the problem).
For HP ZX1, I'm really not happy with this algorithm.

Short term: Maybe use ->offset to stuff the PIDE_FLAG?

> @@ -1037,10 +1038,12 @@
>  		*/
>  		if ((u64)sba_sg_iova(startsg) & PIDE_FLAG) {
>  			u32 pide = (u64)sba_sg_iova(startsg) & ~PIDE_FLAG;
> +			char *vaddr;
>  			dma_offset = (unsigned long) pide & ~IOVP_MASK;
> -			sba_sg_iova(startsg) = 0;
>  			dma_sg++;
> -			sba_sg_iova(dma_sg) = (char *)(pide | ioc->ibase);
> +			vaddr = (char *)(pide | ioc->ibase);
> +			dma_sg->page = virt_to_page(vaddr);
> +			dma_sg->offset = (u64)vaddr * ~PAGE_MASK;
>  			pdirp = &(ioc->pdir_base[pide >> IOVP_SHIFT]);
>  			n_mappings++;
>  		}

This is where we "end" one DMA chunk and start the next.
Maybe "dma_sg->offset = dma_offset" instead of extracting offset again.


> @@ -1162,7 +1166,7 @@
>  				vcontig_end += sba_sg_len(startsg);
>  				dma_len     += sba_sg_len(startsg);
>  				sba_sg_buffer(startsg) = (char *)vaddr;
> -				sba_sg_iova(startsg) = 0;
> +				sba_sg_clear_iova(startsg);
>  				sba_sg_len(startsg) = 0;
>  				continue;
>  			}

GAH!
Anything related to vcontig_end should have been deleted.
It's an artifact from the parisc-linux port.

This really bugs me. I'll make some time in the next couple
of weeks to rewrite and test it, maybe sooner rather than later.
Note that my rewrite will be on 2.4 since that's what I can test.
I'll pickup the casts that were added in this patch.

Given the context, the rest of the changes look right.

thanks,
grant