Re: Emu10k1 SPDIF passthru doesn't work if CONFIG_NOHIGHMEM is not enabled

Re: Emu10k1 SPDIF passthru doesn't work if CONFIG_NOHIGHMEM is not enabled

[German Gomez Garcia]

On 24 Feb 2002, José Carlos Monteiro wrote:

> Hi!
> After some more careful testing, I was able to identify the exact moment
> when the changes in the Linux kernel broke SPDIF passthru of Emu10k1
> cards. I tested all the pre-patches between kernels 2.4.12 and 2.4.13
> and I found that kernel 2.4.13-pre2 was the one that broke it. Up until
> 2.4.13-pre1, everything works fine. From 2.4.13-pre2 on, passthru sound
> is broken (if kernel option CONFIG_HIGHMEM4G or CONFIG_HIGHMEM64G is
> used).
>
> According to the kernel Changelog, it appears that one of these changes
> was the responsible for it:
>
> 2.4.13-pre2:
> - Alan Cox: more merging
> - Ben Fennema: UDF module license
> - Jeff Mahoney: reiserfs endian safeness
> - Chris Mason: reiserfs O_SYNC/fsync performance improvements
> - Jean Tourrilhes: wireless extension update
> - Joerg Reuter: AX.25 updates
> - David Miller: 64-bit DMA interfaces

	Does the emu10k1 driver support the new DMA interface? I've
downloaded the patch-2.4.13-pre1-pre2.bz2 from

ftp://ftp.kernel.org/pub/linux/kernel/v2.4/testing/incr/

and checking it, it seems that the BIG change was the inclussion of
David Miller 64-bit DMA. Does emu10k1 use DMA for SPDIF output? the
main change affecting dma when HIGHMEM is enabled is in types.h, that
define dma_addr_t as a u64 instead of u32, so does the hardware in the
live or the driver (or whatever :-) support that?

	Best regards,

	- german

-------------------------------------------------------------------------
German Gomez Garcia          | Send email with "SEND GPG KEY" as subject
<german@piraos.com>          | to receive my GnuPG public key.

Re: [Emu10k1-devel] Re: Emu10k1 SPDIF passthru doesn't work if CONFIG_NOHIGHMEM is not enabled

[Rui Sousa]

On Tue, 26 Feb 2002, German Gomez Garcia wrote:

> On 24 Feb 2002, José Carlos Monteiro wrote:
> 
> > Hi!
> > After some more careful testing, I was able to identify the exact moment
> > when the changes in the Linux kernel broke SPDIF passthru of Emu10k1
> > cards. I tested all the pre-patches between kernels 2.4.12 and 2.4.13
> > and I found that kernel 2.4.13-pre2 was the one that broke it. Up until
> > 2.4.13-pre1, everything works fine. From 2.4.13-pre2 on, passthru sound
> > is broken (if kernel option CONFIG_HIGHMEM4G or CONFIG_HIGHMEM64G is
> > used).
> >
> > According to the kernel Changelog, it appears that one of these changes
> > was the responsible for it:
> >
> > 2.4.13-pre2:
> > - Alan Cox: more merging
> > - Ben Fennema: UDF module license
> > - Jeff Mahoney: reiserfs endian safeness
> > - Chris Mason: reiserfs O_SYNC/fsync performance improvements
> > - Jean Tourrilhes: wireless extension update
> > - Joerg Reuter: AX.25 updates
> > - David Miller: 64-bit DMA interfaces
> 
> 	Does the emu10k1 driver support the new DMA interface? I've
> downloaded the patch-2.4.13-pre1-pre2.bz2 from

We allocate memory with pci_alloc_consistent() which according to
DMA-mapping.txt assures 32-bits PCI addresses. On top of that
we set a dma_mask (with pci_set_dma_mask) of 29 bits (512Mib).

> ftp://ftp.kernel.org/pub/linux/kernel/v2.4/testing/incr/
> 
> and checking it, it seems that the BIG change was the inclussion of
> David Miller 64-bit DMA. Does emu10k1 use DMA for SPDIF output?

It uses DMA for all sound input/output.

> the
> main change affecting dma when HIGHMEM is enabled is in types.h, that
> define dma_addr_t as a u64 instead of u32, so does the hardware in the
> live or the driver (or whatever :-) support that?
> 
> 	Best regards,
> 
> 	- german

The most bizzare is that in a machine with 192Mib of memory but with a 
kernel compiled with HIGHMEM support I see the same type of problems.


Rui Sousa

Re: [Emu10k1-devel] Re: Emu10k1 SPDIF passthru doesn't work if

[Alan Cox]

> The most bizzare is that in a machine with 192Mib of memory but with a=20
> kernel compiled with HIGHMEM support I see the same type of problems.

Change of size in a structure or type ?

Re: [Emu10k1-devel] Re: Emu10k1 SPDIF passthru doesn't work if

[Rui Sousa]

On Wed, 27 Feb 2002, Alan Cox wrote:

It's true dma_addr_t does change from u32 to u64 and we do thinks like:

(32 bit pci register) = cpu_to_le32(dma_handle)

What is the correct way of doing this?

(32 bit pci register) = cpu_to_le32((u32)dma_handle)
?

Rui Sousa

> > The most bizzare is that in a machine with 192Mib of memory but with a=20
> > kernel compiled with HIGHMEM support I see the same type of problems.
> 
> Change of size in a structure or type ?
> 
> _______________________________________________
> Emu10k1-devel mailing list
> Emu10k1-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emu10k1-devel
> 

Re: [Emu10k1-devel] Re: Emu10k1 SPDIF passthru doesn't work if

[Jeff Garzik]

Rui Sousa wrote:
> 
> On Wed, 27 Feb 2002, Alan Cox wrote:
> 
> It's true dma_addr_t does change from u32 to u64 and we do thinks like:
> 
> (32 bit pci register) = cpu_to_le32(dma_handle)
> 
> What is the correct way of doing this?
> 
> (32 bit pci register) = cpu_to_le32((u32)dma_handle)

If you only have 32 bits, then I presume 64-bit DMA isn't supported.

So, (1) never pass more than 0xffffffff to pci_set_dma_mask, and (2)
just truncate dma_addr_t (addr & 0xffffffff) so that you only read the
low 32-bits, always.

	Jeff



-- 
Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

Re: [Emu10k1-devel] Re: Emu10k1 SPDIF passthru doesn't work if

[Alan Cox]

> It's true dma_addr_t does change from u32 to u64 and we do thinks like:
> (32 bit pci register) = cpu_to_le32(dma_handle)
> 
> What is the correct way of doing this?
> (32 bit pci register) = cpu_to_le32((u32)dma_handle)

The cast befor ethe cpu_to_ is safe if its 32bit I/O only. Maybe we should
have cpu_to_le_dma_addr_t 8)

Re: [Emu10k1-devel] Re: Emu10k1 SPDIF passthru doesn't work if

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Fri, 1 Mar 2002 01:07:27 +0000 (GMT)
   
   The cast befor ethe cpu_to_ is safe if its 32bit I/O only. Maybe we should
   have cpu_to_le_dma_addr_t 8)

Actually, the cast to 32-bit is safe if you've set your DMA mask
properly :-)

Re: [Emu10k1-devel] Re: Emu10k1 SPDIF passthru doesn't work if

[Daniel Bertrand]

Hi,

Looks like the bug is from pushing the 64bit dma_handle on a 32bit va_arg 
list. Its fixed in CVS, and at least one person has reported success.


On Thu, 28 Feb 2002, David S. Miller wrote:

>    From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>    Date: Fri, 1 Mar 2002 01:07:27 +0000 (GMT)
>    
>    The cast befor ethe cpu_to_ is safe if its 32bit I/O only. Maybe we should
>    have cpu_to_le_dma_addr_t 8)
> 
> Actually, the cast to 32-bit is safe if you've set your DMA mask
> properly :-)
> 

-- 
Daniel Bertrand

64bit dma_addr_t (was: Emu10k1 SPDIF ...)

[Daniel Bertrand]

Hi,

Sorry to beat a dead horse, but wouldn't it be better if sizes didn't
change within the same CPU arch? I don't see how binary-only modules can
ever work reliably if the size of types change depending on people's
.config file. (not that I use any binary-only modules :-).

Is this a common thing done in the kernel? For dma_addr_t, why not just
have it always be 64bit?


On Thu, 28 Feb 2002, David S. Miller wrote:

>    From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>    Date: Fri, 1 Mar 2002 01:07:27 +0000 (GMT)
>    
>    The cast befor ethe cpu_to_ is safe if its 32bit I/O only. Maybe we should
>    have cpu_to_le_dma_addr_t 8)
> 
> Actually, the cast to 32-bit is safe if you've set your DMA mask
> properly :-)
> 

-- 
Daniel Bertrand