[RFC v2 0/5] Common Display Framework

[Laurent Pinchart]

Hi Sylwester,

On Tuesday 18 December 2012 11:59:35 Sylwester Nawrocki wrote:
> On 12/18/2012 07:21 AM, Rob Clark wrote:
> > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie<airlied at gmail.com>  wrote:
> >> So this might be a bit off topic but this whole CDF triggered me
> >> looking at stuff I generally avoid:
> >> 
> >> The biggest problem I'm having currently with the whole ARM graphics
> >> and output world is the proliferation of platform drivers for every
> >> little thing. The whole ordering of operations with respect to things
> >> like suspend/resume or dynamic power management is going to be a real
> >> nightmare if there are dependencies between the drivers. How do you
> >> enforce ordering of s/r operations between all the various components?
> 
> There have been already some ideas proposed to resolve this at the PM
> subsystem level [1]. And this problem is of course not only specific to
> platform drivers. The idea of having monolithic drivers, just because we
> can't get the suspend/resume sequences right otherwise, doesn't really sound
> appealing. SoC IPs get reused on multiple different SoC series, no only by
> single manufacturer. Whole graphics/video subsystems are composed from
> smaller blocks in SoCs, with various number of distinct sub-blocks and same
> sub-blocks repeated different number of times in a specific SoC revision.
> Expressing an IP as a platform device seems justified to me, often these
> platform devices have enough differences to treat them as such. E.g. belong
> in different power domain/use different clocks. Except there is big issue
> with the power management... However probably more important is to be able
> to have driver for a specific IP in a separate module.
> 
> And this suspend/resume ordering issue is not only about the platform
> devices. E.g. camera subsystem can be composed of an image sensor sub-device
> driver, which is most often an I2C client driver, and of multiple SoC
> processing blocks. The image sensor can have dependencies on the SoC sub-
> blocks. So even if we created monolithic driver for the SoC part, there are
> still two pieces to get s/r ordering right - I2C client and SoC drivers. And
> please don't propose to merge the sensor sub-device driver too. There has
> been a lot of effort in V4L2 to separate those various functional blocks
> into sub-devices, so they can be freely reused, without reimplementing same
> functionality in each driver. BTW, there has been a nice talk about these
> topics at ELCE [2], particularly slide 22 is interesting.
> 
> I believe the solution for these issues really needs to be sought in the PM
> subsystem itself.

I tend to agree with you, or at least I believe we should research a proper 
solution in the PM framework. In the meantime, though, I think early 
suspend/late resume might provide an intermediate solution.

> > I tend to think that sub-devices are useful just to have a way to
> > probe hw which may or may not be there, since on ARM we often don't
> > have any alternative.. but beyond that, suspend/resume, and other
> > life-cycle aspects, they should really be treated as all one device.
> > Especially to avoid undefined suspend/resume ordering.
> 
> [1] https://lkml.org/lkml/2009/9/9/373
> [2]
> http://elinux.org/images/9/90/ELCE2012-Modular-Graphics-on-Embedded-ARM.pdf

-- 
Regards,

Laurent Pinchart