From: Paul Pawlowski <mrarmdev@gmail.com>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: linux-mm@kvack.org
Subject: Re: Do DMA mappings get cleared on suspend?
Date: Tue, 20 Aug 2019 17:58:29 +0200 [thread overview]
Message-ID: <CAKSqxP8rb9e3-VcNnf=nXt5REqs_0NBCKFH4pBgwRx==aM7cDw@mail.gmail.com> (raw)
In-Reply-To: <CAKSqxP-igwDqk0sT5O8T0y9rNVSrakYaNbkLAiof5-NzTtNCbA@mail.gmail.com>
Hello,
I have done some more debugging now and it turned out that the bug was
indeed in my driver, and that the dma_alloc_coherent()+memcpy()
somehow magically caused the issue not to happen, however it had
nothing to do with the issue.
Sorry for the inconvenience.
Thank you,
Paul Pawlowski
On Tue, Aug 20, 2019 at 1:58 PM Paul Pawlowski <mrarmdev@gmail.com> wrote:
>
> Hello,
> Thank you for your reply and sorry for the confusion.
>
> I mean the IOMMU mapping state, not anything regarding the device state.
>
> If I create a DMA mapping before the suspend (as in,
> dma_alloc_coherent was called before suspend), and then try to pass
> the DMA mapping address to the device after the system is resumed, the
> device gives me an error back.
> However, if the DMA mapping is created after the suspend is completed,
> the device accepts it and processes the data.
>
> In my particular case, the device stores state into a DMA buffer for
> suspend. I attempted to persist the DMA buffer mapping through the
> suspend however this caused a device error when I tried to tell the
> device to restore the state on resume.
> If I copied the data from the old buffer into a newly allocated one
> (using dma_alloc_coherent), and then tried to use that address, the
> device successfully resumed.
> The buffer is obviously not freed, at least not in my driver code.
>
> I assume this is not expected and I had to end up with a bug somewhere
> in my driver code?
>
> Thank you,
> Paul Pawlowski
>
> On Tue, Aug 20, 2019 at 12:37 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> >
> > On Mon, 2019-08-19 at 21:49 +0200, Paul Pawlowski wrote:
> > > Hello,
> > > Do DMA mappings get cleared when the device is suspended to RAM? A
> > > device I'm writing a driver for requires the DMA addresses not to
> > > change after a resume and trying to use DMA memory allocated before
> > > the suspend causes a device error. Is there a way to persist the
> > > mappings through a suspend?
> >
> > What are you actually asking? The state of the IOMMU mappings should
> > be saved and restored on suspend/resume. However, whether mappings
> > that are inside actual PCI devices are saved and restored depends on
> > the actual device. In general we don't expect them to remember in-
> > flight I/O which is why I/O is quiesced before devices are suspended,
> > so the device should be inactive and any I/O in the upper layers will
> > be mapped on resume. The DMA addresses of the mailboxes are usually
> > saved and restored, but how is up to the driver.
> >
> > James
> >
prev parent reply other threads:[~2019-08-20 15:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-19 19:49 Paul Pawlowski
2019-08-20 10:37 ` James Bottomley
2019-08-20 11:58 ` Paul Pawlowski
2019-08-20 15:58 ` Paul Pawlowski [this message]
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='CAKSqxP8rb9e3-VcNnf=nXt5REqs_0NBCKFH4pBgwRx==aM7cDw@mail.gmail.com' \
--to=mrarmdev@gmail.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=linux-mm@kvack.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox