All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanimir Varbanov <stanimir.varbanov@linaro.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Stanimir Varbanov <stanimir.varbanov@linaro.org>
Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Arnd Bergmann <arnd@arndb.de>, Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Jingoo Han <jingoohan1@gmail.com>,
	Pratyush Anand <pratyush.anand@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Bjorn Andersson <bjorn.andersson@sonymobile.com>
Subject: Re: [PATCH v3 2/6] PCI: designware: add memory barrier after enabling region
Date: Mon, 23 Nov 2015 18:05:27 +0200	[thread overview]
Message-ID: <56533947.4040206@linaro.org> (raw)
In-Reply-To: <20151123112744.GL8644@n2100.arm.linux.org.uk>

On 11/23/2015 01:27 PM, Russell King - ARM Linux wrote:
> On Mon, Nov 23, 2015 at 11:28:59AM +0200, Stanimir Varbanov wrote:
>> Add 'write memory' barrier after enable region in PCIE_ATU_CR2
>> register. The barrier is needed to ensure that the region enable
>> request has been reached it's destination at time when we
>> read/write to PCI configuration space.
>>
>> Without this barrier PCI device enumeration during kernel boot
>> is not reliable, and reading configuration space for particular
>> PCI device on the bus returns zero aka no device.
>>
>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
>> ---
>>  drivers/pci/host/pcie-designware.c |    5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
>> index 02a7452bdf23..e15a2ae1583f 100644
>> --- a/drivers/pci/host/pcie-designware.c
>> +++ b/drivers/pci/host/pcie-designware.c
>> @@ -164,6 +164,11 @@ static void dw_pcie_prog_outbound_atu(struct pcie_port *pp, int index,
>>  	dw_pcie_writel_rc(pp, upper_32_bits(pci_addr), PCIE_ATU_UPPER_TARGET);
>>  	dw_pcie_writel_rc(pp, type, PCIE_ATU_CR1);
>>  	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].
>> +	 */
>> +	smp_wmb();
> 
> So, why is this a SMP barrier?
> 

I wrongly assumed that smp_wmb will come down to wmb(), I have no excuse.

But despite my ignorant, as I noted in cover letter I want this patch to
be treated as an RFC (maybe I had to add it in the subject).

Do we really need a memory barrier after enabling ATU in PCI_ATU_CR2
register and before first access to pci configuration space using
read[lwb] (see dw_pcie_rd_other_conf)? Or I have made totally wrong
assumption.

-- 
regards,
Stan

WARNING: multiple messages have this Message-ID (diff)
From: stanimir.varbanov@linaro.org (Stanimir Varbanov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/6] PCI: designware: add memory barrier after enabling region
Date: Mon, 23 Nov 2015 18:05:27 +0200	[thread overview]
Message-ID: <56533947.4040206@linaro.org> (raw)
In-Reply-To: <20151123112744.GL8644@n2100.arm.linux.org.uk>

On 11/23/2015 01:27 PM, Russell King - ARM Linux wrote:
> On Mon, Nov 23, 2015 at 11:28:59AM +0200, Stanimir Varbanov wrote:
>> Add 'write memory' barrier after enable region in PCIE_ATU_CR2
>> register. The barrier is needed to ensure that the region enable
>> request has been reached it's destination at time when we
>> read/write to PCI configuration space.
>>
>> Without this barrier PCI device enumeration during kernel boot
>> is not reliable, and reading configuration space for particular
>> PCI device on the bus returns zero aka no device.
>>
>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
>> ---
>>  drivers/pci/host/pcie-designware.c |    5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
>> index 02a7452bdf23..e15a2ae1583f 100644
>> --- a/drivers/pci/host/pcie-designware.c
>> +++ b/drivers/pci/host/pcie-designware.c
>> @@ -164,6 +164,11 @@ static void dw_pcie_prog_outbound_atu(struct pcie_port *pp, int index,
>>  	dw_pcie_writel_rc(pp, upper_32_bits(pci_addr), PCIE_ATU_UPPER_TARGET);
>>  	dw_pcie_writel_rc(pp, type, PCIE_ATU_CR1);
>>  	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].
>> +	 */
>> +	smp_wmb();
> 
> So, why is this a SMP barrier?
> 

I wrongly assumed that smp_wmb will come down to wmb(), I have no excuse.

But despite my ignorant, as I noted in cover letter I want this patch to
be treated as an RFC (maybe I had to add it in the subject).

Do we really need a memory barrier after enabling ATU in PCI_ATU_CR2
register and before first access to pci configuration space using
read[lwb] (see dw_pcie_rd_other_conf)? Or I have made totally wrong
assumption.

-- 
regards,
Stan

  reply	other threads:[~2015-11-23 16:05 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-23  9:28 [PATCH v3 0/6] Qualcomm PCIe driver and designware fixes Stanimir Varbanov
2015-11-23  9:28 ` Stanimir Varbanov
2015-11-23  9:28 ` Stanimir Varbanov
2015-11-23  9:28 ` [PATCH v3 1/6] PCI: designware: remove wrong io_base assignment Stanimir Varbanov
2015-11-23  9:28   ` Stanimir Varbanov
     [not found]   ` <44d133d5ebd4f7b9e8b817aa8bae12f690e70000.1448270813.git.stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-11-23  9:59     ` Arnd Bergmann
2015-11-23  9:59       ` Arnd Bergmann
2015-11-23  9:59       ` Arnd Bergmann
2015-11-23 10:27       ` Gabriele Paoloni
2015-11-23 10:27         ` Gabriele Paoloni
2015-11-23 16:23         ` Stanimir Varbanov
2015-11-23 16:23           ` Stanimir Varbanov
2015-11-23 16:40           ` Arnd Bergmann
2015-11-23 16:40             ` Arnd Bergmann
2015-11-24  9:25             ` Stanimir Varbanov
2015-11-24  9:25               ` Stanimir Varbanov
2015-11-23  9:28 ` [PATCH v3 2/6] PCI: designware: add memory barrier after enabling region Stanimir Varbanov
2015-11-23  9:28   ` Stanimir Varbanov
2015-11-23 11:27   ` Russell King - ARM Linux
2015-11-23 11:27     ` Russell King - ARM Linux
2015-11-23 16:05     ` Stanimir Varbanov [this message]
2015-11-23 16:05       ` Stanimir Varbanov
2015-11-23  9:29 ` [PATCH v3 3/6] DT: PCI: qcom: Document PCIe devicetree bindings Stanimir Varbanov
2015-11-23  9:29   ` Stanimir Varbanov
2015-11-23  9:29   ` Stanimir Varbanov
2015-11-23 18:13   ` Bjorn Andersson
2015-11-23 18:13     ` Bjorn Andersson
2015-11-24  9:17     ` Stanimir Varbanov
2015-11-24  9:17       ` Stanimir Varbanov
2015-11-23 23:17   ` Rob Herring
2015-11-23 23:17     ` Rob Herring
2015-11-24  9:22     ` Stanimir Varbanov
2015-11-24  9:22       ` Stanimir Varbanov
2015-11-24  9:22       ` Stanimir Varbanov
2015-11-23  9:29 ` [PATCH v3 4/6] PCI: qcom: Add Qualcomm PCIe controller driver Stanimir Varbanov
2015-11-23  9:29   ` Stanimir Varbanov
2015-11-23  9:29   ` Stanimir Varbanov
2015-11-23 11:02   ` kbuild test robot
2015-11-23 11:02     ` kbuild test robot
2015-11-23 11:02     ` kbuild test robot
2015-11-23  9:29 ` [PATCH v3 5/6] ARM: dts: apq8064: add pcie devicetree node Stanimir Varbanov
2015-11-23  9:29   ` Stanimir Varbanov
2015-11-23  9:29   ` Stanimir Varbanov
2015-11-23  9:29 ` [PATCH v3 6/6] ARM: dts: ifc6410: enable pcie dt node for this board Stanimir Varbanov
2015-11-23  9:29   ` Stanimir Varbanov

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=56533947.4040206@linaro.org \
    --to=stanimir.varbanov@linaro.org \
    --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=pratyush.anand@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=srinivas.kandagatla@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.