Date: Mon, 2 Oct 2006 17:12:37 -0400 From: John Baldwin <jhb@freebsd.org> To: Ariff Abdullah <ariff@freebsd.org> Cc: phk@phk.freebsd.dk, freebsd-current@freebsd.org Subject: Re: sound/driver/hda and ia64 Message-ID: <200610021712.38017.jhb@freebsd.org> In-Reply-To: <20061003043453.334093bd.ariff@FreeBSD.org> References: <59493.1159791753@critter.freebsd.dk> <200610021500.00727.jhb@freebsd.org> <20061003043453.334093bd.ariff@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 02 October 2006 16:34, Ariff Abdullah wrote:
> On Mon, 2 Oct 2006 14:59:59 -0400
> John Baldwin <jhb@freebsd.org> wrote:
> > On Monday 02 October 2006 08:50, Ariff Abdullah wrote:
> > > On Mon, 02 Oct 2006 12:22:33 +0000
> > > Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> > > >
> > > > During a "make universe" ia64 fails with the following errors.
> > > >
> > > > I wouldn't expect a sound driver to call any of those functions
> > > > at all, what's going on ?
> > > >
> > > >
> [....]
> > > >
> > >
> > > I wish BUS_DMA_NOCACHE has real meaning (like what NetBSD did)
> > > since uncached DMA is pretty much guarantee to make the driver
> > > works on broken i386/amd86 hardwares.
> > >
> > > Should we just narrow this down to i386/amd64 , or give
> > > BUS_DMA_NOCACHE a real meaning as part of bus_dmamem_alloc() ?
> > >
> > > I'm open for suggestion.
> >
> > I can probably fix NOCACHE for i386/amd64 for the bus_dmamem_alloc()
> > case. Try this patch:
> >
> > --- //depot/vendor/freebsd/src/sys/amd64/amd64/busdma_machdep.c 2006/06/01
> > 04:50:42
> > +++ //depot/user/jhb/acpipci/amd64/amd64/busdma_machdep.c 2006/10/02
18:58:21
> > @@ -48,6 +48,7 @@
> > #include <machine/atomic.h>
> > #include <machine/bus.h>
> > #include <machine/md_var.h>
> > +#include <machine/specialreg.h>
> >
> > #define MAX_BPAGES 8192
> >
> > @@ -522,6 +523,9 @@
> > } else if ((uintptr_t)*vaddr & (dmat->alignment - 1)) {
> > printf("bus_dmamem_alloc failed to align memory properly.");
> > }
> > + if (flags & BUS_DMA_NOCACHE)
> > + pmap_change_attr((vm_offset_t)*vaddr, dmat->maxsize,
> > + PAT_UNCACHEABLE);
> > CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x error %d",
> > __func__, dmat, dmat->flags, ENOMEM);
> > return (0);
> > --- //depot/vendor/freebsd/src/sys/i386/i386/busdma_machdep.c 2006/09/26
> > 23:16:33
> > +++ //depot/user/jhb/acpipci/i386/i386/busdma_machdep.c 2006/10/02
18:58:21
> > @@ -51,6 +51,7 @@
> > #include <machine/atomic.h>
> > #include <machine/bus.h>
> > #include <machine/md_var.h>
> > +#include <machine/specialreg.h>
> >
> > #define MAX_BPAGES 512
> > #define BUS_DMA_COULD_BOUNCE BUS_DMA_BUS3
> > @@ -530,6 +531,9 @@
> > } else if ((uintptr_t)*vaddr & (dmat->alignment - 1)) {
> > printf("bus_dmamem_alloc failed to align memory
> > properly.\n");
> > }
> > + if (flags & BUS_DMA_NOCACHE)
> > + pmap_change_attr((vm_offset_t)*vaddr, dmat->maxsize,
> > + PAT_UNCACHEABLE);
> > CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x error %d",
> > __func__, dmat, dmat->flags, ENOMEM);
> > return (0);
> >
> >
> I guess these are what we're looking for. I can't tell whether it
> really works or not (finding such buggy hardware is quite difficult),
> but this will make lot of things easier for drivers.
>
> Any objections? I guess you should go ahead, John.
It needs testing. :) Can you find a victim?
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610021712.38017.jhb>