Thu Nov 6 11:49:12 CET 2008
and Normal BCLK means receive data sampled on rising edge and transmit=20
data driven on falling edge. Correct me if I am wrong here.
> For most newer SoC CPUs (like the DaVinci) the drivers have to=20
> simulate the various clocking modes by configuring the chip rather=20
> than by having native support for the modes in the chip.
> > I am referring the davinci ASP default polarities (without=20
> > inversion)
> of FS and BCLK as standard.
> Like I say, the DaVinci chip defaults don't matter here - what matters=20
> is the mode the DAI is supposed to be operating in.
> > In davinci ASP Frame sync signals internal to the ASP are active
> > The Frame sync clock (either FSX or FSR) is XORed with Frame sync
> polarity bit (FSXP or FSRP).
> > So if the requirement is for frame sync active low FSXP and FSRP=20
> > bits
> in PCR register should be set.
> Troy left the frame clock settings alone so I'll assume you've no=20
> concerns there?
Yes, No concerns here
> > Similarly the BCLK (CLKX and CLKR) is XORed with BCLK polarity bit
> (CLKXP and CLKRP).
> > Internally the transmit data driven on rising edge of CLKX and
> receive data sampled on falling edge of CLKR.
> > To inverse this CLKXP and CLKRP should be set.
> > According to this the existing code is proper since it is not=20
> > setting
> any polarity bits in _SOC_DAIFMT_NB_NF (Normal bit and Normal Frame=20
> The DaVinci driver is configuring the clocks to match DSP mode (when=20
> using I2S mode it flips the inversion bits in the format before using=20
> them). For DSP mode data is available on the first rising edge of=20
> BCLK so sampling should be done on the rising edge. This means that=20
> the data has to be driven out on the falling edge to ensure that it is=20
> ready to be sampled on the rising edge. Troy's changes implement this=20
> so they look correct to me.
Yes, its correct according to ASoC polarity standards
> > And also in AIC33 codec there is no question of polarities since it
> is directly configurable through modes (either I2S or DSP).
> The inversions apply to the standard clocking for a given mode. For=20
> example, with I2S LRCLK clock inversion is essentially equivalent to=20
> swapping left and right channels. This facility is implemented by a=20
> reasonable number of codecs and made available through the API since=20
> it improves interoperability. Some CPUs (especially those with hand=20
> configured ports rather than native support for the clocking modes)=20
> have trouble doing some of the standard modes but can deal with=20
> inverted versions of one or both of the clocks.
> [BTW, your MUA appears to be generating lines ~90-100 characters long=20
> - it'd help if it were to go for something less than 80 characters=20
> since it makes your messages easier to read and reply to with standard=20
> mail clients.]
Sorry, I will take care of this=20
More information about the Alsa-devel