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

[alsa-devel] HDSPM - Problems with SyncIn
by Andre Schramm 19 Oct '12

19 Oct '12

Hello, I did some tests with the SyncIn-Feature of the HDSPe cards. [root@localhost ~]# lspci |grep Mult 01:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP MADI (rev d2) 02:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP MADI (rev d2) The SyncOut of card 2:00 was plugged to the SyncIn of 1:00 and 1:00 was put to AutoSync-mode automatically upon boot. Problem is that the amixer output seems to be inconsistent and differs from the proc output as well, so I'm not sure which one to trust. [root@localhost ~]# amixer -c0 contents numid=5,iface=MIXER,name='AutoSync Reference' ; type=ENUMERATED,access=r-------,values=1,items=5 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'TCO' ; Item #3 'Sync In' ; Item #4 'None' : values=3 numid=2,iface=MIXER,name='Internal Clock' ; type=ENUMERATED,access=rw------,values=1,items=9 ; Item #0 '32 kHz' ; Item #1 '44.1 kHz' ; Item #2 '48 kHz' ; Item #3 '64 kHz' ; Item #4 '88.2 kHz' ; Item #5 '96 kHz' ; Item #6 '128 kHz' ; Item #7 '176.4 kHz' ; Item #8 '192 kHz' : values=2 numid=4,iface=MIXER,name='Preferred Sync Reference' ; type=ENUMERATED,access=rw------,values=1,items=3 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'Sync In' : values=2 numid=10,iface=MIXER,name='SYNC IN SyncCheck' ; type=ENUMERATED,access=r-------,values=1,items=4 ; Item #0 'No Lock' ; Item #1 'Lock' ; Item #2 'Sync' ; Item #3 'N/A' : values=0 numid=3,iface=MIXER,name='System Clock Mode' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'Master' ; Item #1 'AutoSync' : values=1 numid=6,iface=MIXER,name='System Sample Rate' ; type=INTEGER,access=r-------,values=1,min=27000,max=207000,step=1 : values=47999 'Preferred Sync Reference' is SyncIn, 'SYNC IN SyncCheck' says 'No Lock', meaning no signal at all, but the 'System Sample Rate' coming from the master card is detected with 1Hz offset. When putting the master to 32000Hz, 31999Hz are shown and so on. [root@localhost ~]# cat /proc/asound/card0/hdspm RME MADI (Card #1) Rev.d2 Status2first3bits: 1 HW Serial: 0x0000019196d4 IRQ: 16 Registers bus: 0xfe9f0000 VM: 0xf8920000 --- System --- IRQ Pending: Audio=0, MIDI0=0, MIDI1=0, IRQcount=0 HW pointer: id = 0, rawptr = 0 (0->16320) estimated= 0 (bytes) MIDI FIFO: Out1=0x0, Out2=0x0, In1=0x0, In2=0x0 MIDIoverMADI FIFO: In=0x0, Out=0x0 Register: ctrl1=0x10344ca, ctrl2=0x0, status1=0xc30004, status2=0xc0020361 No TCO module detected. --- Settings --- Size (Latency): 2048 samples (2 periods of 8192 bytes) Line out: on ClearTrackMarker = off, Transmit in 64 Channel Mode, Auto Input off AutoSync Reference: AutoSync Preferred Sync Reference: TCO System Clock Frequency: 48000 --- Status: Inputs MADI=NoLock, WordClock=NoLock AutoSync: Reference= Sync In, Freq=0 (MADI = 3, Word = 3) Input: Coax, Mode=56 channels Now the proc-output reports 'No TCO module detected', which is correct, as no expansion modules where plugged to the cards. But it also says 'Preferred Sync Reference: TCO' and 'Freq=0', where amixer said SyncIn and 47999? Output of the master card is below. Regards, Andre [root@localhost ~]# amixer -c1 contents numid=5,iface=MIXER,name='AutoSync Reference' ; type=ENUMERATED,access=r-------,values=1,items=5 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'TCO' ; Item #3 'Sync In' ; Item #4 'None' : values=4 numid=15,iface=MIXER,name='Input Select' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'optical' ; Item #1 'coaxial' : values=0 numid=2,iface=MIXER,name='Internal Clock' ; type=ENUMERATED,access=rw------,values=1,items=9 ; Item #0 '32 kHz' ; Item #1 '44.1 kHz' ; Item #2 '48 kHz' ; Item #3 '64 kHz' ; Item #4 '88.2 kHz' ; Item #5 '96 kHz' ; Item #6 '128 kHz' ; Item #7 '176.4 kHz' ; Item #8 '192 kHz' : values=2 numid=4,iface=MIXER,name='Preferred Sync Reference' ; type=ENUMERATED,access=rw------,values=1,items=3 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'Sync In' : values=0 numid=10,iface=MIXER,name='SYNC IN SyncCheck' ; type=ENUMERATED,access=r-------,values=1,items=4 ; Item #0 'No Lock' ; Item #1 'Lock' ; Item #2 'Sync' ; Item #3 'N/A' : values=0 numid=3,iface=MIXER,name='System Clock Mode' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'Master' ; Item #1 'AutoSync' : values=0 numid=6,iface=MIXER,name='System Sample Rate' ; type=INTEGER,access=r-------,values=1,min=27000,max=207000,step=1 : values=48000 [root@localhost ~]# cat /proc/asound/card1/hdspm RME MADI (Card #2) Rev.d2 Status2first3bits: 1 HW Serial: 0x000001b1c606 IRQ: 17 Registers bus: 0xfeaf0000 VM: 0xf9280000 --- System --- IRQ Pending: Audio=0, MIDI0=0, MIDI1=0, IRQcount=0 HW pointer: id = 0, rawptr = 0 (0->16320) estimated= 0 (bytes) MIDI FIFO: Out1=0x0, Out2=0x0, In1=0x0, In2=0x0 MIDIoverMADI FIFO: In=0x0, Out=0x0 Register: ctrl1=0x10004da, ctrl2=0x0, status1=0x2800000, status2=0xc0020701 No TCO module detected. --- Settings --- Size (Latency): 2048 samples (2 periods of 8192 bytes) Line out: on ClearTrackMarker = off, Transmit in 64 Channel Mode, Auto Input off AutoSync Reference: Master Preferred Sync Reference: Word Clock System Clock Frequency: 48000 --- Status: Inputs MADI=NoLock, WordClock=NoLock AutoSync: Reference= Input not valid, Freq=0 (MADI = 10, Word = 0) Input: Optical, Mode=56 channels

2 2

[alsa-devel] snd-usb-audio probe problem (Teac UD-H01)
by bEN 13 Oct '12

13 Oct '12

Hi all, the new USB DAC from Teac seems detected as 'Human Interface Device' instead of 'Audio'. Despite the fact it is based on a standard USB Audio class v2 controller (Tenor 8802). Below is dmesg and lsusb outputs. Does it need to apply a patch in /sound/usb/quirks-table.h ? If yes, someone could help me to write this patch, please? Your help would be very much appreciated, Thanks in advance. bEN (from Ubuntu 11.04 with Linux 2.6.38-13-generic + Alsa driver 1.0.23) $ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.23. $ dmesg (...) [34035.000078] usb 2-4: new high speed USB device using ehci_hcd and address 3 [34035.151753] usb 2-4: config 1 has an invalid interface number: 3 but max is 2 [34035.151763] usb 2-4: config 1 has an invalid interface number: 3 but max is 2 [34035.151770] usb 2-4: config 1 has an invalid interface number: 3 but max is 2 [34035.151777] usb 2-4: config 1 has no interface number 1 [34035.155108] input: TEAC TEAC USB AUDIO DEVICE as /devices/pci0000:00/0000:00:1d.7/usb2/2-4/2-4:1.0/input/input13 [34035.155328] generic-usb 0003:0644:8038.0002: input,hidraw1: USB HID v1.00 Device [TEAC TEAC USB AUDIO DEVICE] on usb-0000:00:1d.7-4/input0 [34035.202368] Audio class v2 interfaces need an interface association [34035.202387] snd-usb-audio: probe of 2-4:1.2 failed with error -5 [34035.202426] usbcore: registered new interface driver snd-usb-audio $ lsusb -v --> see attachment.

5 6

Re: [alsa-devel] [PATCH 2.6.39-rc3] hda_intel: ALSA HD Audio patch for Intel Panther Point DeviceIDs
by Takashi Iwai 09 Oct '12

09 Oct '12

At Wed, 20 Apr 2011 10:59:57 -0700, Seth Heasley wrote: > > This patch adds the HD Audio Controller DeviceIDs for the Intel Panther Point PCH. > > Signed-off-by: Seth Heasley <seth.heasley(a)intel.com> Applied now. Thanks. Takashi > --- > --- linux-2.6.39-rc3/sound/pci/hda/hda_intel.c.orig 2011-04-11 17:21:51.000000000 -0700 > +++ linux-2.6.39-rc3/sound/pci/hda/hda_intel.c 2011-04-14 11:44:40.000000000 -0700 > @@ -126,6 +126,7 @@ > "{Intel, ICH10}," > "{Intel, PCH}," > "{Intel, CPT}," > + "{Intel, PPT}," > "{Intel, PBG}," > "{Intel, SCH}," > "{ATI, SB450}," > @@ -2759,6 +2760,8 @@ > { PCI_DEVICE(0x8086, 0x1c20), .driver_data = AZX_DRIVER_PCH }, > /* PBG */ > { PCI_DEVICE(0x8086, 0x1d20), .driver_data = AZX_DRIVER_PCH }, > + /* Panther Point */ > + { PCI_DEVICE(0x8086, 0x1e20), .driver_data = AZX_DRIVER_PCH }, > /* SCH */ > { PCI_DEVICE(0x8086, 0x811b), .driver_data = AZX_DRIVER_SCH }, > /* Generic Intel */ >

3 2

[alsa-devel] [PATCH] ASoC: ams-delta: fix card initalization failure
by Janusz Krzysztofik 04 Oct '12

04 Oct '12

Since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d, 'device-core: Ensure drvdata = NULL when no driver is bound', the Amstrad Delta sound card no longer initializes correctly due to drvdata reset to NULL by an upper layer before the codec device, required for successful card setup, is registered. Fix this by moving the codec registration bits up, before the card is probed for. Created and tested against linux-3.6-rc3 Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- sound/soc/omap/ams-delta.c | 18 ++++++++++-------- 1 files changed, 10 insertions(+), 8 deletions(-) diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c index 7d4fa8e..270de9c 100644 --- a/sound/soc/omap/ams-delta.c +++ b/sound/soc/omap/ams-delta.c @@ -590,20 +590,22 @@ static int __init ams_delta_module_init(void) if (!ams_delta_audio_platform_device) return -ENOMEM; - platform_set_drvdata(ams_delta_audio_platform_device, - &ams_delta_audio_card); - - ret = platform_device_add(ams_delta_audio_platform_device); - if (ret) - goto err; - /* * Codec platform device could be registered from elsewhere (board?), * but I do it here as it makes sense only if used with the card. + * Moreover, it must be registered before the card is probed for, + * or the card setup fails due to drvdata reset by upper layers. */ cx20442_platform_device = platform_device_register_simple("cx20442-codec", -1, NULL, 0); - return 0; + + platform_set_drvdata(ams_delta_audio_platform_device, + &ams_delta_audio_card); + + ret = platform_device_add(ams_delta_audio_platform_device); + if (!ret) + return ret; + err: platform_device_put(ams_delta_audio_platform_device); return ret; -- 1.7.3.4

4 14

[alsa-devel] Merging alsa-driver and alsa-kmirror to one GIT repo
by Jaroslav Kysela 26 Sep '12

26 Sep '12

Hi all, I believe, it's time to manage only one GIT repository for the alsa-driver package now. The merge has benefits mainly for the end users - bisecting may work, the correlation between kernel sources and our out-of-kernel build framework becomes more strong. I merged the alsa-driver and alsa-kmirror repos with full history. I also added some code changes to enable the "build-in" mirror tree in Makefile and gitcompile from v1.0.18 (but I don't think that it will be used). The structure of new repository is similar, but the kernel mirrored code is located in the mirror/ subdirectory. The paths are exactly same as in the Linux kernel tree, so possible patches can be applied without any path modifications. Of course, we may create a bash script to do proper and full cherry-picks between kernel and mirrored trees (comments, author, dates). New temporary repository has name alsa-driver.new: http://git.alsa-project.org/?p=alsa-driver.new.git;a=summary The another difference is that the releases are now branches not tags. It allows me to do quick fixes out of the standard development or separate the main development in the release time window (to not include some very new code). The previous branches won't contain probably any additional commits, but it's probably better to play with only one reference scheme. I think that the change from alsa-driver.git to alsa-driver.new.git should be quick. Please, report any objections or acks now. Schedule: When accepted, I will rename the original alsa-driver.git repository to alsa-driver.old.git and move alsa-driver.new.git to alsa-driver.git quickly. 1.0.26 release: This was my last big change (with the ALSA server upgrade) which blocked me to do the 1.0.26 release. I'm going to create new release after the repos switch ASAP. Jaroslav -- Jaroslav Kysela <perex(a)perex.cz> Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.

3 3

[alsa-devel] [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device
by Lee Jones 20 Sep '12

20 Sep '12

The PCM is a pseudo-device. It doesn't have any of it's own registers or hardware. It rather acts as a layer of abstraction for DMA transfers. Hence, instead of classifying it as a device in its own right, we call the initialisation from the MSP driver. CC: alsa-devel(a)alsa-project.org Signed-off-by: Lee Jones <lee.jones(a)linaro.org> --- sound/soc/ux500/mop500.c | 4 ++-- sound/soc/ux500/ux500_msp_dai.c | 14 +++++++++++++- sound/soc/ux500/ux500_pcm.c | 19 ++++--------------- sound/soc/ux500/ux500_pcm.h | 3 +++ 4 files changed, 22 insertions(+), 18 deletions(-) diff --git a/sound/soc/ux500/mop500.c b/sound/soc/ux500/mop500.c index 6840df7..fe6223a 100644 --- a/sound/soc/ux500/mop500.c +++ b/sound/soc/ux500/mop500.c @@ -33,7 +33,7 @@ struct snd_soc_dai_link mop500_dai_links[] = { .stream_name = "ab8500_0", .cpu_dai_name = "ux500-msp-i2s.1", .codec_dai_name = "ab8500-codec-dai.0", - .platform_name = "ux500-pcm.0", + .platform_name = "ux500-msp-i2s.1", .codec_name = "ab8500-codec.0", .init = mop500_ab8500_machine_init, .ops = mop500_ab8500_ops, @@ -43,7 +43,7 @@ struct snd_soc_dai_link mop500_dai_links[] = { .stream_name = "ab8500_1", .cpu_dai_name = "ux500-msp-i2s.3", .codec_dai_name = "ab8500-codec-dai.1", - .platform_name = "ux500-pcm.0", + .platform_name = "ux500-msp-i2s.3", .codec_name = "ab8500-codec.0", .init = NULL, .ops = mop500_ab8500_ops, diff --git a/sound/soc/ux500/ux500_msp_dai.c b/sound/soc/ux500/ux500_msp_dai.c index 0f7dd49..3476d6a 100644 --- a/sound/soc/ux500/ux500_msp_dai.c +++ b/sound/soc/ux500/ux500_msp_dai.c @@ -28,6 +28,7 @@ #include "ux500_msp_i2s.h" #include "ux500_msp_dai.h" +#include "ux500_pcm.h" static int setup_pcm_multichan(struct snd_soc_dai *dai, struct ux500_msp_config *msp_config) @@ -806,11 +807,20 @@ static int __devinit ux500_msp_drv_probe(struct platform_device *pdev) goto err_init_msp; } + ret = ux500_pcm_register_platform(pdev); + if (ret < 0) { + dev_err(&pdev->dev, + "Error: %s: Failed to register PCM platform device!\n", + __func__); + goto err_reg_plat; + } + return 0; +err_reg_plat: + snd_soc_unregister_dais(&pdev->dev, ARRAY_SIZE(ux500_msp_dai_drv)); err_init_msp: clk_put(drvdata->clk); - err_clk: devm_regulator_put(drvdata->reg_vape); @@ -821,6 +831,8 @@ static int __devexit ux500_msp_drv_remove(struct platform_device *pdev) { struct ux500_msp_i2s_drvdata *drvdata = dev_get_drvdata(&pdev->dev); + ux500_pcm_unregister_platform(pdev); + snd_soc_unregister_dais(&pdev->dev, ARRAY_SIZE(ux500_msp_dai_drv)); devm_regulator_put(drvdata->reg_vape); diff --git a/sound/soc/ux500/ux500_pcm.c b/sound/soc/ux500/ux500_pcm.c index 1a04e24..894c9f4 100644 --- a/sound/soc/ux500/ux500_pcm.c +++ b/sound/soc/ux500/ux500_pcm.c @@ -282,7 +282,7 @@ static struct snd_soc_platform_driver ux500_pcm_soc_drv = { .pcm_new = ux500_pcm_new, }; -static int __devexit ux500_pcm_drv_probe(struct platform_device *pdev) +int __devinit ux500_pcm_register_platform(struct platform_device *pdev) { int ret; @@ -296,23 +296,12 @@ static int __devexit ux500_pcm_drv_probe(struct platform_device *pdev) return 0; } +EXPORT_SYMBOL_GPL(ux500_pcm_register_platform); -static int __devinit ux500_pcm_drv_remove(struct platform_device *pdev) +int __devexit ux500_pcm_unregister_platform(struct platform_device *pdev) { snd_soc_unregister_platform(&pdev->dev); return 0; } - -static struct platform_driver ux500_pcm_driver = { - .driver = { - .name = "ux500-pcm", - .owner = THIS_MODULE, - }, - - .probe = ux500_pcm_drv_probe, - .remove = __devexit_p(ux500_pcm_drv_remove), -}; -module_platform_driver(ux500_pcm_driver); - -MODULE_LICENSE("GPL v2"); +EXPORT_SYMBOL_GPL(ux500_pcm_unregister_platform); diff --git a/sound/soc/ux500/ux500_pcm.h b/sound/soc/ux500/ux500_pcm.h index 77ed44d..76d3444 100644 --- a/sound/soc/ux500/ux500_pcm.h +++ b/sound/soc/ux500/ux500_pcm.h @@ -32,4 +32,7 @@ #define UX500_PLATFORM_PERIODS_MAX 48 #define UX500_PLATFORM_BUFFER_BYTES_MAX (2048 * PAGE_SIZE) +int ux500_pcm_register_platform(struct platform_device *pdev); +int ux500_pcm_unregister_platform(struct platform_device *pdev); + #endif -- 1.7.9.5

4 5

[alsa-devel] Internal speaker output from Sony Vaio Z (2010 model) lost somewhere between 3.1.0 and 3.2.6
by Adam Williamson 20 Sep '12

20 Sep '12

Welp, pretty much as the topic says. I just noticed today that sound is no longer playing from the internal speakers of my laptop, a 2010 model Sony Vaio Z. Plugging in headphones causes sound to be played fine through those. There are three possible choices for 'Connector' - 'Analog Speakers', 'Analog Output', and 'Analog Headphones' - but none of these seems to make sound come out of the internal speakers. The default is 'Analog Speakers', and when it's set to this, headphone output does work when headphones are plugged in. I've verified that it's broken on Fedora 16 kernels 3.2.6-4, 3.2.8-3 and 3.2.10-1. It's also broken in a very recent Fedora 17 kernel, 3.3.0rc6 or so. It works on a Fedora 16 live image, with kernel 3.1.0-1. Unfortunately the kernels before 3.2.6 have been trashed from Fedora's buildsystem archives, I think, so it's hard to narrow things down any further :/ the alsa-info output is http://www.alsa-project.org/db/?f=368e2359757b537d4daa0f5399830d3942540196 . Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

3 22

Re: [alsa-devel] [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device
by Lee Jones 19 Sep '12

19 Sep '12

Mark, > > > I'm sorry but this patch is breaking the design of ASoC. > > > The ASoC-platform is the DMA-block (in combination with the > > > MSP-block), and there should be a platform-driver for the DMA/PCM. > > > The > > > platform-driver then has a DAI which is the MSP. The ASoC > > > DAI-link-struct should have one driver for each of these, so the > > > dummy-driver for PCM should be there. > > > > Just thinking about this now. I converted it to the current format at > > the request of Mark. If this isn't the correct method I'm not quite > > sure what is. If you want it to be registered as a device, then it > > needs to go into the Device Tree, but Mark doesn't want it in there > > because it doesn't actually represent hardware. I've just taken a closer look at this with a view to finding the most suitable solution. My conclusion is that although the PCM doesn't contain any registers, or represent hardware it should be a device and therefore be present in the Device Tree. These are my findings: PCM devices already represented in DTs: fsl,mpc5200-pcm - written by Grant Likely, the author of Device Tree phytec,pcm030 - written by Grant Likely, the author of Device Tree PCM devices which register as actual devices (should be in DT): samsung - samsung-pcm sh - siu-pcm-audio omap - omap-pcm-audio pxa - pxa-pcm-audio jz4740 - jz4740-pcm-audio kirkwood - kirkwood-pcm-audio ep93xx - ep93xx-pcm-audio ... The later was basically every PCM device bar one I think. The Open Firmware used to stipulate that each device represented in the Device Tree to own registers and therefore be an actual hardware device, but that has since been lifted as it didn't make sense. I propose to represent the PCM in the Device Tree again and have it probe just like all the other PCM devices in sound/soc. If you give me the nod, I'll revert this patch, enable the PCM for DT again and resent the patch-set in full. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

2 8

Re: [alsa-devel] [PATCH 4/7] mfd: ab8500-core: Apply the AB8500 CODEC's compatible string to its MFD cell
by Mark Brown 14 Sep '12

14 Sep '12

On Fri, Jul 27, 2012 at 03:36:33PM +0200, Samuel Ortiz wrote: > On Fri, Jul 27, 2012 at 01:38:51PM +0100, Lee Jones wrote: > > Provide a compatible string for the AB8500 CODEC to aid in > > configuration property look-up from its associated Device Tree > > node. > Applied as well. I remain *deeply* unconvinced that this is tasteful design for the device tree bindings, and it's certainly not needed urgently for v3.6 as there's no DT bindings on the CODEC side.

3 2

Re: [alsa-devel] FW: [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device
by Ola Lilja 14 Sep '12

14 Sep '12

On 08/23/2012 09:29 PM, Ola Lilja wrote: > > >> -----Original Message----- >> From: Lee Jones [mailto:lee.jones@linaro.org] >> Sent: den 23 augusti 2012 16:59 >> To: Mark Brown >> Cc: Ola Lilja; 'Linus Walleij'; roger.xr.nilsson(a)stericsson.com; linux- >> arm-kernel(a)lists.infradead.org; alsa-devel(a)alsa-project.org >> Subject: Re: [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe >> rather than as a device >> >> On Thu, Aug 23, 2012 at 03:37:57PM +0100, Mark Brown wrote: >> > On Thu, Aug 23, 2012 at 02:26:19PM +0100, Lee Jones wrote: >> > >> > > > I think Ola is suggesting probing the DMA driver from the machine >> > > > which will also work though I'm not 100% sure if I'm parsing the >> > > > above correctly. The issue in DT terms is that if the DMA >> > > > controller is shared with a bunch of other IPs then it should >> have >> > > > one node shared between them all and not a bunch of shim nodes >> > > > inserted in the middle which only exists due to the way Linux >> instantiates stuff. I haven't followed everything in this discussion, but what I meant in an earlier mail was that using the device for platform-DAI (MSP_I2S) also as platform int the DAI-link struct is not anything I can see fit (as in the patch Lee first submitted). I can see a few acceptable solutions: 1) Use it as it is! (A virtual device for PCM is created in arch/arm and the probe is invoked from the machine-driver). 2) Since the actual platform is the DMA-block, maybe there is some way of making the device "non-virtual" by having some sub-device in the DMA-driver that is instead triggered in the same way as in 1). 3) Move it to DT, but it seems that it is not possible when it is now a virtual device. Any of these three would be fine with me. >> > >> > > When you say 'machine', do you mean from arch/<arch>/mach-*? If so, >> > > I'm keen for that not to happen. >> > >> > No, sound/soc/ux500/snowball.c or whatever. At least that's my >> guess. >> >> Ah, I see. Maybe the mop500.c file then. >> >> > > > They instantiate the PCM driver dynamically from the DAI when >> it's >> > > > probed which is pretty much what you're patch is doing. >> > >> > > So they do it in the same why I have with this patch? Do you know >> > > why Ola might think this is a bad idea? >> > >> > I'm not 100% sure, I'm guessing it might be down to the fact that you >> > end up with multiple PCM drivers. We could avoid that with >> > refcounting but nobody's really worried about it. >> >> I think I'll wait for Ola to get back, as he's the expert on this >> stuff. >> >> I'll attempt to re-jig the patch-set, as this is a blocker atm. >> >> -- >> Lee Jones >> Linaro ST-Ericsson Landing Team Lead >> Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook >> | Twitter | Blog >

3 2