)]}'
{
  "commit": "e63d79d1ffcd2201a2dbff1d7a1184b8f3ec74cf",
  "tree": "daadad358df3eb989fc950a6e8e3935cf4ffa0b0",
  "parents": [
    "fb6dda8349ea0a6a68a743b6cb636261f4489983"
  ],
  "author": {
    "name": "Gustavo Pimentel",
    "email": "Gustavo.Pimentel@synopsys.com",
    "time": "Tue Jun 04 15:29:22 2019 +0200"
  },
  "committer": {
    "name": "Vinod Koul",
    "email": "vkoul@kernel.org",
    "time": "Mon Jun 10 13:10:39 2019 +0530"
  },
  "message": "dmaengine: Add Synopsys eDMA IP core driver\n\nAdd Synopsys PCIe Endpoint eDMA IP core driver to kernel.\n\nThis IP is generally distributed with Synopsys PCIe Endpoint IP (depends\nof the use and licensing agreement).\n\nThis core driver, initializes and configures the eDMA IP using vma-helpers\nfunctions and dma-engine subsystem.\n\nThis driver can be compile as built-in or external module in kernel.\n\nTo enable this driver just select DW_EDMA option in kernel configuration,\nhowever it requires and selects automatically DMA_ENGINE and\nDMA_VIRTUAL_CHANNELS option too.\n\nIn order to transfer data from point A to B as fast as possible this IP\nrequires a dedicated memory space containing linked list of elements.\n\nAll elements of this linked list are continuous and each one describes a\ndata transfer (source and destination addresses, length and a control\nvariable).\n\nFor the sake of simplicity, lets assume a memory space for channel write\n0 which allows about 42 elements.\n\n+---------+\n| Desc #0 |-+\n+---------+ |\n            V\n       +----------+\n       | Chunk #0 |-+\n       |  CB \u003d 1  | |  +----------+  +-----+  +-----------+  +-----+\n       +----------+ +-\u003e| Burst #0 |-\u003e| ... |-\u003e| Burst #41 |-\u003e| llp |\n            |          +----------+  +-----+  +-----------+  +-----+\n            V\n       +----------+\n       | Chunk #1 |-+\n       |  CB \u003d 0  | |  +-----------+  +-----+  +-----------+  +-----+\n       +----------+ +-\u003e| Burst #42 |-\u003e| ... |-\u003e| Burst #83 |-\u003e| llp |\n            |          +-----------+  +-----+  +-----------+  +-----+\n            V\n       +----------+\n       | Chunk #2 |-+\n       |  CB \u003d 1  | |  +-----------+  +-----+  +------------+  +-----+\n       +----------+ +-\u003e| Burst #84 |-\u003e| ... |-\u003e| Burst #125 |-\u003e| llp |\n            |          +-----------+  +-----+  +------------+  +-----+\n            V\n       +----------+\n       | Chunk #3 |-+\n       |  CB \u003d 0  | |  +------------+  +-----+  +------------+  +-----+\n       +----------+ +-\u003e| Burst #126 |-\u003e| ... |-\u003e| Burst #129 |-\u003e| llp |\n                       +------------+  +-----+  +------------+  +-----+\n\nLegend:\n - Linked list, also know as Chunk\n - Linked list element*, also know as Burst *CB*, also know as Change Bit,\nit\u0027s a control bit (and typically is toggled) that allows to easily\nidentify and differentiate between the current linked list and the\nprevious or the next one.\n - LLP, is a special element that indicates the end of the linked list\nelement stream also informs that the next CB should be toggle\n\nOn every last Burst of the Chunk (Burst #41, Burst #83, Burst #125 or\neven Burst #129) is set some flags on their control variable (RIE and\nLIE bits) that will trigger the send of \"done\" interruption.\n\nOn the interruptions callback, is decided whether to recycle the linked\nlist memory space by writing a new set of Bursts elements (if still\nexists Chunks to transfer) or is considered completed (if there is no\nChunks available to transfer).\n\nOn scatter-gather transfer mode, the client will submit a scatter-gather\nlist of n (on this case 130) elements, that will be divide in multiple\nChunks, each Chunk will have (on this case 42) a limited number of\nBursts and after transferring all Bursts, an interrupt will be\ntriggered, which will allow to recycle the all linked list dedicated\nmemory again with the new information relative to the next Chunk and\nrespective Burst associated and repeat the whole cycle again.\n\nOn cyclic transfer mode, the client will submit a buffer pointer, length\nof it and number of repetitions, in this case each burst will correspond\ndirectly to each repetition.\n\nEach Burst can describes a data transfer from point A(source) to point\nB(destination) with a length that can be from 1 byte up to 4 GB. Since\ndedicated the memory space where the linked list will reside is limited,\nthe whole n burst elements will be organized in several Chunks, that\nwill be used later to recycle the dedicated memory space to initiate a\nnew sequence of data transfers.\n\nThe whole transfer is considered has completed when it was transferred\nall bursts.\n\nCurrently this IP has a set well-known register map, which includes\nsupport for legacy and unroll modes. Legacy mode is version of this\nregister map that has multiplexer register that allows to switch\nregisters between all write and read channels and the unroll modes\nrepeats all write and read channels registers with an offset between\nthem. This register map is called v0.\n\nThe IP team is creating a new register map more suitable to the latest\nPCIe features, that very likely will change the map register, which this\nversion will be called v1. As soon as this new version is released by\nthe IP team the support for this version in be included on this driver.\n\nAccording to the logic, patches 1, 2 and 3 should be squashed into 1\nunique patch, but for the sake of simplicity of review, it was divided\nin this 3 patches files.\n\nSigned-off-by: Gustavo Pimentel \u003cgustavo.pimentel@synopsys.com\u003e\nCc: Vinod Koul \u003cvkoul@kernel.org\u003e\nCc: Dan Williams \u003cdan.j.williams@intel.com\u003e\nCc: Andy Shevchenko \u003candriy.shevchenko@linux.intel.com\u003e\nCc: Russell King \u003crmk+kernel@armlinux.org.uk\u003e\nCc: Joao Pinto \u003cjpinto@synopsys.com\u003e\nSigned-off-by: Vinod Koul \u003cvkoul@kernel.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "eaf78f4e07ce70c9a1a589d647db14f555aaa54f",
      "old_mode": 33188,
      "old_path": "drivers/dma/Kconfig",
      "new_id": "76859aa2688cbee1f5a96834905596ce0ade2835",
      "new_mode": 33188,
      "new_path": "drivers/dma/Kconfig"
    },
    {
      "type": "modify",
      "old_id": "6126e1c3a875684eca1cd6f91e95f784b5db51e1",
      "old_mode": 33188,
      "old_path": "drivers/dma/Makefile",
      "new_id": "5bddf6f8790f9a2b2d70e3f97a15abb7d1dea4f3",
      "new_mode": 33188,
      "new_path": "drivers/dma/Makefile"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "3016bed635893ff0ed03dbd61518064abed358df",
      "new_mode": 33188,
      "new_path": "drivers/dma/dw-edma/Kconfig"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "322401089891de55de760b493321b0ab2db0d2af",
      "new_mode": 33188,
      "new_path": "drivers/dma/dw-edma/Makefile"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "c9d032f49dc3f8f79e3a3dd285f6e12c6b6f7b3e",
      "new_mode": 33188,
      "new_path": "drivers/dma/dw-edma/dw-edma-core.c"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "b6cc90cbc9dc244734fd763a9ed34829419c994a",
      "new_mode": 33188,
      "new_path": "drivers/dma/dw-edma/dw-edma-core.h"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "cab6e18773dadd2149f6310e0c87316137419d24",
      "new_mode": 33188,
      "new_path": "include/linux/dma/edma.h"
    }
  ]
}
