1202  * caches and system write buffers.
1203  *
1204  * Done at varying points during an I/O transfer (including at the
1205  * removal of an I/O mapping).
1206  *
1207  * Due to the support of systems with write buffers which may
1208  * not be able to be turned off, this function *must* used at
1209  * any point in which data consistency might be required.
1210  *
1211  * Generally this means that if a memory object has multiple mappings
1212  * (both for I/O, as described by the handle, and the IU, via, e.g.
1213  * a call to ddi_dma_kvaddrp), and one mapping may have been
1214  * used to modify the memory object, this function must be called
1215  * to ensure that the modification of the memory object is
1216  * complete, as well as possibly to inform other mappings of
1217  * the object that any cached references to the object are
1218  * now stale (and flush or invalidate these stale cache references
1219  * as necessary).
1220  *
1221  * The function ddi_dma_sync() provides the general interface with
1222  * respect to this capability. Generally, ddi_dma_free() (below) may
1223  * be used in preference to ddi_dma_sync() as ddi_dma_free() calls
1224  * ddi_dma_sync().
1225  *
1226  * Returns 0 if all caches that exist and are specified by cache_flags
1227  * are successfully operated on, else -1.
1228  *
1229  * The argument offset specifies an offset into the mapping of the mapped
1230  * object in which to perform the synchronization. It will be silently
1231  * truncated to the granularity of underlying cache line sizes as
1232  * appropriate.
1233  *
1234  * The argument len specifies a length starting from offset in which to
1235  * perform the synchronization. A value of (uint_t) -1 means that the length
1236  * proceeds from offset to the end of the mapping. The length argument
1237  * will silently rounded up to the granularity of underlying cache line
1238  * sizes  as appropriate.
1239  *
1240  * The argument flags specifies what to synchronize (the device's view of
1241  * the object or the cpu's view of the object).
1242  *
1243  * Inquiring minds want to know when ddi_dma_sync should be used:
1244  *
1245  * +    When an object is mapped for dma, assume that an
1246  *      implicit ddi_dma_sync() is done for you.
1247  *
1248  * +    When an object is unmapped (ddi_dma_free()), assume
1249  *      that an implicit ddi_dma_sync() is done for you.
1250  *
1251  * +    At any time between the two times above that the
1252  *      memory object may have been modified by either
1253  *      the DMA device or a processor and you wish that
1254  *      the change be noticed by the master that didn't
1255  *      do the modifying.
1256  *
1257  * Clearly, only the third case above requires the use of ddi_dma_sync.
1258  *
1259  * Inquiring minds also want to know which flag to use:
1260  *
1261  * +    If you *modify* with a cpu the object, you use
1262  *      ddi_dma_sync(...DDI_DMA_SYNC_FORDEV) (you are making sure
1263  *      that the DMA device sees the changes you made).
1264  *
1265  * +    If you are checking, with the processor, an area
1266  *      of the object that the DMA device *may* have modified,
1267  *      you use ddi_dma_sync(....DDI_DMA_SYNC_FORCPU) (you are
1268  *      making sure that the processor(s) will see the changes

1202  * caches and system write buffers.
1203  *
1204  * Done at varying points during an I/O transfer (including at the
1205  * removal of an I/O mapping).
1206  *
1207  * Due to the support of systems with write buffers which may
1208  * not be able to be turned off, this function *must* used at
1209  * any point in which data consistency might be required.
1210  *
1211  * Generally this means that if a memory object has multiple mappings
1212  * (both for I/O, as described by the handle, and the IU, via, e.g.
1213  * a call to ddi_dma_kvaddrp), and one mapping may have been
1214  * used to modify the memory object, this function must be called
1215  * to ensure that the modification of the memory object is
1216  * complete, as well as possibly to inform other mappings of
1217  * the object that any cached references to the object are
1218  * now stale (and flush or invalidate these stale cache references
1219  * as necessary).
1220  *
1221  * The function ddi_dma_sync() provides the general interface with
1222  * respect to this capability. Generally, ddi_dma_unbind_handle()
1223  * (below) may be used in preference to ddi_dma_sync() as it calls
1224  * ddi_dma_sync().
1225  *
1226  * Returns 0 if all caches that exist and are specified by cache_flags
1227  * are successfully operated on, else -1.
1228  *
1229  * The argument offset specifies an offset into the mapping of the mapped
1230  * object in which to perform the synchronization. It will be silently
1231  * truncated to the granularity of underlying cache line sizes as
1232  * appropriate.
1233  *
1234  * The argument len specifies a length starting from offset in which to
1235  * perform the synchronization. A value of (uint_t) -1 means that the length
1236  * proceeds from offset to the end of the mapping. The length argument
1237  * will silently rounded up to the granularity of underlying cache line
1238  * sizes  as appropriate.
1239  *
1240  * The argument flags specifies what to synchronize (the device's view of
1241  * the object or the cpu's view of the object).
1242  *
1243  * Inquiring minds want to know when ddi_dma_sync should be used:
1244  *
1245  * +    When an object is mapped for dma, assume that an
1246  *      implicit ddi_dma_sync() is done for you.
1247  *
1248  * +    When an object is unmapped (ddi_dma_unbind_handle()), assume
1249  *      that an implicit ddi_dma_sync() is done for you.
1250  *
1251  * +    At any time between the two times above that the
1252  *      memory object may have been modified by either
1253  *      the DMA device or a processor and you wish that
1254  *      the change be noticed by the master that didn't
1255  *      do the modifying.
1256  *
1257  * Clearly, only the third case above requires the use of ddi_dma_sync.
1258  *
1259  * Inquiring minds also want to know which flag to use:
1260  *
1261  * +    If you *modify* with a cpu the object, you use
1262  *      ddi_dma_sync(...DDI_DMA_SYNC_FORDEV) (you are making sure
1263  *      that the DMA device sees the changes you made).
1264  *
1265  * +    If you are checking, with the processor, an area
1266  *      of the object that the DMA device *may* have modified,
1267  *      you use ddi_dma_sync(....DDI_DMA_SYNC_FORCPU) (you are
1268  *      making sure that the processor(s) will see the changes