On 05.12.2012 13:13, Thierry Reding wrote: > What I propose is to move the client registration code that is currently > in drivers/gpu/drm/tegra/host1x.c to the host1x driver, which may or may > not end up in drivers/gpu/host1x. Ok. > >> host1x hardware access must be encapsulated in host1x driver >> (drivers/gpu/host1x if that's the location we prefer). As for the >> management of the list of DRM clients, we proposed the move to drm.c, >> because host1x hardware would anyway be controlled by a different >> driver. Having file called host1x.c in tegradrm didn't sound logical, as >> its not really controlling host1x, and its probe wouldn't be called. > > Oh well, at the time nobody from NVIDIA was involved so I wrote that > code in preparation for proper host1x support that I thought I would > have to add myself at some point. I'm more than glad that I don't have > to do this all by myself. However the patch proposed in this series > breaks a number of requirements such as proper encapsulation, which I > already mentioned in more detail in another mail. Hmm, I'm not sure if I remember that you refer to by the proper encapsulation. Is that the fact that we bind DRM to a sub-client? > The problem that this solves is that the DRM driver needs to be bound to > a specific platform device. None of the DRM subdevices are suitable > because they are only part of the whole DRM device. I think that host1x > is the only device that fits here. > > Note that this is only an administrative problem. It shouldn't interfere > with the way host1x works. The goal is that the DRM device is registered > at the proper hierarchical location. > > The circular dependency is indeed a problem, though. Quite frankly I > have no idea how to solve this. However the approach taken in the > current patch will break several other requirements as I already > explained. The problem with doing drm_platform_init() with host1x device as parameter is that drm_get_platform_dev() will take control of drvdata. We'd need to put host1x specific struct host1x pointer to some other place and I'm not sure what that place could be. You're right in that binding to a sub-device is not a nice way. DRM framework just needs a "struct device" to bind to. exynos seems to solve this by introducing a virtual device and bind to that. I'm not sure if this is the best way, but worth considering? Terje _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
