Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: "Sumit Kumar" <sumit.kumar@oss.qualcomm.com>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] pci: designware: Set DMA_BYPASS bit in outbound IATU CTRL2 register
Date: Sun, 13 Sep 2026 19:16:52 +0200	[thread overview]
Message-ID: <aqbahGslz11TWIRo@fedora> (raw)
In-Reply-To: <4nxyshx26bl5r7jjjnghsyz7k63lah6zx77cuea37mziww7kb4@iij5g3om67ub>

On Sun, Sep 13, 2026 at 11:35:59AM +0200, Manivannan Sadhasivam wrote:
> 
> pci_epc_mem_map() is already useless in the eDMA path today. So this patch
> doesn't change that.

I'm not sure if useless is the proper word here.
Redundant is perhaps a better word.


Let me explain using pci-epf-test.c:pci_epf_test_read() as an example:

Without the patch in $subject, on a DWC based platform:

pci_epc_mem_map() will setup an iATU entry, and the eDMA transaction will then
be translated using that iATU entry, before being sent out on the PCIe bus.

So the iATU entry is actually being used.


After the patch in $subject, on a DWC based platform:

pci_epc_mem_map() will setup an iATU entry, however, because of the DMA_BYPASS
bit, that iATU entry will not be used, and the transaction will be send out on
the PCIe bus untranslated.


So I would argue that it is only after this patch that pci_epc_mem_map() will
setup an iATU entry that will then never be used.

Yes, I think I understand that you are trying to say that, for DWC based
drivers, we could theoretically skip the pci_epc_mem_map() call, and send the
transaction untranslated.

My point is that it feels silly to set the DMA_BYPASS bit without also making
sure that the pci_epc_mem_map() calls are either removed or (at least for DWC
based platforms) modified to not set up an iATU entry in the DMA path in the
first place.

I am happy that this is getting cleaned up, I just don't like a half cleanup
where we, after this commit, will setup+teardown iATU entries that will then
never be used for the actual transaction.


Kind regards,
Niklas

      reply	other threads:[~2026-09-13 17:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08  6:18 [PATCH v2] pci: designware: Set DMA_BYPASS bit in outbound IATU CTRL2 register Sumit Kumar
2026-09-08  6:25 ` sashiko-bot
2026-09-08 15:08 ` Niklas Cassel
2026-09-13  9:35   ` Manivannan Sadhasivam
2026-09-13 17:16     ` Niklas Cassel [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=aqbahGslz11TWIRo@fedora \
    --to=cassel@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=jingoohan1@gmail.com \
    --cc=kwilczynski@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=robh@kernel.org \
    --cc=sumit.kumar@oss.qualcomm.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