)]}'
{
  "log": [
    {
      "commit": "e024e11070a0a0dc7163ce1ec2da354a638bdbed",
      "tree": "add483e7428f91da6f3c26be702aa45e6d69b694",
      "parents": [
        "c836e862803b2aa2bd9a354e151316d2b42c44ec"
      ],
      "author": {
        "name": "Dave Airlie",
        "email": "airlied@redhat.com",
        "time": "Wed Jun 24 09:48:08 2009 +1000"
      },
      "committer": {
        "name": "Dave Airlie",
        "email": "airlied@redhat.com",
        "time": "Wed Jul 29 15:42:18 2009 +1000"
      },
      "message": "drm/radeon/kms: add initial colortiling support.\n\nThis adds new set/get tiling interfaces where the pitch\nand macro/micro tiling enables can be set. Along with\na flag to decide if this object should have a surface when mapped.\n\nThe only thing we need to allocate with a mapped surface should be\nthe frontbuffer. Note rotate scanout shouldn\u0027t require one, and\nback/depth shouldn\u0027t either, though mesa needs some fixes.\n\nIt fixes the TTM interfaces along Thomas\u0027s suggestions, and I\u0027ve tested\nthe surface stealing code with two X servers and not seen any lockdep issues.\n\nI\u0027ve stopped tiling the fbcon frontbuffer, as I don\u0027t see there being\nany advantage other than testing, I\u0027ve left the testing commands in there,\njust flip the fb_tiled to true in radeon_fb.c\n\nOpen: Can we integrate endian swapping in with this?\n\nFuture features:\ntexture tiling - need to relocate texture registers TXOFFSET* with tiling info.\n\nThis also merges Michel\u0027s cleanup surfaces regs at init time patch\neven though it makes sense on its own, this patch really relies on it.\n\nSome PowerMac firmwares set up a tiling surface at the beginning of VRAM\nwhich messes us up otherwise.\nthat patch is:\nSigned-off-by: Michel Dänzer \u003cdaenzer@vmware.com\u003e\n\nSigned-off-by: Dave Airlie \u003cairlied@redhat.com\u003e\n"
    },
    {
      "commit": "ad49f501867cba87e1e45e5ebae0b12435d68bf1",
      "tree": "4602e5caf96451b1dcdda7a38628d494466d2e20",
      "parents": [
        "61b576dbbe6a19d102c025ebc102a0749e2d3c80"
      ],
      "author": {
        "name": "Dave Airlie",
        "email": "airlied@linux.ie",
        "time": "Fri Jul 10 22:36:26 2009 +1000"
      },
      "committer": {
        "name": "Dave Airlie",
        "email": "airlied@redhat.com",
        "time": "Wed Jul 15 17:13:18 2009 +1000"
      },
      "message": "drm/ttm/radeon: add dma32 support.\n\nThis add support for using dma32 memory on gpus that really need it.\n\nCurrently IGPs are left without DMA32 but we might need to change\nthat unless we can fix rs690.\n\nSigned-off-by: Dave Airlie \u003cairlied@redhat.com\u003e\n"
    },
    {
      "commit": "d1724078d6a01177c1db4ea0b75fda1ca8a73d57",
      "tree": "24c2cef55a572938acadbbd662df4d65701ca38e",
      "parents": [
        "531369e62649bb8f31217cc0bf33ee6f89f1dff6"
      ],
      "author": {
        "name": "Thomas Hellstrom",
        "email": "thellstrom@vmware.com",
        "time": "Wed Jun 24 19:57:35 2009 +0200"
      },
      "committer": {
        "name": "Dave Airlie",
        "email": "airlied@redhat.com",
        "time": "Wed Jul 15 17:13:09 2009 +1000"
      },
      "message": "ttm: Make messages more readable.\n\nSigned-off-by: Thomas Hellstrom \u003cthellstrom@vmware.com\u003e\nSigned-off-by: Dave Airlie \u003cairlied@redhat.com\u003e\n"
    },
    {
      "commit": "ba4e7d973dd09b66912ac4c0856add8b0703a997",
      "tree": "32a87edb83a427ffd22645c5f77e6cec8be4e719",
      "parents": [
        "e6c03c5b40314d787f7053f631594d6b1bd609e8"
      ],
      "author": {
        "name": "Thomas Hellstrom",
        "email": "thellstrom@vmware.com",
        "time": "Wed Jun 10 15:20:19 2009 +0200"
      },
      "committer": {
        "name": "Dave Airlie",
        "email": "airlied@redhat.com",
        "time": "Mon Jun 15 09:37:57 2009 +1000"
      },
      "message": "drm: Add the TTM GPU memory manager subsystem.\n\nTTM is a GPU memory manager subsystem designed for use with GPU\ndevices with various memory types (On-card VRAM, AGP,\nPCI apertures etc.). It\u0027s essentially a helper library that assists\nthe DRM driver in creating and managing persistent buffer objects.\n\nTTM manages placement of data and CPU map setup and teardown on\ndata movement. It can also optionally manage synchronization of\ndata on a per-buffer-object level.\n\nTTM takes care to provide an always valid virtual user-space address\nto a buffer object which makes user-space sub-allocation of\nbig buffer objects feasible.\n\nTTM uses a fine-grained per buffer-object locking scheme, taking\ncare to release all relevant locks when waiting for the GPU.\nAlthough this implies some locking overhead, it\u0027s probably a big\nwin for devices with multiple command submission mechanisms, since\nthe lock contention will be minimal.\n\nTTM can be used with whatever user-space interface the driver\nchooses, including GEM. It\u0027s used by the upcoming Radeon KMS DRM driver\nand is also the GPU memory management core of various new experimental\nDRM drivers.\n\nSigned-off-by: Thomas Hellstrom \u003cthellstrom@vmware.com\u003e\nSigned-off-by: Jerome Glisse \u003cjglisse@redhat.com\u003e\nSigned-off-by: Dave Airlie \u003cairlied@redhat.com\u003e\n"
    }
  ]
}