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. 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 >
Attachment:
pgpTNHlIByX3G.pgp
Description: PGP signature
