No subject

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.
>=20
> > I am referring the davinci ASP default polarities (without=20
> > inversion)
> of FS and BCLK as standard.
>=20
> 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.
>=20
> > In davinci ASP Frame sync signals internal to the ASP are active
> high.
> > 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.
>=20
> Troy left the frame clock settings alone so I'll assume you've no=20
> concerns there?

Yes, No concerns here

>=20
> > 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.
>=20
> > 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
> )case.
>=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.
>=20

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).
>=20
> 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.

Thanks =20

>=20
> [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


Regards
Naresh=