On Sun, Jun 20, 2010 at 09:28:41PM +1000, Stuart Longland wrote: > On Sat, Jun 19, 2010 at 11:57:07AM +0100, Mark Brown wrote: > > On Sat, Jun 19, 2010 at 07:49:08PM +1000, Stuart Longland wrote: > > > On Sat, Jun 19, 2010 at 02:12:21AM +0100, Mark Brown wrote: > > > > On Sat, Jun 19, 2010 at 08:24:36AM +1000, Stuart Longland wrote: > > There's no specific ALSA control for it, just make it a Switch. > Are switches variable? For what its worth, I've simplified things by > assuming the oversampling rate is identical for DAC and ADC. It is > possible to have DAC OSRs up to 1024... but the ADC OSR is limited to > 128. I keep them identical as it simplifies clock generation. > I'm thinking if I make this a control, it'd have to be some numeric > control (not a TLV, but something similar with a linear scale). If there's a range of selectable options then use an enum. Otherwise a regular ALSA control gives a linear mapping, but you can't skip any values. > > > Well, when the problem goes, so can the comment. :-) One question > > > though, the shift value derives the mask for further operations on these > > > registers... if we were to change the shift value so it reflected how > > > other widget types work, how does one define the mask? > > I'd intuitively expect it to be relative to the start of the controlled > > data rather than the start of the register. > Correct... but how do you define the mask's width? Would that be > derived from min or max (or both)? I'd expect it to define the bits to be overwritten by the update - it'd be related to the min and the max in that both need to be stored in a value masked out but not directly (note that I've not gone so far as to look at the actual control definition here). > I wasn't sure how else to do it, and this seemed to be the most flexible > option. However, if it's better as platform data, then platform data it > is. ;-) It's flexible but it's flexibility that it's not possible to actually use - like I say, these things get fixed when the board is laid out in almost all cases. > Yeah, this is to be expected, doesn't mean I haven't been caught out by > it more than once. The thing with the TLV320AIC3204... the bit clock is > derived from one of two sources (actually four)... the ADC's clock, or > the DAC's clock. If the ADCs are powered down, there's no ADC clock. > Likewise for the DAC. Consider creating supply widgets for the actual DACs and ADCs then using those to supply the clocks and NOPM DAC/ADC widgets. Not thought that through fully but I think it'd do the right thing. > > If you track this in the audio path setup/teardown path instead of > > looking at the DAC power status you should find everything works fine. > I'll have a closer look then. I figured I was "doing it wrong", but > couldn't see what the right way was. Would the event-handling widgets > be of use here? Possibly, another way of dealing with it might be to set the sources for all the clocks whenever you power up or down a DAC or ADC rather than based off the clock widgets themselves. > > > I wasn't sure about the link between AVDD and DVDD, so I left that > > > configurable. I'm guessing most will probably want it disabled. This > > > was configured using arbitrary register initialisation scripts, passed > > > in via the CODEC setup data... so at least things are headded in the > > > right direction. :-) > > What does this register actually do? Does it describe the hardware > > configuration to the device? > This is where I'm not clear on exactly what's going on... TI's > documentation seems to have a fair bit to be desired. When the CODEC > powers up, the AVDD and DVDD are weakly connected together by some high > resistance inside the chip. > This register allows you to break that link so that AVDD and DVDD are > separate. I'm guessing this would be the norm, perhaps I'll just ditch > the relevant platform data configuration. That sounds... intresting. I note that there's an LDO in there - is this for bootstrapping the LDO by any chance? Power DVDD from AVDD until the LDO has been enabled by software and then disable the link. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
