From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Curtis Malainey <cujomalainey@google.com>
Cc: ALSA development <alsa-devel@alsa-project.org>,
Ross Zwisler <zwisler@google.com>,
Fletcher Woodruff <fletcherw@google.com>,
Liam Girdwood <liam.r.girdwood@intel.com>,
dmaengine@vger.kernel.org,
Pierre-louis Bossart <pierre-louis.bossart@intel.com>
Subject: Re: DW-DMA: Probe failures on broadwell
Date: Thu, 11 Jul 2019 16:12:32 +0300 [thread overview]
Message-ID: <20190711131232.GS9224@smile.fi.intel.com> (raw)
In-Reply-To: <CAOReqxgnUp2tTp__YCjF_QH4166FAA1CE8Yq_VdE9jLW6Q4s3A@mail.gmail.com>
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.
> 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
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Curtis Malainey <cujomalainey@google.com>
Cc: Ross Zwisler <zwisler@google.com>,
Fletcher Woodruff <fletcherw@google.com>,
dmaengine@vger.kernel.org,
ALSA development <alsa-devel@alsa-project.org>,
Pierre-louis Bossart <pierre-louis.bossart@intel.com>,
Liam Girdwood <liam.r.girdwood@intel.com>
Subject: Re: DW-DMA: Probe failures on broadwell
Date: Thu, 11 Jul 2019 16:12:32 +0300 [thread overview]
Message-ID: <20190711131232.GS9224@smile.fi.intel.com> (raw)
In-Reply-To: <CAOReqxgnUp2tTp__YCjF_QH4166FAA1CE8Yq_VdE9jLW6Q4s3A@mail.gmail.com>
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.
> 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
next prev parent reply other threads:[~2019-07-11 13:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAOReqxhxHiJ-4UYC-j4Quuuy5YP9ywohe_JwiLpCxqCvP-7ypg@mail.gmail.com>
2019-07-09 13:14 ` DW-DMA: Probe failures on broadwell Andy Shevchenko
2019-07-09 13:14 ` Andy Shevchenko
2019-07-09 13:29 ` Andy Shevchenko
2019-07-09 13:29 ` Andy Shevchenko
2019-07-09 13:34 ` Andy Shevchenko
2019-07-09 13:34 ` Andy Shevchenko
2019-07-09 13:38 ` Andy Shevchenko
2019-07-09 13:38 ` Andy Shevchenko
2019-07-09 19:27 ` Curtis Malainey
2019-07-09 19:27 ` Curtis Malainey
2019-07-10 16:43 ` Andy Shevchenko
2019-07-10 16:43 ` Andy Shevchenko
2019-07-10 21:24 ` Curtis Malainey
2019-07-10 21:24 ` Curtis Malainey
2019-07-11 13:12 ` Andy Shevchenko [this message]
2019-07-11 13:12 ` Andy Shevchenko
2019-07-11 18:15 ` Curtis Malainey
2019-07-11 18:15 ` Curtis Malainey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190711131232.GS9224@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=cujomalainey@google.com \
--cc=dmaengine@vger.kernel.org \
--cc=fletcherw@google.com \
--cc=liam.r.girdwood@intel.com \
--cc=pierre-louis.bossart@intel.com \
--cc=zwisler@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.