All of lore.kernel.org
 help / color / mirror / Atom feed
From: Art Nikpal <email2tema@gmail.com>
To: Neil Armstrong <narmstrong@baylibre.com>
Cc: Rob Herring <robh@kernel.org>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.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>,
	Artem Lapkin <art@khadas.com>, Nick Xie <nick@khadas.com>,
	Gouwa Wang <gouwa@khadas.com>
Subject: Re: [PATCH] PCI: dwc: meson add quirk
Date: Sat, 19 Jun 2021 11:01:53 +0800	[thread overview]
Message-ID: <CAKaHn9JK341ijN81kJyh32LksXVNGXTz-59QiGPxp0K6WGFN6g@mail.gmail.com> (raw)
In-Reply-To: <9b27444c-ea13-0dd2-a671-cef27e03b35c@baylibre.com>

> 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
> >
>

WARNING: multiple messages have this Message-ID (diff)
From: Art Nikpal <email2tema@gmail.com>
To: Neil Armstrong <narmstrong@baylibre.com>
Cc: Rob Herring <robh@kernel.org>,
	 Martin Blumenstingl <martin.blumenstingl@googlemail.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>,
	Artem Lapkin <art@khadas.com>,  Nick Xie <nick@khadas.com>,
	Gouwa Wang <gouwa@khadas.com>
Subject: Re: [PATCH] PCI: dwc: meson add quirk
Date: Sat, 19 Jun 2021 11:01:53 +0800	[thread overview]
Message-ID: <CAKaHn9JK341ijN81kJyh32LksXVNGXTz-59QiGPxp0K6WGFN6g@mail.gmail.com> (raw)
In-Reply-To: <9b27444c-ea13-0dd2-a671-cef27e03b35c@baylibre.com>

> 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
> >
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Art Nikpal <email2tema@gmail.com>
To: Neil Armstrong <narmstrong@baylibre.com>
Cc: Rob Herring <robh@kernel.org>,
	 Martin Blumenstingl <martin.blumenstingl@googlemail.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>,
	Artem Lapkin <art@khadas.com>,  Nick Xie <nick@khadas.com>,
	Gouwa Wang <gouwa@khadas.com>
Subject: Re: [PATCH] PCI: dwc: meson add quirk
Date: Sat, 19 Jun 2021 11:01:53 +0800	[thread overview]
Message-ID: <CAKaHn9JK341ijN81kJyh32LksXVNGXTz-59QiGPxp0K6WGFN6g@mail.gmail.com> (raw)
In-Reply-To: <9b27444c-ea13-0dd2-a671-cef27e03b35c@baylibre.com>

> 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
> >
>

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

  reply	other threads:[~2021-06-19  3:02 UTC|newest]

Thread overview: 20+ 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  6:38 ` Artem Lapkin
2021-06-18  6:38 ` Artem Lapkin
2021-06-18 12:11 ` Martin Blumenstingl
2021-06-18 12:11   ` Martin Blumenstingl
2021-06-18 12:11   ` Martin Blumenstingl
2021-06-18 14:30   ` Rob Herring
2021-06-18 14:30     ` Rob Herring
2021-06-18 14:30     ` Rob Herring
2021-06-18 15:08     ` Neil Armstrong
2021-06-18 15:08       ` Neil Armstrong
2021-06-18 15:08       ` Neil Armstrong
2021-06-19  3:01       ` Art Nikpal [this message]
2021-06-19  3:01         ` Art Nikpal
2021-06-19  3:01         ` Art Nikpal
2021-06-18 18:29 ` kernel test robot
2021-06-18 18:29   ` kernel test robot
2021-06-18 23:01 ` Bjorn Helgaas
2021-06-18 23:01   ` Bjorn Helgaas
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=CAKaHn9JK341ijN81kJyh32LksXVNGXTz-59QiGPxp0K6WGFN6g@mail.gmail.com \
    --to=email2tema@gmail.com \
    --cc=art@khadas.com \
    --cc=christianshewitt@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=narmstrong@baylibre.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.