| Message ID | 20210618063821.1383357-1-art@khadas.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Lorenzo Pieralisi |
| Headers | show |
| Series | PCI: dwc: meson add quirk | expand |
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); 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? Best regards, Martin [0] https://elixir.bootlin.com/linux/v5.12/source/drivers/pci/controller/dwc/pci-keystone.c#L524 [1] https://elixir.bootlin.com/linux/v5.12/source/drivers/pci/controller/pci-loongson.c#L63
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 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. Rob
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 >
Hi Artem,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on pci/next]
[also build test ERROR on v5.13-rc6 next-20210618]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Artem-Lapkin/PCI-dwc-meson-add-quirk/20210618-144001
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/1ef258aa2d36864949ac0d97fbdb475c8b1a8fd0
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Artem-Lapkin/PCI-dwc-meson-add-quirk/20210618-144001
git checkout 1ef258aa2d36864949ac0d97fbdb475c8b1a8fd0
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> ERROR: modpost: "pcie_bus_config" [drivers/pci/controller/dwc/pci-meson.ko] undefined!
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
On Fri, Jun 18, 2021 at 02:38:21PM +0800, Artem Lapkin 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... Wait a minute. We're getting way too much of this MRRS fiddling with too little understanding of what the real problem is, and this is becoming a maintenance problem. We need more details about what the problem is and what specific devices are affected. If this is a defect in the host bridge, we should have published errata about this because AFAICT there is nothing in the spec that limits the MRRS the OS can program. If we need to work around a problem, the quirk should relate to the device that is defective, not to every PCI device that could potentially be plugged in. Related recent issue: https://lore.kernel.org/r/20210528203224.GA1516603@bjorn-Precision-5520 > [ 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 > > Signed-off-by: Artem Lapkin <art@khadas.com> > --- > drivers/pci/controller/dwc/pci-meson.c | 27 ++++++++++++++++++++++++++ > 1 file changed, 27 insertions(+) > > diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controller/dwc/pci-meson.c > index 686ded034f22..e2d40e5c2661 100644 > --- a/drivers/pci/controller/dwc/pci-meson.c > +++ b/drivers/pci/controller/dwc/pci-meson.c > @@ -466,6 +466,33 @@ static int meson_pcie_probe(struct platform_device *pdev) > return ret; > } > > +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); > + > static const struct of_device_id meson_pcie_of_match[] = { > { > .compatible = "amlogic,axg-pcie", > -- > 2.25.1 >
> Neil > 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. > AFAIL Simply moving ks_pcie_quirk() and loongson_mrrs_quirk() to core with the amlogic pci IDS added would be sufficient here. My patch was not a good solution! its was just example how to fix our problem - need to remade it Yes i'm agree with Neil , at this moment we can move (replace duplicate functionalities) ks_pcie_quirk() and loongson_mrrs_quirk() to core + add amlogic pci IDS PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS, PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3) - without other changes for everyone, and after we can improve this quirk by next patches i will send new patches variant soon On Fri, Jun 18, 2021 at 11:08 PM Neil Armstrong <narmstrong@baylibre.com> wrote: > > 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 > > >
diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controller/dwc/pci-meson.c index 686ded034f22..e2d40e5c2661 100644 --- a/drivers/pci/controller/dwc/pci-meson.c +++ b/drivers/pci/controller/dwc/pci-meson.c @@ -466,6 +466,33 @@ static int meson_pcie_probe(struct platform_device *pdev) return ret; } +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); + static const struct of_device_id meson_pcie_of_match[] = { { .compatible = "amlogic,axg-pcie",
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 Signed-off-by: Artem Lapkin <art@khadas.com> --- drivers/pci/controller/dwc/pci-meson.c | 27 ++++++++++++++++++++++++++ 1 file changed, 27 insertions(+)