Hi On 07/03/2014 10:06 AM, Felipe Balbi wrote: > Hi, > > On Thu, Jul 03, 2014 at 09:57:39AM -0500, Dan Murphy wrote: >> On 07/03/2014 09:52 AM, Felipe Balbi wrote: >>> Hi, >>> >>> On Thu, Jul 03, 2014 at 09:39:53AM -0500, Dan Murphy wrote: >>>> +static int tas2552_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt) >>>> +{ >>>> + u8 serial_format; >>>> + struct snd_soc_codec *codec = dai->codec; >>>> + >>>> + switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) { >>>> + case SND_SOC_DAIFMT_CBS_CFS: >>>> + serial_format = 0x00; >>>> + break; >>>> + case SND_SOC_DAIFMT_CBS_CFM: >>>> + serial_format = TAS2552_WORD_CLK_MASK; >>>> + break; >>>> + case SND_SOC_DAIFMT_CBM_CFS: >>>> + serial_format = TAS2552_BIT_CLK_MASK; >>>> + break; >>>> + case SND_SOC_DAIFMT_CBM_CFM: >>>> + serial_format = (TAS2552_BIT_CLK_MASK | TAS2552_WORD_CLK_MASK); >>>> + break; >>>> + default: >>>> + return -EINVAL; >>>> + } >>>> + >>>> + pm_runtime_get_sync(codec->dev); >>>> + >>>> + snd_soc_update_bits(codec, TAS2552_SER_CTRL_1, >>>> + (TAS2552_BIT_CLK_MASK | TAS2552_WORD_CLK_MASK), >>>> + serial_format); >>>> + >>>> + pm_runtime_put(codec->dev); >>> I have a feeling it's better to just put at the end of the function. >>> Remember your pm_runtime_put() will issue i2c transfers which can take a >>> looooooong time ;-) >> I thought about that but the next switch case could return if the format >> mask is invalid which means the runtime calls would not be balanced. >> >> So I decided to wrap the snd_soc calls with the pm_runtime calls to keep it >> balanced. > it looks like you can do both switch statements outside of the > pm_runtime region and cache results on serial_format and do a single > write to CTRL_1 register (?). If not, then just use two local variables. > Yeah I could probably consolidate these into a single call. And throw a debug statement in the default case to why the format was not set. Dan -- ------------------ Dan Murphy -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html