)]}'
{
  "log": [
    {
      "commit": "198fc108ee4c2cd3f08954eae6a819c81c03214b",
      "tree": "153fdb793142ef5ee8e0ab6198dcde32866b062c",
      "parents": [
        "3f16ff608a75c8bf28c8cafed12e076d67a3602a"
      ],
      "author": {
        "name": "Eric Miao",
        "email": "ycmiao@ycmiao-hp520.(none)",
        "time": "Tue Dec 23 17:49:43 2008 +0800"
      },
      "committer": {
        "name": "Eric Miao",
        "email": "eric.miao@marvell.com",
        "time": "Mon Dec 29 18:00:04 2008 +0800"
      },
      "message": "[ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devices\n\nPXA27x and later processors support overlay1 and overlay2 on-top of the\nbase framebuffer (although under-neath the base is also possible). They\nsupport palette and no-palette RGB formats, as well as YUV formats (only\navailable on overlay2). These overlays have dedicated DMA channels and\nbehave in a similar way as a framebuffer.\n\nThis heavily simplified and re-structured work is based on the original\npxafb_overlay.c (which is pending for mainline merge for a long time).\n\nThe major problems with this pxafb_overlay.c are (if you are interested\nin the history):\n\n  1. heavily redundant (the control logics for overlay1 and overlay2 are\n     actually identical except for some small operations,  which are now\n     abstracted into a \u0027pxafb_layer_ops\u0027 structure)\n\n  2. a lot of useless and un-tested code (two workarounds which are now\n     fixed on mature silicons)\n\n  3. cursorfb is actually useless, hardware cursor should not be used\n     this way, and the code was actually un-tested for a long time.\n\nThe code in this patch should be self-explanatory, I tried to add minimum\ncomments. As said, this is basically simplified, there are several things\nstill on the pending list:\n\n  1. palette mode is un-supported and un-tested (although re-using the\n     palette code of the base framebuffer is actually very easy now with\n     previous clean-up patches)\n\n  2. fb_pan_display for overlay(s) is un-supported\n\n  3. the base framebuffer can actually be abstracted by \u0027pxafb_layer\u0027 as\n     well, which will help further re-use of the code and keep a better\n     and consistent structure. (This is the reason I named it \u0027pxafb_layer\u0027\n     instead of \u0027pxafb_overlay\u0027 or something alike)\n\nSee Documentation/fb/pxafb.txt for additional usage information.\n\nSigned-off-by: Eric Miao \u003ceric.miao@marvell.com\u003e\nCc: Rodolfo Giometti \u003cgiometti@linux.it\u003e\nSigned-off-by: Eric Miao \u003cycmiao@ycmiao-hp520.(none)\u003e\n"
    },
    {
      "commit": "77e196752bdd76a0c58ab082658d28c6a90fa40e",
      "tree": "935fbe8b897d8770fff05254c6c91dc0a8058984",
      "parents": [
        "5bfb4093be6ac7b6c06c8e6461d85241654acc61"
      ],
      "author": {
        "name": "Eric Miao",
        "email": "eric.miao@marvell.com",
        "time": "Tue Dec 16 11:54:34 2008 +0800"
      },
      "committer": {
        "name": "Eric Miao",
        "email": "eric.miao@marvell.com",
        "time": "Mon Dec 29 17:59:16 2008 +0800"
      },
      "message": "[ARM] pxafb: allow video memory size to be configurable\n\nThe amount of video memory size is decided according to the following\norder:\n\n1. \u003cxres\u003e x \u003cyres\u003e x \u003cbits_per_pixel\u003e by default, which is the backward\n   compatible way\n\n2. size specified in platform data\n\n3. size specified in module parameter \u0027options\u0027 string or specified in\n   kernel boot command line (see updated Documentation/fb/pxafb.txt)\n\nAnd now since the memory is allocated from system memory, the pxafb_mmap\ncan be removed and the default fb_mmap() should be working all right.\n\nAlso, since we now have introduced the \u0027struct pxafb_dma_buff\u0027 for DMA\ndescriptors and palettes, the allocation can be separated cleanly.\n\nNOTE: the LCD DMA actually supports chained transfer (i.e. page-based\ntransfers), to simplify the logic and keep the performance (with less\nTLB misses when accessing from memory mapped user space), the memory\nis allocated by alloc_pages_*() to ensures it\u0027s physical contiguous.\n\nSigned-off-by: Eric Miao \u003ceric.miao@marvell.com\u003e\nSigned-off-by: Eric Miao \u003cycmiao@ycmiao-hp520.(none)\u003e\n"
    },
    {
      "commit": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
      "tree": "0bba044c4ce775e45a88a51686b5d9f90697ea9d",
      "parents": [],
      "author": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "message": "Linux-2.6.12-rc2\n\nInitial git repository build. I\u0027m not bothering with the full history,\neven though we have it. We can create a separate \"historical\" git\narchive of that later if we want to, and in the meantime it\u0027s about\n3.2GB when imported into git - space that would just make the early\ngit days unnecessarily complicated, when we don\u0027t have a lot of good\ninfrastructure for it.\n\nLet it rip!\n"
    }
  ]
}