| Message ID | 1458082066-2859-1-git-send-email-tim.howe@cirrus.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Mar 15, 2016 at 05:47:46PM -0500, tim.howe@cirrus.com wrote: > +/* ADC Preamp gain select */ > +static const char * const cs53l30_preamp_gain_sel_text[] = { > + "0dB", "10dB", "20dB"}; > + > +static const struct soc_enum adc1a_preamp_gain_enum = > + SOC_ENUM_SINGLE(CS53L30_ADC1A_AFE_CTL, 6, > + ARRAY_SIZE(cs53l30_preamp_gain_sel_text), > + cs53l30_preamp_gain_sel_text); Why are you writing volume controls as enums? Please use normal volume controls with TLV information. > +/* Set MIC Bias Voltage Control */ > +static const char * const cs53l30_micbias_text[] = { > + "HiZ", "1.8V", "2.75V"}; Why is this exposed to userspace and not platform data like other bias controls? The voltage to use will normally be determined by the hardware design and the enable/disable should be managed via DAPM. > + case SND_SOC_DAPM_PRE_PMU: > + regmap_update_bits(priv->regmap, CS53L30_ASP1_CTL, > + CS53L30_ASP1_3ST, 0); > + break; > + case SND_SOC_DAPM_POST_PMD: > + regmap_update_bits(priv->regmap, CS53L30_ASP1_CTL, > + CS53L30_ASP1_3ST, 1); > + break; Could this be a supply widget? > + regmap_read(priv->regmap, CS53L30_MCLKCTL, &mclk_ctl); > + mclk_ctl &= ~CS53L30_MCLK_DIV; > + mclk_ctl |= cs53l30_mclkx_coeffs[mclkx_coeff].mclkdiv; > + > + regmap_update_bits(priv->regmap, CS53L30_MCLKCTL, CS53L30_MCLK_DIV, > + mclk_ctl << CS53L30_MCLK_DIV); You're using regmap_update_bits() but still implementing a manual read/modify write cycle. Just use regmap_update_bits. > + regmap_read(priv->regmap, CS53L30_ASPCFG_CTL, &asp_config_ctl); > + > + switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) { > + case SND_SOC_DAIFMT_CBM_CFM: > + asp_config_ctl |= CS53L30_ASP_MS; > + priv->asp_config_ctl = asp_config_ctl; The driver appears to be mixing use of priv->asp_config_ctl and the physical value, that seems likely to go wrong somewhere along the line. Either the variable is authorative and we should always work from that then write it to the device when needed or the device is authorative but currently we're mixing both. > + regmap_update_bits(priv->regmap, CS53L30_ASPCFG_CTL, > + CS53L30_ASP_RATE_MASK, priv->asp_config_ctl); We also write out via update_bits but don't specify all the bits sometimes...
Hi Mark, I have two quick questions regarding the DAI and its TDM support. On Tue, Mar 15, 2016 at 05:47:46PM -0500, tim.howe@cirrus.com wrote: > +static const struct snd_soc_dapm_route cs53l30_audio_map[] = { > + > + /* ADC Input Paths */ > + {"ADC1A", NULL, "IN1_DMIC1"}, > + {"Input Mux 1", "ADC1_SEL", "ADC1A"}, > + {"ADC1B", NULL, "IN2"}, > + > + {"ADC2A", NULL, "IN3_DMIC2"}, > + {"Input Mux 2", "ADC2_SEL", "ADC2A"}, > + {"ADC2B", NULL, "IN4"}, > + > + /* MIC Bias Paths */ > + {"ADC1A", NULL, "MIC1 Bias"}, > + {"ADC1B", NULL, "MIC2 Bias"}, > + {"ADC2A", NULL, "MIC3 Bias"}, > + {"ADC2B", NULL, "MIC4 Bias"}, > + > + /* DMIC Paths */ > + {"DMIC1", NULL, "IN1_DMIC1"}, > + {"Input Mux 1", "DMIC1_SEL", "DMIC1"}, > + > + {"DMIC2", NULL, "IN3_DMIC2"}, > + {"Input Mux 2", "DMIC2_SEL", "DMIC2"}, > + > + /* Output Paths */ > + {"ASP_SDOUT1", NULL, "ADC1A" }, > + {"ASP_SDOUT1", NULL, "Input Mux 1"}, > + {"ASP_SDOUT1", NULL, "ADC1B"}, > + > + {"ASP_SDOUT2", NULL, "ADC2A"}, > + {"ASP_SDOUT2", NULL, "Input Mux 2"}, > + {"ASP_SDOUT2", NULL, "ADC2B"}, > + > + {"ASP1 Capture", NULL, "ASP_SDOUT1"}, > + {"ASP2 Capture", NULL, "ASP_SDOUT2"}, > +}; This codec chip has two SDOUT (Serial Data Output) pins while sharing one serial port -- there's only one pair of bit clock and fsync clock. > +static struct snd_soc_dai_driver cs53l30_dai[] = { > + { > + .name = "cs53l30-asp1", > + .id = CS53L30_ASP1, > + .capture = { > + .stream_name = "ASP1 Capture", > + .channels_min = 1, > + .channels_max = 2, > + .rates = CS53L30_RATES, > + .formats = CS53L30_FORMATS, > + }, > + .ops = &cs53l30_ops, > + .symmetric_rates = 1, > + }, > + { > + .name = "cs53l30-asp2", > + .id = CS53L30_ASP2, > + .capture = { > + .stream_name = "ASP2 Capture", > + .channels_min = 1, > + .channels_max = 2, > + .rates = CS53L30_RATES, > + .formats = CS53L30_FORMATS, > + }, > + .ops = &cs53l30_ops, > + .symmetric_rates = 1, > + } > +}; In this case, would it be more appropriate to create one single DAI with channels_max = 4 over here? Another question is for its TDM support. This chip outputs 4-channel data on two data output pins (SDOUT1 and SDOUT2) as normal mode; it outputs 4-channel data on one data output pin (SDOUT1) as TDM mode. However, the mode selection for a 4-channel recording should depend on the hardware design: whether the SDOUT2 is connected or not. So I am wondering if there is a common way or existing way to indicate this hardware design. Or just by simply defining a new DT property? Thank you Nicolin
On Tue, May 17, 2016 at 04:43:33PM -0700, Nicolin Chen wrote: > In this case, would it be more appropriate to create one single DAI > with channels_max = 4 over here? Yes. > Another question is for its TDM support. This chip outputs 4-channel > data on two data output pins (SDOUT1 and SDOUT2) as normal mode; it > outputs 4-channel data on one data output pin (SDOUT1) as TDM mode. > However, the mode selection for a 4-channel recording should depend > on the hardware design: whether the SDOUT2 is connected or not. So > I am wondering if there is a common way or existing way to indicate > this hardware design. Or just by simply defining a new DT property? That's a really rare thing to have as an option, most things either do TDM or parallel data signals but not both.
On Tue, May 31, 2016 at 9:53 AM, Mark Brown <broonie@kernel.org> wrote: > > On Tue, May 17, 2016 at 04:43:33PM -0700, Nicolin Chen wrote: > > > In this case, would it be more appropriate to create one single DAI > > with channels_max = 4 over here? > > Yes. > > > Another question is for its TDM support. This chip outputs 4-channel > > data on two data output pins (SDOUT1 and SDOUT2) as normal mode; it > > outputs 4-channel data on one data output pin (SDOUT1) as TDM mode. > > However, the mode selection for a 4-channel recording should depend > > on the hardware design: whether the SDOUT2 is connected or not. So > > I am wondering if there is a common way or existing way to indicate > > this hardware design. Or just by simply defining a new DT property? > > That's a really rare thing to have as an option, most things either do > TDM or parallel data signals but not both. Interesting comment. While I'm sure that's true for the moment, microphone arrays are changing this quickly. I fall into the oddball category that the main chips I use are the TLV320AIC34 and CS53L30, and both of them can switch between TDM mode or dual I2S mode for 4 channel support. Since I need to get many channels on board, and SoCs (except for TI) rarely have enough parallel I2S ports for mic arrays, I opt for TDM mode often. If you're using the CS53L30, chances are high that you're building a mic array. Then the question is, how many microphones? up to 4, you could live with dual I2S if your chip supports it. Beyond 4, you're almost certainly talking TDM, unless you have a TI McASP with lots of inputs, or an XMOS part with multiple I2S interfaces. Of course, it's highly dependent on what the SoC supports. I would say it's just about mandatory for the CS53L30 driver in particular to be able to switch between TDM or I2S mode based on a DT setting because of the huge variability of capabilities on the SoC side. A TI McBSP could support multiple I2S busses, but a freescale SSI must use TDM mode. -Caleb > > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >
On 5/31/16, 12:10 PM, "Caleb Crome" <caleb@crome.org> wrote: >On Tue, May 31, 2016 at 9:53 AM, Mark Brown <broonie@kernel.org> wrote: >> >> On Tue, May 17, 2016 at 04:43:33PM -0700, Nicolin Chen wrote: >> >> > In this case, would it be more appropriate to create one single DAI >> > with channels_max = 4 over here? >> >> Yes. >> >> > Another question is for its TDM support. This chip outputs 4-channel >> > data on two data output pins (SDOUT1 and SDOUT2) as normal mode; it >> > outputs 4-channel data on one data output pin (SDOUT1) as TDM mode. >> > However, the mode selection for a 4-channel recording should depend >> > on the hardware design: whether the SDOUT2 is connected or not. So >> > I am wondering if there is a common way or existing way to indicate >> > this hardware design. Or just by simply defining a new DT property? >> >> That's a really rare thing to have as an option, most things either do >> TDM or parallel data signals but not both. > > >Interesting comment. While I'm sure that's true for the moment, >microphone arrays are changing this quickly. I fall into the oddball >category that the main chips I use are the TLV320AIC34 and CS53L30, >and both of them can switch between TDM mode or dual I2S mode for 4 >channel support. > >Since I need to get many channels on board, and SoCs (except for TI) >rarely have enough parallel I2S ports for mic arrays, I opt for TDM >mode often. > >If you're using the CS53L30, chances are high that you're building a >mic array. Then the question is, how many microphones? up to 4, you >could live with dual I2S if your chip supports it. Beyond 4, you're >almost certainly talking TDM, unless you have a TI McASP with lots of >inputs, or an XMOS part with multiple I2S interfaces. > >Of course, it's highly dependent on what the SoC supports. I would >say it's just about mandatory for the CS53L30 driver in particular to >be able to switch between TDM or I2S mode based on a DT setting >because of the huge variability of capabilities on the SoC side. A >TI McBSP could support multiple I2S busses, but a freescale SSI must >use TDM mode. > >-Caleb For this device you are using either I2S or TDM, therefore, it will depend on the capabilities of the SoC (hence the hardware design). This will not require a DT property since it is configured by the cs53l30_set_dai_fmt callback. As Calib mentioned, you will have to use TDM if you are using greater than channels up to 16 channels for a mic array. > > > >> >> >> _______________________________________________ >> Alsa-devel mailing list >> Alsa-devel@alsa-project.org >> >>https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.alsa-2Dprojec >>t.org_mailman_listinfo_alsa-2Ddevel&d=DQIBaQ&c=O3LcjD-V2Iepl5V0N1424A&r=N >>JtNI3T_InLOY17xIGk4jdUC7XljFdoy6miaxhGHOOI&m=Qrzd24GLzVm_xD3O3sFLrdCF9bUr >>dZ_DqkhoIuAy6b0&s=szG5oWmXcuMj-OEhja5V7GMcXXMCfLn9ia0maAr8YG8&e= >>
On Tue, May 31, 2016 at 10:10:11AM -0700, Caleb Crome wrote: > On Tue, May 31, 2016 at 9:53 AM, Mark Brown <broonie@kernel.org> wrote: > > That's a really rare thing to have as an option, most things either do > > TDM or parallel data signals but not both. > Interesting comment. While I'm sure that's true for the moment, > microphone arrays are changing this quickly. I fall into the oddball > category that the main chips I use are the TLV320AIC34 and CS53L30, > and both of them can switch between TDM mode or dual I2S mode for 4 > channel support. I'm not sure why mic arrays would drive that, it's not like they're particularly new or innovative technology here and multi channel output has been even more widely available for a long time? > Since I need to get many channels on board, and SoCs (except for TI) > rarely have enough parallel I2S ports for mic arrays, I opt for TDM > mode often. Modern systems all use TDM for the most part, the usage of parallel data lines that I've seen has been for surround sound applications where a 5.1 or 7.1 decoder will often be built by taking a bunch of high end stereo CODECs and wiring them up in parallel, partly for performance and physical design reasons and partly because such system designs have often had their roots in very old systems. This also matches the trend with more modern SoCs to use programmable serial ports rather than dedicated I2S controllers so TDM is very easy to configure, and of course it's fewer signals so it's easier from a board design point of view too.
On Tue, May 31, 2016 at 10:35 AM, Mark Brown <broonie@kernel.org> wrote: > On Tue, May 31, 2016 at 10:10:11AM -0700, Caleb Crome wrote: > > On Tue, May 31, 2016 at 9:53 AM, Mark Brown <broonie@kernel.org> wrote: > > > > That's a really rare thing to have as an option, most things either do > > > TDM or parallel data signals but not both. > > > Interesting comment. While I'm sure that's true for the moment, > > microphone arrays are changing this quickly. I fall into the oddball > > category that the main chips I use are the TLV320AIC34 and CS53L30, > > and both of them can switch between TDM mode or dual I2S mode for 4 > > channel support. > > I'm not sure why mic arrays would drive that, it's not like they're > particularly new or innovative technology here and multi channel output > has been even more widely available for a long time? > Good point. I guess I'm coming from the SoC/mobile world where most SoCs support stereo only, and a couple microphones at most. Now phones have 3-4 or more microphones. Amazon echo has 7 mics. We're working on arrays of 16 and beyond, and getting those channels into linux has proven to be an enormous headache given the hardware and software status of many of the SoCs our customers want to use. > > > Since I need to get many channels on board, and SoCs (except for TI) > > rarely have enough parallel I2S ports for mic arrays, I opt for TDM > > mode often. > > Modern systems all use TDM for the most part ... > We must be looking at different sorts of chips :-) Even on new parts like the Snapdragon 410, they have a super inflexible I2S only port. (up to 3 parallel I2S for up to 6 channels, but no TDM). From my experience, the SoC support for TDM has been essentially nonexistent, except for TI's McBSP and McASP. I'd sure welcome a Cortex A53 or A57 (or even A15 for that matter!) that has good TDM support. Here are the chips that we've come across lately from our customers: MX6 (SSI): hardware supports TDM, but linux didn't until recently (thanks everybody for help with that!) MX6 (ESAI): not available on MX6 solo, nor on any SOM modules I've ever seen, but supported if you can get to the pins. MX7: (SAI): hardware supports TDM, linux BSP driver does not. TI parts (McASP): supported in hardware & software TI parts (McBSP): supported in hardware & software Qualcomm Snapdragon 410c (MI2S): TDM not possible in hardware. Supports multiple parallel I2S channels only. Broadcom: (forgot part number...) hardware supports TDM. software still in the works but apparently somebody's working on it. A quick grep for channels_max > 2 in sound/soc shows the following few drivers that support channels > 2 (not necessarily even in TDM mode). All the rest are 2 channels max. pxa/mmp-sspa: 128/2 (playback/capture). pxa/pxa-ssp: 8/8 zx286702-i2s.c: 8/2 fsl_esai: 12/8 fsl_ssi: 32/32 blackfin 5: 8/8 channels blackfin 6: 2/2 channels only. mcbsp: 16/16 mcasp: 512/512 and a few other chips that I'm not familiar with. So there does not seem to be overwhelming support for TDM in Alsa ASoC. To what extent this is a software vs. hardware issue could use a little investigation. the bummer is that even newer chips like the snapdragon are still using really inflexible ports. So... if anybody knows of a Cortex A53 or A57 with good TDM support in linux (at least 16 channels in and out), I'd love to know about it :-) -Caleb
On Tue, May 31, 2016 at 03:32:05PM -0700, Caleb Crome wrote: > On Tue, May 31, 2016 at 10:35 AM, Mark Brown <broonie@kernel.org> wrote: > > I'm not sure why mic arrays would drive that, it's not like they're > > particularly new or innovative technology here and multi channel output > > has been even more widely available for a long time? > Good point. I guess I'm coming from the SoC/mobile world where most SoCs > support stereo only, and a couple microphones at most. Now phones have 3-4 > or more microphones. Amazon echo has 7 mics. We're working on arrays of That's fairly rare, I'd say more of the vendors are doing programmable serial ports and those that aren't have a different model... see below. > We must be looking at different sorts of chips :-) Even on new parts like > the Snapdragon 410, they have a super inflexible I2S only port. (up to 3 > parallel I2S for up to 6 channels, but no TDM). Qualcomm have never really wanted anyone to use I2S in their mobile products for quite some time now - they've always wanted to do a system sale based on either their integrated CODECs or (in the current production designs) their own external CODECs which normally use Slimbus to connect to the CPU (they are working off and on on upstreaming Slimbus, nobody else ever adopted it so there's relatively little pressure). > and a few other chips that I'm not familiar with. So there does not seem > to be overwhelming support for TDM in Alsa ASoC. To what extent this is a > software vs. hardware issue could use a little investigation. It's software and legacy hardware. > So... if anybody knows of a Cortex A53 or A57 with good TDM support in > linux (at least 16 channels in and out), I'd love to know about it :-) Well, if you specifically mean TDM as opposed to multi-channel our general support for that isn't good (mainly due to lack of demand). It sounds like you're more interested in multi channel here though.
On Thu, Jun 2, 2016 at 10:17 AM, Mark Brown <broonie@kernel.org> wrote: > On Tue, May 31, 2016 at 03:32:05PM -0700, Caleb Crome wrote: >> On Tue, May 31, 2016 at 10:35 AM, Mark Brown <broonie@kernel.org> wrote: > >> > I'm not sure why mic arrays would drive that, it's not like they're >> > particularly new or innovative technology here and multi channel output >> > has been even more widely available for a long time? > >> Good point. I guess I'm coming from the SoC/mobile world where most SoCs >> support stereo only, and a couple microphones at most. Now phones have 3-4 >> or more microphones. Amazon echo has 7 mics. We're working on arrays of > > That's fairly rare, I'd say more of the vendors are doing programmable > serial ports and those that aren't have a different model... see below. > >> We must be looking at different sorts of chips :-) Even on new parts like >> the Snapdragon 410, they have a super inflexible I2S only port. (up to 3 >> parallel I2S for up to 6 channels, but no TDM). > > Qualcomm have never really wanted anyone to use I2S in their mobile > products for quite some time now - they've always wanted to do a system > sale based on either their integrated CODECs or (in the current > production designs) their own external CODECs which normally use Slimbus > to connect to the CPU (they are working off and on on upstreaming > Slimbus, nobody else ever adopted it so there's relatively little > pressure). > >> and a few other chips that I'm not familiar with. So there does not seem >> to be overwhelming support for TDM in Alsa ASoC. To what extent this is a >> software vs. hardware issue could use a little investigation. > > It's software and legacy hardware. > >> So... if anybody knows of a Cortex A53 or A57 with good TDM support in >> linux (at least 16 channels in and out), I'd love to know about it :-) > > Well, if you specifically mean TDM as opposed to multi-channel our > general support for that isn't good (mainly due to lack of demand). It > sounds like you're more interested in multi channel here though. I must be missing something. To me, TDM is synonymous with multi-channel on a single wire. The datasheets of codecs and SoCs invariably refer to TDM as putting multiple slots onto a single wire, and not necessarily the actual bit-format and clocking of that wire. The actual clocking and bits are generally configurable, but the concept of TDM in the datasheets seems to be universal and have the same meaning -- multi-channel on a wire. (I recall there is also a specific TDM format with something like 384 slots per frame, which is a well defined thing, but that's not what I'm talking about. That's used just for telephony I beleive). What's the linuxy name for what the datasheets call TDM format with slots > 2? Do we just call that 'multi-channel', or specifically say, 'channels_max > 2'? I was always under the assumption that's what TDM meant. Thanks, -Caleb
On Thu, Jun 02, 2016 at 10:40:58AM -0700, Caleb Crome wrote: > On Thu, Jun 2, 2016 at 10:17 AM, Mark Brown <broonie@kernel.org> wrote: > > Well, if you specifically mean TDM as opposed to multi-channel our > > general support for that isn't good (mainly due to lack of demand). It > > sounds like you're more interested in multi channel here though. > I must be missing something. To me, TDM is synonymous with > multi-channel on a single wire. The datasheets of codecs and SoCs TDM, at least in the sense Linux is using it, is multiple *unrelated* audio streams on a single wire. Any multi-channel audio stream is TDM in some sense but the trivial extension to add two or more channels isn't really a big deal. This is for things more complex than just stuffing more bytes of data onto a wire where there are going to be some timeslots that the device should ignore as they're going to/from other devices (or at least other streams even if the same chip is handling them). > (I recall there is also a specific TDM format with something like 384 > slots per frame, which is a well defined thing, but that's not what > I'm talking about. That's used just for telephony I beleive). You're thinking of H.1x0 CTBus which is genuine TDM, used for routing single channel audio streams between multiple PCI (H.100) or cPCI (H.110) cards in a system. It does way more than 384 slots, 4096 8kHz 8 bit timeslots IIRC. > What's the linuxy name for what the datasheets call TDM format with > slots > 2? Do we just call that 'multi-channel', or specifically say, > 'channels_max > 2'? I was always under the assumption that's what TDM > meant. We don't particularly call it anything, it's such a trivial extension.
On Thu, Jun 2, 2016 at 11:40 AM, Mark Brown <broonie@kernel.org> wrote: > On Thu, Jun 02, 2016 at 10:40:58AM -0700, Caleb Crome wrote: >> On Thu, Jun 2, 2016 at 10:17 AM, Mark Brown <broonie@kernel.org> wrote: > >> > Well, if you specifically mean TDM as opposed to multi-channel our >> > general support for that isn't good (mainly due to lack of demand). It >> > sounds like you're more interested in multi channel here though. > >> I must be missing something. To me, TDM is synonymous with >> multi-channel on a single wire. The datasheets of codecs and SoCs > > TDM, at least in the sense Linux is using it, is multiple *unrelated* > audio streams on a single wire. Any multi-channel audio stream is TDM > in some sense but the trivial extension to add two or more channels > isn't really a big deal. This is for things more complex than just > stuffing more bytes of data onto a wire where there are going to be some > timeslots that the device should ignore as they're going to/from other > devices (or at least other streams even if the same chip is handling > them). Hi Mark, Thanks for taking the time to describe this to me. This definitely comes as a surprise to me. I assumed that TDM mode simply means multi-channels on a single wire (which is what it means in all the datasheets). Just so I have this straight, TDM in the linux sense is putting say, 6-channels on one wire where the channels are from logically different places? i.e. chanels 0-1 are from bluetooth, 2-3 from analog in, and 4-5 from somewhere else? So, going back to Nicolin's original question for this email, the CS53L30, what are the proper DT settings for these modes: The device can be configured in what amounts to at least 3 different modes: 1) 4-channel, 5-pin ADC interface: dual I2S: shared BCLK/WCLK/MCLK, separate data pins for channels 0/1 and 2/3 (SDOUT0/SDOUT1). 2) 4-channel, 4-pin ADC interface: MBLCK/BCLK/WCLK/SDOUT0 only. Slots 0/1/2/3 on the SDOUT0 pin (synch master) 3) and finally, a multi-codec configuration, where 4 x CS53L30 are used: 16-channel, 4-pin ADC (what I call TDM) interface, all on the same 4 pins. These are very related data streams -- they are perfectly synchronized in hardware, so perhaps this isn't TDM in the linux-sense. >> Nicolin Wrote: >> Another question is for its TDM support. This chip outputs 4-channel >> data on two data output pins (SDOUT1 and SDOUT2) as normal mode; it >> outputs 4-channel data on one data output pin (SDOUT1) as TDM mode. >> However, the mode selection for a 4-channel recording should depend >> on the hardware design: whether the SDOUT2 is connected or not. So >> I am wondering if there is a common way or existing way to indicate >> this hardware design. Or just by simply defining a new DT property? As far as I can see he's not trying to define *unrelated* streams in TDM mode, but very related streams, which is TDM in the datasheet-sense. And there not only needs to be a mechanism of choosing the dual I2S mode, but also which TDM slots to drop the data in (which I think already exists, right?) >> What's the linuxy name for what the datasheets call TDM format with >> slots > 2? Do we just call that 'multi-channel', or specifically say, >> 'channels_max > 2'? I was always under the assumption that's what TDM >> meant. > > We don't particularly call it anything, it's such a trivial extension. That's not been my experience :-) Getting 16 channels onto a wire has been anything but trivial because of the lack of SoC driver support for it. Perhaps I'm just using the wrong SoCs. Thanks again, -Caleb
On Sun, Jun 05, 2016 at 09:48:36AM -0700, Caleb Crome wrote: > On Thu, Jun 2, 2016 at 11:40 AM, Mark Brown <broonie@kernel.org> wrote: > > TDM, at least in the sense Linux is using it, is multiple *unrelated* > > audio streams on a single wire. Any multi-channel audio stream is TDM > > in some sense but the trivial extension to add two or more channels > Thanks for taking the time to describe this to me. This definitely > comes as a surprise to me. I assumed that TDM mode simply means > multi-channels on a single wire (which is what it means in all the > datasheets). It *really* depends on the datasheets you're looking at. Things that are doing generic programmable serial ports might have no concept of channels and inflexible devices which just support configurable numbers of channels are just as likely to refer to DSP mode or whatever as anything else. > Just so I have this straight, TDM in the linux sense is putting say, > 6-channels on one wire where the channels are from logically different > places? i.e. chanels 0-1 are from bluetooth, 2-3 from analog in, and > 4-5 from somewhere else? You also need some separation of devices for us to actually care - if none of the hardware can tell this is going on it's not meaningfully TDM. > As far as I can see he's not trying to define *unrelated* streams in > TDM mode, but very related streams, which is TDM in the > datasheet-sense. And there not only needs to be a mechanism of > choosing the dual I2S mode, but also which TDM slots to drop the data > in (which I think already exists, right?) Yes. > >> 'channels_max > 2'? I was always under the assumption that's what TDM > >> meant. > > We don't particularly call it anything, it's such a trivial extension. > That's not been my experience :-) Getting 16 channels onto a wire has > been anything but trivial because of the lack of SoC driver support > for it. Perhaps I'm just using the wrong SoCs. Yes, you're using the wrong SoCs - anything with a programmable serial port should cope fine.
diff --git a/Documentation/devicetree/bindings/sound/cs53l30.txt b/Documentation/devicetree/bindings/sound/cs53l30.txt new file mode 100644 index 0000000..a2dff95 +++ b/Documentation/devicetree/bindings/sound/cs53l30.txt @@ -0,0 +1,21 @@ +CS53L30 audio CODEC + +Required properties: + + - compatible : "cirrus,cs53l30" + + - reg : the I2C address of the device + +Optional properties: + + - reset-gpios : a GPIO spec for the reset pin. + + +Example: + +codec: cs53l30@48 { + compatible = "cirrus,cs53l30"; + reg = <0x48>; + reset-gpios = <&gpio 54 0>; +}; + diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index b282169..2dd97d4 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -60,6 +60,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_CS4271_SPI if SPI_MASTER select SND_SOC_CS42XX8_I2C if I2C select SND_SOC_CS4349 if I2C + select SND_SOC_CS53L30 if I2C select SND_SOC_CX20442 if TTY select SND_SOC_DA7210 if SND_SOC_I2C_AND_SPI select SND_SOC_DA7213 if I2C @@ -449,6 +450,11 @@ config SND_SOC_CS4349 tristate "Cirrus Logic CS4349 CODEC" depends on I2C +# Cirrus Logic Quad-Channel ADC +config SND_SOC_CS53L30 + tristate "Cirrus Logic CS53L30 CODEC" + depends on I2C + config SND_SOC_CX20442 tristate depends on TTY diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index 81324bc..88dff59 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -52,6 +52,7 @@ snd-soc-cs4271-spi-objs := cs4271-spi.o snd-soc-cs42xx8-objs := cs42xx8.o snd-soc-cs42xx8-i2c-objs := cs42xx8-i2c.o snd-soc-cs4349-objs := cs4349.o +snd-soc-cs53l30-objs := cs53l30.o snd-soc-cx20442-objs := cx20442.o snd-soc-da7210-objs := da7210.o snd-soc-da7213-objs := da7213.o @@ -252,6 +253,7 @@ obj-$(CONFIG_SND_SOC_CS4271_SPI) += snd-soc-cs4271-spi.o obj-$(CONFIG_SND_SOC_CS42XX8) += snd-soc-cs42xx8.o obj-$(CONFIG_SND_SOC_CS42XX8_I2C) += snd-soc-cs42xx8-i2c.o obj-$(CONFIG_SND_SOC_CS4349) += snd-soc-cs4349.o +obj-$(CONFIG_SND_SOC_CS53L30) += snd-soc-cs53l30.o obj-$(CONFIG_SND_SOC_CX20442) += snd-soc-cx20442.o obj-$(CONFIG_SND_SOC_DA7210) += snd-soc-da7210.o obj-$(CONFIG_SND_SOC_DA7213) += snd-soc-da7213.o