From: Neil Armstrong <narmstrong@baylibre.com>
To: Rob Herring <robh@kernel.org>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Artem Lapkin <email2tema@gmail.com>,
Yue Wang <yue.wang@amlogic.com>,
Kevin Hilman <khilman@baylibre.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Krzysztof Wilczynski <kw@linux.com>,
Jerome Brunet <jbrunet@baylibre.com>,
Christian Hewitt <christianshewitt@gmail.com>,
PCI <linux-pci@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
"open list:ARM/Amlogic Meson..."
<linux-amlogic@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
art@khadas.com, Nick Xie <nick@khadas.com>,
gouwa@khadas.com
Subject: Re: [PATCH] PCI: dwc: meson add quirk
Date: Fri, 18 Jun 2021 17:08:42 +0200 [thread overview]
Message-ID: <9b27444c-ea13-0dd2-a671-cef27e03b35c@baylibre.com> (raw)
In-Reply-To: <CAL_JsqK+zjf2r_Q9gE8JwJw+Emn+JB4wOyH7eQct=kBvpUKstw@mail.gmail.com>
On 18/06/2021 16:30, Rob Herring wrote:
> On Fri, Jun 18, 2021 at 6:12 AM Martin Blumenstingl
> <martin.blumenstingl@googlemail.com> wrote:
>>
>> Hi Artem,
>>
>> On Fri, Jun 18, 2021 at 8:38 AM Artem Lapkin <email2tema@gmail.com> wrote:
>>>
>>> Device set same 256 bytes maximum read request size equal MAX_READ_REQ_SIZE
>>> was find some issue with HDMI scrambled picture and nvme devices
>>> at intensive writing...
>>>
>>> [ 4.798971] nvme 0000:01:00.0: fix MRRS from 512 to 256
>>>
>>> This quirk setup same MRRS if we try solve this problem with
>>> pci=pcie_bus_perf kernel command line param
>> thank you for investigating this issue and for providing a fix!
>>
>> [...]
>>> +static void meson_pcie_quirk(struct pci_dev *dev)
>>> +{
>>> + int mrrs;
>>> +
>>> + /* no need quirk */
>>> + if (pcie_bus_config != PCIE_BUS_DEFAULT)
>>> + return;
>>> +
>>> + /* no need for root bus */
>>> + if (pci_is_root_bus(dev->bus))
>>> + return;
>>> +
>>> + mrrs = pcie_get_readrq(dev);
>>> +
>>> + /*
>>> + * set same 256 bytes maximum read request size equal MAX_READ_REQ_SIZE
>>> + * was find some issue with HDMI scrambled picture and nvme devices
>>> + * at intensive writing...
>>> + */
>>> +
>>> + if (mrrs != MAX_READ_REQ_SIZE) {
>>> + dev_info(&dev->dev, "fix MRRS from %d to %d\n", mrrs, MAX_READ_REQ_SIZE);
>>> + pcie_set_readrq(dev, MAX_READ_REQ_SIZE);
>>> + }
>>> +}
>>> +DECLARE_PCI_FIXUP_ENABLE(PCI_ANY_ID, PCI_ANY_ID, meson_pcie_quirk);
>
> Isn't this going to run for everyone if meson driver happens to be enabled?
It should be enabled only when the Amlogic bridge is present, thus similar filtering as keystone & loongon
is needed, but with such filtering we could reuse ks_pcie_quirk() and loongson_mrrs_quirk() as is.
>
>> it seems that other PCIe controllers need something similar. in
>> particular I found pci-keystone [0] and pci-loongson [1]
>> while comparing your code with the two existing implementations two
>> things came to my mind:
>> 1. your implementation slightly differs from the two existing ones as
>> it's not walking through the parent PCI busses (I think this would be
>> relevant if there's another bridge between the host bridge and the
>> actual device)
>> 2. (this is a question towards the PCI maintainers) does it make sense
>> to have this MRRS quirk re-usable somewhere?
>
> Yes. Ideally, the max size could just be data in the bus or bridge
> struct and perhaps some flags too, then the core can handle
> everything.
AFAIL Simply moving ks_pcie_quirk() and loongson_mrrs_quirk() to core with the amlogic pci IDS added would be sufficient here.
Neil
>
> Rob
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-06-18 15:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-18 6:38 [PATCH] PCI: dwc: meson add quirk Artem Lapkin
2021-06-18 12:11 ` Martin Blumenstingl
2021-06-18 14:30 ` Rob Herring
2021-06-18 15:08 ` Neil Armstrong [this message]
2021-06-19 3:01 ` Art Nikpal
2021-06-18 23:01 ` 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=9b27444c-ea13-0dd2-a671-cef27e03b35c@baylibre.com \
--to=narmstrong@baylibre.com \
--cc=art@khadas.com \
--cc=christianshewitt@gmail.com \
--cc=email2tema@gmail.com \
--cc=gouwa@khadas.com \
--cc=jbrunet@baylibre.com \
--cc=khilman@baylibre.com \
--cc=kw@linux.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=martin.blumenstingl@googlemail.com \
--cc=nick@khadas.com \
--cc=robh@kernel.org \
--cc=yue.wang@amlogic.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