Re: ep93xx I2S driver

On Wed, Jan 10, 2007 at 10:40:28PM -0500, Chase Douglas wrote:

> My I2S driver runs assuming the audio data is 24 bits. I saw that  
> ep93xx-pcm.c says the only allowed format is 16 bit. Since I'm not  
> quite sure what happens with the DMA stuff, what is the best way to  
> handle this?

The AC97 controller either delivers 16 bit or 32 bit samples to the
DMA controller.  Since ALSA doesn't have a format for 32 bit LE data,
I run the AC97 controller in 16 bit mode unconditionally (Compact
Mode Enable, I think the bit is called.)

Glancing at the I2S section of the EP9315 datasheet, it seems to have
an option for what word length to use on the wire (remember that I2S
uses variable word length), but not for what sample width to present
to the DMA controller, so I'm guessing it'll always use 32 bit
samples.  (The docs might be incorrect, though -- they are
occasionally.)  If there is indeed no other format it can read/write
data in, you might be forced to do the conversion to a sane format in
the PCM driver (ugh.)

(I wonder why ALSA doesn't have a 32bit sample format..)

Re: ep93xx I2S driver

Re: ep93xx I2S driver

On Thu, Jan 11, 2007 at 12:25:17PM +0000, Breton M. Saunders wrote:

> I believe that you always write 32 bit samples to the fifo.

(Yes, but if you enable Compact Mode on the AC97 controller, it puts
two 16bit samples in every 32bit word.)

(Note that the M2P FIFOs in hardware are really only 8 bits wide, which
is why you can run into situations where if you disable the DMA channel
while playback or recording is going on, only half-a-sample gets
transferred and subsequent attempts to play or record audio will only
yield noise.)

> This is why the Cirrus driver has format conversion routines in it,
> and converts buffers before DMAing them.

Probably because the I2S controller doesn't have this option.

If the Cirrus driver also does this for AC97, i.e. not enabling
Compact Mode on the AC97 controller and then converting samples by
hand to 16bit format, then that's a bit silly.

Re: ep93xx I2S driver

So what format of data samples is getting DMA'd to the I2S? Is it  
something like two 16 bit samples packed into one 32 bit "sample"? I  
would assume the I2S receives each 32 bit "sample" from the DMA and  
sends out the correct word length on I2S. I haven't seen any  
documentation to the contrary, unless it is in the DMA section. If  
that's the case, I assume I just need to either unpack the 16 bit  
samples into two separate 32 bit words if I use 16 bit I2S samples,  
or unpack and then shift if I use 24 bit samples (which is easier to  
set up due to the cs4271 codec on the edb9302a).

Where do the audio samples from user space actually get transferred  
to kernel space and then sent through the DMA? Is this where I should  
be mucking with it to get it to the right format?

Thanks

On Jan 11, 2007, at 8:18 AM, Lennert Buytenhek wrote:

> On Thu, Jan 11, 2007 at 12:25:17PM +0000, Breton M. Saunders wrote:
>
>> I believe that you always write 32 bit samples to the fifo.
>
> (Yes, but if you enable Compact Mode on the AC97 controller, it puts
> two 16bit samples in every 32bit word.)
>
> (Note that the M2P FIFOs in hardware are really only 8 bits wide,  
> which
> is why you can run into situations where if you disable the DMA  
> channel
> while playback or recording is going on, only half-a-sample gets
> transferred and subsequent attempts to play or record audio will only
> yield noise.)
>
>
>> This is why the Cirrus driver has format conversion routines in it,
>> and converts buffers before DMAing them.
>
> Probably because the I2S controller doesn't have this option.
>
> If the Cirrus driver also does this for AC97, i.e. not enabling
> Compact Mode on the AC97 controller and then converting samples by
> hand to 16bit format, then that's a bit silly.
>

Re: EP93xx Discontig patch rev 2

Hi Breton,

Do you know if your patch would also be applicable for the TS-72xx boards?

~/Chris

Breton M. Saunders wrote:
> Hi All,
> 
>  After a lot of debugging I have placed a revision of the discontig 
> memory patch on http://www.mynah-software.com/arm  .
> 
>  This patch should allow you to run a TS-7400 board, or boards using 
> ep93xx with identical memory maps.  It should no longer show a kernel 
> oops when the kernel function show_mem is invoked.
> 
>  Do let me know if you run into problems.  Email brett < at >  
> mynah-software.com for offline discussions.
> 
>    Cheers,
> 
>    -Brett
> 
> 
> 

Re: ep93xx I2S driver

I see that you can do 32 bit samples from the kernel source (not sure  
what you meant by ALSA not having 32 bit samples, Lennert), and if I  
were to do that I could push out the samples without having to muck  
with the data. Is this correct and possible? Do I need to change any  
of the pcm code other than setting the formats to 32 bit?

Thanks,
Chase

Re: ep93xx I2S driver

On Thu, Jan 11, 2007 at 02:10:43PM -0500, Chase Douglas wrote:

> I see that you can do 32 bit samples from the kernel source (not sure  
> what you meant by ALSA not having 32 bit samples, Lennert), and if I  
> were to do that I could push out the samples without having to muck  
> with the data. Is this correct and possible? Do I need to change any  
> of the pcm code other than setting the formats to 32 bit?

Hmm.  I remember checking this a while ago and not finding a 32 bit
sample format in ALSA.  I checked current kernel sources and it does
appear to support 32 bit sample format (SNDRV_PCM_FMTBIT_U32_[BL]E.)
Maybe I was just confused with something else.

In any case, you're right, if you set this, then in theory ALSA should
hand data to you in 32bit sample format, and you should then be able
to shove the data directly into the DMA controller.  Not mucking with
the data in the i2s/pcm driver is the preferable option by far, IMHO.

*makes mental note to add 32bit sample support to the AC97 driver*

Re: ep93xx I2S driver

On Thu, Jan 11, 2007 at 08:18:10PM +0100, Lennert Buytenhek wrote:

> > I see that you can do 32 bit samples from the kernel source (not sure  
> > what you meant by ALSA not having 32 bit samples, Lennert), and if I  
> > were to do that I could push out the samples without having to muck  
> > with the data. Is this correct and possible? Do I need to change any  
> > of the pcm code other than setting the formats to 32 bit?
> 
> Hmm.  I remember checking this a while ago and not finding a 32 bit
> sample format in ALSA.  I checked current kernel sources and it does
> appear to support 32 bit sample format (SNDRV_PCM_FMTBIT_U32_[BL]E.)
> Maybe I was just confused with something else.
> 
> In any case, you're right, if you set this, then in theory ALSA should
> hand data to you in 32bit sample format, and you should then be able
> to shove the data directly into the DMA controller.  Not mucking with
> the data in the i2s/pcm driver is the preferable option by far, IMHO.

Actually, I take that back.  When Compact Mode is off (and thus, the
AC97 controller uses 32 bits per sample word), I remember samples being
aligned towards the LSB instead of the MSB.  So instead of getting
0xfffff000 for a 20-bit sample, you'd get 0x000fffff.

I'm not sure whether the I2S controller does this in the same way or
not.

Re: EP93xx Discontig patch rev 2

Christopher Friedt wrote:
> Hi Breton,
>
> Do you know if your patch would also be applicable for the TS-72xx 
> boards?
>
Hi Christopher,

  Check the wiring diagram for your board.  If it is 32MiB on a single 
SDRAM chip with CS wired to SD_CS3 you won't need my patch (it should 
work without it and slightly faster).  If it is two 32MiB chips wired to 
SD_CS3# and SD_CS2# my patch should get the kernel to boot and work 
properly.  I have not tested other configurations as I don't have the 
hardware - however, the function that maps pages to node ids should 
support all of the possible EP9302 memory configurations.  Do let me 
know if you get the board working with a different configuration, or 
have problems.

    Cheers,

       -Brett

> ~/Chris
>
> Breton M. Saunders wrote:
>> Hi All,
>>
>>  After a lot of debugging I have placed a revision of the discontig 
>> memory patch on http://www.mynah-software.com/arm  .
>>
>>  This patch should allow you to run a TS-7400 board, or boards using 
>> ep93xx with identical memory maps.  It should no longer show a kernel 
>> oops when the kernel function show_mem is invoked.
>>
>>  Do let me know if you run into problems.  Email brett < at >  
>> mynah-software.com for offline discussions.
>>
>>    Cheers,
>>
>>    -Brett
>>
>>
>>

Re: ep93xx I2S driver

On Jan 11, 2007, at 2:24 PM, Lennert Buytenhek wrote:

> On Thu, Jan 11, 2007 at 08:18:10PM +0100, Lennert Buytenhek wrote:
>
>>> I see that you can do 32 bit samples from the kernel source (not  
>>> sure
>>> what you meant by ALSA not having 32 bit samples, Lennert), and if I
>>> were to do that I could push out the samples without having to muck
>>> with the data. Is this correct and possible? Do I need to change any
>>> of the pcm code other than setting the formats to 32 bit?
>>
>> Hmm.  I remember checking this a while ago and not finding a 32 bit
>> sample format in ALSA.  I checked current kernel sources and it does
>> appear to support 32 bit sample format (SNDRV_PCM_FMTBIT_U32_[BL]E.)
>> Maybe I was just confused with something else.
>>
>> In any case, you're right, if you set this, then in theory ALSA  
>> should
>> hand data to you in 32bit sample format, and you should then be able
>> to shove the data directly into the DMA controller.  Not mucking with
>> the data in the i2s/pcm driver is the preferable option by far, IMHO.
>
> Actually, I take that back.  When Compact Mode is off (and thus, the
> AC97 controller uses 32 bits per sample word), I remember samples  
> being
> aligned towards the LSB instead of the MSB.  So instead of getting
> 0xfffff000 for a 20-bit sample, you'd get 0x000fffff.
>
> I'm not sure whether the I2S controller does this in the same way or
> not.

Well, you can tell the I2S controller to shift it out MSB or LSB  
first, so we should be able to overcome that.