devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Shawn Lin" <shawn.lin@rock-chips.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	linux-pci@vger.kernel.org, "Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org,
	"Rick Wertenbroek" <rick.wertenbroek@gmail.com>,
	"Wilfred Mallawa" <wilfred.mallawa@wdc.com>,
	"Niklas Cassel" <cassel@kernel.org>
Subject: Re: [PATCH v3 04/12] PCI: rockchip-ep: Improve rockchip_pcie_ep_map_addr()
Date: Sat, 12 Oct 2024 21:02:43 +0900	[thread overview]
Message-ID: <b70c7850-1fd2-4267-aa18-5e944a0bf81d@kernel.org> (raw)
In-Reply-To: <20241012093101.aj5hyeo3r7g6qlnn@thinkpad>

On 10/12/24 18:31, Manivannan Sadhasivam wrote:
> On Thu, Oct 10, 2024 at 12:43:57PM +0530, Manivannan Sadhasivam wrote:
>> On Mon, Oct 07, 2024 at 01:12:10PM +0900, Damien Le Moal wrote:
>>> Add a check to verify that the outbound region to be used for mapping an
>>> address is not already in use.
>>>
>>> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
>>
>> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>>
> 
> I'm trying to understand the ob window mapping here. So if rockchip_ob_region()
> returns same index for different *CPU* addresses, then you cannot map both of
> them? Is this a hardware ATU limitation?

The CPU addresses mapped are (under normal use) addresses from one of the 32 1MB
memory windows that pci_epc_alloc_addr() will give us. To map a memory window
address, we use the ATU entry at the index given by:

static inline u32 rockchip_ob_region(phys_addr_t addr)
{
        return (addr >> ilog2(SZ_1M)) & 0x1f;
}

So each memory window always use the same ATU entry and addresses from different
windows cannot use the same entry, ever.

But if there is a bug in the endpoint driver and map() or unmap() are called
with an invalid address (e.g. one that is not from a memory window), we will
still get a valid ATU entry number for that address. Hence the check that the
address passed to unmap is the one that is actually mapped, and also why we
check that the entry for an address to map is not being used.

> Also rockchip_pcie_prog_ep_ob_atu() is not taking into account of the cpu_addr.
> So I'm not sure how the mapping happens either.

Each ATU entry is for the corresponding memory window at the same index in the
controller memory. So the cpu address is not needed when programming the ATU as
it is implied from the entry we are programming.

So we could remove the cpu_addr argument of this function.

I also suspect that we potentially could play games with the .align_addr() to
assume a fixed 1MB alignment constraint for a PCI address mapping and always
pass 20 to the num_bits field of the ADDR0 register. However, I have not tried that.

-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2024-10-12 12:02 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-07  4:12 [PATCH v3 00/12] Damien Le Moal
2024-10-07  4:12 ` [PATCH v3 01/12] PCI: rockchip-ep: Fix address translation unit programming Damien Le Moal
2024-10-10  7:02   ` Manivannan Sadhasivam
2024-10-10  8:41     ` Damien Le Moal
2024-10-10 10:36       ` Manivannan Sadhasivam
2024-10-07  4:12 ` [PATCH v3 02/12] PCI: rockchip-ep: Use a macro to define EP controller .align feature Damien Le Moal
2024-10-10  7:03   ` Manivannan Sadhasivam
2024-10-07  4:12 ` [PATCH v3 03/12] PCI: rockchip-ep: Improve rockchip_pcie_ep_unmap_addr() Damien Le Moal
2024-10-10  7:09   ` Manivannan Sadhasivam
2024-10-11  8:22     ` Damien Le Moal
2024-10-07  4:12 ` [PATCH v3 04/12] PCI: rockchip-ep: Improve rockchip_pcie_ep_map_addr() Damien Le Moal
2024-10-10  7:13   ` Manivannan Sadhasivam
2024-10-12  9:31     ` Manivannan Sadhasivam
2024-10-12 12:02       ` Damien Le Moal [this message]
2024-10-12 12:39         ` Manivannan Sadhasivam
2024-10-07  4:12 ` [PATCH v3 05/12] PCI: rockchip-ep: Implement the .map_align() controller operation Damien Le Moal
2024-10-10  2:43   ` kernel test robot
2024-10-10  3:44   ` kernel test robot
2024-10-07  4:12 ` [PATCH v3 06/12] PCI: rockchip-ep: Refactor rockchip_pcie_ep_probe() memory allocations Damien Le Moal
2024-10-10  7:23   ` Manivannan Sadhasivam
2024-10-07  4:12 ` [PATCH v3 07/12] PCI: rockchip-ep: Refactor rockchip_pcie_ep_probe() MSI-X hiding Damien Le Moal
2024-10-10  7:25   ` Manivannan Sadhasivam
2024-10-10  8:09     ` Manivannan Sadhasivam
2024-10-10  8:37       ` Damien Le Moal
2024-10-11  8:30       ` Damien Le Moal
2024-10-12 12:14         ` Manivannan Sadhasivam
2024-10-11  8:25     ` Damien Le Moal
2024-10-12 12:12       ` Manivannan Sadhasivam
2024-10-07  4:12 ` [PATCH v3 08/12] PCI: rockchip-ep: Refactor endpoint link training enable Damien Le Moal
2024-10-10  8:22   ` Manivannan Sadhasivam
2024-10-11  8:45     ` Damien Le Moal
2024-10-07  4:12 ` [PATCH v3 09/12] PCI: rockship-ep: Introduce rockchip_pcie_ep_stop() Damien Le Moal
2024-10-10  8:24   ` Manivannan Sadhasivam
2024-10-07  4:12 ` [PATCH v3 10/12] PCI: rockchip-ep: Improve link training Damien Le Moal
2024-10-10 10:35   ` Manivannan Sadhasivam
2024-10-11  8:55     ` Damien Le Moal
2024-10-12 12:16       ` Manivannan Sadhasivam
2024-10-17  0:52         ` Damien Le Moal
2024-10-07  4:12 ` [PATCH v3 11/12] dt-bindings: pci: rockchip,rk3399-pcie-ep: Add ep-gpios property Damien Le Moal
2024-10-07  6:12   ` Krzysztof Kozlowski
2024-10-07  6:50     ` Damien Le Moal
2024-10-07  6:54       ` Krzysztof Kozlowski
2024-10-07  6:58         ` Damien Le Moal
2024-10-07  7:00           ` Krzysztof Kozlowski
2024-10-07  7:22             ` Damien Le Moal
2024-10-07  7:27               ` Manivannan Sadhasivam
2024-10-07  4:12 ` [PATCH v3 12/12] PCI: rockchip-ep: Handle PERST# signal in endpoint mode Damien Le Moal
2024-10-10  4:35   ` kernel test robot
2024-10-10 10:49   ` Manivannan Sadhasivam
2024-10-11  9:30     ` Damien Le Moal
2024-10-12 12:31       ` Manivannan Sadhasivam
2024-10-15  6:24         ` Damien Le Moal
2024-10-07  4:45 ` [PATCH v3 00/12] Damien Le Moal
2024-10-07 10:02 ` Niklas Cassel
2024-10-07 10:26   ` Damien Le Moal

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=b70c7850-1fd2-4267-aa18-5e944a0bf81d@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=kishon@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kw@linux.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=rick.wertenbroek@gmail.com \
    --cc=robh@kernel.org \
    --cc=shawn.lin@rock-chips.com \
    --cc=wilfred.mallawa@wdc.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).