linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
To: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>,
	Kishon Vijay Abraham I <kishon@ti.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	linux-pci <linux-pci@vger.kernel.org>
Subject: RE: PCIe EPF
Date: Tue, 31 Mar 2020 07:10:52 +0000	[thread overview]
Message-ID: <TYAPR01MB45446ABD97A846045FD2B896D8C80@TYAPR01MB4544.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <CA+V-a8t6WuBsMaW4WTCDHihUFv69WpwqJgOYH+rL7ndJ2NhrDQ@mail.gmail.com>

Hi Prabhakar-san,

> From: Lad, Prabhakar, Sent: Monday, March 30, 2020 10:47 PM
<snip>
> > > Agreed. But we don't flush in SW when -d option is not specified I am
> > > assuming  when we us
> > > -d dma engine takes care of flushing it.
> >
> > The -d option switch doesn't change anything on the SW that runs on the host
> > side (misc/pci-endpoint-test.c). That only tells the EP to use DMA.
> >
> > When you use streaming APIs, dma_map_single(), dmap_unmap_single() takes care
> > of flushing or invalidating memory based on the platform. (Platforms which have
> > coherent memory will have dma-coherent property,
> > dma_map_single()/dmap_unmap_single() will not do flush or invalidate.
> >
> My bad, I thought dma_sync*() calls did it.
> 
> Shimoda-san do you see any platform restrictions while using streaming DMA api
> instead of coherent memory. Note I tried this enabling/disabling ipmmu
> too but the
> results are the same.

(Un)fortunately, I have never replaced coherent memory API with stream DMA API.

> > Did you try to probe the failure further by comparing the hexdumps? Where does
> > the mismatch happen?
> >
> I shall dump the memory and check the values, but basically crc is failing.

I'm also interesting about comparing the hexdump between host and ep.
This is my gut feeling though, I'm guessing this is a timing issue
because using coherent memory API will be on non-cache even if CPU access,
but using steaming DMA API will be on cache if CPU access by
dma_unmap_single(DMA_FROM_DEVICE) and get_random_bytes() in pci_endpoint_test_write().

If my guess is correct, almost all hexdumps are the same, but last
some bytes (I'm not sure how much bytes though) are not match.

Best regards,
Yoshihiro Shimoda


  reply	other threads:[~2020-03-31  7:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-18 11:37 PCIe EPF Lad, Prabhakar
2020-03-20  5:28 ` Kishon Vijay Abraham I
2020-03-21 22:49   ` Lad, Prabhakar
2020-03-24  1:58     ` Kishon Vijay Abraham I
2020-03-24 14:41       ` Lad, Prabhakar
2020-03-28 18:44         ` Lad, Prabhakar
2020-03-29 14:04           ` Lad, Prabhakar
2020-03-30 11:59             ` Kishon Vijay Abraham I
2020-03-30 13:09               ` Lad, Prabhakar
2020-03-30 13:20                 ` Kishon Vijay Abraham I
2020-03-30 13:46                   ` Lad, Prabhakar
2020-03-31  7:10                     ` Yoshihiro Shimoda [this message]
2020-03-31 17:25                       ` Lad, Prabhakar
2020-04-01  1:25                         ` Yoshihiro Shimoda
2020-04-01  8:00                           ` Lad, Prabhakar
2020-04-01  8:50                             ` Yoshihiro Shimoda
2020-04-01  9:24                               ` Lad, Prabhakar
2020-04-02  1:22                                 ` Yoshihiro Shimoda
2020-04-02  4:58                                   ` Yoshihiro Shimoda
2020-04-02 17:44                                     ` Lad, Prabhakar

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=TYAPR01MB45446ABD97A846045FD2B896D8C80@TYAPR01MB4544.jpnprd01.prod.outlook.com \
    --to=yoshihiro.shimoda.uh@renesas.com \
    --cc=kishon@ti.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=prabhakar.csengg@gmail.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 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).