On 05/13/2013 01:41 PM, Matt Sealey wrote:
Nack.
While I like the concept, I don't like the following:
- That the regulator-before-read-chip-id should be a separate patch (please)
I thought about doing like this initially and that would require some heavy cleanup.
- That this revision check went away without anyone fully knowing WHY
it was there in the first place
- I am fairly certain the first run consumer-purchased Efika MX boards
have an older SGTL5000 on them and I would like to know if the internal LDO actually operates on those.. and don't want to churn by reintroducing such a patch.
Can you test on this platform, please?
As far as I see the operation after patch would be that VDDD is accepted in the DT, enabled, and then LDO is enabled (thus shunting VDDD-LDO supply to the highest of VDDA or VDDIO, or VDDA in the case VDDA&VDDIO >3.1V) which leaves the board VDDD enabled until the driver is removed.
How does this differ from current code?
If you're enabling the LDO, please disable board VDDD.
Agree, but that would be another patch.
And please consider that on Efika MX and Babbage, VDDD is supplied at 1.2V by a separate on-board regulator, so using VDDIO->LDO->1.2V is completely obtuse and doubles codec power consumption.
Babbage leaves VDDD unconnected.
I am leaning towards the case that the revision check is redundant, in that since there is no design data that says the LDO was non-operational or has any differences between versions the only difference is in the particulars of the implementation on the board itself. It seems like it is coded as a non-intrusive hack on the assumption that "any board with SGTL5000 0x11 is a production Freescale reference platform which does not supply VDDD" rather than having to go and re-validate a ridiculous number of supported reference designs. Unless I see data otherwise..
Yes, I also do not find any data for this revision check.
If that's true, what we need here is to keep VDDD if it's supplied, and remove VDDD from the DT where it is not, and optionally tell the codec to force usage of the internal LDO in the case of supplied VDDD (i.e. please disable VDDD), and WHICH source to use for the charge pump (VDDIO or VDDA) in case the automated default setting is not desirable..
Yes, but this would also need to be another patch.