RE: [PATCH v7 2/5] PCI: dwc: add support to handle ZRX-DC Compliant PHYs

[Pankaj Dubey]

> -Original Message-

> Subject: Re: [PATCH v7 2/5] PCI: dwc: add support to handle ZRX-DC
> Compliant PHYs
> 
> Capitalize subject to match the rest of the series.
> 
> "Add support to handle .." is redundant; "Add support for ..." would be
> equivalent and shorter.

OK 

> 
> But this patch actually doesn't add anything at all by itself, since it
checks pci-
> >phy_zrxdc_compliant but never sets it.

OK, we will reword the commit message as  "configure controller to handle
ZRX-DC compliant PHYs"

> 
> On Thu, Jan 07, 2021 at 08:58:40PM +0530, Shradha Todi wrote:
> > From: Pankaj Dubey 
> >
> > Many platforms use DesignWare controller but the PHY can be different
> > in different platforms. If the PHY is compliant is to ZRX-DC
> > specification it helps in low power consumption during power states.
> 
> s/is to/to/

OK

> 
> Even with that, this sentence doesn't quite parse correctly.  Do you mean
> something like this?
> 
>   If the PHY is compliant to the ZRX-DC specification, it reduces
>   power consumption in low power Link states.
> 
> (I assume this is related to Link power states (L0, L1, etc), not device
power
> states (D0, D3hot, etc)).
> 

Yes, we are talking about Link power states. We rephrase the commit
description to make it more clear.

> > If current data rate is 8.0 GT/s or higher and PHY is not compliant to
> > ZRX-DC specification, then after every 100ms link should transition to
> > recovery state during the low power states.
> 
> Not sure this makes sense.  If the Link is in a low power state for 10
seconds,
> it must transition to the Recovery state every 100ms during that 10
seconds,
> i.e., 100 times?
> 

According to SNPS DesignWare data-book, the link will transition into
recovery state every 100ms, which means that yes, 100 times in 10 seconds.
But what we are trying to say here is that if the PHY is ZRX-DC compliant,
then the controller does not need to do this and we can thus save power
consumption.

As per the DesignWare data-book, the controller keeps this bit set to '1' by
default ("This bit enables a 100ms timer which can trigger exit from L1.")
and we are trying to reset this bit to '0' in order to not perform the
constant recovery and hence save power.

> > DesignWare controller provides GEN3_ZRXDC_NONCOMPL field in
> > GEN3_RELATED_OFF to specify about ZRX-DC compliant PHY.
> >
> > Platforms with ZRX-DC compliant PHY can set phy_zrxdc_compliant
> > variable to specify this property to the controller.
> 
> If this is a DesignWare-generic register and the "phy-zrxdc-compliant"
> property can be used by any DesignWare-based driver, why isn't the code to
> look for it in the DesignWare-generic part?
> 

Do you mean why this property is part of PHY node instead of DesignWare
controller?

> Is there a link to the ZRX-DC specification you can mention somewhere in
this
> series?
> 

I don't know if there is any separate ZRX-DC specification exists which can
be pointed out here, but we have implementation note in PCIe specification
Rev 4.0 which says as:
"Ports that meet the ZRX-DC specification for 2.5 GT/s while in the L1.Idle
state and are therefore not required to implement the 100 ms timeout and
transition to Recovery should avoid implementing it, since it will reduce
the power savings expected from the L1 state." 

We have captured same in cover-letter of this patch series.

> > Signed-off-by: Anvesh Salveru 
> > Signed-off-by: Pankaj Dubey 
> > Signed-off-by: Shradha Todi 
> > Cc: Jingoo Han 
> > Cc: Gustavo Pimentel 
> > Cc: Lorenzo Pieralisi 
> > Cc: Rob Herring 
> > Cc: Bjorn Helgaas 
> > ---
> >  drivers/pci/controller/dwc/pcie-designware.c | 6 ++
> > drivers/pci/controller/dwc/pcie-designware.h | 4 
> >  2 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index 645fa18..74590c7 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -722,4 +722,10 @@ void dw_pcie_setup(struct dw_pcie *pci)
> >PCIE_PL_CHK_REG_CHK_REG_START;
> > dw_pcie_writel_dbi(pci,
> PCIE_PL_CHK_REG_CONTROL_STATUS, val);
> > }
> > +
> > +   if (pci->phy_zrxdc_compliant) {
> > +   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
> > +   val &= ~PORT_LOGIC_GEN3_ZRXDC_NONCOMPL;
> > +   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
> > +   }
> >  }
> > diff --git a/drivers/pci/controller/dwc/pcie-desi

RE: [PATCH v2] PCI: dwc: Add upper limit address for outbound iATU

[Pankaj Dubey]

> -Original Message-
> From: Shradha Todi 
> Sent: Wednesday, January 6, 2021 4:20 PM
> To: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Cc: jingooh...@gmail.com; gustavo.pimen...@synopsys.com;
> r...@kernel.org; lorenzo.pieral...@arm.com; bhelg...@google.com;
> pankaj.du...@samsung.com; sriram.d...@samsung.com;
> niyas.ah...@samsung.com; p.rajanb...@samsung.com;
> l.me...@samsung.com; hari...@samsung.com; Shradha Todi
> 
> Subject: [PATCH v2] PCI: dwc: Add upper limit address for outbound iATU
> 
> The size parameter is unsigned long type which can accept size > 4GB. In that
> case, the upper limit address must be programmed. Add support to program
> the upper limit address and set INCREASE_REGION_SIZE in case size > 4GB.
> 
> Signed-off-by: Shradha Todi 
> ---
> v1: https://lkml.org/lkml/2020/12/20/187
> v2:
>Addressed Rob's review comment and added PCI version check condition
> to
>avoid writing to reserved registers.
> 

Reviewed-by: Pankaj Dubey 

>  drivers/pci/controller/dwc/pcie-designware.c | 9 +++--
> drivers/pci/controller/dwc/pcie-designware.h | 1 +
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> b/drivers/pci/controller/dwc/pcie-designware.c
> index 74590c7..1d62ca9 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -290,12 +290,17 @@ static void __dw_pcie_prog_outbound_atu(struct
> dw_pcie *pci, u8 func_no,
>  upper_32_bits(cpu_addr));
>   dw_pcie_writel_dbi(pci, PCIE_ATU_LIMIT,
>  lower_32_bits(cpu_addr + size - 1));
> + if (pci->version >= 0x460A)
> + dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_LIMIT,
> +upper_32_bits(cpu_addr + size - 1));
>   dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_TARGET,
>  lower_32_bits(pci_addr));
>   dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_TARGET,
>  upper_32_bits(pci_addr));
> - dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, type |
> -PCIE_ATU_FUNC_NUM(func_no));
> + val = type | PCIE_ATU_FUNC_NUM(func_no);
> + val = ((upper_32_bits(size - 1)) && (pci->version >= 0x460A)) ?
> + val | PCIE_ATU_INCREASE_REGION_SIZE : val;
> + dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, val);
>   dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE);
> 
>   /*
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> b/drivers/pci/controller/dwc/pcie-designware.h
> index 8b905a2..7da79eb 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -102,6 +102,7 @@
>  #define PCIE_ATU_DEV(x)  FIELD_PREP(GENMASK(23,
> 19), x)
>  #define PCIE_ATU_FUNC(x) FIELD_PREP(GENMASK(18, 16), x)
>  #define PCIE_ATU_UPPER_TARGET0x91C
> +#define PCIE_ATU_UPPER_LIMIT 0x924
> 
>  #define PCIE_MISC_CONTROL_1_OFF  0x8BC
>  #define PCIE_DBI_RO_WR_ENBIT(0)
> --
> 2.7.4

RE: [PATCH v2] PCI: dwc: Change size to u64 for EP outbound iATU

[Pankaj Dubey]

> -Original Message-
> From: Shradha Todi 
> Sent: Wednesday, January 6, 2021 4:15 PM
> To: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Cc: jingooh...@gmail.com; gustavo.pimen...@synopsys.com;
> r...@kernel.org; lorenzo.pieral...@arm.com; bhelg...@google.com;
> pankaj.du...@samsung.com; sriram.d...@samsung.com;
> niyas.ah...@samsung.com; p.rajanb...@samsung.com;
> l.me...@samsung.com; hari...@samsung.com; Shradha Todi
> 
> Subject: [PATCH v2] PCI: dwc: Change size to u64 for EP outbound iATU
> 
> Since outbound iATU permits size to be greater than 4GB for which the
> support is also available, allow EP function to send u64 size instead of
> truncating to u32.
> 
> Signed-off-by: Shradha Todi 
> ---
> v1: https://lkml.org/lkml/2020/12/18/690
> v2:
>Addressed Bjorn's review on to keep commit message length limit to 75
> 

Reviewed-by: Pankaj Dubey 

>  drivers/pci/controller/dwc/pcie-designware.c | 2 +-
> drivers/pci/controller/dwc/pcie-designware.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> b/drivers/pci/controller/dwc/pcie-designware.c
> index 1d62ca9..db407ed 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -326,7 +326,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie
> *pci, int index, int type,
> 
>  void dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int
> index,
> int type, u64 cpu_addr, u64 pci_addr,
> -   u32 size)
> +   u64 size)
>  {
>   __dw_pcie_prog_outbound_atu(pci, func_no, index, type,
>   cpu_addr, pci_addr, size);
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> b/drivers/pci/controller/dwc/pcie-designware.h
> index 7da79eb..359151f 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -302,7 +302,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie
> *pci, int index,
>  u64 size);
>  void dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int
> index,
> int type, u64 cpu_addr, u64 pci_addr,
> -   u32 size);
> +   u64 size);
>  int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, u8 func_no, int index,
>int bar, u64 cpu_addr,
>enum dw_pcie_as_type as_type);
> --
> 2.7.4

RE: [PATCH v2 4/4] soc: samsung: exynos-chipid: convert to driver and merge exynos-asv

[Pankaj Dubey]

> -Original Message-
> From: Krzysztof Kozlowski 
> Sent: Tuesday, December 8, 2020 12:35 AM
> To: Krzysztof Kozlowski ; linux-arm-
> ker...@lists.infradead.org; linux-samsung-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Sylwester Nawrocki ; Marek Szyprowski
> ; Bartlomiej Zolnierkiewicz
> ; Arnd Bergmann ; Chanwoo
> Choi ; Alim Akhtar ;
> Pankaj Dubey 
> Subject: [PATCH v2 4/4] soc: samsung: exynos-chipid: convert to driver and
> merge exynos-asv
> 
> The Exynos Chip ID driver on Exynos SoCs has so far only informational
> purpose - to expose the SoC device in sysfs.  No other drivers depend on
it
> so there is really no benefit of initializing it early.
> 

One of the intention behind initializing Exynos Chip ID driver in early
stage was to simplify code in arch/arm/mach-exynos specifically calls such
as soc_is_exynos. 
But there were lot of resistance from community to add any such calls (or
exported function) from mach-exynos files to the driver file. Whereas some
other SoC code is using the same, e.g. tegra_get_chip_id being called from
mach-tegra files to drivers/soc/tegra/. Unfortunately we could not accept
similar solution for Exynos SoC and hence could not get rid of
soc_is_exynosxXXX and similar macros from various file in mach-exynos and
eventually converting those files into a full-fledged driver files. 

Any opinion how can we achieve this if we convert Exynos Chip ID driver to a
regular driver?

Thanks,
Pankaj Dubey

> The code would be the most flexible if converted to a regular driver.
> However there is already another driver - Exynos ASV (Adaptive Supply
> Voltage) - which binds to the device node of Chip ID.
> 
> The solution is to convert the Exynos Chip ID to a built in driver and
merge
> the Exynos ASV into it.
> 
> This has several benefits:
> 1. Although the Exynos ASV driver binds to a device node present in all
>Exynos DTS (generic compatible), it fails to probe except on the
>supported ones (only Exynos5422).  This means that the regular boot
>process has a planned/expected device probe failure.
> 
>Merging the ASV into Chip ID will remove this probe failure because
>the final driver will always bind, just with disabled ASV features.
> 
> 2. Allows to use dev_info() as the SoC bus is present (since
>core_initcall).
> 
> 3. Could speed things up because of execution of Chip ID code in a SMP
>environment (after bringing up secondary CPUs, unlike early_initcall),
>This reduces the amount of work to be done early, when the kernel has
>to bring up critical devices.
> 
> 5. Makes the Chip ID code defer-probe friendly,
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm/mach-exynos/Kconfig|  1 -
>  drivers/soc/samsung/Kconfig | 12 ++---
>  drivers/soc/samsung/Makefile|  3 +-
>  drivers/soc/samsung/exynos-asv.c| 45 +
>  drivers/soc/samsung/exynos-asv.h|  2 +
>  drivers/soc/samsung/exynos-chipid.c | 75 -
>  6 files changed, 70 insertions(+), 68 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-
> exynos/Kconfig index 56d272967fc0..5a48abac6af4 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -13,7 +13,6 @@ menuconfig ARCH_EXYNOS
>   select ARM_GIC
>   select EXYNOS_IRQ_COMBINER
>   select COMMON_CLK_SAMSUNG
> - select EXYNOS_ASV
>   select EXYNOS_CHIPID
>   select EXYNOS_THERMAL
>   select EXYNOS_PMU
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> index fc7f48a92288..5745d7e5908e 100644
> --- a/drivers/soc/samsung/Kconfig
> +++ b/drivers/soc/samsung/Kconfig
> @@ -7,21 +7,19 @@ menuconfig SOC_SAMSUNG
> 
>  if SOC_SAMSUNG
> 
> -config EXYNOS_ASV
> - bool "Exynos Adaptive Supply Voltage support" if COMPILE_TEST
> - depends on (ARCH_EXYNOS && EXYNOS_CHIPID) || COMPILE_TEST
> - select EXYNOS_ASV_ARM if ARM && ARCH_EXYNOS
> -
>  # There is no need to enable these drivers for ARMv8  config
> EXYNOS_ASV_ARM
>   bool "Exynos ASV ARMv7-specific driver extensions" if
> COMPILE_TEST
> - depends on EXYNOS_ASV
> + depends on EXYNOS_CHIPID
> 
>  config EXYNOS_CHIPID
> - bool "Exynos Chipid controller driver" if COMPILE_TEST
> + bool "Exynos ChipID controller and ASV driver" if COMPILE_TEST
>   depends on ARCH_EXYNOS || COMPILE_TEST
> + select EXYNOS_ASV_ARM if ARM && ARCH_EXYNOS
>   select MFD_SYSCON
>   select SOC_BUS
> + help
> +   Support for Samsung Exynos SoC ChipID and Adaptive Supply
> Voltage.
> 
>  config EXYNOS_PMU
>  

RE: [PATCH v2 3/4] soc: samsung: exynos-chipid: order list of SoCs by name

[Pankaj Dubey]

> -Original Message-
> From: Krzysztof Kozlowski 
> Sent: Tuesday, December 8, 2020 12:35 AM
> To: Krzysztof Kozlowski ; linux-arm-
> ker...@lists.infradead.org; linux-samsung-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Sylwester Nawrocki ; Marek Szyprowski
> ; Bartlomiej Zolnierkiewicz
> ; Arnd Bergmann ; Chanwoo
> Choi ; Alim Akhtar ;
> Pankaj Dubey 
> Subject: [PATCH v2 3/4] soc: samsung: exynos-chipid: order list of SoCs by
> name
> 
> Bring some order to the list of SoCs.  No functional change.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/soc/samsung/exynos-chipid.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/samsung/exynos-chipid.c
> b/drivers/soc/samsung/exynos-chipid.c
> index 8d4d05086906..b4cd0cc00f45 100644
> --- a/drivers/soc/samsung/exynos-chipid.c
> +++ b/drivers/soc/samsung/exynos-chipid.c
> @@ -20,6 +20,7 @@ static const struct exynos_soc_id {
>   const char *name;
>   unsigned int id;
>  } soc_ids[] = {
> + /* List ordered by SoC name */
>   { "EXYNOS3250", 0xE3472000 },
>   { "EXYNOS4210", 0x4320 },   /* EVT0 revision */
>   { "EXYNOS4210", 0x4321 },
> @@ -29,10 +30,10 @@ static const struct exynos_soc_id {
>   { "EXYNOS5260", 0xE526 },
>   { "EXYNOS5410", 0xE541 },
>   { "EXYNOS5420", 0xE542 },
> + { "EXYNOS5433", 0xE5433000 },
>   { "EXYNOS5440", 0xE544 },
>   { "EXYNOS5800", 0xE5422000 },
>   { "EXYNOS7420", 0xE742 },
> - { "EXYNOS5433", 0xE5433000 },
>  };
> 
>  static const char * __init product_id_to_soc_id(unsigned int product_id)
> --
> 2.25.1

Reviewed-by: Pankaj Dubey 

RE: [PATCH v2 2/4] soc: samsung: exynos-asv: handle reading revision register error

[Pankaj Dubey]

> -Original Message-
> From: Krzysztof Kozlowski 
> Sent: Tuesday, December 8, 2020 12:35 AM
> To: Krzysztof Kozlowski ; linux-arm-
> ker...@lists.infradead.org; linux-samsung-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Sylwester Nawrocki ; Marek Szyprowski
> ; Bartlomiej Zolnierkiewicz
> ; Arnd Bergmann ; Chanwoo
> Choi ; Alim Akhtar ;
> Pankaj Dubey ; sta...@vger.kernel.org
> Subject: [PATCH v2 2/4] soc: samsung: exynos-asv: handle reading revision
> register error
> 
> If regmap_read() fails, the product_id local variable will contain random
value
> from the stack.  Do not try to parse such value and fail the ASV driver
probe.
> 
> Fixes: 5ea428595cc5 ("soc: samsung: Add Exynos Adaptive Supply Voltage
> driver")
> Cc: 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/soc/samsung/exynos-asv.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/samsung/exynos-asv.c
> b/drivers/soc/samsung/exynos-asv.c
> index f653e3533f0f..5daeadc36382 100644
> --- a/drivers/soc/samsung/exynos-asv.c
> +++ b/drivers/soc/samsung/exynos-asv.c
> @@ -129,7 +129,13 @@ static int exynos_asv_probe(struct platform_device
> *pdev)
>   return PTR_ERR(asv->chipid_regmap);
>   }
> 
> - regmap_read(asv->chipid_regmap, EXYNOS_CHIPID_REG_PRO_ID,
> _id);
> + ret = regmap_read(asv->chipid_regmap,
> EXYNOS_CHIPID_REG_PRO_ID,
> +   _id);
> + if (ret < 0) {
> + dev_err(>dev, "Cannot read revision from
> ChipID: %d\n",
> +         ret);
> + return -ENODEV;
> + }
> 
>   switch (product_id & EXYNOS_MASK) {
>   case 0xE5422000:
> --
> 2.25.1

Reviewed-by: Pankaj Dubey 

RE: [PATCH v2 1/4] soc: samsung: exynos-asv: don't defer early on not-supported SoCs

[Pankaj Dubey]

> -Original Message-
> From: Krzysztof Kozlowski 
> Sent: Tuesday, December 8, 2020 12:35 AM
> To: Krzysztof Kozlowski ; linux-arm-
> ker...@lists.infradead.org; linux-samsung-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Sylwester Nawrocki ; Marek Szyprowski
> ; Bartlomiej Zolnierkiewicz
> ; Arnd Bergmann ; Chanwoo
> Choi ; Alim Akhtar ;
> Pankaj Dubey ; sta...@vger.kernel.org
> Subject: [PATCH v2 1/4] soc: samsung: exynos-asv: don't defer early on
not-
> supported SoCs
> 
> From: Marek Szyprowski 
> 
> Check if the SoC is really supported before gathering the needed
resources.
> This fixes endless deferred probe on some SoCs other than
> Exynos5422 (like Exynos5410).
> 
> Fixes: 5ea428595cc5 ("soc: samsung: Add Exynos Adaptive Supply Voltage
> driver")
> Cc: 
> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/soc/samsung/exynos-asv.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/soc/samsung/exynos-asv.c
> b/drivers/soc/samsung/exynos-asv.c
> index 8abf4dfaa5c5..f653e3533f0f 100644
> --- a/drivers/soc/samsung/exynos-asv.c
> +++ b/drivers/soc/samsung/exynos-asv.c
> @@ -119,11 +119,6 @@ static int exynos_asv_probe(struct platform_device
> *pdev)
>   u32 product_id = 0;
>   int ret, i;
> 
> - cpu_dev = get_cpu_device(0);
> - ret = dev_pm_opp_get_opp_count(cpu_dev);
> - if (ret < 0)
> - return -EPROBE_DEFER;
> -
>   asv = devm_kzalloc(>dev, sizeof(*asv), GFP_KERNEL);
>   if (!asv)
>   return -ENOMEM;
> @@ -144,6 +139,11 @@ static int exynos_asv_probe(struct platform_device
> *pdev)
>   return -ENODEV;
>   }
> 
> + cpu_dev = get_cpu_device(0);
> + ret = dev_pm_opp_get_opp_count(cpu_dev);
> + if (ret < 0)
> + return -EPROBE_DEFER;
> +
>   ret = of_property_read_u32(pdev->dev.of_node, "samsung,asv-
> bin",
>  >of_bin);
>   if (ret < 0)
> --
> 2.25.1

Reviewed-by: Pankaj Dubey 

RE: [PATCH 1/2] dt-bindings: PCI: designware: Add binding for ZRX-DC PHY property

[Pankaj Dubey]

> -Original Message-
> From: Andrew Murray 
> Sent: Monday, October 21, 2019 7:46 PM
> To: Anvesh Salveru 
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; bhelg...@google.com;
> gustavo.pimen...@synopsys.com; jingooh...@gmail.com; robh...@kernel.org;
> mark.rutl...@arm.com; Pankaj Dubey 
> Subject: Re: [PATCH 1/2] dt-bindings: PCI: designware: Add binding for
ZRX-DC
> PHY property
> 
> On Mon, Oct 21, 2019 at 05:55:55PM +0530, Anvesh Salveru wrote:
> > Add support for ZRX-DC compliant PHYs. If PHY is not compliant to
> > ZRX-DC specification, then after every 100ms link should transition to
> > recovery state during the low power states which increases power
> consumption.
> >
> > Platforms with ZRX-DC compliant PHY can use "snps,phy-zrxdc-compliant"
> > property in DesignWare controller DT node.
> >
> > Signed-off-by: Anvesh Salveru 
> > Signed-off-by: Pankaj Dubey 
> > ---
> >  Documentation/devicetree/bindings/pci/designware-pcie.txt | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> > b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> > index 78494c4050f7..9507ac38ac89 100644
> > --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> > @@ -38,6 +38,8 @@ Optional properties:
> > for data corruption. CDM registers include standard PCIe
configuration
> > space registers, Port Logic registers, DMA and iATU (internal
Address
> > Translation Unit) registers.
> > +- snps,phy-zrxdc-compliant: This property is needed if phy complies
> > +with the
> 
> Strictly speaking, this is a property of the phy - not the controller that
uses it.
> 
> If I understand correctly, there are some DW based PCI controllers that
use a
> phandle reference in DT to a Phy (such as fsl,imx6q-pcie.txt). Therefore
it feels
> like this is in the wrong place. Is there a reason this isn't described in
the Phy?
>

Yes, from HW point of view this is a property of the PHY. As PHY is the one
which is ZRXDC compliant or non-compliant. 
But as the DW controller programming needs to be altered for handling such
phys, so we added it as a DT binding of DW controller driver. 
Also it might be possible that, some other PCIe controller (other than
DesignWare), do not have any such provision in controller H/W and they
expect PHY itself should expose some SFR to handle such scenario. In such
cases it is straight-forward to add this binding as part of PHY node.

We can add this as part of PHY binding, but in that case we will end up
checking PHY binding in DWC driver via PHY nodes which seems little a bit of
hack. 

Do you have any other better approach to handle this? 
 
> Thanks,
> 
> Andrew Murray
> 
> > +  ZRX-DC specification.
> >  RC mode:
> >  - num-viewport: number of view ports configured in hardware. If a
platform
> >does not specify it, the driver assumes 2.
> > --
> > 2.17.1
> >

RE: [PATCH 2/2] PCI: dwc: Add support to handle ZRX-DC Compliant PHYs

[Pankaj Dubey]

> -Original Message-
> From: Andrew Murray 
> Sent: Monday, October 21, 2019 7:47 PM
> To: Pankaj Dubey 
> Cc: 'Anvesh Salveru' ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; bhelg...@google.com;
> gustavo.pimen...@synopsys.com; jingooh...@gmail.com;
> lorenzo.pieral...@arm.com
> Subject: Re: [PATCH 2/2] PCI: dwc: Add support to handle ZRX-DC Compliant
> PHYs
> 
> On Mon, Oct 21, 2019 at 07:44:25PM +0530, Pankaj Dubey wrote:
> >
> >
> > > -Original Message-
> > > From: Andrew Murray 
> > > Sent: Monday, October 21, 2019 7:34 PM
> > > To: Anvesh Salveru 
> > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > bhelg...@google.com; gustavo.pimen...@synopsys.com;
> > > jingooh...@gmail.com; lorenzo.pieral...@arm.com; Pankaj Dubey
> > > 
> > > Subject: Re: [PATCH 2/2] PCI: dwc: Add support to handle ZRX-DC
> > > Compliant PHYs
> > >
> > > On Mon, Oct 21, 2019 at 05:59:53PM +0530, Anvesh Salveru wrote:
> > > > Many platforms use DesignWare controller but the PHY can be
> > > > different in different platforms. If the PHY is compliant is to
> > > > ZRX-DC specification
> > >
> > > s/is to/to the/
> >
> > OK
> >
> > >
> > > > it helps in low power consumption during power states.
> > >
> > > s/in low/lower/
> > >
> > OK
> > > >
> > > > If current data rate is 8.0 GT/s or higher and PHY is not
> > > > compliant to ZRX-DC specification, then after every 100ms link
> > > > should transition to recovery state during the low power states.
> > > >
> > > > DesignWare controller provides GEN3_ZRXDC_NONCOMPL field in
> > > > GEN3_RELATED_OFF to specify about ZRX-DC compliant PHY.
> > > >
> > > > Platforms with ZRX-DC compliant PHY can set
"snps,phy-zrxdc-compliant"
> > > > property in controller DT node to specify this property to the
> > controller.
> > > >
> > > > Signed-off-by: Anvesh Salveru 
> > > > Signed-off-by: Pankaj Dubey 
> > > > ---
> > > >  drivers/pci/controller/dwc/pcie-designware.c | 7 +++
> > > > drivers/pci/controller/dwc/pcie-designware.h | 3 +++
> > > >  2 files changed, 10 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > > index 820488dfeaed..6560d9f765d7 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > > @@ -556,4 +556,11 @@ void dw_pcie_setup(struct dw_pcie *pci)
> > > >PCIE_PL_CHK_REG_CHK_REG_START;
> > > > dw_pcie_writel_dbi(pci,
PCIE_PL_CHK_REG_CONTROL_STATUS,
> > > val);
> > > > }
> > > > +
> > > > +   if (of_property_read_bool(np, "snps,phy-zrxdc-compliant")) {
> > > > +   val = dw_pcie_readl_dbi(pci,
PCIE_PORT_GEN3_RELATED);
> > > > +   val &= ~PORT_LOGIC_GEN3_ZRXDC_NONCOMPL;
> > > > +   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED,
val);
> > > > +   }
> > > > +
> > >
> > > Given that this duplicates tegra_pcie_prepare_host in
> > > pcie-tegra194.c, can
> > we
> > > update that driver to adopt this new binding?
> > >
> >
> > Yes, Thanks for highlighting this. Otherwise I was worried that we
> > have one more patch without real user :)
> 
> Indeed :|
> 
> Though besides Tegra, is there any other reason you are adding this?
> 

Yes. We have one internal PCIe RC driver (which we can't disclose/upstream
right now) has this issue and currently we are handling it using this DT
binding. So we would like to upstream common code, so other platform's
driver can use this.

> > We will update pcie-tegra194.c driver and post the patch to adopt this
> > binding.
> 
> It's much appreciated.
> 
> Andrew Murray
> 
> >
> > > Thanks,
> > >
> > > Andrew Murray
> > >
> > > >  }
> > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > > > b/drivers/pci/controller/dwc/pcie-designware.h
> > > > index 5a18e94e52c8..427a55ec43c6 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > > > @@ -60,6 +60,9 @@
> > > >  #define PCIE_MSI_INTR0_MASK0x82C
> > > >  #define PCIE_MSI_INTR0_STATUS  0x830
> > > >
> > > > +#define PCIE_PORT_GEN3_RELATED 0x890
> > > > +#define PORT_LOGIC_GEN3_ZRXDC_NONCOMPL BIT(0)
> > > > +
> > > >  #define PCIE_ATU_VIEWPORT  0x900
> > > >  #define PCIE_ATU_REGION_INBOUNDBIT(31)
> > > >  #define PCIE_ATU_REGION_OUTBOUND   0
> > > > --
> > > > 2.17.1
> > > >
> >

RE: [PATCH 2/2] PCI: dwc: Add support to handle ZRX-DC Compliant PHYs

[Pankaj Dubey]

> -Original Message-
> From: Andrew Murray 
> Sent: Monday, October 21, 2019 7:34 PM
> To: Anvesh Salveru 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; gustavo.pimen...@synopsys.com;
> jingooh...@gmail.com; lorenzo.pieral...@arm.com; Pankaj Dubey
> 
> Subject: Re: [PATCH 2/2] PCI: dwc: Add support to handle ZRX-DC Compliant
> PHYs
> 
> On Mon, Oct 21, 2019 at 05:59:53PM +0530, Anvesh Salveru wrote:
> > Many platforms use DesignWare controller but the PHY can be different
> > in different platforms. If the PHY is compliant is to ZRX-DC
> > specification
> 
> s/is to/to the/

OK

> 
> > it helps in low power consumption during power states.
> 
> s/in low/lower/
> 
OK
> >
> > If current data rate is 8.0 GT/s or higher and PHY is not compliant to
> > ZRX-DC specification, then after every 100ms link should transition to
> > recovery state during the low power states.
> >
> > DesignWare controller provides GEN3_ZRXDC_NONCOMPL field in
> > GEN3_RELATED_OFF to specify about ZRX-DC compliant PHY.
> >
> > Platforms with ZRX-DC compliant PHY can set "snps,phy-zrxdc-compliant"
> > property in controller DT node to specify this property to the
controller.
> >
> > Signed-off-by: Anvesh Salveru 
> > Signed-off-by: Pankaj Dubey 
> > ---
> >  drivers/pci/controller/dwc/pcie-designware.c | 7 +++
> > drivers/pci/controller/dwc/pcie-designware.h | 3 +++
> >  2 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index 820488dfeaed..6560d9f765d7 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -556,4 +556,11 @@ void dw_pcie_setup(struct dw_pcie *pci)
> >PCIE_PL_CHK_REG_CHK_REG_START;
> > dw_pcie_writel_dbi(pci, PCIE_PL_CHK_REG_CONTROL_STATUS,
> val);
> > }
> > +
> > +   if (of_property_read_bool(np, "snps,phy-zrxdc-compliant")) {
> > +   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
> > +   val &= ~PORT_LOGIC_GEN3_ZRXDC_NONCOMPL;
> > +   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
> > +   }
> > +
> 
> Given that this duplicates tegra_pcie_prepare_host in pcie-tegra194.c, can
we
> update that driver to adopt this new binding?
> 

Yes, Thanks for highlighting this. Otherwise I was worried that we have one
more patch without real user :)
We will update pcie-tegra194.c driver and post the patch to adopt this
binding.

> Thanks,
> 
> Andrew Murray
> 
> >  }
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > b/drivers/pci/controller/dwc/pcie-designware.h
> > index 5a18e94e52c8..427a55ec43c6 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -60,6 +60,9 @@
> >  #define PCIE_MSI_INTR0_MASK0x82C
> >  #define PCIE_MSI_INTR0_STATUS  0x830
> >
> > +#define PCIE_PORT_GEN3_RELATED 0x890
> > +#define PORT_LOGIC_GEN3_ZRXDC_NONCOMPL BIT(0)
> > +
> >  #define PCIE_ATU_VIEWPORT  0x900
> >  #define PCIE_ATU_REGION_INBOUNDBIT(31)
> >  #define PCIE_ATU_REGION_OUTBOUND   0
> > --
> > 2.17.1
> >

RE: [PATCH v3] PCI: dwc: Add support to add GEN3 related equalization quirks

[Pankaj Dubey]

> -Original Message-
> From: 'Christoph Hellwig' 
> Sent: Tuesday, October 15, 2019 2:36 PM
> To: Pankaj Dubey 
> Cc: 'Christoph Hellwig' ; linux-...@vger.kernel.org;
linux-
> ker...@vger.kernel.org; bhelg...@google.com; andrew.mur...@arm.com;
> lorenzo.pieral...@arm.com; gustavo.pimen...@synopsys.com;
> jingooh...@gmail.com; vid...@nvidia.com; 'Anvesh Salveru'
> 
> Subject: Re: [PATCH v3] PCI: dwc: Add support to add GEN3 related
equalization
> quirks
> 
> On Tue, Oct 15, 2019 at 02:28:00PM +0530, Pankaj Dubey wrote:
> > Is this something mandatory?
> >
> > As we discussed during first patch-set here [1] with Andrew, we have
> > need of this patch (along with some other stuffs, which will be sent
> > soon), to clean up our internal driver and make it ready for upstream.
> > As of today we have some internal restrictions where we can't make it
> > to upstream along with this patch.
> 
> We don't add code to the kernel without actual users.

OK, but do we think the current driver has only code which is being used by
some user?
At least I can see current driver has some features which is not being used
by any current driver.  

I will leave this call up-to the maintainers.
IMO, This being an DWC H/W IP feature, for me it makes sense to have it in
DWC controller driver as long as it does not break any existing
functionality, irrespective of actual user is present or not. 

RE: [PATCH v3] PCI: dwc: Add support to add GEN3 related equalization quirks

[Pankaj Dubey]

> -Original Message-
> From: Christoph Hellwig 
> Sent: Tuesday, October 15, 2019 1:46 PM
> To: Pankaj Dubey 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; andrew.mur...@arm.com; lorenzo.pieral...@arm.com;
> gustavo.pimen...@synopsys.com; jingooh...@gmail.com; vid...@nvidia.com;
> Anvesh Salveru 
> Subject: Re: [PATCH v3] PCI: dwc: Add support to add GEN3 related
equalization
> quirks
> 
> On Tue, Oct 15, 2019 at 08:29:22AM +0530, Pankaj Dubey wrote:
> > From: Anvesh Salveru 
> >
> > In some platforms, PCIe PHY may have issues which will prevent linkup
> > to happen in GEN3 or higher speed. In case equalization fails, link
> > will fallback to GEN1.
> >
> > DesignWare controller gives flexibility to disable GEN3 equalization
> > completely or only phase 2 and 3 of equalization.
> >
> > This patch enables the DesignWare driver to disable the PCIe GEN3
> > equalization by enabling one of the following quirks:
> >  - DWC_EQUALIZATION_DISABLE: To disable GEN3 equalization all phases
> >  - DWC_EQ_PHASE_2_3_DISABLE: To disable GEN3 equalization phase 2 & 3
> >
> > Platform drivers can set these quirks via "quirk" variable of "dw_pcie"
> > struct.
> 
> Please submit this together with the changes to the dwc frontend driver
that
> actually wants to set these quirks.

Is this something mandatory?

As we discussed during first patch-set here [1] with Andrew, we have need of
this patch (along with some other stuffs, which will be sent soon), to clean
up our internal driver and make it ready for upstream. As of today we have
some internal restrictions where we can't make it to upstream along with
this patch. 

[1]: https://patchwork.ozlabs.org/patch/1160310/#2258262

[PATCH v3] PCI: dwc: Add support to add GEN3 related equalization quirks

[Pankaj Dubey]

From: Anvesh Salveru 

In some platforms, PCIe PHY may have issues which will prevent linkup
to happen in GEN3 or higher speed. In case equalization fails, link will
fallback to GEN1.

DesignWare controller gives flexibility to disable GEN3 equalization
completely or only phase 2 and 3 of equalization.

This patch enables the DesignWare driver to disable the PCIe GEN3
equalization by enabling one of the following quirks:
 - DWC_EQUALIZATION_DISABLE: To disable GEN3 equalization all phases
 - DWC_EQ_PHASE_2_3_DISABLE: To disable GEN3 equalization phase 2 & 3

Platform drivers can set these quirks via "quirk" variable of "dw_pcie"
struct.

Signed-off-by: Anvesh Salveru 
Signed-off-by: Pankaj Dubey 
Acked-by: Gustavo Pimentel 
Reviewed-by: Andrew Murray 
Reviewed-by: Vidya Sagar 
---
Changes w.r.t v2:
 - Rebased on latest linus/master
 - Added Reviewed-by and Acked-by

 drivers/pci/controller/dwc/pcie-designware.c | 12 
 drivers/pci/controller/dwc/pcie-designware.h |  9 +
 2 files changed, 21 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index 820488d..e247d6d 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -556,4 +556,16 @@ void dw_pcie_setup(struct dw_pcie *pci)
   PCIE_PL_CHK_REG_CHK_REG_START;
dw_pcie_writel_dbi(pci, PCIE_PL_CHK_REG_CONTROL_STATUS, val);
}
+
+   if (pci->quirk & DWC_EQUALIZATION_DISABLE) {
+   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
+   val |= PORT_LOGIC_GEN3_EQ_DISABLE;
+   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
+   }
+
+   if (pci->quirk & DWC_EQ_PHASE_2_3_DISABLE) {
+   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
+   val |= PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE;
+   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
+   }
 }
diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index 5a18e94..7d3fe6f 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -29,6 +29,10 @@
 #define LINK_WAIT_MAX_IATU_RETRIES 5
 #define LINK_WAIT_IATU 9
 
+/* Parameters for GEN3 related quirks */
+#define DWC_EQUALIZATION_DISABLE   BIT(1)
+#define DWC_EQ_PHASE_2_3_DISABLE   BIT(2)
+
 /* Synopsys-specific PCIe configuration registers */
 #define PCIE_PORT_LINK_CONTROL 0x710
 #define PORT_LINK_MODE_MASKGENMASK(21, 16)
@@ -60,6 +64,10 @@
 #define PCIE_MSI_INTR0_MASK0x82C
 #define PCIE_MSI_INTR0_STATUS  0x830
 
+#define PCIE_PORT_GEN3_RELATED 0x890
+#define PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE   BIT(9)
+#define PORT_LOGIC_GEN3_EQ_DISABLE BIT(16)
+
 #define PCIE_ATU_VIEWPORT  0x900
 #define PCIE_ATU_REGION_INBOUNDBIT(31)
 #define PCIE_ATU_REGION_OUTBOUND   0
@@ -253,6 +261,7 @@ struct dw_pcie {
struct dw_pcie_ep   ep;
const struct dw_pcie_ops *ops;
unsigned intversion;
+   unsigned intquirk;
 };
 
 #define to_dw_pcie_from_pp(port) container_of((port), struct dw_pcie, pp)
-- 
2.7.4

RE: [PATCH v2] PCI: dwc: Add support to add GEN3 related equalization quirks

[Pankaj Dubey]

> -Original Message-
> From: Lorenzo Pieralisi 
> Sent: Monday, October 14, 2019 8:44 PM
> To: Pankaj Dubey 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; andrew.mur...@arm.com;
> gustavo.pimen...@synopsys.com; jingooh...@gmail.com; vid...@nvidia.com;
> Anvesh Salveru 
> Subject: Re: [PATCH v2] PCI: dwc: Add support to add GEN3 related
equalization
> quirks
> 
> On Mon, Oct 14, 2019 at 12:48:29PM +0530, Pankaj Dubey wrote:
> > From: Anvesh Salveru 
> >
> > In some platforms, PCIe PHY may have issues which will prevent linkup
> > to happen in GEN3 or higher speed. In case equalization fails, link
> > will fallback to GEN1.
> >
> > DesignWare controller gives flexibility to disable GEN3 equalization
> > completely or only phase 2 and 3 of equalization.
> >
> > This patch enables the DesignWare driver to disable the PCIe GEN3
> > equalization by enabling one of the following quirks:
> >  - DWC_EQUALIZATION_DISABLE: To disable GEN3 equalization all phases
> >  - DWC_EQ_PHASE_2_3_DISABLE: To disable GEN3 equalization phase 2 & 3
> >
> > Platform drivers can set these quirks via "quirk" variable of "dw_pcie"
> > struct.
> >
> > Signed-off-by: Anvesh Salveru 
> > Signed-off-by: Pankaj Dubey 
> > Acked-by: Gustavo Pimentel 
> > Reviewed-by: Andrew Murray 
> > Reviewed-by: Vidya Sagar 
> > ---
> > Changes w.r.t v1:
> >  - Rebased on latest linus/master
> >  - Added Reviewed-by and Acked-by
> >
> >  drivers/pci/controller/dwc/pcie-designware.c | 12 
> > drivers/pci/controller/dwc/pcie-designware.h |  9 +
> >  2 files changed, 21 insertions(+)
> 
> So this is v3 not v2, right ?
> 

Yes, you are right. I missed this. 
This can be discarded, I will resend the patch with v3 tag.

> Here is v2:
> 
> https://protect2.fireeye.com/url?k=47b7cdf58f33e5e1.47b646ba-
> 8ad463719e64eba8=https://patchwork.ozlabs.org/patch/1161958/
> 
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index 820488d..e247d6d 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -556,4 +556,16 @@ void dw_pcie_setup(struct dw_pcie *pci)
> >PCIE_PL_CHK_REG_CHK_REG_START;
> > dw_pcie_writel_dbi(pci, PCIE_PL_CHK_REG_CONTROL_STATUS,
> val);
> > }
> > +
> > +   if (pci->quirk & DWC_EQUALIZATION_DISABLE) {
> > +   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
> > +   val |= PORT_LOGIC_GEN3_EQ_DISABLE;
> > +   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
> > +   }
> > +
> > +   if (pci->quirk & DWC_EQ_PHASE_2_3_DISABLE) {
> > +   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
> > +   val |= PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE;
> > +   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
> > +   }
> >  }
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > b/drivers/pci/controller/dwc/pcie-designware.h
> > index 5a18e94..7d3fe6f 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -29,6 +29,10 @@
> >  #define LINK_WAIT_MAX_IATU_RETRIES 5
> >  #define LINK_WAIT_IATU 9
> >
> > +/* Parameters for GEN3 related quirks */
> > +#define DWC_EQUALIZATION_DISABLE   BIT(1)
> > +#define DWC_EQ_PHASE_2_3_DISABLE   BIT(2)
> > +
> >  /* Synopsys-specific PCIe configuration registers */
> >  #define PCIE_PORT_LINK_CONTROL 0x710
> >  #define PORT_LINK_MODE_MASKGENMASK(21, 16)
> > @@ -60,6 +64,10 @@
> >  #define PCIE_MSI_INTR0_MASK0x82C
> >  #define PCIE_MSI_INTR0_STATUS  0x830
> >
> > +#define PCIE_PORT_GEN3_RELATED 0x890
> > +#define PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE   BIT(9)
> > +#define PORT_LOGIC_GEN3_EQ_DISABLE BIT(16)
> > +
> >  #define PCIE_ATU_VIEWPORT  0x900
> >  #define PCIE_ATU_REGION_INBOUNDBIT(31)
> >  #define PCIE_ATU_REGION_OUTBOUND   0
> > @@ -253,6 +261,7 @@ struct dw_pcie {
> > struct dw_pcie_ep   ep;
> > const struct dw_pcie_ops *ops;
> > unsigned intversion;
> > +   unsigned intquirk;
> >  };
> >
> >  #define to_dw_pcie_from_pp(port) container_of((port), struct dw_pcie,
> > pp)
> > --
> > 2.7.4
> >

[PATCH v2] PCI: dwc: Add support to add GEN3 related equalization quirks

[Pankaj Dubey]

From: Anvesh Salveru 

In some platforms, PCIe PHY may have issues which will prevent linkup
to happen in GEN3 or higher speed. In case equalization fails, link will
fallback to GEN1.

DesignWare controller gives flexibility to disable GEN3 equalization
completely or only phase 2 and 3 of equalization.

This patch enables the DesignWare driver to disable the PCIe GEN3
equalization by enabling one of the following quirks:
 - DWC_EQUALIZATION_DISABLE: To disable GEN3 equalization all phases
 - DWC_EQ_PHASE_2_3_DISABLE: To disable GEN3 equalization phase 2 & 3

Platform drivers can set these quirks via "quirk" variable of "dw_pcie"
struct.

Signed-off-by: Anvesh Salveru 
Signed-off-by: Pankaj Dubey 
Acked-by: Gustavo Pimentel 
Reviewed-by: Andrew Murray 
Reviewed-by: Vidya Sagar 
---
Changes w.r.t v1:
 - Rebased on latest linus/master
 - Added Reviewed-by and Acked-by

 drivers/pci/controller/dwc/pcie-designware.c | 12 
 drivers/pci/controller/dwc/pcie-designware.h |  9 +
 2 files changed, 21 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index 820488d..e247d6d 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -556,4 +556,16 @@ void dw_pcie_setup(struct dw_pcie *pci)
   PCIE_PL_CHK_REG_CHK_REG_START;
dw_pcie_writel_dbi(pci, PCIE_PL_CHK_REG_CONTROL_STATUS, val);
}
+
+   if (pci->quirk & DWC_EQUALIZATION_DISABLE) {
+   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
+   val |= PORT_LOGIC_GEN3_EQ_DISABLE;
+   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
+   }
+
+   if (pci->quirk & DWC_EQ_PHASE_2_3_DISABLE) {
+   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
+   val |= PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE;
+   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
+   }
 }
diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index 5a18e94..7d3fe6f 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -29,6 +29,10 @@
 #define LINK_WAIT_MAX_IATU_RETRIES 5
 #define LINK_WAIT_IATU 9
 
+/* Parameters for GEN3 related quirks */
+#define DWC_EQUALIZATION_DISABLE   BIT(1)
+#define DWC_EQ_PHASE_2_3_DISABLE   BIT(2)
+
 /* Synopsys-specific PCIe configuration registers */
 #define PCIE_PORT_LINK_CONTROL 0x710
 #define PORT_LINK_MODE_MASKGENMASK(21, 16)
@@ -60,6 +64,10 @@
 #define PCIE_MSI_INTR0_MASK0x82C
 #define PCIE_MSI_INTR0_STATUS  0x830
 
+#define PCIE_PORT_GEN3_RELATED 0x890
+#define PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE   BIT(9)
+#define PORT_LOGIC_GEN3_EQ_DISABLE BIT(16)
+
 #define PCIE_ATU_VIEWPORT  0x900
 #define PCIE_ATU_REGION_INBOUNDBIT(31)
 #define PCIE_ATU_REGION_OUTBOUND   0
@@ -253,6 +261,7 @@ struct dw_pcie {
struct dw_pcie_ep   ep;
const struct dw_pcie_ops *ops;
unsigned intversion;
+   unsigned intquirk;
 };
 
 #define to_dw_pcie_from_pp(port) container_of((port), struct dw_pcie, pp)
-- 
2.7.4

RE: [PATCH v2] PCI: dwc: Add support to add GEN3 related equalization quirks

[Pankaj Dubey]

> -Original Message-
> From: Vidya Sagar 
> Sent: Tuesday, September 24, 2019 4:57 PM
> To: Pankaj Dubey ; 'Gustavo Pimentel'
> ; 'Andrew Murray'
> 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> jingooh...@gmail.com; lorenzo.pieral...@arm.com; bhelg...@google.com;
> 'Anvesh Salveru' 
> Subject: Re: [PATCH v2] PCI: dwc: Add support to add GEN3 related equalization
> quirks
> 
> On 9/24/2019 2:58 PM, Pankaj Dubey wrote:
> >
> >
> >> -Original Message-
> >> From: Vidya Sagar 
> >> Sent: Thursday, September 19, 2019 4:54 PM
> >> Subject: Re: [PATCH v2] PCI: dwc: Add support to add GEN3 related
> >> equalization quirks
> >>
> >> On 9/16/2019 6:22 PM, Gustavo Pimentel wrote:
> >>> On Mon, Sep 16, 2019 at 13:24:1, Andrew Murray
> >> 
> >>> wrote:
> >>>
> >>>> On Mon, Sep 16, 2019 at 04:36:33PM +0530, Pankaj Dubey wrote:
> >>>>>
> >>>>>
> >>>>>> -Original Message-
> >>>>>> From: Andrew Murray 
> >>>>>> Sent: Monday, September 16, 2019 3:46 PM
> >>>>>> To: Pankaj Dubey 
> >>>>>> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >>>>>> jingooh...@gmail.com; gustavo.pimen...@synopsys.com;
> >>>>>> lorenzo.pieral...@arm.com; bhelg...@google.com; Anvesh Salveru
> >>>>>> 
> >>>>>> Subject: Re: [PATCH v2] PCI: dwc: Add support to add GEN3 related
> >>>>> equalization
> >>>>>> quirks
> >>>>>>
> >>>>>> On Fri, Sep 13, 2019 at 04:09:50PM +0530, Pankaj Dubey wrote:
> >>>>>>> From: Anvesh Salveru 
> >>>>>>>
> >>>>>>> In some platforms, PCIe PHY may have issues which will prevent
> >>>>>>> linkup to happen in GEN3 or higher speed. In case equalization
> >>>>>>> fails, link will fallback to GEN1.
> >>>>>>>
> >>>>>>> DesignWare controller gives flexibility to disable GEN3
> >>>>>>> equalization completely or only phase 2 and 3 of equalization.
> >>>>>>>
> >>>>>>> This patch enables the DesignWare driver to disable the PCIe
> >>>>>>> GEN3 equalization by enabling one of the following quirks:
> >>>>>>>- DWC_EQUALIZATION_DISABLE: To disable GEN3 equalization all
> >>>>>>> phases
> >> I don't think Gen-3 equalization can be skipped altogether.
> >> PCIe Spec Rev 4.0 Ver 1.0 in Section-4.2.3 has the following statement.
> >>
> >> "All the Lanes that are associated with the LTSSM (i.e., those Lanes
> >> that are currently operational or may be operational in the future
> >> due to Link
> >> Upconfigure) must participate in the Equalization procedure"
> >>
> >> and in Section-4.2.6.4.2.1.1 it says
> >> "Note: A transition to Recovery.RcvrLock might be used in the case
> >> where the Downstream Port determines that Phase 2 and Phase 3 are not
> >> needed based on the platform and channel characteristics."
> >>
> >> Based on the above statements, I think it is Ok to skip only Phases
> >> 2&3 of equalization but not 0&1.
> >> I even checked with our hardware engineers and it seems
> >> DWC_EQUALIZATION_DISABLE is present only for debugging purpose in
> >> hardware simulations and shouldn't be used on real silicon otherwise it 
> >> seems.
> >>
> >
> > In DesignWare manual we don't see any comment that this feature is for
> debugging purpose only.
> Agree and as I mentioned even I got to know about it offline.
> 
> > Even if it is meant for debugging purpose, if for some reason in an SoC, 
> > Gen3/4
> linkup is failing due to equalization, and if disabling equalization is 
> helping then
> IMO it is OK to do it.
> Well, I don't have specific reservations to not have it. We can use this as a 
> fall
> back option.
> 
> > Just to re-confirm we tested one of the NVMe device on Jatson AGX Xavier RC
> with equalization disabled. We do see linkup works well in GEN3. As we have
> added this feature as a platform-quirk so only platforms that required this
> feature can enable it.
> >
> Curious to know...You did it because link didn't come up with equalization
> enabled? or just as an experiment?
> 

We did th

RE: [PATCH v2] PCI: dwc: Add support to add GEN3 related equalization quirks

[Pankaj Dubey]

> -Original Message-
> From: Vidya Sagar 
> Sent: Thursday, September 19, 2019 4:54 PM
> Subject: Re: [PATCH v2] PCI: dwc: Add support to add GEN3 related equalization
> quirks
> 
> On 9/16/2019 6:22 PM, Gustavo Pimentel wrote:
> > On Mon, Sep 16, 2019 at 13:24:1, Andrew Murray
> 
> > wrote:
> >
> >> On Mon, Sep 16, 2019 at 04:36:33PM +0530, Pankaj Dubey wrote:
> >>>
> >>>
> >>>> -Original Message-----
> >>>> From: Andrew Murray 
> >>>> Sent: Monday, September 16, 2019 3:46 PM
> >>>> To: Pankaj Dubey 
> >>>> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >>>> jingooh...@gmail.com; gustavo.pimen...@synopsys.com;
> >>>> lorenzo.pieral...@arm.com; bhelg...@google.com; Anvesh Salveru
> >>>> 
> >>>> Subject: Re: [PATCH v2] PCI: dwc: Add support to add GEN3 related
> >>> equalization
> >>>> quirks
> >>>>
> >>>> On Fri, Sep 13, 2019 at 04:09:50PM +0530, Pankaj Dubey wrote:
> >>>>> From: Anvesh Salveru 
> >>>>>
> >>>>> In some platforms, PCIe PHY may have issues which will prevent
> >>>>> linkup to happen in GEN3 or higher speed. In case equalization
> >>>>> fails, link will fallback to GEN1.
> >>>>>
> >>>>> DesignWare controller gives flexibility to disable GEN3
> >>>>> equalization completely or only phase 2 and 3 of equalization.
> >>>>>
> >>>>> This patch enables the DesignWare driver to disable the PCIe GEN3
> >>>>> equalization by enabling one of the following quirks:
> >>>>>   - DWC_EQUALIZATION_DISABLE: To disable GEN3 equalization all
> >>>>> phases
> I don't think Gen-3 equalization can be skipped altogether.
> PCIe Spec Rev 4.0 Ver 1.0 in Section-4.2.3 has the following statement.
> 
> "All the Lanes that are associated with the LTSSM (i.e., those Lanes that are
> currently operational or may be operational in the future due to Link
> Upconfigure) must participate in the Equalization procedure"
> 
> and in Section-4.2.6.4.2.1.1 it says
> "Note: A transition to Recovery.RcvrLock might be used in the case where the
> Downstream Port determines that Phase 2 and Phase 3 are not needed based on
> the platform and channel characteristics."
> 
> Based on the above statements, I think it is Ok to skip only Phases 2&3 of
> equalization but not 0&1.
> I even checked with our hardware engineers and it seems
> DWC_EQUALIZATION_DISABLE is present only for debugging purpose in
> hardware simulations and shouldn't be used on real silicon otherwise it seems.
> 

In DesignWare manual we don't see any comment that this feature is for 
debugging purpose only.
Even if it is meant for debugging purpose, if for some reason in an SoC, Gen3/4 
linkup is failing due to equalization, and if disabling equalization is helping 
then IMO it is OK to do it. 
Just to re-confirm we tested one of the NVMe device on Jatson AGX Xavier RC 
with equalization disabled. We do see linkup works well in GEN3. As we have 
added this feature as a platform-quirk so only platforms that required this 
feature can enable it.

Snippet of lspci (from Jatson AGX Xavier RC) is given below, showing EQ is 
completely disabled and GEN3 linkup
-
0005:01:00.0 Non-Volatile memory controller: Lite-On Technology Corporation 
Device 21f1 (rev 01) (prog-if 02 [NVM Express])
Subsystem: Marvell Technology Group Ltd. Device 1093
 
LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L1, Exit Latency 
L0s <512ns, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- 
BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR+, 
OBFF Via message
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, 
OBFF Disabled
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, 
EqualizationComplete-, EqualizationPhase1-
 EqualizationPhase2-, EqualizationPhase3-, 
LinkEqualizationRequest-
-
> - Vidya Sagar
> 
> 
> >>>>>   -

RE: [PATCH v2] PCI: dwc: Add support to add GEN3 related equalization quirks

[Pankaj Dubey]

> -Original Message-
> From: Andrew Murray 
> Sent: Monday, September 16, 2019 3:46 PM
> To: Pankaj Dubey 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> jingooh...@gmail.com; gustavo.pimen...@synopsys.com;
> lorenzo.pieral...@arm.com; bhelg...@google.com; Anvesh Salveru
> 
> Subject: Re: [PATCH v2] PCI: dwc: Add support to add GEN3 related
equalization
> quirks
> 
> On Fri, Sep 13, 2019 at 04:09:50PM +0530, Pankaj Dubey wrote:
> > From: Anvesh Salveru 
> >
> > In some platforms, PCIe PHY may have issues which will prevent linkup
> > to happen in GEN3 or higher speed. In case equalization fails, link
> > will fallback to GEN1.
> >
> > DesignWare controller gives flexibility to disable GEN3 equalization
> > completely or only phase 2 and 3 of equalization.
> >
> > This patch enables the DesignWare driver to disable the PCIe GEN3
> > equalization by enabling one of the following quirks:
> >  - DWC_EQUALIZATION_DISABLE: To disable GEN3 equalization all phases
> >  - DWC_EQ_PHASE_2_3_DISABLE: To disable GEN3 equalization phase 2 & 3
> >
> > Platform drivers can set these quirks via "quirk" variable of "dw_pcie"
> > struct.
> >
> > Signed-off-by: Anvesh Salveru 
> > Signed-off-by: Pankaj Dubey 
> > ---
> > Patchset v1 can be found at:
> >  - 1/2: https://lkml.org/lkml/2019/9/10/443
> >  - 2/2: https://lkml.org/lkml/2019/9/10/444
> >
> > Changes w.r.t v1:
> >  - Squashed two patches from v1 into one as suggested by Gustavo
> >  - Addressed review comments from Andrew
> >
> >  drivers/pci/controller/dwc/pcie-designware.c | 12 
> > drivers/pci/controller/dwc/pcie-designware.h |  9 +
> >  2 files changed, 21 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index 7d25102..97fb18d 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -466,4 +466,16 @@ void dw_pcie_setup(struct dw_pcie *pci)
> > break;
> > }
> > dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, val);
> > +
> > +   if (pci->quirk & DWC_EQUALIZATION_DISABLE) {
> > +   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
> > +   val |= PORT_LOGIC_GEN3_EQ_DISABLE;
> > +   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
> > +   }
> > +
> > +   if (pci->quirk & DWC_EQ_PHASE_2_3_DISABLE) {
> > +   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
> > +   val |= PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE;
> > +   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
> > +   }
> >  }
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > b/drivers/pci/controller/dwc/pcie-designware.h
> > index ffed084..e428b62 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -29,6 +29,10 @@
> >  #define LINK_WAIT_MAX_IATU_RETRIES 5
> >  #define LINK_WAIT_IATU 9
> >
> > +/* Parameters for GEN3 related quirks */
> > +#define DWC_EQUALIZATION_DISABLE   BIT(1)
> > +#define DWC_EQ_PHASE_2_3_DISABLE   BIT(2)
> > +
> >  /* Synopsys-specific PCIe configuration registers */
> >  #define PCIE_PORT_LINK_CONTROL 0x710
> >  #define PORT_LINK_MODE_MASKGENMASK(21, 16)
> > @@ -60,6 +64,10 @@
> >  #define PCIE_MSI_INTR0_MASK0x82C
> >  #define PCIE_MSI_INTR0_STATUS  0x830
> >
> > +#define PCIE_PORT_GEN3_RELATED 0x890
> 
> I hadn't noticed this in the previous version - what is the proper name
for this
> register? Does it end in _RELATED?

As per SNPS databook the name of the register is "GEN3_RELATED_OFF". It is
port logic register so, to keep similarity with other port logic registers
in this file we named it as "PCIE_PORT_GEN3_RELATED". 

> 
> Thanks,
> 
> Andrew Murray
> 
> > +#define PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE   BIT(9)
> > +#define PORT_LOGIC_GEN3_EQ_DISABLE BIT(16)
> > +
> >  #define PCIE_ATU_VIEWPORT  0x900
> >  #define PCIE_ATU_REGION_INBOUNDBIT(31)
> >  #define PCIE_ATU_REGION_OUTBOUND   0
> > @@ -244,6 +252,7 @@ struct dw_pcie {
> > struct dw_pcie_ep   ep;
> > const struct dw_pcie_ops *ops;
> > unsigned intversion;
> > +   unsigned intquirk;
> >  };
> >
> >  #define to_dw_pcie_from_pp(port) container_of((port), struct dw_pcie,
> > pp)
> > --
> > 2.7.4
> >

RE: [PATCH 1/2] PCI: dwc: Add support to disable GEN3 equalization

[Pankaj Dubey]

> -Original Message-
> From: Gustavo Pimentel 
> Sent: Thursday, September 12, 2019 7:52 PM
> To: Pankaj Dubey ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Cc: jingooh...@gmail.com; gustavo.pimen...@synopsys.com;
> lorenzo.pieral...@arm.com; bhelg...@google.com; Anvesh Salveru
> 
> Subject: RE: [PATCH 1/2] PCI: dwc: Add support to disable GEN3 equalization
> 
> Hi,
> 
> On Tue, Sep 10, 2019 at 13:25:1, Pankaj Dubey 
> wrote:
> 
> > From: Anvesh Salveru 
> >
> > In some platforms, PCIe PHY may have issues which will prevent linkup
> > to happen in GEN3 or high speed. In case equalization fails, link will
> > fallback to GEN1.
> >
> > Designware controller has support for disabling GEN3 equalization if
> > required. This patch enables the designware driver to disable the PCIe
> > GEN3 equalization by writing into PCIE_PORT_GEN3_RELATED.
> 
> s/Designware/DesignWare
> s/designware/DesignWare
> 
> >
> > Platform drivers can disable equalization by setting the dwc_pci_quirk
> > flag DWC_EQUALIZATION_DISABLE.
> >
> > Signed-off-by: Anvesh Salveru 
> > Signed-off-by: Pankaj Dubey 
> > ---
> >  drivers/pci/controller/dwc/pcie-designware.c | 7 +++
> > drivers/pci/controller/dwc/pcie-designware.h | 7 +++
> >  2 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index 7d25102..bf82091 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -466,4 +466,11 @@ void dw_pcie_setup(struct dw_pcie *pci)
> > break;
> > }
> > dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, val);
> > +
> > +   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
> > +
> > +   if (pci->dwc_pci_quirk & DWC_EQUALIZATION_DISABLE)
> > +   val |= PORT_LOGIC_GEN3_EQ_DISABLE;
> > +
> > +   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
> >  }
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > b/drivers/pci/controller/dwc/pcie-designware.h
> > index ffed084..a1453c5 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -29,6 +29,9 @@
> >  #define LINK_WAIT_MAX_IATU_RETRIES 5
> >  #define LINK_WAIT_IATU 9
> >
> > +/* Parameters for PCIe Quirks */
> > +#define DWC_EQUALIZATION_DISABLE   0x1
> > +
> >  /* Synopsys-specific PCIe configuration registers */
> >  #define PCIE_PORT_LINK_CONTROL 0x710
> >  #define PORT_LINK_MODE_MASKGENMASK(21, 16)
> > @@ -60,6 +63,9 @@
> >  #define PCIE_MSI_INTR0_MASK0x82C
> >  #define PCIE_MSI_INTR0_STATUS  0x830
> >
> > +#define PCIE_PORT_GEN3_RELATED 0x890
> > +#define PORT_LOGIC_GEN3_EQ_DISABLE BIT(16)
> > +
> >  #define PCIE_ATU_VIEWPORT  0x900
> >  #define PCIE_ATU_REGION_INBOUNDBIT(31)
> >  #define PCIE_ATU_REGION_OUTBOUND   0
> > @@ -244,6 +250,7 @@ struct dw_pcie {
> > struct dw_pcie_ep   ep;
> > const struct dw_pcie_ops *ops;
> > unsigned intversion;
> > +   unsigned intdwc_pci_quirk;
> 
> I'd prefer called this variable just quirk, the prefix is redundant here.
> 
> >  };
> >
> >  #define to_dw_pcie_from_pp(port) container_of((port), struct dw_pcie,
> > pp)
> > --
> > 2.7.4
> 
> I understand your idea and I'm fine with it, but I just wonder if there isn't 
> any
> other typical way to do this kind of quirks... I'm not seeing a similar case 
> to this
> although.

Even we didn't see any existing approach to address this.

> For me makes more sense to squash both patches (1 and 2), since we aim to add
> this quirk especially because it focuses is on this "GEN3_RELATED"
> register in a logical patch.
>

Done. Posted [v2] where we squashed both the patches.
v2: https://lkml.org/lkml/2019/9/13/171

Thanks for review.
 
> Regards,
> Gustavo

[PATCH v2] PCI: dwc: Add support to add GEN3 related equalization quirks

[Pankaj Dubey]

From: Anvesh Salveru 

In some platforms, PCIe PHY may have issues which will prevent linkup
to happen in GEN3 or higher speed. In case equalization fails, link will
fallback to GEN1.

DesignWare controller gives flexibility to disable GEN3 equalization
completely or only phase 2 and 3 of equalization.

This patch enables the DesignWare driver to disable the PCIe GEN3
equalization by enabling one of the following quirks:
 - DWC_EQUALIZATION_DISABLE: To disable GEN3 equalization all phases
 - DWC_EQ_PHASE_2_3_DISABLE: To disable GEN3 equalization phase 2 & 3

Platform drivers can set these quirks via "quirk" variable of "dw_pcie"
struct.

Signed-off-by: Anvesh Salveru 
Signed-off-by: Pankaj Dubey 
---
Patchset v1 can be found at:
 - 1/2: https://lkml.org/lkml/2019/9/10/443
 - 2/2: https://lkml.org/lkml/2019/9/10/444

Changes w.r.t v1:
 - Squashed two patches from v1 into one as suggested by Gustavo
 - Addressed review comments from Andrew

 drivers/pci/controller/dwc/pcie-designware.c | 12 
 drivers/pci/controller/dwc/pcie-designware.h |  9 +
 2 files changed, 21 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index 7d25102..97fb18d 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -466,4 +466,16 @@ void dw_pcie_setup(struct dw_pcie *pci)
break;
}
dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, val);
+
+   if (pci->quirk & DWC_EQUALIZATION_DISABLE) {
+   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
+   val |= PORT_LOGIC_GEN3_EQ_DISABLE;
+   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
+   }
+
+   if (pci->quirk & DWC_EQ_PHASE_2_3_DISABLE) {
+   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
+   val |= PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE;
+   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
+   }
 }
diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index ffed084..e428b62 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -29,6 +29,10 @@
 #define LINK_WAIT_MAX_IATU_RETRIES 5
 #define LINK_WAIT_IATU 9
 
+/* Parameters for GEN3 related quirks */
+#define DWC_EQUALIZATION_DISABLE   BIT(1)
+#define DWC_EQ_PHASE_2_3_DISABLE   BIT(2)
+
 /* Synopsys-specific PCIe configuration registers */
 #define PCIE_PORT_LINK_CONTROL 0x710
 #define PORT_LINK_MODE_MASKGENMASK(21, 16)
@@ -60,6 +64,10 @@
 #define PCIE_MSI_INTR0_MASK0x82C
 #define PCIE_MSI_INTR0_STATUS  0x830
 
+#define PCIE_PORT_GEN3_RELATED 0x890
+#define PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE   BIT(9)
+#define PORT_LOGIC_GEN3_EQ_DISABLE BIT(16)
+
 #define PCIE_ATU_VIEWPORT  0x900
 #define PCIE_ATU_REGION_INBOUNDBIT(31)
 #define PCIE_ATU_REGION_OUTBOUND   0
@@ -244,6 +252,7 @@ struct dw_pcie {
struct dw_pcie_ep   ep;
const struct dw_pcie_ops *ops;
unsigned intversion;
+   unsigned intquirk;
 };
 
 #define to_dw_pcie_from_pp(port) container_of((port), struct dw_pcie, pp)
-- 
2.7.4

RE: [PATCH 2/2] PCI: dwc: Add support to disable equalization phase 2 and 3

[Pankaj Dubey]

> From: Andrew Murray 
> 
> On Tue, Sep 10, 2019 at 09:51:41PM +0530, Pankaj Dubey wrote:
> > On Tue, 10 Sep 2019 at 19:59, Andrew Murray 
> wrote:
> > >
> > > On Tue, Sep 10, 2019 at 05:55:02PM +0530, Pankaj Dubey wrote:
> > > > From: Anvesh Salveru 
> > > >
> > > > In some platforms, PCIe PHY may have issues which will prevent
> > > > linkup to happen in GEN3 or high speed. In case equalization
> > > > fails, link will fallback to GEN1.
> > > >
> > > > Designware controller gives flexibility to disable GEN3
> > > > equalization completely or only phase 2 and 3.
> > >
> > > Do some platforms have issues conducting phase 2 and 3 when they
> > > successfully conduct phase 0 and 1?
> > >
> >
> > Yes, it is possible.
> >
> > > >
> > > > Platform drivers can disable equalization phase 2 and 3, by
> > > > setting dwc_pci_quirk flag DWC_EQUALIZATION_DISABLE.
> > > >
> > > > Signed-off-by: Anvesh Salveru 
> > > > Signed-off-by: Pankaj Dubey 
> > > > ---
> > > >  drivers/pci/controller/dwc/pcie-designware.c | 3 +++
> > > > drivers/pci/controller/dwc/pcie-designware.h | 2 ++
> > > >  2 files changed, 5 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > > index bf82091..97a8268 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > > @@ -472,5 +472,8 @@ void dw_pcie_setup(struct dw_pcie *pci)
> > > >   if (pci->dwc_pci_quirk & DWC_EQUALIZATION_DISABLE)
> > > >   val |= PORT_LOGIC_GEN3_EQ_DISABLE;
> > > >
> > > > + if (pci->dwc_pci_quirk & DWC_EQ_PHASE_2_3_DISABLE)
> > > > + val |= PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE;
> > > > +
> 
> Also is it harmless to set both DWC_EQUALIZATION_DISABLE and
> DWC_EQ_PHASE_2_3_DISABLE? (Which is permitted here).
> 

Yes, it will be harmless.

> Thanks,
> 
> Andrew Murray
> 
> > > >   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);  }
> > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > > > b/drivers/pci/controller/dwc/pcie-designware.h
> > > > index a1453c5..b541508 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > > > @@ -31,6 +31,7 @@
> > > >
> > > >  /* Parameters for PCIe Quirks */
> > > >  #define DWC_EQUALIZATION_DISABLE 0x1
> > > > +#define DWC_EQ_PHASE_2_3_DISABLE 0x2
> > >
> > > It only makes sense for either DWC_EQUALIZATION_DISABLE or
> > > DWC_EQ_PHASE_2_3_DISABLE to be specified, though if dwc_pci_quirk
> > > intends to hold other quirks should these be numbers and not bit
fields?
> > >
> > Yes, you are right in a given platform it will be either
> > DWC_EQUALIZATION_DISABLE or DWC_EQ_PHASE_2_3_DISABLE.
> >
> > Intention behind making it bit-field was to add other quirks in future.
> >
> > > Thanks,
> > >
> > > Andrew Murray
> > >
> > > >
> > > >  /* Synopsys-specific PCIe configuration registers */
> > > >  #define PCIE_PORT_LINK_CONTROL   0x710
> > > > @@ -65,6 +66,7 @@
> > > >
> > > >  #define PCIE_PORT_GEN3_RELATED   0x890
> > > >  #define PORT_LOGIC_GEN3_EQ_DISABLE   BIT(16)
> > > > +#define PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE BIT(9)
> > > >
> > > >  #define PCIE_ATU_VIEWPORT0x900
> > > >  #define PCIE_ATU_REGION_INBOUND  BIT(31)
> > > > --
> > > > 2.7.4
> > > >

RE: [PATCH 1/2] PCI: dwc: Add support to disable GEN3 equalization

[Pankaj Dubey]

> From: Andrew Murray 
> 
> On Tue, Sep 10, 2019 at 09:46:28PM +0530, Pankaj Dubey wrote:
> > On Tue, 10 Sep 2019 at 19:56, Andrew Murray 
> wrote:
> > >
> > > On Tue, Sep 10, 2019 at 05:55:01PM +0530, Pankaj Dubey wrote:
> > > > From: Anvesh Salveru 
> > > >
> > > > In some platforms, PCIe PHY may have issues which will prevent
> > > > linkup to happen in GEN3 or high speed. In case equalization
> > > > fails, link will fallback to GEN1.
> > >
> > > When you refer to "high speed", do you mean "higher speeds" as in
> > > GEN3, GEN4, etc?
> > >
> >
> > Yes. Will reword the commit message as "higher speeds"
> >
> > > >
> > > > Designware controller has support for disabling GEN3 equalization
> > > > if required. This patch enables the designware driver to disable
> > > > the PCIe
> > > > GEN3 equalization by writing into PCIE_PORT_GEN3_RELATED.
> > >
> > > Thus limiting to GEN2 speeds max, right?
> > >
> > > Is the purpose of PORT_LOGIC_GEN3_EQ_DISABLE to disable GEN3 and
> > > above even though we advertise GEN3 and above speeds? I.e. the IP
> > > advertises
> > > GEN3 but the phy can't handle it, we can't change what the IP
> > > advertises and so we disable equalization to limit to GEN2?
> > >
> > > I notice many of the other dwc drivers (dra7xx, keystone, tegra194,
> > > imx6) seem to use the device tree to specify a max-link-speed and
> > > then impose that limit by changing the value in PCI_EXP_LNKCAP. Is
> > > your PORT_LOGIC_GEN3_EQ_DISABLE approach and alternative to the
> > > PCI_EXP_LNKCAP approach, or does your approach add something else?
> > >
> >
> > No, max speed will be still as per advertised by link or it will be
> > equal to the limited speed as per DT property if any.
> > This register will prohibit to perform all phases of equalization and
> > thus allowing link to happen in maximum supported/advertised speed.
> >
> > This is not to limit max link speed, this register helps link to
> > happen in higher speeds (GEN3/4) without going through equalization
> > phases. It is intended to use only if at all link fails to latch up in
> > GEN3/4 due to failure in equalization phases.
> 
> I thought that for GEN3 and beyond equalization was *required* - with only
> phases 2 and 3 being optional. Therefore I'm suprised to see that if
equalization
> does fail we continue to train the link anyway. Have I understood this
correctly?
> 

AFAIK, equalization is not mandatory for GEN3 and higher speed. I mean in
case there is some H/W issue we can still go ahead and disable complete
equalization.

> Also are there any plans to provide patches to use this quirk on any
drivers?
> 

Yes, we have plans and soon the user driver of this feature will land for
review. But I believe this should not be blocker to consider this patch, as
it is a feature provided in Designware H/W and so we can add S/W support for
the same.

> >
> > > >
> > > > Platform drivers can disable equalization by setting the
> > > > dwc_pci_quirk flag DWC_EQUALIZATION_DISABLE.
> > > >
> > > > Signed-off-by: Anvesh Salveru 
> > > > Signed-off-by: Pankaj Dubey 
> > > > ---
> > > >  drivers/pci/controller/dwc/pcie-designware.c | 7 +++
> > > > drivers/pci/controller/dwc/pcie-designware.h | 7 +++
> > > >  2 files changed, 14 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > > index 7d25102..bf82091 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > > @@ -466,4 +466,11 @@ void dw_pcie_setup(struct dw_pcie *pci)
> > > >   break;
> > > >   }
> > > >   dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, val);
> > > > +
> > > > + val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
> > > > +
> > > > + if (pci->dwc_pci_quirk & DWC_EQUALIZATION_DISABLE)
> > > > + val |= PORT_LOGIC_GEN3_EQ_DISABLE;
> > > > +
> > > > + dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
> > >
> > > The problem here is that even when DWC_EQUALIZATION_DISABLE is not
> > > set the driver will read and write PCIE_PORT_GEN3_RELATED w

Re: [PATCH 2/2] PCI: dwc: Add support to disable equalization phase 2 and 3

[Pankaj Dubey]

On Tue, 10 Sep 2019 at 19:59, Andrew Murray  wrote:
>
> On Tue, Sep 10, 2019 at 05:55:02PM +0530, Pankaj Dubey wrote:
> > From: Anvesh Salveru 
> >
> > In some platforms, PCIe PHY may have issues which will prevent linkup
> > to happen in GEN3 or high speed. In case equalization fails, link will
> > fallback to GEN1.
> >
> > Designware controller gives flexibility to disable GEN3 equalization
> > completely or only phase 2 and 3.
>
> Do some platforms have issues conducting phase 2 and 3 when they successfully
> conduct phase 0 and 1?
>

Yes, it is possible.

> >
> > Platform drivers can disable equalization phase 2 and 3, by setting
> > dwc_pci_quirk flag DWC_EQUALIZATION_DISABLE.
> >
> > Signed-off-by: Anvesh Salveru 
> > Signed-off-by: Pankaj Dubey 
> > ---
> >  drivers/pci/controller/dwc/pcie-designware.c | 3 +++
> >  drivers/pci/controller/dwc/pcie-designware.h | 2 ++
> >  2 files changed, 5 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index bf82091..97a8268 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -472,5 +472,8 @@ void dw_pcie_setup(struct dw_pcie *pci)
> >   if (pci->dwc_pci_quirk & DWC_EQUALIZATION_DISABLE)
> >   val |= PORT_LOGIC_GEN3_EQ_DISABLE;
> >
> > + if (pci->dwc_pci_quirk & DWC_EQ_PHASE_2_3_DISABLE)
> > + val |= PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE;
> > +
> >   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
> >  }
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
> > b/drivers/pci/controller/dwc/pcie-designware.h
> > index a1453c5..b541508 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -31,6 +31,7 @@
> >
> >  /* Parameters for PCIe Quirks */
> >  #define DWC_EQUALIZATION_DISABLE 0x1
> > +#define DWC_EQ_PHASE_2_3_DISABLE 0x2
>
> It only makes sense for either DWC_EQUALIZATION_DISABLE or 
> DWC_EQ_PHASE_2_3_DISABLE
> to be specified, though if dwc_pci_quirk intends to hold other quirks should 
> these
> be numbers and not bit fields?
>
Yes, you are right in a given platform it will be either
DWC_EQUALIZATION_DISABLE or DWC_EQ_PHASE_2_3_DISABLE.

Intention behind making it bit-field was to add other quirks in future.

> Thanks,
>
> Andrew Murray
>
> >
> >  /* Synopsys-specific PCIe configuration registers */
> >  #define PCIE_PORT_LINK_CONTROL   0x710
> > @@ -65,6 +66,7 @@
> >
> >  #define PCIE_PORT_GEN3_RELATED   0x890
> >  #define PORT_LOGIC_GEN3_EQ_DISABLE   BIT(16)
> > +#define PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE BIT(9)
> >
> >  #define PCIE_ATU_VIEWPORT0x900
> >  #define PCIE_ATU_REGION_INBOUND  BIT(31)
> > --
> > 2.7.4
> >

Re: [PATCH 1/2] PCI: dwc: Add support to disable GEN3 equalization

[Pankaj Dubey]

On Tue, 10 Sep 2019 at 19:56, Andrew Murray  wrote:
>
> On Tue, Sep 10, 2019 at 05:55:01PM +0530, Pankaj Dubey wrote:
> > From: Anvesh Salveru 
> >
> > In some platforms, PCIe PHY may have issues which will prevent linkup
> > to happen in GEN3 or high speed. In case equalization fails, link will
> > fallback to GEN1.
>
> When you refer to "high speed", do you mean "higher speeds" as in GEN3,
> GEN4, etc?
>

Yes. Will reword the commit message as "higher speeds"

> >
> > Designware controller has support for disabling GEN3 equalization if
> > required. This patch enables the designware driver to disable the PCIe
> > GEN3 equalization by writing into PCIE_PORT_GEN3_RELATED.
>
> Thus limiting to GEN2 speeds max, right?
>
> Is the purpose of PORT_LOGIC_GEN3_EQ_DISABLE to disable GEN3 and above
> even though we advertise GEN3 and above speeds? I.e. the IP advertises
> GEN3 but the phy can't handle it, we can't change what the IP advertises
> and so we disable equalization to limit to GEN2?
>
> I notice many of the other dwc drivers (dra7xx, keystone, tegra194, imx6)
> seem to use the device tree to specify a max-link-speed and then impose
> that limit by changing the value in PCI_EXP_LNKCAP. Is your
> PORT_LOGIC_GEN3_EQ_DISABLE approach and alternative to the PCI_EXP_LNKCAP
> approach, or does your approach add something else?
>

No, max speed will be still as per advertised by link or it will be
equal to the limited speed as per DT property if any.
This register will prohibit to perform all phases of equalization and
thus allowing link to happen in maximum supported/advertised speed.

This is not to limit max link speed, this register helps link to
happen in higher speeds (GEN3/4) without going through equalization
phases. It is intended to use only if at all link fails to latch up in
GEN3/4 due to failure in equalization phases.

> >
> > Platform drivers can disable equalization by setting the dwc_pci_quirk
> > flag DWC_EQUALIZATION_DISABLE.
> >
> > Signed-off-by: Anvesh Salveru 
> > Signed-off-by: Pankaj Dubey 
> > ---
> >  drivers/pci/controller/dwc/pcie-designware.c | 7 +++
> >  drivers/pci/controller/dwc/pcie-designware.h | 7 +++
> >  2 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index 7d25102..bf82091 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -466,4 +466,11 @@ void dw_pcie_setup(struct dw_pcie *pci)
> >   break;
> >   }
> >   dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, val);
> > +
> > + val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
> > +
> > + if (pci->dwc_pci_quirk & DWC_EQUALIZATION_DISABLE)
> > + val |= PORT_LOGIC_GEN3_EQ_DISABLE;
> > +
> > + dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
>
> The problem here is that even when DWC_EQUALIZATION_DISABLE is not set
> the driver will read and write PCIE_PORT_GEN3_RELATED when it is not
> needed. How about something like:
>
> > +
> > + if (pci->dwc_pci_quirk & DWC_EQUALIZATION_DISABLE) {
> > + val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
> > + val |= PORT_LOGIC_GEN3_EQ_DISABLE;
> > + dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
> > + }
>

Yes, before posting we taught about it, but then next patchset is
adding one more quirk and in that case we need to repeat read and
write under each if condition. I hope that repetition should be fine.

> >  }
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
> > b/drivers/pci/controller/dwc/pcie-designware.h
> > index ffed084..a1453c5 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -29,6 +29,9 @@
> >  #define LINK_WAIT_MAX_IATU_RETRIES   5
> >  #define LINK_WAIT_IATU   9
> >
> > +/* Parameters for PCIe Quirks */
> > +#define DWC_EQUALIZATION_DISABLE 0x1
>
> How about using BIT(1) instead? Thus implying that you can combine
> quirks.
>

Agreed.

> Thanks,
>
> Andrew Murray
>
> > +
> >  /* Synopsys-specific PCIe configuration registers */
> >  #define PCIE_PORT_LINK_CONTROL   0x710
> >  #define PORT_LINK_MODE_MASK  GENMASK(21, 16)
> > @@ -60,6 +63,9 @@
> >  #define PCIE_MSI_INTR0_MASK  0x82C
> >  #define PCIE_MSI_INTR0_STATUS0x830
> >

[PATCH 1/2] PCI: dwc: Add support to disable GEN3 equalization

[Pankaj Dubey]

From: Anvesh Salveru 

In some platforms, PCIe PHY may have issues which will prevent linkup
to happen in GEN3 or high speed. In case equalization fails, link will
fallback to GEN1.

Designware controller has support for disabling GEN3 equalization if
required. This patch enables the designware driver to disable the PCIe
GEN3 equalization by writing into PCIE_PORT_GEN3_RELATED.

Platform drivers can disable equalization by setting the dwc_pci_quirk
flag DWC_EQUALIZATION_DISABLE.

Signed-off-by: Anvesh Salveru 
Signed-off-by: Pankaj Dubey 
---
 drivers/pci/controller/dwc/pcie-designware.c | 7 +++
 drivers/pci/controller/dwc/pcie-designware.h | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index 7d25102..bf82091 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -466,4 +466,11 @@ void dw_pcie_setup(struct dw_pcie *pci)
break;
}
dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, val);
+
+   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
+
+   if (pci->dwc_pci_quirk & DWC_EQUALIZATION_DISABLE)
+   val |= PORT_LOGIC_GEN3_EQ_DISABLE;
+
+   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
 }
diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index ffed084..a1453c5 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -29,6 +29,9 @@
 #define LINK_WAIT_MAX_IATU_RETRIES 5
 #define LINK_WAIT_IATU 9
 
+/* Parameters for PCIe Quirks */
+#define DWC_EQUALIZATION_DISABLE   0x1
+
 /* Synopsys-specific PCIe configuration registers */
 #define PCIE_PORT_LINK_CONTROL 0x710
 #define PORT_LINK_MODE_MASKGENMASK(21, 16)
@@ -60,6 +63,9 @@
 #define PCIE_MSI_INTR0_MASK0x82C
 #define PCIE_MSI_INTR0_STATUS  0x830
 
+#define PCIE_PORT_GEN3_RELATED 0x890
+#define PORT_LOGIC_GEN3_EQ_DISABLE BIT(16)
+
 #define PCIE_ATU_VIEWPORT  0x900
 #define PCIE_ATU_REGION_INBOUNDBIT(31)
 #define PCIE_ATU_REGION_OUTBOUND   0
@@ -244,6 +250,7 @@ struct dw_pcie {
struct dw_pcie_ep   ep;
const struct dw_pcie_ops *ops;
unsigned intversion;
+   unsigned intdwc_pci_quirk;
 };
 
 #define to_dw_pcie_from_pp(port) container_of((port), struct dw_pcie, pp)
-- 
2.7.4

[PATCH 2/2] PCI: dwc: Add support to disable equalization phase 2 and 3

[Pankaj Dubey]

From: Anvesh Salveru 

In some platforms, PCIe PHY may have issues which will prevent linkup
to happen in GEN3 or high speed. In case equalization fails, link will
fallback to GEN1.

Designware controller gives flexibility to disable GEN3 equalization
completely or only phase 2 and 3.

Platform drivers can disable equalization phase 2 and 3, by setting
dwc_pci_quirk flag DWC_EQUALIZATION_DISABLE.

Signed-off-by: Anvesh Salveru 
Signed-off-by: Pankaj Dubey 
---
 drivers/pci/controller/dwc/pcie-designware.c | 3 +++
 drivers/pci/controller/dwc/pcie-designware.h | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index bf82091..97a8268 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -472,5 +472,8 @@ void dw_pcie_setup(struct dw_pcie *pci)
if (pci->dwc_pci_quirk & DWC_EQUALIZATION_DISABLE)
val |= PORT_LOGIC_GEN3_EQ_DISABLE;
 
+   if (pci->dwc_pci_quirk & DWC_EQ_PHASE_2_3_DISABLE)
+   val |= PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE;
+
dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
 }
diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index a1453c5..b541508 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -31,6 +31,7 @@
 
 /* Parameters for PCIe Quirks */
 #define DWC_EQUALIZATION_DISABLE   0x1
+#define DWC_EQ_PHASE_2_3_DISABLE   0x2
 
 /* Synopsys-specific PCIe configuration registers */
 #define PCIE_PORT_LINK_CONTROL 0x710
@@ -65,6 +66,7 @@
 
 #define PCIE_PORT_GEN3_RELATED 0x890
 #define PORT_LOGIC_GEN3_EQ_DISABLE BIT(16)
+#define PORT_LOGIC_GEN3_EQ_PHASE_2_3_DISABLE   BIT(9)
 
 #define PCIE_ATU_VIEWPORT  0x900
 #define PCIE_ATU_REGION_INBOUNDBIT(31)
-- 
2.7.4

Re: [PATCH] usb: xhci: inherit dma_mask from bus if set correctly

[Pankaj Dubey]

On 4/10/19 4:32 AM, Robin Murphy wrote:
> On 2019-04-09 3:56 am, Sriram Dash wrote:
>> On Tue, Apr 2, 2019 at 9:53 PM Pankaj Dubey 
>>  wrote:
>>>
>>> On Tue, 2 Apr 2019 at 15:34, Robin Murphy  wrote:
>>>>
>>>> On 02/04/2019 10:40, Pankaj Dubey wrote:
>>>>> From: Sriram Dash 
>>>>>
>>>>> The xhci forcefully converts the dma_mask to either 64 or 32 and the
>>>>> dma-mask set by the bus is somewhat ignored. If the platform  sets 
>>>>> the
>>>>> correct dma_mask, then respect that.
>>>>
>>>> It's expected for dma_mask to be larger than bus_dma_mask if the 
>>>> latter
>>>> is set - conceptually, the device mask represents what the device is
>>>> inherently capable of, while the bus mask represents external
>>>> interconnect restrictions which individual drivers should not have to
>>>> care about. The DMA API backend should take care of combining the 
>>>> two to
>>>> find the intersection.
>>>
>>> Thanks for the review.
>>>
>>> We are dealing here with the xhci platform which inherits the dma mask
>>> of the parent, which is from a controller device.
>>>
>>> When the controller dma mask is set by the platform in DT, what we
>>> observe is, its not getting inherited properly and the xhci bus is
>>> forcing the dma address to be either 32 bit or 64 bit.
>>>
>>> In "drivers/usb/host/xhci-plat.c" we have dma_mask setting as below:
>>>
>>>   /* Try to set 64-bit DMA first */
>>> if (WARN_ON(!sysdev->dma_mask))
>>>   /* Platform did not initialize dma_mask */
>>>   ret = dma_coerce_mask_and_coherent(sysdev, DMA_BIT_MASK(64));
>>> else
>>>   ret = dma_set_mask_and_coherent(sysdev, DMA_BIT_MASK(64));
>>>
>>> So even if the controller device has set the dma_mask as per it's
>>> configuration in DT, xhci-plat.c will override it here in else part.
>>>
>>> Next it goes to "drivers/usb/host/xhci.c" file, here we have code as:
>>>
>>> /* Set dma_mask and coherent_dma_mask to 64-bits,
>>>   * if xHC supports 64-bit addressing */
>>> if (HCC_64BIT_ADDR(xhci->hcc_params) &&
>>>  !dma_set_mask(dev, DMA_BIT_MASK(64))) {
>>>  xhci_dbg(xhci, "Enabling 64-bit DMA addresses.\n");
>>>  dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
>>> } else {
>>>  /*
>>>   * This is to avoid error in cases where a 32-bit USB
>>>   * controller is used on a 64-bit capable system.
>>>   */
>>>  retval = dma_set_mask(dev, DMA_BIT_MASK(32));
>>>  if (retval)
>>>  return retval;
>>>  xhci_dbg(xhci, "Enabling 32-bit DMA addresses.\n");
>>>  dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
>>> }
>>>
>>> So xhci will force the dma_mask to either DMA_BIT_MASK(32) or
>>> DMA_BIT_MASK(64), what if my device needs other than 32 bit or 64 bit
>>> dma_mask.
>>>
>>> The bus_dma_mask was introduced for a case when the bus from a
>>> device's dma interface may carry fewer address bits. But apparently,
>>> it is the only mask which retains the original dma addressing from the
>>> parent. So basically what we observe is currently there is no way we
>>> can pass dma_mask greater than 32-bit, from DT via dev->dma_mask or
>>> dev->coherent_dma_mask due to below logic in
>>>
>>> from "drivers/of/platform.c" we have
>>> static struct platform_device *of_platform_device_create_pdata(
>>>  struct device_node *np,
>>>  const char *bus_id,
>>>  void *platform_data,
>>>  struct device *parent)
>>> {
>>>    struct platform_device *dev;
>>>    ...
>>>    dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>>>    if (!dev->dev.dma_mask)
>>>   dev->dev.dma_mask = >dev.coherent_dma_mask;
>>>    ...
>>> }
>>>
>>> and then in of_dma_configure function in "drivers/of/device.c" we 
>>> have..
>>>
>>> mask = DMA_BIT_MASK(ilog2(dma_addr + size - 1) + 1); //This mask
>>> computation is going fine and g

[PATCH] usb: xhci: inherit dma_mask from bus if set correctly

[Pankaj Dubey]

From: Sriram Dash 

The xhci forcefully converts the dma_mask to either 64 or 32 and the
dma-mask set by the bus is somewhat ignored. If the platform  sets the
correct dma_mask, then respect that.

Signed-off-by: Pankaj Dubey 
Signed-off-by: Sriram Dash 
---
 drivers/usb/host/xhci.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 005e659..55cf89e 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -5119,6 +5119,16 @@ int xhci_gen_setup(struct usb_hcd *hcd, 
xhci_get_quirks_t get_quirks)
dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
}
 
+   /*
+* A platform may require coherent masks other than 64/32 bit, and we
+* should respect that. If the firmware has already requested for a
+* dma-range, we inherit the dma_mask presuming the platform knows
+* what it is doing.
+*/
+
+   if (dev->bus_dma_mask)
+   dma_set_mask_and_coherent(dev, dev->bus_dma_mask);
+
xhci_dbg(xhci, "Calling HCD init\n");
/* Initialize HCD and host controller data structures. */
retval = xhci_init(hcd);
-- 
2.7.4

Re: [PATCH] PCI: dwc: designware: don't sleep in atomic context

[Pankaj Dubey]

Hi Jingoo,


On 12/21/2017 10:09 PM, Jingoo Han wrote:
> On Thursday, October 12, 2017 3:55 AM, Pankaj Dubey wrote:
>> In pcie-designware.c many places we are calling "usleep_range" which
>> are in atomic context. This patch fixes these potential BUGs and
>> replaces "usleep_range" with mdelay calls.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
> Sorry for my late response.
>
> Acked-by: Jingoo Han <jingooh...@gmail.com>
>
> Best regards,
> Jingoo Han

Thanks for review and Ack. Will resubmit this along with your ack.

Thanks,
Pankaj Dubey

Re: [PATCH] PCI: dwc: designware: don't sleep in atomic context

[Pankaj Dubey]

Hi Jingoo,


On 12/21/2017 10:09 PM, Jingoo Han wrote:
> On Thursday, October 12, 2017 3:55 AM, Pankaj Dubey wrote:
>> In pcie-designware.c many places we are calling "usleep_range" which
>> are in atomic context. This patch fixes these potential BUGs and
>> replaces "usleep_range" with mdelay calls.
>>
>> Signed-off-by: Pankaj Dubey 
> Sorry for my late response.
>
> Acked-by: Jingoo Han 
>
> Best regards,
> Jingoo Han

Thanks for review and Ack. Will resubmit this along with your ack.

Thanks,
Pankaj Dubey

Re: [PATCH] PCI: designware: move dw_pcie_iatu_unroll_enabled to pcie-designware.c

[Pankaj Dubey]

Hi Jingoo,


On 12/21/2017 10:04 PM, Jingoo Han wrote:
> On Thursday, October 12, 2017 12:41 AM, Pankaj Dubey wrote:
>> IATU unroll feature can be enabled in EP mode as well, so we need to
>> have this check in pcie-designware-ep.c, so instead of making this
>> function as static in pcie-desigware-host.c, let's move this in
>> pcie-designware.c so that both pcie-designware-host.c and
>> pcie-designware-ep.c can use it.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
> Sorry for my late response.
>
> Acked-by: Jingoo Han <jingooh...@gmail.com>
>
> Best regards,
> Jingoo Han

Thanks for review and Ack. Will resubmit this along with your Ack.

Thanks,
Pankaj Dubey

Re: [PATCH] PCI: designware: move dw_pcie_iatu_unroll_enabled to pcie-designware.c

[Pankaj Dubey]

Hi Jingoo,


On 12/21/2017 10:04 PM, Jingoo Han wrote:
> On Thursday, October 12, 2017 12:41 AM, Pankaj Dubey wrote:
>> IATU unroll feature can be enabled in EP mode as well, so we need to
>> have this check in pcie-designware-ep.c, so instead of making this
>> function as static in pcie-desigware-host.c, let's move this in
>> pcie-designware.c so that both pcie-designware-host.c and
>> pcie-designware-ep.c can use it.
>>
>> Signed-off-by: Pankaj Dubey 
> Sorry for my late response.
>
> Acked-by: Jingoo Han 
>
> Best regards,
> Jingoo Han

Thanks for review and Ack. Will resubmit this along with your Ack.

Thanks,
Pankaj Dubey

Re: [PATCH] PCI: endpoint: handle probable NULL pointer access

[Pankaj Dubey]

On 25 October 2017 at 17:32, Kishon Vijay Abraham I <kis...@ti.com> wrote:
> Hi,
>
> On Wednesday 25 October 2017 01:32 AM, Bjorn Helgaas wrote:
>> On Thu, Oct 12, 2017 at 09:27:57AM +0530, Pankaj Dubey wrote:
>>> controller_group allocation in pci_ep_cfs_init function can fail
>>> so we should have a check while using it in pci_ep_cfs_add_epc_group
>>> for registering group, else we will hit NULL pointer access.
>>>
>>> This patch adds required check for the same and returns -EPROBE_DEFER,
>>> so that endpoint controller driver probe can be reattempted later
>>> in case controller_group is not allocated because pci_ep_cfs_init is
>>> not yet called.
>>>
>>> Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
>>
>> Looking for Kishon's ack here.
>>
>>> ---
>>>  drivers/pci/endpoint/pci-ep-cfs.c   | 7 ++-
>>>  drivers/pci/endpoint/pci-epc-core.c | 4 
>>>  2 files changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
>>> b/drivers/pci/endpoint/pci-ep-cfs.c
>>> index 424fdd6..3cac818 100644
>>> --- a/drivers/pci/endpoint/pci-ep-cfs.c
>>> +++ b/drivers/pci/endpoint/pci-ep-cfs.c
>>> @@ -172,7 +172,12 @@ struct config_group *pci_ep_cfs_add_epc_group(const 
>>> char *name)
>>>  group = _group->group;
>>>
>>>  config_group_init_type_name(group, name, _epc_type);
>>> -ret = configfs_register_group(controllers_group, group);
>>> +
>>> +if (controllers_group)
>>> +ret = configfs_register_group(controllers_group, group);
>>> +else
>>> +ret = -EPROBE_DEFER;
>>> +
>
> Do you ever face this issue?

Yes, I was adding support for PCIe endpoint in Exynos driver and if we
see pci-exynos.c,
platform_driver_probe is called via subsys_initcall, which will happen
much before that module_init
and during endpoint probe sequence I got kernel panic for NULL pointer access.

> Ideally controllers_group should always be
> initialized if the dependencies are modeled properly.

Ideally Yes.

But we can't ignore error cases. Even though dependencies are modeled properly,
this check is mandatory, if we see pci_ep_cfs_init function where
"controllers_group" is suppose
to be allocated via call to "configfs_register_default_group", is
prone to failure as allocated via
kzalloc. We are handling error condition in pci_ep_cfs_init if it
fails to allocate "controllers_group"
but during EP initialization sequence, there is no check on
"controllers_group" pointer in
"configfs_register_default_group" function. So I feel it should have a
check for valid pointer.


>>>  if (ret) {
>>>  pr_err("failed to register configfs group for %s\n", name);
>>>  goto err_register_group;
>>> diff --git a/drivers/pci/endpoint/pci-epc-core.c 
>>> b/drivers/pci/endpoint/pci-epc-core.c
>>> index 42c2a11..d327a2a 100644
>>> --- a/drivers/pci/endpoint/pci-epc-core.c
>>> +++ b/drivers/pci/endpoint/pci-epc-core.c
>>> @@ -518,6 +518,10 @@ __pci_epc_create(struct device *dev, const struct 
>>> pci_epc_ops *ops,
>>>      goto put_dev;
>>>
>>>  epc->group = pci_ep_cfs_add_epc_group(dev_name(dev));
>>> +if (IS_ERR(epc->group)) {
>>> +ret = -EPROBE_DEFER;
>
> should use the return value of pci_ep_cfs_add_epc_group().
>

OK. Will modify in next version.

> However I don't think this is required since drivers might not actually need 
> cfs.

Ok, we can avoid propagating error to the caller here, but in case if
ERR_PTR there should be
at least one warn message. What do you say?


Thanks,
Pankaj Dubey
>
> Thanks
> Kishon

Re: [PATCH] PCI: endpoint: handle probable NULL pointer access

[Pankaj Dubey]

On 25 October 2017 at 17:32, Kishon Vijay Abraham I  wrote:
> Hi,
>
> On Wednesday 25 October 2017 01:32 AM, Bjorn Helgaas wrote:
>> On Thu, Oct 12, 2017 at 09:27:57AM +0530, Pankaj Dubey wrote:
>>> controller_group allocation in pci_ep_cfs_init function can fail
>>> so we should have a check while using it in pci_ep_cfs_add_epc_group
>>> for registering group, else we will hit NULL pointer access.
>>>
>>> This patch adds required check for the same and returns -EPROBE_DEFER,
>>> so that endpoint controller driver probe can be reattempted later
>>> in case controller_group is not allocated because pci_ep_cfs_init is
>>> not yet called.
>>>
>>> Signed-off-by: Pankaj Dubey 
>>
>> Looking for Kishon's ack here.
>>
>>> ---
>>>  drivers/pci/endpoint/pci-ep-cfs.c   | 7 ++-
>>>  drivers/pci/endpoint/pci-epc-core.c | 4 
>>>  2 files changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
>>> b/drivers/pci/endpoint/pci-ep-cfs.c
>>> index 424fdd6..3cac818 100644
>>> --- a/drivers/pci/endpoint/pci-ep-cfs.c
>>> +++ b/drivers/pci/endpoint/pci-ep-cfs.c
>>> @@ -172,7 +172,12 @@ struct config_group *pci_ep_cfs_add_epc_group(const 
>>> char *name)
>>>  group = _group->group;
>>>
>>>  config_group_init_type_name(group, name, _epc_type);
>>> -ret = configfs_register_group(controllers_group, group);
>>> +
>>> +if (controllers_group)
>>> +ret = configfs_register_group(controllers_group, group);
>>> +else
>>> +ret = -EPROBE_DEFER;
>>> +
>
> Do you ever face this issue?

Yes, I was adding support for PCIe endpoint in Exynos driver and if we
see pci-exynos.c,
platform_driver_probe is called via subsys_initcall, which will happen
much before that module_init
and during endpoint probe sequence I got kernel panic for NULL pointer access.

> Ideally controllers_group should always be
> initialized if the dependencies are modeled properly.

Ideally Yes.

But we can't ignore error cases. Even though dependencies are modeled properly,
this check is mandatory, if we see pci_ep_cfs_init function where
"controllers_group" is suppose
to be allocated via call to "configfs_register_default_group", is
prone to failure as allocated via
kzalloc. We are handling error condition in pci_ep_cfs_init if it
fails to allocate "controllers_group"
but during EP initialization sequence, there is no check on
"controllers_group" pointer in
"configfs_register_default_group" function. So I feel it should have a
check for valid pointer.


>>>  if (ret) {
>>>  pr_err("failed to register configfs group for %s\n", name);
>>>  goto err_register_group;
>>> diff --git a/drivers/pci/endpoint/pci-epc-core.c 
>>> b/drivers/pci/endpoint/pci-epc-core.c
>>> index 42c2a11..d327a2a 100644
>>> --- a/drivers/pci/endpoint/pci-epc-core.c
>>> +++ b/drivers/pci/endpoint/pci-epc-core.c
>>> @@ -518,6 +518,10 @@ __pci_epc_create(struct device *dev, const struct 
>>> pci_epc_ops *ops,
>>>  goto put_dev;
>>>
>>>  epc->group = pci_ep_cfs_add_epc_group(dev_name(dev));
>>> +if (IS_ERR(epc->group)) {
>>> +ret = -EPROBE_DEFER;
>
> should use the return value of pci_ep_cfs_add_epc_group().
>

OK. Will modify in next version.

> However I don't think this is required since drivers might not actually need 
> cfs.

Ok, we can avoid propagating error to the caller here, but in case if
ERR_PTR there should be
at least one warn message. What do you say?


Thanks,
Pankaj Dubey
>
> Thanks
> Kishon

Re: [PATCH] PCI: designware: move dw_pcie_iatu_unroll_enabled to pcie-designware.c

[Pankaj Dubey]

On 20 October 2017 at 23:11, Bjorn Helgaas <helg...@kernel.org> wrote:
>
> On Thu, Oct 12, 2017 at 10:11:08AM +0530, Pankaj Dubey wrote:
> > IATU unroll feature can be enabled in EP mode as well, so we need to
> > have this check in pcie-designware-ep.c, so instead of making this
> > function as static in pcie-desigware-host.c, let's move this in
> > pcie-designware.c so that both pcie-designware-host.c and
> > pcie-designware-ep.c can use it.
> >
> > Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
>
> This is fine with me but I'm looking for an ack from Jingoo and/or Joao.
>

Jingoo / Joao any comments on this?

>
> > ---
> >  drivers/pci/dwc/pcie-designware-ep.c   |  4 
> >  drivers/pci/dwc/pcie-designware-host.c | 11 ---
> >  drivers/pci/dwc/pcie-designware.c  | 11 +++
> >  drivers/pci/dwc/pcie-designware.h  |  1 +
> >  4 files changed, 16 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> > b/drivers/pci/dwc/pcie-designware-ep.c
> > index d53d5f1..64803a9 100644
> > --- a/drivers/pci/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/dwc/pcie-designware-ep.c
> > @@ -314,6 +314,10 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> >   if (ep->ops->ep_init)
> >   ep->ops->ep_init(ep);
> >
> > + pci->iatu_unroll_enabled = dw_pcie_iatu_unroll_enabled(pci);
> > + dev_dbg(dev, "iATU unroll: %s\n",
> > + pci->iatu_unroll_enabled ? "enabled" : "disabled");
> > +
> >   epc = devm_pci_epc_create(dev, _ops);
> >   if (IS_ERR(epc)) {
> >   dev_err(dev, "failed to create epc device\n");
> > diff --git a/drivers/pci/dwc/pcie-designware-host.c 
> > b/drivers/pci/dwc/pcie-designware-host.c
> > index 81e2157..d3f579e 100644
> > --- a/drivers/pci/dwc/pcie-designware-host.c
> > +++ b/drivers/pci/dwc/pcie-designware-host.c
> > @@ -574,17 +574,6 @@ static struct pci_ops dw_pcie_ops = {
> >   .write = dw_pcie_wr_conf,
> >  };
> >
> > -static u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
> > -{
> > - u32 val;
> > -
> > - val = dw_pcie_readl_dbi(pci, PCIE_ATU_VIEWPORT);
> > - if (val == 0x)
> > - return 1;
> > -
> > - return 0;
> > -}
> > -
> >  void dw_pcie_setup_rc(struct pcie_port *pp)
> >  {
> >   u32 val;
> > diff --git a/drivers/pci/dwc/pcie-designware.c 
> > b/drivers/pci/dwc/pcie-designware.c
> > index 88abddd..f15da90 100644
> > --- a/drivers/pci/dwc/pcie-designware.c
> > +++ b/drivers/pci/dwc/pcie-designware.c
> > @@ -92,6 +92,17 @@ void __dw_pcie_write_dbi(struct dw_pcie *pci, void 
> > __iomem *base, u32 reg,
> >   dev_err(pci->dev, "write DBI address failed\n");
> >  }
> >
> > +u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
>
> I know this is just moved verbatim, but it's more conventional to simply
> return an int (or possibly bool) for a predicate like this.  There's really
> no point in going out of your way to specify "u8" for the return type.
>

Ok, it can be done, will wait for comments from Jingoo and or Joao and
then update.

Thanks,
Pankaj


> > +{
> > + u32 val;
> > +
> > + val = dw_pcie_readl_dbi(pci, PCIE_ATU_VIEWPORT);
> > + if (val == 0x)
> > + return 1;
> > +
> > + return 0;
> > +}
> > +
> >  static u32 dw_pcie_readl_ob_unroll(struct dw_pcie *pci, u32 index, u32 reg)
> >  {
> >   u32 offset = PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
> > diff --git a/drivers/pci/dwc/pcie-designware.h 
> > b/drivers/pci/dwc/pcie-designware.h
> > index e5d9d77..8d6829c 100644
> > --- a/drivers/pci/dwc/pcie-designware.h
> > +++ b/drivers/pci/dwc/pcie-designware.h
> > @@ -242,6 +242,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int 
> > index, int bar,
> >  void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
> >enum dw_pcie_region_type type);
> >  void dw_pcie_setup(struct dw_pcie *pci);
> > +u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci);
> >
> >  static inline void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 
> > val)
> >  {
> > --
> > 2.7.4
> >

Re: [PATCH] PCI: designware: move dw_pcie_iatu_unroll_enabled to pcie-designware.c

[Pankaj Dubey]

On 20 October 2017 at 23:11, Bjorn Helgaas  wrote:
>
> On Thu, Oct 12, 2017 at 10:11:08AM +0530, Pankaj Dubey wrote:
> > IATU unroll feature can be enabled in EP mode as well, so we need to
> > have this check in pcie-designware-ep.c, so instead of making this
> > function as static in pcie-desigware-host.c, let's move this in
> > pcie-designware.c so that both pcie-designware-host.c and
> > pcie-designware-ep.c can use it.
> >
> > Signed-off-by: Pankaj Dubey 
>
> This is fine with me but I'm looking for an ack from Jingoo and/or Joao.
>

Jingoo / Joao any comments on this?

>
> > ---
> >  drivers/pci/dwc/pcie-designware-ep.c   |  4 
> >  drivers/pci/dwc/pcie-designware-host.c | 11 ---
> >  drivers/pci/dwc/pcie-designware.c  | 11 +++
> >  drivers/pci/dwc/pcie-designware.h  |  1 +
> >  4 files changed, 16 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> > b/drivers/pci/dwc/pcie-designware-ep.c
> > index d53d5f1..64803a9 100644
> > --- a/drivers/pci/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/dwc/pcie-designware-ep.c
> > @@ -314,6 +314,10 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> >   if (ep->ops->ep_init)
> >   ep->ops->ep_init(ep);
> >
> > + pci->iatu_unroll_enabled = dw_pcie_iatu_unroll_enabled(pci);
> > + dev_dbg(dev, "iATU unroll: %s\n",
> > + pci->iatu_unroll_enabled ? "enabled" : "disabled");
> > +
> >   epc = devm_pci_epc_create(dev, _ops);
> >   if (IS_ERR(epc)) {
> >   dev_err(dev, "failed to create epc device\n");
> > diff --git a/drivers/pci/dwc/pcie-designware-host.c 
> > b/drivers/pci/dwc/pcie-designware-host.c
> > index 81e2157..d3f579e 100644
> > --- a/drivers/pci/dwc/pcie-designware-host.c
> > +++ b/drivers/pci/dwc/pcie-designware-host.c
> > @@ -574,17 +574,6 @@ static struct pci_ops dw_pcie_ops = {
> >   .write = dw_pcie_wr_conf,
> >  };
> >
> > -static u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
> > -{
> > - u32 val;
> > -
> > - val = dw_pcie_readl_dbi(pci, PCIE_ATU_VIEWPORT);
> > - if (val == 0x)
> > - return 1;
> > -
> > - return 0;
> > -}
> > -
> >  void dw_pcie_setup_rc(struct pcie_port *pp)
> >  {
> >   u32 val;
> > diff --git a/drivers/pci/dwc/pcie-designware.c 
> > b/drivers/pci/dwc/pcie-designware.c
> > index 88abddd..f15da90 100644
> > --- a/drivers/pci/dwc/pcie-designware.c
> > +++ b/drivers/pci/dwc/pcie-designware.c
> > @@ -92,6 +92,17 @@ void __dw_pcie_write_dbi(struct dw_pcie *pci, void 
> > __iomem *base, u32 reg,
> >   dev_err(pci->dev, "write DBI address failed\n");
> >  }
> >
> > +u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
>
> I know this is just moved verbatim, but it's more conventional to simply
> return an int (or possibly bool) for a predicate like this.  There's really
> no point in going out of your way to specify "u8" for the return type.
>

Ok, it can be done, will wait for comments from Jingoo and or Joao and
then update.

Thanks,
Pankaj


> > +{
> > + u32 val;
> > +
> > + val = dw_pcie_readl_dbi(pci, PCIE_ATU_VIEWPORT);
> > + if (val == 0x)
> > + return 1;
> > +
> > + return 0;
> > +}
> > +
> >  static u32 dw_pcie_readl_ob_unroll(struct dw_pcie *pci, u32 index, u32 reg)
> >  {
> >   u32 offset = PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
> > diff --git a/drivers/pci/dwc/pcie-designware.h 
> > b/drivers/pci/dwc/pcie-designware.h
> > index e5d9d77..8d6829c 100644
> > --- a/drivers/pci/dwc/pcie-designware.h
> > +++ b/drivers/pci/dwc/pcie-designware.h
> > @@ -242,6 +242,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int 
> > index, int bar,
> >  void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
> >enum dw_pcie_region_type type);
> >  void dw_pcie_setup(struct dw_pcie *pci);
> > +u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci);
> >
> >  static inline void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 
> > val)
> >  {
> > --
> > 2.7.4
> >

Re: [PATCH] PCI: dwc: designware: don't sleep in atomic context

[Pankaj Dubey]

On 10/12/2017 04:09 PM, David Laight wrote:

From: Pankaj Dubey

Sent: 12 October 2017 08:55
In pcie-designware.c many places we are calling "usleep_range" which
are in atomic context. This patch fixes these potential BUGs and
replaces "usleep_range" with mdelay calls.

Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
  drivers/pci/dwc/pcie-designware.c | 8 
  drivers/pci/dwc/pcie-designware.h | 3 +--
  2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware.c 
b/drivers/pci/dwc/pcie-designware.c
index 88abddd..35d19b9 100644
--- a/drivers/pci/dwc/pcie-designware.c
+++ b/drivers/pci/dwc/pcie-designware.c
@@ -138,7 +138,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return;

-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU_MIN);
}

Spinning for 9ms (possibly 10 times) isn't really a good idea.


Yes. It may not be a good idea, however in our experiment it never hit 
maximum retry count.
I just converted usleep_range to mdelay keeping min time limitation as 
it is, though I
am not sure, how do we arrived on these numbers in original code, may be 
Joao Pinto
from Synopsys have some idea, I will try to do few experiment and try to 
find out what

is sufficient minimum time in our hardware for these mdelay.

Thanks,
Pankaj Dubey

David

Re: [PATCH] PCI: dwc: designware: don't sleep in atomic context

[Pankaj Dubey]

On 10/12/2017 04:09 PM, David Laight wrote:

From: Pankaj Dubey

Sent: 12 October 2017 08:55
In pcie-designware.c many places we are calling "usleep_range" which
are in atomic context. This patch fixes these potential BUGs and
replaces "usleep_range" with mdelay calls.

Signed-off-by: Pankaj Dubey 
---
  drivers/pci/dwc/pcie-designware.c | 8 
  drivers/pci/dwc/pcie-designware.h | 3 +--
  2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware.c 
b/drivers/pci/dwc/pcie-designware.c
index 88abddd..35d19b9 100644
--- a/drivers/pci/dwc/pcie-designware.c
+++ b/drivers/pci/dwc/pcie-designware.c
@@ -138,7 +138,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return;

-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU_MIN);
}

Spinning for 9ms (possibly 10 times) isn't really a good idea.


Yes. It may not be a good idea, however in our experiment it never hit 
maximum retry count.
I just converted usleep_range to mdelay keeping min time limitation as 
it is, though I
am not sure, how do we arrived on these numbers in original code, may be 
Joao Pinto
from Synopsys have some idea, I will try to do few experiment and try to 
find out what

is sufficient minimum time in our hardware for these mdelay.

Thanks,
Pankaj Dubey

David

[PATCH] PCI: dwc: designware: don't sleep in atomic context

[Pankaj Dubey]

In pcie-designware.c many places we are calling "usleep_range" which
are in atomic context. This patch fixes these potential BUGs and
replaces "usleep_range" with mdelay calls.

Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 drivers/pci/dwc/pcie-designware.c | 8 
 drivers/pci/dwc/pcie-designware.h | 3 +--
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware.c 
b/drivers/pci/dwc/pcie-designware.c
index 88abddd..35d19b9 100644
--- a/drivers/pci/dwc/pcie-designware.c
+++ b/drivers/pci/dwc/pcie-designware.c
@@ -138,7 +138,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU_MIN);
}
dev_err(pci->dev, "outbound iATU is not being enabled\n");
 }
@@ -181,7 +181,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int 
index, int type,
if (val & PCIE_ATU_ENABLE)
return;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU_MIN);
}
dev_err(pci->dev, "outbound iATU is not being enabled\n");
 }
@@ -239,7 +239,7 @@ static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return 0;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU_MIN);
}
dev_err(pci->dev, "inbound iATU is not being enabled\n");
 
@@ -285,7 +285,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int 
index, int bar,
if (val & PCIE_ATU_ENABLE)
return 0;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU_MIN);
}
dev_err(pci->dev, "inbound iATU is not being enabled\n");
 
diff --git a/drivers/pci/dwc/pcie-designware.h 
b/drivers/pci/dwc/pcie-designware.h
index e5d9d77..13c17c9 100644
--- a/drivers/pci/dwc/pcie-designware.h
+++ b/drivers/pci/dwc/pcie-designware.h
@@ -28,8 +28,7 @@
 
 /* Parameters for the waiting for iATU enabled routine */
 #define LINK_WAIT_MAX_IATU_RETRIES 5
-#define LINK_WAIT_IATU_MIN 9000
-#define LINK_WAIT_IATU_MAX 1
+#define LINK_WAIT_IATU_MIN 9
 
 /* Synopsys-specific PCIe configuration registers */
 #define PCIE_PORT_LINK_CONTROL 0x710
-- 
2.7.4

[PATCH] PCI: dwc: designware: don't sleep in atomic context

[Pankaj Dubey]

In pcie-designware.c many places we are calling "usleep_range" which
are in atomic context. This patch fixes these potential BUGs and
replaces "usleep_range" with mdelay calls.

Signed-off-by: Pankaj Dubey 
---
 drivers/pci/dwc/pcie-designware.c | 8 
 drivers/pci/dwc/pcie-designware.h | 3 +--
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware.c 
b/drivers/pci/dwc/pcie-designware.c
index 88abddd..35d19b9 100644
--- a/drivers/pci/dwc/pcie-designware.c
+++ b/drivers/pci/dwc/pcie-designware.c
@@ -138,7 +138,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU_MIN);
}
dev_err(pci->dev, "outbound iATU is not being enabled\n");
 }
@@ -181,7 +181,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int 
index, int type,
if (val & PCIE_ATU_ENABLE)
return;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU_MIN);
}
dev_err(pci->dev, "outbound iATU is not being enabled\n");
 }
@@ -239,7 +239,7 @@ static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return 0;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU_MIN);
}
dev_err(pci->dev, "inbound iATU is not being enabled\n");
 
@@ -285,7 +285,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int 
index, int bar,
if (val & PCIE_ATU_ENABLE)
return 0;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU_MIN);
}
dev_err(pci->dev, "inbound iATU is not being enabled\n");
 
diff --git a/drivers/pci/dwc/pcie-designware.h 
b/drivers/pci/dwc/pcie-designware.h
index e5d9d77..13c17c9 100644
--- a/drivers/pci/dwc/pcie-designware.h
+++ b/drivers/pci/dwc/pcie-designware.h
@@ -28,8 +28,7 @@
 
 /* Parameters for the waiting for iATU enabled routine */
 #define LINK_WAIT_MAX_IATU_RETRIES 5
-#define LINK_WAIT_IATU_MIN 9000
-#define LINK_WAIT_IATU_MAX 1
+#define LINK_WAIT_IATU_MIN 9
 
 /* Synopsys-specific PCIe configuration registers */
 #define PCIE_PORT_LINK_CONTROL 0x710
-- 
2.7.4

[PATCH] PCI: designware: move dw_pcie_iatu_unroll_enabled to pcie-designware.c

[Pankaj Dubey]

IATU unroll feature can be enabled in EP mode as well, so we need to
have this check in pcie-designware-ep.c, so instead of making this
function as static in pcie-desigware-host.c, let's move this in
pcie-designware.c so that both pcie-designware-host.c and
pcie-designware-ep.c can use it.

Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 drivers/pci/dwc/pcie-designware-ep.c   |  4 
 drivers/pci/dwc/pcie-designware-host.c | 11 ---
 drivers/pci/dwc/pcie-designware.c  | 11 +++
 drivers/pci/dwc/pcie-designware.h  |  1 +
 4 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
b/drivers/pci/dwc/pcie-designware-ep.c
index d53d5f1..64803a9 100644
--- a/drivers/pci/dwc/pcie-designware-ep.c
+++ b/drivers/pci/dwc/pcie-designware-ep.c
@@ -314,6 +314,10 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
if (ep->ops->ep_init)
ep->ops->ep_init(ep);
 
+   pci->iatu_unroll_enabled = dw_pcie_iatu_unroll_enabled(pci);
+   dev_dbg(dev, "iATU unroll: %s\n",
+   pci->iatu_unroll_enabled ? "enabled" : "disabled");
+
epc = devm_pci_epc_create(dev, _ops);
if (IS_ERR(epc)) {
dev_err(dev, "failed to create epc device\n");
diff --git a/drivers/pci/dwc/pcie-designware-host.c 
b/drivers/pci/dwc/pcie-designware-host.c
index 81e2157..d3f579e 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -574,17 +574,6 @@ static struct pci_ops dw_pcie_ops = {
.write = dw_pcie_wr_conf,
 };
 
-static u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
-{
-   u32 val;
-
-   val = dw_pcie_readl_dbi(pci, PCIE_ATU_VIEWPORT);
-   if (val == 0x)
-   return 1;
-
-   return 0;
-}
-
 void dw_pcie_setup_rc(struct pcie_port *pp)
 {
u32 val;
diff --git a/drivers/pci/dwc/pcie-designware.c 
b/drivers/pci/dwc/pcie-designware.c
index 88abddd..f15da90 100644
--- a/drivers/pci/dwc/pcie-designware.c
+++ b/drivers/pci/dwc/pcie-designware.c
@@ -92,6 +92,17 @@ void __dw_pcie_write_dbi(struct dw_pcie *pci, void __iomem 
*base, u32 reg,
dev_err(pci->dev, "write DBI address failed\n");
 }
 
+u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
+{
+   u32 val;
+
+   val = dw_pcie_readl_dbi(pci, PCIE_ATU_VIEWPORT);
+   if (val == 0x)
+   return 1;
+
+   return 0;
+}
+
 static u32 dw_pcie_readl_ob_unroll(struct dw_pcie *pci, u32 index, u32 reg)
 {
u32 offset = PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
diff --git a/drivers/pci/dwc/pcie-designware.h 
b/drivers/pci/dwc/pcie-designware.h
index e5d9d77..8d6829c 100644
--- a/drivers/pci/dwc/pcie-designware.h
+++ b/drivers/pci/dwc/pcie-designware.h
@@ -242,6 +242,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int 
index, int bar,
 void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
 enum dw_pcie_region_type type);
 void dw_pcie_setup(struct dw_pcie *pci);
+u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci);
 
 static inline void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 val)
 {
-- 
2.7.4

[PATCH] PCI: designware: move dw_pcie_iatu_unroll_enabled to pcie-designware.c

[Pankaj Dubey]

IATU unroll feature can be enabled in EP mode as well, so we need to
have this check in pcie-designware-ep.c, so instead of making this
function as static in pcie-desigware-host.c, let's move this in
pcie-designware.c so that both pcie-designware-host.c and
pcie-designware-ep.c can use it.

Signed-off-by: Pankaj Dubey 
---
 drivers/pci/dwc/pcie-designware-ep.c   |  4 
 drivers/pci/dwc/pcie-designware-host.c | 11 ---
 drivers/pci/dwc/pcie-designware.c  | 11 +++
 drivers/pci/dwc/pcie-designware.h  |  1 +
 4 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
b/drivers/pci/dwc/pcie-designware-ep.c
index d53d5f1..64803a9 100644
--- a/drivers/pci/dwc/pcie-designware-ep.c
+++ b/drivers/pci/dwc/pcie-designware-ep.c
@@ -314,6 +314,10 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
if (ep->ops->ep_init)
ep->ops->ep_init(ep);
 
+   pci->iatu_unroll_enabled = dw_pcie_iatu_unroll_enabled(pci);
+   dev_dbg(dev, "iATU unroll: %s\n",
+   pci->iatu_unroll_enabled ? "enabled" : "disabled");
+
epc = devm_pci_epc_create(dev, _ops);
if (IS_ERR(epc)) {
dev_err(dev, "failed to create epc device\n");
diff --git a/drivers/pci/dwc/pcie-designware-host.c 
b/drivers/pci/dwc/pcie-designware-host.c
index 81e2157..d3f579e 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -574,17 +574,6 @@ static struct pci_ops dw_pcie_ops = {
.write = dw_pcie_wr_conf,
 };
 
-static u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
-{
-   u32 val;
-
-   val = dw_pcie_readl_dbi(pci, PCIE_ATU_VIEWPORT);
-   if (val == 0x)
-   return 1;
-
-   return 0;
-}
-
 void dw_pcie_setup_rc(struct pcie_port *pp)
 {
u32 val;
diff --git a/drivers/pci/dwc/pcie-designware.c 
b/drivers/pci/dwc/pcie-designware.c
index 88abddd..f15da90 100644
--- a/drivers/pci/dwc/pcie-designware.c
+++ b/drivers/pci/dwc/pcie-designware.c
@@ -92,6 +92,17 @@ void __dw_pcie_write_dbi(struct dw_pcie *pci, void __iomem 
*base, u32 reg,
dev_err(pci->dev, "write DBI address failed\n");
 }
 
+u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
+{
+   u32 val;
+
+   val = dw_pcie_readl_dbi(pci, PCIE_ATU_VIEWPORT);
+   if (val == 0x)
+   return 1;
+
+   return 0;
+}
+
 static u32 dw_pcie_readl_ob_unroll(struct dw_pcie *pci, u32 index, u32 reg)
 {
u32 offset = PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
diff --git a/drivers/pci/dwc/pcie-designware.h 
b/drivers/pci/dwc/pcie-designware.h
index e5d9d77..8d6829c 100644
--- a/drivers/pci/dwc/pcie-designware.h
+++ b/drivers/pci/dwc/pcie-designware.h
@@ -242,6 +242,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int 
index, int bar,
 void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
 enum dw_pcie_region_type type);
 void dw_pcie_setup(struct dw_pcie *pci);
+u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci);
 
 static inline void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 val)
 {
-- 
2.7.4

[PATCH] PCI: endpoint: handle probable NULL pointer access

[Pankaj Dubey]

controller_group allocation in pci_ep_cfs_init function can fail
so we should have a check while using it in pci_ep_cfs_add_epc_group
for registering group, else we will hit NULL pointer access.

This patch adds required check for the same and returns -EPROBE_DEFER,
so that endpoint controller driver probe can be reattempted later
in case controller_group is not allocated because pci_ep_cfs_init is
not yet called.

Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 drivers/pci/endpoint/pci-ep-cfs.c   | 7 ++-
 drivers/pci/endpoint/pci-epc-core.c | 4 
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
b/drivers/pci/endpoint/pci-ep-cfs.c
index 424fdd6..3cac818 100644
--- a/drivers/pci/endpoint/pci-ep-cfs.c
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -172,7 +172,12 @@ struct config_group *pci_ep_cfs_add_epc_group(const char 
*name)
group = _group->group;
 
config_group_init_type_name(group, name, _epc_type);
-   ret = configfs_register_group(controllers_group, group);
+
+   if (controllers_group)
+   ret = configfs_register_group(controllers_group, group);
+   else
+   ret = -EPROBE_DEFER;
+
if (ret) {
pr_err("failed to register configfs group for %s\n", name);
goto err_register_group;
diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index 42c2a11..d327a2a 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -518,6 +518,10 @@ __pci_epc_create(struct device *dev, const struct 
pci_epc_ops *ops,
goto put_dev;
 
epc->group = pci_ep_cfs_add_epc_group(dev_name(dev));
+   if (IS_ERR(epc->group)) {
+   ret = -EPROBE_DEFER;
+   goto put_dev;
+   }
 
return epc;
 
-- 
2.7.4

[PATCH] PCI: endpoint: handle probable NULL pointer access

[Pankaj Dubey]

controller_group allocation in pci_ep_cfs_init function can fail
so we should have a check while using it in pci_ep_cfs_add_epc_group
for registering group, else we will hit NULL pointer access.

This patch adds required check for the same and returns -EPROBE_DEFER,
so that endpoint controller driver probe can be reattempted later
in case controller_group is not allocated because pci_ep_cfs_init is
not yet called.

Signed-off-by: Pankaj Dubey 
---
 drivers/pci/endpoint/pci-ep-cfs.c   | 7 ++-
 drivers/pci/endpoint/pci-epc-core.c | 4 
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
b/drivers/pci/endpoint/pci-ep-cfs.c
index 424fdd6..3cac818 100644
--- a/drivers/pci/endpoint/pci-ep-cfs.c
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -172,7 +172,12 @@ struct config_group *pci_ep_cfs_add_epc_group(const char 
*name)
group = _group->group;
 
config_group_init_type_name(group, name, _epc_type);
-   ret = configfs_register_group(controllers_group, group);
+
+   if (controllers_group)
+   ret = configfs_register_group(controllers_group, group);
+   else
+   ret = -EPROBE_DEFER;
+
if (ret) {
pr_err("failed to register configfs group for %s\n", name);
goto err_register_group;
diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index 42c2a11..d327a2a 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -518,6 +518,10 @@ __pci_epc_create(struct device *dev, const struct 
pci_epc_ops *ops,
goto put_dev;
 
epc->group = pci_ep_cfs_add_epc_group(dev_name(dev));
+   if (IS_ERR(epc->group)) {
+   ret = -EPROBE_DEFER;
+   goto put_dev;
+   }
 
return epc;
 
-- 
2.7.4

[PATCH v3] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

From: Niyas Ahmed S T <niyas.ah...@samsung.com>

Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
This patch does refactoring of Exynos PCIe driver to extend support
for other Exynos SoC.

Following are the main changes done via this patch:

1) It adds separate structs for memory, clock resources.

Reason behind this change is, moving ahead various Exynos SoC will
have different hardware resources such as iomem, clocks, regmap handles
etc. for PCIe controller, so keeping these resources in separate struct
will help us in intiailizing them via per SoC ops, and will avoid too
many of_machine_is_compatible in code, and help us simplifying
exynos_pcie struct.

2) It add exynos_pcie_ops struct which will allow us to support the
differences in resources in different Exynos SoC.

No functional change intended.

Signed-off-by: Niyas Ahmed S T <niyas.ah...@samsung.com>
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
Acked-by: Krzysztof Kozlowski <k...@kernel.org>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>
Reviewed-by: Jaehoon Chung <jh80.ch...@samsung.com>
---
This patch set is prepared on top of Krzysztof's for-next and
PCIe driver cleanup patch-v3 [1] by Jaehoon Chung.

[1]: https://lkml.org/lkml/2017/1/16/19

Changes from v2:
 - Included Acked-by from Krzysztof
 - Rebased on top of cleanup patch-v3 from Jaehoon Chung and latest
   for-next of Krzysztof tree.

Changes from v1:
 - Addressed review comments from Krzysztof and Jingoo Han.

 drivers/pci/host/pci-exynos.c | 346 ++
 1 file changed, 217 insertions(+), 129 deletions(-)

diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index faee7d3..0f255ab 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,16 +29,6 @@
 
 #define to_exynos_pcie(x)  container_of(x, struct exynos_pcie, pp)
 
-struct exynos_pcie {
-   struct pcie_portpp;
-   void __iomem*elbi_base; /* DT 0th resource */
-   void __iomem*phy_base;  /* DT 1st resource */
-   void __iomem*block_base;/* DT 2nd resource */
-   int reset_gpio;
-   struct clk  *clk;
-   struct clk  *bus_clk;
-};
-
 /* PCIe ELBI registers */
 #define PCIE_IRQ_PULSE 0x000
 #define IRQ_INTA_ASSERTBIT(0)
@@ -102,6 +93,122 @@ struct exynos_pcie {
 #define PCIE_PHY_TRSV3_PD_TSV  BIT(7)
 #define PCIE_PHY_TRSV3_LVCC0x31c
 
+struct exynos_pcie_mem_res {
+   void __iomem *elbi_base; /* DT 0th resource: PCIE CTRL */
+   void __iomem *phy_base; /* DT 1st resource: PHY CTRL */
+   void __iomem *block_base; /* DT 2nd resource: PHY ADDITIONAL CTRL */
+};
+
+struct exynos_pcie_clk_res {
+   struct clk *clk;
+   struct clk *bus_clk;
+};
+
+struct exynos_pcie {
+   struct pcie_portpp;
+   struct exynos_pcie_mem_res  *mem_res;
+   struct exynos_pcie_clk_res  *clk_res;
+   const struct exynos_pcie_ops*ops;
+   int reset_gpio;
+};
+
+struct exynos_pcie_ops {
+   int (*get_mem_resources)(struct platform_device *pdev,
+   struct exynos_pcie *ep);
+   int (*get_clk_resources)(struct exynos_pcie *ep);
+   int (*init_clk_resources)(struct exynos_pcie *ep);
+   void (*deinit_clk_resources)(struct exynos_pcie *ep);
+};
+
+static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev,
+   struct exynos_pcie *ep)
+{
+   struct resource *res;
+   struct device *dev = ep->pp.dev;
+
+   ep->mem_res = devm_kzalloc(dev, sizeof(*ep->mem_res), GFP_KERNEL);
+   if (!ep->mem_res)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   ep->mem_res->elbi_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->elbi_base))
+   return PTR_ERR(ep->mem_res->elbi_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   ep->mem_res->phy_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->phy_base))
+   return PTR_ERR(ep->mem_res->phy_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   ep->mem_res->block_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->block_base))
+   return PTR_ERR(ep->mem_res->block_base);
+
+   return 0;
+}
+
+static int exynos5440_pcie_get_clk_resources(struct exynos_pcie *ep)
+{
+   struct device *dev = ep->pp.dev;
+
+   ep->clk_res = devm_kzalloc(dev, sizeo

[PATCH v3] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

From: Niyas Ahmed S T 

Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
This patch does refactoring of Exynos PCIe driver to extend support
for other Exynos SoC.

Following are the main changes done via this patch:

1) It adds separate structs for memory, clock resources.

Reason behind this change is, moving ahead various Exynos SoC will
have different hardware resources such as iomem, clocks, regmap handles
etc. for PCIe controller, so keeping these resources in separate struct
will help us in intiailizing them via per SoC ops, and will avoid too
many of_machine_is_compatible in code, and help us simplifying
exynos_pcie struct.

2) It add exynos_pcie_ops struct which will allow us to support the
differences in resources in different Exynos SoC.

No functional change intended.

Signed-off-by: Niyas Ahmed S T 
Signed-off-by: Pankaj Dubey 
Acked-by: Krzysztof Kozlowski 
Reviewed-by: Bartlomiej Zolnierkiewicz 
Reviewed-by: Alim Akhtar 
Reviewed-by: Jaehoon Chung 
---
This patch set is prepared on top of Krzysztof's for-next and
PCIe driver cleanup patch-v3 [1] by Jaehoon Chung.

[1]: https://lkml.org/lkml/2017/1/16/19

Changes from v2:
 - Included Acked-by from Krzysztof
 - Rebased on top of cleanup patch-v3 from Jaehoon Chung and latest
   for-next of Krzysztof tree.

Changes from v1:
 - Addressed review comments from Krzysztof and Jingoo Han.

 drivers/pci/host/pci-exynos.c | 346 ++
 1 file changed, 217 insertions(+), 129 deletions(-)

diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index faee7d3..0f255ab 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,16 +29,6 @@
 
 #define to_exynos_pcie(x)  container_of(x, struct exynos_pcie, pp)
 
-struct exynos_pcie {
-   struct pcie_portpp;
-   void __iomem*elbi_base; /* DT 0th resource */
-   void __iomem*phy_base;  /* DT 1st resource */
-   void __iomem*block_base;/* DT 2nd resource */
-   int reset_gpio;
-   struct clk  *clk;
-   struct clk  *bus_clk;
-};
-
 /* PCIe ELBI registers */
 #define PCIE_IRQ_PULSE 0x000
 #define IRQ_INTA_ASSERTBIT(0)
@@ -102,6 +93,122 @@ struct exynos_pcie {
 #define PCIE_PHY_TRSV3_PD_TSV  BIT(7)
 #define PCIE_PHY_TRSV3_LVCC0x31c
 
+struct exynos_pcie_mem_res {
+   void __iomem *elbi_base; /* DT 0th resource: PCIE CTRL */
+   void __iomem *phy_base; /* DT 1st resource: PHY CTRL */
+   void __iomem *block_base; /* DT 2nd resource: PHY ADDITIONAL CTRL */
+};
+
+struct exynos_pcie_clk_res {
+   struct clk *clk;
+   struct clk *bus_clk;
+};
+
+struct exynos_pcie {
+   struct pcie_portpp;
+   struct exynos_pcie_mem_res  *mem_res;
+   struct exynos_pcie_clk_res  *clk_res;
+   const struct exynos_pcie_ops*ops;
+   int reset_gpio;
+};
+
+struct exynos_pcie_ops {
+   int (*get_mem_resources)(struct platform_device *pdev,
+   struct exynos_pcie *ep);
+   int (*get_clk_resources)(struct exynos_pcie *ep);
+   int (*init_clk_resources)(struct exynos_pcie *ep);
+   void (*deinit_clk_resources)(struct exynos_pcie *ep);
+};
+
+static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev,
+   struct exynos_pcie *ep)
+{
+   struct resource *res;
+   struct device *dev = ep->pp.dev;
+
+   ep->mem_res = devm_kzalloc(dev, sizeof(*ep->mem_res), GFP_KERNEL);
+   if (!ep->mem_res)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   ep->mem_res->elbi_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->elbi_base))
+   return PTR_ERR(ep->mem_res->elbi_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   ep->mem_res->phy_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->phy_base))
+   return PTR_ERR(ep->mem_res->phy_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   ep->mem_res->block_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->block_base))
+   return PTR_ERR(ep->mem_res->block_base);
+
+   return 0;
+}
+
+static int exynos5440_pcie_get_clk_resources(struct exynos_pcie *ep)
+{
+   struct device *dev = ep->pp.dev;
+
+   ep->clk_res = devm_kzalloc(dev, sizeof(*ep->clk_res), GFP_KERNEL);
+   if (!ep->clk_res)
+   return -ENOMEM;
+
+   ep->clk_res->clk = devm_clk_get(dev, "pcie");
+   if (IS_ERR(ep->clk_res->clk)) {
+

[PATCH] arm64: dts: exynos: Remove address node from usb parent node

[Pankaj Dubey]

Address node does not required to be put after parent't node,
so remove address node from usb parent node.

Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 68f764e..0d7a55d 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -1285,7 +1285,7 @@
status = "disabled";
};
 
-   usbdrd30: usb@1540  {
+   usbdrd30: usb3-0 {
compatible = "samsung,exynos5250-dwusb3";
clocks = <_fsys CLK_ACLK_USBDRD30>,
<_fsys CLK_SCLK_USBDRD30>;
@@ -1332,7 +1332,7 @@
status = "disabled";
};
 
-   usbhost30: usb@15a0 {
+   usbhost30: usbhost3-0 {
compatible = "samsung,exynos5250-dwusb3";
clocks = <_fsys CLK_ACLK_USBHOST30>,
<_fsys CLK_SCLK_USBHOST30>;
-- 
2.7.4

[PATCH] arm64: dts: exynos: Remove address node from usb parent node

[Pankaj Dubey]

Address node does not required to be put after parent't node,
so remove address node from usb parent node.

Signed-off-by: Pankaj Dubey 
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 68f764e..0d7a55d 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -1285,7 +1285,7 @@
status = "disabled";
};
 
-   usbdrd30: usb@1540  {
+   usbdrd30: usb3-0 {
compatible = "samsung,exynos5250-dwusb3";
clocks = <_fsys CLK_ACLK_USBDRD30>,
<_fsys CLK_SCLK_USBDRD30>;
@@ -1332,7 +1332,7 @@
status = "disabled";
};
 
-   usbhost30: usb@15a0 {
+   usbhost30: usbhost3-0 {
compatible = "samsung,exynos5250-dwusb3";
clocks = <_fsys CLK_ACLK_USBHOST30>,
<_fsys CLK_SCLK_USBHOST30>;
-- 
2.7.4

[PATCH v2] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

From: Niyas Ahmed S T <niyas.ah...@samsung.com>

Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
This patch does refactoring of Exynos PCIe driver to extend support
for other Exynos SoC.

Following are the main changes done via this patch:

1) It adds separate structs for memory, clock resources.

Reason behind this change is, moving ahead various Exynos SoC will
have different hardware resources such as iomem, clocks, regmap handles
etc. for PCIe controller, so keeping these resources in separate struct
will help us in intiailizing them via per SoC ops, and will avoid too
many of_machine_is_compatible in code, and help us simplifying
exynos_pcie struct.

2) It add exynos_pcie_ops struct which will allow us to support the
differences in resources in different Exynos SoC.

No functional change intended.

Signed-off-by: Niyas Ahmed S T <niyas.ah...@samsung.com>
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
Acked-by: Krzysztof Kozlowski <k...@kernel.org>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
---
This patch set is prepared on top of Krzysztof's for-next and
PCIe driver cleanup patch [1] by Jaehoon Chung.

[1]: https://lkml.org/lkml/2016/12/19/44

Changes from v1:
 - Addressed review comments from Krzysztof and Jingoo Han.

 drivers/pci/host/pci-exynos.c | 348 ++
 1 file changed, 219 insertions(+), 129 deletions(-)

diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index 33562cf..d91751b 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,16 +29,6 @@
 
 #define to_exynos_pcie(x)  container_of(x, struct exynos_pcie, pp)
 
-struct exynos_pcie {
-   struct pcie_portpp;
-   void __iomem*elbi_base; /* DT 0th resource */
-   void __iomem*phy_base;  /* DT 1st resource */
-   void __iomem*block_base;/* DT 2nd resource */
-   int reset_gpio;
-   struct clk  *clk;
-   struct clk  *bus_clk;
-};
-
 /* PCIe ELBI registers */
 #define PCIE_IRQ_PULSE 0x000
 #define IRQ_INTA_ASSERTBIT(0)
@@ -102,6 +93,122 @@ struct exynos_pcie {
 #define PCIE_PHY_TRSV3_PD_TSV  BIT(7)
 #define PCIE_PHY_TRSV3_LVCC0x31c
 
+struct exynos_pcie_mem_res {
+   void __iomem *elbi_base; /* DT 0th resource: PCIE CTRL */
+   void __iomem *phy_base; /* DT 1st resource: PHY CTRL */
+   void __iomem *block_base; /* DT 2nd resource: PHY ADDITIONAL CTRL */
+};
+
+struct exynos_pcie_clk_res {
+   struct clk *clk;
+   struct clk *bus_clk;
+};
+
+struct exynos_pcie {
+   struct pcie_portpp;
+   struct exynos_pcie_mem_res  *mem_res;
+   struct exynos_pcie_clk_res  *clk_res;
+   const struct exynos_pcie_ops*ops;
+   int reset_gpio;
+};
+
+struct exynos_pcie_ops {
+   int (*get_mem_resources)(struct platform_device *pdev,
+   struct exynos_pcie *ep);
+   int (*get_clk_resources)(struct exynos_pcie *ep);
+   int (*init_clk_resources)(struct exynos_pcie *ep);
+   void (*deinit_clk_resources)(struct exynos_pcie *ep);
+};
+
+static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev,
+   struct exynos_pcie *ep)
+{
+   struct resource *res;
+   struct device *dev = ep->pp.dev;
+
+   ep->mem_res = devm_kzalloc(dev, sizeof(*ep->mem_res), GFP_KERNEL);
+   if (!ep->mem_res)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   ep->mem_res->elbi_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->elbi_base))
+   return PTR_ERR(ep->mem_res->elbi_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   ep->mem_res->phy_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->phy_base))
+   return PTR_ERR(ep->mem_res->phy_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   ep->mem_res->block_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->block_base))
+   return PTR_ERR(ep->mem_res->block_base);
+
+   return 0;
+}
+
+static int exynos5440_pcie_get_clk_resources(struct exynos_pcie *ep)
+{
+   struct device *dev = ep->pp.dev;
+
+   ep->clk_res = devm_kzalloc(dev, sizeof(*ep->clk_res), GFP_KERNEL);
+   if (!ep->clk_res)
+   return -ENOMEM;
+
+   ep->clk_res->clk = devm_clk_get(dev, "pcie");
+   if (IS_ERR(ep->clk_res->clk)) {
+   dev_err(dev, "Failed to get pcie

[PATCH v2] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

From: Niyas Ahmed S T 

Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
This patch does refactoring of Exynos PCIe driver to extend support
for other Exynos SoC.

Following are the main changes done via this patch:

1) It adds separate structs for memory, clock resources.

Reason behind this change is, moving ahead various Exynos SoC will
have different hardware resources such as iomem, clocks, regmap handles
etc. for PCIe controller, so keeping these resources in separate struct
will help us in intiailizing them via per SoC ops, and will avoid too
many of_machine_is_compatible in code, and help us simplifying
exynos_pcie struct.

2) It add exynos_pcie_ops struct which will allow us to support the
differences in resources in different Exynos SoC.

No functional change intended.

Signed-off-by: Niyas Ahmed S T 
Signed-off-by: Pankaj Dubey 
Acked-by: Krzysztof Kozlowski 
Reviewed-by: Bartlomiej Zolnierkiewicz 
---
This patch set is prepared on top of Krzysztof's for-next and
PCIe driver cleanup patch [1] by Jaehoon Chung.

[1]: https://lkml.org/lkml/2016/12/19/44

Changes from v1:
 - Addressed review comments from Krzysztof and Jingoo Han.

 drivers/pci/host/pci-exynos.c | 348 ++
 1 file changed, 219 insertions(+), 129 deletions(-)

diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index 33562cf..d91751b 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,16 +29,6 @@
 
 #define to_exynos_pcie(x)  container_of(x, struct exynos_pcie, pp)
 
-struct exynos_pcie {
-   struct pcie_portpp;
-   void __iomem*elbi_base; /* DT 0th resource */
-   void __iomem*phy_base;  /* DT 1st resource */
-   void __iomem*block_base;/* DT 2nd resource */
-   int reset_gpio;
-   struct clk  *clk;
-   struct clk  *bus_clk;
-};
-
 /* PCIe ELBI registers */
 #define PCIE_IRQ_PULSE 0x000
 #define IRQ_INTA_ASSERTBIT(0)
@@ -102,6 +93,122 @@ struct exynos_pcie {
 #define PCIE_PHY_TRSV3_PD_TSV  BIT(7)
 #define PCIE_PHY_TRSV3_LVCC0x31c
 
+struct exynos_pcie_mem_res {
+   void __iomem *elbi_base; /* DT 0th resource: PCIE CTRL */
+   void __iomem *phy_base; /* DT 1st resource: PHY CTRL */
+   void __iomem *block_base; /* DT 2nd resource: PHY ADDITIONAL CTRL */
+};
+
+struct exynos_pcie_clk_res {
+   struct clk *clk;
+   struct clk *bus_clk;
+};
+
+struct exynos_pcie {
+   struct pcie_portpp;
+   struct exynos_pcie_mem_res  *mem_res;
+   struct exynos_pcie_clk_res  *clk_res;
+   const struct exynos_pcie_ops*ops;
+   int reset_gpio;
+};
+
+struct exynos_pcie_ops {
+   int (*get_mem_resources)(struct platform_device *pdev,
+   struct exynos_pcie *ep);
+   int (*get_clk_resources)(struct exynos_pcie *ep);
+   int (*init_clk_resources)(struct exynos_pcie *ep);
+   void (*deinit_clk_resources)(struct exynos_pcie *ep);
+};
+
+static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev,
+   struct exynos_pcie *ep)
+{
+   struct resource *res;
+   struct device *dev = ep->pp.dev;
+
+   ep->mem_res = devm_kzalloc(dev, sizeof(*ep->mem_res), GFP_KERNEL);
+   if (!ep->mem_res)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   ep->mem_res->elbi_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->elbi_base))
+   return PTR_ERR(ep->mem_res->elbi_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   ep->mem_res->phy_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->phy_base))
+   return PTR_ERR(ep->mem_res->phy_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   ep->mem_res->block_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->block_base))
+   return PTR_ERR(ep->mem_res->block_base);
+
+   return 0;
+}
+
+static int exynos5440_pcie_get_clk_resources(struct exynos_pcie *ep)
+{
+   struct device *dev = ep->pp.dev;
+
+   ep->clk_res = devm_kzalloc(dev, sizeof(*ep->clk_res), GFP_KERNEL);
+   if (!ep->clk_res)
+   return -ENOMEM;
+
+   ep->clk_res->clk = devm_clk_get(dev, "pcie");
+   if (IS_ERR(ep->clk_res->clk)) {
+   dev_err(dev, "Failed to get pcie rc clock\n");
+   return PTR_ERR(ep->clk_res->clk);
+   }
+
+   ep->clk_res->bus_clk = devm_clk_get(

Re: [PATCH] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

Hi Bartlomiej,

On 27 December 2016 at 19:05, Bartlomiej Zolnierkiewicz
<b.zolnier...@samsung.com> wrote:
>
> Hi,
>
> On Friday, December 23, 2016 04:26:27 PM Pankaj Dubey wrote:
>> From: Niyas Ahmed S T <niyas.ah...@samsung.com>
>>
>> Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
>> This patch does refactoring of Exynos PCIe driver to extend support
>> for other Exynos SoC.
>>
>> Following are the main changes done via this patch:
>> 1) It adds separate structs for memory, clock resources.
>> 2) It add exynos_pcie_ops struct which will allow us to support the
>> differences in resources in different Exynos SoC.
>>
>> No functional change intended.
>>
>> Signed-off-by: Niyas Ahmed S T <niyas.ah...@samsung.com>
>> Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
>
> I would also like to see the explanation for 1) (as already
> requested by Jingoo).  Otherwise it all looks fine to me:
>
> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
>

Thanks for review and Reviewed-by tag.

In other thread as a reply to Jaehoon, I have explained reason behind
point no 1, I hope this reason is sufficient to separate these
resources from main exynos_pcie structs.

Thanks,
Pankaj Dubey

> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

Hi Bartlomiej,

On 27 December 2016 at 19:05, Bartlomiej Zolnierkiewicz
 wrote:
>
> Hi,
>
> On Friday, December 23, 2016 04:26:27 PM Pankaj Dubey wrote:
>> From: Niyas Ahmed S T 
>>
>> Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
>> This patch does refactoring of Exynos PCIe driver to extend support
>> for other Exynos SoC.
>>
>> Following are the main changes done via this patch:
>> 1) It adds separate structs for memory, clock resources.
>> 2) It add exynos_pcie_ops struct which will allow us to support the
>> differences in resources in different Exynos SoC.
>>
>> No functional change intended.
>>
>> Signed-off-by: Niyas Ahmed S T 
>> Signed-off-by: Pankaj Dubey 
>
> I would also like to see the explanation for 1) (as already
> requested by Jingoo).  Otherwise it all looks fine to me:
>
> Reviewed-by: Bartlomiej Zolnierkiewicz 
>

Thanks for review and Reviewed-by tag.

In other thread as a reply to Jaehoon, I have explained reason behind
point no 1, I hope this reason is sufficient to separate these
resources from main exynos_pcie structs.

Thanks,
Pankaj Dubey

> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

Hi Jaehoon,

On 27 December 2016 at 15:48, Jaehoon Chung <jh80.ch...@samsung.com> wrote:
> Dear Alim,
>
> On 12/27/2016 03:34 PM, Alim Akhtar wrote:
>> Hi Jaehoon,
>>
> [snip]
>>>
>>> Ah. Right..And i'm doing the refactoring to reuse the current pci-exynos.c.
>> There is a nice refactoring patch posted by Pankaj recently @
>> https://lkml.org/lkml/2016/12/23/73
>> I would suggest you to rebase your work on this top.
>
> Well, i don't think so. Pankaj's patch might be good way..but i can't agree 
> about a few point.
> If based on Pankaj's patch, it's more complex..
>
> why put the ops callback for getting clock and mem resource?
>

I think I replied reason behind this in reply to Jingoo. Well I will
explain with some example here. Current exynos_pcie struct contains
all mem, phy, gpio and clock resources in one place and this driver is
supported only for Exynos5440. Until this it was fine. As Jingoo
mentioned when he up streamed this driver, generic phy framework was
not ready so he used phy_base along with some additional phy related
sfr base in pcie driver itself.

Moving ahead for adding support for PCIe module on Exynos7, Exynos5433
or other existing Exynos (non-mainlined) and some of upcoming SoC
seeing the differences in these resources (mem, clk, regmap handles,
gpio etc.) we will endup adding following kind of code in probe to get
these resources from DT

if (of_machine_is_compatible(exynos7420)) {
/* get certain mem resources */
/* get certain clock resources */
/* get certain regmap handle resources if required */
} else if (of_machine_is_compatble(exynos5433)) {
/* get certain but may be different mem resources */
/* get certain clock resources */
/* get certain regmap handle resources if required */
} else if (of_machine_is_compatible(exynos)) {
  //may be something else
}

for giving real example, exynos7420 does not uses only two clocks
"bus", "pcie_bus" there are other clocks required to be taken care in
driver. It also need to take care of pmu regmap handle and sysreg
regmap handle.

So if we keep exynos_pcie as only struct then we will keep adding all
these resources in only one struct making it more complex. Also
resource initialization part will become complex. For the same reason
I decided to separate these rather keeping them in single struct. This
is very obvious design used in many drivers (samsung or other
vendors). Just to give one more example see pcie-qcom.c where they
also have different clocks and it is managed in same fashion.

> If PHY generic framework is used, it's unnecessary. because it needs to get 
> elbi and dbi resources.

Surely elbi and dbi are fixed, but as we already have one example of
exynos5440 which used block_base (additional SFR base other than phy
base), I can see some of existing and upcoming SoC will need more SFR
base than these two, it all depends on how h/w engineers design these
modules and distribute SFR access.

> clock resources("pcie" and "pcie_bus") are general things.
>

With current Exynos SoCs which have PCIe hardware modules I can see
this will not remain uniform across various SoCs, some of them require
more clocks to be handled by PCIe driver.

> If Pankaj's patch is applied, also need to make the exynos5433_pcie_* 
> callback functions?
> It doesn't make sense.
>

Adding exynos5433_pcie_ops struct and hooks specific to the exynos5433
is a small overhead compared to the flexibility it provides. This will
make current driver flexibility with less
of_machine_is_compatible(...) kind of conditional statement, less
complex exynos_pcie struct.
For the hooks of exynos_pcie_ops also if two different Exynos SoC
shares same mem, clock and other resources the actual hooks will point
to same functions so no overhead of implementing these for each SoC.
Only separate implementation will be required if they differ in these
resources. This approach also very common across various drivers
nothing special here.

I hope I am clear in explaining the intention and pros and cons of
both approaches.

> I want to know maintainer's opinion..we can just touch a little for 
> supporting All Exynos SoCs.
>

I also have same intention but design should be flexible to adopt
future SoC at least some of them which we are seeing will be supported
soon and we can see the differences.

Thanks,
Pankaj Dubey

> Best Regards,
> Jaehoon Chung
>
>>
>>> Maybe..Today or Tomorrow..I will send the patches..At that time, could you 
>>> also check them?
>>> Any comments might be helpful to me! :)
>>>
>> Will wait for you patches :-)
>>
>>> Best Regards,
>>> Jaehoon Chung
>>>
> [snip]
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

Hi Jaehoon,

On 27 December 2016 at 15:48, Jaehoon Chung  wrote:
> Dear Alim,
>
> On 12/27/2016 03:34 PM, Alim Akhtar wrote:
>> Hi Jaehoon,
>>
> [snip]
>>>
>>> Ah. Right..And i'm doing the refactoring to reuse the current pci-exynos.c.
>> There is a nice refactoring patch posted by Pankaj recently @
>> https://lkml.org/lkml/2016/12/23/73
>> I would suggest you to rebase your work on this top.
>
> Well, i don't think so. Pankaj's patch might be good way..but i can't agree 
> about a few point.
> If based on Pankaj's patch, it's more complex..
>
> why put the ops callback for getting clock and mem resource?
>

I think I replied reason behind this in reply to Jingoo. Well I will
explain with some example here. Current exynos_pcie struct contains
all mem, phy, gpio and clock resources in one place and this driver is
supported only for Exynos5440. Until this it was fine. As Jingoo
mentioned when he up streamed this driver, generic phy framework was
not ready so he used phy_base along with some additional phy related
sfr base in pcie driver itself.

Moving ahead for adding support for PCIe module on Exynos7, Exynos5433
or other existing Exynos (non-mainlined) and some of upcoming SoC
seeing the differences in these resources (mem, clk, regmap handles,
gpio etc.) we will endup adding following kind of code in probe to get
these resources from DT

if (of_machine_is_compatible(exynos7420)) {
/* get certain mem resources */
/* get certain clock resources */
/* get certain regmap handle resources if required */
} else if (of_machine_is_compatble(exynos5433)) {
/* get certain but may be different mem resources */
/* get certain clock resources */
/* get certain regmap handle resources if required */
} else if (of_machine_is_compatible(exynos)) {
  //may be something else
}

for giving real example, exynos7420 does not uses only two clocks
"bus", "pcie_bus" there are other clocks required to be taken care in
driver. It also need to take care of pmu regmap handle and sysreg
regmap handle.

So if we keep exynos_pcie as only struct then we will keep adding all
these resources in only one struct making it more complex. Also
resource initialization part will become complex. For the same reason
I decided to separate these rather keeping them in single struct. This
is very obvious design used in many drivers (samsung or other
vendors). Just to give one more example see pcie-qcom.c where they
also have different clocks and it is managed in same fashion.

> If PHY generic framework is used, it's unnecessary. because it needs to get 
> elbi and dbi resources.

Surely elbi and dbi are fixed, but as we already have one example of
exynos5440 which used block_base (additional SFR base other than phy
base), I can see some of existing and upcoming SoC will need more SFR
base than these two, it all depends on how h/w engineers design these
modules and distribute SFR access.

> clock resources("pcie" and "pcie_bus") are general things.
>

With current Exynos SoCs which have PCIe hardware modules I can see
this will not remain uniform across various SoCs, some of them require
more clocks to be handled by PCIe driver.

> If Pankaj's patch is applied, also need to make the exynos5433_pcie_* 
> callback functions?
> It doesn't make sense.
>

Adding exynos5433_pcie_ops struct and hooks specific to the exynos5433
is a small overhead compared to the flexibility it provides. This will
make current driver flexibility with less
of_machine_is_compatible(...) kind of conditional statement, less
complex exynos_pcie struct.
For the hooks of exynos_pcie_ops also if two different Exynos SoC
shares same mem, clock and other resources the actual hooks will point
to same functions so no overhead of implementing these for each SoC.
Only separate implementation will be required if they differ in these
resources. This approach also very common across various drivers
nothing special here.

I hope I am clear in explaining the intention and pros and cons of
both approaches.

> I want to know maintainer's opinion..we can just touch a little for 
> supporting All Exynos SoCs.
>

I also have same intention but design should be flexible to adopt
future SoC at least some of them which we are seeing will be supported
soon and we can see the differences.

Thanks,
Pankaj Dubey

> Best Regards,
> Jaehoon Chung
>
>>
>>> Maybe..Today or Tomorrow..I will send the patches..At that time, could you 
>>> also check them?
>>> Any comments might be helpful to me! :)
>>>
>> Will wait for you patches :-)
>>
>>> Best Regards,
>>> Jaehoon Chung
>>>
> [snip]
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

Hi Jaehoon,

On 26 December 2016 at 14:32, Jaehoon Chung <jh80.ch...@samsung.com> wrote:
> Hi Pankaj,
>
> On 12/23/2016 07:56 PM, Pankaj Dubey wrote:
>> From: Niyas Ahmed S T <niyas.ah...@samsung.com>
>>
>> Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
>> This patch does refactoring of Exynos PCIe driver to extend support
>> for other Exynos SoC.
>>
>> Following are the main changes done via this patch:
>> 1) It adds separate structs for memory, clock resources.
>> 2) It add exynos_pcie_ops struct which will allow us to support the
>> differences in resources in different Exynos SoC.
>
> It's nice to me for reusing this file.
> but after considering too many times, i decided not to use this file.
>

It would be better if we redesign/modify existing driver to support new single
driver for all Exynos SoC.

For this we can have internal discussion and design it so that it
becomes suitable
for other Exynos SoC PCIe controllers.

> I'm not sure what block base is..actually this pci-exynos.c is really 
> black-box.

I saw Jingoo already explained about block base, so it may or may not be used in
other exynos. If it is used they can reuse this variable and related
code, if not the
implementation of exynos_pcie_ops hooks should be written in such a way that
ignores (do not initializes/uses) block_base.

> (No one maintains this file, even Samsung didn't care.)
> Who is using this?

I feel now we we (you and me) will care for it, at least we have use
case for this now :)

> If Someone can share the information about exynos5440, i can refactor 
> everything.
> Otherwise, there are two solution..
>

We also do not have access to exynos5440 hardware, but we do have access
to exynos5440 UM, so we can see some details of these SFRs. Based on
our understanding
we refactored this code for making it more suitable for other SoC.

Regarding phy_base and block_base as they are phy related it need to
be replaced with phy driver, so for this we can reuse your RFC patch
of pcie-phy. Even phy driver design should be
such that it can support multiple Exynos SoC PCIe-Phy.

> One is "adding the new pci-exynos.c" likes pci-exynos5433.c

I know exynos5433 and exynos7 SoC have similar PCIe controller, although they
may share comparatively less similarity with exynos5440. If start
adding new file for
each SoC we may end of lot of code duplication.

> Other is "refactor this file" under assuming the each register's usage.
>

IMHO, this would be good design decision.

We have separate various resources of exynos_pcie struct such as iomem
and clks for
the timebeing, and these resources can be managed via exynos_pcie_ops
which can have different implementation for different SoCs, we have
freedom to handle these resources per SoC. If some SoCs share similar
PCIe controller h/w design, code will be reused.

> I want to use the PHY generic Framework for EXYNOS PCIe.
>
> If you or other guys really want to use the pci-exynos.c for other exynos,
> I will rework with PHY generic framework. Then i will resend the my patches 
> as V2.
>
> One more thing..Does anyone know what the usage of block base is?
> Can i use that register as "syscon"?
>

I think this is not exactly syscon, as it only be used in pcie-phy,
so we can use this as child device of phy-device.

> Best Regards,
> Jaehoon Chung
>

Thanks,
Pankaj Dubey

Re: [PATCH] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

Hi Jaehoon,

On 26 December 2016 at 14:32, Jaehoon Chung  wrote:
> Hi Pankaj,
>
> On 12/23/2016 07:56 PM, Pankaj Dubey wrote:
>> From: Niyas Ahmed S T 
>>
>> Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
>> This patch does refactoring of Exynos PCIe driver to extend support
>> for other Exynos SoC.
>>
>> Following are the main changes done via this patch:
>> 1) It adds separate structs for memory, clock resources.
>> 2) It add exynos_pcie_ops struct which will allow us to support the
>> differences in resources in different Exynos SoC.
>
> It's nice to me for reusing this file.
> but after considering too many times, i decided not to use this file.
>

It would be better if we redesign/modify existing driver to support new single
driver for all Exynos SoC.

For this we can have internal discussion and design it so that it
becomes suitable
for other Exynos SoC PCIe controllers.

> I'm not sure what block base is..actually this pci-exynos.c is really 
> black-box.

I saw Jingoo already explained about block base, so it may or may not be used in
other exynos. If it is used they can reuse this variable and related
code, if not the
implementation of exynos_pcie_ops hooks should be written in such a way that
ignores (do not initializes/uses) block_base.

> (No one maintains this file, even Samsung didn't care.)
> Who is using this?

I feel now we we (you and me) will care for it, at least we have use
case for this now :)

> If Someone can share the information about exynos5440, i can refactor 
> everything.
> Otherwise, there are two solution..
>

We also do not have access to exynos5440 hardware, but we do have access
to exynos5440 UM, so we can see some details of these SFRs. Based on
our understanding
we refactored this code for making it more suitable for other SoC.

Regarding phy_base and block_base as they are phy related it need to
be replaced with phy driver, so for this we can reuse your RFC patch
of pcie-phy. Even phy driver design should be
such that it can support multiple Exynos SoC PCIe-Phy.

> One is "adding the new pci-exynos.c" likes pci-exynos5433.c

I know exynos5433 and exynos7 SoC have similar PCIe controller, although they
may share comparatively less similarity with exynos5440. If start
adding new file for
each SoC we may end of lot of code duplication.

> Other is "refactor this file" under assuming the each register's usage.
>

IMHO, this would be good design decision.

We have separate various resources of exynos_pcie struct such as iomem
and clks for
the timebeing, and these resources can be managed via exynos_pcie_ops
which can have different implementation for different SoCs, we have
freedom to handle these resources per SoC. If some SoCs share similar
PCIe controller h/w design, code will be reused.

> I want to use the PHY generic Framework for EXYNOS PCIe.
>
> If you or other guys really want to use the pci-exynos.c for other exynos,
> I will rework with PHY generic framework. Then i will resend the my patches 
> as V2.
>
> One more thing..Does anyone know what the usage of block base is?
> Can i use that register as "syscon"?
>

I think this is not exactly syscon, as it only be used in pcie-phy,
so we can use this as child device of phy-device.

> Best Regards,
> Jaehoon Chung
>

Thanks,
Pankaj Dubey

Re: [PATCH] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

Hi Jingoo,

On 24 December 2016 at 00:07, Jingoo Han <jingooh...@gmail.com> wrote:
> On Friday, December 23, 2016 5:56 AM, Pankaj Dubey wrote:
>>
>> From: Niyas Ahmed S T <niyas.ah...@samsung.com>
>>
>> Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
>> This patch does refactoring of Exynos PCIe driver to extend support
>> for other Exynos SoC.
>>
>> Following are the main changes done via this patch:
>> 1) It adds separate structs for memory, clock resources.
>
> What is the reason to separate structs for these?
> Please add the reason to this commit message.
> It will be helpful.
>

As we know current driver only supports exynos5440 specific PCIe controller,
We also know for sure that different variant of Exynos SoC will have different
hardware resources such as iomem, clks, regmap handles etc. for PCIe
controller, so our intention behind separating these resources was to make
exynos_pcie struct simple instead of making it complex. All data structs will be
shared by all Exynos SoCs but different exynos_pcie_ops will give them freedom
to use them as per SoC need.

We have refactored current driver in such a way that, even with very minimal
information about exynos5440 we can add support for new SoC's PCIe controller
with maximum core reuse.

>> 2) It add exynos_pcie_ops struct which will allow us to support the
>> differences in resources in different Exynos SoC.
>

Thanks for review. Please let us know if you have any other concern, and it
would be great if you can review this patch more thoroughly.

Thanks,
Pankaj

> Good. I have no objection.
>
> Best regards,
> Jingoo Han
>
>>
>> No functional change intended.
>>
>> Signed-off-by: Niyas Ahmed S T <niyas.ah...@samsung.com>
>> Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
>> ---
>> This patch set is prepared on top of Krzysztof's for-next and
>> PCIe driver cleanup patch [1] by Jaehoon Chung.
>>
>> [1]: https://lkml.org/lkml/2016/12/19/44
>>
>>
>>  drivers/pci/host/pci-exynos.c | 346 ++---
>> -
>>  1 file changed, 217 insertions(+), 129 deletions(-)
>>
>> diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
>> index 33562cf..2dc54f7 100644
>> --- a/drivers/pci/host/pci-exynos.c
>> +++ b/drivers/pci/host/pci-exynos.c
>> @@ -17,6 +17,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -28,16 +29,6 @@
>>
>>  #define to_exynos_pcie(x)container_of(x, struct exynos_pcie, pp)
>>
>> -struct exynos_pcie {
>> - struct pcie_portpp;
>> - void __iomem*elbi_base; /* DT 0th resource */
>> - void __iomem*phy_base;  /* DT 1st resource */
>> - void __iomem*block_base;/* DT 2nd resource */
>> - int reset_gpio;
>> - struct clk  *clk;
>> - struct clk  *bus_clk;
>> -};
>> -
>>  /* PCIe ELBI registers */
>>  #define PCIE_IRQ_PULSE   0x000
>>  #define IRQ_INTA_ASSERT  BIT(0)
>> @@ -102,6 +93,122 @@ struct exynos_pcie {
>>  #define PCIE_PHY_TRSV3_PD_TSVBIT(7)
>>  #define PCIE_PHY_TRSV3_LVCC  0x31c
>>
>> +struct exynos_pcie_mem_res {
>> + void __iomem *elbi_base; /* DT 0th resource: PCIE CTRL */
>> + void __iomem *phy_base; /* DT 1st resource: PHY CTRL */
>> + void __iomem *block_base; /* DT 2nd resource: PHY ADDITIONAL CTRL
>> */
>> +};
>> +
>> +struct exynos_pcie_clk_res {
>> + struct clk *clk;
>> + struct clk *bus_clk;
>> +};
>> +
>> +struct exynos_pcie {
>> + struct pcie_portpp;
>> + struct exynos_pcie_mem_res  *mem_res;
>> + struct exynos_pcie_clk_res  *clk_res;
>> + const struct exynos_pcie_ops*ops;
>> + int reset_gpio;
>> +};
>> +
>> +struct exynos_pcie_ops {
>> + int (*get_mem_resources)(struct platform_device *pdev,
>> + struct exynos_pcie *ep);
>> + int (*get_clk_resources)(struct exynos_pcie *ep);
>> + int (*init_clk_resources)(struct exynos_pcie *ep);
>> + void (*deinit_clk_resources)(struct exynos_pcie *ep);
>> +};
>> +
>> +static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev,
>> + struct exynos_pcie *ep)
>> +{
>> + struc

Re: [PATCH] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

Hi Jingoo,

On 24 December 2016 at 00:07, Jingoo Han  wrote:
> On Friday, December 23, 2016 5:56 AM, Pankaj Dubey wrote:
>>
>> From: Niyas Ahmed S T 
>>
>> Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
>> This patch does refactoring of Exynos PCIe driver to extend support
>> for other Exynos SoC.
>>
>> Following are the main changes done via this patch:
>> 1) It adds separate structs for memory, clock resources.
>
> What is the reason to separate structs for these?
> Please add the reason to this commit message.
> It will be helpful.
>

As we know current driver only supports exynos5440 specific PCIe controller,
We also know for sure that different variant of Exynos SoC will have different
hardware resources such as iomem, clks, regmap handles etc. for PCIe
controller, so our intention behind separating these resources was to make
exynos_pcie struct simple instead of making it complex. All data structs will be
shared by all Exynos SoCs but different exynos_pcie_ops will give them freedom
to use them as per SoC need.

We have refactored current driver in such a way that, even with very minimal
information about exynos5440 we can add support for new SoC's PCIe controller
with maximum core reuse.

>> 2) It add exynos_pcie_ops struct which will allow us to support the
>> differences in resources in different Exynos SoC.
>

Thanks for review. Please let us know if you have any other concern, and it
would be great if you can review this patch more thoroughly.

Thanks,
Pankaj

> Good. I have no objection.
>
> Best regards,
> Jingoo Han
>
>>
>> No functional change intended.
>>
>> Signed-off-by: Niyas Ahmed S T 
>> Signed-off-by: Pankaj Dubey 
>> ---
>> This patch set is prepared on top of Krzysztof's for-next and
>> PCIe driver cleanup patch [1] by Jaehoon Chung.
>>
>> [1]: https://lkml.org/lkml/2016/12/19/44
>>
>>
>>  drivers/pci/host/pci-exynos.c | 346 ++---
>> -
>>  1 file changed, 217 insertions(+), 129 deletions(-)
>>
>> diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
>> index 33562cf..2dc54f7 100644
>> --- a/drivers/pci/host/pci-exynos.c
>> +++ b/drivers/pci/host/pci-exynos.c
>> @@ -17,6 +17,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -28,16 +29,6 @@
>>
>>  #define to_exynos_pcie(x)container_of(x, struct exynos_pcie, pp)
>>
>> -struct exynos_pcie {
>> - struct pcie_portpp;
>> - void __iomem*elbi_base; /* DT 0th resource */
>> - void __iomem*phy_base;  /* DT 1st resource */
>> - void __iomem*block_base;/* DT 2nd resource */
>> - int reset_gpio;
>> - struct clk  *clk;
>> - struct clk  *bus_clk;
>> -};
>> -
>>  /* PCIe ELBI registers */
>>  #define PCIE_IRQ_PULSE   0x000
>>  #define IRQ_INTA_ASSERT  BIT(0)
>> @@ -102,6 +93,122 @@ struct exynos_pcie {
>>  #define PCIE_PHY_TRSV3_PD_TSVBIT(7)
>>  #define PCIE_PHY_TRSV3_LVCC  0x31c
>>
>> +struct exynos_pcie_mem_res {
>> + void __iomem *elbi_base; /* DT 0th resource: PCIE CTRL */
>> + void __iomem *phy_base; /* DT 1st resource: PHY CTRL */
>> + void __iomem *block_base; /* DT 2nd resource: PHY ADDITIONAL CTRL
>> */
>> +};
>> +
>> +struct exynos_pcie_clk_res {
>> + struct clk *clk;
>> + struct clk *bus_clk;
>> +};
>> +
>> +struct exynos_pcie {
>> + struct pcie_portpp;
>> + struct exynos_pcie_mem_res  *mem_res;
>> + struct exynos_pcie_clk_res  *clk_res;
>> + const struct exynos_pcie_ops*ops;
>> + int reset_gpio;
>> +};
>> +
>> +struct exynos_pcie_ops {
>> + int (*get_mem_resources)(struct platform_device *pdev,
>> + struct exynos_pcie *ep);
>> + int (*get_clk_resources)(struct exynos_pcie *ep);
>> + int (*init_clk_resources)(struct exynos_pcie *ep);
>> + void (*deinit_clk_resources)(struct exynos_pcie *ep);
>> +};
>> +
>> +static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev,
>> + struct exynos_pcie *ep)
>> +{
>> + struct resource *res;
>> + struct device *dev = ep->pp.dev;
>> +
>> + ep->mem_res = devm_kzalloc(dev, 

[PATCH] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

From: Niyas Ahmed S T <niyas.ah...@samsung.com>

Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
This patch does refactoring of Exynos PCIe driver to extend support
for other Exynos SoC.

Following are the main changes done via this patch:
1) It adds separate structs for memory, clock resources.
2) It add exynos_pcie_ops struct which will allow us to support the
differences in resources in different Exynos SoC.

No functional change intended.

Signed-off-by: Niyas Ahmed S T <niyas.ah...@samsung.com>
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
This patch set is prepared on top of Krzysztof's for-next and
PCIe driver cleanup patch [1] by Jaehoon Chung.

[1]: https://lkml.org/lkml/2016/12/19/44


 drivers/pci/host/pci-exynos.c | 346 ++
 1 file changed, 217 insertions(+), 129 deletions(-)

diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index 33562cf..2dc54f7 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,16 +29,6 @@
 
 #define to_exynos_pcie(x)  container_of(x, struct exynos_pcie, pp)
 
-struct exynos_pcie {
-   struct pcie_portpp;
-   void __iomem*elbi_base; /* DT 0th resource */
-   void __iomem*phy_base;  /* DT 1st resource */
-   void __iomem*block_base;/* DT 2nd resource */
-   int reset_gpio;
-   struct clk  *clk;
-   struct clk  *bus_clk;
-};
-
 /* PCIe ELBI registers */
 #define PCIE_IRQ_PULSE 0x000
 #define IRQ_INTA_ASSERTBIT(0)
@@ -102,6 +93,122 @@ struct exynos_pcie {
 #define PCIE_PHY_TRSV3_PD_TSV  BIT(7)
 #define PCIE_PHY_TRSV3_LVCC0x31c
 
+struct exynos_pcie_mem_res {
+   void __iomem *elbi_base; /* DT 0th resource: PCIE CTRL */
+   void __iomem *phy_base; /* DT 1st resource: PHY CTRL */
+   void __iomem *block_base; /* DT 2nd resource: PHY ADDITIONAL CTRL */
+};
+
+struct exynos_pcie_clk_res {
+   struct clk *clk;
+   struct clk *bus_clk;
+};
+
+struct exynos_pcie {
+   struct pcie_portpp;
+   struct exynos_pcie_mem_res  *mem_res;
+   struct exynos_pcie_clk_res  *clk_res;
+   const struct exynos_pcie_ops*ops;
+   int reset_gpio;
+};
+
+struct exynos_pcie_ops {
+   int (*get_mem_resources)(struct platform_device *pdev,
+   struct exynos_pcie *ep);
+   int (*get_clk_resources)(struct exynos_pcie *ep);
+   int (*init_clk_resources)(struct exynos_pcie *ep);
+   void (*deinit_clk_resources)(struct exynos_pcie *ep);
+};
+
+static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev,
+   struct exynos_pcie *ep)
+{
+   struct resource *res;
+   struct device *dev = ep->pp.dev;
+
+   ep->mem_res = devm_kzalloc(dev, sizeof(*ep->mem_res), GFP_KERNEL);
+   if (!ep->mem_res)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   ep->mem_res->elbi_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->elbi_base))
+   return PTR_ERR(ep->mem_res->elbi_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   ep->mem_res->phy_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->phy_base))
+   return PTR_ERR(ep->mem_res->phy_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   ep->mem_res->block_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->block_base))
+   return PTR_ERR(ep->mem_res->block_base);
+
+   return 0;
+}
+
+static int exynos5440_pcie_get_clk_resources(struct exynos_pcie *ep)
+{
+   struct device *dev = ep->pp.dev;
+
+   ep->clk_res = devm_kzalloc(dev, sizeof(*ep->clk_res), GFP_KERNEL);
+   if (!ep->clk_res)
+   return -ENOMEM;
+
+   ep->clk_res->clk = devm_clk_get(dev, "pcie");
+   if (IS_ERR(ep->clk_res->clk)) {
+   dev_err(dev, "Failed to get pcie rc clock\n");
+   return PTR_ERR(ep->clk_res->clk);
+   }
+
+   ep->clk_res->bus_clk = devm_clk_get(dev, "pcie_bus");
+   if (IS_ERR(ep->clk_res->bus_clk)) {
+   dev_err(dev, "Failed to get pcie bus clock\n");
+   return PTR_ERR(ep->clk_res->bus_clk);
+   }
+
+   return 0;
+}
+
+static int exynos5440_pcie_init_clk_resources(struct exynos_pcie *ep)
+{
+   struct device *dev = ep->pp.dev;
+   int ret;
+
+   ret = clk_prepare_enable(ep->clk_res-&g

[PATCH] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

From: Niyas Ahmed S T 

Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
This patch does refactoring of Exynos PCIe driver to extend support
for other Exynos SoC.

Following are the main changes done via this patch:
1) It adds separate structs for memory, clock resources.
2) It add exynos_pcie_ops struct which will allow us to support the
differences in resources in different Exynos SoC.

No functional change intended.

Signed-off-by: Niyas Ahmed S T 
Signed-off-by: Pankaj Dubey 
---
This patch set is prepared on top of Krzysztof's for-next and
PCIe driver cleanup patch [1] by Jaehoon Chung.

[1]: https://lkml.org/lkml/2016/12/19/44


 drivers/pci/host/pci-exynos.c | 346 ++
 1 file changed, 217 insertions(+), 129 deletions(-)

diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index 33562cf..2dc54f7 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,16 +29,6 @@
 
 #define to_exynos_pcie(x)  container_of(x, struct exynos_pcie, pp)
 
-struct exynos_pcie {
-   struct pcie_portpp;
-   void __iomem*elbi_base; /* DT 0th resource */
-   void __iomem*phy_base;  /* DT 1st resource */
-   void __iomem*block_base;/* DT 2nd resource */
-   int reset_gpio;
-   struct clk  *clk;
-   struct clk  *bus_clk;
-};
-
 /* PCIe ELBI registers */
 #define PCIE_IRQ_PULSE 0x000
 #define IRQ_INTA_ASSERTBIT(0)
@@ -102,6 +93,122 @@ struct exynos_pcie {
 #define PCIE_PHY_TRSV3_PD_TSV  BIT(7)
 #define PCIE_PHY_TRSV3_LVCC0x31c
 
+struct exynos_pcie_mem_res {
+   void __iomem *elbi_base; /* DT 0th resource: PCIE CTRL */
+   void __iomem *phy_base; /* DT 1st resource: PHY CTRL */
+   void __iomem *block_base; /* DT 2nd resource: PHY ADDITIONAL CTRL */
+};
+
+struct exynos_pcie_clk_res {
+   struct clk *clk;
+   struct clk *bus_clk;
+};
+
+struct exynos_pcie {
+   struct pcie_portpp;
+   struct exynos_pcie_mem_res  *mem_res;
+   struct exynos_pcie_clk_res  *clk_res;
+   const struct exynos_pcie_ops*ops;
+   int reset_gpio;
+};
+
+struct exynos_pcie_ops {
+   int (*get_mem_resources)(struct platform_device *pdev,
+   struct exynos_pcie *ep);
+   int (*get_clk_resources)(struct exynos_pcie *ep);
+   int (*init_clk_resources)(struct exynos_pcie *ep);
+   void (*deinit_clk_resources)(struct exynos_pcie *ep);
+};
+
+static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev,
+   struct exynos_pcie *ep)
+{
+   struct resource *res;
+   struct device *dev = ep->pp.dev;
+
+   ep->mem_res = devm_kzalloc(dev, sizeof(*ep->mem_res), GFP_KERNEL);
+   if (!ep->mem_res)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   ep->mem_res->elbi_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->elbi_base))
+   return PTR_ERR(ep->mem_res->elbi_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   ep->mem_res->phy_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->phy_base))
+   return PTR_ERR(ep->mem_res->phy_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   ep->mem_res->block_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->block_base))
+   return PTR_ERR(ep->mem_res->block_base);
+
+   return 0;
+}
+
+static int exynos5440_pcie_get_clk_resources(struct exynos_pcie *ep)
+{
+   struct device *dev = ep->pp.dev;
+
+   ep->clk_res = devm_kzalloc(dev, sizeof(*ep->clk_res), GFP_KERNEL);
+   if (!ep->clk_res)
+   return -ENOMEM;
+
+   ep->clk_res->clk = devm_clk_get(dev, "pcie");
+   if (IS_ERR(ep->clk_res->clk)) {
+   dev_err(dev, "Failed to get pcie rc clock\n");
+   return PTR_ERR(ep->clk_res->clk);
+   }
+
+   ep->clk_res->bus_clk = devm_clk_get(dev, "pcie_bus");
+   if (IS_ERR(ep->clk_res->bus_clk)) {
+   dev_err(dev, "Failed to get pcie bus clock\n");
+   return PTR_ERR(ep->clk_res->bus_clk);
+   }
+
+   return 0;
+}
+
+static int exynos5440_pcie_init_clk_resources(struct exynos_pcie *ep)
+{
+   struct device *dev = ep->pp.dev;
+   int ret;
+
+   ret = clk_prepare_enable(ep->clk_res->clk);
+   if (ret) {
+   dev_err(dev, "cannot enable pcie rc clock");

[PATCH] of: reserved_mem: set dma_ops for devices using reserved mem

[Pankaj Dubey]

From: Smitha T Murthy <smith...@samsung.com>

For some IPs, there may be virtual child devices created and for them its
necessary to set the dma_ops if it's using reserved memory else it will call
the dummy dma_ops during buffer operations for the child devices which will
lead to memory mapping failure.

Signed-off-by: Smitha T Murthy <smith...@samsung.com>
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 drivers/of/of_reserved_mem.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 366d8c3..d507c35 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -354,6 +354,10 @@ int of_reserved_mem_device_init_by_idx(struct device *dev,
mutex_lock(_rmem_assigned_device_mutex);
list_add(>list, _rmem_assigned_device_list);
mutex_unlock(_rmem_assigned_device_mutex);
+   /* ensure that dma_ops is set for virtual devices
+* using reserved memory
+*/
+   of_dma_configure(dev, np);
 
dev_info(dev, "assigned reserved memory node %s\n", rmem->name);
} else {
-- 
2.7.4

[PATCH] of: reserved_mem: set dma_ops for devices using reserved mem

[Pankaj Dubey]

From: Smitha T Murthy 

For some IPs, there may be virtual child devices created and for them its
necessary to set the dma_ops if it's using reserved memory else it will call
the dummy dma_ops during buffer operations for the child devices which will
lead to memory mapping failure.

Signed-off-by: Smitha T Murthy 
Signed-off-by: Pankaj Dubey 
---
 drivers/of/of_reserved_mem.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 366d8c3..d507c35 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -354,6 +354,10 @@ int of_reserved_mem_device_init_by_idx(struct device *dev,
mutex_lock(_rmem_assigned_device_mutex);
list_add(>list, _rmem_assigned_device_list);
mutex_unlock(_rmem_assigned_device_mutex);
+   /* ensure that dma_ops is set for virtual devices
+* using reserved memory
+*/
+   of_dma_configure(dev, np);
 
dev_info(dev, "assigned reserved memory node %s\n", rmem->name);
} else {
-- 
2.7.4

[PATCH 1/2] media: s5p-mfc: convert drivers to use the new vb2_queue dev field

[Pankaj Dubey]

From: Smitha T Murthy <smith...@samsung.com>

commit 2548fee63d9e ("[media] media/platform: convert drivers to use the new
vb2_queue dev field") has missed to set dev pointer of vb2_queue which will be
used in reqbufs of mfc driver. Without this change following error is observed:

---
V4L2 Codec decoding example application
Kamil Debski <k.deb...@samsung.com>
Copyright 2012 Samsung Electronics Co., Ltd.

Opening MFC.
(mfc.c:mfc_open:58): MFC Info (/dev/video0): driver="s5p-mfc" \
bus_info="platform:12c3.mfc0" card="s5p-mfc-dec" fd=0x4[
42.339165] Remapping memory failed, error: -6

MFC Open Success.
(main.c:main:711): Successfully opened all necessary files and devices
(mfc.c:mfc_dec_setup_output:103): Setup MFC decoding OUTPUT buffer \
size=4194304 (requested=4194304)
(mfc.c:mfc_dec_setup_output:120): Number of MFC OUTPUT buffers is 2 \
(requested 2)

[App] Out buf phy : 0x, virt : 0x
Output Length is = 0x30
Error (mfc.c:mfc_dec_setup_output:145): Failed to MMAP MFC OUTPUT buffer
---

Signed-off-by: Smitha T Murthy <smith...@samsung.com>
[pankaj.dubey: debugging issue and formatting commit message]
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 0a5b8f5..6ea8246 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -838,6 +838,7 @@ static int s5p_mfc_open(struct file *file)
q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
q->drv_priv = >fh;
q->lock = >mfc_mutex;
+   q->dev = >plat_dev->dev;
if (vdev == dev->vfd_dec) {
q->io_modes = VB2_MMAP;
q->ops = get_dec_queue_ops();
@@ -861,6 +862,7 @@ static int s5p_mfc_open(struct file *file)
q->io_modes = VB2_MMAP;
q->drv_priv = >fh;
q->lock = >mfc_mutex;
+   q->dev = >plat_dev->dev;
if (vdev == dev->vfd_dec) {
q->io_modes = VB2_MMAP;
q->ops = get_dec_queue_ops();
-- 
2.7.4

[PATCH 0/2] s5p-mfc fix for using reserved memory

[Pankaj Dubey]

It has been observed on ARM64 based Exynos SoC, if IOMMU is not enabled
and we try to use reserved memory for MFC, reqbufs fails with below
mentioned error
---
V4L2 Codec decoding example application
Kamil Debski 
Copyright 2012 Samsung Electronics Co., Ltd.

Opening MFC.
(mfc.c:mfc_open:58): MFC Info (/dev/video0): driver="s5p-mfc" \
bus_info="platform:12c3.mfc0" card="s5p-mfc-dec" fd=0x4[
42.339165] Remapping memory failed, error: -6

MFC Open Success.
(main.c:main:711): Successfully opened all necessary files and devices
(mfc.c:mfc_dec_setup_output:103): Setup MFC decoding OUTPUT buffer \
size=4194304 (requested=4194304)
(mfc.c:mfc_dec_setup_output:120): Number of MFC OUTPUT buffers is 2 \
(requested 2)

[App] Out buf phy : 0x, virt : 0x
Output Length is = 0x30
Error (mfc.c:mfc_dec_setup_output:145): Failed to MMAP MFC OUTPUT buffer
-
This is because the device requesting for memory is mfc0.left not the parent 
mfc0.
Hence setting of alloc_devs need to be done only if IOMMU is enabled
and in that case both the left and right device is treated as mfc0 only.
Also we need to populate vb2_queue's dev pointer with mfc dev pointer.

Smitha T Murthy (2):
  media: s5p-mfc: convert drivers to use the new vb2_queue dev field
  media: s5p-mfc: fix MMAP of mfc buffer during reqbufs

 drivers/media/platform/s5p-mfc/s5p_mfc.c |  2 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 17 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 18 +++---
 3 files changed, 23 insertions(+), 14 deletions(-)

-- 
2.7.4

[PATCH 1/2] media: s5p-mfc: convert drivers to use the new vb2_queue dev field

[Pankaj Dubey]

From: Smitha T Murthy 

commit 2548fee63d9e ("[media] media/platform: convert drivers to use the new
vb2_queue dev field") has missed to set dev pointer of vb2_queue which will be
used in reqbufs of mfc driver. Without this change following error is observed:

---
V4L2 Codec decoding example application
Kamil Debski 
Copyright 2012 Samsung Electronics Co., Ltd.

Opening MFC.
(mfc.c:mfc_open:58): MFC Info (/dev/video0): driver="s5p-mfc" \
bus_info="platform:12c3.mfc0" card="s5p-mfc-dec" fd=0x4[
42.339165] Remapping memory failed, error: -6

MFC Open Success.
(main.c:main:711): Successfully opened all necessary files and devices
(mfc.c:mfc_dec_setup_output:103): Setup MFC decoding OUTPUT buffer \
size=4194304 (requested=4194304)
(mfc.c:mfc_dec_setup_output:120): Number of MFC OUTPUT buffers is 2 \
(requested 2)

[App] Out buf phy : 0x, virt : 0x
Output Length is = 0x30
Error (mfc.c:mfc_dec_setup_output:145): Failed to MMAP MFC OUTPUT buffer
---

Signed-off-by: Smitha T Murthy 
[pankaj.dubey: debugging issue and formatting commit message]
Signed-off-by: Pankaj Dubey 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 0a5b8f5..6ea8246 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -838,6 +838,7 @@ static int s5p_mfc_open(struct file *file)
q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
q->drv_priv = >fh;
q->lock = >mfc_mutex;
+   q->dev = >plat_dev->dev;
if (vdev == dev->vfd_dec) {
q->io_modes = VB2_MMAP;
q->ops = get_dec_queue_ops();
@@ -861,6 +862,7 @@ static int s5p_mfc_open(struct file *file)
q->io_modes = VB2_MMAP;
q->drv_priv = >fh;
q->lock = >mfc_mutex;
+   q->dev = >plat_dev->dev;
if (vdev == dev->vfd_dec) {
q->io_modes = VB2_MMAP;
q->ops = get_dec_queue_ops();
-- 
2.7.4

[PATCH 0/2] s5p-mfc fix for using reserved memory

[Pankaj Dubey]

It has been observed on ARM64 based Exynos SoC, if IOMMU is not enabled
and we try to use reserved memory for MFC, reqbufs fails with below
mentioned error
---
V4L2 Codec decoding example application
Kamil Debski 
Copyright 2012 Samsung Electronics Co., Ltd.

Opening MFC.
(mfc.c:mfc_open:58): MFC Info (/dev/video0): driver="s5p-mfc" \
bus_info="platform:12c3.mfc0" card="s5p-mfc-dec" fd=0x4[
42.339165] Remapping memory failed, error: -6

MFC Open Success.
(main.c:main:711): Successfully opened all necessary files and devices
(mfc.c:mfc_dec_setup_output:103): Setup MFC decoding OUTPUT buffer \
size=4194304 (requested=4194304)
(mfc.c:mfc_dec_setup_output:120): Number of MFC OUTPUT buffers is 2 \
(requested 2)

[App] Out buf phy : 0x, virt : 0x
Output Length is = 0x30
Error (mfc.c:mfc_dec_setup_output:145): Failed to MMAP MFC OUTPUT buffer
-
This is because the device requesting for memory is mfc0.left not the parent 
mfc0.
Hence setting of alloc_devs need to be done only if IOMMU is enabled
and in that case both the left and right device is treated as mfc0 only.
Also we need to populate vb2_queue's dev pointer with mfc dev pointer.

Smitha T Murthy (2):
  media: s5p-mfc: convert drivers to use the new vb2_queue dev field
  media: s5p-mfc: fix MMAP of mfc buffer during reqbufs

 drivers/media/platform/s5p-mfc/s5p_mfc.c |  2 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 17 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 18 +++---
 3 files changed, 23 insertions(+), 14 deletions(-)

-- 
2.7.4

[PATCH 2/2] media: s5p-mfc: fix MMAP of mfc buffer during reqbufs

[Pankaj Dubey]

From: Smitha T Murthy <smith...@samsung.com>

It has been observed on ARM64 based Exynos SoC, if IOMMU is not enabled
and we try to use reserved memory for MFC, reqbufs fails with below
mentioned error
---
V4L2 Codec decoding example application
Kamil Debski <k.deb...@samsung.com>
Copyright 2012 Samsung Electronics Co., Ltd.

Opening MFC.
(mfc.c:mfc_open:58): MFC Info (/dev/video0): driver="s5p-mfc" \
bus_info="platform:12c3.mfc0" card="s5p-mfc-dec" fd=0x4[
42.339165] Remapping memory failed, error: -6

MFC Open Success.
(main.c:main:711): Successfully opened all necessary files and devices
(mfc.c:mfc_dec_setup_output:103): Setup MFC decoding OUTPUT buffer \
size=4194304 (requested=4194304)
(mfc.c:mfc_dec_setup_output:120): Number of MFC OUTPUT buffers is 2 \
(requested 2)

[App] Out buf phy : 0x, virt : 0x
Output Length is = 0x30
Error (mfc.c:mfc_dec_setup_output:145): Failed to MMAP MFC OUTPUT buffer
-
This is because the device requesting for memory is mfc0.left not the parent 
mfc0.
Hence setting of alloc_devs need to be done only if IOMMU is enabled
and in that case both the left and right device is treated as mfc0 only.

Signed-off-by: Smitha T Murthy <smith...@samsung.com>
[pankaj.dubey: debugging issue and formatting commit message]
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 17 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 18 +++---
 2 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 52081dd..9cfca5d 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -30,6 +30,7 @@
 #include "s5p_mfc_intr.h"
 #include "s5p_mfc_opr.h"
 #include "s5p_mfc_pm.h"
+#include "s5p_mfc_iommu.h"
 
 static struct s5p_mfc_fmt formats[] = {
{
@@ -930,16 +931,18 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq,
vq->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
psize[0] = ctx->luma_size;
psize[1] = ctx->chroma_size;
-
-   if (IS_MFCV6_PLUS(dev))
-   alloc_devs[0] = ctx->dev->mem_dev_l;
-   else
-   alloc_devs[0] = ctx->dev->mem_dev_r;
-   alloc_devs[1] = ctx->dev->mem_dev_l;
+   if (exynos_is_iommu_available(>plat_dev->dev)) {
+   if (IS_MFCV6_PLUS(dev))
+   alloc_devs[0] = ctx->dev->mem_dev_l;
+   else
+   alloc_devs[0] = ctx->dev->mem_dev_r;
+   alloc_devs[1] = ctx->dev->mem_dev_l;
+   }
} else if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE &&
   ctx->state == MFCINST_INIT) {
psize[0] = ctx->dec_src_buf_size;
-   alloc_devs[0] = ctx->dev->mem_dev_l;
+   if (exynos_is_iommu_available(>plat_dev->dev))
+   alloc_devs[0] = ctx->dev->mem_dev_l;
} else {
mfc_err("This video node is dedicated to decoding. Decoding not 
initialized\n");
return -EINVAL;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index fcc2e05..eb8f06d 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -30,6 +30,7 @@
 #include "s5p_mfc_enc.h"
 #include "s5p_mfc_intr.h"
 #include "s5p_mfc_opr.h"
+#include "s5p_mfc_iommu.h"
 
 #define DEF_SRC_FMT_ENCV4L2_PIX_FMT_NV12M
 #define DEF_DST_FMT_ENCV4L2_PIX_FMT_H264
@@ -1832,7 +1833,8 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq,
if (*buf_count > MFC_MAX_BUFFERS)
*buf_count = MFC_MAX_BUFFERS;
psize[0] = ctx->enc_dst_buf_size;
-   alloc_devs[0] = ctx->dev->mem_dev_l;
+   if (exynos_is_iommu_available(>plat_dev->dev))
+   alloc_devs[0] = ctx->dev->mem_dev_l;
} else if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
if (ctx->src_fmt)
*plane_count = ctx->src_fmt->num_planes;
@@ -1847,12 +1849,14 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq,
psize[0] = ctx->luma_size;
psize[1] = ctx->chroma_size;
 
-   if (IS_MFCV6_PLUS(dev)) {
-   alloc_devs[0] = ctx->dev->m

[PATCH 2/2] media: s5p-mfc: fix MMAP of mfc buffer during reqbufs

[Pankaj Dubey]

From: Smitha T Murthy 

It has been observed on ARM64 based Exynos SoC, if IOMMU is not enabled
and we try to use reserved memory for MFC, reqbufs fails with below
mentioned error
---
V4L2 Codec decoding example application
Kamil Debski 
Copyright 2012 Samsung Electronics Co., Ltd.

Opening MFC.
(mfc.c:mfc_open:58): MFC Info (/dev/video0): driver="s5p-mfc" \
bus_info="platform:12c3.mfc0" card="s5p-mfc-dec" fd=0x4[
42.339165] Remapping memory failed, error: -6

MFC Open Success.
(main.c:main:711): Successfully opened all necessary files and devices
(mfc.c:mfc_dec_setup_output:103): Setup MFC decoding OUTPUT buffer \
size=4194304 (requested=4194304)
(mfc.c:mfc_dec_setup_output:120): Number of MFC OUTPUT buffers is 2 \
(requested 2)

[App] Out buf phy : 0x, virt : 0x
Output Length is = 0x30
Error (mfc.c:mfc_dec_setup_output:145): Failed to MMAP MFC OUTPUT buffer
-
This is because the device requesting for memory is mfc0.left not the parent 
mfc0.
Hence setting of alloc_devs need to be done only if IOMMU is enabled
and in that case both the left and right device is treated as mfc0 only.

Signed-off-by: Smitha T Murthy 
[pankaj.dubey: debugging issue and formatting commit message]
Signed-off-by: Pankaj Dubey 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 17 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 18 +++---
 2 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 52081dd..9cfca5d 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -30,6 +30,7 @@
 #include "s5p_mfc_intr.h"
 #include "s5p_mfc_opr.h"
 #include "s5p_mfc_pm.h"
+#include "s5p_mfc_iommu.h"
 
 static struct s5p_mfc_fmt formats[] = {
{
@@ -930,16 +931,18 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq,
vq->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
psize[0] = ctx->luma_size;
psize[1] = ctx->chroma_size;
-
-   if (IS_MFCV6_PLUS(dev))
-   alloc_devs[0] = ctx->dev->mem_dev_l;
-   else
-   alloc_devs[0] = ctx->dev->mem_dev_r;
-   alloc_devs[1] = ctx->dev->mem_dev_l;
+   if (exynos_is_iommu_available(>plat_dev->dev)) {
+   if (IS_MFCV6_PLUS(dev))
+   alloc_devs[0] = ctx->dev->mem_dev_l;
+   else
+   alloc_devs[0] = ctx->dev->mem_dev_r;
+   alloc_devs[1] = ctx->dev->mem_dev_l;
+   }
} else if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE &&
   ctx->state == MFCINST_INIT) {
psize[0] = ctx->dec_src_buf_size;
-   alloc_devs[0] = ctx->dev->mem_dev_l;
+   if (exynos_is_iommu_available(>plat_dev->dev))
+   alloc_devs[0] = ctx->dev->mem_dev_l;
} else {
mfc_err("This video node is dedicated to decoding. Decoding not 
initialized\n");
return -EINVAL;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index fcc2e05..eb8f06d 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -30,6 +30,7 @@
 #include "s5p_mfc_enc.h"
 #include "s5p_mfc_intr.h"
 #include "s5p_mfc_opr.h"
+#include "s5p_mfc_iommu.h"
 
 #define DEF_SRC_FMT_ENCV4L2_PIX_FMT_NV12M
 #define DEF_DST_FMT_ENCV4L2_PIX_FMT_H264
@@ -1832,7 +1833,8 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq,
if (*buf_count > MFC_MAX_BUFFERS)
*buf_count = MFC_MAX_BUFFERS;
psize[0] = ctx->enc_dst_buf_size;
-   alloc_devs[0] = ctx->dev->mem_dev_l;
+   if (exynos_is_iommu_available(>plat_dev->dev))
+   alloc_devs[0] = ctx->dev->mem_dev_l;
} else if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
if (ctx->src_fmt)
*plane_count = ctx->src_fmt->num_planes;
@@ -1847,12 +1849,14 @@ static int s5p_mfc_queue_setup(struct vb2_queue *vq,
psize[0] = ctx->luma_size;
psize[1] = ctx->chroma_size;
 
-   if (IS_MFCV6_PLUS(dev)) {
-   alloc_devs[0] = ctx->dev->mem_dev_l;
-   alloc_devs[1] = ctx->dev->mem_dev_l;
-   } else {
-

Re: [GIT PULL 1/3] ARM: exynos: Soc/mach for v4.10

[Pankaj Dubey]

On 3 December 2016 at 22:33, Krzysztof Kozlowski <k...@kernel.org> wrote:
> On Fri, Dec 02, 2016 at 10:52:57PM +0100, Arnd Bergmann wrote:
>> On Thursday, December 1, 2016 8:34:04 PM CET Krzysztof Kozlowski wrote:
>> > On Thu, Nov 24, 2016 at 08:08:27AM +0200, Krzysztof Kozlowski wrote:
>> > > Hi,
>> > >
>> > > This contains previous dts branch because SCU node in dts is needed
>> > > prior to removing it from mach code.
>> > >
>> > > Below you will find full pull request and one stripped from dependency.
>> > >
>> >
>> > Hi Arnd, Kevin and Olof,
>> >
>> > What about this pull from the set?
>> >
>>
>> Sorry, I initially deferred it and then didn't get back to it.
>>
>> The dependency on the .dts changes made me a bit nervous about
>> taking it, mostly because the changelog fails to explain the
>> exact dependencies.
>>
>> This breaks compatibility with existing .dtb files, right?
>
> No, strictly speaking not. There was no dt-bindings change here, no DT
> properties for SCU before. We are converting our drivers to DTB so this
> is the same as before when switching for pinctrl, clocks or all other
> drivers to DT.
>
> We are not braking DTB ABI because there was no ABI around it before.
> Otherwise, one would say that lack of SCU DT node was an ABI. That is
> wrong, because DT should describe the hardware and SCU is in hardware.
>
>> What I'd like to see here is an explanation about:
>>
>> - what the upside of breaking compatibility is
>
> DTBs which do not have SCU are not proper because they skip that part of
> hardware. However we are breaking them in the way the SMP won't work
> there. It is not an ABI break, as I mentioned above.
>
>> - what exactly stops working with an old dtb
>> - why we don't keep a fallback for handling old dtb files
>
> What is the point for it? This is not an ABI break. Even if it was,
> Samsung guys don't care for ABI breaks at all (and in fact we wanted to
> mark the platform experimental...).
>
>> It would also be helpful to have a separate pull request for
>> the commits require the new dtb, and the stuff that is unrelated.
>
> I can do that but the pull will be small.
>

Arnd,

Any update on this? Intention of this change is to improve
Exynos SoC's DT support in mainline kernel. This will help in removing static
mapping from exynos machine files and simplify mach-exynos code-base.

Thanks,
Pankaj Dubey

> Best regards,
> Krzysztof
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 1/3] ARM: exynos: Soc/mach for v4.10

[Pankaj Dubey]

On 3 December 2016 at 22:33, Krzysztof Kozlowski  wrote:
> On Fri, Dec 02, 2016 at 10:52:57PM +0100, Arnd Bergmann wrote:
>> On Thursday, December 1, 2016 8:34:04 PM CET Krzysztof Kozlowski wrote:
>> > On Thu, Nov 24, 2016 at 08:08:27AM +0200, Krzysztof Kozlowski wrote:
>> > > Hi,
>> > >
>> > > This contains previous dts branch because SCU node in dts is needed
>> > > prior to removing it from mach code.
>> > >
>> > > Below you will find full pull request and one stripped from dependency.
>> > >
>> >
>> > Hi Arnd, Kevin and Olof,
>> >
>> > What about this pull from the set?
>> >
>>
>> Sorry, I initially deferred it and then didn't get back to it.
>>
>> The dependency on the .dts changes made me a bit nervous about
>> taking it, mostly because the changelog fails to explain the
>> exact dependencies.
>>
>> This breaks compatibility with existing .dtb files, right?
>
> No, strictly speaking not. There was no dt-bindings change here, no DT
> properties for SCU before. We are converting our drivers to DTB so this
> is the same as before when switching for pinctrl, clocks or all other
> drivers to DT.
>
> We are not braking DTB ABI because there was no ABI around it before.
> Otherwise, one would say that lack of SCU DT node was an ABI. That is
> wrong, because DT should describe the hardware and SCU is in hardware.
>
>> What I'd like to see here is an explanation about:
>>
>> - what the upside of breaking compatibility is
>
> DTBs which do not have SCU are not proper because they skip that part of
> hardware. However we are breaking them in the way the SMP won't work
> there. It is not an ABI break, as I mentioned above.
>
>> - what exactly stops working with an old dtb
>> - why we don't keep a fallback for handling old dtb files
>
> What is the point for it? This is not an ABI break. Even if it was,
> Samsung guys don't care for ABI breaks at all (and in fact we wanted to
> mark the platform experimental...).
>
>> It would also be helpful to have a separate pull request for
>> the commits require the new dtb, and the stuff that is unrelated.
>
> I can do that but the pull will be small.
>

Arnd,

Any update on this? Intention of this change is to improve
Exynos SoC's DT support in mainline kernel. This will help in removing static
mapping from exynos machine files and simplify mach-exynos code-base.

Thanks,
Pankaj Dubey

> Best regards,
> Krzysztof
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU

[Pankaj Dubey]

On 18 November 2016 at 19:02, Arnd Bergmann <a...@arndb.de> wrote:
> On Friday, November 18, 2016 12:48:07 PM CET Russell King - ARM Linux wrote:
>> On Fri, Nov 18, 2016 at 01:14:35PM +0100, Arnd Bergmann wrote:
>> > @@ -41,6 +43,9 @@ void scu_enable(void __iomem *scu_base)
>> >  {
>> >   u32 scu_ctrl;
>> >
>> > + if (scu_base)
>> > + scu_base = scu_base_addr;
>> > +
>>
>> This looks to me like nonsense.
>>
>> >  #ifdef CONFIG_ARM_ERRATA_764369
>> >   /* Cortex-A9 only */
>> >   if ((read_cpuid_id() & 0xff00) == 0x410fc090) {
>> > @@ -85,6 +90,9 @@ int scu_power_mode(void __iomem *scu_base, unsigned int 
>> > mode)
>> >   unsigned int val;
>> >   int cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(smp_processor_id()), 
>> > 0);
>> >
>> > + if (scu_base)
>> > + scu_base = scu_base_addr;
>> > +
>>
>> Ditto.
>>
>> Rather than doing this, I'd much prefer to always store the SCU base in
>> the SCU code, and remove the "void __iomem *scu_base" argment from all
>> these functions.
>
> Ok, then we just need one scu_probe_*() variant for each of the
> four methods of initializing it (iotable, of_iomap,
> ioremap(scu_a9_get_base) and hardcoded.
>
> The intention of doing the fallback for the NULL argument was
> to avoid having to add lots of new API while also allowing
> the change to be done one platform at a time.
>
> If we remove the argument from the other functions, they either
> need to get a new name, or we change them all to the new prototype
> at once. Either way works fine, do you have a preference between
> them?
>

Russell,

Any opinion on this. Are you OK, with the approach suggested by Arnd?

Thanks,
Pankaj Dubey

> Arnd
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU

[Pankaj Dubey]

On 18 November 2016 at 19:02, Arnd Bergmann  wrote:
> On Friday, November 18, 2016 12:48:07 PM CET Russell King - ARM Linux wrote:
>> On Fri, Nov 18, 2016 at 01:14:35PM +0100, Arnd Bergmann wrote:
>> > @@ -41,6 +43,9 @@ void scu_enable(void __iomem *scu_base)
>> >  {
>> >   u32 scu_ctrl;
>> >
>> > + if (scu_base)
>> > + scu_base = scu_base_addr;
>> > +
>>
>> This looks to me like nonsense.
>>
>> >  #ifdef CONFIG_ARM_ERRATA_764369
>> >   /* Cortex-A9 only */
>> >   if ((read_cpuid_id() & 0xff00) == 0x410fc090) {
>> > @@ -85,6 +90,9 @@ int scu_power_mode(void __iomem *scu_base, unsigned int 
>> > mode)
>> >   unsigned int val;
>> >   int cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(smp_processor_id()), 
>> > 0);
>> >
>> > + if (scu_base)
>> > + scu_base = scu_base_addr;
>> > +
>>
>> Ditto.
>>
>> Rather than doing this, I'd much prefer to always store the SCU base in
>> the SCU code, and remove the "void __iomem *scu_base" argment from all
>> these functions.
>
> Ok, then we just need one scu_probe_*() variant for each of the
> four methods of initializing it (iotable, of_iomap,
> ioremap(scu_a9_get_base) and hardcoded.
>
> The intention of doing the fallback for the NULL argument was
> to avoid having to add lots of new API while also allowing
> the change to be done one platform at a time.
>
> If we remove the argument from the other functions, they either
> need to get a new name, or we change them all to the new prototype
> at once. Either way works fine, do you have a preference between
> them?
>

Russell,

Any opinion on this. Are you OK, with the approach suggested by Arnd?

Thanks,
Pankaj Dubey

> Arnd
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 03/16] ARM: berlin: use generic API for enabling SCU

[Pankaj Dubey]

Hi Jisheng,

On 14 November 2016 at 14:21, Jisheng Zhang <jszh...@marvell.com> wrote:
> Hi Pankaj,
>
> On Mon, 14 Nov 2016 10:31:58 +0530 Pankaj Dubey wrote:
>
>> Now as we have of_scu_enable which takes care of mapping
>> scu base from DT, lets use it.
>>
>> CC: Jisheng Zhang <jszh...@marvell.com>
>> CC: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
>> Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
>> ---
>>  arch/arm/mach-berlin/platsmp.c | 17 +
>>  1 file changed, 5 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm/mach-berlin/platsmp.c b/arch/arm/mach-berlin/platsmp.c
>> index 93f9068..25a6ca5 100644
>> --- a/arch/arm/mach-berlin/platsmp.c
>> +++ b/arch/arm/mach-berlin/platsmp.c
>> @@ -60,26 +60,21 @@ static int berlin_boot_secondary(unsigned int cpu, 
>> struct task_struct *idle)
>>  static void __init berlin_smp_prepare_cpus(unsigned int max_cpus)
>>  {
>>   struct device_node *np;
>> - void __iomem *scu_base;
>>   void __iomem *vectors_base;
>>
>> - np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
>> - scu_base = of_iomap(np, 0);
>> - of_node_put(np);
>> - if (!scu_base)
>> - return;
>> -
>>   np = of_find_compatible_node(NULL, NULL, "marvell,berlin-cpu-ctrl");
>>   cpu_ctrl = of_iomap(np, 0);
>>   of_node_put(np);
>>   if (!cpu_ctrl)
>> - goto unmap_scu;
>> + return;
>>
>>   vectors_base = ioremap(CONFIG_VECTORS_BASE, SZ_32K);
>>   if (!vectors_base)
>> - goto unmap_scu;
>> + return;
>> +
>> + if (of_scu_enable())
>
> In err code path, we need to unmap vectors_base before return
>

You are correct. I missed this, Will update in v2.

Thanks for review.

Pankaj Dubey

>> + return;
>>
>> - scu_enable(scu_base);
>>   flush_cache_all();
>>
>>   /*
>> @@ -95,8 +90,6 @@ static void __init berlin_smp_prepare_cpus(unsigned int 
>> max_cpus)
>>   writel(virt_to_phys(secondary_startup), vectors_base + SW_RESET_ADDR);
>>
>>   iounmap(vectors_base);
>> -unmap_scu:
>> - iounmap(scu_base);
>>  }
>>
>>  #ifdef CONFIG_HOTPLUG_CPU
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 03/16] ARM: berlin: use generic API for enabling SCU

[Pankaj Dubey]

Hi Jisheng,

On 14 November 2016 at 14:21, Jisheng Zhang  wrote:
> Hi Pankaj,
>
> On Mon, 14 Nov 2016 10:31:58 +0530 Pankaj Dubey wrote:
>
>> Now as we have of_scu_enable which takes care of mapping
>> scu base from DT, lets use it.
>>
>> CC: Jisheng Zhang 
>> CC: Sebastian Hesselbarth 
>> Signed-off-by: Pankaj Dubey 
>> ---
>>  arch/arm/mach-berlin/platsmp.c | 17 +
>>  1 file changed, 5 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm/mach-berlin/platsmp.c b/arch/arm/mach-berlin/platsmp.c
>> index 93f9068..25a6ca5 100644
>> --- a/arch/arm/mach-berlin/platsmp.c
>> +++ b/arch/arm/mach-berlin/platsmp.c
>> @@ -60,26 +60,21 @@ static int berlin_boot_secondary(unsigned int cpu, 
>> struct task_struct *idle)
>>  static void __init berlin_smp_prepare_cpus(unsigned int max_cpus)
>>  {
>>   struct device_node *np;
>> - void __iomem *scu_base;
>>   void __iomem *vectors_base;
>>
>> - np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
>> - scu_base = of_iomap(np, 0);
>> - of_node_put(np);
>> - if (!scu_base)
>> - return;
>> -
>>   np = of_find_compatible_node(NULL, NULL, "marvell,berlin-cpu-ctrl");
>>   cpu_ctrl = of_iomap(np, 0);
>>   of_node_put(np);
>>   if (!cpu_ctrl)
>> - goto unmap_scu;
>> + return;
>>
>>   vectors_base = ioremap(CONFIG_VECTORS_BASE, SZ_32K);
>>   if (!vectors_base)
>> - goto unmap_scu;
>> + return;
>> +
>> + if (of_scu_enable())
>
> In err code path, we need to unmap vectors_base before return
>

You are correct. I missed this, Will update in v2.

Thanks for review.

Pankaj Dubey

>> + return;
>>
>> - scu_enable(scu_base);
>>   flush_cache_all();
>>
>>   /*
>> @@ -95,8 +90,6 @@ static void __init berlin_smp_prepare_cpus(unsigned int 
>> max_cpus)
>>   writel(virt_to_phys(secondary_startup), vectors_base + SW_RESET_ADDR);
>>
>>   iounmap(vectors_base);
>> -unmap_scu:
>> - iounmap(scu_base);
>>  }
>>
>>  #ifdef CONFIG_HOTPLUG_CPU
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 04/16] ARM: realview: use generic API for enabling SCU

[Pankaj Dubey]

Hi Arnd,

On 14 November 2016 at 17:26, Arnd Bergmann <a...@arndb.de> wrote:
> On Monday, November 14, 2016 10:31:59 AM CET Pankaj Dubey wrote:
>>  static const struct of_device_id realview_scu_match[] = {
>> { .compatible = "arm,arm11mp-scu", },
>> -   { .compatible = "arm,cortex-a9-scu", },
>> -   { .compatible = "arm,cortex-a5-scu", },
>> { }
>>  };
>>
>> @@ -41,27 +39,18 @@ static void __init realview_smp_prepare_cpus(unsigned 
>> int max_cpus)
>> struct device_node *np;
>> void __iomem *scu_base;
>> struct regmap *map;
>> -   unsigned int ncores;
>> int i;
>>
>> -   np = of_find_matching_node(NULL, realview_scu_match);
>> -   if (!np) {
>> -   pr_err("PLATSMP: No SCU base address\n");
>> -   return;
>> +   if (of_scu_enable()) {
>> +   np = of_find_matching_node(NULL, realview_scu_match);
>> +   scu_base = of_iomap(np, 0);
>> +   of_node_put(np);
>> +   if (!scu_base) {
>> +   pr_err("PLATSMP: No SCU remap\n");
>> +   return;
>> +   }
>> +   scu_enable(scu_base);
>> }
>>
>
> The only difference here seems to be that realview also needs to handle
> "arm,arm11mp-scu". Why not move that into the generic implementation?
>

Just checked scu binding documentation for "arm,arm11mp-scu" and came
to know its for ARM11 MPCore based SoC's SCU. So as you said, it can
surely be moved to genenric imeplemenation. Will do this change and
resubmit again.

Thanks,
Pankaj Dubey

> Arnd
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 04/16] ARM: realview: use generic API for enabling SCU

[Pankaj Dubey]

Hi Arnd,

On 14 November 2016 at 17:26, Arnd Bergmann  wrote:
> On Monday, November 14, 2016 10:31:59 AM CET Pankaj Dubey wrote:
>>  static const struct of_device_id realview_scu_match[] = {
>> { .compatible = "arm,arm11mp-scu", },
>> -   { .compatible = "arm,cortex-a9-scu", },
>> -   { .compatible = "arm,cortex-a5-scu", },
>> { }
>>  };
>>
>> @@ -41,27 +39,18 @@ static void __init realview_smp_prepare_cpus(unsigned 
>> int max_cpus)
>> struct device_node *np;
>> void __iomem *scu_base;
>> struct regmap *map;
>> -   unsigned int ncores;
>> int i;
>>
>> -   np = of_find_matching_node(NULL, realview_scu_match);
>> -   if (!np) {
>> -   pr_err("PLATSMP: No SCU base address\n");
>> -   return;
>> +   if (of_scu_enable()) {
>> +   np = of_find_matching_node(NULL, realview_scu_match);
>> +   scu_base = of_iomap(np, 0);
>> +   of_node_put(np);
>> +   if (!scu_base) {
>> +   pr_err("PLATSMP: No SCU remap\n");
>> +   return;
>> +   }
>> +   scu_enable(scu_base);
>> }
>>
>
> The only difference here seems to be that realview also needs to handle
> "arm,arm11mp-scu". Why not move that into the generic implementation?
>

Just checked scu binding documentation for "arm,arm11mp-scu" and came
to know its for ARM11 MPCore based SoC's SCU. So as you said, it can
surely be moved to genenric imeplemenation. Will do this change and
resubmit again.

Thanks,
Pankaj Dubey

> Arnd
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 03/16] ARM: berlin: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Jisheng Zhang <jszh...@marvell.com>
CC: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 arch/arm/mach-berlin/platsmp.c | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-berlin/platsmp.c b/arch/arm/mach-berlin/platsmp.c
index 93f9068..25a6ca5 100644
--- a/arch/arm/mach-berlin/platsmp.c
+++ b/arch/arm/mach-berlin/platsmp.c
@@ -60,26 +60,21 @@ static int berlin_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 static void __init berlin_smp_prepare_cpus(unsigned int max_cpus)
 {
struct device_node *np;
-   void __iomem *scu_base;
void __iomem *vectors_base;
 
-   np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-   scu_base = of_iomap(np, 0);
-   of_node_put(np);
-   if (!scu_base)
-   return;
-
np = of_find_compatible_node(NULL, NULL, "marvell,berlin-cpu-ctrl");
cpu_ctrl = of_iomap(np, 0);
of_node_put(np);
if (!cpu_ctrl)
-   goto unmap_scu;
+   return;
 
vectors_base = ioremap(CONFIG_VECTORS_BASE, SZ_32K);
if (!vectors_base)
-   goto unmap_scu;
+   return;
+
+   if (of_scu_enable())
+   return;
 
-   scu_enable(scu_base);
flush_cache_all();
 
/*
@@ -95,8 +90,6 @@ static void __init berlin_smp_prepare_cpus(unsigned int 
max_cpus)
writel(virt_to_phys(secondary_startup), vectors_base + SW_RESET_ADDR);
 
iounmap(vectors_base);
-unmap_scu:
-   iounmap(scu_base);
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
-- 
2.7.4

[PATCH 09/16] ARM: BCM: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Florian Fainelli <f.faine...@gmail.com>
CC: Ray Jui <r...@broadcom.com>
CC: Scott Branden <sbran...@broadcom.com>
CC: bcm-kernel-feedback-l...@broadcom.com
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 arch/arm/mach-bcm/bcm63xx_smp.c | 18 ++--
 arch/arm/mach-bcm/platsmp.c | 46 +
 2 files changed, 3 insertions(+), 61 deletions(-)

diff --git a/arch/arm/mach-bcm/bcm63xx_smp.c b/arch/arm/mach-bcm/bcm63xx_smp.c
index 9b6727e..a4c6ecd 100644
--- a/arch/arm/mach-bcm/bcm63xx_smp.c
+++ b/arch/arm/mach-bcm/bcm63xx_smp.c
@@ -20,9 +20,6 @@
 
 #include "bcm63xx_smp.h"
 
-/* Size of mapped Cortex A9 SCU address space */
-#define CORTEX_A9_SCU_SIZE 0x58
-
 /*
  * Enable the Cortex A9 Snoop Control Unit
  *
@@ -35,7 +32,6 @@
  */
 static int __init scu_a9_enable(void)
 {
-   unsigned long config_base;
void __iomem *scu_base;
unsigned int i, ncores;
 
@@ -44,19 +40,9 @@ static int __init scu_a9_enable(void)
return -ENXIO;
}
 
-   /* Config base address register value is zero for uniprocessor */
-   config_base = scu_a9_get_base();
-   if (!config_base) {
-   pr_err("hardware reports only one core\n");
-   return -ENOENT;
-   }
-
-   scu_base = ioremap((phys_addr_t)config_base, CORTEX_A9_SCU_SIZE);
-   if (!scu_base) {
-   pr_err("failed to remap config base (%lu/%u) for SCU\n",
-   config_base, CORTEX_A9_SCU_SIZE);
+   scu_base = of_scu_get_base();
+   if (IS_ERR(scu_base))
return -ENOMEM;
-   }
 
scu_enable(scu_base);
 
diff --git a/arch/arm/mach-bcm/platsmp.c b/arch/arm/mach-bcm/platsmp.c
index 3ac3a9b..743599a 100644
--- a/arch/arm/mach-bcm/platsmp.c
+++ b/arch/arm/mach-bcm/platsmp.c
@@ -28,9 +28,6 @@
 #include 
 #include 
 
-/* Size of mapped Cortex A9 SCU address space */
-#define CORTEX_A9_SCU_SIZE 0x58
-
 #define SECONDARY_TIMEOUT_NS   NSEC_PER_MSEC   /* 1 msec (in nanoseconds) */
 #define BOOT_ADDR_CPUID_MASK   0x3
 
@@ -38,47 +35,6 @@
 #define OF_SECONDARY_BOOT  "secondary-boot-reg"
 #define MPIDR_CPUID_BITMASK0x3
 
-/*
- * Enable the Cortex A9 Snoop Control Unit
- *
- * By the time this is called we already know there are multiple
- * cores present.  We assume we're running on a Cortex A9 processor,
- * so any trouble getting the base address register or getting the
- * SCU base is a problem.
- *
- * Return 0 if successful or an error code otherwise.
- */
-static int __init scu_a9_enable(void)
-{
-   unsigned long config_base;
-   void __iomem *scu_base;
-
-   if (!scu_a9_has_base()) {
-   pr_err("no configuration base address register!\n");
-   return -ENXIO;
-   }
-
-   /* Config base address register value is zero for uniprocessor */
-   config_base = scu_a9_get_base();
-   if (!config_base) {
-   pr_err("hardware reports only one core\n");
-   return -ENOENT;
-   }
-
-   scu_base = ioremap((phys_addr_t)config_base, CORTEX_A9_SCU_SIZE);
-   if (!scu_base) {
-   pr_err("failed to remap config base (%lu/%u) for SCU\n",
-   config_base, CORTEX_A9_SCU_SIZE);
-   return -ENOMEM;
-   }
-
-   scu_enable(scu_base);
-
-   iounmap(scu_base);  /* That's the last we'll need of this */
-
-   return 0;
-}
-
 static u32 secondary_boot_addr_for(unsigned int cpu)
 {
u32 secondary_boot_addr = 0;
@@ -134,7 +90,7 @@ static void __init bcm_smp_prepare_cpus(unsigned int 
max_cpus)
const cpumask_t only_cpu_0 = { CPU_BITS_CPU0 };
 
/* Enable the SCU on Cortex A9 based SoCs */
-   if (scu_a9_enable()) {
+   if (of_scu_enable()) {
/* Update the CPU present map to reflect uniprocessor mode */
pr_warn("failed to enable A9 SCU - disabling SMP\n");
init_cpu_present(_cpu_0);
-- 
2.7.4

[PATCH 03/16] ARM: berlin: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Jisheng Zhang 
CC: Sebastian Hesselbarth 
Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-berlin/platsmp.c | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-berlin/platsmp.c b/arch/arm/mach-berlin/platsmp.c
index 93f9068..25a6ca5 100644
--- a/arch/arm/mach-berlin/platsmp.c
+++ b/arch/arm/mach-berlin/platsmp.c
@@ -60,26 +60,21 @@ static int berlin_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 static void __init berlin_smp_prepare_cpus(unsigned int max_cpus)
 {
struct device_node *np;
-   void __iomem *scu_base;
void __iomem *vectors_base;
 
-   np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-   scu_base = of_iomap(np, 0);
-   of_node_put(np);
-   if (!scu_base)
-   return;
-
np = of_find_compatible_node(NULL, NULL, "marvell,berlin-cpu-ctrl");
cpu_ctrl = of_iomap(np, 0);
of_node_put(np);
if (!cpu_ctrl)
-   goto unmap_scu;
+   return;
 
vectors_base = ioremap(CONFIG_VECTORS_BASE, SZ_32K);
if (!vectors_base)
-   goto unmap_scu;
+   return;
+
+   if (of_scu_enable())
+   return;
 
-   scu_enable(scu_base);
flush_cache_all();
 
/*
@@ -95,8 +90,6 @@ static void __init berlin_smp_prepare_cpus(unsigned int 
max_cpus)
writel(virt_to_phys(secondary_startup), vectors_base + SW_RESET_ADDR);
 
iounmap(vectors_base);
-unmap_scu:
-   iounmap(scu_base);
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
-- 
2.7.4

[PATCH 09/16] ARM: BCM: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Florian Fainelli 
CC: Ray Jui 
CC: Scott Branden 
CC: bcm-kernel-feedback-l...@broadcom.com
Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-bcm/bcm63xx_smp.c | 18 ++--
 arch/arm/mach-bcm/platsmp.c | 46 +
 2 files changed, 3 insertions(+), 61 deletions(-)

diff --git a/arch/arm/mach-bcm/bcm63xx_smp.c b/arch/arm/mach-bcm/bcm63xx_smp.c
index 9b6727e..a4c6ecd 100644
--- a/arch/arm/mach-bcm/bcm63xx_smp.c
+++ b/arch/arm/mach-bcm/bcm63xx_smp.c
@@ -20,9 +20,6 @@
 
 #include "bcm63xx_smp.h"
 
-/* Size of mapped Cortex A9 SCU address space */
-#define CORTEX_A9_SCU_SIZE 0x58
-
 /*
  * Enable the Cortex A9 Snoop Control Unit
  *
@@ -35,7 +32,6 @@
  */
 static int __init scu_a9_enable(void)
 {
-   unsigned long config_base;
void __iomem *scu_base;
unsigned int i, ncores;
 
@@ -44,19 +40,9 @@ static int __init scu_a9_enable(void)
return -ENXIO;
}
 
-   /* Config base address register value is zero for uniprocessor */
-   config_base = scu_a9_get_base();
-   if (!config_base) {
-   pr_err("hardware reports only one core\n");
-   return -ENOENT;
-   }
-
-   scu_base = ioremap((phys_addr_t)config_base, CORTEX_A9_SCU_SIZE);
-   if (!scu_base) {
-   pr_err("failed to remap config base (%lu/%u) for SCU\n",
-   config_base, CORTEX_A9_SCU_SIZE);
+   scu_base = of_scu_get_base();
+   if (IS_ERR(scu_base))
return -ENOMEM;
-   }
 
scu_enable(scu_base);
 
diff --git a/arch/arm/mach-bcm/platsmp.c b/arch/arm/mach-bcm/platsmp.c
index 3ac3a9b..743599a 100644
--- a/arch/arm/mach-bcm/platsmp.c
+++ b/arch/arm/mach-bcm/platsmp.c
@@ -28,9 +28,6 @@
 #include 
 #include 
 
-/* Size of mapped Cortex A9 SCU address space */
-#define CORTEX_A9_SCU_SIZE 0x58
-
 #define SECONDARY_TIMEOUT_NS   NSEC_PER_MSEC   /* 1 msec (in nanoseconds) */
 #define BOOT_ADDR_CPUID_MASK   0x3
 
@@ -38,47 +35,6 @@
 #define OF_SECONDARY_BOOT  "secondary-boot-reg"
 #define MPIDR_CPUID_BITMASK0x3
 
-/*
- * Enable the Cortex A9 Snoop Control Unit
- *
- * By the time this is called we already know there are multiple
- * cores present.  We assume we're running on a Cortex A9 processor,
- * so any trouble getting the base address register or getting the
- * SCU base is a problem.
- *
- * Return 0 if successful or an error code otherwise.
- */
-static int __init scu_a9_enable(void)
-{
-   unsigned long config_base;
-   void __iomem *scu_base;
-
-   if (!scu_a9_has_base()) {
-   pr_err("no configuration base address register!\n");
-   return -ENXIO;
-   }
-
-   /* Config base address register value is zero for uniprocessor */
-   config_base = scu_a9_get_base();
-   if (!config_base) {
-   pr_err("hardware reports only one core\n");
-   return -ENOENT;
-   }
-
-   scu_base = ioremap((phys_addr_t)config_base, CORTEX_A9_SCU_SIZE);
-   if (!scu_base) {
-   pr_err("failed to remap config base (%lu/%u) for SCU\n",
-   config_base, CORTEX_A9_SCU_SIZE);
-   return -ENOMEM;
-   }
-
-   scu_enable(scu_base);
-
-   iounmap(scu_base);  /* That's the last we'll need of this */
-
-   return 0;
-}
-
 static u32 secondary_boot_addr_for(unsigned int cpu)
 {
u32 secondary_boot_addr = 0;
@@ -134,7 +90,7 @@ static void __init bcm_smp_prepare_cpus(unsigned int 
max_cpus)
const cpumask_t only_cpu_0 = { CPU_BITS_CPU0 };
 
/* Enable the SCU on Cortex A9 based SoCs */
-   if (scu_a9_enable()) {
+   if (of_scu_enable()) {
/* Update the CPU present map to reflect uniprocessor mode */
pr_warn("failed to enable A9 SCU - disabling SMP\n");
init_cpu_present(_cpu_0);
-- 
2.7.4

[PATCH 06/16] ARM: STi: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Patrice Chotard <patrice.chot...@st.com>
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 arch/arm/mach-sti/platsmp.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm/mach-sti/platsmp.c b/arch/arm/mach-sti/platsmp.c
index ea5a227..0bc7ff8 100644
--- a/arch/arm/mach-sti/platsmp.c
+++ b/arch/arm/mach-sti/platsmp.c
@@ -99,19 +99,12 @@ static int sti_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 static void __init sti_smp_prepare_cpus(unsigned int max_cpus)
 {
struct device_node *np;
-   void __iomem *scu_base;
u32 __iomem *cpu_strt_ptr;
u32 release_phys;
int cpu;
unsigned long entry_pa = virt_to_phys(sti_secondary_startup);
 
-   np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-
-   if (np) {
-   scu_base = of_iomap(np, 0);
-   scu_enable(scu_base);
-   of_node_put(np);
-   }
+   of_scu_enable();
 
if (max_cpus <= 1)
return;
-- 
2.7.4

[PATCH 06/16] ARM: STi: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Patrice Chotard 
Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-sti/platsmp.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm/mach-sti/platsmp.c b/arch/arm/mach-sti/platsmp.c
index ea5a227..0bc7ff8 100644
--- a/arch/arm/mach-sti/platsmp.c
+++ b/arch/arm/mach-sti/platsmp.c
@@ -99,19 +99,12 @@ static int sti_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 static void __init sti_smp_prepare_cpus(unsigned int max_cpus)
 {
struct device_node *np;
-   void __iomem *scu_base;
u32 __iomem *cpu_strt_ptr;
u32 release_phys;
int cpu;
unsigned long entry_pa = virt_to_phys(sti_secondary_startup);
 
-   np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-
-   if (np) {
-   scu_base = of_iomap(np, 0);
-   scu_enable(scu_base);
-   of_node_put(np);
-   }
+   of_scu_enable();
 
if (max_cpus <= 1)
return;
-- 
2.7.4

[PATCH 11/16] ARM: rockchip: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Heiko Stuebner <he...@sntech.de>
CC: linux-rockc...@lists.infradead.org
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 arch/arm/mach-rockchip/platsmp.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c
index 4d827a0..31169cf 100644
--- a/arch/arm/mach-rockchip/platsmp.c
+++ b/arch/arm/mach-rockchip/platsmp.c
@@ -282,21 +282,15 @@ static void __init rockchip_smp_prepare_cpus(unsigned int 
max_cpus)
if (has_pmu && rockchip_smp_prepare_pmu())
return;
 
-   if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
+   if (scu_a9_has_base()) {
if (rockchip_smp_prepare_sram(node))
return;
 
/* enable the SCU power domain */
pmu_set_power_domain(PMU_PWRDN_SCU, true);
 
-   node = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-   if (!node) {
-   pr_err("%s: missing scu\n", __func__);
-   return;
-   }
-
-   scu_base_addr = of_iomap(node, 0);
-   if (!scu_base_addr) {
+   scu_base_addr = of_scu_get_base();
+   if (IS_ERR(scu_base_addr)) {
pr_err("%s: could not map scu registers\n", __func__);
return;
}
-- 
2.7.4

[PATCH 13/16] ARM: zynq: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

At the same time this patch cleans up mach-zynq platform files by
removing static mapping of SCU and dropping zynq_scu_map_io and zynq_map_io
functions.

CC: Michal Simek <michal.si...@xilinx.com>
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 arch/arm/mach-zynq/common.c  | 32 +---
 arch/arm/mach-zynq/common.h  |  2 --
 arch/arm/mach-zynq/platsmp.c |  2 ++
 3 files changed, 3 insertions(+), 33 deletions(-)

diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index d12002c..3986b2b 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -38,7 +38,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -48,8 +47,6 @@
 #define ZYNQ_DEVCFG_PS_VERSION_SHIFT   28
 #define ZYNQ_DEVCFG_PS_VERSION_MASK0xF
 
-void __iomem *zynq_scu_base;
-
 /**
  * zynq_memory_init - Initialize special memory
  *
@@ -153,33 +150,6 @@ static void __init zynq_timer_init(void)
clocksource_probe();
 }
 
-static struct map_desc zynq_cortex_a9_scu_map __initdata = {
-   .length = SZ_256,
-   .type   = MT_DEVICE,
-};
-
-static void __init zynq_scu_map_io(void)
-{
-   unsigned long base;
-
-   base = scu_a9_get_base();
-   zynq_cortex_a9_scu_map.pfn = __phys_to_pfn(base);
-   /* Expected address is in vmalloc area that's why simple assign here */
-   zynq_cortex_a9_scu_map.virtual = base;
-   iotable_init(_cortex_a9_scu_map, 1);
-   zynq_scu_base = (void __iomem *)base;
-   BUG_ON(!zynq_scu_base);
-}
-
-/**
- * zynq_map_io - Create memory mappings needed for early I/O.
- */
-static void __init zynq_map_io(void)
-{
-   debug_ll_io_init();
-   zynq_scu_map_io();
-}
-
 static void __init zynq_irq_init(void)
 {
zynq_early_slcr_init();
@@ -196,7 +166,7 @@ DT_MACHINE_START(XILINX_EP107, "Xilinx Zynq Platform")
.l2c_aux_val= 0x0040,
.l2c_aux_mask   = 0xffbf,
.smp= smp_ops(zynq_smp_ops),
-   .map_io = zynq_map_io,
+   .map_io = debug_ll_io_init,
.init_irq   = zynq_irq_init,
.init_machine   = zynq_init_machine,
.init_late  = zynq_init_late,
diff --git a/arch/arm/mach-zynq/common.h b/arch/arm/mach-zynq/common.h
index e771933..7c2f008 100644
--- a/arch/arm/mach-zynq/common.h
+++ b/arch/arm/mach-zynq/common.h
@@ -33,8 +33,6 @@ extern int zynq_cpun_start(u32 address, int cpu);
 extern const struct smp_operations zynq_smp_ops;
 #endif
 
-extern void __iomem *zynq_scu_base;
-
 void zynq_pm_late_init(void);
 
 static inline void zynq_core_pm_init(void)
diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
index 7cd9865..2d09119 100644
--- a/arch/arm/mach-zynq/platsmp.c
+++ b/arch/arm/mach-zynq/platsmp.c
@@ -33,6 +33,7 @@
  * be called from zynq_cpun_start() because it is not in __init section.
  */
 static int ncores;
+static void __iomem *zynq_scu_base;
 
 int zynq_cpun_start(u32 address, int cpu)
 {
@@ -108,6 +109,7 @@ static void __init zynq_smp_init_cpus(void)
 
 static void __init zynq_smp_prepare_cpus(unsigned int max_cpus)
 {
+   zynq_scu_base = of_scu_get_base();
scu_enable(zynq_scu_base);
 }
 
-- 
2.7.4

[PATCH 15/16] ARM: mvebu: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Jason Cooper <ja...@lakedaemon.net>
CC: Andrew Lunn <and...@lunn.ch>
CC: Gregory Clement <gregory.clem...@free-electrons.com>
CC: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 arch/arm/mach-mvebu/board-v7.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index ccca951..d7014a3 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -41,13 +41,9 @@ static void __iomem *scu_base;
  */
 static void __init mvebu_scu_enable(void)
 {
-   struct device_node *np =
-   of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-   if (np) {
-   scu_base = of_iomap(np, 0);
+   scu_base = of_scu_get_base();
+   if (!IS_ERR(scu_base))
scu_enable(scu_base);
-   of_node_put(np);
-   }
 }
 
 void __iomem *mvebu_get_scu_base(void)
-- 
2.7.4

[PATCH 11/16] ARM: rockchip: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Heiko Stuebner 
CC: linux-rockc...@lists.infradead.org
Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-rockchip/platsmp.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c
index 4d827a0..31169cf 100644
--- a/arch/arm/mach-rockchip/platsmp.c
+++ b/arch/arm/mach-rockchip/platsmp.c
@@ -282,21 +282,15 @@ static void __init rockchip_smp_prepare_cpus(unsigned int 
max_cpus)
if (has_pmu && rockchip_smp_prepare_pmu())
return;
 
-   if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
+   if (scu_a9_has_base()) {
if (rockchip_smp_prepare_sram(node))
return;
 
/* enable the SCU power domain */
pmu_set_power_domain(PMU_PWRDN_SCU, true);
 
-   node = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-   if (!node) {
-   pr_err("%s: missing scu\n", __func__);
-   return;
-   }
-
-   scu_base_addr = of_iomap(node, 0);
-   if (!scu_base_addr) {
+   scu_base_addr = of_scu_get_base();
+   if (IS_ERR(scu_base_addr)) {
pr_err("%s: could not map scu registers\n", __func__);
return;
}
-- 
2.7.4

[PATCH 13/16] ARM: zynq: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

At the same time this patch cleans up mach-zynq platform files by
removing static mapping of SCU and dropping zynq_scu_map_io and zynq_map_io
functions.

CC: Michal Simek 
Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-zynq/common.c  | 32 +---
 arch/arm/mach-zynq/common.h  |  2 --
 arch/arm/mach-zynq/platsmp.c |  2 ++
 3 files changed, 3 insertions(+), 33 deletions(-)

diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index d12002c..3986b2b 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -38,7 +38,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -48,8 +47,6 @@
 #define ZYNQ_DEVCFG_PS_VERSION_SHIFT   28
 #define ZYNQ_DEVCFG_PS_VERSION_MASK0xF
 
-void __iomem *zynq_scu_base;
-
 /**
  * zynq_memory_init - Initialize special memory
  *
@@ -153,33 +150,6 @@ static void __init zynq_timer_init(void)
clocksource_probe();
 }
 
-static struct map_desc zynq_cortex_a9_scu_map __initdata = {
-   .length = SZ_256,
-   .type   = MT_DEVICE,
-};
-
-static void __init zynq_scu_map_io(void)
-{
-   unsigned long base;
-
-   base = scu_a9_get_base();
-   zynq_cortex_a9_scu_map.pfn = __phys_to_pfn(base);
-   /* Expected address is in vmalloc area that's why simple assign here */
-   zynq_cortex_a9_scu_map.virtual = base;
-   iotable_init(_cortex_a9_scu_map, 1);
-   zynq_scu_base = (void __iomem *)base;
-   BUG_ON(!zynq_scu_base);
-}
-
-/**
- * zynq_map_io - Create memory mappings needed for early I/O.
- */
-static void __init zynq_map_io(void)
-{
-   debug_ll_io_init();
-   zynq_scu_map_io();
-}
-
 static void __init zynq_irq_init(void)
 {
zynq_early_slcr_init();
@@ -196,7 +166,7 @@ DT_MACHINE_START(XILINX_EP107, "Xilinx Zynq Platform")
.l2c_aux_val= 0x0040,
.l2c_aux_mask   = 0xffbf,
.smp= smp_ops(zynq_smp_ops),
-   .map_io = zynq_map_io,
+   .map_io = debug_ll_io_init,
.init_irq   = zynq_irq_init,
.init_machine   = zynq_init_machine,
.init_late  = zynq_init_late,
diff --git a/arch/arm/mach-zynq/common.h b/arch/arm/mach-zynq/common.h
index e771933..7c2f008 100644
--- a/arch/arm/mach-zynq/common.h
+++ b/arch/arm/mach-zynq/common.h
@@ -33,8 +33,6 @@ extern int zynq_cpun_start(u32 address, int cpu);
 extern const struct smp_operations zynq_smp_ops;
 #endif
 
-extern void __iomem *zynq_scu_base;
-
 void zynq_pm_late_init(void);
 
 static inline void zynq_core_pm_init(void)
diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
index 7cd9865..2d09119 100644
--- a/arch/arm/mach-zynq/platsmp.c
+++ b/arch/arm/mach-zynq/platsmp.c
@@ -33,6 +33,7 @@
  * be called from zynq_cpun_start() because it is not in __init section.
  */
 static int ncores;
+static void __iomem *zynq_scu_base;
 
 int zynq_cpun_start(u32 address, int cpu)
 {
@@ -108,6 +109,7 @@ static void __init zynq_smp_init_cpus(void)
 
 static void __init zynq_smp_prepare_cpus(unsigned int max_cpus)
 {
+   zynq_scu_base = of_scu_get_base();
scu_enable(zynq_scu_base);
 }
 
-- 
2.7.4

[PATCH 15/16] ARM: mvebu: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Jason Cooper 
CC: Andrew Lunn 
CC: Gregory Clement 
CC: Sebastian Hesselbarth 
Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-mvebu/board-v7.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index ccca951..d7014a3 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -41,13 +41,9 @@ static void __iomem *scu_base;
  */
 static void __init mvebu_scu_enable(void)
 {
-   struct device_node *np =
-   of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-   if (np) {
-   scu_base = of_iomap(np, 0);
+   scu_base = of_scu_get_base();
+   if (!IS_ERR(scu_base))
scu_enable(scu_base);
-   of_node_put(np);
-   }
 }
 
 void __iomem *mvebu_get_scu_base(void)
-- 
2.7.4

[PATCH 12/16] ARM: imx: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

At the same time this patch cleans up mach-imx platform files by
removing static mapping of SCU and dropping imx_scu_map_io function.

CC: Shawn Guo <shawn...@kernel.org>
CC: Sascha Hauer <ker...@pengutronix.de>
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 arch/arm/mach-imx/common.h |  5 -
 arch/arm/mach-imx/mach-imx6q.c |  8 +---
 arch/arm/mach-imx/platsmp.c| 32 +---
 arch/arm/mach-imx/pm-imx6.c|  3 ++-
 4 files changed, 8 insertions(+), 40 deletions(-)

diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index c4436d9..9787d5f 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -87,11 +87,6 @@ u32 imx_get_cpu_arg(int cpu);
 void imx_set_cpu_arg(int cpu, u32 arg);
 #ifdef CONFIG_SMP
 void v7_secondary_startup(void);
-void imx_scu_map_io(void);
-void imx_smp_prepare(void);
-#else
-static inline void imx_scu_map_io(void) {}
-static inline void imx_smp_prepare(void) {}
 #endif
 void imx_src_init(void);
 void imx_gpc_pre_suspend(bool arm_power_off);
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 45801b2..1c6cc9f 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -383,12 +383,6 @@ static void __init imx6q_init_late(void)
}
 }
 
-static void __init imx6q_map_io(void)
-{
-   debug_ll_io_init();
-   imx_scu_map_io();
-}
-
 static void __init imx6q_init_irq(void)
 {
imx_gpc_check_dt();
@@ -410,7 +404,7 @@ DT_MACHINE_START(IMX6Q, "Freescale i.MX6 Quad/DualLite 
(Device Tree)")
.l2c_aux_val= 0,
.l2c_aux_mask   = ~0,
.smp= smp_ops(imx_smp_ops),
-   .map_io = imx6q_map_io,
+   .map_io = debug_ll_io_init,
.init_irq   = imx6q_init_irq,
.init_machine   = imx6q_init_machine,
.init_late  = imx6q_init_late,
diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
index 711dbbd..c032369 100644
--- a/arch/arm/mach-imx/platsmp.c
+++ b/arch/arm/mach-imx/platsmp.c
@@ -26,26 +26,6 @@
 u32 g_diag_reg;
 static void __iomem *scu_base;
 
-static struct map_desc scu_io_desc __initdata = {
-   /* .virtual and .pfn are run-time assigned */
-   .length = SZ_4K,
-   .type   = MT_DEVICE,
-};
-
-void __init imx_scu_map_io(void)
-{
-   unsigned long base;
-
-   /* Get SCU base */
-   asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
-
-   scu_io_desc.virtual = IMX_IO_P2V(base);
-   scu_io_desc.pfn = __phys_to_pfn(base);
-   iotable_init(_io_desc, 1);
-
-   scu_base = IMX_IO_ADDRESS(base);
-}
-
 static int imx_boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
imx_set_cpu_jump(cpu, v7_secondary_startup);
@@ -61,20 +41,18 @@ static void __init imx_smp_init_cpus(void)
 {
int i, ncores;
 
-   ncores = scu_get_core_count(scu_base);
+   if (!IS_ERR(scu_base))
+   ncores = scu_get_core_count(scu_base);
 
for (i = ncores; i < NR_CPUS; i++)
set_cpu_possible(i, false);
 }
 
-void imx_smp_prepare(void)
-{
-   scu_enable(scu_base);
-}
-
 static void __init imx_smp_prepare_cpus(unsigned int max_cpus)
 {
-   imx_smp_prepare();
+   scu_base = of_scu_get_base();
+   if (!IS_ERR(scu_base))
+   scu_enable(scu_base);
 
/*
 * The diagnostic register holds the errata bits.  Mostly bootloader
diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
index 1515e49..859aacb 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "common.h"
@@ -393,7 +394,7 @@ static int imx6q_pm_enter(suspend_state_t state)
/* Zzz ... */
cpu_suspend(0, imx6q_suspend_finish);
if (cpu_is_imx6q() || cpu_is_imx6dl())
-   imx_smp_prepare();
+   of_scu_enable();
imx_anatop_post_resume();
imx_gpc_post_resume();
imx6_enable_rbc(false);
-- 
2.7.4

[PATCH 10/16] ARM: tegra: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Stephen Warren <swar...@wwwdotorg.org>
CC: linux-te...@vger.kernel.org
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 arch/arm/mach-tegra/platsmp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index 75620ae..3467617 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -179,7 +179,7 @@ static void __init tegra_smp_prepare_cpus(unsigned int 
max_cpus)
cpumask_set_cpu(0, _cpu_init_mask);
 
if (scu_a9_has_base())
-   scu_enable(IO_ADDRESS(scu_a9_get_base()));
+   of_scu_enable();
 }
 
 const struct smp_operations tegra_smp_ops __initconst = {
-- 
2.7.4

[PATCH 05/16] ARM: socfpga: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Dinh Nguyen <dingu...@opensource.altera.com>
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 arch/arm/mach-socfpga/platsmp.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/arch/arm/mach-socfpga/platsmp.c b/arch/arm/mach-socfpga/platsmp.c
index 0794574..d3f0a07 100644
--- a/arch/arm/mach-socfpga/platsmp.c
+++ b/arch/arm/mach-socfpga/platsmp.c
@@ -79,19 +79,10 @@ static int socfpga_a10_boot_secondary(unsigned int cpu, 
struct task_struct *idle
 
 static void __init socfpga_smp_prepare_cpus(unsigned int max_cpus)
 {
-   struct device_node *np;
-   void __iomem *socfpga_scu_base_addr;
-
-   np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-   if (!np) {
+   if (of_scu_enable()) {
pr_err("%s: missing scu\n", __func__);
return;
}
-
-   socfpga_scu_base_addr = of_iomap(np, 0);
-   if (!socfpga_scu_base_addr)
-   return;
-   scu_enable(socfpga_scu_base_addr);
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
-- 
2.7.4

[PATCH 12/16] ARM: imx: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

At the same time this patch cleans up mach-imx platform files by
removing static mapping of SCU and dropping imx_scu_map_io function.

CC: Shawn Guo 
CC: Sascha Hauer 
Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-imx/common.h |  5 -
 arch/arm/mach-imx/mach-imx6q.c |  8 +---
 arch/arm/mach-imx/platsmp.c| 32 +---
 arch/arm/mach-imx/pm-imx6.c|  3 ++-
 4 files changed, 8 insertions(+), 40 deletions(-)

diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index c4436d9..9787d5f 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -87,11 +87,6 @@ u32 imx_get_cpu_arg(int cpu);
 void imx_set_cpu_arg(int cpu, u32 arg);
 #ifdef CONFIG_SMP
 void v7_secondary_startup(void);
-void imx_scu_map_io(void);
-void imx_smp_prepare(void);
-#else
-static inline void imx_scu_map_io(void) {}
-static inline void imx_smp_prepare(void) {}
 #endif
 void imx_src_init(void);
 void imx_gpc_pre_suspend(bool arm_power_off);
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 45801b2..1c6cc9f 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -383,12 +383,6 @@ static void __init imx6q_init_late(void)
}
 }
 
-static void __init imx6q_map_io(void)
-{
-   debug_ll_io_init();
-   imx_scu_map_io();
-}
-
 static void __init imx6q_init_irq(void)
 {
imx_gpc_check_dt();
@@ -410,7 +404,7 @@ DT_MACHINE_START(IMX6Q, "Freescale i.MX6 Quad/DualLite 
(Device Tree)")
.l2c_aux_val= 0,
.l2c_aux_mask   = ~0,
.smp= smp_ops(imx_smp_ops),
-   .map_io = imx6q_map_io,
+   .map_io = debug_ll_io_init,
.init_irq   = imx6q_init_irq,
.init_machine   = imx6q_init_machine,
.init_late  = imx6q_init_late,
diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
index 711dbbd..c032369 100644
--- a/arch/arm/mach-imx/platsmp.c
+++ b/arch/arm/mach-imx/platsmp.c
@@ -26,26 +26,6 @@
 u32 g_diag_reg;
 static void __iomem *scu_base;
 
-static struct map_desc scu_io_desc __initdata = {
-   /* .virtual and .pfn are run-time assigned */
-   .length = SZ_4K,
-   .type   = MT_DEVICE,
-};
-
-void __init imx_scu_map_io(void)
-{
-   unsigned long base;
-
-   /* Get SCU base */
-   asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
-
-   scu_io_desc.virtual = IMX_IO_P2V(base);
-   scu_io_desc.pfn = __phys_to_pfn(base);
-   iotable_init(_io_desc, 1);
-
-   scu_base = IMX_IO_ADDRESS(base);
-}
-
 static int imx_boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
imx_set_cpu_jump(cpu, v7_secondary_startup);
@@ -61,20 +41,18 @@ static void __init imx_smp_init_cpus(void)
 {
int i, ncores;
 
-   ncores = scu_get_core_count(scu_base);
+   if (!IS_ERR(scu_base))
+   ncores = scu_get_core_count(scu_base);
 
for (i = ncores; i < NR_CPUS; i++)
set_cpu_possible(i, false);
 }
 
-void imx_smp_prepare(void)
-{
-   scu_enable(scu_base);
-}
-
 static void __init imx_smp_prepare_cpus(unsigned int max_cpus)
 {
-   imx_smp_prepare();
+   scu_base = of_scu_get_base();
+   if (!IS_ERR(scu_base))
+   scu_enable(scu_base);
 
/*
 * The diagnostic register holds the errata bits.  Mostly bootloader
diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
index 1515e49..859aacb 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "common.h"
@@ -393,7 +394,7 @@ static int imx6q_pm_enter(suspend_state_t state)
/* Zzz ... */
cpu_suspend(0, imx6q_suspend_finish);
if (cpu_is_imx6q() || cpu_is_imx6dl())
-   imx_smp_prepare();
+   of_scu_enable();
imx_anatop_post_resume();
imx_gpc_post_resume();
imx6_enable_rbc(false);
-- 
2.7.4

[PATCH 10/16] ARM: tegra: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Stephen Warren 
CC: linux-te...@vger.kernel.org
Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-tegra/platsmp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index 75620ae..3467617 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -179,7 +179,7 @@ static void __init tegra_smp_prepare_cpus(unsigned int 
max_cpus)
cpumask_set_cpu(0, _cpu_init_mask);
 
if (scu_a9_has_base())
-   scu_enable(IO_ADDRESS(scu_a9_get_base()));
+   of_scu_enable();
 }
 
 const struct smp_operations tegra_smp_ops __initconst = {
-- 
2.7.4

[PATCH 05/16] ARM: socfpga: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Dinh Nguyen 
Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-socfpga/platsmp.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/arch/arm/mach-socfpga/platsmp.c b/arch/arm/mach-socfpga/platsmp.c
index 0794574..d3f0a07 100644
--- a/arch/arm/mach-socfpga/platsmp.c
+++ b/arch/arm/mach-socfpga/platsmp.c
@@ -79,19 +79,10 @@ static int socfpga_a10_boot_secondary(unsigned int cpu, 
struct task_struct *idle
 
 static void __init socfpga_smp_prepare_cpus(unsigned int max_cpus)
 {
-   struct device_node *np;
-   void __iomem *socfpga_scu_base_addr;
-
-   np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-   if (!np) {
+   if (of_scu_enable()) {
pr_err("%s: missing scu\n", __func__);
return;
}
-
-   socfpga_scu_base_addr = of_iomap(np, 0);
-   if (!socfpga_scu_base_addr)
-   return;
-   scu_enable(socfpga_scu_base_addr);
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
-- 
2.7.4

[PATCH 07/16] ARM: ux500: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Linus Walleij <linus.wall...@linaro.org>
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 arch/arm/mach-ux500/platsmp.c | 20 +---
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/arch/arm/mach-ux500/platsmp.c b/arch/arm/mach-ux500/platsmp.c
index 8f2f615..e1927ae 100644
--- a/arch/arm/mach-ux500/platsmp.c
+++ b/arch/arm/mach-ux500/platsmp.c
@@ -66,28 +66,10 @@ static void wakeup_secondary(void)
 
 static void __init ux500_smp_prepare_cpus(unsigned int max_cpus)
 {
-   struct device_node *np;
-   static void __iomem *scu_base;
-   unsigned int ncores;
-   int i;
-
-   np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-   if (!np) {
-   pr_err("No SCU base address\n");
-   return;
-   }
-   scu_base = of_iomap(np, 0);
-   of_node_put(np);
-   if (!scu_base) {
+   if (of_scu_enable()) {
pr_err("No SCU remap\n");
return;
}
-
-   scu_enable(scu_base);
-   ncores = scu_get_core_count(scu_base);
-   for (i = 0; i < ncores; i++)
-   set_cpu_possible(i, true);
-   iounmap(scu_base);
 }
 
 static int ux500_boot_secondary(unsigned int cpu, struct task_struct *idle)
-- 
2.7.4

[PATCH 08/16] ARM: vexpress: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Liviu Dudau <liviu.du...@arm.com>
CC: Sudeep Holla <sudeep.ho...@arm.com>
CC: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 arch/arm/mach-vexpress/platsmp.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
index 8b8d072..17dee2b 100644
--- a/arch/arm/mach-vexpress/platsmp.c
+++ b/arch/arm/mach-vexpress/platsmp.c
@@ -41,20 +41,9 @@ bool __init vexpress_smp_init_ops(void)
return false;
 }
 
-static const struct of_device_id vexpress_smp_dt_scu_match[] __initconst = {
-   { .compatible = "arm,cortex-a5-scu", },
-   { .compatible = "arm,cortex-a9-scu", },
-   {}
-};
-
 static void __init vexpress_smp_dt_prepare_cpus(unsigned int max_cpus)
 {
-   struct device_node *scu = of_find_matching_node(NULL,
-   vexpress_smp_dt_scu_match);
-
-   if (scu)
-   scu_enable(of_iomap(scu, 0));
-
+   of_scu_enable();
/*
 * Write the address of secondary startup into the
 * system-wide flags register. The boot monitor waits
-- 
2.7.4

[PATCH 16/16] ARM: zx: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Jun Nie <jun@linaro.org>
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 arch/arm/mach-zx/platsmp.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-zx/platsmp.c b/arch/arm/mach-zx/platsmp.c
index 0297f92..2788c34 100644
--- a/arch/arm/mach-zx/platsmp.c
+++ b/arch/arm/mach-zx/platsmp.c
@@ -44,13 +44,11 @@ static void __iomem *scu_base;
 void __init zx_smp_prepare_cpus(unsigned int max_cpus)
 {
struct device_node *np;
-   unsigned long base = 0;
void __iomem *aonsysctrl_base;
void __iomem *sys_iram;
 
-   base = scu_a9_get_base();
-   scu_base = ioremap(base, SZ_256);
-   if (!scu_base) {
+   scu_base = of_scu_get_base();
+   if (IS_ERR(scu_base)) {
pr_err("%s: failed to map scu\n", __func__);
return;
}
-- 
2.7.4

[PATCH 14/16] ARM: hisi: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Wei Xu <xuw...@hisilicon.com>
Signed-off-by: Pankaj Dubey <pankaj.du...@samsung.com>
---
 arch/arm/mach-hisi/platsmp.c | 24 +---
 1 file changed, 5 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-hisi/platsmp.c b/arch/arm/mach-hisi/platsmp.c
index e1d6764..425a291 100644
--- a/arch/arm/mach-hisi/platsmp.c
+++ b/arch/arm/mach-hisi/platsmp.c
@@ -39,29 +39,14 @@ int hi3xxx_get_cpu_jump(int cpu)
return readl_relaxed(ctrl_base + ((cpu - 1) << 2));
 }
 
-static void __init hisi_enable_scu_a9(void)
-{
-   unsigned long base = 0;
-   void __iomem *scu_base = NULL;
-
-   if (scu_a9_has_base()) {
-   base = scu_a9_get_base();
-   scu_base = ioremap(base, SZ_4K);
-   if (!scu_base) {
-   pr_err("ioremap(scu_base) failed\n");
-   return;
-   }
-   scu_enable(scu_base);
-   iounmap(scu_base);
-   }
-}
-
 static void __init hi3xxx_smp_prepare_cpus(unsigned int max_cpus)
 {
struct device_node *np = NULL;
u32 offset = 0;
 
-   hisi_enable_scu_a9();
+   if (scu_a9_has_base())
+   of_scu_enable();
+
if (!ctrl_base) {
np = of_find_compatible_node(NULL, NULL, "hisilicon,sysctrl");
if (!np) {
@@ -100,7 +85,8 @@ static const struct smp_operations hi3xxx_smp_ops 
__initconst = {
 
 static void __init hisi_common_smp_prepare_cpus(unsigned int max_cpus)
 {
-   hisi_enable_scu_a9();
+   if (scu_a9_has_base())
+   of_scu_enable();
 }
 
 static void hix5hd2_set_scu_boot_addr(phys_addr_t start_addr, phys_addr_t 
jump_addr)
-- 
2.7.4

[PATCH 07/16] ARM: ux500: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Linus Walleij 
Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-ux500/platsmp.c | 20 +---
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/arch/arm/mach-ux500/platsmp.c b/arch/arm/mach-ux500/platsmp.c
index 8f2f615..e1927ae 100644
--- a/arch/arm/mach-ux500/platsmp.c
+++ b/arch/arm/mach-ux500/platsmp.c
@@ -66,28 +66,10 @@ static void wakeup_secondary(void)
 
 static void __init ux500_smp_prepare_cpus(unsigned int max_cpus)
 {
-   struct device_node *np;
-   static void __iomem *scu_base;
-   unsigned int ncores;
-   int i;
-
-   np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
-   if (!np) {
-   pr_err("No SCU base address\n");
-   return;
-   }
-   scu_base = of_iomap(np, 0);
-   of_node_put(np);
-   if (!scu_base) {
+   if (of_scu_enable()) {
pr_err("No SCU remap\n");
return;
}
-
-   scu_enable(scu_base);
-   ncores = scu_get_core_count(scu_base);
-   for (i = 0; i < ncores; i++)
-   set_cpu_possible(i, true);
-   iounmap(scu_base);
 }
 
 static int ux500_boot_secondary(unsigned int cpu, struct task_struct *idle)
-- 
2.7.4

[PATCH 08/16] ARM: vexpress: use generic API for enabling SCU

[Pankaj Dubey]

Now as we have of_scu_enable which takes care of mapping
scu base from DT, lets use it.

CC: Liviu Dudau 
CC: Sudeep Holla 
CC: Lorenzo Pieralisi 
Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-vexpress/platsmp.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
index 8b8d072..17dee2b 100644
--- a/arch/arm/mach-vexpress/platsmp.c
+++ b/arch/arm/mach-vexpress/platsmp.c
@@ -41,20 +41,9 @@ bool __init vexpress_smp_init_ops(void)
return false;
 }
 
-static const struct of_device_id vexpress_smp_dt_scu_match[] __initconst = {
-   { .compatible = "arm,cortex-a5-scu", },
-   { .compatible = "arm,cortex-a9-scu", },
-   {}
-};
-
 static void __init vexpress_smp_dt_prepare_cpus(unsigned int max_cpus)
 {
-   struct device_node *scu = of_find_matching_node(NULL,
-   vexpress_smp_dt_scu_match);
-
-   if (scu)
-   scu_enable(of_iomap(scu, 0));
-
+   of_scu_enable();
/*
 * Write the address of secondary startup into the
 * system-wide flags register. The boot monitor waits
-- 
2.7.4