Currently when built with DEBUG DAPM will dump information about
the power state decisions it is taking for each widget to dmesg.
This isn't an ideal way of getting the information - it requires
a kernel build to turn it on and off and for large hub CODECs the
volume of information is so large as to be illegible. When the
output goes to the console it can also cause a noticable impact
on performance simply to print it out.

Improve the situation by adding a dapm directory to our debugfs
tree containing a file per widget with the same information in
it. This still requires a decision to build with debugfs support
but is easier to navigate and much less intrusive.

In addition to the previously displayed information active streams
are also shown in these files.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Currently DAPM interfaces with the audio streams to and from the
processor at the DAC and ADC widgets. As the digital capabilities
of parts increases this is becoming a less and less able to meet
the needs of parts.

To meet the needs of these devices create new widgets interfacing
with the TDM bus but not integrated into any other functionality.
Audio can then be routed to and from these widgets using existing
routing widgets.

A slot number is provided in the definition but this is currently
not used yet. This is intended to support devices which can use
more than one TDM slot on a single interface.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Ensure that the audio subsystem is powered down cleanly when the system
shuts down by providing a shutdown operation. This ensures that all the
components have been returned to an off state cleanly which should avoid
audio issues from partially charged capacitors or noise on digital inputs
if the system is restarted quickly.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: Ben Dooks <ben-linux@fluff.org>

Rather than managing the bias level of the system based on if there is
an active audio stream manage it based on there being an active DAPM
widget. This simplifies the code a little, moving the power handling
into one place, and improves audio performance for bypass paths when no
playbacks or captures are active.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

DAPM has always applied any changes to the power state of widgets as soon
as it has determined that they are required. Instead of doing this store
all the changes that are required on lists of widgets to power up and
down, then iterate over those lists and apply the changes. This changes
the sequence in which changes are implemented, doing all power downs
before power ups and always using the up/down sequences (previously they
were only used when changes were due to DAC/ADC power events). The error
handling is also changed so that we continue attempting to power widgets
if some changes fail.

The main benefit of this is to allow future changes to do optimisations
over the whole power sequence and to reduce the number of walks of the
widget graph required to check the power status of widgets.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Many modern CODECs have shared resources on chip which must be enabled
for portions of the chip to work but which can be disabled at other times
in order to achieve power savings. Examples of such resources include
power supplies and some internal clocks.

Since these widgets are dependencies for the audio path but do not carry
audio signals they require slightly different handling to most widgets -
they do not contribute to the audio path and so should not be counted as
either inputs or outputs during path walks.

Cases where one supply provides a supply for another will require
additional work. There is also room for more optimisation of the graph
walking to avoid repeated checks for the same thing.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Rather than having switch statements at point of use make the DAPM
power check a member of the widget structure and set it when we
instantiate the widget.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

On some systems it is desirable for control for DAPM pins to be provided
to user space. This is the case with things like GSM modems which are
controlled primarily from user space, for example. Provide a helper which
exposes the state of a DAPM pin to user space for use in cases like this.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>