Russell, On 11/12/2018 15.13, Russell King - ARM Linux wrote: > > We're nearing the merge window, and this is a regression that is yet > to be solved. It causes a kernel warning with backtrace, so it's > very annoying. > > The error is: > > omap-dma-engine 4a056000.dma-controller: DMA-API: mapping sg segment longer than device claims to support [len=69632] [max=65536] > > which indicates that we have a SG segment length that exceeds thte > published maximum segment size for a device - in this case the > DMA engine device. The maximum segment size for the DMA engine comes > from the default per-device setting, in linux/dma-mapping.h, which is > 64K. > > However, omap_hsmmc sets: > > mmc->max_blk_size = 512; /* Block Length at max can be 1024 */ > mmc->max_blk_count = 0xFFFF; /* No. of Blocks is 16 bits */ > mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count; > mmc->max_seg_size = mmc->max_req_size; > > which ends up telling the block layer that we support a maximum segment > size of 65535*512, so of course it _will_ pass SG lists where a segment > is longer than 64K. > > The problem here is that the HSMMC driver doesn't take account of the > DMA engine device's capabilities. > > We have something of an odd situation in that the omap-dma device's > maximum SG size depends on the "address width" - it's 64K transfers > of whatever unit "address width" is, so the current implementation of > per-device parameters doesn't exactly work. That means the default > 64K limit at the device-level is reasonable. > > The only thing I can think of doing is adding into omap_hsmmc: > > mmc->max_seg_size = min(mmc->max_req_size, > min(dma_get_max_seg_size(host->rx_chan->device->dev), > dma_get_max_seg_size(host->tx_chan->device->dev))); > > to limit the maximum segment size to that of the device _and_ dma > engine's capabilities. Make sense. > Doing this solves the problem for me. > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
