Audio on Sunblade 100

[Marius Strobl]

On Wed, Aug 19, 2009 at 10:56:10AM -0700, Pyun YongHyeon wrote:
> On Tue, Aug 18, 2009 at 09:27:48PM +0200, Marius Strobl wrote:
> > On Mon, Aug 17, 2009 at 11:56:12PM +0200, Marius Strobl wrote:
> > > On Mon, Aug 17, 2009 at 10:53:40PM +0200, Marius Strobl wrote:
> > > > On Fri, Aug 07, 2009 at 07:58:40PM +0200, Christian Ramseyer wrote:
> > > > > Hi
> > > > > 
> > > > > I'm trying to get sound on a Sunblade 100 with 7.2R. I've added
> > > > > 
> > > > > device          sound
> > > > > device          snd_t4dwave
> > > > > 
> > > > > to the kernel and recompiled. pciconf shows an attached driver:
> > > > > 
> > > > > pcm0 at pci0:0:8:0:        class=0x040100 card=0x545110b9 chip=0x545110b9
> > > > > rev=0x01 hdr=0x00
> > > > >     vendor     = 'Acer Labs Incorporated (ALi/ULi)'
> > > > >     device     = 'ALI M5451 PCI AC-Link Controller Audio Device'
> > > > >     class      = multimedia
> > > > >     subclass   = audio
> > > > > 
> > > > > However, there are errors in dmesg:
> > > > > 
> > > > > pcm0: <Acer Labs M5451> port 0x900-0x9ff mem 0x424000-0x424fff at device
> > > > > 8.0 on pci0
> > > > > pcm0: <Analog Devices AD1881A AC97 Codec>
> > > > > pcm0: [GIANT-LOCKED]
> > > > > pcm0: [ITHREAD]
> > > > > pcm0: chn_init(pcm0:record:dsp0.r0) failed: err = 19
> > > > > pcm0: pcm_chn_create(trrchan, -1, 0xfffff80001370800) failed
> > > > > pcm0: chn_init(pcm0:play:dsp0.p0) failed: err = 19
> > > > > pcm0: pcm_chn_create(trpchan, 1, 0xfffff80001370800) failed
> > > > > 
> > > > > I've also found this message from 2006:
> > > > > http://lists.freebsd.org/mailman/htdig/freebsd-sparc64/2006-June/004168.html
> > > > > 
> > > > > So, am I just doing something wrong or are there problems with 5451
> > > > > audio on SPARC? I see that the release notes only list i386 and amd64 as
> > > > >  architectures for the t4dwave driver.
> > > > > 
> > > > > By the way, thanks a lot for all the work your guys are doing in general
> > > > > and for the SPARC port in particular. I'm currently trying BSD for the
> > > > > first time in my life and I like it a lot. It runs surprisingly well on
> > > > > this outdated platform.
> > > > > 
> > > > 
> > > > Could you (or any other Blade 100 user) please give the following
> > > > patch at try?
> > > > http://people.freebsd.org/~marius/t4dwave_sparc64_32-bit.diff
> > > > This gets at least the line-out of the M5451 in my Blade 1500
> > > > working (I've no idea whether its internal speaker is also
> > > > connected to the sound chip like for example in a Blade 1000
> > > > and thus supposed to also work or just to a PC-style beeper,
> > > > the firmware at least makes it beep that way...), but which
> > > > also has a newer revision of this chip.
> > > > 
> > > 
> > > Looks like I've spoken to soon; it only works when it happens
> > > to get certain buffer addresses, otherwise nothing is played
> > > and the interrupt times out (which according to google isn't
> > > a sparc64 specific problem). This probably means that some
> > > bus_dma(9) parameters are incorrect...
> > > 
> > 
> > Ok, I think I've identified the incorrect bus_dma(9) settings
> > with the help of Tatsuo YOKOGAWA's ali(4) (which as least for
> > the alignment requirement also matches the NetBSD autri(4). A
> > new patch is at:
> > http://people.freebsd.org/~marius/t4dwave_M5451_32-bit.diff
> 
> The patch looks good to me but I have two questions. The alignment
> restriction specified in bus_dma_tag_create(9) really works even
> if the alignment is greater than PAGE_SIZE? I vaguely remember
> the alignment was not satisfied last time I tried it on i386 if I
> specified 256K.

Hrm, from a quick check of the i386 busdma and the sparc64
busdma and IOMMU code I see no indication why such an
alignment shouldn't work as expected, neither do relevant
man pages like bus_dma(9) and contigmalloc(9) indicate a
restriction to PAGE_SIZE. Based on the addresses of the
buffers I get on sparc64 (f.e. 0xc0000000 and 0xc0020000)
I'd also say it just works. But before possibly commiting
this change I've to also run-time check it on i386 anyway.

> The second question is number of channels
> supported for M5451. If I remember correctly there are some
> differences among 4D wave compatible chips and M5451 may have 32
> channels instead of 64.

Well, r173511 limited the driver to effectively only use
one channel with M5451 and given that the same change added
a knob I suspect that it was also actually tested with more
than one channel but that also failed. Do you mean that the
interation in the interrupt handler should be limited to 32
(according to the M1535 datasheet [1] that number is correct)
for M5451 or maybe also to the number of channels registered?

Marius

[1]: www.nvidia.com/docs/CP/29993/m1535dm_web.pdf