Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp5683192pxv; Wed, 7 Jul 2021 09:20:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzuQNmpalHdC9isqycfyT9QtAjwWr84QF81SMx78jaWF6HqTkVxyvDZV4QCr8eHIEIBXJZO X-Received: by 2002:aa7:c3d8:: with SMTP id l24mr30764705edr.172.1625674803539; Wed, 07 Jul 2021 09:20:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625674803; cv=none; d=google.com; s=arc-20160816; b=Zs4sUHnHuCoUdMkBK2Ni5JaWce9OhdZebQcveCF+x8oJFUGPkfv1Q/vwzaurygaXDd xxLDaA+ZmbzCs81VDcZkSFcApnr5tMHzPLGrxRR7H+4wB7R7FT5c/UUFJtiYlasAQVeo Gwq+cm8BQI6Cd04JtprRb9HJG7w/M3mH4wvVhS2I0M2rE7Zg6ewildgBsxKcl7ehFZzw uKGkuDXZ0gYIJb4neyYY/XMT8rG8+rZvzFW/Kh0ak2ZQw0GLAp3U5c6foM4NUyNxj3xl RWyudEmcL9ice8It2fGa1HA/QLt0y1wcruG9EhlQj0uc0s5tksz4/O3Y5OI9RIK3pMz8 q8vA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :message-id:subject:cc:to:from:date:dkim-signature; bh=8QLvRqINq+eaQqLXXyZH1BstAjE5dKDP6ec9wHyQl2Y=; b=VQwO3xgBmj19hPZdW2BNZlKf0CYG0EkzL56s0OcWEg8n3CA3AYGgbn8qJ7Qdfh2xcI KkkDdwEBySLhYAK1H27G85hOjNZsD/V776BVRVAxqdV3AbNAVZacqvsB7I5cGlI8ptDq 96vEJakaJgItPLmiN94EAexrDfIlcKiKVjV5BR/kfuOS70yympxYBaEYHe0Bn0hrtGOl VLwfpkCl7u9zc84IuUzOCg3bV56b2jeA2X8+kI/PU+9q8FPF3N/C7osgycJOaK++vlZN G2wFv20kQEL+Cn+MyW3BmyrqeRGv8vYomNnWOqyls3blC5VN0XZ6FsuC5kMK0u8WmxCw O+Xw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=i2oNik5d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q4si19020122edv.597.2021.07.07.09.19.40; Wed, 07 Jul 2021 09:20:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=i2oNik5d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231797AbhGGP5A (ORCPT + 99 others); Wed, 7 Jul 2021 11:57:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:52436 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231533AbhGGP47 (ORCPT ); Wed, 7 Jul 2021 11:56:59 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 477B561CBF; Wed, 7 Jul 2021 15:54:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1625673259; bh=jBYB8E2kxgHKI+p6Ge17CrAqEwZGHZvxadKDfFVaIpg=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=i2oNik5do5AHOLInc4OUUnh1F5HFHYK0kr4sWV3miNytCJw7/lDxUrFNZc8zt+nVY OiD9V2ljFumrYj8FRbVYSSjxPfzFDRrGLSj6Wx3m5uQA2m8CZtbkBk/RKXZ+aWJb2E SmHiGI0lmJLrmjHxBW1okpUEq0lX4ITih1OyeYBigaiJ2xoKatvbZdQ2hBOYN8FPYD 10AdgnOw8vzYCVq5JVfO5sByQHdJvhvdYC2IBE/4TnEELQcKv8QoPSP7J9TBO3vLyg T+hSNeXjX71oyYS4rQ5JrGBRvKfteyyO2NwNv3nYVTt1O1mfPW6tTySCVYE1nJY/w3 rXj5dhh7qvz2Q== Date: Wed, 7 Jul 2021 10:54:18 -0500 From: Bjorn Helgaas To: Neil Armstrong Cc: Art Nikpal , Huacai Chen , =?utf-8?B?6ZmI5Y2O5omN?= , Yue Wang , Kevin Hilman , Lorenzo Pieralisi , Rob Herring , Krzysztof Wilczynski , Jerome Brunet , Christian Hewitt , Martin Blumenstingl , PCI , linux-arm-kernel , "open list:ARM/Amlogic Meson..." , LKML , Artem Lapkin , Nick Xie , Gouwa Wang Subject: Re: [PATCH 0/4] PCI: replace dublicated MRRS limit quirks Message-ID: <20210707155418.GA897940@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1271fa28-dddd-01a3-5ad5-e3b4898f5482@baylibre.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 06, 2021 at 11:54:05AM +0200, Neil Armstrong wrote: > In their Designware PCIe controller driver, amlogic sets the > Max_Payload_Size & Max_Read_Request_Size to 256: > https://elixir.bootlin.com/linux/latest/source/drivers/pci/controller/dwc/pci-meson.c#L260 > https://elixir.bootlin.com/linux/latest/source/drivers/pci/controller/dwc/pci-meson.c#L276 > in their root port PCIe Express Device Control Register. > > Looking at the Synopsys DW-PCIe Databook, Max_Payload_Size & > Max_Read_Request_Size are used to decompose into AXI burst, but it > seems the Max_Payload_Size & Max_Read_Request_Size are set by > default to 512 but the internal Max_Payload_Size_Supported is set to > 256, thus changing these values to 256 at runtime to match and > optimize bandwidth. > > It's said, "Reducing Outbound Decomposition" : > - "Ensure that your application master does not generate bursts of > size greater than or equal to Max_Payload_Size" > > - "Program your PCIe system with a larger value of Max_Payload_Size > without exceeding Max_Payload_Size_Supported" > > - "Program your PCIe system with a larger value of Max_Read_Request > without exceeding Max_Payload_Size_Supported: > > So leaving 512 in Max_Payload_Size & Max_Read_Request leads to > Outbound Decomposition which decreases PCIe link and degrades the > AXI bus by doubling the bursts, leading to this fix to avoid > overflowing the AXI bus. > > So it seems to be still needed, I assume this *should* be handled in > the core somehow to propagate these settings to child endpoints to > match the root port Max_Payload_Size & Max_Read_Request sizes. > > Maybe by adding a core function to set these values instead of using > the dw_pcie_find_capability() & dw_pcie_write/readl_dbi() helpers > and set a state on the root port to propagate the value ? I don't have the Synopsys DW-PCIe Databook, so I'm lacking any context. The above *seems* to say that MPS/MRRS settings affect AXI bus usage. The MPS and MRRS registers are defined to affect traffic on *PCIe*. If a platform uses MPS and MRRS values to optimize transfers on non-PCIe links, that's a problem because the PCI core code that manages MPS and MRRS has no knowledge of those non-PCIe parts of the system. You might be able to deal with this in Synopsys-specific code somehow, but it's going to be a bit of a hassle because I don't want it to make maintenance of the generic MPS/MRRS code harder. Bjorn