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 -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
