Mark,
=20
Could you expand on that a bit - what are you referring to as the=20 standard here? This could just be a case of different hardware=20 manufacturers implementing slightly different things and giving
them
the same name.
=20
Yes, Exactly it's just a case of different manufacturers=20 implementing
the same thing in different way. =20 The idea in ASoC is to follow a consistent naming scheme within ASoC=20 rather than implement the APIs in a per-manufacturer fashion. A given=20 DAI mode should always produce the same effect in hardware no matter=20 which device is being configured. This makes the code much easier to=20 work with since otherwise you'd not be able to tell from the code if=20 the devices that are being connected are configured compatibly simply=20 by looking at the set_dai_fmt() calls. =20
_From this I came to conclusion in ASoC Normal FS means active high
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=