linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: Rick Wertenbroek <rick.wertenbroek@gmail.com>
Cc: alberto.dassatti@heig-vd.ch, xxm@rock-chips.com,
	rick.wertenbroek@heig-vd.ch, "Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Shawn Lin" <shawn.lin@rock-chips.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Jani Nikula" <jani.nikula@intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Mikko Kovanen" <mikko.kovanen@aavamobile.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v2 1/9] PCI: rockchip: Remove writes to unused registers
Date: Thu, 16 Feb 2023 16:28:38 +0900	[thread overview]
Message-ID: <5c15e1d1-c7e9-0b7c-9b14-f95543c70383@opensource.wdc.com> (raw)
In-Reply-To: <559bdd8c-9cc8-d7ae-a937-ffee9cfbb8a6@opensource.wdc.com>

On 2/15/23 18:58, Damien Le Moal wrote:
[...]
> WRITE ( 131072 bytes):		OKAY
> WRITE (1024000 bytes):		OKAY
> 
> Then stops here doing the 1024001 B case. The host waits for a completion that
> does not come. On the EP side, I see:
> 
> [   94.307215] pci_epf_test pci_epf_test.0: READ src addr 0xffd00000, 1024001 B
> [   94.307960] pci_epc fd000000.pcie-ep: Map region 1 phys addr 0xfa100000 to
> pci addr 0xffd00000, 1024001 B
> [   94.308924] rockchip-pcie-ep fd000000.pcie-ep: Set atu: region 1, cpu addr
> 0xfa100000, pci addr 0xffd00000, 1024001 B
> [  132.309645] dma-pl330 ff6e0000.dma-controller: Reset Channel-2
> CS-20000e FTC-40000
> 
>                                                   ^^^^^^^^^^^^^^^
> The DMA engine does not like something at all. Back to where I was when I tried
> your series initially, which is why I tried removing patch 1 to see what happens...
> 
> [  132.370479] pci_epf_test pci_epf_test.0: READ => Size: 1024001 B, DMA: YES,
> Time: 38.059623935 s, Rate: 26 KB/s
> [  132.372152] pci_epc fd000000.pcie-ep: Unmap region 1
> [  132.372780] pci_epf_test pci_epf_test.0: RAISE MSI IRQ 1
> [  132.373312] rockchip-pcie-ep fd000000.pcie-ep: Send MSI IRQ 1
> [  132.373844] rockchip-pcie-ep fd000000.pcie-ep: MSI disabled
> [  132.374388] pci_epf_test pci_epf_test.0: Raise IRQ failed -22
> 
> And it looks like the PCI core crashed or something because MSI does not work
> anymore as well (note that this is wheat I see with my nvme epf driver too, but
> I do not have that DMA channel reset message...)
> 
> If I run the tests without DMA (mmio only), everything seems fine:
> 
> ## Read Tests (No DMA)
> READ (      1 bytes):		OKAY
> READ (   1024 bytes):		OKAY
> READ (   1025 bytes):		OKAY
> READ (1024000 bytes):		OKAY
> READ (1024001 bytes):		OKAY
> 
> ## Write Tests (No DMA)
> WRITE (      1 bytes):		OKAY
> WRITE (   1024 bytes):		OKAY
> WRITE (   1025 bytes):		OKAY
> WRITE (1024000 bytes):		OKAY
> WRITE (1024001 bytes):		OKAY
> 
> ## Copy Tests (No DMA)
> COPY (      1 bytes):		OKAY
> COPY (   1024 bytes):		OKAY
> COPY (   1025 bytes):		OKAY
> COPY (1024000 bytes):		OKAY
> COPY (1024001 bytes):		OKAY
> 
> So it looks like translation is working with your patch, but that the driver is
> still missing something for DMA to work correctly...

I kept testing this and realized that I was not getting a consistent behavior.
Sometimes all tests passed, but would not repeat (running again would fail
everything), sometimes NMIs from bad accesses, and other times "hang" (test not
completing but no real machine hang/crash). So it started to hint at something
randomly initialized...

Re-reading the TRM, particularly section 17.5.5.1.1, I realized that the lower
16 bits of the desc2 register are used for the translation, but we never set
them with the current code. Only desc0 and desc1... So I added a write(0) to
desc2 and now it is finally working well. Running the tests in a loop, they all
pass and no bad behavior is observed.

My cleaned-up rockchip_pcie_prog_ep_ob_atu() function now looks like this:

static void rockchip_pcie_prog_ep_ob_atu(struct rockchip_pcie *rockchip, u8 fn,
                                         u32 r, u32 type, u64 phys_addr,
                                         u64 pci_addr, size_t size)
{
        u64 sz = 1ULL << fls64(size - 1);
        int num_pass_bits = ilog2(sz);
        u32 addr0, addr1, desc0;

        /* Sanity checks */
        if (WARN_ON_ONCE(type == AXI_WRAPPER_NOR_MSG))
                return;
        if (WARN_ON_ONCE(ALIGN_DOWN(phys_addr, SZ_1M) != phys_addr))
                return;
        if (WARN_ON_ONCE(rockchip_ob_region(phys_addr + size - 1) != r))
                return;

        /* We must pass at least 8 bits of PCI bus address */
        if (num_pass_bits < 8)
                num_pass_bits = 8;

        /* PCI bus address region */
        addr0 = ((num_pass_bits - 1) & PCIE_CORE_OB_REGION_ADDR0_NUM_BITS) |
                (lower_32_bits(pci_addr) & PCIE_CORE_OB_REGION_ADDR0_LO_ADDR);
        addr1 = upper_32_bits(pci_addr);
        desc0 = ROCKCHIP_PCIE_AT_OB_REGION_DESC0_DEVFN(fn) | type;

        rockchip_pcie_write(rockchip, addr0,
                            ROCKCHIP_PCIE_AT_OB_REGION_PCI_ADDR0(r));
        rockchip_pcie_write(rockchip, addr1,
                            ROCKCHIP_PCIE_AT_OB_REGION_PCI_ADDR1(r));
        rockchip_pcie_write(rockchip, desc0,
                            ROCKCHIP_PCIE_AT_OB_REGION_DESC0(r));
        rockchip_pcie_write(rockchip, 0,
                            ROCKCHIP_PCIE_AT_OB_REGION_DESC1(r));
        rockchip_pcie_write(rockchip, 0,
                            ROCKCHIP_PCIE_AT_OB_REGION_DESC2(r));
}

And the function rockchip_pcie_clear_ep_ob_atu() also clears desc2:

static void rockchip_pcie_clear_ep_ob_atu(struct rockchip_pcie *rockchip,
                                          u32 region)
{
        rockchip_pcie_write(rockchip, 0,
                            ROCKCHIP_PCIE_AT_OB_REGION_PCI_ADDR0(region));
        rockchip_pcie_write(rockchip, 0,
                            ROCKCHIP_PCIE_AT_OB_REGION_PCI_ADDR1(region));
        rockchip_pcie_write(rockchip, 0,
                            ROCKCHIP_PCIE_AT_OB_REGION_DESC0(region));
        rockchip_pcie_write(rockchip, 0,
                            ROCKCHIP_PCIE_AT_OB_REGION_DESC1(region));
        rockchip_pcie_write(rockchip, 0,
                            ROCKCHIP_PCIE_AT_OB_REGION_DESC2(region));
}

Thoughts ?

-- 
Damien Le Moal
Western Digital Research


  reply	other threads:[~2023-02-16  7:28 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-14 14:08 [PATCH v2 0/9] PCI: rockchip: Fix RK3399 PCIe endpoint controller driver Rick Wertenbroek
2023-02-14 14:08 ` [PATCH v2 1/9] PCI: rockchip: Remove writes to unused registers Rick Wertenbroek
2023-02-14 23:56   ` Damien Le Moal
2023-02-15  9:04     ` Rick Wertenbroek
2023-02-15  9:17       ` Damien Le Moal
2023-02-15  9:58       ` Damien Le Moal
2023-02-16  7:28         ` Damien Le Moal [this message]
2023-02-16  8:43           ` Rick Wertenbroek
2023-02-16  9:54             ` Damien Le Moal
2023-02-14 14:08 ` [PATCH v2 2/9] PCI: rockchip: Write PCI Device ID to correct register Rick Wertenbroek
2023-02-14 23:57   ` Damien Le Moal
2023-02-14 14:08 ` [PATCH v2 3/9] PCI: rockchip: Assert PCI Configuration Enable bit after probe Rick Wertenbroek
2023-02-14 23:58   ` Damien Le Moal
2023-02-14 14:08 ` [PATCH v2 4/9] PCI: rockchip: Add poll and timeout to wait for PHY PLLs to be locked Rick Wertenbroek
2023-02-15  1:01   ` Damien Le Moal
2023-02-14 14:08 ` [PATCH v2 5/9] arm64: dts: rockchip: Add dtsi entry for RK3399 PCIe endpoint core Rick Wertenbroek
2023-02-15  1:03   ` Damien Le Moal
2023-02-14 14:08 ` [PATCH v2 6/9] PCI: rockchip: Fix window mapping and address translation for endpoint Rick Wertenbroek
2023-02-15  1:20   ` Damien Le Moal
2023-02-14 14:08 ` [PATCH v2 7/9] PCI: rockchip: Fix legacy IRQ generation for RK3399 PCIe endpoint core Rick Wertenbroek
2023-02-15  1:26   ` Damien Le Moal
2023-02-15  2:38   ` Damien Le Moal
2023-02-14 14:08 ` [PATCH v2 8/9] PCI: rockchip: Use u32 variable to access 32-bit registers Rick Wertenbroek
2023-02-15  1:34   ` Damien Le Moal
2023-02-15 10:46     ` David Laight
2023-02-15 11:20       ` Damien Le Moal
2023-03-14 15:45     ` Rick Wertenbroek
2023-02-14 14:08 ` [PATCH v2 9/9] PCI: rockchip: Add parameter check for RK3399 PCIe endpoint core set_msi() Rick Wertenbroek
2023-02-15  1:39   ` Damien Le Moal
2023-02-21 10:47     ` Rick Wertenbroek
2023-02-21 10:55       ` Damien Le Moal
2023-02-21 13:19         ` Rick Wertenbroek
2023-02-21 16:37           ` Rick Wertenbroek
2023-02-21 22:01             ` Damien Le Moal
2023-02-21 21:57           ` Damien Le Moal
2023-02-15  1:51 ` [PATCH v2 0/9] PCI: rockchip: Fix RK3399 PCIe endpoint controller driver Damien Le Moal
2023-02-15 10:28   ` Rick Wertenbroek
2023-02-15 10:41     ` Damien Le Moal
2023-03-14  0:02 ` Damien Le Moal
2023-03-14  7:57   ` Rick Wertenbroek
2023-03-14  8:10     ` Damien Le Moal
2023-03-14 14:53       ` Rick Wertenbroek
2023-03-14 22:54         ` Damien Le Moal
2023-03-15  0:00           ` Damien Le Moal
2023-03-16 12:52             ` Rick Wertenbroek
2023-03-16 16:34               ` Rick Wertenbroek
2023-03-16 22:09                 ` Damien Le Moal
2023-04-13 13:49                   ` Lorenzo Pieralisi
2023-04-13 14:34                     ` Rick Wertenbroek

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=5c15e1d1-c7e9-0b7c-9b14-f95543c70383@opensource.wdc.com \
    --to=damien.lemoal@opensource.wdc.com \
    --cc=alberto.dassatti@heig-vd.ch \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko@sntech.de \
    --cc=jani.nikula@intel.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=linux-rockchip@lists.infradead.org \
    --cc=lpieralisi@kernel.org \
    --cc=mikko.kovanen@aavamobile.com \
    --cc=rick.wertenbroek@gmail.com \
    --cc=rick.wertenbroek@heig-vd.ch \
    --cc=robh+dt@kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=shawn.lin@rock-chips.com \
    --cc=xxm@rock-chips.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).