On Wed, Oct 01, 2014 at 06:17:04PM +0100, Mark Brown wrote: > On Wed, Oct 01, 2014 at 02:48:53PM +0200, Thierry Reding wrote: > > On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote: [...] > > > and that the DT must not contain any hint of simplefb as > > > shipped separately. > > > Well, I don't think it should because it describes the same resources > > that the device tree node for the real device already describes. But > > perhaps this is one of the cases where duplication isn't all that bad? > > If we were worried about this wecould also do it by referring to > those nodes and saying "get all the resources these things need" rather > than duplicating the references (this might make it easier to work out > when the system is ready to hand off to the real drivers). That's problematic to some degree because not all resource types may have a binding that allows them to be automatically probed, so it could be difficult to implement "get all the resources this thing needs". But perhaps we can come up with good enough heuristics to make that work reliably. One downside of that is that there may be a lot of components involved in getting display to work and not all resources may be needed to keep the current state running, so we may be claiming too many. But given that we'd eventually release all of them anyway this shouldn't be too much of an issue. > > > That's never going to work well as far as I can see > > > but doesn't seem like an ABI stability issue, or at least not a > > > reasonable one. > > > It would work well under the assumption that the kernel wouldn't be > > touching any of the resources that simplefb depends on. If that's not a > > reasonable assumption then I think we can't make simplefb work the way > > it's currently written. > > I can't see how that's reasonable unless the kernel has some way of > figuring out what it shouldn't be touching. Agreed. It's become clear in this discussion that we can't do this in the way x86 and other more firmware-oriented architectures do it. They get away with it because they in fact hide all of this in the firmware or don't provide a way to control the resources in such a fine-grained manner to begin with. Thierry
Attachment:
pgpvVA4FcPaRJ.pgp
Description: PGP signature
