Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Oct 2006 04:34:53 +0800
From:      Ariff Abdullah <ariff@FreeBSD.org>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        phk@phk.freebsd.dk, freebsd-current@FreeBSD.org
Subject:   Re: sound/driver/hda and ia64
Message-ID:  <20061003043453.334093bd.ariff@FreeBSD.org>
In-Reply-To: <200610021500.00727.jhb@freebsd.org>
References:  <59493.1159791753@critter.freebsd.dk> <20061002205039.301fa766.ariff@FreeBSD.org> <200610021500.00727.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--Signature=_Tue__3_Oct_2006_04_34_53_+0800_GkbTOLMKrw8lxm0_
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
> > >=20
> > > During a "make universe" ia64 fails with the following errors.
> > >=20
> > > I wouldn't expect a sound driver to call any of those functions
> > > at all, what's going on ?
> > >=20
> > >=20
[....]
> > >
> >=20
> > 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.
> >=20
> > Should we just narrow this down to i386/amd64 , or give
> > BUS_DMA_NOCACHE a real meaning as part of bus_dmamem_alloc() ?
> >=20
> > I'm open for suggestion.
>=20
> I can probably fix NOCACHE for i386/amd64 for the bus_dmamem_alloc()
> case. Try this patch:
>=20
> --- //depot/vendor/freebsd/src/sys/amd64/amd64/busdma_machdep.c	2006/06/0=
1=20
> 04:50:42
> +++ //depot/user/jhb/acpipci/amd64/amd64/busdma_machdep.c	2006/10/02 18:5=
8:21
> @@ -48,6 +48,7 @@
>  #include <machine/atomic.h>
>  #include <machine/bus.h>
>  #include <machine/md_var.h>
> +#include <machine/specialreg.h>
> =20
>  #define MAX_BPAGES 8192
> =20
> @@ -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=
=20
> 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>
> =20
>  #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);
>=20
>=20
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.


--
Ariff Abdullah
FreeBSD

... Recording in stereo is obviously too advanced
    and confusing for us idiot ***** users :P ........

--Signature=_Tue__3_Oct_2006_04_34_53_+0800_GkbTOLMKrw8lxm0_
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFFIXfwlr+deMUwTNoRAjOWAJ0YNZzldmP3LlU//BD7TM6dZzQ5nQCgoAvo
uPFyHtyJKrx0Ts/Wl8Xu6UM=
=QJe/
-----END PGP SIGNATURE-----

--Signature=_Tue__3_Oct_2006_04_34_53_+0800_GkbTOLMKrw8lxm0_--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061003043453.334093bd.ariff>