On Tue, Aug 21, 2012 at 03:53:07PM -0600, Stephen Warren wrote: > On 08/20/2012 07:01 AM, Terje Bergström wrote: > > Hi, > > > > I've been trying to figure out the best way to bind together tegradrm > > and nvhost. I assume that nvhost and tegradrm will live as separate > > drivers, with tegradrm taking care of display controller, and nvhost > > taking care of host1x and other client devices. > > > > I've identified a bumps that we need to agree on. I've included here the > > problem and my proposal: > > > > 1) Device & driver registration > > tegradrm registers as platform_driver, and exports ioctl's. Here we > > already have to agree on which device the platform_driver maps to. > > Currently it maps to host1x, but we'll need to move control of host1x to > > nvhost driver. We'll need to pass drm_platform_init() some > > platform_device - I propose that we create a virtual device for this. > > I don't think there's any need for a virtual device. There's one device > in HW, and that can be represented by a single device object within the > kernel. There's nothing then stopping that device exposing multiple > APIs, i.e. providing host1x APIs to clients, and also instantiating the > tegra-drm driver directly on top of the host1x device. The problem with the host1x' platform device is that we already associate host1x' private data with it. drm_platform_init() will eventually override that with the struct drm_device. That's the reason for the drm_soc patch that I've included. It basically creates a child device of host1x that the DRM driver can bind to in order to side-step the issue. This isn't as hackish as it may sound because the DRM device is essentially a virtual device and no platform device would really be a good choice. Thierry
Attachment:
pgp_s5de0i9b5.pgp
Description: PGP signature
