linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: xxm <xxm@rock-chips.com>
To: Leon Romanovsky <leon@kernel.org>, Robin Murphy <robin.murphy@arm.com>
Cc: devicetree@vger.kernel.org,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Heiko Stuebner <heiko@sntech.de>,
	linux-pci@vger.kernel.org, Shawn Lin <shawn.lin@rock-chips.com>,
	linux-rockchip@lists.infradead.org, robh+dt@kernel.org,
	Bjorn Helgaas <bhelgaas@google.com>,
	Johan Jonker <jbx6244@gmail.com>
Subject: Re: [PATCH v3 2/2] PCI: rockchip: add DesignWare based PCIe controller
Date: Tue, 26 Jan 2021 10:34:16 +0800	[thread overview]
Message-ID: <79885f84-5c89-b21a-b0e1-dcb870736b05@rock-chips.com> (raw)
In-Reply-To: <20210125184541.GJ579511@unreal>

Hi Leon,

Thanks for your reply.

在 2021/1/26 2:45, Leon Romanovsky 写道:
> On Mon, Jan 25, 2021 at 03:53:38PM +0000, Robin Murphy wrote:
>> On 2021-01-25 09:01, Leon Romanovsky wrote:
>>> On Mon, Jan 25, 2021 at 02:40:10PM +0800, xxm wrote:
>>>> Hi Leon,
>>>>
>>>> Thanks for your reply.
>>>>
>>>> 在 2021/1/25 13:48, Leon Romanovsky 写道:
>>>>> On Mon, Jan 25, 2021 at 10:49:27AM +0800, Simon Xue wrote:
>>>>>> pcie-dw-rockchip is based on DWC IP. But pcie-rockchip-host
>>>>>> is Rockchip designed IP which is only used for RK3399. So all the following
>>>>>> non-RK3399 SoCs should use this driver.
>>>>>>
>>>>>> Signed-off-by: Simon Xue <xxm@rock-chips.com>
>>>>>> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>>>>>> ---
>>>>>>     drivers/pci/controller/dwc/Kconfig            |   9 +
>>>>>>     drivers/pci/controller/dwc/Makefile           |   1 +
>>>>>>     drivers/pci/controller/dwc/pcie-dw-rockchip.c | 286 ++++++++++++++++++
>>>>>>     3 files changed, 296 insertions(+)
>>>>>>     create mode 100644 drivers/pci/controller/dwc/pcie-dw-rockchip.c
>>>>>>
>>>>>> diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
>>>>>> index 22c5529e9a65..aee408fe9283 100644
>>>>>> --- a/drivers/pci/controller/dwc/Kconfig
>>>>>> +++ b/drivers/pci/controller/dwc/Kconfig
>>>>>> @@ -214,6 +214,15 @@ config PCIE_ARTPEC6_EP
>>>>>>     	  Enables support for the PCIe controller in the ARTPEC-6 SoC to work in
>>>>>>     	  endpoint mode. This uses the DesignWare core.
>>>>>>
>>>>>> +config PCIE_ROCKCHIP_DW_HOST
>>>>>> +	bool "Rockchip DesignWare PCIe controller"
>>>>>> +	select PCIE_DW
>>>>>> +	select PCIE_DW_HOST
>>>>>> +	depends on ARCH_ROCKCHIP || COMPILE_TEST
>>>>>> +	depends on OF
>>>>>> +	help
>>>>>> +	  Enables support for the DW PCIe controller in the Rockchip SoC.
>>>>>> +
>>>>>>     config PCIE_INTEL_GW
>>>>>>     	bool "Intel Gateway PCIe host controller support"
>>>>>>     	depends on OF && (X86 || COMPILE_TEST)
>>>>>> diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
>>>>>> index a751553fa0db..30eef8e9ee8a 100644
>>>>>> --- a/drivers/pci/controller/dwc/Makefile
>>>>>> +++ b/drivers/pci/controller/dwc/Makefile
>>>>>> @@ -13,6 +13,7 @@ obj-$(CONFIG_PCI_LAYERSCAPE_EP) += pci-layerscape-ep.o
>>>>>>     obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
>>>>>>     obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
>>>>>>     obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
>>>>>> +obj-$(CONFIG_PCIE_ROCKCHIP_DW_HOST) += pcie-dw-rockchip.o
>>>>>>     obj-$(CONFIG_PCIE_INTEL_GW) += pcie-intel-gw.o
>>>>>>     obj-$(CONFIG_PCIE_KIRIN) += pcie-kirin.o
>>>>>>     obj-$(CONFIG_PCIE_HISI_STB) += pcie-histb.o
>>>>>> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>>>>>> new file mode 100644
>>>>>> index 000000000000..07f6d1cd5853
>>>>>> --- /dev/null
>>>>>> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>>>>>> @@ -0,0 +1,286 @@
>>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>>> +/*
>>>>>> + * PCIe host controller driver for Rockchip SoCs
>>>>>> + *
>>>>>> + * Copyright (C) 2021 Rockchip Electronics Co., Ltd.
>>>>>> + *		http://www.rock-chips.com
>>>>>> + *
>>>>>> + * Author: Simon Xue <xxm@rock-chips.com>
>>>>>> + */
>>>>>> +
>>>>>> +#include <linux/clk.h>
>>>>>> +#include <linux/gpio/consumer.h>
>>>>>> +#include <linux/mfd/syscon.h>
>>>>>> +#include <linux/module.h>
>>>>>> +#include <linux/of_device.h>
>>>>>> +#include <linux/phy/phy.h>
>>>>>> +#include <linux/platform_device.h>
>>>>>> +#include <linux/regmap.h>
>>>>>> +#include <linux/reset.h>
>>>>>> +
>>>>>> +#include "pcie-designware.h"
>>>>>> +
>>>>>> +/*
>>>>>> + * The upper 16 bits of PCIE_CLIENT_CONFIG are a write
>>>>>> + * mask for the lower 16 bits.  This allows atomic updates
>>>>>> + * of the register without locking.
>>>>>> + */
>>>>> This is correct only for the variables that naturally aligned, I imagine
>>>>> that this is the case here and in the Linux, but better do not write comments
>>>>> in the code that are not accurate.
>>>> Ok, will remove.
>>>> I wonder what it would be when outside the Linux? Could you share some information?
>>> The C standard says nothing about atomicity, integer assignment maybe atomic,
>>> maybe it isn’t. There is no guarantee, plain integer assignment in C is non-atomic
>>> by definition.
>>>
>>> The atomicity of u32 is very dependent on hardware vendor, memory model and compiler,
>>> for example x86 and ARMs guarantee atomicity for u32. This is why I said that probably
>>> here (Linux) it is ok and you are not alone in expecting lockless write.
>> Huh? What do variables and the abstract machine of the C language
>> environment have to do with the definition of *hardware MMIO registers*? We
>> don't write to registers with plain integer assignment of u32, we use
>> writel() (precisely in order to bypass that abstract C environment).
>>
>> I appreciate that the comment is not universally true if taken completely
>> out of context, but I that's true of pretty much all comments ever. If
>> someone really were trying to learn basic programming principles from random
>> comments in Linux drivers, then it's already a bit late for us to try and
>> save them from themselves.
> So what? Does it mean that new code should have comments that are not
> correct? As you can see from this conversation, even the author didn't
> know what u32 isn’t guaranteed to be atomic, so yes, the comments should
> be correct.

What I do know is writel() will do the right things(like mem barrier, 
atomic...) to update the registers correctly

in "ARM + Linux" platform. But I have no idear if out of  this specific 
platform, so I asked for more information to learn.

Anyway, I will keep the first part of comment to illustrate how to use 
PCIE_CLIENT_REGISTER, and remove the "atomic" part.

> Thanks
>
>



  reply	other threads:[~2021-01-26  5:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-25  2:48 [PATCH v3 1/2] dt-bindings: rockchip: Add DesignWare based PCIe controller Simon Xue
2021-01-25  2:49 ` [PATCH v3 2/2] PCI: rockchip: add " Simon Xue
2021-01-25  5:48   ` Leon Romanovsky
2021-01-25  6:40     ` xxm
2021-01-25  9:01       ` Leon Romanovsky
2021-01-25 15:53         ` Robin Murphy
2021-01-25 18:45           ` Leon Romanovsky
2021-01-26  2:34             ` xxm [this message]
2021-01-26 14:52         ` Rob Herring
2021-01-26 15:25           ` Leon Romanovsky
2021-01-25 14:51 ` [PATCH v3 1/2] dt-bindings: rockchip: Add " Rob Herring
2021-01-25 15:26 ` Rob Herring
2021-01-26  2:44   ` [PATCH v3 1/2] dt-bindings: rockchip: Add DesignWare based PCIe controller【请注意,邮件由robherring2@gmail.com代发】 xxm
2021-01-26 14:48     ` Rob Herring
2021-01-25 15:55 ` [PATCH v3 1/2] dt-bindings: rockchip: Add DesignWare based PCIe controller Johan Jonker

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=79885f84-5c89-b21a-b0e1-dcb870736b05@rock-chips.com \
    --to=xxm@rock-chips.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=jbx6244@gmail.com \
    --cc=leon@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=shawn.lin@rock-chips.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).