-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Mon, 20 Aug 2012 15:18:01 +0200
Thierry Reding <thierry.reding@xxxxxxxxxxxxxxxxx> escribió:
> 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.
Can we please push to get tegradrm merged into staging in linus's tree.
For fedora to ship a working console and allow tegra systems to run X
etc we need to get it merged upstream. There is a lot of fedora folks
with trimslices and other tegra based devices, it would be good to see
them fully supported for Fedora 18, we are very short in time we are
currently running 3.6 based kernels and we follow very closely linus's
tree. Building all kernels from it with as little patching as possible.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAlAzBYIACgkQkSxm47BaWfeeiwCgsGIrn8MCCgC8DEHHBXJ1u+Vb
I1wAn2RmfpPSBccEVzxG4e/9MDjBT1tH
=khEj
-----END PGP SIGNATURE-----
��.n��������+%������w��{.n�����{��נ���^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
