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@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
