[Linux-ia64] new ia64 kernel patch (relative to 2.5.69)

[Linux-ia64] new ia64 kernel patch (relative to 2.5.69)

[David Mosberger]

The kernel patch linux-2.5.69-ia64-030509.diff.gz is now available at
ftp.kernel.org/pub/linux/kernel/ports/ia64/v2.5/.  See the bitkeeper
pages for a detailed log.

This is a bit of a temporary patch because the ia32 subsystem is
currently broken (because of the ioctl changes; Arun, would you mind
taking a look?).  Other than that, things seem to work quite well for
me.  Apart from the simulator, I tried Big Sur, zx2000, zx6000, and
rx5670 (4-way Itanium 2).  The AGP GART stuff seems to be working for
both zx1 and i460, but I couldn't get DRM quite to work yet.  Some
sort of locking problem it appears.

Oh, Keith, you might like the fact that I added NEW_LOCK back again
and it's even turned on by default!  I talked to Cary Coutant and he
thinks it's OK to treat a save of ar.pfs in r0 as a special case.
Thus, we can use your scheme for now.  Also, I wrote a patch for
gcc3.4 which makes it possible to mark ar.pfs clobbered (subsequently,
Rich Henderson fixed and improved the patch which is now in the
official gcc cvs tree).  With this, we can generate an extremely
light-weight special call to the spinlock contention routine.  I tried
all 4 versions (old compiler, new compiler, merced vs mckinley) and
they all seemed to work fine.

At the moment, the spinlock contention routines do NOT do any backoff.
Someone with access to large machines might want to play with this.
I'd be very interested in hearing what kind of performance difference
it makes.

I hope to make an updated patch sometime next week (hopefully with the
ia32 subsystem working again).  So if I goofed somewhere else, send
patches.

Oh, and just a friendly reminder that Linus is making noises about
2.6.  So if you procrastinated with 2.5 so far, now is the time to get
going!

	--david

Re: [Linux-ia64] new ia64 kernel patch (relative to 2.5.69)

[David Mosberger]

Forgot to mention that I switched the ia64 tree from the PCI-DMA API
to the generic DMA API.  Doesn't affect device drivers, but all I/O
MMU support needs to be updated accordingly.  I already did swiotlb
and the HP SBA I/O MMU support.  I updated that machvec definitions
for all platforms, but didn't try to update the SN-specific
implementation (since I can't test it anyhow).  Updating the SN-files
should be straight-forward: you can look at swiotlb.c and
hp/common/sba_iommu.c for what needs to be done.

The one caveat is that sba_iommu.c for the moment continues to support
only PCI-devices.  This shouldn't be a problem for now, but it would
be nice if someone could fix it so it can work with any device.

While working on this, I started to wonder whether or not a DMA "sync"
operation should imply a memory barrier.  The API documentation is
definitely ambiguous on this point and I didn't go out to look whether
current practice is consistent (I suspect it isn't).  Anyone want to
argue for or against making "sync" a memory barrier?

	--david