On Tue, Feb 7, 2017 at 10:12 PM, Vinod Koul <vinod.koul@xxxxxxxxx> wrote: > On Tue, Feb 07, 2017 at 02:32:15PM +0530, Anup Patel wrote: >> On Tue, Feb 7, 2017 at 1:57 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: >> > On Tue, Feb 7, 2017 at 12:16 AM, Anup Patel <anup.patel@xxxxxxxxxxxx> wrote: >> >> The DMAENGINE framework assumes that if PQ offload is supported by a >> >> DMA device then all 256 PQ coefficients are supported. This assumption >> >> does not hold anymore because we now have BCM-SBA-RAID offload engine >> >> which supports PQ offload with limited number of PQ coefficients. >> >> >> >> This patch extends async_tx APIs to handle DMA devices with support >> >> for fewer PQ coefficients. >> >> >> >> Signed-off-by: Anup Patel <anup.patel@xxxxxxxxxxxx> >> >> Reviewed-by: Scott Branden <scott.branden@xxxxxxxxxxxx> >> > >> > I don't like this approach. Define an interface for md to query the >> > offload engine once at the beginning of time. We should not be adding >> > any new extensions to async_tx. >> >> Even if we do capability checks in Linux MD, we still need a way >> for DMAENGINE drivers to advertise number of PQ coefficients >> handled by the HW. > > If the question is only for advertising caps, then why not do as done > for dma_get_slave_caps(). you can add dma_get_pq_caps() so that clients (md) > in this case would know the HW capability. We have large number of possible capabilities for DMA slave such as src_addr_widths, dst_addr_widths, directions, max_burst, residue_granularity, and descriptor_resue. The possible capabilities of PQ offload are: 1. Number of PQ sources handled by PQ offload (Represented by "max_pq" member of "struct dma_device") 2. Number of PQ coefficients handled by PQ offload The above two PQ capabilities are good enough for current PQ HW and future PQ HW so we just need a way to specify number of PQ coefficients. Till now all of the PQ HW always supported all 256 PQ coefficients so we never felt the need of capability to specify PQ coefficients. The BCM-SBA-RAID is the only HW (as far as I know) which does not support all 256 PQ coefficients. Currently, DMAENGINE drivers use dma_set_maxpq() to specify number of PQ sources handled by PQ HW and Linux Async Tx uses dma_maxpq() to get number of PQ sources. On similar lines, we added dma_set_maxpqcoef() to specify number of PQ coefficients and Linux Async Tx uses dma_maxpqcoef() to get number of PQ coefficients. If DMAENGINE driver does not specify PQ coefficients then dma_maxpqcoef() will return 256 assuming all PQ coefficients are supported. This approach is backward compatible to existing DMAENGINE APIs and will not break existing DMAENGINE drivers. If we add dma_get_pq_caps() similar to the dma_get_slave_caps() for PQ capabilities then we will have to use this new method for both of the above PQ capabilities and we have to change all DMAENGINE drivers to use new method of specifying PQ capabilities. I think this is too intrusive and bit overkill because its very very unlikely to see anymore additions to PQ capabilities. Regards, Anup -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
