All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Anand <pratyush.anand@gmail.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Stanimir Varbanov <stanimir.varbanov@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Jingoo Han <jingoohan1@gmail.com>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Rob Herring <robh+dt@kernel.org>, Rob Herring <robh@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Bjorn Andersson <bjorn.andersson@sonymobile.com>
Subject: Re: [PATCH v4 1/5] PCI: designware: add memory barrier after enabling region
Date: Fri, 11 Dec 2015 09:35:10 +0530	[thread overview]
Message-ID: <CAHM4w1m-NiwyCLz9tikbOcNtCmVu0Vd9FhmKKSuMi5ChzfDafA@mail.gmail.com> (raw)
In-Reply-To: <20151209102359.GF8644@n2100.arm.linux.org.uk>

On Wed, Dec 9, 2015 at 3:53 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

[...]

>> > >       dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
>> > > +     /*
>> > > +      * ensure that the ATU enable has been happaned before accessing
>> > > +      * pci configuration/io spaces through dw_pcie_cfg_[read|write].
>> > > +      */
>> > > +     wmb();
>> > >  }
>> > >
>>
>>
>> My understnading is that since writel() of dw_pcie_writel_rc() in
>> above code and readl(), writel() of dw_pcie_cfg_[read|write]() (which
>> will follow) goes through same device (ie PCIe host here). So, it is
>> guaranteed that 1st writel() will be executed before later
>> readl()/writel(). If that is true then we do not need any explicit
>> barrier here.
>>
>> Arnd, Russel: whats your opinion here.
>               ^l

Sorry :(

>
> writel() has a barrier _before_ the access but not after.
>
> The fact is that there's nothing which guarantees that the write will hit
> the hardware in a timely manner (forget any rules about PCI config space,
> the PCI ordering rules apply to the PCI bus, not to the ARM buses.)
>
> If you need this write to have hit the hardware before continuing, you
> need to read back from the same register.

OK, so better to replace wmb() with read back of control register.

>
> I'm just looking at this driver, trying to decipher what it's doing.  It
> _looks_ to me like it's reprogramming one of the outbound windows (IO?)
> so that configuration space can be accessed.  Doesn't this have the
> effect of disabling access to the IO segment of the PCI bus from the
> host CPU?
>
> What protections are there against other CPUs in the system issuing a
> PCI I/O read/write while this outbound window is programmed as
> configuration space?


Yes, that is an issue with this driver. Most of the host controller
has 4 or more viewpoints, and it is very easy to handle for them. But
there are few which has only two viewpoints. Do not know how to solve
it, so that it works for all.

~Pratyush

WARNING: multiple messages have this Message-ID (diff)
From: pratyush.anand@gmail.com (Pratyush Anand)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/5] PCI: designware: add memory barrier after enabling region
Date: Fri, 11 Dec 2015 09:35:10 +0530	[thread overview]
Message-ID: <CAHM4w1m-NiwyCLz9tikbOcNtCmVu0Vd9FhmKKSuMi5ChzfDafA@mail.gmail.com> (raw)
In-Reply-To: <20151209102359.GF8644@n2100.arm.linux.org.uk>

On Wed, Dec 9, 2015 at 3:53 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

[...]

>> > >       dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
>> > > +     /*
>> > > +      * ensure that the ATU enable has been happaned before accessing
>> > > +      * pci configuration/io spaces through dw_pcie_cfg_[read|write].
>> > > +      */
>> > > +     wmb();
>> > >  }
>> > >
>>
>>
>> My understnading is that since writel() of dw_pcie_writel_rc() in
>> above code and readl(), writel() of dw_pcie_cfg_[read|write]() (which
>> will follow) goes through same device (ie PCIe host here). So, it is
>> guaranteed that 1st writel() will be executed before later
>> readl()/writel(). If that is true then we do not need any explicit
>> barrier here.
>>
>> Arnd, Russel: whats your opinion here.
>               ^l

Sorry :(

>
> writel() has a barrier _before_ the access but not after.
>
> The fact is that there's nothing which guarantees that the write will hit
> the hardware in a timely manner (forget any rules about PCI config space,
> the PCI ordering rules apply to the PCI bus, not to the ARM buses.)
>
> If you need this write to have hit the hardware before continuing, you
> need to read back from the same register.

OK, so better to replace wmb() with read back of control register.

>
> I'm just looking at this driver, trying to decipher what it's doing.  It
> _looks_ to me like it's reprogramming one of the outbound windows (IO?)
> so that configuration space can be accessed.  Doesn't this have the
> effect of disabling access to the IO segment of the PCI bus from the
> host CPU?
>
> What protections are there against other CPUs in the system issuing a
> PCI I/O read/write while this outbound window is programmed as
> configuration space?


Yes, that is an issue with this driver. Most of the host controller
has 4 or more viewpoints, and it is very easy to handle for them. But
there are few which has only two viewpoints. Do not know how to solve
it, so that it works for all.

~Pratyush

  reply	other threads:[~2015-12-11  4:05 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-03 13:35 [PATCH v4 0/5] Qualcomm PCIe driver and designware fixes Stanimir Varbanov
2015-12-03 13:35 ` Stanimir Varbanov
2015-12-03 13:35 ` [PATCH v4 1/5] PCI: designware: add memory barrier after enabling region Stanimir Varbanov
2015-12-03 13:35   ` Stanimir Varbanov
2015-12-03 13:35   ` Stanimir Varbanov
2015-12-08  9:01   ` Stanimir Varbanov
2015-12-08  9:01     ` Stanimir Varbanov
2015-12-09  4:40     ` Pratyush Anand
2015-12-09  4:40       ` Pratyush Anand
2015-12-09  4:40       ` Pratyush Anand
2015-12-09  9:52       ` Arnd Bergmann
2015-12-09  9:52         ` Arnd Bergmann
2015-12-09  9:52         ` Arnd Bergmann
2015-12-09 10:29         ` Stanimir Varbanov
2015-12-09 10:29           ` Stanimir Varbanov
2015-12-09 10:29           ` Stanimir Varbanov
2015-12-09 10:23       ` Russell King - ARM Linux
2015-12-09 10:23         ` Russell King - ARM Linux
2015-12-09 10:23         ` Russell King - ARM Linux
2015-12-11  4:05         ` Pratyush Anand [this message]
2015-12-11  4:05           ` Pratyush Anand
2015-12-11  4:05           ` Pratyush Anand
2015-12-11  5:48           ` Jisheng Zhang
2015-12-11  5:48             ` Jisheng Zhang
2015-12-11  5:48             ` Jisheng Zhang
2015-12-11  5:48             ` Jisheng Zhang
2015-12-22 12:36             ` Jingoo Han
2015-12-22 12:36               ` Jingoo Han
2015-12-22 12:36               ` Jingoo Han
2015-12-17 15:45           ` Stanimir Varbanov
2015-12-17 15:45             ` Stanimir Varbanov
2015-12-17 15:45             ` Stanimir Varbanov
2015-12-17 15:51             ` Pratyush Anand
2015-12-17 15:51               ` Pratyush Anand
2015-12-17 15:51               ` Pratyush Anand
2015-12-03 13:35 ` [PATCH v4 3/5] PCI: qcom: Add Qualcomm PCIe controller driver Stanimir Varbanov
2015-12-03 13:35   ` Stanimir Varbanov
2015-12-15  8:24   ` Stanimir Varbanov
2015-12-15  8:24     ` Stanimir Varbanov
2015-12-16 21:17     ` Bjorn Helgaas
2015-12-16 21:17       ` Bjorn Helgaas
2015-12-16 21:53   ` Bjorn Helgaas
2015-12-16 21:53     ` Bjorn Helgaas
2015-12-17 13:18     ` Stanimir Varbanov
2015-12-17 13:18       ` Stanimir Varbanov
2015-12-17 21:15       ` Bjorn Helgaas
2015-12-17 21:15         ` Bjorn Helgaas
     [not found] ` <1449149725-27607-1-git-send-email-stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-12-03 13:35   ` [PATCH v4 2/5] DT: PCI: qcom: Document PCIe devicetree bindings Stanimir Varbanov
2015-12-03 13:35     ` Stanimir Varbanov
2015-12-03 13:35     ` Stanimir Varbanov
2015-12-03 20:42     ` Rob Herring
2015-12-03 20:42       ` Rob Herring
2015-12-03 13:35   ` [PATCH v4 4/5] ARM: dts: apq8064: add pcie devicetree node Stanimir Varbanov
2015-12-03 13:35     ` Stanimir Varbanov
2015-12-03 13:35     ` Stanimir Varbanov
2015-12-03 13:35 ` [PATCH v4 5/5] ARM: dts: ifc6410: enable pcie dt node for this board Stanimir Varbanov
2015-12-03 13:35   ` Stanimir Varbanov
     [not found]   ` <1449149725-27607-6-git-send-email-stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-12-17 21:55     ` Bjorn Andersson
2015-12-17 21:55       ` Bjorn Andersson
2015-12-17 21:55       ` Bjorn Andersson
2015-12-17 21:55       ` Bjorn Andersson
2015-12-18  9:57       ` Stanimir Varbanov
2015-12-18  9:57         ` Stanimir Varbanov
2015-12-18  9:57         ` Stanimir Varbanov
2015-12-07 17:33 ` [PATCH v4 0/5] Qualcomm PCIe driver and designware fixes Srinivas Kandagatla
2015-12-07 17:33   ` Srinivas Kandagatla

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=CAHM4w1m-NiwyCLz9tikbOcNtCmVu0Vd9FhmKKSuMi5ChzfDafA@mail.gmail.com \
    --to=pratyush.anand@gmail.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=bjorn.andersson@sonymobile.com \
    --cc=devicetree@vger.kernel.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jingoohan1@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=stanimir.varbanov@linaro.org \
    /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.