On Fri, Aug 02, 2024 at 10:50:46AM +0300, Serge Semin wrote: > Currently the src_addr_width and dst_addr_width fields of the > dma_slave_config structure are mapped to the CTLx.SRC_TR_WIDTH and > CTLx.DST_TR_WIDTH fields of the peripheral bus side in order to have the > properly aligned data passed to the target device. It's done just by > converting the passed peripheral bus width to the encoded value using the > __ffs() function. This implementation has several problematic sides: > > 1. __ffs() is undefined if no bit exist in the passed value. Thus if the > specified addr-width is DMA_SLAVE_BUSWIDTH_UNDEFINED, __ffs() may return > unexpected value depending on the platform-specific implementation. > > 2. DW AHB DMA-engine permits having the power-of-2 transfer width limited > by the DMAH_Mk_HDATA_WIDTH IP-core synthesize parameter. Specifying > bus-width out of that constraints scope will definitely cause unexpected > result since the destination reg will be only partly touched than the > client driver implied. > > Let's fix all of that by adding the peripheral bus width verification > method and calling it in dwc_config() which is supposed to be executed > before preparing any transfer. The new method will make sure that the > passed source or destination address width is valid and if undefined then > the driver will just fallback to the 1-byte width transfer. This patch broke Intel Merrifield iDMA32 + SPI PXA2xx configuration to me. Since it's first in the series and most likely the rest is dependent and we are almost at the release date I propose to roll back and start again after v6.12-rc1 will be out. Vinod, can we revert the entire series, please? -- With Best Regards, Andy Shevchenko
