Re: [Ksummit-discuss] [Unconference] PM dependencies

[Mauro Carvalho Chehab <mchehab@osg.samsung.com>]

Em Mon, 18 Aug 2014 15:08:05 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> Hello,
> 
> As we still haven't hammered out PM dependencies I propose discussing it in 
> the unconference track. Shuah and Mauro have reminded me of their interest in 
> the topic, does anyone else want to discuss it ?

Count on me on that.

> The unconference slots are 30 minutes long only. We should avoid spending all 
> the allocated time presenting the problems, so please post your use case(s) in 
> a reply to this mail thread if you plan to participate.

One usecase we're seeing is how to properly resume a complex media device
that was streaming when the system got suspend. Resuming it is a complex
challenge, if we want to keep the device streaming after resume, as
such devices depend on:
- I2C subsystem (as the communication with tuner/demod depends on that);
- block subsystem and eventually userspace, in order to load a firmware
  (generally required by tuner and/or by the demod);
- DVB core subsystem, as some threads need to be started there;
- Media subsystem;
- Input subsystem (due to remote controller). Sometimes, IR is provided
  by a separate device driver, like mceusb, but there are some devices,
  where the IR receiver is connected to some weird block (on au0828 devices,
  the IR is connected to the Analog/Digital TV demod - au8522);
- Tuner sub-driver, with needs to tune to the last channel, after re-loading
  the firmware (if it needs);
- DVB (or analog TV) demodulator, with need to be coordinated with the
  tuner at dvb recovery, in order to pass the right parameters to decode
  the video system used by the tuned channel;
- For analog TV, the VBI decoding logic should also be reenabled, if
  it was active during suspend time;
- ALSA driver (on some cases, using an USB Vendor Class, but on other
  cases just uses the standard USB Audio Class supported by an independent
  driver;
- Restart some threads that were stopped at resume (some are
  driver-specific, while others are part of the DVB or Remote Controller
  core).

The PM recovery order is important, as doing it at the wrong order
may either cause the device to not work after resume or to produce
bad side effects.

For example, cx88 audio carrier detection happens by a kthread that
does some DSP processing to detect the audio standard. If the ALSA
audio is unmuted too early, white noise can be output to the
speakers.

On other devices, like tm6000, both audio, video and VBI comes via
the very same DMA engine, and are packed together (in a way that
looks like an MPEG-TS). So, the ALSA driver or VBI will only work
if the video is streaming.

Of course, we don't want to restart video streaming before having
the device tuned and the demod properly set.

Regards,
Mauro