Re: Binding together tegradrm & nvhost

[Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]

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 #2: Type: application/pgp-signature, Size: 836 bytes --]