August 2009 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] Digidesign Mbox2 - usb support
by Damien Zammit 16 Aug '09

16 Aug '09

Hi, I wrote an addition to usbquirks.h to provide support for "Digidesign Mbox 2" but I need someone to point me in the right direction as to which interfaces to use. I'm not sure if the MIDI interface is a standard device, and I'm not sure which interfaces to ignore. I am about to compile a new alsa + kernel with my changes to usbquirks.h to test the device. Here is my usbquirks.h addition: /* DIGIDESIGN MBOX 2 addition to usbquirks.h */ { /* Damien Zammit <damien.zammit(a)gmail.com> * 16 August 2009 * * Interface topology of Digidesign Mbox 2, it has 7 interfaces: * 0 - Proprietary firmware updates * 1 - Audio control device * 2 - Double endpoint IN-OUT PCM * 3 - Double endpoint OUT-IN PCM * 4 - Single endpoint IEC1937 AC3 / PCM (selectable by altsetting) * 5 - Single endpoint PCM (supports full 24bit 48000Hz) * 6 - Triple endpoint MIDI (Interrupt + 1 IN + 1 OUT) * * As I am unsure which interfaces to try, I have provided _all_ the settings * I can in this file to hand to the usb-audio developers. * I have no idea what .altset_idx does or where to find it, so I set it to 1 in all cases. * * I am currently testing with just interfaces 5 and 6 (not sure if it will work) */ USB_DEVICE(0x0dba, 0x3000), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .vendor_name = "Digidesign", .product_name = "Mbox 2", .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { /* Proprietary firmware updater interface - ignore for now */ { .ifnum = 0, .type = QUIRK_IGNORE_INTERFACE }, /* Audio control interface - altsetting = 0 not sure what to do with this */ { .ifnum = 1, .type = QUIRK_IGNORE_INTERFACE }, { .ifnum = 2, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .format = SNDDRV_PCM_FORMAT_S24_3LE, .channels = 2, .iface = 2, .altsetting = 3, /* 0 is also available but has no endpoints */ .altset_idx = 1, .endpoint = 0x03, /* IN or 0x83 OUT */ .ep_attr = 0x05, .rates = SNDRV_PCM_RATE_CONTINUOUS, .rate_min = 8000, .rate_max = 48000 } }, { .ifnum = 3, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .format = SNDDRV_PCM_FORMAT_S24_3LE, .channels = 2, .iface = 3, .altsetting = 3, /* 0 is also available, but has no endpoints */ .altset_idx = 1, .endpoint = 0x04, /* OUT or 0x84 IN */ .ep_attr = 0x05, .rates = SNDRV_PCM_RATE_CONTINUOUS, .rate_min = 8000, .rate_max = 48000 } }, { .ifnum = 4, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .format = <<<<< Type III - IEC1937_AC3 (16 bit) >>>>> .channels = 2, .iface = 3, .altsetting = 6, .altset_idx = 1, .endpoint = 0x04, .ep_attr = 0x05, .rates = SNDRV_PCM_RATE_CONTINUOUS, .rate_min = 8000, .rate_max = 48000 } }, { .ifnum = 5, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .format = SNDDRV_PCM_FORMAT_S24_3LE, .channels = 2, .iface = 5, .altsetting = 3, .altset_idx = 1, .endpoint = 0x86, /* Single endpoint only */ .ep_attr = 0x0D, .rates = SNDRV_PCM_RATE_CONTINUOUS, .rate_min = 8000, .rate_max = 48000 } }, { /* MIDI INTERFACE DESCRIPTION * Is this a standard USB MIDI device? * It has 2 Interface descriptors for the same altsetting... Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 6 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0 Undefined Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 6 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 0 */ .ifnum = 6, .type = QUIRK_MIDI_FIXED_ENDPOINT, .data = & (const struct snd_usb_midi_endpoint_info) { /* I am not certain of the "cables" flags or how * to find out what they are. */ .out_ep = 2, .out_interval = 0x00, .in_ep = 2, .in_interval = 0x00, .out_cables = 0x0001, .in_cables = 0x0001 } }, { .ifnum = -1 } } } },

1 0

Re: [alsa-devel] [PATCH] ALSA: hda: partially revert ALC268 quirk collapse
by Takashi Iwai 15 Aug '09

15 Aug '09

At Sat, 15 Aug 2009 16:38:46 +0400, Alexey Dobriyan wrote: > > Fix alsamixer inability to start: > > ALSA lib simple_none.c:1491:(simple_add1) helem (MIXER,'Master Playback Switch',0,3,0) appears twice or more > > ALC268 codec shipped with Toshiba Satellite X200 has ids 1179:ff00 and > began to match quirk table. > > If it doesn't match and auto-probe from BIOS is used, alsamixer works: > > hda_codec: Unknown model for ALC268, trying auto-probe from BIOS... > > 8871e5b91518a47284b6bc2603b44dbc79c85446 is first bad commit > commit 8871e5b91518a47284b6bc2603b44dbc79c85446 > Author: Takashi Iwai <tiwai(a)suse.de> > Date: Tue Jun 2 01:02:50 2009 +0200 > > ALSA: hda - Reorder and clean-up ALC268 quirk table > > Rearrange alc268_cfg_tbl[] in the order of vendor id, and group some > entries using SND_PCI_QUIRK_MASK(). > > Signed-off-by: Takashi Iwai <tiwai(a)suse.de> > > :040000 040000 2497bb6fc5305acf3191b8e9b82956ec0ea1aee9 6f1d9ff9fed20550a1b2b398c7d2d5fec705fcd9 M sound > > Signed-off-by: Alexey Dobriyan <adobriyan(a)gmail.com> Well, it's no right fix. The symptom implies that something wrong with the current model=toshiba, so fixing the quirk is the way to go at this moment. Could you give alsa-info.sh output (run with --no-upload option) as vanilla kernel? Run with both model=auto and without model option and attach both results to compare. The former means actually the condition as your patch does. thanks, Takashi

1 0

[alsa-devel] Digidesign Mbox2 - usb support
by Damien Zammit 15 Aug '09

15 Aug '09

I have a Digidesign Mbox2 and I am trying to write an open source alsa driver for it. It is a usb self powered device, and I used usbsnoop on the Windows XP drivers to capture the initialisation of the device. It doesn't seem to require any firmware, as I was able to playback the init code to the device over libusb and all the lights turned on (which hopefully means it's awaiting further instructions to play/record). I have written some C code which sends the init codes to the device using raw URB, but I really need someone who is familiar with snd-usb-audio to take a look at my lsusb output in case it is a standard device before I waste any more time on it. Please find the debugging output for my experimental initialisation driver here: http://cytdesign.com/mbox2/mbox2.tar.bz2 Note: After running my init codes, all the lights appeared on the device just as it does when you boot windows. Please contact me at damien.zammit [at] gmail.com if you are able to help. I'm not up to speed with mailing lists, I would prefer an email to my account if you are replying to me. Thanks, Damien Zammit

1 0

[alsa-devel] snd_pcm_delay, hw buffers and driver api (v2)
by Kai Vehmanen 15 Aug '09

15 Aug '09

Hi, as I got at least one reply, reposting this in a new thread to catch more people. Originally sent to alsa-devel thread: "[PATCH 11/20] OMAP: McBSP: Add link DMA mode selection)" http://kerneltrap.org/mailarchive/alsa-devel/2009/7/30/6272573 --- So not strictly related to the patch that started the original thread, but this touches on, and is a good example of, one question I've been wondering for some time now as an app developer. Could Takashi, Jaroslav, Mark, or others comment on this as well, perhaps? Dropping linux-omap as this is a generic ALSA question. On Wed, 12 Aug 2009, Jarkko Nikula wrote: [i.e. pcm_pointer == hw_ptr] > The threshold based transfer will cause that omap_pcm_pointer will > loose a bit its accuracy. Probably irrelevant but still better to play > safe at least over one kernel release before making it default. [...] > element: > 614 > 669 > 691 [...] > threshold: > 512 > 512 > 1024 > 1024 In both cases, this value (hw_ptr) shows the status of sending data to an separate entity, and one that has its own buffer (multiple ms) before the actual DAC/ADC. So when application developer uses snd_pcm_delay(), the result is not quite what the ALSA API says: alsa-lib.git/src/pcm/pcm.c: --cut-- * For playback the delay is defined as the time that a frame that is written * to the PCM stream shortly after this call will take to be actually * audible. It is as such the overall latency from the write call to the final * DAC. [...] int snd_pcm_delay(snd_pcm_t *pcm, snd_pcm_sframes_t *delayp) --cut-- Of course, there are many other cases where the same happens, as the latency of the HW (or where it is connected) is not known. But we also have many cases where we _do_ know more about the latency, and we are just missing the means to expose this info. I think this applies to this OMAP patch as well. E.g. the HW can tell fairly accurately the current status (i.e. which sample is played-out/captured _now_). Now that brings us to my question -- how to expose this info in an ALSA driver. Elsewhere in alsa-lib docs, there is more accurate description of current implementation and behaviour of snd_pcm_delay(): alsa-lib.git/src/pcm/pcm.c: --cut-- The function #snd_pcm_delay() returns the delay in samples. For playback, it means count of samples in the ring buffer before the next sample will be sent to DAC. --cut-- So e.g. the OMAP patch that this thread started from, complies with this definition, and element/threshold modes just differ in accuracy (although threshold implementation should warn the application with the SNDRV_PCM_INFO_BATCH flag). But how would a driver expose both bits of info to apps (in a standard fashion): 1) the hw_ptr for shuffling bits out of the ringbuffer, and 2) the delay to next played-out/captured sample. For application developers, (2) is the piece of info we are mostly interested in (if I write a sample now, how long it will be until it's played out). One obvious solution (that has been used already in other ALSA drivers) is to virtualize the hw_ptr, but this way you lose the accurate info about ringbuffer status. Ideally both pieces of info could be exposed. But as I see it, drivers currently can only implement "pointer" to relay this info. Jaroslav proposed some ideas earlier this year, but then the discussion faded: "Re: Driver code with mpc5200 pointer problem.", 2009-04-28 http://article.gmane.org/gmane.linux.alsa.devel/62170 Takashi made basicly the same point I've tried to make above "Re: Driver code with mpc5200 pointer problem.", 2009-04-28 http://article.gmane.org/gmane.linux.alsa.devel/62172 Mark also commented to the same thread: http://article.gmane.org/gmane.linux.alsa.devel/62176, 2009-04-28 Any update/ideas on this topic? Personally I think adding a new driver callback would make most sense, as that would allow to take full benefit from hardware that allows to query sample-accurate position of playout (i.e. not just support exposing a fixed latency). Of course that's potentially a big change. In alsa-lib, snd_pcm_hwsync() could call this driver callback, and a new variant of snd_pcm_delay() could present the information to the applications.

3 5

[alsa-devel] [PATCH] delete -spi suffix in name and free private data while registers fail
by Barry Song 14 Aug '09

14 Aug '09

Signed-off-by: Barry Song <21cnbao(a)gmail.com> --- sound/soc/codecs/ad1938.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/ad1938.c b/sound/soc/codecs/ad1938.c index 051f68c..e62b277 100644 --- a/sound/soc/codecs/ad1938.c +++ b/sound/soc/codecs/ad1938.c @@ -456,7 +456,7 @@ static int __devexit ad1938_spi_remove(struct spi_device *spi) static struct spi_driver ad1938_spi_driver = { .driver = { - .name = "ad1938-spi", + .name = "ad1938", .bus = &spi_bus_type, .owner = THIS_MODULE, }, @@ -543,6 +543,7 @@ static int ad1938_register(struct ad1938_priv *ad1938) ret = snd_soc_register_codec(codec); if (ret != 0) { dev_err(codec->dev, "Failed to register codec: %d\n", ret); + kfree(ad1938); return ret; } @@ -550,6 +551,7 @@ static int ad1938_register(struct ad1938_priv *ad1938) if (ret != 0) { dev_err(codec->dev, "Failed to register DAI: %d\n", ret); snd_soc_unregister_codec(codec); + kfree(ad1938); return ret; } -- 1.5.6.3

2 1

[alsa-devel] [PATCH 0/1 - v2] ASoC: TWL4030: Capture mixer string changes
by Peter Ujfalusi 14 Aug '09

14 Aug '09

Hello, Resending with the suggested changes: Before the patch the analog capture path strings ended up like this at the end: "Analog Left Capture Route Main mic Switch" These switches showed up in the playback tab of alsamixer, which was not nice. After the patch the strings will be like this: "Analog Left Main Mic Capture Switch" Which show up correctly in alsamixer as "Analog Left Main mic" under the capture tab. --- Peter Ujfalusi (1): ASoC: TWL4030: Fix for capture mixer strings sound/soc/codecs/twl4030.c | 46 +++++++++++++++++++++++-------------------- 1 files changed, 25 insertions(+), 21 deletions(-)

2 2

[alsa-devel] [PATCH] Allow passing platform_data to devices attached to AC97 bus
by Marek Vasut 14 Aug '09

14 Aug '09

Hi, I managed to put together this patch with huge help from Mark. It allows passing platform_data to devices on ac97 bus and implements this for pxa2xx- ac97. Please consider applying.

6 51

Re: [alsa-devel] [PATCHv3 14/20] OMAP: McBSP: Let element DMA mode hit retention also
by Eero Nurkkala 14 Aug '09

14 Aug '09

On Fri, 2009-08-14 at 05:19 +0200, ext Woodruff, Richard wrote: > > From: linux-omap-owner(a)vger.kernel.org [mailto:linux-omap- > > owner(a)vger.kernel.org] On Behalf Of Eduardo Valentin > > > The device no longer hits retention if element DMA > > mode is taken for at least the duration of the > > serial console timeout. Force element DMA mode to > > shut down through smartidle. > > Probably this behaves as you say but it seems possible that the bug is somewhere else in device handling. > For some reason unknown to us, if NO_IDLE mode is taken, and long enough of a arecord | aplay loop was tried (a minute or so), then, and when closing the loop, the device never hit retention anymore =) But after the fix, yes it does so. > The generic hope is you can set smart-idle + wakeups at init time and never need to touch them again. There are a few known cases where the hardware IP does have some bug which force you to dynamically play with bits. > Right. I did try to set them initially at device init (that was one of the first things I tried with McBSP), but things were not really working as expected. (Well, having iclk and fclk on and putting those at device init caused the whole HW device to jam). Another thing is, that if the McBSP is a slave (external clocking), then there will be unnecessary wakeups? If smart-idle + wakeups are always set? (and the slave clocks the McBSP WCLK and BCLK). BTW, are the wakeups active if McBSP is in reset state? > Clockactivity settings are usually static also, but depending on how you configure your device (slave or master clocking) you will need to dynamically set these. > It most you don't need all this dynamic twiddling of the idle protocol handshake bits. Doing it once at pm_init is what should be necessary. > One example which comes to mind is MMC with DMA mode. Early drivers were finding RET was gated once the driver was active. In the first pass port to 3430 the writer toggled smart/no/forced idle and the system went happily back to sleep. However, after some profiling it was seen that this method of putting the device down ended up causing the clock disable to the device to take a very long time. Another level of digging into documents was done and it was found that it was necessary to reset some command line as part of a clean shut down. Doing it this way allowed the system to idle, and the time to shut down clocks was just a few nS instead of uS. As I recall some status was not cleared until the reset of the line. It did happen that toggling through handshakes had a side effect of also clearing it, but not in the intended way. Whether a few uSec:s or nS:s, doesn't really matter in this case? (if that even was the case). > > Regards, > Richard W. -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

1 0

[alsa-devel] [PATCH 00/20] OMAP ASoC changes in DMA utilization
by Eduardo Valentin 13 Aug '09

13 Aug '09

Hellos guys, This series provides a way to allow DMA go to idle while performing playback/capture in OMAP3 devices using ASoC driver. The idea behind it is to do not use DMA element mode, but frame mode. In addition to that, it also configures McBSP threshold accordingly to alsa period. Also, McBSP wakeup signals are configured to generate wakeups for threshold events. Besides that, this series also include a way to allow choosing between element mode or the frame mode added here. Patches 1-15 are McBSP changes and, for this reason, are intended to be include in linux-omap tree. Patches 16-20 are OMAP ASoC driver changes, so, they are for alsa-devel. BR, Eduardo Valentin (11): OMAP: McBSP: Change wakeup signals OMAP: McBSP: Add IRQEN, IRQSTATUS, THRESHOLD2 and THRESHOLD1 registers. OMAP: McBSP: Use appropriate value for startup delay OMAP: McBSP: Add transmit/receive threshold handler OMAP: McBSP: Create and export max_(r|t)x_thres property OMAP: McBSP: Rename thres sysfs symbols OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold ASoC: OMAP: Use McBSP threshold again ASoC: OMAP: Make DMA 64 aligned ASoC: OMAP: Enable DMA burst mode ASoC: OMAP: Use DMA operating mode of McBSP Eero Nurkkala (7): OMAP: McBSP: Provide functions for ASoC frame syncronization OMAP: McBSP: Wakeups utilized OMAP: McBSP: Retain McBSP FCLK clockactivity OMAP: McBSP: Do not enable wakeups for no-idle mode OMAP: McBSP: Disable all wakeups upon exit OMAP: McBSP: Let element DMA mode hit retention also ASoC: Always syncronize audio transfers on frames Peter Ujfalusi (2): OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 OMAP: McBSP: Add link DMA mode selection arch/arm/mach-omap2/mcbsp.c | 5 + arch/arm/plat-omap/include/mach/mcbsp.h | 54 +++++ arch/arm/plat-omap/mcbsp.c | 343 ++++++++++++++++++++++++++++++- sound/soc/omap/omap-mcbsp.c | 16 ++- sound/soc/omap/omap-pcm.c | 57 +++++- 5 files changed, 468 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

8 66

[alsa-devel] [PATCH v2 1/2] ASoC: DaVinci: McASP driver enhacements
by Chaithrika U S 13 Aug '09

13 Aug '09

On DA830/OMAP-L137 and DA850/OMAP-L138 SoCs, the McASP peripheral has FIFO support. This FIFO provides additional data buffering. It also provides tolerance to variation in host/DMA controller response times. The read and write FIFO sizes are 256 bytes each. If FIFO is enabled, the DMA events from McASP are sent to the FIFO which in turn sends DMA requests to the host CPU according to the thresholds programmed. More details of the FIFO operation can be found at http://focus.ti.com/general/docs/lit/getliterature.tsp?literatureNumber= sprufm1&fileType=pdf This patch adds support for FIFO configuration. The platform data has a version field which differentiates the McASP on different SoCs. Signed-off-by: Chaithrika U S <chaithrika(a)ti.com> --- In this version of the patch, the davinci-i2s driver changes have been done to account acnt member introduced in the dma_params structure. Also, the DAI format addition has been removed from this patch. Applies to ALSA GIT tree on branch topic/asoc at http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=shortlog; h=topic/asoc sound/soc/davinci/davinci-i2s.c | 1 + sound/soc/davinci/davinci-mcasp.c | 105 ++++++++++++++++++++++++++++++++++--- sound/soc/davinci/davinci-mcasp.h | 5 ++ sound/soc/davinci/davinci-pcm.c | 4 +- sound/soc/davinci/davinci-pcm.h | 1 + 5 files changed, 107 insertions(+), 9 deletions(-) diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c index 2a56fb7..12a6c54 100644 --- a/sound/soc/davinci/davinci-i2s.c +++ b/sound/soc/davinci/davinci-i2s.c @@ -406,6 +406,7 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream *substream, return -EINVAL; } + dma_params->acnt = dma_params->data_type; rcr |= DAVINCI_MCBSP_RCR_RFRLEN1(1); xcr |= DAVINCI_MCBSP_XCR_XFRLEN1(1); diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index f0c0347..e672f43 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -102,6 +102,11 @@ /* Receive Buffer for Serializer n */ #define DAVINCI_MCASP_RXBUF_REG 0x280 +/* McASP FIFO Registers */ +#define DAVINCI_MCASP_WFIFOCTL (0x1010) +#define DAVINCI_MCASP_WFIFOSTS (0x1014) +#define DAVINCI_MCASP_RFIFOCTL (0x1018) +#define DAVINCI_MCASP_RFIFOSTS (0x101C) /* * DAVINCI_MCASP_PWREMUMGT_REG - Power Down and Emulation Management @@ -276,6 +281,13 @@ */ #define TXDATADMADIS BIT(0) +/* + * DAVINCI_MCASP_W[R]FIFOCTL - Write/Read FIFO Control Register bits + */ +#define FIFO_ENABLE BIT(16) +#define NUMEVT_MASK (0xFF << 8) +#define NUMDMA_MASK (0xFF) + #define DAVINCI_MCASP_NUM_SERIALIZER 16 static inline void mcasp_set_bits(void __iomem *reg, u32 val) @@ -345,6 +357,9 @@ static void mcasp_start_rx(struct davinci_audio_dev *dev) static void mcasp_start_tx(struct davinci_audio_dev *dev) { + u8 offset = 0, i; + u32 cnt; + mcasp_set_ctl_reg(dev->base + DAVINCI_MCASP_GBLCTLX_REG, TXHCLKRST); mcasp_set_ctl_reg(dev->base + DAVINCI_MCASP_GBLCTLX_REG, TXCLKRST); mcasp_set_ctl_reg(dev->base + DAVINCI_MCASP_GBLCTLX_REG, TXSERCLR); @@ -353,6 +368,19 @@ static void mcasp_start_tx(struct davinci_audio_dev *dev) mcasp_set_ctl_reg(dev->base + DAVINCI_MCASP_GBLCTLX_REG, TXSMRST); mcasp_set_ctl_reg(dev->base + DAVINCI_MCASP_GBLCTLX_REG, TXFSRST); mcasp_set_reg(dev->base + DAVINCI_MCASP_TXBUF_REG, 0); + for (i = 0; i < dev->num_serializer; i++) { + if (dev->serial_dir[i] == TX_MODE) { + offset = i; + break; + } + } + + /* wait for TX ready */ + cnt = 0; + while (!(mcasp_get_reg(dev->base + DAVINCI_MCASP_XRSRCTL_REG(offset)) & + TXSTATE) && (cnt < 100000)) + cnt++; + mcasp_set_reg(dev->base + DAVINCI_MCASP_TXBUF_REG, 0); } @@ -362,6 +390,13 @@ static void davinci_mcasp_start(struct davinci_audio_dev *dev, int stream) mcasp_start_tx(dev); else mcasp_start_rx(dev); + + /* enable FIFO */ + if (dev->txnumevt) + mcasp_set_bits(dev->base + DAVINCI_MCASP_WFIFOCTL, FIFO_ENABLE); + + if (dev->rxnumevt) + mcasp_set_bits(dev->base + DAVINCI_MCASP_RFIFOCTL, FIFO_ENABLE); } static void mcasp_stop_rx(struct davinci_audio_dev *dev) @@ -382,6 +417,13 @@ static void davinci_mcasp_stop(struct davinci_audio_dev *dev, int stream) mcasp_stop_tx(dev); else mcasp_stop_rx(dev); + + /* disable FIFO */ + if (dev->txnumevt) + mcasp_clr_bits(dev->base + DAVINCI_MCASP_WFIFOCTL, FIFO_ENABLE); + + if (dev->rxnumevt) + mcasp_clr_bits(dev->base + DAVINCI_MCASP_RFIFOCTL, FIFO_ENABLE); } static int davinci_mcasp_set_dai_fmt(struct snd_soc_dai *cpu_dai, @@ -401,7 +443,6 @@ static int davinci_mcasp_set_dai_fmt(struct snd_soc_dai *cpu_dai, mcasp_set_bits(base + DAVINCI_MCASP_PDIR_REG, (0x7 << 26)); break; - case SND_SOC_DAIFMT_CBM_CFM: /* codec is clock and frame master */ mcasp_clr_bits(base + DAVINCI_MCASP_ACLKXCTL_REG, ACLKXE); @@ -505,6 +546,8 @@ static int davinci_config_channel_size(struct davinci_audio_dev *dev, static void davinci_hw_common_param(struct davinci_audio_dev *dev, int stream) { int i; + u8 tx_ser = 0; + u8 rx_ser = 0; /* Default configuration */ mcasp_set_bits(dev->base + DAVINCI_MCASP_PWREMUMGT_REG, MCASP_SOFT); @@ -525,12 +568,37 @@ static void davinci_hw_common_param(struct davinci_audio_dev *dev, int stream) for (i = 0; i < dev->num_serializer; i++) { mcasp_set_bits(dev->base + DAVINCI_MCASP_XRSRCTL_REG(i), dev->serial_dir[i]); - if (dev->serial_dir[i] == TX_MODE) + if (dev->serial_dir[i] == TX_MODE) { mcasp_set_bits(dev->base + DAVINCI_MCASP_PDIR_REG, AXR(i)); - else if (dev->serial_dir[i] == RX_MODE) + tx_ser++; + } else if (dev->serial_dir[i] == RX_MODE) { mcasp_clr_bits(dev->base + DAVINCI_MCASP_PDIR_REG, AXR(i)); + rx_ser++; + } + } + + if (dev->txnumevt && stream == SNDRV_PCM_STREAM_PLAYBACK) { + if (dev->txnumevt * tx_ser > 64) + dev->txnumevt = 1; + + mcasp_mod_bits(dev->base + DAVINCI_MCASP_WFIFOCTL, tx_ser, + NUMDMA_MASK); + mcasp_mod_bits(dev->base + DAVINCI_MCASP_WFIFOCTL, + ((dev->txnumevt * tx_ser) << 8), NUMEVT_MASK); + mcasp_set_bits(dev->base + DAVINCI_MCASP_WFIFOCTL, FIFO_ENABLE); + } + + if (dev->rxnumevt && stream == SNDRV_PCM_STREAM_CAPTURE) { + if (dev->rxnumevt * rx_ser > 64) + dev->rxnumevt = 1; + + mcasp_mod_bits(dev->base + DAVINCI_MCASP_RFIFOCTL, rx_ser, + NUMDMA_MASK); + mcasp_mod_bits(dev->base + DAVINCI_MCASP_RFIFOCTL, + ((dev->rxnumevt * rx_ser) << 8), NUMEVT_MASK); + mcasp_set_bits(dev->base + DAVINCI_MCASP_RFIFOCTL, FIFO_ENABLE); } } @@ -543,6 +611,8 @@ static void davinci_hw_param(struct davinci_audio_dev *dev, int stream) for (i = 0; i < active_slots; i++) mask |= (1 << i); + mcasp_clr_bits(dev->base + DAVINCI_MCASP_ACLKXCTL_REG, TX_ASYNC); + if (stream == SNDRV_PCM_STREAM_PLAYBACK) { /* bit stream is MSB first with no delay */ /* DSP_B mode */ @@ -622,8 +692,16 @@ static int davinci_mcasp_hw_params(struct snd_pcm_substream *substream, struct davinci_pcm_dma_params *dma_params = dev->dma_params[substream->stream]; int word_length; + u8 numevt; davinci_hw_common_param(dev, substream->stream); + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + numevt = dev->txnumevt; + else + numevt = dev->rxnumevt; + + if (!numevt) + numevt = 1; if (dev->op_mode == DAVINCI_MCASP_DIT_MODE) davinci_hw_dit_param(dev); @@ -650,6 +728,13 @@ static int davinci_mcasp_hw_params(struct snd_pcm_substream *substream, printk(KERN_WARNING "davinci-mcasp: unsupported PCM format"); return -EINVAL; } + + if (dev->version == MCASP_VERSION_2) { + dma_params->data_type *= numevt; + dma_params->acnt = 4 * numevt; + } else + dma_params->acnt = dma_params->data_type; + davinci_config_channel_size(dev, word_length); return 0; @@ -778,6 +863,9 @@ static int davinci_mcasp_probe(struct platform_device *pdev) dev->num_serializer = pdata->num_serializer; dev->serial_dir = pdata->serial_dir; dev->codec_fmt = pdata->codec_fmt; + dev->version = pdata->version; + dev->txnumevt = pdata->txnumevt; + dev->rxnumevt = pdata->rxnumevt; dma_data[count].name = "I2S PCM Stereo out"; dma_data[count].eventq_no = pdata->eventq_no; @@ -807,9 +895,9 @@ static int davinci_mcasp_probe(struct platform_device *pdev) } dma_data[count].channel = res->start; - davinci_mcasp_dai[pdev->id].private_data = dev; - davinci_mcasp_dai[pdev->id].dev = &pdev->dev; - ret = snd_soc_register_dai(&davinci_mcasp_dai[pdev->id]); + davinci_mcasp_dai[pdata->op_mode].private_data = dev; + davinci_mcasp_dai[pdata->op_mode].dev = &pdev->dev; + ret = snd_soc_register_dai(&davinci_mcasp_dai[pdata->op_mode]); if (ret != 0) goto err_release_region; @@ -827,12 +915,13 @@ err_release_dev: static int davinci_mcasp_remove(struct platform_device *pdev) { + struct snd_platform_data *pdata = pdev->dev.platform_data; struct davinci_pcm_dma_params *dma_data; struct davinci_audio_dev *dev; struct resource *mem; - snd_soc_unregister_dai(&davinci_mcasp_dai[pdev->id]); - dev = davinci_mcasp_dai[pdev->id].private_data; + snd_soc_unregister_dai(&davinci_mcasp_dai[pdata->op_mode]); + dev = davinci_mcasp_dai[pdata->op_mode].private_data; clk_disable(dev->clk); clk_put(dev->clk); dev->clk = NULL; diff --git a/sound/soc/davinci/davinci-mcasp.h b/sound/soc/davinci/davinci-mcasp.h index 36b7104..554354c 100644 --- a/sound/soc/davinci/davinci-mcasp.h +++ b/sound/soc/davinci/davinci-mcasp.h @@ -50,6 +50,11 @@ struct davinci_audio_dev { u8 op_mode; u8 num_serializer; u8 *serial_dir; + u8 version; + + /* McASP FIFO related */ + u8 txnumevt; + u8 rxnumevt; }; #endif /* DAVINCI_MCASP_H */ diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c index ab43a53..091dacb 100644 --- a/sound/soc/davinci/davinci-pcm.c +++ b/sound/soc/davinci/davinci-pcm.c @@ -67,6 +67,7 @@ static void davinci_pcm_enqueue_dma(struct snd_pcm_substream *substream) dma_addr_t src, dst; unsigned short src_bidx, dst_bidx; unsigned int data_type; + unsigned short acnt; unsigned int count; period_size = snd_pcm_lib_period_bytes(substream); @@ -91,11 +92,12 @@ static void davinci_pcm_enqueue_dma(struct snd_pcm_substream *substream) dst_bidx = data_type; } + acnt = prtd->params->acnt; edma_set_src(lch, src, INCR, W8BIT); edma_set_dest(lch, dst, INCR, W8BIT); edma_set_src_index(lch, src_bidx, 0); edma_set_dest_index(lch, dst_bidx, 0); - edma_set_transfer_params(lch, data_type, count, 1, 0, ASYNC); + edma_set_transfer_params(lch, acnt, count, 1, 0, ASYNC); prtd->period++; if (unlikely(prtd->period >= runtime->periods)) diff --git a/sound/soc/davinci/davinci-pcm.h b/sound/soc/davinci/davinci-pcm.h index eb4287f..63d9625 100644 --- a/sound/soc/davinci/davinci-pcm.h +++ b/sound/soc/davinci/davinci-pcm.h @@ -19,6 +19,7 @@ struct davinci_pcm_dma_params { char *name; /* stream identifier */ int channel; /* sync dma channel ID */ + unsigned short acnt; dma_addr_t dma_addr; /* device physical address for DMA */ enum dma_event_q eventq_no; /* event queue number */ unsigned char data_type; /* xfer data type */ -- 1.5.6

2 1