linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Tom Joseph <tjoseph@cadence.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	PCI <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	devicetree@vger.kernel.org,
	linux-omap <linux-omap@vger.kernel.org>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 03/14] PCI: cadence: Convert all r/w accessors to perform only 32-bit accesses
Date: Wed, 27 May 2020 10:37:44 -0600	[thread overview]
Message-ID: <CAL_JsqJMZxOFw-kn5_9bNTPzJuwHybJAi6iQyBq=6BrKSvfTqA@mail.gmail.com> (raw)
In-Reply-To: <b3663862-44df-867f-0824-28802909f224@ti.com>

On Wed, May 27, 2020 at 4:49 AM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>
> Hi Rob,
>
> On 5/26/2020 8:42 PM, Rob Herring wrote:
> > On Sun, May 24, 2020 at 9:30 PM Kishon Vijay Abraham I <kishon@ti.com> wrote:
> >>
> >> Hi Rob,
> >>
> >> On 5/22/2020 9:24 PM, Rob Herring wrote:
> >>> On Thu, May 21, 2020 at 9:37 PM Kishon Vijay Abraham I <kishon@ti.com> wrote:
> >>>>
> >>>> Certain platforms like TI's J721E using Cadence PCIe IP can perform only
> >>>> 32-bit accesses for reading or writing to Cadence registers. Convert all
> >>>> read and write accesses to 32-bit in Cadence PCIe driver in preparation
> >>>> for adding PCIe support in TI's J721E SoC.
> >>>
> >>> Looking more closely I don't think cdns_pcie_ep_assert_intx is okay
> >>> with this and never can be given the PCI_COMMAND and PCI_STATUS
> >>> registers are in the same word (IIRC, that's the main reason 32-bit
> >>> config space accesses are broken). So this isn't going to work at
> >>
> >> right, PCI_STATUS has write '1' to clear bits and there's a chance that it
> >> could be reset while raising legacy interrupt. While this cannot be avoided for
> >> TI's J721E, other platforms doesn't have to have this limitation.
> >>> least for EP accesses. And maybe you need a custom .raise_irq() hook
> >>> to minimize any problems (such as making the RMW atomic at least from
> >>> the endpoint's perspective).
> >>
> >> This is to make sure EP doesn't update in-consistent state when RC is updating
> >> the PCI_STATUS register? Since this involves two different systems, how do we
> >> make this atomic?
> >
> > You can't make it atomic WRT both systems, but is there locking around
> > each RMW? Specifically, are preemption and interrupts disabled to
> > ensure time between a read and write are minimized? You wouldn't want
> > interrupts disabled during the delay too though (i.e. around
> > .raise_irq()).
>
> Okay, I'll add spin spin_lock_irqsave() in cdns_pcie_write_sz(). As you also
> pointed below that delay for legacy interrupt is wrong and it has to be fixed
> (with a later series).

But you don't need a lock everywhere. You need locks in the callers
(and only sometimes).

> How do you want to handle cdns_pcie_ep_fn_writew() now? Because now we are
> changing the default implementation to perform only 32-bit access (used for
> legacy interrupt, msi-x interrupt and while writing standard headers) and it's
> not okay only for legacy interrupts for platforms other than TI.

Now I'm wondering how set_msi is not racy in the current code with the
host setting/clearing PCI_MSI_FLAGS_ENABLE? Maybe that bit is RO from
the EP side?

Ultimately I think you're going to have to provide your own endpoint
functions or you need accessors for specific registers like
PCI_MSI_FLAGS. Then for example, you just rely on the 2 bytes before
PCI_MSI_FLAGS being reserved and do a 32-bit access without a RMW.
Trying to abstract this at the register read/write level is going to
be fragile.

Rob

  reply	other threads:[~2020-05-27 16:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-22  3:36 [PATCH v5 00/14] Add PCIe support to TI's J721E SoC Kishon Vijay Abraham I
2020-05-22  3:36 ` [PATCH v5 01/14] PCI: cadence: Fix cdns_pcie_{host|ep}_setup() error path Kishon Vijay Abraham I
2020-05-22  3:36 ` [PATCH v5 02/14] linux/kernel.h: Add PTR_ALIGN_DOWN macro Kishon Vijay Abraham I
2020-05-22  3:36 ` [PATCH v5 03/14] PCI: cadence: Convert all r/w accessors to perform only 32-bit accesses Kishon Vijay Abraham I
2020-05-22 15:54   ` Rob Herring
2020-05-25  3:30     ` Kishon Vijay Abraham I
2020-05-26 15:12       ` Rob Herring
2020-05-27 10:49         ` Kishon Vijay Abraham I
2020-05-27 16:37           ` Rob Herring [this message]
2020-05-27 22:06             ` Kishon Vijay Abraham I
2020-06-01  1:16               ` Kishon Vijay Abraham I
2020-06-08 15:58                 ` Kishon Vijay Abraham I
2020-05-22  3:36 ` [PATCH v5 04/14] PCI: cadence: Add support to start link and verify link status Kishon Vijay Abraham I
2020-05-22  3:36 ` [PATCH v5 05/14] PCI: cadence: Allow pci_host_bridge to have custom pci_ops Kishon Vijay Abraham I
2020-05-22  3:36 ` [PATCH v5 06/14] dt-bindings: PCI: cadence: Remove "mem" from reg binding Kishon Vijay Abraham I
2020-05-26 22:53   ` Rob Herring
2020-05-22  3:36 ` [PATCH v5 07/14] PCI: cadence: Add new *ops* for CPU addr fixup Kishon Vijay Abraham I
2020-05-22  3:36 ` [PATCH v5 08/14] PCI: cadence: Fix updating Vendor ID and Subsystem Vendor ID register Kishon Vijay Abraham I
2020-05-22  3:36 ` [PATCH v5 09/14] PCI: cadence: Add MSI-X support to Endpoint driver Kishon Vijay Abraham I
2020-05-22  3:36 ` [PATCH v5 10/14] dt-bindings: PCI: Add host mode dt-bindings for TI's J721E SoC Kishon Vijay Abraham I
2020-05-22  3:36 ` [PATCH v5 11/14] dt-bindings: PCI: Add EP " Kishon Vijay Abraham I
2020-05-22  3:36 ` [PATCH v5 12/14] PCI: j721e: Add TI J721E PCIe driver Kishon Vijay Abraham I
2020-05-22  3:36 ` [PATCH v5 13/14] misc: pci_endpoint_test: Add J721E in pci_device_id table Kishon Vijay Abraham I
2020-05-22  3:36 ` [PATCH v5 14/14] MAINTAINERS: Add Kishon Vijay Abraham I for TI J721E SoC PCIe Kishon Vijay Abraham I

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='CAL_JsqJMZxOFw-kn5_9bNTPzJuwHybJAi6iQyBq=6BrKSvfTqA@mail.gmail.com' \
    --to=robh@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kishon@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=tjoseph@cadence.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).