[Ksummit-discuss] [Unconference] PM dependencies

[Ksummit-discuss] [Unconference] PM dependencies

[Laurent Pinchart]

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 ?

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.

-- 
Regards,

Laurent Pinchart

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

[Linus Walleij]

On Mon, Aug 18, 2014 at 8:08 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:

> 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 me in.

Yours,
Linus Walleij

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

[Shuah Khan]

On Mon, Aug 18, 2014 at 8:11 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Aug 18, 2014 at 8:08 AM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>
>> 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 me in.
>

Count me in  as well. I updated the wiki for 2:30 timeslot

-- Shuah

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

[Mauro Carvalho Chehab]

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

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

[Mauro Carvalho Chehab]

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 ?
> 
> 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.
> 
Greg,

I'm thinking that one solution that won't sound too hacky would be to add
a module init macro that would mark a driver to be the first one to be
probed, to be handled by the device core. If the device core
finds a USB (PCI) ID for a table initialized this way, it will only call
one device driver. This device will be the master device for that USB ID,
and he will call some init function that will do the probing of the other
device drivers associated with that specific device, being allowed to
replace the drivers specific fops by their own internal ones.

This way, at resume time, it can call each driver's specific .resume code
on the right order.

Would that work?

Regards,
Mauro

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

[Greg Kroah-Hartman]

On Tue, Aug 19, 2014 at 03:08:08PM -0500, Mauro Carvalho Chehab wrote:
> 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 ?
> > 
> > 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.
> > 
> Greg,
> 
> I'm thinking that one solution that won't sound too hacky would be to add
> a module init macro that would mark a driver to be the first one to be
> probed, to be handled by the device core. If the device core
> finds a USB (PCI) ID for a table initialized this way, it will only call
> one device driver. This device will be the master device for that USB ID,
> and he will call some init function that will do the probing of the other
> device drivers associated with that specific device, being allowed to
> replace the drivers specific fops by their own internal ones.
> 
> This way, at resume time, it can call each driver's specific .resume code
> on the right order.
> 
> Would that work?

As we discussed in person later on that day, this will not work due to
linking vs. module issues, and lots of other things.

People have been asking for "priorities" of driver binding/matching for
over a decade, but no one has come up with a way to solve the issues
involved, sorry.

greg k-h