Am 11.08.2016 um 13:58 schrieb Markus Heiser <markus.hei...@darmarit.de>: >> +.. note:: Until this stage, the buffer-exporter has the option to choose >> not to >> + actually allocate the backing storage for this buffer, but wait for the >> + first buffer-user to request use of buffer for allocation. > > Use newlines ... which are markups in reST ;) > > .. note:: > > Until this stage, the buffer-exporter has the option to choose not to > actually allocate the backing storage for this buffer, but wait for the > first buffer-user to request use of buffer for allocation. >
Sorry, my f... apple mail drops leading whitespaces ... |.. note:: | | Until this stage, the buffer-exporter has the option to choose not to | actually allocate the backing storage for this buffer, but wait for the >> +Kernel cpu access to a dma-buf buffer object >> +============================================ >> + >> +The motivation to allow cpu access from the kernel to a dma-buf object from >> the >> +importers side are: >> + >> +* fallback operations, e.g. if the devices is connected to a usb bus and the >> + kernel needs to shuffle the data around first before sending it away. >> +* full transparency for existing users on the importer side, i.e. userspace >> + should not notice the difference between a normal object from that >> subsystem >> + and an imported one backed by a dma-buf. This is really important for drm >> + opengl drivers that expect to still use all the existing upload/download >> + paths. > > I is recommended to separate blocks (in this case the list item blocks) with > a newline. E.g. > > * first lorem > ipsum > > * second lorem > ipsum > > If you have only one-liners, it is OK to write > > * first > * second > same here, leading whitespace are droped by the mail client. |* first lorem | ipsum | |* second lorem | ipsum Sorry for disorientation. For a snatch I forgot, that that Apple & MS have a mistaken idea of "plain text" ;) -- Markus --
