* Re: DW-DMA: Probe failures on broadwell
[not found] <CAOReqxhxHiJ-4UYC-j4Quuuy5YP9ywohe_JwiLpCxqCvP-7ypg@mail.gmail.com>
@ 2019-07-09 13:14 ` Andy Shevchenko
2019-07-09 13:29 ` Andy Shevchenko
0 siblings, 1 reply; 9+ messages in thread
From: Andy Shevchenko @ 2019-07-09 13:14 UTC (permalink / raw)
To: Curtis Malainey
Cc: Ross Zwisler, Fletcher Woodruff, dmaengine, alsa-devel,
Pierre-louis Bossart, Liam Girdwood
(I think this is okay to go on public here)
+Cc: Pierre, Liam, DMA Engine ML, ASoC ML
On Mon, Jul 08, 2019 at 01:50:07PM -0700, Curtis Malainey wrote:
> Hello Andy,
>
> I am reaching out to you as you are the main author for
> drivers/dma/dw/core.c and we are seeing a failure in there on some of
> our samus devices. On certain device we are seeing the following
> failure (debugging enabled in this log.)
>
> [ 3.587515] sst-acpi INT3438:00: DW_PARAMS: 0x00000000
AFAIK, when Synopsys DesignWare DMA IP is in use in Intel, we almost always
(yes, I know couple of exceptions), enable auto configuration block. Thus, the
*private* DMA controllers used in Broadwell are actually Intel iDMA 32-bit.
Nowadays the differences can be seen in drivers/dma/dw/idma32.c.
Note, DMA in the driver is used solely for firmware load, simplest workaround
is to disable DMA. Though, personally, for sake of test coverage, I would like
to see how it works in DMA case.
> [ 3.587519] haswell-pcm-audio haswell-pcm-audio: error: DMA device
> register failed
> [ 3.587524] haswell-pcm-audio haswell-pcm-audio: sst_dma_new failed -22
> [ 3.598010] bdw-rt5677 bdw-rt5677: ASoC: failed to init link System PCM
>
> I don't have the datasheets for this component but I am wondering if
> you could help us troubleshoot this bug it would be greatly
> appreciated if possible. I am not sure if we are seeing a hardware
> boot failure or a boot race. I was hoping you could shed some light on
> this and if it is a boot race help us recover from it. I know Intel
> relies on no defers typically but it would be nice to see if we can
> fix this. Below is where I have traced the error source to in core.c.
So, the correct fix is to provide a platform data, like it's done in
drivers/dma/dw/pci.c::idma32_pdata, in the sst-firmware.c::dw_probe(), and call
idma32_dma_probe() with idma32_dma_remove() respectively on removal stage.
(It will require latest patches to be applied, which are material for v5.x)
> dw_params = dma_readl(dw, DW_PARAMS);
> dev_dbg(chip->dev, "DW_PARAMS: 0x%08x\n", dw_params);
>
> autocfg = dw_params >> DW_PARAMS_EN & 1;
> if (!autocfg) {
> err = -EINVAL;
> goto err_pdata;
> }
> Let me know if you have any ideas on how to mitigate this, thanks.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: DW-DMA: Probe failures on broadwell
2019-07-09 13:14 ` DW-DMA: Probe failures on broadwell Andy Shevchenko
@ 2019-07-09 13:29 ` Andy Shevchenko
2019-07-09 13:34 ` Andy Shevchenko
0 siblings, 1 reply; 9+ messages in thread
From: Andy Shevchenko @ 2019-07-09 13:29 UTC (permalink / raw)
To: Curtis Malainey
Cc: Ross Zwisler, Fletcher Woodruff, dmaengine, alsa-devel,
Pierre-louis Bossart, Liam Girdwood
On Tue, Jul 09, 2019 at 04:14:01PM +0300, Andy Shevchenko wrote:
> On Mon, Jul 08, 2019 at 01:50:07PM -0700, Curtis Malainey wrote:
> So, the correct fix is to provide a platform data, like it's done in
> drivers/dma/dw/pci.c::idma32_pdata, in the sst-firmware.c::dw_probe(), and call
> idma32_dma_probe() with idma32_dma_remove() respectively on removal stage.
>
> (It will require latest patches to be applied, which are material for v5.x)
Below completely untested patch to try
--- 8< --- 8< --- 8< ---
From 2bd36a75460613f0a14f0763b766cae8ce20c57d Mon Sep 17 00:00:00 2001
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue, 9 Jul 2019 16:24:35 +0300
Subject: [PATCH 1/1] ASoC: Intel: common: Use proper DMA controller type
It has been reported that Intel Broadwell machines can't use SST
since DMA driver probe failure. The root cause *maybe* in a wrong type
of DMA controller in use.
Use Intel iDMA 32-bit instead of Synopsys DesignWare controller for Intel SST.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
sound/soc/intel/common/sst-firmware.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/sound/soc/intel/common/sst-firmware.c b/sound/soc/intel/common/sst-firmware.c
index d27947aeb079..5da7fb74c845 100644
--- a/sound/soc/intel/common/sst-firmware.c
+++ b/sound/soc/intel/common/sst-firmware.c
@@ -174,6 +174,16 @@ static int block_list_prepare(struct sst_dsp *dsp,
return ret;
}
+static const struct dw_dma_platform_data idma32_pdata = {
+ .nr_channels = 8,
+ .chan_allocation_order = CHAN_ALLOCATION_ASCENDING,
+ .chan_priority = CHAN_PRIORITY_ASCENDING,
+ .block_size = 131071,
+ .nr_masters = 1,
+ .data_width = {4},
+ .multi_block = {1, 1, 1, 1, 1, 1, 1, 1},
+};
+
static struct dw_dma_chip *dw_probe(struct device *dev, struct resource *mem,
int irq)
{
@@ -184,6 +194,7 @@ static struct dw_dma_chip *dw_probe(struct device *dev, struct resource *mem,
if (!chip)
return ERR_PTR(-ENOMEM);
+ chip->pdata = &idma32_pdata;
chip->irq = irq;
chip->regs = devm_ioremap_resource(dev, mem);
if (IS_ERR(chip->regs))
@@ -195,7 +206,7 @@ static struct dw_dma_chip *dw_probe(struct device *dev, struct resource *mem,
chip->dev = dev;
- err = dw_dma_probe(chip);
+ err = idma32_dma_probe(chip);
if (err)
return ERR_PTR(err);
@@ -204,7 +215,7 @@ static struct dw_dma_chip *dw_probe(struct device *dev, struct resource *mem,
static void dw_remove(struct dw_dma_chip *chip)
{
- dw_dma_remove(chip);
+ idma32_dma_remove(chip);
}
static bool dma_chan_filter(struct dma_chan *chan, void *param)
--
2.20.1
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: DW-DMA: Probe failures on broadwell
2019-07-09 13:29 ` Andy Shevchenko
@ 2019-07-09 13:34 ` Andy Shevchenko
2019-07-09 13:38 ` Andy Shevchenko
0 siblings, 1 reply; 9+ messages in thread
From: Andy Shevchenko @ 2019-07-09 13:34 UTC (permalink / raw)
To: Curtis Malainey
Cc: Ross Zwisler, Fletcher Woodruff, dmaengine, alsa-devel,
Pierre-louis Bossart, Liam Girdwood
On Tue, Jul 09, 2019 at 04:29:43PM +0300, Andy Shevchenko wrote:
> On Tue, Jul 09, 2019 at 04:14:01PM +0300, Andy Shevchenko wrote:
> > On Mon, Jul 08, 2019 at 01:50:07PM -0700, Curtis Malainey wrote:
>
> > So, the correct fix is to provide a platform data, like it's done in
> > drivers/dma/dw/pci.c::idma32_pdata, in the sst-firmware.c::dw_probe(), and call
> > idma32_dma_probe() with idma32_dma_remove() respectively on removal stage.
> >
> > (It will require latest patches to be applied, which are material for v5.x)
>
> Below completely untested patch to try
Also, it might require to set proper request lines (currently it uses 0 AFAICS).
Something like it's done in drivers/spi/spi-pxa2xx-pci.c for Intel Merrifield.
>
> --- 8< --- 8< --- 8< ---
>
> From 2bd36a75460613f0a14f0763b766cae8ce20c57d Mon Sep 17 00:00:00 2001
> From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Date: Tue, 9 Jul 2019 16:24:35 +0300
> Subject: [PATCH 1/1] ASoC: Intel: common: Use proper DMA controller type
>
> It has been reported that Intel Broadwell machines can't use SST
> since DMA driver probe failure. The root cause *maybe* in a wrong type
> of DMA controller in use.
>
> Use Intel iDMA 32-bit instead of Synopsys DesignWare controller for Intel SST.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> sound/soc/intel/common/sst-firmware.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/intel/common/sst-firmware.c b/sound/soc/intel/common/sst-firmware.c
> index d27947aeb079..5da7fb74c845 100644
> --- a/sound/soc/intel/common/sst-firmware.c
> +++ b/sound/soc/intel/common/sst-firmware.c
> @@ -174,6 +174,16 @@ static int block_list_prepare(struct sst_dsp *dsp,
> return ret;
> }
>
> +static const struct dw_dma_platform_data idma32_pdata = {
> + .nr_channels = 8,
> + .chan_allocation_order = CHAN_ALLOCATION_ASCENDING,
> + .chan_priority = CHAN_PRIORITY_ASCENDING,
> + .block_size = 131071,
> + .nr_masters = 1,
> + .data_width = {4},
> + .multi_block = {1, 1, 1, 1, 1, 1, 1, 1},
> +};
> +
> static struct dw_dma_chip *dw_probe(struct device *dev, struct resource *mem,
> int irq)
> {
> @@ -184,6 +194,7 @@ static struct dw_dma_chip *dw_probe(struct device *dev, struct resource *mem,
> if (!chip)
> return ERR_PTR(-ENOMEM);
>
> + chip->pdata = &idma32_pdata;
> chip->irq = irq;
> chip->regs = devm_ioremap_resource(dev, mem);
> if (IS_ERR(chip->regs))
> @@ -195,7 +206,7 @@ static struct dw_dma_chip *dw_probe(struct device *dev, struct resource *mem,
>
> chip->dev = dev;
>
> - err = dw_dma_probe(chip);
> + err = idma32_dma_probe(chip);
> if (err)
> return ERR_PTR(err);
>
> @@ -204,7 +215,7 @@ static struct dw_dma_chip *dw_probe(struct device *dev, struct resource *mem,
>
> static void dw_remove(struct dw_dma_chip *chip)
> {
> - dw_dma_remove(chip);
> + idma32_dma_remove(chip);
> }
>
> static bool dma_chan_filter(struct dma_chan *chan, void *param)
> --
> 2.20.1
>
>
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: DW-DMA: Probe failures on broadwell
2019-07-09 13:34 ` Andy Shevchenko
@ 2019-07-09 13:38 ` Andy Shevchenko
2019-07-09 19:27 ` Curtis Malainey
0 siblings, 1 reply; 9+ messages in thread
From: Andy Shevchenko @ 2019-07-09 13:38 UTC (permalink / raw)
To: Curtis Malainey
Cc: Ross Zwisler, Fletcher Woodruff, dmaengine, alsa-devel,
Pierre-louis Bossart, Liam Girdwood
On Tue, Jul 09, 2019 at 04:34:48PM +0300, Andy Shevchenko wrote:
> On Tue, Jul 09, 2019 at 04:29:43PM +0300, Andy Shevchenko wrote:
> > On Tue, Jul 09, 2019 at 04:14:01PM +0300, Andy Shevchenko wrote:
> > > On Mon, Jul 08, 2019 at 01:50:07PM -0700, Curtis Malainey wrote:
> >
> > > So, the correct fix is to provide a platform data, like it's done in
> > > drivers/dma/dw/pci.c::idma32_pdata, in the sst-firmware.c::dw_probe(), and call
> > > idma32_dma_probe() with idma32_dma_remove() respectively on removal stage.
> > >
> > > (It will require latest patches to be applied, which are material for v5.x)
> >
> > Below completely untested patch to try
>
> Also, it might require to set proper request lines (currently it uses 0 AFAICS).
> Something like it's done in drivers/spi/spi-pxa2xx-pci.c for Intel Merrifield.
And SST_DSP_DMA_MAX_BURST seems encoded while it's should be simple number,
like 8 (bytes). Also SPI PXA is an example to look into.
I doubt it has been validated with upstream driver (I know about some internal
drivers, hacked version of dw one, you may find sources somewhere in public).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: DW-DMA: Probe failures on broadwell
2019-07-09 13:38 ` Andy Shevchenko
@ 2019-07-09 19:27 ` Curtis Malainey
2019-07-10 16:43 ` Andy Shevchenko
0 siblings, 1 reply; 9+ messages in thread
From: Curtis Malainey @ 2019-07-09 19:27 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Ross Zwisler, Fletcher Woodruff, dmaengine, ALSA development,
Pierre-louis Bossart, Liam Girdwood
Hi Andy,
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.
Thanks.
On Tue, Jul 9, 2019 at 6:38 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Jul 09, 2019 at 04:34:48PM +0300, Andy Shevchenko wrote:
> > On Tue, Jul 09, 2019 at 04:29:43PM +0300, Andy Shevchenko wrote:
> > > On Tue, Jul 09, 2019 at 04:14:01PM +0300, Andy Shevchenko wrote:
> > > > On Mon, Jul 08, 2019 at 01:50:07PM -0700, Curtis Malainey wrote:
> > >
> > > > So, the correct fix is to provide a platform data, like it's done in
> > > > drivers/dma/dw/pci.c::idma32_pdata, in the sst-firmware.c::dw_probe(), and call
> > > > idma32_dma_probe() with idma32_dma_remove() respectively on removal stage.
> > > >
> > > > (It will require latest patches to be applied, which are material for v5.x)
> > >
> > > Below completely untested patch to try
> >
> > Also, it might require to set proper request lines (currently it uses 0 AFAICS).
> > Something like it's done in drivers/spi/spi-pxa2xx-pci.c for Intel Merrifield.
>
> And SST_DSP_DMA_MAX_BURST seems encoded while it's should be simple number,
> like 8 (bytes). Also SPI PXA is an example to look into.
>
> I doubt it has been validated with upstream driver (I know about some internal
> drivers, hacked version of dw one, you may find sources somewhere in public).
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: DW-DMA: Probe failures on broadwell
2019-07-09 19:27 ` Curtis Malainey
@ 2019-07-10 16:43 ` Andy Shevchenko
2019-07-10 21:24 ` Curtis Malainey
0 siblings, 1 reply; 9+ messages in thread
From: Andy Shevchenko @ 2019-07-10 16:43 UTC (permalink / raw)
To: Curtis Malainey
Cc: Ross Zwisler, Fletcher Woodruff, dmaengine, ALSA development,
Pierre-louis Bossart, Liam Girdwood
On Tue, Jul 09, 2019 at 12:27:49PM -0700, Curtis Malainey wrote:
> Hi Andy,
Please, don't top post in the public mailing lists, community doesn't like it.
> 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.
> On Tue, Jul 9, 2019 at 6:38 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Tue, Jul 09, 2019 at 04:34:48PM +0300, Andy Shevchenko wrote:
> > > On Tue, Jul 09, 2019 at 04:29:43PM +0300, Andy Shevchenko wrote:
> > > > On Tue, Jul 09, 2019 at 04:14:01PM +0300, Andy Shevchenko wrote:
> > > > > On Mon, Jul 08, 2019 at 01:50:07PM -0700, Curtis Malainey wrote:
> > > >
> > > > > So, the correct fix is to provide a platform data, like it's done in
> > > > > drivers/dma/dw/pci.c::idma32_pdata, in the sst-firmware.c::dw_probe(), and call
> > > > > idma32_dma_probe() with idma32_dma_remove() respectively on removal stage.
> > > > >
> > > > > (It will require latest patches to be applied, which are material for v5.x)
> > > >
> > > > Below completely untested patch to try
> > >
> > > Also, it might require to set proper request lines (currently it uses 0 AFAICS).
> > > Something like it's done in drivers/spi/spi-pxa2xx-pci.c for Intel Merrifield.
> >
> > And SST_DSP_DMA_MAX_BURST seems encoded while it's should be simple number,
> > like 8 (bytes). Also SPI PXA is an example to look into.
> >
> > I doubt it has been validated with upstream driver (I know about some internal
> > drivers, hacked version of dw one, you may find sources somewhere in public).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: DW-DMA: Probe failures on broadwell
2019-07-10 16:43 ` Andy Shevchenko
@ 2019-07-10 21:24 ` Curtis Malainey
2019-07-11 13:12 ` Andy Shevchenko
0 siblings, 1 reply; 9+ messages in thread
From: Curtis Malainey @ 2019-07-10 21:24 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Ross Zwisler, Fletcher Woodruff, dmaengine, ALSA development,
Pierre-louis Bossart, Liam Girdwood
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:
> > Hi Andy,
>
> Please, don't top post in the public mailing lists, community doesn't like it.
>
Apologies, forgot you looped in the mailing lists.
> > 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
The bug code line corresponds to
BUG_ON(!list_empty(&dwc->active_list));
in dwc_free_chan_resources.
[ 3.576829] sst-acpi INT3438:00: DesignWare DMA Controller, 8 channels
....
[ 8.595007] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 13.595019] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 18.595025] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 23.595017] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 28.595017] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 33.595018] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 38.595018] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 43.595008] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 48.595011] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 53.595008] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 58.595019] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 63.595018] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 63.835059] udevd[172]: seq 1704
'/devices/pci0000:00/INT3438:00/haswell-pcm-audio' is taking a long
time
[ 63.835078] udevd[172]: seq 1697
'/devices/pci0000:00/INT3438:00/bdw-rt5677' is taking a long time
[ 68.595019] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 73.595007] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 78.595014] sst-acpi INT3438:00: dma_sync_wait: timeout!
[ 78.595062] ------------[ cut here ]------------
[ 78.595065] kernel BUG at
/mnt/host/source/src/third_party/kernel/v4.14/drivers/dma/dw/core.c:1035!
[ 78.595074] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[ 78.656023] gsmi: Log Shutdown Reason 0x03
[ 78.656026] Modules linked in: snd_seq_dummy snd_seq snd_seq_device
bridge stp llc nf_nat_tftp nf_conntrack_tftp nf_nat_ftp
nf_conntrack_ftp esp6 ah6 xfrm6_mode_tunnel xfrm6_mode_transport
xfrm4_mode_tunnel xfrm4_mode_transport lzo_rle lzo_compress
ip6t_REJECT ip6t_ipv6header zram
ipt_MASQUERADE nf_nat_masquerade_ipv4 snd_soc_sst_haswell_pcm(+)
snd_soc_sst_dsp snd_soc_sst_ipc snd_soc_sst_firmware xt_mark uvcvideo
videobuf2_vmalloc snd_hda_codec_hdmi acpi_als snd_soc_rt5677
snd_soc_sst_acpi snd_soc_acpi_intel_match snd_hda_intel snd_soc_acpi
snd_soc_rt5677_spi
snd_soc_rl6231 snd_hda_codec snd_hwdep snd_hda_core fuse
iio_trig_sysfs cros_ec_sensors_ring cros_ec_sensors
cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf
industrialio iwlmvm iwl7000_mac80211 r8152 mii iwlwifi cfg80211 btusb
btrtl
[ 78.656072] btbcm btintel bluetooth ecdh_generic joydev
[ 78.656079] CPU: 2 PID: 2006 Comm: udevd Not tainted 4.14.132 #38
[ 78.656081] Hardware name: GOOGLE Samus, BIOS
Google_Samus.6300.276.0 08/17/2016
[ 78.656084] task: ffff9a4c86dde580 task.stack: ffffbae9817e8000
[ 78.656089] RIP: 0010:dwc_free_chan_resources+0x140/0x151
[ 78.656091] RSP: 0018:ffffbae9817eb8f0 EFLAGS: 00010293
[ 78.656094] RAX: ffff9a4c827c60b8 RBX: ffff9a4c827c6028 RCX: ffff9a48b881f020
[ 78.656095] RDX: 0000000000000007 RSI: 0000000000000006 RDI: ffff9a4cbed15418
[ 78.656097] RBP: ffffbae9817eb920 R08: fffffffffffffcf6 R09: ffffffff8c8d2400
[ 78.656099] R10: 0000000000000007 R11: ffffffff8c8c2130 R12: ffff9a4c8a6b8c00
[ 78.656101] R13: 000000000003f8e0 R14: ffff9a4c8520bc28 R15: ffff9a4c86c49220
[ 78.656103] FS: 00007c53e45ed040(0000) GS:ffff9a4cbed00000(0000)
knlGS:0000000000000000
[ 78.656106] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 78.656108] CR2: 00003deb215fc004 CR3: 00000004451dc002 CR4: 00000000003606e0
[ 78.656109] Call Trace:
[ 78.656115] dma_chan_put+0x83/0xb1
[ 78.656118] dma_release_channel+0x33/0x6b
[ 78.656123] sst_fw_new+0x13f/0x274 [snd_soc_sst_firmware]
[ 78.656135] sst_hsw_module_load+0x108/0x167 [snd_soc_sst_haswell_pcm]
[ 78.656141] sst_hsw_dsp_init+0x1b9/0x429 [snd_soc_sst_haswell_pcm]
[ 78.656147] hsw_pcm_dev_probe+0x48/0xa7 [snd_soc_sst_haswell_pcm]
[ 78.656152] platform_drv_probe+0x3f/0x8b
[ 78.656156] driver_probe_device+0x272/0x2bf
[ 78.656159] __driver_attach+0x7a/0x9e
[ 78.656162] ? driver_attach+0x1f/0x1f
[ 78.656165] bus_for_each_dev+0x8e/0xc9
[ 78.656168] bus_add_driver+0x133/0x205
[ 78.656175] ?
trace_event_define_fields_hsw_device_config_req+0xc0/0xc0
[snd_soc_sst_haswell_pcm]
[ 78.656178] driver_register+0x8e/0xcd
[ 78.656184] ?
trace_event_define_fields_hsw_device_config_req+0xc0/0xc0
[snd_soc_sst_haswell_pcm]
[ 78.656187] do_one_initcall+0x113/0x206
[ 78.656191] ? __wake_up_common_lock+0x87/0xe5
[ 78.656194] ? __free_one_page+0x30/0x1eb
[ 78.656198] ? _raw_spin_unlock+0x1f/0x52
[ 78.656201] ? free_pcppages_bulk+0x222/0x245
[ 78.656204] ? kmem_cache_alloc_trace+0x55/0x1d1
[ 78.656208] do_init_module+0x61/0x1bc
[ 78.656211] load_module+0x252a/0x28c8
[ 78.656215] ? kernel_read_file+0x133/0x1ab
[ 78.656218] ? kernel_read_file_from_fd+0x46/0x71
[ 78.656222] SyS_finit_module+0xb6/0xda
[ 78.656226] do_syscall_64+0x6b/0x7f
[ 78.656229] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 78.656232] RIP: 0033:0x7c53e3d7c199
[ 78.656234] RSP: 002b:00007ffef05b2ec8 EFLAGS: 00000246 ORIG_RAX:
0000000000000139
[ 78.656237] RAX: ffffffffffffffda RBX: 00005adda7225fb0 RCX: 00007c53e3d7c199
[ 78.656239] RDX: 0000000000000000 RSI: 00007c53e4628b85 RDI: 0000000000000011
[ 78.656242] RBP: 00007ffef05b2f10 R08: 0000000000000000 R09: 00005adda720c5c0
[ 78.656244] R10: 0000000000000011 R11: 0000000000000246 R12: 0000000000000000
[ 78.656246] R13: 00005adda72140c0 R14: 00007c53e4628b85 R15: 0000000000000000
[ 78.656249] Code: 41 20 86 81 01 00 00 75 08 4c 89 f7 e8 35 f4 ff
ff 65 48 8b 04 25 28 00 00 00 48 3b 45 e0 75 17 48 83 c4 18 5b 41 5e
41 5f 5d c3 <0f> 0b eb fe 0f 0b eb fe 0f 0b eb fe e8 96 76 c7 ff 0f 1f
44 00
[ 78.656285] RIP: dwc_free_chan_resources+0x140/0x151 RSP: ffffbae9817eb8f0
[ 78.656332] ---[ end trace 7557efe63d2179e8 ]---
[ 78.659486] Kernel panic - not syncing: Fatal exception
[ 78.659499] Kernel Offset: 0xa200000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 78.659604] gsmi: Log Shutdown Reason 0x02
[ 78.662188] ACPI MEMORY or I/O RESET_REG.
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.
[ 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
> > On Tue, Jul 9, 2019 at 6:38 AM Andy Shevchenko
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: DW-DMA: Probe failures on broadwell
2019-07-10 21:24 ` Curtis Malainey
@ 2019-07-11 13:12 ` Andy Shevchenko
2019-07-11 18:15 ` Curtis Malainey
0 siblings, 1 reply; 9+ messages in thread
From: Andy Shevchenko @ 2019-07-11 13:12 UTC (permalink / raw)
To: Curtis Malainey
Cc: Ross Zwisler, Fletcher Woodruff, dmaengine, ALSA development,
Pierre-louis Bossart, Liam Girdwood
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: DW-DMA: Probe failures on broadwell
2019-07-11 13:12 ` Andy Shevchenko
@ 2019-07-11 18:15 ` Curtis Malainey
0 siblings, 0 replies; 9+ messages in thread
From: Curtis Malainey @ 2019-07-11 18:15 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Ross Zwisler, Fletcher Woodruff, dmaengine, ALSA development,
Pierre-louis Bossart, Liam Girdwood
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
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-07-11 18:15 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[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:29 ` Andy Shevchenko
2019-07-09 13:34 ` Andy Shevchenko
2019-07-09 13:38 ` Andy Shevchenko
2019-07-09 19:27 ` Curtis Malainey
2019-07-10 16:43 ` Andy Shevchenko
2019-07-10 21:24 ` Curtis Malainey
2019-07-11 13:12 ` Andy Shevchenko
2019-07-11 18:15 ` Curtis Malainey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).