On Wed, Aug 22, 2012 at 11:42:00AM +0300, Terje Bergström wrote: > On 21.08.2012 17:57, Thierry Reding wrote: > > Finally the upload is done. You can find my latest work in the next > > branch of the following repository: > > > > git://gitorious.org/linux-tegra-drm/linux-tegra-drm.git > > > > It's down to two patches and based on next-20120820. Eventually I was > > going to maybe split it up a bit to separate at least the hunks for > > arch/ (Stephen will probably want this anyway) and maybe also some > > functionality like HDMI support. > > Hi, > > What's the purpose of the drm_clients list? I notice that the drivers > register into that list, but I can't see how the list is used. I feel > like I'm missing something. This is used to determine when the DRM driver can be safely initialized. Basically the host1x driver scans the DT for display controllers and outputs and adds them to this list if they are available. When the drivers for those device call host1x_register_client(), they'll be moved to the drm_active list and once the the drm_clients list becomes empty, the DRM driver is registered using the call to drm_soc_init(). > This patch ties all of the drivers to host1x. As not all host1x clients > are going to be controlled via DRM, we need to eventually decouple > these. I'm expecting the host1x hardware to controlled by nvhost driver, > and tegradrm will just call nvhost when it needs host1x. I'm not sure how this can be solved any better than the above. All the drivers are inherently tied to host1x anyway. That's why I suggested putting the host1x driver along with the DRM driver in the last version of these patches so that we can get the initial support written. If the functionality is required by other drivers we have two options, either the API is exported from the DRM driver or the host1x driver is moved to a more central location where other drivers can use it. > I know it's a bit difficult to understand in concrete terms what I am > after as long as I haven't been upload any code. The memory management > is one obstacle that needs some code before nvhost is usable in upstream > kernel, and lack of device tree support is another. That's precisely why I think it's better to get going with the DRM part and keep the tight coupling for now. If needed it can always be split off at a later point in time should the need arise. Thierry
Attachment:
pgpPzOKew6Fed.pgp
Description: PGP signature
