On Thu, Jul 11, 2019 at 6:12 AM Andy Shevchenko andriy.shevchenko@linux.intel.com 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@linux.intel.com 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