)]}'
{
  "log": [
    {
      "commit": "4137e50494cb3496fbb6ccd27aa7b6d7c9634c1e",
      "tree": "eb824b1d6b716c156d2fa3f50232c6b32e06de13",
      "parents": [
        "b678b91f22debd5f8efa04895652989004761d06"
      ],
      "author": {
        "name": "Stephen Boyd",
        "email": "sboyd@codeaurora.org",
        "time": "Mon Dec 05 10:28:44 2011 -0800"
      },
      "committer": {
        "name": "Chris Ball",
        "email": "cjb@laptop.org",
        "time": "Wed Jan 11 23:58:43 2012 -0500"
      },
      "message": "mmc: core: Fixup delayed work clock gating patch\n\nc31b50e (mmc: core: Use delayed work in clock gating framework,\n2011-11-14) missed a few things during review:\n\n o A useless pr_info()\n\n o milliseconds was written as two words\n\n o The sysfs file had units in its output\n\nFix all three problems.\n\nSigned-off-by: Stephen Boyd \u003csboyd@codeaurora.org\u003e\nCc: Sujit Reddy Thumma \u003csthumma@codeaurora.org\u003e\nSigned-off-by: Chris Ball \u003ccjb@laptop.org\u003e\n"
    },
    {
      "commit": "add710eaa88606de8ba98a014d37178579e6dbaf",
      "tree": "2d719508cabd213d5923cef95fdd3d6c9c40d977",
      "parents": [
        "92df954df3422a7dcf99eea34cf4cb68bb06ea08"
      ],
      "author": {
        "name": "Johan Rudholm",
        "email": "johan.rudholm@stericsson.com",
        "time": "Fri Dec 02 08:51:06 2011 +0100"
      },
      "committer": {
        "name": "Chris Ball",
        "email": "cjb@laptop.org",
        "time": "Wed Jan 11 23:58:43 2012 -0500"
      },
      "message": "mmc: boot partition ro lock support\n\nEnable boot partitions to be read-only locked until next power on via\na sysfs entry. There will be one sysfs entry for each boot partition:\n\n/sys/block/mmcblkXbootY/ro_lock_until_next_power_on\n\nEach boot partition is locked by writing 1 to its file.\n\nSigned-off-by: Johan Rudholm \u003cjohan.rudholm@stericsson.com\u003e\nSigned-off-by: John Beckett \u003cjohn.beckett@stericsson.com\u003e\nSigned-off-by: Chris Ball \u003ccjb@laptop.org\u003e\n"
    },
    {
      "commit": "597dd9d79cfbbb1636d00a7fd0880355d9b20c41",
      "tree": "12911a3daaa38018d7ca1678fb28bb8c72536b68",
      "parents": [
        "c59d44739a8519cb7abdcd7cb7fd88f807dec9fd"
      ],
      "author": {
        "name": "Sujit Reddy Thumma",
        "email": "sthumma@codeaurora.org",
        "time": "Mon Nov 14 13:53:29 2011 +0530"
      },
      "committer": {
        "name": "Chris Ball",
        "email": "cjb@laptop.org",
        "time": "Wed Jan 11 23:58:41 2012 -0500"
      },
      "message": "mmc: core: Use delayed work in clock gating framework\n\nCurrent clock gating framework disables the MCI clock as soon as the\nrequest is completed and enables it when a request arrives. This aggressive\nclock gating framework, when enabled, cause following issues:\n\nWhen there are back-to-back requests from the Queue layer, we unnecessarily\nend up disabling and enabling the clocks between these requests since 8MCLK\nclock cycles is a very short duration compared to the time delay between\nback to back requests reaching the MMC layer. This overhead can effect the\noverall performance depending on how long the clock enable and disable\ncalls take which is platform dependent. For example on some platforms we\ncan have clock control not on the local processor, but on a different\nsubsystem and the time taken to perform the clock enable/disable can add\nsignificant overhead.\n\nAlso if the host controller driver decides to disable the host clock too\nwhen mmc_set_ios function is called with ios.clock\u003d0, it adds additional\ndelay and it is highly possible that the next request had already arrived\nand unnecessarily blocked in enabling the clocks. This is seen frequently\nwhen the processor is executing at high speeds and in multi-core platforms\nthus reduces the overall throughput compared to if clock gating is\ndisabled.\n\nFix this by delaying turning off the clocks by posting request on\ndelayed workqueue. Also cancel the unscheduled pending work, if any,\nwhen there is access to card.\n\nsysfs entry is provided to tune the delay as needed, default\nvalue set to 200ms.\n\nSigned-off-by: Sujit Reddy Thumma \u003csthumma@codeaurora.org\u003e\nAcked-by: Linus Walleij \u003clinus.walleij@linaro.org\u003e\nSigned-off-by: Chris Ball \u003ccjb@laptop.org\u003e\n"
    },
    {
      "commit": "7937e878f91ccc32c09177f44cfdc45183d78605",
      "tree": "ea343c892288164d9ae8e963e25e832a20d70fcc",
      "parents": [
        "101ed47e01516adeffeb4769df77b9207e6ba48a"
      ],
      "author": {
        "name": "Per Forlin",
        "email": "per.forlin@linaro.org",
        "time": "Sun Jul 10 21:21:59 2011 +0200"
      },
      "committer": {
        "name": "Chris Ball",
        "email": "cjb@laptop.org",
        "time": "Thu Jul 21 10:34:52 2011 -0400"
      },
      "message": "mmc: documentation of mmc non-blocking request usage and design.\n\nDocumentation about the background and the design of mmc non-blocking.\nHost driver guidelines to minimize request preparation overhead.\n\nSigned-off-by: Per Forlin \u003cper.forlin@linaro.org\u003e\nAcked-by: Randy Dunlap \u003crdunlap@xenotime.net\u003e\nSigned-off-by: Chris Ball \u003ccjb@laptop.org\u003e\n"
    },
    {
      "commit": "371a689f64b0da140c3bcd3f55305ffa1c3a58ef",
      "tree": "c0dff82d668378d395cb22ce33cd93e6dafef9eb",
      "parents": [
        "1a258db6f396e26c2c00b19c0107a891895d4584"
      ],
      "author": {
        "name": "Andrei Warkentin",
        "email": "andreiw@motorola.com",
        "time": "Mon Apr 11 18:10:25 2011 -0500"
      },
      "committer": {
        "name": "Chris Ball",
        "email": "cjb@laptop.org",
        "time": "Tue May 24 21:01:21 2011 -0400"
      },
      "message": "mmc: MMC boot partitions support.\n\nAllows device MMC boot partitions to be accessed. MMC partitions are\ntreated effectively as separate block devices on the same MMC card.\n\nSigned-off-by: Andrei Warkentin \u003candreiw@motorola.com\u003e\nAcked-by: Arnd Bergmann \u003carnd@arndb.de\u003e\nSigned-off-by: Chris Ball \u003ccjb@laptop.org\u003e\n"
    },
    {
      "commit": "dfe86cba7676d58db8de7e623f5e72f1b0d3ca35",
      "tree": "ed7e6a267c50e0ba2374dc6895515d7a100961a3",
      "parents": [
        "81d73a32d775ae9674ea6edf0b5b721fc3bc57d9"
      ],
      "author": {
        "name": "Adrian Hunter",
        "email": "adrian.hunter@nokia.com",
        "time": "Wed Aug 11 14:17:46 2010 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@linux-foundation.org",
        "time": "Thu Aug 12 08:43:30 2010 -0700"
      },
      "message": "mmc: add erase, secure erase, trim and secure trim operations\n\nSD/MMC cards tend to support an erase operation.  In addition, eMMC v4.4\ncards can support secure erase, trim and secure trim operations that are\nall variants of the basic erase command.\n\nSD/MMC device attributes \"erase_size\" and \"preferred_erase_size\" have been\nadded.\n\n\"erase_size\" is the minimum size, in bytes, of an erase operation.  For\nMMC, \"erase_size\" is the erase group size reported by the card.  Note that\n\"erase_size\" does not apply to trim or secure trim operations where the\nminimum size is always one 512 byte sector.  For SD, \"erase_size\" is 512\nif the card is block-addressed, 0 otherwise.\n\nSD/MMC cards can erase an arbitrarily large area up to and\nincluding the whole card.  When erasing a large area it may\nbe desirable to do it in smaller chunks for three reasons:\n\n    1. A single erase command will make all other I/O on the card\n       wait.  This is not a problem if the whole card is being erased, but\n       erasing one partition will make I/O for another partition on the\n       same card wait for the duration of the erase - which could be a\n       several minutes.\n\n    2. To be able to inform the user of erase progress.\n\n    3. The erase timeout becomes too large to be very useful.\n       Because the erase timeout contains a margin which is multiplied by\n       the size of the erase area, the value can end up being several\n       minutes for large areas.\n\n\"erase_size\" is not the most efficient unit to erase (especially for SD\nwhere it is just one sector), hence \"preferred_erase_size\" provides a good\nchunk size for erasing large areas.\n\nFor MMC, \"preferred_erase_size\" is the high-capacity erase size if a card\nspecifies one, otherwise it is based on the capacity of the card.\n\nFor SD, \"preferred_erase_size\" is the allocation unit size specified by\nthe card.\n\n\"preferred_erase_size\" is in bytes.\n\nSigned-off-by: Adrian Hunter \u003cadrian.hunter@nokia.com\u003e\nAcked-by: Jens Axboe \u003caxboe@kernel.dk\u003e\nCc: Kyungmin Park \u003ckmpark@infradead.org\u003e\nCc: Madhusudhan Chikkature \u003cmadhu.cr@ti.com\u003e\nCc: Christoph Hellwig \u003chch@lst.de\u003e\nCc: Ben Gardiner \u003cbengardiner@nanometrics.ca\u003e\nCc: \u003clinux-mmc@vger.kernel.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n"
    }
  ]
}