On Thu, Jul 11, 2019 at 6:12 AM Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > On Wed, Jul 10, 2019 at 02:24:48PM -0700, Curtis Malainey wrote: > > On Wed, Jul 10, 2019 at 9:43 AM Andy Shevchenko > > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > > On Tue, Jul 09, 2019 at 12:27:49PM -0700, Curtis Malainey wrote: > > > > > Thanks for the information, we are running a 4.14 kernel so we don't > > > > have the idma32 driver, I will see if I can backport it and report > > > > back if the fix works. > > > > > > Driver is supporting iDMA 32-bit in v4.14 AFAICS. > > > The missed stuff is a split and some fixes here and there. > > > Here is the list of patches I have in a range v4.14..v5.2 > > > (I deliberately dropped the insignificant ones) > > > > > > 934891b0a16c dmaengine: dw: Don't pollute CTL_LO on iDMA 32-bit > > > 91f0ff883e9a dmaengine: dw: Reset DRAIN bit when resume the channel > > > 69da8be90d5e dmaengine: dw: Split DW and iDMA 32-bit operations > > > 87fe9ae84d7b dmaengine: dw: Add missed multi-block support for iDMA 32-bit > > > ffe843b18211 dmaengine: dw: Fix FIFO size for Intel Merrifield > > > 7b0c03ecc42f dmaengine: dw-dmac: implement dma protection control setting > > > > > > For me sounds like fairly easy to backport. > > > > > I got the code integrated, and ran some tests. The test device > > regularly hits a BUG_ON in the dw/core.c, debug is turned on in dw > > core > > I see. We need ASoC guys to shed a light here. I don't know that part at all. > > Only last suggestion I have is to try remove multi-block setting from the > platform data (it will be emulated in software if needed). But I don't believe > the DMA for audio has no such feature enabled. > In theory, (assuming I understand this correctly) it seems the DMA driver is failing to probe (from what appears to possibly be a hardware issue) but we should fallback to a non-DMA/direct method to load the firmware to keep the system alive. Also I am still seeing the same dma_sync_wait: timeout! failures with multi-block commented out. > > We have only been able to consistently reproduce the DMA boot issue on > > our original code consistently on 1 device and sporadically on another > > handful of devices. > > When the device did finally booted after 2-3 device crashes the device > > failed to load the DSP. > > Yeah, it has something to do with this firmware loader code... > > > [ 3.709573] sst-acpi INT3438:00: DesignWare DMA Controller, 8 channels > > [ 3.959027] haswell-pcm-audio haswell-pcm-audio: error: audio DSP > > boot timeout IPCD 0x0 IPCX 0x0 > > [ 3.970336] bdw-rt5677 bdw-rt5677: ASoC: failed to init link System PCM > > -- > With Best Regards, > Andy Shevchenko > >
