On Thu, May 20, 2010 at 09:03:53AM +0300, Peter Ujfalusi wrote:
On Wednesday 19 May 2010 18:05:12 ext Mark Brown wrote:
I guess my reasoning was to avoid the following DAPM route, which for me seamed weird: soc codec | tap6130a2 | machine driver codec_DAC -> .. -> codec_OUTPUT -> tpa_PGA -> tpa_OUTPUT -> machine_HP
It seamed wrong to have codec_OUTPUT and tpa_OUTPUT in the same DAPM route.
That seems absolutely fine to me - it's something I'd expect to happen as we move into a multi-chip ASoC world, you'll have signals which go out of one chip and into another before going to the edge of the system. The output wigdget is the output of one chip but there's no reason you can't use it as an input for another chip.
They may also wish to use the event that is available on the jack widget to perform some board specific action when the headphone is activated.
The event is _usually_ needed to toggle the power for the amp (enable/disable). The power for the tpa is managed within the driver, so no additional enable is needed.
Well, usually the event is completely unused and the headphone widget is entirely ornamental.
There's no actual requirement to define headphone widgets if they don't have any other code associated with them - if the outputs are left unconnected the effect will be the same as if a noop and unused headphone widget were there.
That is true, but in that case why would anyone add the tpa amp to their DAPM route in the first place (when it is not connected)?
They wouldn't, I'm just saying that having the extra headphone widget on the end is not a requirement for anything to function.