mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Rob Herring <robh@kernel.org>, Elad Nachman <enachman@marvell.com>
Cc: thomas.petazzoni@bootlin.com, bhelgaas@google.com,
	lpieralisi@kernel.org, kw@linux.com,
	krzysztof.kozlowski+dt@linaro.org, linux-pci@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 7/8] PCI: dwc: Introduce configurable DMA mask
Date: Mon, 27 Mar 2023 18:01:47 +0100	[thread overview]
Message-ID: <15102094-10d3-b160-59cc-d5b9b93ae1b3@arm.com> (raw)
In-Reply-To: <20230317182323.GA2445959-robh@kernel.org>

On 2023-03-17 18:23, Rob Herring wrote:
> +Robin
> 
> On Mon, Mar 13, 2023 at 02:40:15PM +0200, Elad Nachman wrote:
>> From: Elad Nachman <enachman@marvell.com>
>>
>> Some devices, such as AC5 and AC5X have their physical DDR memory
>> start at address 0x2_0000_0000. In order to have the DMA coherent
>> allocation succeed later, a different DMA mask is required, as
>> defined in the DT file for such SOCs, using dma-ranges.
> 
> I'm afraid this is not right. 'dma-ranges' in the PCI host bridge node
> applies to PCI devices (i.e. child node), not the host bridge itself.
> It's 'dma-ranges' in the parent node of the host bridge that applies
> here. The core code will set masks (ranges really now) based on bus
> restrictions. The mask for the device should only be based on the
> device's limits (i.e. the device is 32-bit only).
> 
> I think you will need whatever solution comes out of this thread[1].

Right, "make the allocation succeed later" is entirely missing the point 
of this code. The only reason we're doing that allocation at all is to 
reserve a 32-bit bus address. If it fails, it means we can't reliably 
support endpoints with only a 32-bit MSI capability. Using a bigger mask 
in order to successfully reserve a >32-bit bus address basically 
*guarantees* that you can't support endpoints with only a 32-bit MSI 
capability.

Thanks Rob for digging up that thread; the original idea there should 
still be fine, but the alternative suggestion from Serge at the end is 
potentially even better for this situation where it's down to the SoC's 
memory map rather than the kernel config. It just needs somebody with 
sufficient motivation and resources to write and test a patch :)

Robin.

> 
> Rob
> 
> [1] https://lore.kernel.org/all/c014b074-6d7f-773b-533a-c0500e239ab8@arm.com/

  reply	other threads:[~2023-03-27 17:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-13 12:40 [PATCH v4 0/8] PCI: dwc: Add support for Marvell AC5 SoC Elad Nachman
2023-03-13 12:40 ` [PATCH v4 1/8] dt-bindings: PCI: armada8k: Add compatible string for " Elad Nachman
2023-03-13 12:40 ` [PATCH v4 2/8] PCI: armada8k: Add AC5 SoC support Elad Nachman
2023-03-13 19:43   ` Bjorn Helgaas
2023-03-22 23:19   ` Serge Semin
2023-03-13 12:40 ` [PATCH v4 3/8] PCI: armada8k: Add AC5 MSI support Elad Nachman
2023-03-22 23:23   ` Serge Semin
2023-03-13 12:40 ` [PATCH v4 4/8] dt-bindings: PCI: dwc: Add dma-ranges, region mask Elad Nachman
2023-03-17 18:30   ` Rob Herring
2023-03-13 12:40 ` [PATCH v4 5/8] PCI: armada8k: support AC5 INTx PCIe interrupts Elad Nachman
2023-03-13 12:40 ` [PATCH v4 6/8] PCI: armada8k: support reg regions according to DT Elad Nachman
2023-03-13 12:40 ` [PATCH v4 7/8] PCI: dwc: Introduce configurable DMA mask Elad Nachman
2023-03-17 18:23   ` Rob Herring
2023-03-27 17:01     ` Robin Murphy [this message]
2023-03-13 12:40 ` [PATCH v4 8/8] PCI: dwc: Introduce region limit from DT Elad Nachman
2023-03-13 19:48   ` Bjorn Helgaas
2023-03-14 20:48     ` Serge Semin
2023-03-23  0:11   ` Serge Semin
2023-03-13 19:22 ` [PATCH v4 0/8] PCI: dwc: Add support for Marvell AC5 SoC Bjorn Helgaas

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=15102094-10d3-b160-59cc-d5b9b93ae1b3@arm.com \
    --to=robin.murphy@arm.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=enachman@marvell.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=robh@kernel.org \
    --cc=thomas.petazzoni@bootlin.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

all inboxes | Powered by JetHome®