[RFC v2 0/5] Common Display Framework

[Sylwester Nawrocki]

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 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

Thanks,
Sylwester