From: Trent Piepho <tpiepho@impinj.com>
To: "festevam@gmail.com" <festevam@gmail.com>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stefan@agner.ch" <stefan@agner.ch>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"linux-imx@nxp.com" <linux-imx@nxp.com>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"fabio.estevam@nxp.com" <fabio.estevam@nxp.com>,
"shawnguo@kernel.org" <shawnguo@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/2] ARM: dts: imx7: add DMA properties for ECSPI
Date: Wed, 13 Feb 2019 00:07:17 +0000 [thread overview]
Message-ID: <1550016436.3075.127.camel@impinj.com> (raw)
In-Reply-To: <CAOMZO5Ccovx2hMU0SmPm9ToZDNXOdLWkoQ8QT7EOhLocL7GAEQ@mail.gmail.com>
On Tue, 2019-02-12 at 17:37 -0200, Fabio Estevam wrote:
> On Mon, Feb 11, 2019 at 8:22 PM Trent Piepho <tpiepho@impinj.com>
> wrote:
>
> > > Just trying to understand if the SDMA firmware plays a role on
> > > this
> > > behavior or not.
> >
> > The ROM firmware only.
>
> Does the problem also happen if the external SDMA firmware is used?
> Just trying to narrow it down.
Tried SDMA firmware 4.2. Still broken. No apparent change.
Get 4 cycle pause after each byte.
And crash while/after using DMA. Clearly some sort of memory
corruption going on. Fortunately, it's very reliable that using DMA
almost immediately causes a problem and this is easy to reproduce. I
think that indicates it's either clobbers a lot of RAM, or consistently
manages to hit a very important location for kernel memory allocators.
I've got an idea of where that might be happening that I'm looking
into.
I think it's reasonable to add the dma attributes, but put a check in
the spi-imx driver to disable DMA on imx7d at least.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Trent Piepho <tpiepho@impinj.com>
To: "festevam@gmail.com" <festevam@gmail.com>
Cc: "linux-imx@nxp.com" <linux-imx@nxp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"stefan@agner.ch" <stefan@agner.ch>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"fabio.estevam@nxp.com" <fabio.estevam@nxp.com>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"shawnguo@kernel.org" <shawnguo@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>
Subject: Re: [PATCH 2/2] ARM: dts: imx7: add DMA properties for ECSPI
Date: Wed, 13 Feb 2019 00:07:17 +0000 [thread overview]
Message-ID: <1550016436.3075.127.camel@impinj.com> (raw)
In-Reply-To: <CAOMZO5Ccovx2hMU0SmPm9ToZDNXOdLWkoQ8QT7EOhLocL7GAEQ@mail.gmail.com>
On Tue, 2019-02-12 at 17:37 -0200, Fabio Estevam wrote:
> On Mon, Feb 11, 2019 at 8:22 PM Trent Piepho <tpiepho@impinj.com>
> wrote:
>
> > > Just trying to understand if the SDMA firmware plays a role on
> > > this
> > > behavior or not.
> >
> > The ROM firmware only.
>
> Does the problem also happen if the external SDMA firmware is used?
> Just trying to narrow it down.
Tried SDMA firmware 4.2. Still broken. No apparent change.
Get 4 cycle pause after each byte.
And crash while/after using DMA. Clearly some sort of memory
corruption going on. Fortunately, it's very reliable that using DMA
almost immediately causes a problem and this is easy to reproduce. I
think that indicates it's either clobbers a lot of RAM, or consistently
manages to hit a very important location for kernel memory allocators.
I've got an idea of where that might be happening that I'm looking
into.
I think it's reasonable to add the dma attributes, but put a check in
the spi-imx driver to disable DMA on imx7d at least.
next prev parent reply other threads:[~2019-02-13 0:07 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-07 13:22 [PATCH 1/2] ARM: dts: imx6ul: add DMA properties for ECSPI Stefan Agner
2019-01-07 13:22 ` Stefan Agner
2019-01-07 13:22 ` [PATCH 2/2] ARM: dts: imx7: " Stefan Agner
2019-01-07 13:22 ` Stefan Agner
2019-02-07 21:00 ` Trent Piepho
2019-02-07 21:00 ` Trent Piepho
2019-02-11 1:23 ` Shawn Guo
2019-02-11 1:23 ` Shawn Guo
2019-02-11 20:14 ` Trent Piepho
2019-02-11 20:14 ` Trent Piepho
2019-02-11 21:34 ` Fabio Estevam
2019-02-11 21:34 ` Fabio Estevam
2019-02-11 22:22 ` Trent Piepho
2019-02-11 22:22 ` Trent Piepho
2019-02-12 19:37 ` Fabio Estevam
2019-02-12 19:37 ` Fabio Estevam
2019-02-13 0:07 ` Trent Piepho [this message]
2019-02-13 0:07 ` Trent Piepho
2019-02-13 0:57 ` Fabio Estevam
2019-02-13 0:57 ` Fabio Estevam
2019-02-13 1:10 ` Trent Piepho
2019-02-13 1:10 ` Trent Piepho
2019-02-12 19:20 ` Stefan Agner
2019-02-12 19:20 ` Stefan Agner
2019-02-13 11:56 ` Mark Brown
2019-02-13 11:56 ` Mark Brown
2019-01-13 3:34 ` [PATCH 1/2] ARM: dts: imx6ul: " Shawn Guo
2019-01-13 3:34 ` Shawn Guo
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=1550016436.3075.127.camel@impinj.com \
--to=tpiepho@impinj.com \
--cc=devicetree@vger.kernel.org \
--cc=fabio.estevam@nxp.com \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=stefan@agner.ch \
/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.