Re: Binding together tegradrm & nvhost

[Mark Zhang <markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

On Mon, 2012-08-20 at 21:18 +0800, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Mon, Aug 20, 2012 at 04:01:07PM +0300, 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.
> > 
> > 2) Device tree parsing
> > At bootup, we need to parse only host1x node and create a device for
> > that. host1x probe will need to dig into host1x to create the children.
> > This is something that we'll need to implement first in the internal
> > kernel. tegra-dc would get probed only after this sequence. If this is
> > ok, I'll take care of this part, and adjustments to tegradrm when this
> > becomes topical.
> 
> I have a new patch series that takes care of these two steps. Mark sent
> some patches for Tegra30 and HDMI on top of the older series that I need
> to merge with what I have. Maybe I'll decide to send the series out
> without the patches merged, depending on how much time I'll get or how
> much effort it requires. I had hoped the next series would have working
> HDMI support, which is why I waited.

OK. So I'm going to pause the patch writing right now and wait for your
codes to be published on linux-tegra. Regardless of whether my patches
be merged into yours, I'll provide patches for the version which you
send to maillist in the near future.

> 
> Basically what I have is a very rudimentary driver for host1x, which
> waits for some of the subdevices to be registered and then creates a
> dummy device against which the Tegra DRM driver can bind. It's not quite
> what you proposed above, but very similar.
> 
> For now I've also put the host1x driver in the same directory as the
> Tegra DRM because there are no other users. We may want to change that
> at some point.
> 
> > We include in device tree the register addresses. Some information that
> > would be needed is still clocks, clock gating behavior, power domain
> > ids, mapping of client devices to channels, and mapping of sync points
> > per channnel
> > 
> > 3) The handling of ioctl's from user space
> > The ioctl's represent the needed synchronization and channel
> > functionality. I'll write the necessary glue. There would be two
> > categories of ioctl's:
> > 
> > 3a) Simple operations such as synchronization:
> > 
> > Wait, signal, read, etc. are exported from nvhost as public APIs, and
> > tegradrm simply calls them. No big hurdle there. I already have concept
> > code to do this.
> > 
> > 3b) Channel operations:
> > 
> > tegradrm needs to have a concept of logical channel. Channel open
> > creates a logical channel (/context) by calling nvhost. nvhost needs to
> > know which hw is going to be used by the channel to be able to control
> > power, and to map to physical channel, so that comes as a parameter in
> > ioctl.
> > 
> > Each channel operation needs to pass the channel id, and tegradrm passes
> > the calls to nvhost. Most important operation is submit, which sends a
> > command buffer to nvhost's queue.
> 
> Some thought will probably have to go into these. The easiest would
> probably be to have a driver that needs to do synchronization or other
> channel operations. It may make the requirements on the exact ioctls
> clearer.
> 
> > 4) Buffer management
> > We already know that this is a missing part. Hopefully we can get this
> > filled soon.
> 
> This should be cheap if we use GEM along with DMA-BUF. However without
> other drivers that the buffers can be shared with this won't do us any
> good. So maybe something like a video capturing driver for Tegra should
> be added first so we can actually test buffer sharing.
> 
> > 
> > Terje
> > 
> 
> * Unknown Key
> * 0x7F3EB3A1