Re: [PATCH 30/31] video: fbdev: s3c-fb: Remove unused variable 'var' from 's3c_fb_probe_win()'
On 1/13/21, 9:50 AM, Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/video/fbdev/s3c-fb.c: In function ‘s3c_fb_probe_win’: > drivers/video/fbdev/s3c-fb.c:1176:28: warning: variable ‘var’ set but not > used [-Wunused-but-set-variable] > > Cc: Jingoo Han Acked-by: Jingoo Han Best regards, Jingoo Han > Cc: Ben Dooks > Cc: linux-fb...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > drivers/video/fbdev/s3c-fb.c | 2 -- > 1 file changed, 2 deletions(-) [...]
Re: [PATCH 24/31] video: fbdev: s3c-fb: Fix some kernel-doc misdemeanours
On 1/13/21, 9:50 AM, Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/video/fbdev/s3c-fb.c:104: warning: Function parameter or member > 'osd_stride' not described in 's3c_fb_variant' > drivers/video/fbdev/s3c-fb.c:174: warning: Function parameter or member > 'variant' not described in 's3c_fb_win' > drivers/video/fbdev/s3c-fb.c:345: warning: Function parameter or member > 'pixclk' not described in 's3c_fb_calc_pixclk' > drivers/video/fbdev/s3c-fb.c:345: warning: Excess function parameter > 'pixclock' description in 's3c_fb_calc_pixclk' > drivers/video/fbdev/s3c-fb.c:742: warning: Function parameter or member > 'transp' not described in 's3c_fb_setcolreg' > drivers/video/fbdev/s3c-fb.c:742: warning: Excess function parameter 'trans' > description in 's3c_fb_setcolreg' > drivers/video/fbdev/s3c-fb.c:1142: warning: Function parameter or member > 'sfb' not described in 's3c_fb_release_win' > drivers/video/fbdev/s3c-fb.c:1172: warning: Function parameter or member > 'win_no' not described in 's3c_fb_probe_win' > > Cc: Jingoo Han Acked-by: Jingoo Han Thank you. > Cc: Ben Dooks > Cc: linux-fb...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > drivers/video/fbdev/s3c-fb.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) [...]
Re: [PATCH V2] PCI: dwc: Add support to configure for ECRC
On 11/11/20, 7:12 AM, Vidya Sagar wrote:
>
> DesignWare core has a TLP digest (TD) override bit in one of the control
> registers of ATU. This bit also needs to be programmed for proper ECRC
> functionality. This is currently identified as an issue with DesignWare
> IP version 4.90a.
>
> Signed-off-by: Vidya Sagar
> Acked-by: Bjorn Helgaas
> ---
> V2:
> * Addressed Bjorn's comments
>
> drivers/pci/controller/dwc/pcie-designware.c | 52 ++--
> drivers/pci/controller/dwc/pcie-designware.h | 1 +
> 2 files changed, 49 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> b/drivers/pci/controller/dwc/pcie-designware.c
> index c2dea8fc97c8..ec0d13ab6bad 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -225,6 +225,46 @@ static void dw_pcie_writel_ob_unroll(struct dw_pcie
> *pci, u32 index, u32 reg,
> dw_pcie_writel_atu(pci, offset + reg, val);
> }
>
> +static inline u32 dw_pcie_enable_ecrc(u32 val)
What is the reason to use inline here?
Best regards,
Jingoo Han
> +{
> + /*
> + * DesignWare core version 4.90A has this strange design issue
> + * where the 'TD' bit in the Control register-1 of the ATU outbound
> + * region acts like an override for the ECRC setting i.e. the presence
> + * of TLP Digest(ECRC) in the outgoing TLPs is solely determined by
> + * this bit. This is contrary to the PCIe spec which says that the
> + * enablement of the ECRC is solely determined by the AER registers.
> + *
> + * Because of this, even when the ECRC is enabled through AER
> + * registers, the transactions going through ATU won't have TLP Digest
> + * as there is no way the AER sub-system could program the TD bit which
> + * is specific to DesignWare core.
> + *
> + * The best way to handle this scenario is to program the TD bit
> + * always. It affects only the traffic from root port to downstream
> + * devices.
> + *
> + * At this point,
> + * When ECRC is enabled in AER registers, everything works normally
> + * When ECRC is NOT enabled in AER registers, then,
> + * on Root Port:- TLP Digest (DWord size) gets appended to each packet
> + *even through it is not required. Since downstream
> + *TLPs are mostly for configuration accesses and BAR
> + *accesses, they are not in critical path and won't
> + *have much negative effect on the performance.
> + * on End Point:- TLP Digest is received for some/all the packets coming
> + *from the root port. TLP Digest is ignored because,
> + *as per the PCIe Spec r5.0 v1.0 section 2.2.3
> + *"TLP Digest Rules", when an endpoint receives TLP
> + *Digest when its ECRC check functionality is disabled
> + *in AER registers, received TLP Digest is just ignored.
> + * Since there is no issue or error reported either side, best way to
> + * handle the scenario is to program TD bit by default.
> + */
> +
> + return val | PCIE_ATU_TD;
> +}
> +
> static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, u8 func_no,
>int index, int type,
>u64 cpu_addr, u64 pci_addr,
> @@ -245,8 +285,10 @@ static void dw_pcie_prog_outbound_atu_unroll(struct
> dw_pcie *pci, u8 func_no,
>lower_32_bits(pci_addr));
> dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET,
>upper_32_bits(pci_addr));
> - dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1,
> - type | PCIE_ATU_FUNC_NUM(func_no));
> + val = type | PCIE_ATU_FUNC_NUM(func_no);
> + if (pci->version == 0x490A)
> + val = dw_pcie_enable_ecrc(val);
> + dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1, val);
> dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2,
>PCIE_ATU_ENABLE);
>
> @@ -292,8 +334,10 @@ static void __dw_pcie_prog_outbound_atu(struct dw_pcie
> *pci, u8 func_no,
> 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);
> + if (pci->version == 0x
Re: [PATCH v3 2/6] dt-bindings: pci: add the samsung,exynos-pcie binding
On 11/5/20, 10:27 AM, Rob Herring wrote: > > On Thu, Nov 5, 2020 at 2:33 AM Marek Szyprowski > wrote: > > > > Hi Rob, > > > > On 04.11.2020 22:35, Rob Herring wrote: > > > On Thu, Oct 29, 2020 at 02:40:13PM +0100, Marek Szyprowski wrote: > > >> Add dt-bindings for the Samsung Exynos PCIe controller (Exynos5433 > > >> variant). Based on the text dt-binding posted by Jaehoon Chung. > > >> > > >> Signed-off-by: Marek Szyprowski > > >> Reviewed-by: Krzysztof Kozlowski > > >> --- > > >> .../bindings/pci/samsung,exynos-pcie.yaml | 119 ++ > > >> 1 file changed, 119 insertions(+) > > >> create mode 100644 > > >> Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml > > > > >> ... > > > > >> + num-viewport: > > >> +const: 3 > > > I'm confused why you need this. This is only used with the iATU except > > > for keystone. Platforms like Exynos with their own child bus config > > > space accessors don't have an iATU. > > > > Frankly I have no idea, I don't know much about the PCI internals. > > Sorry, I was confused. It's fine. I was confused, too. But, as far as I remember, I also think that viewpoint-related setting was necessary for Exynos PCIe. Thank you. Best regards, Jingoo Han > > Reviewed-by: Rob Herring > > Rob
Re: [PATCH v3] MAINTAINERS: add Dan Murphy as TI LP8xxx drivers maintainer
On 11/3/20, 11:28 AM, Krzysztof Kozlowski wrote: > > Milo Kim's email in TI bounces with permanent error (550: Invalid > recipient). Last email from him on LKML was in 2017. Move Milo Kim to > credits and add Dan Murphy from TI to look after: > - TI LP855x backlight driver, > - TI LP8727 charger driver, > - TI LP8788 MFD (ADC, LEDs, charger and regulator) drivers. > > Signed-off-by: Krzysztof Kozlowski > Cc: Dan Murphy > Acked-by: Dan Murphy > Acked-by: Jonathan Cameron > Acked-by: Sebastian Reichel Acked-by: Jingoo Han Best regards, Jingoo Han [...]
Re: [PATCH V3 2/2] PCI: dwc: Add support to configure for ECRC
On 10/29/20, 1:40 AM, Vidya Sagar wrote: > > DesignWare core has a TLP digest (TD) override bit in one of the control > registers of ATU. This bit also needs to be programmed for proper ECRC > functionality. This is currently identified as an issue with DesignWare > IP version 4.90a. This patch does the required programming in ATU upon > querying the system policy for ECRC. > > Signed-off-by: Vidya Sagar > Reviewed-by: Jingoo Han No, it should be Acked-by. I gave you Acked-by, not Reviewed-by. Acked-by: Jingoo Han Best regards, Jingoo Han > --- > V3: > * Added 'Reviewed-by: Jingoo Han ' > > V2: > * Addressed Jingoo's review comment > * Removed saving 'td' bit information in 'dw_pcie' structure > > drivers/pci/controller/dwc/pcie-designware.c | 8 ++-- > drivers/pci/controller/dwc/pcie-designware.h | 1 + > 2 files changed, 7 insertions(+), 2 deletions(-) [...]
Re: [PATCH v3 5/6] pci: dwc: pci-exynos: rework the driver to support Exynos5433 variant
On 10/29/20, 9:41 AM, Marek Szyprowski wrote:
>
> From: Jaehoon Chung
>
> Exynos5440 SoC support has been dropped since commit 8c83315da1cf ("ARM:
> dts: exynos: Remove Exynos5440"). Rework this driver to support DWC PCIe
> variant found in the Exynos5433 SoCs.
>
> The main difference in Exynos5433 variant is lack of the MSI support
> (the MSI interrupt is not even routed to the CPU).
>
> Signed-off-by: Jaehoon Chung
> [mszyprow: reworked the driver to support only Exynos5433 variant,
> simplified code, rebased onto current kernel code, added
> regulator support, converted to the regular platform driver,
> removed MSI related code, rewrote commit message, added help]
> Signed-off-by: Marek Szyprowski
> Acked-by: Krzysztof Kozlowski
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/pci/controller/dwc/Kconfig | 10 +-
> drivers/pci/controller/dwc/pci-exynos.c | 353 ++--
> drivers/pci/quirks.c| 1 +
> 3 files changed, 147 insertions(+), 217 deletions(-)
[...]
Re: [PATCH V2 1/2] PCI/AER: Add pcie_is_ecrc_enabled() API
On 10/27/20, 4:03 AM, Vidya Sagar wrote:
>
> Adds pcie_is_ecrc_enabled() API to let other sub-systems (like DesignWare)
> to query if ECRC policy is enabled and perform any configuration
> required in those respective sub-systems.
>
> Signed-off-by: Vidya Sagar
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> V2:
> * None from V1
>
> drivers/pci/pci.h | 2 ++
> drivers/pci/pcie/aer.c | 11 +++
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index fa12f7cbc1a0..325fdbf91dde 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -575,9 +575,11 @@ static inline void
> pcie_aspm_powersave_config_link(struct pci_dev *pdev) { }
> #ifdef CONFIG_PCIE_ECRC
> void pcie_set_ecrc_checking(struct pci_dev *dev);
> void pcie_ecrc_get_policy(char *str);
> +bool pcie_is_ecrc_enabled(void);
> #else
> static inline void pcie_set_ecrc_checking(struct pci_dev *dev) { }
> static inline void pcie_ecrc_get_policy(char *str) { }
> +static inline bool pcie_is_ecrc_enabled(void) { return false; }
> #endif
>
> #ifdef CONFIG_PCIE_PTM
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index 65dff5f3457a..24363c895aba 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -207,6 +207,17 @@ void pcie_ecrc_get_policy(char *str)
>
> ecrc_policy = i;
> }
> +
> +/**
> + * pcie_is_ecrc_enabled - returns if ECRC is enabled in the system or not
> + *
> + * Returns 1 if ECRC policy is enabled and 0 otherwise
> + */
> +bool pcie_is_ecrc_enabled(void)
> +{
> + return ecrc_policy == ECRC_POLICY_ON;
> +}
> +EXPORT_SYMBOL(pcie_is_ecrc_enabled);
> #endif /* CONFIG_PCIE_ECRC */
>
> #define PCI_EXP_AER_FLAGS (PCI_EXP_DEVCTL_CERE |
> PCI_EXP_DEVCTL_NFERE | \
> --
> 2.17.1
Re: [PATCH V2 2/2] PCI: dwc: Add support to configure for ECRC
On 10/27/20, 4:03 AM, Vidya Sagar wrote: > > DesignWare core has a TLP digest (TD) override bit in one of the control > registers of ATU. This bit also needs to be programmed for proper ECRC > functionality. This is currently identified as an issue with DesignWare > IP version 4.90a. This patch does the required programming in ATU upon > querying the system policy for ECRC. > > Signed-off-by: Vidya Sagar Acked-by: Jingoo Han Best regards, Jingoo Han > --- > V2: > * Addressed Jingoo's review comment > * Removed saving 'td' bit information in 'dw_pcie' structure > > drivers/pci/controller/dwc/pcie-designware.c | 8 ++-- > drivers/pci/controller/dwc/pcie-designware.h | 1 + > 2 files changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c > b/drivers/pci/controller/dwc/pcie-designware.c > index b5e438b70cd5..cbd651b219d2 100644 > --- a/drivers/pci/controller/dwc/pcie-designware.c > +++ b/drivers/pci/controller/dwc/pcie-designware.c > @@ -246,6 +246,8 @@ static void dw_pcie_prog_outbound_atu_unroll(struct > dw_pcie *pci, u8 func_no, > dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET, >upper_32_bits(pci_addr)); > val = type | PCIE_ATU_FUNC_NUM(func_no); > + if (pci->version == 0x490A) > + val = val | pcie_is_ecrc_enabled() << PCIE_ATU_TD_SHIFT; > val = upper_32_bits(size - 1) ? > val | PCIE_ATU_INCREASE_REGION_SIZE : val; > dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1, val); > @@ -294,8 +296,10 @@ static void __dw_pcie_prog_outbound_atu(struct dw_pcie > *pci, u8 func_no, > 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); > + if (pci->version == 0x490A) > + val = val | pcie_is_ecrc_enabled() << PCIE_ATU_TD_SHIFT; > + 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 21dd06831b50..e5449b205c22 100644 > --- a/drivers/pci/controller/dwc/pcie-designware.h > +++ b/drivers/pci/controller/dwc/pcie-designware.h > @@ -90,6 +90,7 @@ > #define PCIE_ATU_TYPE_IO 0x2 > #define PCIE_ATU_TYPE_CFG0 0x4 > #define PCIE_ATU_TYPE_CFG1 0x5 > +#define PCIE_ATU_TD_SHIFT8 > #define PCIE_ATU_FUNC_NUM(pf) ((pf) << 20) > #define PCIE_ATU_CR2 0x908 > #define PCIE_ATU_ENABLE BIT(31) > -- > 2.17.1
Re: [PATCH 2/2] PCI: dwc: Add support to configure for ECRC
On 10/26/20, 2:59 AM, Vidya Sagar wrote:
>
> On 10/26/2020 2:19 AM, Jingoo Han wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On 10/25/20, 3:31 AM, Vidya Sagar wrote:
> >>
> >> DesignWare core has a TLP digest (TD) override bit in one of the control
> >> registers of ATU. This bit also needs to be programmed for proper ECRC
> >> functionality. This is currently identified as an issue with DesignWare
> >> IP version 4.90a. This patch does the required programming in ATU upon
> >> querying the system policy for ECRC.
> >>
> >> Signed-off-by: Vidya Sagar
> >> ---
> >> drivers/pci/controller/dwc/pcie-designware.c | 8 ++--
> >> drivers/pci/controller/dwc/pcie-designware.h | 2 ++
> >> 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 b5e438b70cd5..810dcbdbe869 100644
> >> --- a/drivers/pci/controller/dwc/pcie-designware.c
> >> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> >> @@ -245,7 +245,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct
> >> dw_pcie *pci, u8 func_no,
> >> lower_32_bits(pci_addr));
> >>dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET,
> >> upper_32_bits(pci_addr));
> >> - val = type | PCIE_ATU_FUNC_NUM(func_no);
> >> + val = type | PCIE_ATU_FUNC_NUM(func_no) | pci->td <<
> >> PCIE_ATU_TD_SHIFT;
> >>val = upper_32_bits(size - 1) ?
> >>val | PCIE_ATU_INCREASE_REGION_SIZE : val;
> >>dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1,
> >> val);
> >> @@ -295,7 +295,8 @@ static void __dw_pcie_prog_outbound_atu(struct dw_pcie
> >> *pci, u8 func_no,
> >>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));
> >> +PCIE_ATU_FUNC_NUM(func_no) |
> >> +pci->td << PCIE_ATU_TD_SHIFT);
> >>dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE);
> >>
> >>/*
> >> @@ -565,6 +566,9 @@ void dw_pcie_setup(struct dw_pcie *pci)
> >>dev_dbg(pci->dev, "iATU unroll: %s\n", pci->iatu_unroll_enabled ?
> >>"enabled" : "disabled");
> >>
> >> + if (pci->version == 0x490A)
> >> + pci->td = pcie_is_ecrc_enabled();
> >> +
> >>if (pci->link_gen > 0)
> >>dw_pcie_link_set_max_speed(pci, pci->link_gen);
> >>
> >> diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> >> b/drivers/pci/controller/dwc/pcie-designware.h
> >> index 21dd06831b50..d34723e42e79 100644
> >> --- a/drivers/pci/controller/dwc/pcie-designware.h
> >> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> >> @@ -90,6 +90,7 @@
> >> #define PCIE_ATU_TYPE_IO 0x2
> >> #define PCIE_ATU_TYPE_CFG0 0x4
> >> #define PCIE_ATU_TYPE_CFG1 0x5
> >> +#define PCIE_ATU_TD_SHIFT8
> >> #define PCIE_ATU_FUNC_NUM(pf) ((pf) << 20)
> >> #define PCIE_ATU_CR2 0x908
> >> #define PCIE_ATU_ENABLE BIT(31)
> >> @@ -276,6 +277,7 @@ struct dw_pcie {
> >>int num_lanes;
> >>int link_gen;
> >> u8 n_fts[2];
> >> + booltd; /* TLP Digest (for ECRC purpose) */
> >
> > If possible, don't add a new variable to 'dw_pcie' structure.
> > Please find a way to set TD bit without adding a new variable to 'dw_pcie'
> > structure'.
>
> I can use pcie_is_ecrc_enabled() directly in place of pci->td. That
> should be fine right? BTW, curious to know if there is any specific
> reason behind asking not to add any new variables to 'dw_pcie' structure?
>
Vice versa, what is the reason to add a new variable 'td' to 'dw_pcie'
structure?
It is not good to add a new variable to the global structure without any
specific reason.
> >
> Best regards,
> Jingoo Han
>
>> };
>>
>> #define to_dw_pcie_from_pp(port) container_of((port), struct dw_pcie, pp)
>> --
>> 2.17.1
>
Re: [PATCH v2 5/6] pci: dwc: pci-exynos: rework the driver to support Exynos5433 variant
On 10/25/20, 10:49 PM, Jaehoon Chung wrote:
>
> Dear Jingoo,
Hi Jaehoon,
> On 10/24/20 12:12 PM, Jingoo Han wrote:
> > On 10/23/20, 3:58 AM, Marek Szyprowski wrote:
> >>
> >> From: Jaehoon Chung
> >>
> >> Exynos5440 SoC support has been dropped since commit 8c83315da1cf ("ARM:
> >> dts: exynos: Remove Exynos5440"). Rework this driver to support DWC PCIe
> >> variant found in the Exynos5433 SoCs.
> >>
> >> The main difference in Exynos5433 variant is lack of the MSI support
> >> (the MSI interrupt is not even routed to the CPU).
> >>
> >> Signed-off-by: Jaehoon Chung
> >> [mszyprow: reworked the driver to support only Exynos5433 variant,
> >> simplified code, rebased onto current kernel code, added
> >> regulator support, converted to the regular platform driver,
> >> removed MSI related code, rewrote commit message]
> >> Signed-off-by: Marek Szyprowski
> >> Acked-by: Krzysztof Kozlowski
> >> ---
> >> drivers/pci/controller/dwc/Kconfig | 3 +-
> >> drivers/pci/controller/dwc/pci-exynos.c | 358 ++--
> >> drivers/pci/quirks.c| 1 +
> >> 3 files changed, 145 insertions(+), 217 deletions(-)
> >
> > []
> >
> >> diff --git a/drivers/pci/controller/dwc/pci-exynos.c
> >> b/drivers/pci/controller/dwc/pci-exynos.c
> >> index 242683cde04a..58056fbdc2fa 100644
> >> --- a/drivers/pci/controller/dwc/pci-exynos.c
> >> +++ b/drivers/pci/controller/dwc/pci-exynos.c
> >> @@ -2,26 +2,23 @@
> >> /*
> >> * PCIe host controller driver for Samsung Exynos SoCs
> >> *
> >> - * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> >> + * Copyright (C) 2013-2020 Samsung Electronics Co., Ltd.
> >> *https://www.samsung.com
> >> *
> >> * Author: Jingoo Han
> >> + * Jaehoon Chung
> >
> > Would you explain the reason why you add him as an author?
> > If reasonable, I will accept it. Also, I want gentle discussion, not
> > aggressive one.
> > Thank you.
>
> It's not important to add me as author. :)
> If you don't want to accept it, i think it can be removed it.
> I think that pci-exynos was supported on only exynos5440.
> As you know, exynos5440 was not common as compared with other exynos SoC.
> After this patch, pci-exynos is re-newed.
Ah, I just thought that you are not interested in Exynos PCIe anymore.
However, if you want
to submit other patches for supporting other Exynos PCIe, adding you as an
author is ok.
There are many Exynos SoCs that support PCIe IP. So, if someone like you who
have good
experience on Exynos, helps submitting patches for Exynos PCIe, it would be
very helpful. :-)
Thank you.
Best regards,
Jingoo Han
>
> Best Regards,
> Jaehoon Chung
>
> >
> > Best regards,
> > Jingoo Han
> >
> >> */
> >
> > []
> >
Re: [PATCH 2/2] PCI: dwc: Add support to configure for ECRC
On 10/25/20, 3:31 AM, Vidya Sagar wrote:
>
> DesignWare core has a TLP digest (TD) override bit in one of the control
> registers of ATU. This bit also needs to be programmed for proper ECRC
> functionality. This is currently identified as an issue with DesignWare
> IP version 4.90a. This patch does the required programming in ATU upon
> querying the system policy for ECRC.
>
> Signed-off-by: Vidya Sagar
> ---
> drivers/pci/controller/dwc/pcie-designware.c | 8 ++--
> drivers/pci/controller/dwc/pcie-designware.h | 2 ++
> 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 b5e438b70cd5..810dcbdbe869 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -245,7 +245,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct
> dw_pcie *pci, u8 func_no,
>lower_32_bits(pci_addr));
> dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET,
>upper_32_bits(pci_addr));
> - val = type | PCIE_ATU_FUNC_NUM(func_no);
> + val = type | PCIE_ATU_FUNC_NUM(func_no) | pci->td << PCIE_ATU_TD_SHIFT;
> val = upper_32_bits(size - 1) ?
> val | PCIE_ATU_INCREASE_REGION_SIZE : val;
> dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1, val);
> @@ -295,7 +295,8 @@ static void __dw_pcie_prog_outbound_atu(struct dw_pcie
> *pci, u8 func_no,
> 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));
> +PCIE_ATU_FUNC_NUM(func_no) |
> +pci->td << PCIE_ATU_TD_SHIFT);
> dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE);
>
> /*
> @@ -565,6 +566,9 @@ void dw_pcie_setup(struct dw_pcie *pci)
> dev_dbg(pci->dev, "iATU unroll: %s\n", pci->iatu_unroll_enabled ?
> "enabled" : "disabled");
>
> + if (pci->version == 0x490A)
> + pci->td = pcie_is_ecrc_enabled();
> +
> if (pci->link_gen > 0)
> dw_pcie_link_set_max_speed(pci, pci->link_gen);
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> b/drivers/pci/controller/dwc/pcie-designware.h
> index 21dd06831b50..d34723e42e79 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -90,6 +90,7 @@
> #define PCIE_ATU_TYPE_IO 0x2
> #define PCIE_ATU_TYPE_CFG0 0x4
> #define PCIE_ATU_TYPE_CFG1 0x5
> +#define PCIE_ATU_TD_SHIFT8
> #define PCIE_ATU_FUNC_NUM(pf) ((pf) << 20)
> #define PCIE_ATU_CR2 0x908
> #define PCIE_ATU_ENABLE BIT(31)
> @@ -276,6 +277,7 @@ struct dw_pcie {
> int num_lanes;
> int link_gen;
> u8 n_fts[2];
> + booltd; /* TLP Digest (for ECRC purpose) */
If possible, don't add a new variable to 'dw_pcie' structure.
Please find a way to set TD bit without adding a new variable to 'dw_pcie'
structure'.
Best regards,
Jingoo Han
> };
>
> #define to_dw_pcie_from_pp(port) container_of((port), struct dw_pcie, pp)
> --
> 2.17.1
Re: [PATCH 0/3] Add support to handle prefetchable memory
On 10/23/20, 3:57 PM, Vidya Sagar wrote: > > This patch series adds support for configuring the DesignWare IP's ATU > region for prefetchable memory translations. > It first starts by flagging a warning if the size of non-prefetchable > aperture goes beyond 32-bit as PCIe spec doesn't allow it. > And then adds required support for programming the ATU to handle higher > (i.e. >4GB) sizes and then finally adds support for differentiating > between prefetchable and non-prefetchable regions and configuring one of > the ATU regions for prefetchable memory translations purpose. > > Vidya Sagar (3): > PCI: of: Warn if non-prefetchable memory aperture size is > 32-bit > PCI: dwc: Add support to program ATU for >4GB memory aperture sizes > PCI: dwc: Add support to handle prefetchable memory mapping For 2nd & 3rd, Acked-by: Jingoo But, I still want someone to ack 1st patch, not me. To Vidya, If possible, can you ask your coworker to give 'Tested-by'? It will be very helpful. Thank you. Best regards, Jingoo Han > > .../pci/controller/dwc/pcie-designware-host.c | 39 --- > drivers/pci/controller/dwc/pcie-designware.c | 12 +++--- > drivers/pci/controller/dwc/pcie-designware.h | 4 +- > drivers/pci/of.c | 5 +++ > 4 files changed, 48 insertions(+), 12 deletions(-) > > -- > 2.17.1
Re: [PATCH v2 5/6] pci: dwc: pci-exynos: rework the driver to support Exynos5433 variant
On 10/23/20, 3:58 AM, Marek Szyprowski wrote:
>
> From: Jaehoon Chung
>
> Exynos5440 SoC support has been dropped since commit 8c83315da1cf ("ARM:
> dts: exynos: Remove Exynos5440"). Rework this driver to support DWC PCIe
> variant found in the Exynos5433 SoCs.
>
> The main difference in Exynos5433 variant is lack of the MSI support
> (the MSI interrupt is not even routed to the CPU).
>
> Signed-off-by: Jaehoon Chung
> [mszyprow: reworked the driver to support only Exynos5433 variant,
> simplified code, rebased onto current kernel code, added
> regulator support, converted to the regular platform driver,
> removed MSI related code, rewrote commit message]
> Signed-off-by: Marek Szyprowski
> Acked-by: Krzysztof Kozlowski
> ---
> drivers/pci/controller/dwc/Kconfig | 3 +-
> drivers/pci/controller/dwc/pci-exynos.c | 358 ++--
> drivers/pci/quirks.c| 1 +
> 3 files changed, 145 insertions(+), 217 deletions(-)
[]
> diff --git a/drivers/pci/controller/dwc/pci-exynos.c
> b/drivers/pci/controller/dwc/pci-exynos.c
> index 242683cde04a..58056fbdc2fa 100644
> --- a/drivers/pci/controller/dwc/pci-exynos.c
> +++ b/drivers/pci/controller/dwc/pci-exynos.c
> @@ -2,26 +2,23 @@
> /*
> * PCIe host controller driver for Samsung Exynos SoCs
> *
> - * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + * Copyright (C) 2013-2020 Samsung Electronics Co., Ltd.
> * https://www.samsung.com
> *
> * Author: Jingoo Han
> + * Jaehoon Chung
Would you explain the reason why you add him as an author?
If reasonable, I will accept it. Also, I want gentle discussion, not aggressive
one.
Thank you.
Best regards,
Jingoo Han
> */
[]
Re: [PATCH v2 4/6] phy: samsung: phy-exynos-pcie: rework driver to support Exynos5433 PCIe PHY
On 10/23/20, 3:59 AM, Marek Szyprowski wrote:
>
> From: Jaehoon Chung
>
> Exynos5440 SoC support has been dropped since commit 8c83315da1cf ("ARM:
> dts: exynos: Remove Exynos5440"). Rework this driver to support PCIe PHY
> variant found in the Exynos5433 SoCs.
>
> Signed-off-by: Jaehoon Chung
> [mszyprow: reworked the driver to support only Exynos5433 variant, rebased
> onto current kernel code, rewrote commit message]
> Signed-off-by: Marek Szyprowski
> Acked-by: Krzysztof Kozlowski
>
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/phy/samsung/phy-exynos-pcie.c | 304 ++
> 1 file changed, 112 insertions(+), 192 deletions(-)
[.]
Re: [PATCH v2 1/6] dt-bindings: pci: drop samsung,exynos5440-pcie binding
On 10/23/20, 3:58 AM, Marek Szyprowski wrote:
>
> Exynos5440 SoC support has been dropped since commit 8c83315da1cf ("ARM:
> dts: exynos: Remove Exynos5440"). Drop the obsolete bindings for
> exynos5440-pcie.
>
> Signed-off-by: Marek Szyprowski
> Reviewed-by: Rob Herring
> Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> .../bindings/pci/samsung,exynos5440-pcie.txt | 58 ---
> 1 file changed, 58 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
[.]
Re: [PATCH] PCI: dwc: Fix inner MSI IRQ domain registration
On 5/1/20, 7:39 AM, Marc Zyngier wrote: > On a system that uses the internal DWC MSI widget, I get this > warning from debugfs when CONFIG_GENERIC_IRQ_DEBUGFS is selected: > > debugfs: File ':soc:pcie@fc00' in directory 'domains' already present! > > This is due to the fact that the DWC MSI code tries to register two > IRQ domains for the same firmware node, without telling the low > level code how to distinguish them (by setting a bus token). This > further confuses debugfs which tries to create corresponding > files for each domain. > > Fix it by tagging the inner domain as DOMAIN_BUS_NEXUS, which is > the closest thing we have as to "generic MSI". > > Signed-off-by: Marc Zyngier Acked-by: Jingoo Han > --- > drivers/pci/controller/dwc/pcie-designware-host.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c > b/drivers/pci/controller/dwc/pcie-designware-host.c > index 395feb8ca051..3c43311bb95c 100644 > --- a/drivers/pci/controller/dwc/pcie-designware-host.c > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c > @@ -264,6 +264,8 @@ int dw_pcie_allocate_domains(struct pcie_port *pp) > return -ENOMEM; > } > > + irq_domain_update_bus_token(pp->irq_domain, DOMAIN_BUS_NEXUS); > + > pp->msi_domain = pci_msi_create_irq_domain(fwnode, > _pcie_msi_domain_info, > pp->irq_domain); > -- > 2.26.2
Re: [PATCH v3] PCI: dwc: Add support to add GEN3 related equalization quirks
On 10/16/19, 2:52 AM, 'Christoph Hellwig' wrote: > > On Tue, Oct 15, 2019 at 08:47:32PM +0530, Pankaj Dubey wrote: > > OK, but do we think the current driver has only code which is being used by > > some user? > > That is at least the intent of how we do kernel development. Agreed! > > > At least I can see current driver has some features which is not being used > > by any current driver. > > Please send patches to remove them. Agreed! Mainline kernel should not include features that have not been used. Thank you. Best regards, Jingoo Han
Re: [PATCH -next] fbdev: s3c-fb: use devm_platform_ioremap_resource() to simplify code
On 9/4/19, 7:57 AM, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
>
Acked-by: Jingoo Han
>
> ---
> drivers/video/fbdev/s3c-fb.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c
> index ba04d7a..43ac8d7 100644
> --- a/drivers/video/fbdev/s3c-fb.c
> +++ b/drivers/video/fbdev/s3c-fb.c
> @@ -1411,8 +1411,7 @@ static int s3c_fb_probe(struct platform_device *pdev)
>
> pm_runtime_enable(sfb->dev);
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - sfb->regs = devm_ioremap_resource(dev, res);
> + sfb->regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(sfb->regs)) {
> ret = PTR_ERR(sfb->regs);
> goto err_lcd_clk;
> --
> 2.7.4
Re: [PATCH V9 2/3] PCI: dwc: Cleanup DBI,ATU read and write APIs
On 6/25/19, 6:22 PM, Vidya Sagar wrote:
>
> Cleanup DBI read and write APIs by removing "__" (underscore) from their
> names as there are no no-underscore versions and the underscore versions
> are already doing what no-underscore versions typically do. It also removes
> passing dbi/dbi2 base address as one of the arguments as the same can be
> derived with in read and write APIs. Since dw_pcie_{readl/writel}_dbi()
> APIs can't be used for ATU read/write as ATU base address could be
> different from DBI base address, this patch attempts to implement
> ATU read/write APIs using ATU base address without using
> dw_pcie_{readl/writel}_dbi() APIs.
>
> Signed-off-by: Vidya Sagar
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> Changes from v8:
> * Removed exporting dw_pcie_{read/write}_atu() APIs
>
> Changes from v7:
> * Based on suggestion from Jingoo Han, moved implementation of readl, writel
> for ATU
> region to separate APIs dw_pcie_{read/write}_atu() in pcie-designware.c
> file and
> calling them from pcie-designware.h file.
>
> Changes from v6:
> * Modified ATU read/write APIs to use implementation specific DBI read/write
> APIs if present.
>
> Changes from v5:
> * Removed passing base address as one of the arguments as the same can be
> derived within
> the API itself.
> * Modified ATU read/write APIs to call dw_pcie_{write/read}() API
>
> Changes from v4:
> * This is a new patch in this series
>
> drivers/pci/controller/dwc/pcie-designware.c | 57 ++--
> drivers/pci/controller/dwc/pcie-designware.h | 34 ++--
> 2 files changed, 57 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> b/drivers/pci/controller/dwc/pcie-designware.c
> index 9d7c51c32b3b..c2843ea1d1e8 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -52,68 +52,93 @@ int dw_pcie_write(void __iomem *addr, int size, u32 val)
> return PCIBIOS_SUCCESSFUL;
> }
>
> -u32 __dw_pcie_read_dbi(struct dw_pcie *pci, void __iomem *base, u32 reg,
> -size_t size)
> +u32 dw_pcie_read_dbi(struct dw_pcie *pci, u32 reg, size_t size)
> {
> int ret;
> u32 val;
>
> if (pci->ops->read_dbi)
> - return pci->ops->read_dbi(pci, base, reg, size);
> + return pci->ops->read_dbi(pci, pci->dbi_base, reg, size);
>
> - ret = dw_pcie_read(base + reg, size, );
> + ret = dw_pcie_read(pci->dbi_base + reg, size, );
> if (ret)
> dev_err(pci->dev, "Read DBI address failed\n");
>
> return val;
> }
>
> -void __dw_pcie_write_dbi(struct dw_pcie *pci, void __iomem *base, u32 reg,
> - size_t size, u32 val)
> +void dw_pcie_write_dbi(struct dw_pcie *pci, u32 reg, size_t size, u32 val)
> {
> int ret;
>
> if (pci->ops->write_dbi) {
> - pci->ops->write_dbi(pci, base, reg, size, val);
> + pci->ops->write_dbi(pci, pci->dbi_base, reg, size, val);
> return;
> }
>
> - ret = dw_pcie_write(base + reg, size, val);
> + ret = dw_pcie_write(pci->dbi_base + reg, size, val);
> if (ret)
> dev_err(pci->dev, "Write DBI address failed\n");
> }
>
> -u32 __dw_pcie_read_dbi2(struct dw_pcie *pci, void __iomem *base, u32 reg,
> - size_t size)
> +u32 dw_pcie_read_dbi2(struct dw_pcie *pci, u32 reg, size_t size)
> {
> int ret;
> u32 val;
>
> if (pci->ops->read_dbi2)
> - return pci->ops->read_dbi2(pci, base, reg, size);
> + return pci->ops->read_dbi2(pci, pci->dbi_base2, reg, size);
>
> - ret = dw_pcie_read(base + reg, size, );
> + ret = dw_pcie_read(pci->dbi_base2 + reg, size, );
> if (ret)
> dev_err(pci->dev, "read DBI address failed\n");
>
> return val;
> }
>
> -void __dw_pcie_write_dbi2(struct dw_pcie *pci, void __iomem *base, u32 reg,
> - size_t size, u32 val)
> +void dw_pcie_write_dbi2(struct dw_pcie *pci, u32 reg, size_t size, u32 val)
> {
> int ret;
>
> if (pci->ops->write_dbi2) {
> - pci->ops->write_dbi2(pci, base, reg, size, val);
> + pci->ops->write_dbi2(pci, pci->dbi_base2, reg, size, val);
> return;
> }
>
> - ret = dw_pcie_write(base + reg, size, val);
> + ret = dw_pcie_write(pci->dbi_base2 + reg, size, val);
> if (ret)
>
Re: [PATCH V8 2/3] PCI: dwc: Cleanup DBI,ATU read and write APIs
On 6/24/19, 2:26 PM, Vidya Sagar wrote:
>
> Cleanup DBI read and write APIs by removing "__" (underscore) from their
> names as there are no no-underscore versions and the underscore versions
> are already doing what no-underscore versions typically do. It also removes
> passing dbi/dbi2 base address as one of the arguments as the same can be
> derived with in read and write APIs. Since dw_pcie_{readl/writel}_dbi()
> APIs can't be used for ATU read/write as ATU base address could be
> different from DBI base address, this patch attempts to implement
> ATU read/write APIs using ATU base address without using
> dw_pcie_{readl/writel}_dbi() APIs.
>
> Signed-off-by: Vidya Sagar
> ---
> Changes from v7:
> * Based on suggestion from Jingoo Han, moved implementation of readl, writel
> for ATU
> region to separate APIs dw_pcie_{read/write}_atu() in pcie-designware.c
> file and
> calling them from pcie-designware.h file.
>
> Changes from v6:
> * Modified ATU read/write APIs to use implementation specific DBI read/write
> APIs if present.
>
> Changes from v5:
> * Removed passing base address as one of the arguments as the same can be
> derived within
> the API itself.
> * Modified ATU read/write APIs to call dw_pcie_{write/read}() API
>
> Changes from v4:
> * This is a new patch in this series
>
> drivers/pci/controller/dwc/pcie-designware.c | 28 +--
> drivers/pci/controller/dwc/pcie-designware.h | 51 +---
> 2 files changed, 45 insertions(+), 34 deletions(-)
...
> +u32 dw_pcie_read_atu(struct dw_pcie *pci, u32 reg, size_t size)
> +{
> + int ret;
> + u32 val;
> +
> + if (pci->ops->read_dbi)
> + return pci->ops->read_dbi(pci, pci->atu_base, reg, size);
> +
> + ret = dw_pcie_read(pci->atu_base + reg, size, );
> + if (ret)
> + dev_err(pci->dev, "Read ATU address failed\n");
> +
> + return val;
> +}
> +EXPORT_SYMBOL_GPL(dw_pcie_read_atu);
Don't export dw_pcie_read_atu unnecessarily.
> +
> +void dw_pcie_write_atu(struct dw_pcie *pci, u32 reg, size_t size, u32 val)
> +{
> + int ret;
> +
> + if (pci->ops->write_dbi) {
> + pci->ops->write_dbi(pci, pci->atu_base, reg, size, val);
> + return;
> + }
> +
> + ret = dw_pcie_write(pci->atu_base + reg, size, val);
> + if (ret)
> + dev_err(pci->dev, "Write ATU address failed\n");
> +}
> +EXPORT_SYMBOL_GPL(dw_pcie_write_atu);
Don't export dw_pcie_write_atu unnecessarily.
Best regards,
Jingoo Han
.
Re: [PATCH V7 2/3] PCI: dwc: Cleanup DBI,ATU read and write APIs
On 6/23/19, 1:52 AM, Vidya Sagar wrote:
>
> Cleanup DBI read and write APIs by removing "__" (underscore) from their
> names as there are no no-underscore versions and the underscore versions
> are already doing what no-underscore versions typically do. It also removes
> passing dbi/dbi2 base address as one of the arguments as the same can be
> derived with in read and write APIs. Since dw_pcie_{readl/writel}_dbi()
> APIs can't be used for ATU read/write as ATU base address could be
> different from DBI base address, this patch attempts to implement
> ATU read/write APIs using ATU base address without using
> dw_pcie_{readl/writel}_dbi() APIs.
>
> Signed-off-by: Vidya Sagar
> ---
> Changes from v6:
> * Modified ATU read/write APIs to use implementation specific DBI read/write
> APIs if present.
>
> Changes from v5:
> * Removed passing base address as one of the arguments as the same can be
> derived within
> the API itself.
> * Modified ATU read/write APIs to call dw_pcie_{write/read}() API
>
> Changes from v4:
> * This is a new patch in this series
>
> drivers/pci/controller/dwc/pcie-designware.c | 28 +--
> drivers/pci/controller/dwc/pcie-designware.h | 51 +---
> 2 files changed, 45 insertions(+), 34 deletions(-)
.
> static inline void dw_pcie_writel_atu(struct dw_pcie *pci, u32 reg, u32 val)
> {
> - __dw_pcie_write_dbi(pci, pci->atu_base, reg, 0x4, val);
> + int ret;
> +
> + if (pci->ops->write_dbi) {
> + pci->ops->write_dbi(pci, pci->atu_base, reg, 0x4, val);
> + return;
> + }
> +
> + ret = dw_pcie_write(pci->atu_base + reg, 0x4, val);
> + if (ret)
> + dev_err(pci->dev, "Write ATU address failed\n");
> }
>
> static inline u32 dw_pcie_readl_atu(struct dw_pcie *pci, u32 reg)
> {
> - return __dw_pcie_read_dbi(pci, pci->atu_base, reg, 0x4);
> + int ret;
> + u32 val;
> +
> + if (pci->ops->read_dbi)
> + return pci->ops->read_dbi(pci, pci->atu_base, reg, 0x4);
> +
> + ret = dw_pcie_read(pci->atu_base + reg, 0x4, );
> + if (ret)
> + dev_err(pci->dev, "Read ATU address failed\n");
> +
> + return val;
> }
Hmm. In cases of dbi and dbi2, readb/readw/readl and writeb/writew/writel are
located in pcie-designware.h. These functions just call read/write which are
located
in pcie-designware.c. For readability, would you write the code as below?
1. For drivers/pci/controller/dwc/pcie-designware.h,
Just call dw_pcie_{write/read}_atu(), instead of implementing functions as
below.
static inline void dw_pcie_writel_atu(struct dw_pcie *pci, u32 reg, u32
val)
{
return dw_pcie_write_atu(pci, reg, 0x4, val);
}
static inline u32 dw_pcie_readl_atu(struct dw_pcie *pci, u32 reg)
{
return dw_pcie_read_atu(pci, reg, 0x4);
}
2. For drivers/pci/controller/dwc/pcie-designware.c,
Please add new dw_pcie_{write/read}_atu() as below.
void dw_pcie_write_atu(struct dw_pcie *pci, u32 reg, size_t size, u32
val)
{
int ret;
if (pci->ops->write_dbi) {
pci->ops->write_dbi(pci, pci->atu_base, reg, size, val);
return;
}
ret = dw_pcie_write(pci->atu_base + reg, size, val);
if (ret)
dev_err(pci->dev, "Write ATU address failed\n");
}
u32 dw_pcie_read_atu(struct dw_pcie *pci, u32 reg, size_t size)
{
int ret;
u32 val;
if (pci->ops->read_dbi)
return pci->ops->read_dbi(pci, pci->atu_base, reg,
size);
ret = dw_pcie_read(pci->atu_base + reg, size, );
if (ret)
dev_err(pci->dev, "Read ATU address failed\n");
return val;
}
Thank you.
Best regards,
Jingoo Han
>
> static inline void dw_pcie_dbi_ro_wr_en(struct dw_pcie *pci)
> --
> 2.17.1
Re: [PATCH V6 2/3] PCI: dwc: Cleanup DBI read and write APIs
On 6/21/19, 8:10 PM, Vidya Sagar wrote:
>
> Cleanup DBI read and write APIs by removing "__" (underscore) from their
> names as there are no no-underscore versions and the underscore versions
> are already doing what no-underscore versions typically do. It also removes
> passing dbi/dbi2 base address as one of the arguments as the same can be
> derived with in read and write APIs.
>
> Signed-off-by: Vidya Sagar
> ---
> Changes from v5:
> * Removed passing base address as one of the arguments as the same can be
> derived within
> the API itself.
> * Modified ATU read/write APIs to call dw_pcie_{write/read}() API
Unlike previous patches (v1~v5), you modified ATU read/write APIs from v6.
Why do you change ATU read/write APIs to call dw_pcie_{write/read}() API???
It is not clean-up, but function change. Please add the reason to the commit
message.
Best regards,
Jingoo Han
>
> Changes from v4:
> * This is a new patch in this series
>
> drivers/pci/controller/dwc/pcie-designware.c | 28 ++---
> drivers/pci/controller/dwc/pcie-designware.h | 43
> 2 files changed, 37 insertions(+), 34 deletions(-)
.
> static inline void dw_pcie_writel_atu(struct dw_pcie *pci, u32 reg, u32 val)
> {
> - __dw_pcie_write_dbi(pci, pci->atu_base, reg, 0x4, val);
> + int ret;
> +
> + ret = dw_pcie_write(pci->atu_base + reg, 0x4, val);
> + if (ret)
> + dev_err(pci->dev, "write ATU address failed\n");
> }
>
> static inline u32 dw_pcie_readl_atu(struct dw_pcie *pci, u32 reg)
> {
> - return __dw_pcie_read_dbi(pci, pci->atu_base, reg, 0x4);
> + int ret;
> + u32 val;
> +
> + ret = dw_pcie_read(pci->atu_base + reg, 0x4, );
> + if (ret)
> + dev_err(pci->dev, "Read ATU address failed\n");
> +
> + return val;
> }
>
> static inline void dw_pcie_dbi_ro_wr_en(struct dw_pcie *pci)
> --
> 2.17.1
Re: [PATCH] video: fbdev: s3c-fb: add COMPILE_TEST support
On 6/14/19, 11:46 PM, Bartlomiej Zolnierkiewicz wrote: > > Add COMPILE_TEST support to s3c-fb driver for better compile > testing coverage. > > Cc: Jingoo Han Acked-by: Jingoo Han > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > drivers/video/fbdev/Kconfig |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > Index: b/drivers/video/fbdev/Kconfig > === > --- a/drivers/video/fbdev/Kconfig > +++ b/drivers/video/fbdev/Kconfig > @@ -1877,7 +1877,8 @@ config FB_TMIO_ACCELL > > config FB_S3C > tristate "Samsung S3C framebuffer support" > - depends on FB && (CPU_S3C2416 || ARCH_S3C64XX) > + depends on FB && HAVE_CLK && HAS_IOMEM > + depends on (CPU_S3C2416 || ARCH_S3C64XX) || COMPILE_TEST > select FB_CFB_FILLRECT > select FB_CFB_COPYAREA > select FB_CFB_IMAGEBLIT
Re: [PATCH V10 03/15] PCI: dwc: Perform dbi regs write lock towards the end
On 6/12/19, 6:54 PM, Vidya Sagar wrote:
>
> Remove multiple write enable and disable sequences of dbi registers as
> Tegra194 implements writes to BAR-0 register (offset: 0x10) controlled by
> DBI write-lock enable bit thereby not allowing any further writes to BAR-0
> register in config space to take place. Hence enabling write permission at
> the start of function and disabling the same only towards the end.
>
> Signed-off-by: Vidya Sagar
> Reviewed-by: Thierry Reding
Acked-by: Jingoo Han
Sorry for being late. I read the previous threads. I don't think that this patch
has any harmful effects. This patch looks good to me.
Thank you.
Best regards,
Jingoo Han
> ---
> Changes since [v9]:
> * None
>
> Changes since [v8]:
> * None
>
> Changes since [v7]:
> * None
>
> Changes since [v6]:
> * None
>
> Changes since [v5]:
> * Moved write enable to the beginning of the API and write disable to the end
>
> Changes since [v4]:
> * None
>
> Changes since [v3]:
> * None
>
> Changes since [v2]:
> * None
>
> Changes since [v1]:
> * None
>
> drivers/pci/controller/dwc/pcie-designware-host.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> b/drivers/pci/controller/dwc/pcie-designware-host.c
> index f93252d0da5b..d3156446ff27 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -628,6 +628,12 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
> u32 val, ctrl, num_ctrls;
> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>
> + /*
> + * Enable DBI read-only registers for writing/updating configuration.
> + * Write permission gets disabled towards the end of this function.
> + */
> + dw_pcie_dbi_ro_wr_en(pci);
> +
> dw_pcie_setup(pci);
>
> if (!pp->ops->msi_host_init) {
> @@ -650,12 +656,10 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
> dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_1, 0x);
>
> /* Setup interrupt pins */
> - dw_pcie_dbi_ro_wr_en(pci);
> val = dw_pcie_readl_dbi(pci, PCI_INTERRUPT_LINE);
> val &= 0x00ff;
> val |= 0x0100;
> dw_pcie_writel_dbi(pci, PCI_INTERRUPT_LINE, val);
> - dw_pcie_dbi_ro_wr_dis(pci);
>
> /* Setup bus numbers */
> val = dw_pcie_readl_dbi(pci, PCI_PRIMARY_BUS);
> @@ -687,15 +691,13 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>
> dw_pcie_wr_own_conf(pp, PCI_BASE_ADDRESS_0, 4, 0);
>
> - /* Enable write permission for the DBI read-only register */
> - dw_pcie_dbi_ro_wr_en(pci);
> /* Program correct class for RC */
> dw_pcie_wr_own_conf(pp, PCI_CLASS_DEVICE, 2, PCI_CLASS_BRIDGE_PCI);
> - /* Better disable write permission right after the update */
> - dw_pcie_dbi_ro_wr_dis(pci);
>
> dw_pcie_rd_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, );
> val |= PORT_LOGIC_SPEED_CHANGE;
> dw_pcie_wr_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, val);
> +
> + dw_pcie_dbi_ro_wr_dis(pci);
> }
> EXPORT_SYMBOL_GPL(dw_pcie_setup_rc);
> --
> 2.17.1
Re: [PATCH v4 4/8] PCI: Replace dev_node parameter of of_pci_get_host_bridge_resources with device
On Tuesday, May 15, 2018 5:07 AM, Jan Kiszka wrote: > > From: Jan Kiszka <jan.kis...@siemens.com> > > Another step towards a managed version of > of_pci_get_host_bridge_resources(): Feed in the underlying device, > rather than just the OF node. This will allow to use managed resource > allocation internally later on. > > CC: Jingoo Han <jingooh...@gmail.com> > CC: Joao Pinto <joao.pi...@synopsys.com> > CC: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> Acked-by: Jingoo Han <jingooh...@gmail.com> Best regards, Jingoo Han > --- > drivers/pci/dwc/pcie-designware-host.c | 2 +- > drivers/pci/host/pci-aardvark.c| 5 ++--- > drivers/pci/host/pci-ftpci100.c| 4 ++-- > drivers/pci/host/pci-v3-semi.c | 3 ++- > drivers/pci/host/pci-versatile.c | 3 +-- > drivers/pci/host/pci-xgene.c | 3 ++- > drivers/pci/host/pcie-altera.c | 5 ++--- > drivers/pci/host/pcie-iproc-platform.c | 4 ++-- > drivers/pci/host/pcie-rcar.c | 5 ++--- > drivers/pci/host/pcie-rockchip.c | 4 ++-- > drivers/pci/host/pcie-xilinx-nwl.c | 4 ++-- > drivers/pci/host/pcie-xilinx.c | 4 ++-- > drivers/pci/of.c | 9 + > include/linux/of_pci.h | 4 ++-- > 14 files changed, 29 insertions(+), 30 deletions(-) >
Re: [PATCH v4 4/8] PCI: Replace dev_node parameter of of_pci_get_host_bridge_resources with device
On Tuesday, May 15, 2018 5:07 AM, Jan Kiszka wrote: > > From: Jan Kiszka > > Another step towards a managed version of > of_pci_get_host_bridge_resources(): Feed in the underlying device, > rather than just the OF node. This will allow to use managed resource > allocation internally later on. > > CC: Jingoo Han > CC: Joao Pinto > CC: Lorenzo Pieralisi > Signed-off-by: Jan Kiszka Acked-by: Jingoo Han Best regards, Jingoo Han > --- > drivers/pci/dwc/pcie-designware-host.c | 2 +- > drivers/pci/host/pci-aardvark.c| 5 ++--- > drivers/pci/host/pci-ftpci100.c| 4 ++-- > drivers/pci/host/pci-v3-semi.c | 3 ++- > drivers/pci/host/pci-versatile.c | 3 +-- > drivers/pci/host/pci-xgene.c | 3 ++- > drivers/pci/host/pcie-altera.c | 5 ++--- > drivers/pci/host/pcie-iproc-platform.c | 4 ++-- > drivers/pci/host/pcie-rcar.c | 5 ++--- > drivers/pci/host/pcie-rockchip.c | 4 ++-- > drivers/pci/host/pcie-xilinx-nwl.c | 4 ++-- > drivers/pci/host/pcie-xilinx.c | 4 ++-- > drivers/pci/of.c | 9 + > include/linux/of_pci.h | 4 ++-- > 14 files changed, 29 insertions(+), 30 deletions(-) >
Re: [PATCH v4 6/8] PCI: Rework of_pci_get_host_bridge_resources() to devm_of_pci_get_host_bridge_resources()
On Tuesday, May 15, 2018 5:07 AM, Jan Kiszka wrote: > > From: Jan Kiszka <jan.kis...@siemens.com> > > of_pci_get_host_bridge_resources() allocates the resource structures it > fills dynamically, but none of its callers care to release them so far. > Rather than requiring everyone to do this explicitly, convert the > existing function to a managed version. > > CC: Jingoo Han <jingooh...@gmail.com> > CC: Joao Pinto <joao.pi...@synopsys.com> > CC: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> Acked-by: Jingoo Han <jingooh...@gmail.com> Best regards, Jingoo Han > --- > drivers/pci/dwc/pcie-designware-host.c | 2 +- > drivers/pci/host/pci-aardvark.c| 2 +- > drivers/pci/host/pci-ftpci100.c| 2 +- > drivers/pci/host/pci-v3-semi.c | 2 +- > drivers/pci/host/pci-versatile.c | 2 +- > drivers/pci/host/pci-xgene.c | 2 +- > drivers/pci/host/pcie-altera.c | 2 +- > drivers/pci/host/pcie-iproc-platform.c | 2 +- > drivers/pci/host/pcie-rcar.c | 2 +- > drivers/pci/host/pcie-rockchip.c | 2 +- > drivers/pci/host/pcie-xilinx-nwl.c | 2 +- > drivers/pci/host/pcie-xilinx.c | 2 +- > drivers/pci/of.c | 30 -- > include/linux/of_pci.h | 4 ++-- > 14 files changed, 26 insertions(+), 32 deletions(-) >
Re: [PATCH v4 6/8] PCI: Rework of_pci_get_host_bridge_resources() to devm_of_pci_get_host_bridge_resources()
On Tuesday, May 15, 2018 5:07 AM, Jan Kiszka wrote: > > From: Jan Kiszka > > of_pci_get_host_bridge_resources() allocates the resource structures it > fills dynamically, but none of its callers care to release them so far. > Rather than requiring everyone to do this explicitly, convert the > existing function to a managed version. > > CC: Jingoo Han > CC: Joao Pinto > CC: Lorenzo Pieralisi > Signed-off-by: Jan Kiszka Acked-by: Jingoo Han Best regards, Jingoo Han > --- > drivers/pci/dwc/pcie-designware-host.c | 2 +- > drivers/pci/host/pci-aardvark.c| 2 +- > drivers/pci/host/pci-ftpci100.c| 2 +- > drivers/pci/host/pci-v3-semi.c | 2 +- > drivers/pci/host/pci-versatile.c | 2 +- > drivers/pci/host/pci-xgene.c | 2 +- > drivers/pci/host/pcie-altera.c | 2 +- > drivers/pci/host/pcie-iproc-platform.c | 2 +- > drivers/pci/host/pcie-rcar.c | 2 +- > drivers/pci/host/pcie-rockchip.c | 2 +- > drivers/pci/host/pcie-xilinx-nwl.c | 2 +- > drivers/pci/host/pcie-xilinx.c | 2 +- > drivers/pci/of.c | 30 -- > include/linux/of_pci.h | 4 ++-- > 14 files changed, 26 insertions(+), 32 deletions(-) >
Re: [PATCH V2 1/5] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c
On Thursday, May 3, 2018 6:12 AM, Kiran Gunda wrote:
If you really want someone to review your patch, please add more detailed
explanations.
1. Please add 0th patch.
2. Please add what the difference is between V1 and V2 patches.
If you cannot understand what I am saying, just ask another person who have
an experience to send patches to Linux mailing-list.
Best regards,
Jingoo Han
>
> pm8941-wled.c driver is supporting the WLED peripheral
> on pm8941. Rename it to qcom-wled.c so that it can support
> WLED on multiple PMICs.
>
> Signed-off-by: Kiran Gunda <kgu...@codeaurora.org>
> ---
> .../bindings/leds/backlight/{pm8941-wled.txt => qcom-wled.txt}| 2 +-
> drivers/video/backlight/Kconfig | 8
> drivers/video/backlight/Makefile | 2 +-
> drivers/video/backlight/{pm8941-wled.c => qcom-wled.c}| 0
> 4 files changed, 6 insertions(+), 6 deletions(-)
> rename Documentation/devicetree/bindings/leds/backlight/{pm8941-wled.txt
> => qcom-wled.txt} (95%)
> rename drivers/video/backlight/{pm8941-wled.c => qcom-wled.c} (100%)
>
> diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-
> wled.txt b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> similarity index 95%
> rename from Documentation/devicetree/bindings/leds/backlight/pm8941-
> wled.txt
> rename to Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> index e5b294d..fb39e32 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
> +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> @@ -1,4 +1,4 @@
> -Binding for Qualcomm PM8941 WLED driver
> +Binding for Qualcomm Technologies, Inc. WLED driver
>
> Required properties:
> - compatible: should be "qcom,pm8941-wled"
> diff --git a/drivers/video/backlight/Kconfig
> b/drivers/video/backlight/Kconfig
> index 4e1d2ad..8c095e3 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -299,12 +299,12 @@ config BACKLIGHT_TOSA
> If you have an Sharp SL-6000 Zaurus say Y to enable a driver
> for its backlight
>
> -config BACKLIGHT_PM8941_WLED
> - tristate "Qualcomm PM8941 WLED Driver"
> +config BACKLIGHT_QCOM_WLED
> + tristate "Qualcomm PMIC WLED Driver"
> select REGMAP
> help
> - If you have the Qualcomm PM8941, say Y to enable a driver for the
> - WLED block.
> + If you have the Qualcomm PMIC, say Y to enable a driver for the
> + WLED block. Currently it supports PM8941 and PMI8998.
>
> config BACKLIGHT_SAHARA
> tristate "Tabletkiosk Sahara Touch-iT Backlight Driver"
> diff --git a/drivers/video/backlight/Makefile
> b/drivers/video/backlight/Makefile
> index 5e28f01..6fd76ef 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -49,8 +49,8 @@ obj-$(CONFIG_BACKLIGHT_OMAP1) +=
omap1_bl.o
> obj-$(CONFIG_BACKLIGHT_OT200)+= ot200_bl.o
> obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
> obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
> -obj-$(CONFIG_BACKLIGHT_PM8941_WLED) += pm8941-wled.o
> obj-$(CONFIG_BACKLIGHT_PWM) += pwm_bl.o
> +obj-$(CONFIG_BACKLIGHT_QCOM_WLED)+= qcom-wled.o
> obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
> obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
> obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
> diff --git a/drivers/video/backlight/pm8941-wled.c
> b/drivers/video/backlight/qcom-wled.c
> similarity index 100%
> rename from drivers/video/backlight/pm8941-wled.c
> rename to drivers/video/backlight/qcom-wled.c
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
Re: [PATCH V2 1/5] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c
On Thursday, May 3, 2018 6:12 AM, Kiran Gunda wrote:
If you really want someone to review your patch, please add more detailed
explanations.
1. Please add 0th patch.
2. Please add what the difference is between V1 and V2 patches.
If you cannot understand what I am saying, just ask another person who have
an experience to send patches to Linux mailing-list.
Best regards,
Jingoo Han
>
> pm8941-wled.c driver is supporting the WLED peripheral
> on pm8941. Rename it to qcom-wled.c so that it can support
> WLED on multiple PMICs.
>
> Signed-off-by: Kiran Gunda
> ---
> .../bindings/leds/backlight/{pm8941-wled.txt => qcom-wled.txt}| 2 +-
> drivers/video/backlight/Kconfig | 8
> drivers/video/backlight/Makefile | 2 +-
> drivers/video/backlight/{pm8941-wled.c => qcom-wled.c}| 0
> 4 files changed, 6 insertions(+), 6 deletions(-)
> rename Documentation/devicetree/bindings/leds/backlight/{pm8941-wled.txt
> => qcom-wled.txt} (95%)
> rename drivers/video/backlight/{pm8941-wled.c => qcom-wled.c} (100%)
>
> diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-
> wled.txt b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> similarity index 95%
> rename from Documentation/devicetree/bindings/leds/backlight/pm8941-
> wled.txt
> rename to Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> index e5b294d..fb39e32 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
> +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> @@ -1,4 +1,4 @@
> -Binding for Qualcomm PM8941 WLED driver
> +Binding for Qualcomm Technologies, Inc. WLED driver
>
> Required properties:
> - compatible: should be "qcom,pm8941-wled"
> diff --git a/drivers/video/backlight/Kconfig
> b/drivers/video/backlight/Kconfig
> index 4e1d2ad..8c095e3 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -299,12 +299,12 @@ config BACKLIGHT_TOSA
> If you have an Sharp SL-6000 Zaurus say Y to enable a driver
> for its backlight
>
> -config BACKLIGHT_PM8941_WLED
> - tristate "Qualcomm PM8941 WLED Driver"
> +config BACKLIGHT_QCOM_WLED
> + tristate "Qualcomm PMIC WLED Driver"
> select REGMAP
> help
> - If you have the Qualcomm PM8941, say Y to enable a driver for the
> - WLED block.
> + If you have the Qualcomm PMIC, say Y to enable a driver for the
> + WLED block. Currently it supports PM8941 and PMI8998.
>
> config BACKLIGHT_SAHARA
> tristate "Tabletkiosk Sahara Touch-iT Backlight Driver"
> diff --git a/drivers/video/backlight/Makefile
> b/drivers/video/backlight/Makefile
> index 5e28f01..6fd76ef 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -49,8 +49,8 @@ obj-$(CONFIG_BACKLIGHT_OMAP1) +=
omap1_bl.o
> obj-$(CONFIG_BACKLIGHT_OT200)+= ot200_bl.o
> obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
> obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
> -obj-$(CONFIG_BACKLIGHT_PM8941_WLED) += pm8941-wled.o
> obj-$(CONFIG_BACKLIGHT_PWM) += pwm_bl.o
> +obj-$(CONFIG_BACKLIGHT_QCOM_WLED)+= qcom-wled.o
> obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
> obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
> obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
> diff --git a/drivers/video/backlight/pm8941-wled.c
> b/drivers/video/backlight/qcom-wled.c
> similarity index 100%
> rename from drivers/video/backlight/pm8941-wled.c
> rename to drivers/video/backlight/qcom-wled.c
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
Re: [PATCH 2/2] backlight: Remove ld9040 driver
> -Original Message- > From: Krzysztof Kozlowski <k...@kernel.org> > Sent: Monday, April 30, 2018 1:30 PM > To: Lee Jones <lee.jo...@linaro.org>; Daniel Thompson > <daniel.thomp...@linaro.org>; Jingoo Han <jingooh...@gmail.com>; > Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>; linux- > ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; linux- > fb...@vger.kernel.org > Cc: Krzysztof Kozlowski <k...@kernel.org>; Marek Szyprowski > <m.szyprow...@samsung.com>; Inki Dae <inki@samsung.com> > Subject: [PATCH 2/2] backlight: Remove ld9040 driver > > The driver for LD9040 AMOLED LCD panel was superseded with DRM driver > panel-samsung-ld9040.c. It does not support DeviceTree and respective > possible user (Exynos4210 Universal C210) is DeviceTree-only and uses > DRM version of driver.. > > Suggested-by: Marek Szyprowski <m.szyprow...@samsung.com> > Cc: Marek Szyprowski <m.szyprow...@samsung.com> > Cc: Inki Dae <inki@samsung.com> > Signed-off-by: Krzysztof Kozlowski <k...@kernel.org> > --- > drivers/video/backlight/Kconfig| 8 - > drivers/video/backlight/Makefile | 1 - > drivers/video/backlight/ld9040.c | 811 - > > drivers/video/backlight/ld9040_gamma.h | 202 > 4 files changed, 1022 deletions(-) > delete mode 100644 drivers/video/backlight/ld9040.c > delete mode 100644 drivers/video/backlight/ld9040_gamma.h Acked-by: Jingoo Han <jingooh...@gmail.com> Best regards, Jingoo Han [.]
Re: [PATCH 2/2] backlight: Remove ld9040 driver
> -Original Message- > From: Krzysztof Kozlowski > Sent: Monday, April 30, 2018 1:30 PM > To: Lee Jones ; Daniel Thompson > ; Jingoo Han ; > Bartlomiej Zolnierkiewicz ; linux- > ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; linux- > fb...@vger.kernel.org > Cc: Krzysztof Kozlowski ; Marek Szyprowski > ; Inki Dae > Subject: [PATCH 2/2] backlight: Remove ld9040 driver > > The driver for LD9040 AMOLED LCD panel was superseded with DRM driver > panel-samsung-ld9040.c. It does not support DeviceTree and respective > possible user (Exynos4210 Universal C210) is DeviceTree-only and uses > DRM version of driver.. > > Suggested-by: Marek Szyprowski > Cc: Marek Szyprowski > Cc: Inki Dae > Signed-off-by: Krzysztof Kozlowski > --- > drivers/video/backlight/Kconfig| 8 - > drivers/video/backlight/Makefile | 1 - > drivers/video/backlight/ld9040.c | 811 - > > drivers/video/backlight/ld9040_gamma.h | 202 > 4 files changed, 1022 deletions(-) > delete mode 100644 drivers/video/backlight/ld9040.c > delete mode 100644 drivers/video/backlight/ld9040_gamma.h Acked-by: Jingoo Han Best regards, Jingoo Han [.]
Re: [PATCH 1/2] backlight: Remove s6e63m0 driver
On Monday, April 30, 2018 1:30 PM, Krzysztof Kozlowski wrote: > > The driver for S6E63M0 AMOLED LCD panel is not used. It does not > support DeviceTree and respective possible users (S5Pv210 Aquila and > Goni boards) are DeviceTree-only. > > Suggested-by: Marek Szyprowski <m.szyprow...@samsung.com> > Cc: Marek Szyprowski <m.szyprow...@samsung.com> > Cc: Inki Dae <inki@samsung.com> > Signed-off-by: Krzysztof Kozlowski <k...@kernel.org> > --- > drivers/video/backlight/Kconfig | 8 - > drivers/video/backlight/Makefile| 1 - > drivers/video/backlight/s6e63m0.c | 857 > Acked-by: Jingoo Han <jingooh...@gmail.com> Best regards, Jingoo Han [.]
Re: [PATCH 1/2] backlight: Remove s6e63m0 driver
On Monday, April 30, 2018 1:30 PM, Krzysztof Kozlowski wrote: > > The driver for S6E63M0 AMOLED LCD panel is not used. It does not > support DeviceTree and respective possible users (S5Pv210 Aquila and > Goni boards) are DeviceTree-only. > > Suggested-by: Marek Szyprowski > Cc: Marek Szyprowski > Cc: Inki Dae > Signed-off-by: Krzysztof Kozlowski > --- > drivers/video/backlight/Kconfig | 8 - > drivers/video/backlight/Makefile| 1 - > drivers/video/backlight/s6e63m0.c | 857 -------- > ---- Acked-by: Jingoo Han Best regards, Jingoo Han [.]
Re: [PATCH 4/6] PCI: Convert of_pci_get_host_bridge_resources users to devm variant
> -Original Message-
> From: Jan Kiszka <jan.kis...@siemens.com>
> Sent: Tuesday, April 24, 2018 11:14 AM
> To: Bjorn Helgaas <bhelg...@google.com>; Linux Kernel Mailing List ker...@vger.kernel.org>; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Cc: Jingoo Han <jingooh...@gmail.com>; Joao Pinto
> <joao.pi...@synopsys.com>; Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
> Subject: [PATCH 4/6] PCI: Convert of_pci_get_host_bridge_resources users
> to devm variant
>
> From: Jan Kiszka <jan.kis...@siemens.com>
>
> Straightforward for all of them, no more leaks afterwards.
>
> CC: Jingoo Han <jingooh...@gmail.com>
For drivers/pci/dwc/pcie-designware-host.c,
Acked-by: Jingoo Han <jingoo1...@gmail.com>
Best regards,
Jingoo Han
> CC: Joao Pinto <joao.pi...@synopsys.com>
> CC: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
> ---
> drivers/pci/dwc/pcie-designware-host.c | 2 +-
> drivers/pci/host/pci-aardvark.c| 5 ++---
> drivers/pci/host/pci-ftpci100.c| 4 ++--
> drivers/pci/host/pci-v3-semi.c | 3 ++-
> drivers/pci/host/pci-versatile.c | 3 +--
> drivers/pci/host/pci-xgene.c | 3 ++-
> drivers/pci/host/pcie-altera.c | 5 ++---
> drivers/pci/host/pcie-iproc-platform.c | 4 ++--
> drivers/pci/host/pcie-rcar.c | 5 ++---
> drivers/pci/host/pcie-rockchip.c | 4 ++--
> drivers/pci/host/pcie-xilinx-nwl.c | 4 ++--
> drivers/pci/host/pcie-xilinx.c | 4 ++--
> drivers/pci/of.c | 4 ++--
> 13 files changed, 24 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/pci/dwc/pcie-designware-host.c
> b/drivers/pci/dwc/pcie-designware-host.c
> index 6c409079d514..a8f6ab54b4c0 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -342,7 +342,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
> if (!bridge)
> return -ENOMEM;
>
> - ret = of_pci_get_host_bridge_resources(np, 0, 0xff,
> + ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> >windows, >io_base);
> if (ret)
> return ret;
> diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-
> aardvark.c
> index b04d37b3c5de..709f0d69e35b 100644
> --- a/drivers/pci/host/pci-aardvark.c
> +++ b/drivers/pci/host/pci-aardvark.c
> @@ -815,14 +815,13 @@ static int
> advk_pcie_parse_request_of_pci_ranges(struct advk_pcie *pcie)
> {
> int err, res_valid = 0;
> struct device *dev = >pdev->dev;
> - struct device_node *np = dev->of_node;
> struct resource_entry *win, *tmp;
> resource_size_t iobase;
>
> INIT_LIST_HEAD(>resources);
>
> - err = of_pci_get_host_bridge_resources(np, 0, 0xff,
> >resources,
> -);
> + err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> + >resources,
);
> if (err)
> return err;
>
> diff --git a/drivers/pci/host/pci-ftpci100.c b/drivers/pci/host/pci-
> ftpci100.c
> index 5008fd87956a..87748eaeaaed 100644
> --- a/drivers/pci/host/pci-ftpci100.c
> +++ b/drivers/pci/host/pci-ftpci100.c
> @@ -476,8 +476,8 @@ static int faraday_pci_probe(struct platform_device
> *pdev)
> if (IS_ERR(p->base))
> return PTR_ERR(p->base);
>
> - ret = of_pci_get_host_bridge_resources(dev->of_node, 0, 0xff,
> -, _base);
> + ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> + , _base);
> if (ret)
> return ret;
>
> diff --git a/drivers/pci/host/pci-v3-semi.c b/drivers/pci/host/pci-v3-
> semi.c
> index 0a4dea796663..167bf6f6b378 100644
> --- a/drivers/pci/host/pci-v3-semi.c
> +++ b/drivers/pci/host/pci-v3-semi.c
> @@ -791,7 +791,8 @@ static int v3_pci_probe(struct platform_device *pdev)
> if (IS_ERR(v3->config_base))
> return PTR_ERR(v3->config_base);
>
> - ret = of_pci_get_host_bridge_resources(np, 0, 0xff, , _base);
> + ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, ,
> + _base);
> if (ret)
> return ret;
>
> diff --git a/drivers/pci/host/pci-versatile.c b/drivers/pci/host/pci-
> versatile.c
> index 5b3876f5312b..ff2cd12b3978 100644
> --- a/drivers/pci/host/pci-versatile.c
> +++ b/drivers/pci/host/pci
Re: [PATCH 4/6] PCI: Convert of_pci_get_host_bridge_resources users to devm variant
> -Original Message-
> From: Jan Kiszka
> Sent: Tuesday, April 24, 2018 11:14 AM
> To: Bjorn Helgaas ; Linux Kernel Mailing List ker...@vger.kernel.org>; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Cc: Jingoo Han ; Joao Pinto
> ; Lorenzo Pieralisi
> Subject: [PATCH 4/6] PCI: Convert of_pci_get_host_bridge_resources users
> to devm variant
>
> From: Jan Kiszka
>
> Straightforward for all of them, no more leaks afterwards.
>
> CC: Jingoo Han
For drivers/pci/dwc/pcie-designware-host.c,
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> CC: Joao Pinto
> CC: Lorenzo Pieralisi
> Signed-off-by: Jan Kiszka
> ---
> drivers/pci/dwc/pcie-designware-host.c | 2 +-
> drivers/pci/host/pci-aardvark.c| 5 ++---
> drivers/pci/host/pci-ftpci100.c| 4 ++--
> drivers/pci/host/pci-v3-semi.c | 3 ++-
> drivers/pci/host/pci-versatile.c | 3 +--
> drivers/pci/host/pci-xgene.c | 3 ++-
> drivers/pci/host/pcie-altera.c | 5 ++---
> drivers/pci/host/pcie-iproc-platform.c | 4 ++--
> drivers/pci/host/pcie-rcar.c | 5 ++---
> drivers/pci/host/pcie-rockchip.c | 4 ++--
> drivers/pci/host/pcie-xilinx-nwl.c | 4 ++--
> drivers/pci/host/pcie-xilinx.c | 4 ++--
> drivers/pci/of.c | 4 ++--
> 13 files changed, 24 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/pci/dwc/pcie-designware-host.c
> b/drivers/pci/dwc/pcie-designware-host.c
> index 6c409079d514..a8f6ab54b4c0 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -342,7 +342,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
> if (!bridge)
> return -ENOMEM;
>
> - ret = of_pci_get_host_bridge_resources(np, 0, 0xff,
> + ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> >windows, >io_base);
> if (ret)
> return ret;
> diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-
> aardvark.c
> index b04d37b3c5de..709f0d69e35b 100644
> --- a/drivers/pci/host/pci-aardvark.c
> +++ b/drivers/pci/host/pci-aardvark.c
> @@ -815,14 +815,13 @@ static int
> advk_pcie_parse_request_of_pci_ranges(struct advk_pcie *pcie)
> {
> int err, res_valid = 0;
> struct device *dev = >pdev->dev;
> - struct device_node *np = dev->of_node;
> struct resource_entry *win, *tmp;
> resource_size_t iobase;
>
> INIT_LIST_HEAD(>resources);
>
> - err = of_pci_get_host_bridge_resources(np, 0, 0xff,
> >resources,
> -);
> + err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> + >resources,
);
> if (err)
> return err;
>
> diff --git a/drivers/pci/host/pci-ftpci100.c b/drivers/pci/host/pci-
> ftpci100.c
> index 5008fd87956a..87748eaeaaed 100644
> --- a/drivers/pci/host/pci-ftpci100.c
> +++ b/drivers/pci/host/pci-ftpci100.c
> @@ -476,8 +476,8 @@ static int faraday_pci_probe(struct platform_device
> *pdev)
> if (IS_ERR(p->base))
> return PTR_ERR(p->base);
>
> - ret = of_pci_get_host_bridge_resources(dev->of_node, 0, 0xff,
> -, _base);
> + ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> + , _base);
> if (ret)
> return ret;
>
> diff --git a/drivers/pci/host/pci-v3-semi.c b/drivers/pci/host/pci-v3-
> semi.c
> index 0a4dea796663..167bf6f6b378 100644
> --- a/drivers/pci/host/pci-v3-semi.c
> +++ b/drivers/pci/host/pci-v3-semi.c
> @@ -791,7 +791,8 @@ static int v3_pci_probe(struct platform_device *pdev)
> if (IS_ERR(v3->config_base))
> return PTR_ERR(v3->config_base);
>
> - ret = of_pci_get_host_bridge_resources(np, 0, 0xff, , _base);
> + ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, ,
> + _base);
> if (ret)
> return ret;
>
> diff --git a/drivers/pci/host/pci-versatile.c b/drivers/pci/host/pci-
> versatile.c
> index 5b3876f5312b..ff2cd12b3978 100644
> --- a/drivers/pci/host/pci-versatile.c
> +++ b/drivers/pci/host/pci-versatile.c
> @@ -64,11 +64,10 @@ static int
> versatile_pci_parse_request_of_pci_ranges(struct device *dev,
>struct list_head *res)
> {
> int err, mem = 1, res_valid = 0;
> - struct device_node *np = dev->of_node;
> resource_size_t iobas
Re: [PATCH 6/6] MAINTAINERS: add dri-devel for backlight subsystem patches
On Wednesday, April 25, 2018 1:43 PM, Daniel Vetter wrote: > > For the same reasons we've added dri-devel for all fbdev patches: Most > of the actively developed drivers using this infrastructure are in > drivers/gpu/. It just makes sense to cross-post patches and keep > aligned. And total activity in the backlight subsystem is miniscule > compared to drm overall. > > Cc: Lee Jones <lee.jo...@linaro.org> > Cc: Daniel Thompson <daniel.thomp...@linaro.org> > Cc: Jingoo Han <jingooh...@gmail.com> > Acked-by: Daniel Thompson <daniel.thomp...@linaro.org> > Acked-by: Jingoo Han <jingooh...@gmail.com> > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> Acked-by: Jingoo Han <jingooh...@gmail.com> Best regards, Jingoo Han > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index fa72c117bcd5..0f902399a348 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2589,6 +2589,7 @@ BACKLIGHT CLASS/SUBSYSTEM > M: Lee Jones <lee.jo...@linaro.org> > M: Daniel Thompson <daniel.thomp...@linaro.org> > M: Jingoo Han <jingooh...@gmail.com> > +L: dri-de...@lists.freedesktop.org > T: git git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git > S: Maintained > F: drivers/video/backlight/ > -- > 2.17.0
Re: [PATCH 6/6] MAINTAINERS: add dri-devel for backlight subsystem patches
On Wednesday, April 25, 2018 1:43 PM, Daniel Vetter wrote: > > For the same reasons we've added dri-devel for all fbdev patches: Most > of the actively developed drivers using this infrastructure are in > drivers/gpu/. It just makes sense to cross-post patches and keep > aligned. And total activity in the backlight subsystem is miniscule > compared to drm overall. > > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han > Acked-by: Daniel Thompson > Acked-by: Jingoo Han > Signed-off-by: Daniel Vetter Acked-by: Jingoo Han Best regards, Jingoo Han > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index fa72c117bcd5..0f902399a348 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2589,6 +2589,7 @@ BACKLIGHT CLASS/SUBSYSTEM > M: Lee Jones > M: Daniel Thompson > M: Jingoo Han > +L: dri-de...@lists.freedesktop.org > T: git git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git > S: Maintained > F: drivers/video/backlight/ > -- > 2.17.0
Re: [PATCH 1/6] backlight: Nuke unused backlight.props.state states
On Wednesday, April 25, 2018 1:43 PM, Daniel Vetter wrote:
>
> The backlight power state handling is supremely confusing. We have:
> - props.power, using FB_BLANK_* defines
> - props.fb_blank, using the same, but deprecated int favour of
> props.state
> - props.state, using the BL_CORE_* defines
> - and finally a bunch of backlight drivers treat brightness == 0 as
> off. But of course not all of them.
>
> This is way too much confusion to fix in a simple patch, but at least
> prevent more hilarity from spreading by removing the unused BL_CORE_*
> defines. I have no idea why exactly anyone would need that.
>
> Wrt the ideal state, we really just want a boolean state. The 4 power
> saving states that the fbdev subsystem uses are overkill in todays hw
> (this was only relevant for VGA and similar analog circuits like
> TV-out), the new drm atomic modeset api simplified even the uapi to a
> simple bool. And there was never a valid technical reason to have the
> intermediate fbdev power states for backlights (those really only can
> be either off or on).
>
> Cleanup motivated by Meghana's questions about all this.
>
> Cc: Lee Jones <lee.jo...@linaro.org>
> Cc: Daniel Thompson <daniel.thomp...@linaro.org>
> Cc: Jingoo Han <jingooh...@gmail.com>
> Cc: Meghana Madhyastha <meghana.madhyas...@gmail.com>
> Acked-by: Daniel Thompson <daniel.thomp...@linaro.org>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
Acked-by: Jingoo Han <jingooh...@gmail.com>
I really love this patch!
Good job!
Thank you.
Best regards,
Jingoo Han
> ---
> include/linux/backlight.h | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 2baab6f3861d..1db67662bfcb 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -84,9 +84,6 @@ struct backlight_properties {
>
> #define BL_CORE_SUSPENDED(1 << 0)/* backlight is suspended */
> #define BL_CORE_FBBLANK (1 << 1)/* backlight is
under an fb
> blank event */
> -#define BL_CORE_DRIVER4 (1 << 28) /* reserved for
driver
> specific use */
> -#define BL_CORE_DRIVER3 (1 << 29) /* reserved for
driver
> specific use */
> -#define BL_CORE_DRIVER2 (1 << 30) /* reserved for
driver
> specific use */
> #define BL_CORE_DRIVER1 (1 << 31) /* reserved for
driver
> specific use */
>
> };
> --
> 2.17.0
Re: [PATCH 1/6] backlight: Nuke unused backlight.props.state states
On Wednesday, April 25, 2018 1:43 PM, Daniel Vetter wrote:
>
> The backlight power state handling is supremely confusing. We have:
> - props.power, using FB_BLANK_* defines
> - props.fb_blank, using the same, but deprecated int favour of
> props.state
> - props.state, using the BL_CORE_* defines
> - and finally a bunch of backlight drivers treat brightness == 0 as
> off. But of course not all of them.
>
> This is way too much confusion to fix in a simple patch, but at least
> prevent more hilarity from spreading by removing the unused BL_CORE_*
> defines. I have no idea why exactly anyone would need that.
>
> Wrt the ideal state, we really just want a boolean state. The 4 power
> saving states that the fbdev subsystem uses are overkill in todays hw
> (this was only relevant for VGA and similar analog circuits like
> TV-out), the new drm atomic modeset api simplified even the uapi to a
> simple bool. And there was never a valid technical reason to have the
> intermediate fbdev power states for backlights (those really only can
> be either off or on).
>
> Cleanup motivated by Meghana's questions about all this.
>
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> Cc: Meghana Madhyastha
> Acked-by: Daniel Thompson
> Signed-off-by: Daniel Vetter
Acked-by: Jingoo Han
I really love this patch!
Good job!
Thank you.
Best regards,
Jingoo Han
> ---
> include/linux/backlight.h | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 2baab6f3861d..1db67662bfcb 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -84,9 +84,6 @@ struct backlight_properties {
>
> #define BL_CORE_SUSPENDED(1 << 0)/* backlight is suspended */
> #define BL_CORE_FBBLANK (1 << 1)/* backlight is
under an fb
> blank event */
> -#define BL_CORE_DRIVER4 (1 << 28) /* reserved for
driver
> specific use */
> -#define BL_CORE_DRIVER3 (1 << 29) /* reserved for
driver
> specific use */
> -#define BL_CORE_DRIVER2 (1 << 30) /* reserved for
driver
> specific use */
> #define BL_CORE_DRIVER1 (1 << 31) /* reserved for
driver
> specific use */
>
> };
> --
> 2.17.0
Re: [PATCH v7 6/9] PCI: dwc: Define maximum number of vectors
On Tuesday, April 24, 2018 9:45 AM, Gustavo Pimentel wrote:
>
> Adds a callback that defines the maximum number of vectors that can be use
> by the Root Complex.
>
> Since this is a parameter associated to each SoC IP setting, makes sense
> to
> be configurable and easily visible to future modifications.
>
> The designware IP supports a maximum of 256 vectors.
>
> Signed-off-by: Gustavo Pimentel <gustavo.pimen...@synopsys.com>
> Acked-by: Joao Pinto <jpi...@synopsys.com>
Acked-by: Jingoo Han <jingooh...@gmail.com>
Best regards,
Jingoo Han
> ---
> Change v1->v2:
> - Nothing changed, just to follow the patch set version.
> Change v2->v3:
> - Nothing changed, just to follow the patch set version.
> Changes v3->v4:
> - Nothing changed, just to follow the patch set version.
> Changes v4->v5:
> - Nothing changed, just to follow the patch set version.
> Changes v5->v6:
> - Nothing changed, just to follow the patch set version.
> Changes v6->v7:
> - Nothing changed, just to follow the patch set version.
>
> drivers/pci/dwc/pcie-designware-plat.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/pci/dwc/pcie-designware-plat.c
> b/drivers/pci/dwc/pcie-designware-plat.c
> index efc315c..5937fed 100644
> --- a/drivers/pci/dwc/pcie-designware-plat.c
> +++ b/drivers/pci/dwc/pcie-designware-plat.c
> @@ -48,8 +48,14 @@ static int dw_plat_pcie_host_init(struct pcie_port *pp)
> return 0;
> }
>
> +static void dw_plat_set_num_vectors(struct pcie_port *pp)
> +{
> + pp->num_vectors = MAX_MSI_IRQS;
> +}
> +
> static const struct dw_pcie_host_ops dw_plat_pcie_host_ops = {
> .host_init = dw_plat_pcie_host_init,
> + .set_num_vectors = dw_plat_set_num_vectors,
> };
>
> static int dw_plat_pcie_establish_link(struct dw_pcie *pci)
> --
> 2.7.4
>
Re: [PATCH v7 6/9] PCI: dwc: Define maximum number of vectors
On Tuesday, April 24, 2018 9:45 AM, Gustavo Pimentel wrote:
>
> Adds a callback that defines the maximum number of vectors that can be use
> by the Root Complex.
>
> Since this is a parameter associated to each SoC IP setting, makes sense
> to
> be configurable and easily visible to future modifications.
>
> The designware IP supports a maximum of 256 vectors.
>
> Signed-off-by: Gustavo Pimentel
> Acked-by: Joao Pinto
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> Change v1->v2:
> - Nothing changed, just to follow the patch set version.
> Change v2->v3:
> - Nothing changed, just to follow the patch set version.
> Changes v3->v4:
> - Nothing changed, just to follow the patch set version.
> Changes v4->v5:
> - Nothing changed, just to follow the patch set version.
> Changes v5->v6:
> - Nothing changed, just to follow the patch set version.
> Changes v6->v7:
> - Nothing changed, just to follow the patch set version.
>
> drivers/pci/dwc/pcie-designware-plat.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/pci/dwc/pcie-designware-plat.c
> b/drivers/pci/dwc/pcie-designware-plat.c
> index efc315c..5937fed 100644
> --- a/drivers/pci/dwc/pcie-designware-plat.c
> +++ b/drivers/pci/dwc/pcie-designware-plat.c
> @@ -48,8 +48,14 @@ static int dw_plat_pcie_host_init(struct pcie_port *pp)
> return 0;
> }
>
> +static void dw_plat_set_num_vectors(struct pcie_port *pp)
> +{
> + pp->num_vectors = MAX_MSI_IRQS;
> +}
> +
> static const struct dw_pcie_host_ops dw_plat_pcie_host_ops = {
> .host_init = dw_plat_pcie_host_init,
> + .set_num_vectors = dw_plat_set_num_vectors,
> };
>
> static int dw_plat_pcie_establish_link(struct dw_pcie *pci)
> --
> 2.7.4
>
Re: [RESEND PATCH v6 22/27] drm/bridge: analogix_dp: Split the platform-specific poweron in two parts
On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote:
>
> From: Douglas Anderson <diand...@chromium.org>
>
> Some of the platform-specific stuff in rockchip_dp_poweron() needs to
> happen before the generic code. Some needs to happen after. Let's
> split the callback in two.
>
> Specifically we can't start doing PSR work until _after_ the whole
> controller is up, so don't set the enable until the end.
>
> Cc: Kristian H. Kristensen <hoegsb...@chromium.org>
> Signed-off-by: Douglas Anderson <diand...@chromium.org>
> [seanpaul added exynos change]
> Signed-off-by: Sean Paul <seanp...@chromium.org>
> Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
> Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
> Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
> Reviewed-by: Archit Taneja <arch...@codeaurora.org>
Acked-by: Jingoo Han <jingooh...@gmail.com>
Best regards,
Jingoo Han
> ---
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 7 +--
> drivers/gpu/drm/exynos/exynos_dp.c | 2 +-
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 12 ++--
> include/drm/bridge/analogix_dp.h | 3 ++-
> 4 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index a260de4f0bd8..2bcbfadb6ac5 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1260,8 +1260,8 @@ static int analogix_dp_set_bridge(struct
> analogix_dp_device *dp)
> goto out_dp_clk_pre;
> }
>
> - if (dp->plat_data->power_on)
> - dp->plat_data->power_on(dp->plat_data);
> + if (dp->plat_data->power_on_start)
> + dp->plat_data->power_on_start(dp->plat_data);
>
> phy_power_on(dp->phy);
>
> @@ -1286,6 +1286,9 @@ static int analogix_dp_set_bridge(struct
> analogix_dp_device *dp)
> goto out_dp_init;
> }
>
> + if (dp->plat_data->power_on_end)
> + dp->plat_data->power_on_end(dp->plat_data);
> +
> enable_irq(dp->irq);
> return 0;
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
> b/drivers/gpu/drm/exynos/exynos_dp.c
> index 964831dab102..86330f396784 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -162,7 +162,7 @@ static int exynos_dp_bind(struct device *dev, struct
> device *master, void *data)
> dp->drm_dev = drm_dev;
>
> dp->plat_data.dev_type = EXYNOS_DP;
> - dp->plat_data.power_on = exynos_dp_poweron;
> + dp->plat_data.power_on_start = exynos_dp_poweron;
> dp->plat_data.power_off = exynos_dp_poweroff;
> dp->plat_data.attach = exynos_dp_bridge_attach;
> dp->plat_data.get_modes = exynos_dp_get_modes;
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index b3f46ed24cdc..23317a2269e1 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -109,7 +109,7 @@ static int rockchip_dp_pre_init(struct
> rockchip_dp_device *dp)
> return 0;
> }
>
> -static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
> +static int rockchip_dp_poweron_start(struct analogix_dp_plat_data
> *plat_data)
> {
> struct rockchip_dp_device *dp = to_dp(plat_data);
> int ret;
> @@ -127,6 +127,13 @@ static int rockchip_dp_poweron(struct
> analogix_dp_plat_data *plat_data)
> return ret;
> }
>
> + return ret;
> +}
> +
> +static int rockchip_dp_poweron_end(struct analogix_dp_plat_data
> *plat_data)
> +{
> + struct rockchip_dp_device *dp = to_dp(plat_data);
> +
> return rockchip_drm_psr_activate(>encoder);
> }
>
> @@ -330,7 +337,8 @@ static int rockchip_dp_bind(struct device *dev, struct
> device *master,
> dp->plat_data.encoder = >encoder;
>
> dp->plat_data.dev_type = dp->data->chip_type;
> - dp->plat_data.power_on = rockchip_dp_poweron;
> + dp->plat_data.power_on_start = rockchip_dp_poweron_start;
> + dp->plat_data.power_on_end = rockchip_dp_poweron_end;
> dp->plat_data.power_off = rockchip_dp_powerdown;
> dp->plat_data.get_modes = rockchip_dp_get_modes;
>
> diff --git a/include/drm/bridge/anal
Re: [RESEND PATCH v6 22/27] drm/bridge: analogix_dp: Split the platform-specific poweron in two parts
On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote:
>
> From: Douglas Anderson
>
> Some of the platform-specific stuff in rockchip_dp_poweron() needs to
> happen before the generic code. Some needs to happen after. Let's
> split the callback in two.
>
> Specifically we can't start doing PSR work until _after_ the whole
> controller is up, so don't set the enable until the end.
>
> Cc: Kristian H. Kristensen
> Signed-off-by: Douglas Anderson
> [seanpaul added exynos change]
> Signed-off-by: Sean Paul
> Signed-off-by: Thierry Escande
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Enric Balletbo i Serra
> Tested-by: Marek Szyprowski
> Reviewed-by: Archit Taneja
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 7 +--
> drivers/gpu/drm/exynos/exynos_dp.c | 2 +-
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 12 ++--
> include/drm/bridge/analogix_dp.h | 3 ++-
> 4 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index a260de4f0bd8..2bcbfadb6ac5 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1260,8 +1260,8 @@ static int analogix_dp_set_bridge(struct
> analogix_dp_device *dp)
> goto out_dp_clk_pre;
> }
>
> - if (dp->plat_data->power_on)
> - dp->plat_data->power_on(dp->plat_data);
> + if (dp->plat_data->power_on_start)
> + dp->plat_data->power_on_start(dp->plat_data);
>
> phy_power_on(dp->phy);
>
> @@ -1286,6 +1286,9 @@ static int analogix_dp_set_bridge(struct
> analogix_dp_device *dp)
> goto out_dp_init;
> }
>
> + if (dp->plat_data->power_on_end)
> + dp->plat_data->power_on_end(dp->plat_data);
> +
> enable_irq(dp->irq);
> return 0;
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
> b/drivers/gpu/drm/exynos/exynos_dp.c
> index 964831dab102..86330f396784 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -162,7 +162,7 @@ static int exynos_dp_bind(struct device *dev, struct
> device *master, void *data)
> dp->drm_dev = drm_dev;
>
> dp->plat_data.dev_type = EXYNOS_DP;
> - dp->plat_data.power_on = exynos_dp_poweron;
> + dp->plat_data.power_on_start = exynos_dp_poweron;
> dp->plat_data.power_off = exynos_dp_poweroff;
> dp->plat_data.attach = exynos_dp_bridge_attach;
> dp->plat_data.get_modes = exynos_dp_get_modes;
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index b3f46ed24cdc..23317a2269e1 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -109,7 +109,7 @@ static int rockchip_dp_pre_init(struct
> rockchip_dp_device *dp)
> return 0;
> }
>
> -static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
> +static int rockchip_dp_poweron_start(struct analogix_dp_plat_data
> *plat_data)
> {
> struct rockchip_dp_device *dp = to_dp(plat_data);
> int ret;
> @@ -127,6 +127,13 @@ static int rockchip_dp_poweron(struct
> analogix_dp_plat_data *plat_data)
> return ret;
> }
>
> + return ret;
> +}
> +
> +static int rockchip_dp_poweron_end(struct analogix_dp_plat_data
> *plat_data)
> +{
> + struct rockchip_dp_device *dp = to_dp(plat_data);
> +
> return rockchip_drm_psr_activate(>encoder);
> }
>
> @@ -330,7 +337,8 @@ static int rockchip_dp_bind(struct device *dev, struct
> device *master,
> dp->plat_data.encoder = >encoder;
>
> dp->plat_data.dev_type = dp->data->chip_type;
> - dp->plat_data.power_on = rockchip_dp_poweron;
> + dp->plat_data.power_on_start = rockchip_dp_poweron_start;
> + dp->plat_data.power_on_end = rockchip_dp_poweron_end;
> dp->plat_data.power_off = rockchip_dp_powerdown;
> dp->plat_data.get_modes = rockchip_dp_get_modes;
>
> diff --git a/include/drm/bridge/analogix_dp.h
> b/include/drm/bridge/analogix_dp.h
> index e9a1116d2f8e..475b706b49de 100644
> --- a/include/drm/bridge/analogix_dp.h
> +++ b/include/drm/bridge/analogix_dp.h
> @@ -33,7 +33,8 @@ struct analogix_dp_plat_data {
> struct drm_connector *connector;
> bool skip_connector;
>
> - int (*power_on)(struct analogix_dp_plat_data *);
> + int (*power_on_start)(struct analogix_dp_plat_data *);
> + int (*power_on_end)(struct analogix_dp_plat_data *);
> int (*power_off)(struct analogix_dp_plat_data *);
> int (*attach)(struct analogix_dp_plat_data *, struct drm_bridge *,
> struct drm_connector *);
> --
> 2.17.0
Re: [RESEND PATCH v6 13/27] drm/rockchip: Restore psr->state when enable/disable psr failed
On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote:
>
> From: zain wang <w...@rock-chips.com>
>
> If we failed disable psr, it would hang the display until next psr
> cycle coming. So we should restore psr->state when it failed.
>
> Cc: Tomasz Figa <tf...@chromium.org>
> Signed-off-by: zain wang <w...@rock-chips.com>
> Signed-off-by: Douglas Anderson <diand...@chromium.org>
> Signed-off-by: Sean Paul <seanp...@chromium.org>
> Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
> Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
> Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
> Reviewed-by: Heiko Stuebner <he...@sntech.de>
> Reviewed-by: Archit Taneja <arch...@codeaurora.org>
Acked-by: Jingoo Han <jingooh...@gmail.com>
Best regards,
Jingoo Han
> ---
>
> .../drm/bridge/analogix/analogix_dp_core.c| 4 +++-
> .../gpu/drm/rockchip/analogix_dp-rockchip.c | 10 +-
> drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 20 ---
> drivers/gpu/drm/rockchip/rockchip_drm_psr.h | 2 +-
> 4 files changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 75e61ebf6722..5540e2dfc2ec 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -153,8 +153,10 @@ int analogix_dp_disable_psr(struct analogix_dp_device
> *dp)
> psr_vsc.DB1 = 0;
>
> ret = drm_dp_dpcd_writeb(>aux, DP_SET_POWER, DP_SET_POWER_D0);
> - if (ret != 1)
> + if (ret != 1) {
> dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
> + return ret;
> + }
>
> return analogix_dp_send_psr_spd(dp, _vsc, false);
> }
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 3e8bf79bea58..8c884f9ce713 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -77,13 +77,13 @@ struct rockchip_dp_device {
> struct analogix_dp_plat_data plat_data;
> };
>
> -static void analogix_dp_psr_set(struct drm_encoder *encoder, bool
enabled)
> +static int analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
> {
> struct rockchip_dp_device *dp = to_dp(encoder);
> int ret;
>
> if (!analogix_dp_psr_enabled(dp->adp))
> - return;
> + return 0;
>
> DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
>
> @@ -91,13 +91,13 @@ static void analogix_dp_psr_set(struct drm_encoder
> *encoder, bool enabled)
>PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
> if (ret) {
> DRM_DEV_ERROR(dp->dev, "line flag interrupt did not
> arrive\n");
> - return;
> + return -ETIMEDOUT;
> }
>
> if (enabled)
> - analogix_dp_enable_psr(dp->adp);
> + return analogix_dp_enable_psr(dp->adp);
> else
> - analogix_dp_disable_psr(dp->adp);
> + return analogix_dp_disable_psr(dp->adp);
> }
>
> static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> index b339ca943139..9376f4396b6b 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> @@ -36,7 +36,7 @@ struct psr_drv {
>
> struct delayed_work flush_work;
>
> - void (*set)(struct drm_encoder *encoder, bool enable);
> + int (*set)(struct drm_encoder *encoder, bool enable);
> };
>
> static struct psr_drv *find_psr_by_crtc(struct drm_crtc *crtc)
> @@ -93,19 +93,25 @@ static void psr_set_state_locked(struct psr_drv *psr,
> enum psr_state state)
> return;
> }
>
> - psr->state = state;
> -
> /* Actually commit the state change to hardware */
> - switch (psr->state) {
> + switch (state) {
> case PSR_ENABLE:
> - psr->set(psr->encoder, true);
> + if (psr->set(psr->encoder, true))
> + return;
> break;
>
> case PSR_DISABLE:
> case PSR_FLUSH:
> - psr->set(psr->encoder, false);
> + if (psr->set(psr->encoder, false))
> + return;
> b
Re: [RESEND PATCH v6 13/27] drm/rockchip: Restore psr->state when enable/disable psr failed
On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote:
>
> From: zain wang
>
> If we failed disable psr, it would hang the display until next psr
> cycle coming. So we should restore psr->state when it failed.
>
> Cc: Tomasz Figa
> Signed-off-by: zain wang
> Signed-off-by: Douglas Anderson
> Signed-off-by: Sean Paul
> Signed-off-by: Thierry Escande
> Signed-off-by: Enric Balletbo i Serra
> Tested-by: Marek Szyprowski
> Reviewed-by: Heiko Stuebner
> Reviewed-by: Archit Taneja
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
>
> .../drm/bridge/analogix/analogix_dp_core.c| 4 +++-
> .../gpu/drm/rockchip/analogix_dp-rockchip.c | 10 +-
> drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 20 ---
> drivers/gpu/drm/rockchip/rockchip_drm_psr.h | 2 +-
> 4 files changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 75e61ebf6722..5540e2dfc2ec 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -153,8 +153,10 @@ int analogix_dp_disable_psr(struct analogix_dp_device
> *dp)
> psr_vsc.DB1 = 0;
>
> ret = drm_dp_dpcd_writeb(>aux, DP_SET_POWER, DP_SET_POWER_D0);
> - if (ret != 1)
> + if (ret != 1) {
> dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
> + return ret;
> + }
>
> return analogix_dp_send_psr_spd(dp, _vsc, false);
> }
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 3e8bf79bea58..8c884f9ce713 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -77,13 +77,13 @@ struct rockchip_dp_device {
> struct analogix_dp_plat_data plat_data;
> };
>
> -static void analogix_dp_psr_set(struct drm_encoder *encoder, bool
enabled)
> +static int analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
> {
> struct rockchip_dp_device *dp = to_dp(encoder);
> int ret;
>
> if (!analogix_dp_psr_enabled(dp->adp))
> - return;
> + return 0;
>
> DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
>
> @@ -91,13 +91,13 @@ static void analogix_dp_psr_set(struct drm_encoder
> *encoder, bool enabled)
>PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
> if (ret) {
> DRM_DEV_ERROR(dp->dev, "line flag interrupt did not
> arrive\n");
> - return;
> + return -ETIMEDOUT;
> }
>
> if (enabled)
> - analogix_dp_enable_psr(dp->adp);
> + return analogix_dp_enable_psr(dp->adp);
> else
> - analogix_dp_disable_psr(dp->adp);
> + return analogix_dp_disable_psr(dp->adp);
> }
>
> static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> index b339ca943139..9376f4396b6b 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> @@ -36,7 +36,7 @@ struct psr_drv {
>
> struct delayed_work flush_work;
>
> - void (*set)(struct drm_encoder *encoder, bool enable);
> + int (*set)(struct drm_encoder *encoder, bool enable);
> };
>
> static struct psr_drv *find_psr_by_crtc(struct drm_crtc *crtc)
> @@ -93,19 +93,25 @@ static void psr_set_state_locked(struct psr_drv *psr,
> enum psr_state state)
> return;
> }
>
> - psr->state = state;
> -
> /* Actually commit the state change to hardware */
> - switch (psr->state) {
> + switch (state) {
> case PSR_ENABLE:
> - psr->set(psr->encoder, true);
> + if (psr->set(psr->encoder, true))
> + return;
> break;
>
> case PSR_DISABLE:
> case PSR_FLUSH:
> - psr->set(psr->encoder, false);
> + if (psr->set(psr->encoder, false))
> + return;
> break;
> +
> + default:
> + pr_err("%s: Unknown state %d\n", __func__, state);
> + return;
> }
> +
> + psr->state = state;
> }
>
> static void psr_set_state(struct psr_drv *psr, enum psr_state state)
> @@ -229,7 +235,7 @@ E
Re: [RESEND PATCH v6 11/27] drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip
On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote:
>
> From: zain wang <w...@rock-chips.com>
>
> There are some different bits between Rockchip and Exynos in register
> "AUX_PD". This patch fixes the incorrect operations about it.
>
> Cc: Douglas Anderson <diand...@chromium.org>
> Signed-off-by: zain wang <w...@rock-chips.com>
> Signed-off-by: Sean Paul <seanp...@chromium.org>
> Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
> Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
> Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
> Reviewed-by: Archit Taneja <arch...@codeaurora.org>
Acked-by: Jingoo Han <jingooh...@gmail.com>
Best regards,
Jingoo Han
> ---
>
> .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 117 ++
> .../gpu/drm/bridge/analogix/analogix_dp_reg.h | 2 +
> 2 files changed, 65 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index bb72f8b0e603..dee1ba109b5f 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -248,76 +248,85 @@ void analogix_dp_set_analog_power_down(struct
> analogix_dp_device *dp,
> {
> u32 reg;
> u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
> + u32 mask;
>
> if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
> phy_pd_addr = ANALOGIX_DP_PD;
>
> switch (block) {
> case AUX_BLOCK:
> - if (enable) {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg |= AUX_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - } else {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg &= ~AUX_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - }
> + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
> + mask = RK_AUX_PD;
> + else
> + mask = AUX_PD;
> +
> + reg = readl(dp->reg_base + phy_pd_addr);
> + if (enable)
> + reg |= mask;
> + else
> + reg &= ~mask;
> + writel(reg, dp->reg_base + phy_pd_addr);
> break;
> case CH0_BLOCK:
> - if (enable) {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg |= CH0_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - } else {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg &= ~CH0_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - }
> + mask = CH0_PD;
> + reg = readl(dp->reg_base + phy_pd_addr);
> +
> + if (enable)
> + reg |= mask;
> + else
> + reg &= ~mask;
> + writel(reg, dp->reg_base + phy_pd_addr);
> break;
> case CH1_BLOCK:
> - if (enable) {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg |= CH1_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - } else {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg &= ~CH1_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - }
> + mask = CH1_PD;
> + reg = readl(dp->reg_base + phy_pd_addr);
> +
> + if (enable)
> + reg |= mask;
> + else
> + reg &= ~mask;
> + writel(reg, dp->reg_base + phy_pd_addr);
> break;
> case CH2_BLOCK:
> - if (enable) {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg |= CH2_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - } else {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg &= ~CH2_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - }
> + mask = CH2_PD;
> + reg = readl(dp->reg_base + phy_pd_addr);
> +
> + if (enab
Re: [RESEND PATCH v6 11/27] drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip
On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote:
>
> From: zain wang
>
> There are some different bits between Rockchip and Exynos in register
> "AUX_PD". This patch fixes the incorrect operations about it.
>
> Cc: Douglas Anderson
> Signed-off-by: zain wang
> Signed-off-by: Sean Paul
> Signed-off-by: Thierry Escande
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Enric Balletbo i Serra
> Tested-by: Marek Szyprowski
> Reviewed-by: Archit Taneja
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
>
> .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 117 ++
> .../gpu/drm/bridge/analogix/analogix_dp_reg.h | 2 +
> 2 files changed, 65 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index bb72f8b0e603..dee1ba109b5f 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -248,76 +248,85 @@ void analogix_dp_set_analog_power_down(struct
> analogix_dp_device *dp,
> {
> u32 reg;
> u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
> + u32 mask;
>
> if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
> phy_pd_addr = ANALOGIX_DP_PD;
>
> switch (block) {
> case AUX_BLOCK:
> - if (enable) {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg |= AUX_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - } else {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg &= ~AUX_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - }
> + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
> + mask = RK_AUX_PD;
> + else
> + mask = AUX_PD;
> +
> + reg = readl(dp->reg_base + phy_pd_addr);
> + if (enable)
> + reg |= mask;
> + else
> + reg &= ~mask;
> + writel(reg, dp->reg_base + phy_pd_addr);
> break;
> case CH0_BLOCK:
> - if (enable) {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg |= CH0_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - } else {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg &= ~CH0_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - }
> + mask = CH0_PD;
> + reg = readl(dp->reg_base + phy_pd_addr);
> +
> + if (enable)
> + reg |= mask;
> + else
> + reg &= ~mask;
> + writel(reg, dp->reg_base + phy_pd_addr);
> break;
> case CH1_BLOCK:
> - if (enable) {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg |= CH1_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - } else {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg &= ~CH1_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - }
> + mask = CH1_PD;
> + reg = readl(dp->reg_base + phy_pd_addr);
> +
> + if (enable)
> + reg |= mask;
> + else
> + reg &= ~mask;
> + writel(reg, dp->reg_base + phy_pd_addr);
> break;
> case CH2_BLOCK:
> - if (enable) {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg |= CH2_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - } else {
> - reg = readl(dp->reg_base + phy_pd_addr);
> - reg &= ~CH2_PD;
> - writel(reg, dp->reg_base + phy_pd_addr);
> - }
> + mask = CH2_PD;
> + reg = readl(dp->reg_base + phy_pd_addr);
> +
> + if (enable)
> + reg |= mask;
> + else
> + reg &= ~mask;
> + writel(reg, dp->reg_base + phy_pd_addr);
> break;
> case CH3_BLOCK:
> - if (enable) {
> - reg = readl
Re: [RESEND PATCH v6 10/27] drm/bridge: analogix_dp: Check dpcd write/read status
On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote:
>
> From: Lin Huang <h...@rock-chips.com>
>
> We need to check the dpcd write/read return value to see whether the
> write/read was successful
>
> Cc: Kristian H. Kristensen <hoegsb...@chromium.org>
> Signed-off-by: Lin Huang <h...@rock-chips.com>
> Signed-off-by: zain wang <w...@rock-chips.com>
> Signed-off-by: Douglas Anderson <diand...@chromium.org>
> Signed-off-by: Sean Paul <seanp...@chromium.org>
> Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
> Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
> Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
> Reviewed-by: Archit Taneja <arch...@codeaurora.org>
Acked-by: Jingoo Han <jingooh...@gmail.com>
Best regards,
Jingoo Han
> ---
>
> .../drm/bridge/analogix/analogix_dp_core.c| 169 +-
> 1 file changed, 127 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 1e1743b59c77..75e61ebf6722 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -160,80 +160,137 @@ int analogix_dp_disable_psr(struct
> analogix_dp_device *dp)
> }
> EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
>
> -static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
> +static int analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
> {
> unsigned char psr_version;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(>aux, DP_PSR_SUPPORT, _version);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to get PSR version, disable it\n");
> + return ret;
> + }
>
> - drm_dp_dpcd_readb(>aux, DP_PSR_SUPPORT, _version);
> dev_dbg(dp->dev, "Panel PSR version : %x\n", psr_version);
>
> - return (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
> + dp->psr_enable = (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
> +
> + return 0;
> }
>
> -static void analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
> +static int analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
> {
> unsigned char psr_en;
> + int ret;
>
> /* Disable psr function */
> - drm_dp_dpcd_readb(>aux, DP_PSR_EN_CFG, _en);
> + ret = drm_dp_dpcd_readb(>aux, DP_PSR_EN_CFG, _en);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to get psr config\n");
> + goto end;
> + }
> +
> psr_en &= ~DP_PSR_ENABLE;
> - drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to disable panel psr\n");
> + goto end;
> + }
>
> /* Main-Link transmitter remains active during PSR active states */
> psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
> - drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to set panel psr\n");
> + goto end;
> + }
>
> /* Enable psr function */
> psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
>DP_PSR_CRC_VERIFICATION;
> - drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to set panel psr\n");
> + goto end;
> + }
>
> analogix_dp_enable_psr_crc(dp);
> +
> + return 0;
> +end:
> + dev_err(dp->dev, "enable psr fail, force to disable psr\n");
> + dp->psr_enable = false;
> +
> + return ret;
> }
>
> -static void
> +static int
> analogix_dp_enable_rx_to_enhanced_mode(struct analogix_dp_device *dp,
> bool enable)
> {
> u8 data;
> + int ret;
>
> - drm_dp_dpcd_readb(>aux, DP_LANE_COUNT_SET, );
> + ret = drm_dp_dpcd_readb(>aux, DP_LANE_COUNT_SET, );
> + if (ret != 1)
> + return ret;
>
> if (enable)
> - drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
> -DP_LANE_COUNT_ENHANCED_FRAME_EN |
> -
Re: [RESEND PATCH v6 10/27] drm/bridge: analogix_dp: Check dpcd write/read status
On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote:
>
> From: Lin Huang
>
> We need to check the dpcd write/read return value to see whether the
> write/read was successful
>
> Cc: Kristian H. Kristensen
> Signed-off-by: Lin Huang
> Signed-off-by: zain wang
> Signed-off-by: Douglas Anderson
> Signed-off-by: Sean Paul
> Signed-off-by: Thierry Escande
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Enric Balletbo i Serra
> Tested-by: Marek Szyprowski
> Reviewed-by: Archit Taneja
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
>
> .../drm/bridge/analogix/analogix_dp_core.c| 169 +-
> 1 file changed, 127 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 1e1743b59c77..75e61ebf6722 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -160,80 +160,137 @@ int analogix_dp_disable_psr(struct
> analogix_dp_device *dp)
> }
> EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
>
> -static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
> +static int analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
> {
> unsigned char psr_version;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(>aux, DP_PSR_SUPPORT, _version);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to get PSR version, disable it\n");
> + return ret;
> + }
>
> - drm_dp_dpcd_readb(>aux, DP_PSR_SUPPORT, _version);
> dev_dbg(dp->dev, "Panel PSR version : %x\n", psr_version);
>
> - return (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
> + dp->psr_enable = (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
> +
> + return 0;
> }
>
> -static void analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
> +static int analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
> {
> unsigned char psr_en;
> + int ret;
>
> /* Disable psr function */
> - drm_dp_dpcd_readb(>aux, DP_PSR_EN_CFG, _en);
> + ret = drm_dp_dpcd_readb(>aux, DP_PSR_EN_CFG, _en);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to get psr config\n");
> + goto end;
> + }
> +
> psr_en &= ~DP_PSR_ENABLE;
> - drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to disable panel psr\n");
> + goto end;
> + }
>
> /* Main-Link transmitter remains active during PSR active states */
> psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
> - drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to set panel psr\n");
> + goto end;
> + }
>
> /* Enable psr function */
> psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
>DP_PSR_CRC_VERIFICATION;
> - drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
> + if (ret != 1) {
> + dev_err(dp->dev, "failed to set panel psr\n");
> + goto end;
> + }
>
> analogix_dp_enable_psr_crc(dp);
> +
> + return 0;
> +end:
> + dev_err(dp->dev, "enable psr fail, force to disable psr\n");
> + dp->psr_enable = false;
> +
> + return ret;
> }
>
> -static void
> +static int
> analogix_dp_enable_rx_to_enhanced_mode(struct analogix_dp_device *dp,
> bool enable)
> {
> u8 data;
> + int ret;
>
> - drm_dp_dpcd_readb(>aux, DP_LANE_COUNT_SET, );
> + ret = drm_dp_dpcd_readb(>aux, DP_LANE_COUNT_SET, );
> + if (ret != 1)
> + return ret;
>
> if (enable)
> - drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
> -DP_LANE_COUNT_ENHANCED_FRAME_EN |
> - DPCD_LANE_COUNT_SET(data));
> + ret = drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
> + DP_LANE_COUNT_ENHANCED_FRAME_EN |
> + DPCD_LANE_COUNT_SET(data));
> else
> - drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET,
> -
Re: [RESEND PATCH v6 16/27] drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1
On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote:
>
> From: zain wang <w...@rock-chips.com>
>
> Register ANALOGIX_DP_FUNC_EN_1(offset 0x18), Rockchip is different to
> Exynos:
>
> on Exynos edp phy,
> BIT 7 MASTER_VID_FUNC_EN_N
> BIT 6 reserved
> BIT 5 SLAVE_VID_FUNC_EN_N
>
> on Rockchip edp phy,
> BIT 7 reserved
> BIT 6 RK_VID_CAP_FUNC_EN_N
> BIT 5 RK_VID_FIFO_FUNC_EN_N
>
> So, we should do some private operations to Rockchip.
>
> Cc: Tomasz Figa <tf...@chromium.org>
> Signed-off-by: zain wang <w...@rock-chips.com>
> Signed-off-by: Sean Paul <seanp...@chromium.org>
> Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
> Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
> Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
> Reviewed-by: Archit Taneja <arch...@codeaurora.org>
Acked-by: Jingoo Han <jingooh...@gmail.com>
Best regards,
Jingoo Han
> ---
>
> .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 19 ++-
> .../gpu/drm/bridge/analogix/analogix_dp_reg.h | 2 ++
> 2 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 02ab1aaa9993..4eae206ec31b 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -126,9 +126,14 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
> analogix_dp_stop_video(dp);
> analogix_dp_enable_video_mute(dp, 0);
>
> - reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
> - AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
> - HDCP_FUNC_EN_N | SW_FUNC_EN_N;
> + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
> + reg = RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N |
> + SW_FUNC_EN_N;
> + else
> + reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
> + AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
> + HDCP_FUNC_EN_N | SW_FUNC_EN_N;
> +
> writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
>
> reg = SSC_FUNC_EN_N | AUX_FUNC_EN_N |
> @@ -971,8 +976,12 @@ void analogix_dp_config_video_slave_mode(struct
> analogix_dp_device *dp)
> u32 reg;
>
> reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
> - reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
> - reg |= MASTER_VID_FUNC_EN_N;
> + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
> + reg &= ~(RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N);
> + } else {
> + reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
> + reg |= MASTER_VID_FUNC_EN_N;
> + }
> writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
>
> reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> index b633a4a5082a..0cf27c731727 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> @@ -127,7 +127,9 @@
>
> /* ANALOGIX_DP_FUNC_EN_1 */
> #define MASTER_VID_FUNC_EN_N (0x1 << 7)
> +#define RK_VID_CAP_FUNC_EN_N (0x1 << 6)
> #define SLAVE_VID_FUNC_EN_N (0x1 << 5)
> +#define RK_VID_FIFO_FUNC_EN_N(0x1 << 5)
> #define AUD_FIFO_FUNC_EN_N (0x1 << 4)
> #define AUD_FUNC_EN_N(0x1 << 3)
> #define HDCP_FUNC_EN_N (0x1 << 2)
> --
> 2.17.0
Re: [RESEND PATCH v6 16/27] drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1
On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote:
>
> From: zain wang
>
> Register ANALOGIX_DP_FUNC_EN_1(offset 0x18), Rockchip is different to
> Exynos:
>
> on Exynos edp phy,
> BIT 7 MASTER_VID_FUNC_EN_N
> BIT 6 reserved
> BIT 5 SLAVE_VID_FUNC_EN_N
>
> on Rockchip edp phy,
> BIT 7 reserved
> BIT 6 RK_VID_CAP_FUNC_EN_N
> BIT 5 RK_VID_FIFO_FUNC_EN_N
>
> So, we should do some private operations to Rockchip.
>
> Cc: Tomasz Figa
> Signed-off-by: zain wang
> Signed-off-by: Sean Paul
> Signed-off-by: Thierry Escande
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Enric Balletbo i Serra
> Tested-by: Marek Szyprowski
> Reviewed-by: Archit Taneja
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
>
> .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 19 ++-
> .../gpu/drm/bridge/analogix/analogix_dp_reg.h | 2 ++
> 2 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 02ab1aaa9993..4eae206ec31b 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -126,9 +126,14 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
> analogix_dp_stop_video(dp);
> analogix_dp_enable_video_mute(dp, 0);
>
> - reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
> - AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
> - HDCP_FUNC_EN_N | SW_FUNC_EN_N;
> + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
> + reg = RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N |
> + SW_FUNC_EN_N;
> + else
> + reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
> + AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
> + HDCP_FUNC_EN_N | SW_FUNC_EN_N;
> +
> writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
>
> reg = SSC_FUNC_EN_N | AUX_FUNC_EN_N |
> @@ -971,8 +976,12 @@ void analogix_dp_config_video_slave_mode(struct
> analogix_dp_device *dp)
> u32 reg;
>
> reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
> - reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
> - reg |= MASTER_VID_FUNC_EN_N;
> + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
> + reg &= ~(RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N);
> + } else {
> + reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
> + reg |= MASTER_VID_FUNC_EN_N;
> + }
> writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
>
> reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> index b633a4a5082a..0cf27c731727 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> @@ -127,7 +127,9 @@
>
> /* ANALOGIX_DP_FUNC_EN_1 */
> #define MASTER_VID_FUNC_EN_N (0x1 << 7)
> +#define RK_VID_CAP_FUNC_EN_N (0x1 << 6)
> #define SLAVE_VID_FUNC_EN_N (0x1 << 5)
> +#define RK_VID_FIFO_FUNC_EN_N(0x1 << 5)
> #define AUD_FIFO_FUNC_EN_N (0x1 << 4)
> #define AUD_FUNC_EN_N(0x1 << 3)
> #define HDCP_FUNC_EN_N (0x1 << 2)
> --
> 2.17.0
Re: [RESEND PATCH v6 14/27] drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll
On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote:
>
> From: zain wang <w...@rock-chips.com>
>
> There is no register named ANALOGIX_DP_PLL_CTL in Rockchip edp phy reg
> list. We should use BIT_4 in ANALOGIX_DP_PD to control the pll power
> instead of ANALOGIX_DP_PLL_CTL.
>
> Cc: Douglas Anderson <diand...@chromium.org>
> Signed-off-by: zain wang <w...@rock-chips.com>
> Signed-off-by: Sean Paul <seanp...@chromium.org>
> Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
> Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
> Tested-by: Marek Szyprowski <m.szyprow...@samsung.com>
> Reviewed-by: Archit Taneja <arch...@codeaurora.org>
Acked-by: Jingoo Han <jingooh...@gmail.com>
Best regards,
Jingoo Han
> ---
>
> .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 20 +++
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 7b7fd227e1f9..02ab1aaa9993 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -230,16 +230,20 @@ enum pll_status
> analogix_dp_get_pll_lock_status(struct analogix_dp_device *dp)
> void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool
> enable)
> {
> u32 reg;
> + u32 mask = DP_PLL_PD;
> + u32 pd_addr = ANALOGIX_DP_PLL_CTL;
>
> - if (enable) {
> - reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
> - reg |= DP_PLL_PD;
> - writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
> - } else {
> - reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
> - reg &= ~DP_PLL_PD;
> - writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
> + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
> + pd_addr = ANALOGIX_DP_PD;
> + mask = RK_PLL_PD;
> }
> +
> + reg = readl(dp->reg_base + pd_addr);
> + if (enable)
> + reg |= mask;
> + else
> + reg &= ~mask;
> + writel(reg, dp->reg_base + pd_addr);
> }
>
> void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
> --
> 2.17.0
Re: [RESEND PATCH v6 14/27] drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll
On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote:
>
> From: zain wang
>
> There is no register named ANALOGIX_DP_PLL_CTL in Rockchip edp phy reg
> list. We should use BIT_4 in ANALOGIX_DP_PD to control the pll power
> instead of ANALOGIX_DP_PLL_CTL.
>
> Cc: Douglas Anderson
> Signed-off-by: zain wang
> Signed-off-by: Sean Paul
> Signed-off-by: Thierry Escande
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Enric Balletbo i Serra
> Tested-by: Marek Szyprowski
> Reviewed-by: Archit Taneja
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
>
> .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 20 +++
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 7b7fd227e1f9..02ab1aaa9993 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -230,16 +230,20 @@ enum pll_status
> analogix_dp_get_pll_lock_status(struct analogix_dp_device *dp)
> void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool
> enable)
> {
> u32 reg;
> + u32 mask = DP_PLL_PD;
> + u32 pd_addr = ANALOGIX_DP_PLL_CTL;
>
> - if (enable) {
> - reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
> - reg |= DP_PLL_PD;
> - writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
> - } else {
> - reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
> - reg &= ~DP_PLL_PD;
> - writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
> + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
> + pd_addr = ANALOGIX_DP_PD;
> + mask = RK_PLL_PD;
> }
> +
> + reg = readl(dp->reg_base + pd_addr);
> + if (enable)
> + reg |= mask;
> + else
> + reg &= ~mask;
> + writel(reg, dp->reg_base + pd_addr);
> }
>
> void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
> --
> 2.17.0
Re: [PATCH v5 09/10] PCI: dwc: Small computation improvement
On Tuesday, April 17, 2018 10:34 AM, Gustavo Pimentel wrote:
>
> Replaces a simple division by 2 to a right shift rotation of 1 bit.
>
> Probably any recent and decent compiler does this kind of substitution
> in order to improve code performance. Nevertheless it's a coding good
> practice whenever there is a division / multiplication by multiple of 2
> to replace it by the equivalent operation in this case, the shift
> rotation.
>
> Signed-off-by: Gustavo Pimentel <gustavo.pimen...@synopsys.com>
Acked-by: Jingoo Han <jingooh...@gmail.com>
> ---
> Change v1->v2:
> - Nothing changed, just to follow the patch set version.
> Change v2->v3:
> - Nothing changed, just to follow the patch set version.
> Changes v3->v4:
> - Added a small explication to the log description.
> Changes v4->v5:
> - Nothing changed, just to follow the patch set version.
>
> drivers/pci/dwc/pcie-designware-host.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/dwc/pcie-designware-host.c
> b/drivers/pci/dwc/pcie-designware-host.c
> index 5a23f78..fc55fde 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -332,8 +332,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>
> cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "config");
> if (cfg_res) {
> - pp->cfg0_size = resource_size(cfg_res) / 2;
> - pp->cfg1_size = resource_size(cfg_res) / 2;
> + pp->cfg0_size = resource_size(cfg_res) >> 1;
> + pp->cfg1_size = resource_size(cfg_res) >> 1;
> pp->cfg0_base = cfg_res->start;
> pp->cfg1_base = cfg_res->start + pp->cfg0_size;
> } else if (!pp->va_cfg0_base) {
> @@ -377,8 +377,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
> break;
> case 0:
> pp->cfg = win->res;
> - pp->cfg0_size = resource_size(pp->cfg) / 2;
> - pp->cfg1_size = resource_size(pp->cfg) / 2;
> + pp->cfg0_size = resource_size(pp->cfg) >> 1;
> + pp->cfg1_size = resource_size(pp->cfg) >> 1;
> pp->cfg0_base = pp->cfg->start;
> pp->cfg1_base = pp->cfg->start + pp->cfg0_size;
> break;
> --
> 2.7.4
>
Re: [PATCH v5 09/10] PCI: dwc: Small computation improvement
On Tuesday, April 17, 2018 10:34 AM, Gustavo Pimentel wrote:
>
> Replaces a simple division by 2 to a right shift rotation of 1 bit.
>
> Probably any recent and decent compiler does this kind of substitution
> in order to improve code performance. Nevertheless it's a coding good
> practice whenever there is a division / multiplication by multiple of 2
> to replace it by the equivalent operation in this case, the shift
> rotation.
>
> Signed-off-by: Gustavo Pimentel
Acked-by: Jingoo Han
> ---
> Change v1->v2:
> - Nothing changed, just to follow the patch set version.
> Change v2->v3:
> - Nothing changed, just to follow the patch set version.
> Changes v3->v4:
> - Added a small explication to the log description.
> Changes v4->v5:
> - Nothing changed, just to follow the patch set version.
>
> drivers/pci/dwc/pcie-designware-host.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/dwc/pcie-designware-host.c
> b/drivers/pci/dwc/pcie-designware-host.c
> index 5a23f78..fc55fde 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -332,8 +332,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>
> cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "config");
> if (cfg_res) {
> - pp->cfg0_size = resource_size(cfg_res) / 2;
> - pp->cfg1_size = resource_size(cfg_res) / 2;
> + pp->cfg0_size = resource_size(cfg_res) >> 1;
> + pp->cfg1_size = resource_size(cfg_res) >> 1;
> pp->cfg0_base = cfg_res->start;
> pp->cfg1_base = cfg_res->start + pp->cfg0_size;
> } else if (!pp->va_cfg0_base) {
> @@ -377,8 +377,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
> break;
> case 0:
> pp->cfg = win->res;
> - pp->cfg0_size = resource_size(pp->cfg) / 2;
> - pp->cfg1_size = resource_size(pp->cfg) / 2;
> + pp->cfg0_size = resource_size(pp->cfg) >> 1;
> + pp->cfg1_size = resource_size(pp->cfg) >> 1;
> pp->cfg0_base = pp->cfg->start;
> pp->cfg1_base = pp->cfg->start + pp->cfg0_size;
> break;
> --
> 2.7.4
>
Re: [PATCH v2 8/9] PCI: dwc: Small computation improvement
On Wednesday, April 11, 2018 3:40 AM, Gustavo Pimentel wrote:
>
> Hi Jingoo,
>
> On 11/04/2018 01:01, Jingoo Han wrote:
> > On Monday, April 9, 2018 5:41 AM, Gustavo Pimentel wrote:
> >>
> >> Replaces a simple division by 2 to a right shift rotation of 1 bit.
> >
> > It looks good. However, would you add a simple reason to the commit
> > message?
>
> Sure.
>
> Can be this one?
>
> Probably any recent and decent compiler does this kind of substitution
> in order to improve code performance. Nevertheless it's a coding good
> practice whenever there is a division / multiplication by multiple of 2
> to replace it by the equivalent operation in this case, the shift
> rotation.
Yes, that's what I wanted. The most platforms using 'dwc' are based on
ARM CPUs. So, the shift rotation can be better.
Thank you.
Best regards,
Jingoo Han
>
> >
> > Best regards,
> > Jingoo Han
> >
> >>
> >> Signed-off-by: Gustavo Pimentel <gustavo.pimen...@synopsys.com>
> >> ---
> >> Change v1->v2:
> >> - Nothing changed, just to follow the patch set version.
> >>
> >> drivers/pci/dwc/pcie-designware-host.c | 8
> >> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/pci/dwc/pcie-designware-host.c
> >> b/drivers/pci/dwc/pcie-designware-host.c
> >> index 03e9b82..8e6fed4 100644
> >> --- a/drivers/pci/dwc/pcie-designware-host.c
> >> +++ b/drivers/pci/dwc/pcie-designware-host.c
> >> @@ -332,8 +332,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
> >>
> >>cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> >> "config");
> >>if (cfg_res) {
> >> - pp->cfg0_size = resource_size(cfg_res) / 2;
> >> - pp->cfg1_size = resource_size(cfg_res) / 2;
> >> + pp->cfg0_size = resource_size(cfg_res) >> 1;
> >> + pp->cfg1_size = resource_size(cfg_res) >> 1;
> >>pp->cfg0_base = cfg_res->start;
> >>pp->cfg1_base = cfg_res->start + pp->cfg0_size;
> >>} else if (!pp->va_cfg0_base) {
> >> @@ -377,8 +377,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
> >>break;
> >>case 0:
> >>pp->cfg = win->res;
> >> - pp->cfg0_size = resource_size(pp->cfg) / 2;
> >> - pp->cfg1_size = resource_size(pp->cfg) / 2;
> >> + pp->cfg0_size = resource_size(pp->cfg) >> 1;
> >> + pp->cfg1_size = resource_size(pp->cfg) >> 1;
> >>pp->cfg0_base = pp->cfg->start;
> >>pp->cfg1_base = pp->cfg->start + pp->cfg0_size;
> >>break;
> >> --
> >> 2.7.4
> >>
> >
> >
>
> Regards,
> Gustavo
Re: [PATCH v2 8/9] PCI: dwc: Small computation improvement
On Wednesday, April 11, 2018 3:40 AM, Gustavo Pimentel wrote:
>
> Hi Jingoo,
>
> On 11/04/2018 01:01, Jingoo Han wrote:
> > On Monday, April 9, 2018 5:41 AM, Gustavo Pimentel wrote:
> >>
> >> Replaces a simple division by 2 to a right shift rotation of 1 bit.
> >
> > It looks good. However, would you add a simple reason to the commit
> > message?
>
> Sure.
>
> Can be this one?
>
> Probably any recent and decent compiler does this kind of substitution
> in order to improve code performance. Nevertheless it's a coding good
> practice whenever there is a division / multiplication by multiple of 2
> to replace it by the equivalent operation in this case, the shift
> rotation.
Yes, that's what I wanted. The most platforms using 'dwc' are based on
ARM CPUs. So, the shift rotation can be better.
Thank you.
Best regards,
Jingoo Han
>
> >
> > Best regards,
> > Jingoo Han
> >
> >>
> >> Signed-off-by: Gustavo Pimentel
> >> ---
> >> Change v1->v2:
> >> - Nothing changed, just to follow the patch set version.
> >>
> >> drivers/pci/dwc/pcie-designware-host.c | 8
> >> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/pci/dwc/pcie-designware-host.c
> >> b/drivers/pci/dwc/pcie-designware-host.c
> >> index 03e9b82..8e6fed4 100644
> >> --- a/drivers/pci/dwc/pcie-designware-host.c
> >> +++ b/drivers/pci/dwc/pcie-designware-host.c
> >> @@ -332,8 +332,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
> >>
> >>cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> >> "config");
> >>if (cfg_res) {
> >> - pp->cfg0_size = resource_size(cfg_res) / 2;
> >> - pp->cfg1_size = resource_size(cfg_res) / 2;
> >> + pp->cfg0_size = resource_size(cfg_res) >> 1;
> >> + pp->cfg1_size = resource_size(cfg_res) >> 1;
> >>pp->cfg0_base = cfg_res->start;
> >>pp->cfg1_base = cfg_res->start + pp->cfg0_size;
> >>} else if (!pp->va_cfg0_base) {
> >> @@ -377,8 +377,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
> >>break;
> >>case 0:
> >>pp->cfg = win->res;
> >> - pp->cfg0_size = resource_size(pp->cfg) / 2;
> >> - pp->cfg1_size = resource_size(pp->cfg) / 2;
> >> + pp->cfg0_size = resource_size(pp->cfg) >> 1;
> >> + pp->cfg1_size = resource_size(pp->cfg) >> 1;
> >>pp->cfg0_base = pp->cfg->start;
> >>pp->cfg1_base = pp->cfg->start + pp->cfg0_size;
> >>break;
> >> --
> >> 2.7.4
> >>
> >
> >
>
> Regards,
> Gustavo
Re: [PATCH v2 9/9] PCI: dwc: Replace magic number by defines
On Monday, April 9, 2018 5:41 AM, Gustavo Pimentel wrote: > > Replace magic numbers by a well known define in order to make the code > human readable and also facilitate the code reusability. > > Signed-off-by: Gustavo Pimentel <gustavo.pimen...@synopsys.com> Acked-by: Jingoo Han <jingooh...@gmail.com> > --- > Change v1->v2: > - Nothing changed, just to follow the patch set version. > > drivers/pci/dwc/pcie-designware-host.c | 34 - > - > drivers/pci/dwc/pcie-designware.h | 1 + > 2 files changed, 21 insertions(+), 14 deletions(-) > [.]
Re: [PATCH v2 9/9] PCI: dwc: Replace magic number by defines
On Monday, April 9, 2018 5:41 AM, Gustavo Pimentel wrote: > > Replace magic numbers by a well known define in order to make the code > human readable and also facilitate the code reusability. > > Signed-off-by: Gustavo Pimentel Acked-by: Jingoo Han > --- > Change v1->v2: > - Nothing changed, just to follow the patch set version. > > drivers/pci/dwc/pcie-designware-host.c | 34 - > - > drivers/pci/dwc/pcie-designware.h | 1 + > 2 files changed, 21 insertions(+), 14 deletions(-) > [.]
Re: [PATCH v2 7/9] PCI: dwc: Replace lower into upper case characters
On Monday, April 9, 2018 5:41 AM, Gustavo Pimentel wrote: > > Replaces lower into upper case characters in comments and debug printks. > > This is an attempt to keep the messages coherent within the designware > driver. > > Also fixed code style on dw_pcie_irq_domain_free function. > > Signed-off-by: Gustavo Pimentel <gustavo.pimen...@synopsys.com> Acked-by: Jingoo Han <jingooh...@gmail.com> > --- > Change v1->v2: > - Added an extra log description line about code style following Fabio > Estevam suggestion. > > drivers/pci/dwc/pcie-designware-ep.c | 16 > drivers/pci/dwc/pcie-designware-host.c | 35 ++--- > - > drivers/pci/dwc/pcie-designware.c | 22 ++--- > 3 files changed, 38 insertions(+), 35 deletions(-) > [.]
Re: [PATCH v2 7/9] PCI: dwc: Replace lower into upper case characters
On Monday, April 9, 2018 5:41 AM, Gustavo Pimentel wrote: > > Replaces lower into upper case characters in comments and debug printks. > > This is an attempt to keep the messages coherent within the designware > driver. > > Also fixed code style on dw_pcie_irq_domain_free function. > > Signed-off-by: Gustavo Pimentel Acked-by: Jingoo Han > --- > Change v1->v2: > - Added an extra log description line about code style following Fabio > Estevam suggestion. > > drivers/pci/dwc/pcie-designware-ep.c | 16 > drivers/pci/dwc/pcie-designware-host.c | 35 ++--- > - > drivers/pci/dwc/pcie-designware.c | 22 ++--- > 3 files changed, 38 insertions(+), 35 deletions(-) > [.]
Re: [PATCH v2 8/9] PCI: dwc: Small computation improvement
On Monday, April 9, 2018 5:41 AM, Gustavo Pimentel wrote:
>
> Replaces a simple division by 2 to a right shift rotation of 1 bit.
It looks good. However, would you add a simple reason to the commit
message?
Best regards,
Jingoo Han
>
> Signed-off-by: Gustavo Pimentel <gustavo.pimen...@synopsys.com>
> ---
> Change v1->v2:
> - Nothing changed, just to follow the patch set version.
>
> drivers/pci/dwc/pcie-designware-host.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/dwc/pcie-designware-host.c
> b/drivers/pci/dwc/pcie-designware-host.c
> index 03e9b82..8e6fed4 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -332,8 +332,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>
> cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "config");
> if (cfg_res) {
> - pp->cfg0_size = resource_size(cfg_res) / 2;
> - pp->cfg1_size = resource_size(cfg_res) / 2;
> + pp->cfg0_size = resource_size(cfg_res) >> 1;
> + pp->cfg1_size = resource_size(cfg_res) >> 1;
> pp->cfg0_base = cfg_res->start;
> pp->cfg1_base = cfg_res->start + pp->cfg0_size;
> } else if (!pp->va_cfg0_base) {
> @@ -377,8 +377,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
> break;
> case 0:
> pp->cfg = win->res;
> - pp->cfg0_size = resource_size(pp->cfg) / 2;
> - pp->cfg1_size = resource_size(pp->cfg) / 2;
> + pp->cfg0_size = resource_size(pp->cfg) >> 1;
> + pp->cfg1_size = resource_size(pp->cfg) >> 1;
> pp->cfg0_base = pp->cfg->start;
> pp->cfg1_base = pp->cfg->start + pp->cfg0_size;
> break;
> --
> 2.7.4
>
Re: [PATCH v2 8/9] PCI: dwc: Small computation improvement
On Monday, April 9, 2018 5:41 AM, Gustavo Pimentel wrote:
>
> Replaces a simple division by 2 to a right shift rotation of 1 bit.
It looks good. However, would you add a simple reason to the commit
message?
Best regards,
Jingoo Han
>
> Signed-off-by: Gustavo Pimentel
> ---
> Change v1->v2:
> - Nothing changed, just to follow the patch set version.
>
> drivers/pci/dwc/pcie-designware-host.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/dwc/pcie-designware-host.c
> b/drivers/pci/dwc/pcie-designware-host.c
> index 03e9b82..8e6fed4 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -332,8 +332,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>
> cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "config");
> if (cfg_res) {
> - pp->cfg0_size = resource_size(cfg_res) / 2;
> - pp->cfg1_size = resource_size(cfg_res) / 2;
> + pp->cfg0_size = resource_size(cfg_res) >> 1;
> + pp->cfg1_size = resource_size(cfg_res) >> 1;
> pp->cfg0_base = cfg_res->start;
> pp->cfg1_base = cfg_res->start + pp->cfg0_size;
> } else if (!pp->va_cfg0_base) {
> @@ -377,8 +377,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
> break;
> case 0:
> pp->cfg = win->res;
> - pp->cfg0_size = resource_size(pp->cfg) / 2;
> - pp->cfg1_size = resource_size(pp->cfg) / 2;
> + pp->cfg0_size = resource_size(pp->cfg) >> 1;
> + pp->cfg1_size = resource_size(pp->cfg) >> 1;
> pp->cfg0_base = pp->cfg->start;
> pp->cfg1_base = pp->cfg->start + pp->cfg0_size;
> break;
> --
> 2.7.4
>
Re: [PATCH] video: fbdev: s3c-fb: remove dead platform code for Exynos and S5PV210 platforms
On Wednesday, February 14, 2018 7:01 AM wrote:
>
> Exynos5, Exynos4 and S5PV210 platforms have been converted to
> use Device Tree and Exynos DRM driver long time ago. Remove
> dead platform code for these platforms and update Kconfig
> s3c-fb entry accordingly.
>
> Cc: Jingoo Han <jingooh...@gmail.com>
Acked-by: Jingoo Han <jingooh...@gmail.com>
Best regards,
Jingoo Han
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
> ---
> drivers/video/fbdev/Kconfig |3
> drivers/video/fbdev/s3c-fb.c | 162 -
> --
> 2 files changed, 1 insertion(+), 164 deletions(-)
>
> Index: b/drivers/video/fbdev/Kconfig
> ===
> --- a/drivers/video/fbdev/Kconfig 2018-02-12 14:28:32.392677896
> +0100
> +++ b/drivers/video/fbdev/Kconfig 2018-02-14 12:54:06.399057592
> +0100
> @@ -2020,8 +2020,7 @@ config FB_TMIO_ACCELL
>
> config FB_S3C
> tristate "Samsung S3C framebuffer support"
> - depends on FB && (CPU_S3C2416 || ARCH_S3C64XX || \
> - ARCH_S5PV210 || ARCH_EXYNOS)
> + depends on FB && (CPU_S3C2416 || ARCH_S3C64XX)
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> Index: b/drivers/video/fbdev/s3c-fb.c
> ===
> --- a/drivers/video/fbdev/s3c-fb.c2017-10-18 14:35:22.063448310
> +0200
> +++ b/drivers/video/fbdev/s3c-fb.c2018-02-14 12:04:00.719262463
> +0100
> @@ -1716,63 +1716,6 @@ static struct s3c_fb_win_variant s3c_fb_
> },
> };
>
> -static struct s3c_fb_win_variant s3c_fb_data_s5p_wins[] = {
> - [0] = {
> - .has_osd_c = 1,
> - .osd_size_off = 0x8,
> - .palette_sz = 256,
> - .valid_bpp = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> - [1] = {
> - .has_osd_c = 1,
> - .has_osd_d = 1,
> - .osd_size_off = 0xc,
> - .has_osd_alpha = 1,
> - .palette_sz = 256,
> - .valid_bpp = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> - [2] = {
> - .has_osd_c = 1,
> - .has_osd_d = 1,
> - .osd_size_off = 0xc,
> - .has_osd_alpha = 1,
> - .palette_sz = 256,
> - .valid_bpp = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> - [3] = {
> - .has_osd_c = 1,
> - .has_osd_alpha = 1,
> - .palette_sz = 256,
> - .valid_bpp = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> - [4] = {
> - .has_osd_c = 1,
> - .has_osd_alpha = 1,
> - .palette_sz = 256,
> - .valid_bpp = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> -};
> -
> static struct s3c_fb_driverdata s3c_fb_data_64xx = {
> .variant = {
> .nr_windows = 5,
> @@ -1804,102 +1747,6 @@ static struct s3c_fb_driverdata s3c_fb_d
> .win[4] = _fb_data_64xx_wins[4],
> };
>
> -static struct s3c_fb_driverdata s3c_fb_data_s5pv210 = {
> - .variant = {
> - .nr_windows = 5,
> - .vidtcon= VIDTCON0,
> - .wincon = WINCON(0),
> - .winmap
Re: [PATCH] video: fbdev: s3c-fb: remove dead platform code for Exynos and S5PV210 platforms
On Wednesday, February 14, 2018 7:01 AM wrote:
>
> Exynos5, Exynos4 and S5PV210 platforms have been converted to
> use Device Tree and Exynos DRM driver long time ago. Remove
> dead platform code for these platforms and update Kconfig
> s3c-fb entry accordingly.
>
> Cc: Jingoo Han
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/video/fbdev/Kconfig |3
> drivers/video/fbdev/s3c-fb.c | 162 -
> --
> 2 files changed, 1 insertion(+), 164 deletions(-)
>
> Index: b/drivers/video/fbdev/Kconfig
> ===
> --- a/drivers/video/fbdev/Kconfig 2018-02-12 14:28:32.392677896
> +0100
> +++ b/drivers/video/fbdev/Kconfig 2018-02-14 12:54:06.399057592
> +0100
> @@ -2020,8 +2020,7 @@ config FB_TMIO_ACCELL
>
> config FB_S3C
> tristate "Samsung S3C framebuffer support"
> - depends on FB && (CPU_S3C2416 || ARCH_S3C64XX || \
> - ARCH_S5PV210 || ARCH_EXYNOS)
> + depends on FB && (CPU_S3C2416 || ARCH_S3C64XX)
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> Index: b/drivers/video/fbdev/s3c-fb.c
> ===
> --- a/drivers/video/fbdev/s3c-fb.c2017-10-18 14:35:22.063448310
> +0200
> +++ b/drivers/video/fbdev/s3c-fb.c2018-02-14 12:04:00.719262463
> +0100
> @@ -1716,63 +1716,6 @@ static struct s3c_fb_win_variant s3c_fb_
> },
> };
>
> -static struct s3c_fb_win_variant s3c_fb_data_s5p_wins[] = {
> - [0] = {
> - .has_osd_c = 1,
> - .osd_size_off = 0x8,
> - .palette_sz = 256,
> - .valid_bpp = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> - [1] = {
> - .has_osd_c = 1,
> - .has_osd_d = 1,
> - .osd_size_off = 0xc,
> - .has_osd_alpha = 1,
> - .palette_sz = 256,
> - .valid_bpp = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> - [2] = {
> - .has_osd_c = 1,
> - .has_osd_d = 1,
> - .osd_size_off = 0xc,
> - .has_osd_alpha = 1,
> - .palette_sz = 256,
> - .valid_bpp = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> - [3] = {
> - .has_osd_c = 1,
> - .has_osd_alpha = 1,
> - .palette_sz = 256,
> - .valid_bpp = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> - [4] = {
> - .has_osd_c = 1,
> - .has_osd_alpha = 1,
> - .palette_sz = 256,
> - .valid_bpp = (VALID_BPP1248 | VALID_BPP(13) |
> -VALID_BPP(15) | VALID_BPP(16) |
> -VALID_BPP(18) | VALID_BPP(19) |
> -VALID_BPP(24) | VALID_BPP(25) |
> -VALID_BPP(32)),
> - },
> -};
> -
> static struct s3c_fb_driverdata s3c_fb_data_64xx = {
> .variant = {
> .nr_windows = 5,
> @@ -1804,102 +1747,6 @@ static struct s3c_fb_driverdata s3c_fb_d
> .win[4] = _fb_data_64xx_wins[4],
> };
>
> -static struct s3c_fb_driverdata s3c_fb_data_s5pv210 = {
> - .variant = {
> - .nr_windows = 5,
> - .vidtcon= VIDTCON0,
> - .wincon = WINCON(0),
> - .winmap = WINxMAP(0),
> - .keycon = WKEYCON,
> - .osd
Re: [PATCH 3/3] PCI: designware-ep: Return an error when requesting a too large BAR size
On Thursday, February 1, 2018 1:58 PM, Andy Shevchenko wrote:
>
> On Thu, Feb 1, 2018 at 6:11 PM, Niklas Cassel <niklas.cas...@axis.com>
> wrote:
>
> include/linux/sizes.h:
>
> +SZ_4G 0x1ULL
>
> > + if (size > 0x1ULL) {
>
> #include
>
> if (size > SZ_4G) {
I like this one for the readability.
Thank you.
Best regards,
Jingoo Han
>
> ?
>
> --
> With Best Regards,
> Andy Shevchenko
Re: [PATCH 3/3] PCI: designware-ep: Return an error when requesting a too large BAR size
On Thursday, February 1, 2018 1:58 PM, Andy Shevchenko wrote:
>
> On Thu, Feb 1, 2018 at 6:11 PM, Niklas Cassel
> wrote:
>
> include/linux/sizes.h:
>
> +SZ_4G 0x1ULL
>
> > + if (size > 0x1ULL) {
>
> #include
>
> if (size > SZ_4G) {
I like this one for the readability.
Thank you.
Best regards,
Jingoo Han
>
> ?
>
> --
> With Best Regards,
> Andy Shevchenko
Re: [PATCH 6/6] MAINTAINERS: add dri-devel for backlight subsystem patches
On Wednesday, January 17, 2018 11:53 AM, Daniel Thompson wrote: > On 17/01/18 14:01, Daniel Vetter wrote: > > For the same reasons we've added dri-devel for all fbdev patches: Most > > of the actively developed drivers using this infrastructure are in > > drivers/gpu/. It just makes sense to cross-post patches and keep > > aligned. And total activity in the backlight subsystem is miniscule > > compared to drm overall. > > > > Cc: Lee Jones <lee.jo...@linaro.org> > > Cc: Daniel Thompson <daniel.thomp...@linaro.org> > > Cc: Jingoo Han <jingooh...@gmail.com> > > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > > Acked-by: Daniel Thompson <daniel.thomp...@linaro.org> Acked-by: Jingoo Han <jingooh...@gmail.com> Best regards, Jingoo Han > > > > --- > > MAINTAINERS | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 7691e1025708..6534517f53b6 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -2546,6 +2546,7 @@ BACKLIGHT CLASS/SUBSYSTEM > > M:Lee Jones <lee.jo...@linaro.org> > > M:Daniel Thompson <daniel.thomp...@linaro.org> > > M:Jingoo Han <jingooh...@gmail.com> > > +L: dri-de...@lists.freedesktop.org > > T:git > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git > > S:Maintained > > F:drivers/video/backlight/ > >
Re: [PATCH 6/6] MAINTAINERS: add dri-devel for backlight subsystem patches
On Wednesday, January 17, 2018 11:53 AM, Daniel Thompson wrote: > On 17/01/18 14:01, Daniel Vetter wrote: > > For the same reasons we've added dri-devel for all fbdev patches: Most > > of the actively developed drivers using this infrastructure are in > > drivers/gpu/. It just makes sense to cross-post patches and keep > > aligned. And total activity in the backlight subsystem is miniscule > > compared to drm overall. > > > > Cc: Lee Jones > > Cc: Daniel Thompson > > Cc: Jingoo Han > > Signed-off-by: Daniel Vetter > > Acked-by: Daniel Thompson Acked-by: Jingoo Han Best regards, Jingoo Han > > > > --- > > MAINTAINERS | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 7691e1025708..6534517f53b6 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -2546,6 +2546,7 @@ BACKLIGHT CLASS/SUBSYSTEM > > M:Lee Jones > > M:Daniel Thompson > > M:Jingoo Han > > +L: dri-de...@lists.freedesktop.org > > T:git > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git > > S:Maintained > > F:drivers/video/backlight/ > >
Re: [PATCH] PCI: exynos: remove the deprecated phy codes
On Tuesday, January 2, 2018 11:34 AM, Lorenzo Pieralisi wrote:
> On Wed, Dec 27, 2017 at 06:43:27PM +0900, Jaehoon Chung wrote:
> > pci-exynos had updated to use the PHY framework.
> > (drivers/phy/samsung/phy-exynos-pcie.c)
> > Removed the depreccated codes relevant to phy in pci-exynos.c.
> > Instead, use the phy-exynos-pcie.c file.
> >
> > Modified the binding documentation.
> >
> > Signed-off-by: Jaehoon Chung <jh80.ch...@samsung.com>
> > ---
> > .../bindings/pci/samsung,exynos5440-pcie.txt | 58 ++
> > drivers/pci/dwc/pci-exynos.c | 219
++-
> --
> > 2 files changed, 22 insertions(+), 255 deletions(-)
>
> I have updated the commit log to the patch below, please
> check before I push it out.
I think that the commit message looks good.
Thank you.
Best regards,
Jingoo Han
>
> Lorenzo
>
> -- >8 --
> Subject: [PATCH] PCI: exynos: Remove deprecated PHY initialization code
>
> Exynos platforms have a PCI PHY driver in the PHY framework that can be
> used by the PCI host bridge drivers to initialize and manage the PHY.
>
> Remove the deprecated PHY initialization code in the Exynos PCI host
> bridge driver by updating the driver to use the PHY framework API;
> modify the DT binding documentation accordingly.
>
> Signed-off-by: Jaehoon Chung <jh80.ch...@samsung.com>
> [lorenzo.pieral...@arm.com: updated commit log]
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
> Acked-by: Jingoo Han <jingooh...@gmail.com>
> Reviewed-by: Rob Herring <r...@kernel.org>
> ---
> .../bindings/pci/samsung,exynos5440-pcie.txt | 58 ++
> drivers/pci/dwc/pci-exynos.c | 219
++--
> -
> 2 files changed, 22 insertions(+), 255 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> pcie.txt
> index 34a11bfbfb60..651d957d1051 100644
> --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> @@ -6,9 +6,6 @@ and thus inherits all the common properties defined in
> designware-pcie.txt.
> Required properties:
> - compatible: "samsung,exynos5440-pcie"
> - reg: base addresses and lengths of the PCIe controller,
> - the PHY controller, additional register for the PHY controller.
> - (Registers for the PHY controller are DEPRECATED.
> - Use the PHY framework.)
> - reg-names : First name should be set to "elbi".
> And use the "config" instead of getting the configuration address
> space
> from "ranges".
> @@ -23,49 +20,8 @@ For other common properties, refer to
>
> Example:
>
> -SoC-specific DT Entry:
> +SoC-specific DT Entry (with using PHY framework):
>
> - pcie@29 {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x29 0x1000
> - 0x27 0x1000
> - 0x271000 0x40>;
> - interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
> - clocks = < 28>, < 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x4000 0x4000 0 0x1000
> /* configuration space */
> - 0x8100 0 0 0x40001000 0 0x0001
/*
> downstream I/O */
> - 0x8200 0 0x40011000 0x40011000 0 0x1ffef000>;
/*
> non-prefetchable memory */
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 GIC_SPI 21
> IRQ_TYPE_LEVEL_HIGH>;
> - num-lanes = <4>;
> - };
> -
> - pcie@2a {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x2a 0x1000
> - 0x272000 0x1000
> - 0x271040 0x40>;
> - interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
> - clocks = < 29>, < 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x6000 0x6000 0 0x0
Re: [PATCH] PCI: exynos: remove the deprecated phy codes
On Tuesday, January 2, 2018 11:34 AM, Lorenzo Pieralisi wrote:
> On Wed, Dec 27, 2017 at 06:43:27PM +0900, Jaehoon Chung wrote:
> > pci-exynos had updated to use the PHY framework.
> > (drivers/phy/samsung/phy-exynos-pcie.c)
> > Removed the depreccated codes relevant to phy in pci-exynos.c.
> > Instead, use the phy-exynos-pcie.c file.
> >
> > Modified the binding documentation.
> >
> > Signed-off-by: Jaehoon Chung
> > ---
> > .../bindings/pci/samsung,exynos5440-pcie.txt | 58 ++
> > drivers/pci/dwc/pci-exynos.c | 219
++-
> --
> > 2 files changed, 22 insertions(+), 255 deletions(-)
>
> I have updated the commit log to the patch below, please
> check before I push it out.
I think that the commit message looks good.
Thank you.
Best regards,
Jingoo Han
>
> Lorenzo
>
> -- >8 --
> Subject: [PATCH] PCI: exynos: Remove deprecated PHY initialization code
>
> Exynos platforms have a PCI PHY driver in the PHY framework that can be
> used by the PCI host bridge drivers to initialize and manage the PHY.
>
> Remove the deprecated PHY initialization code in the Exynos PCI host
> bridge driver by updating the driver to use the PHY framework API;
> modify the DT binding documentation accordingly.
>
> Signed-off-by: Jaehoon Chung
> [lorenzo.pieral...@arm.com: updated commit log]
> Signed-off-by: Lorenzo Pieralisi
> Acked-by: Jingoo Han
> Reviewed-by: Rob Herring
> ---
> .../bindings/pci/samsung,exynos5440-pcie.txt | 58 ++
> drivers/pci/dwc/pci-exynos.c | 219
++--
> -
> 2 files changed, 22 insertions(+), 255 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> pcie.txt
> index 34a11bfbfb60..651d957d1051 100644
> --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> @@ -6,9 +6,6 @@ and thus inherits all the common properties defined in
> designware-pcie.txt.
> Required properties:
> - compatible: "samsung,exynos5440-pcie"
> - reg: base addresses and lengths of the PCIe controller,
> - the PHY controller, additional register for the PHY controller.
> - (Registers for the PHY controller are DEPRECATED.
> - Use the PHY framework.)
> - reg-names : First name should be set to "elbi".
> And use the "config" instead of getting the configuration address
> space
> from "ranges".
> @@ -23,49 +20,8 @@ For other common properties, refer to
>
> Example:
>
> -SoC-specific DT Entry:
> +SoC-specific DT Entry (with using PHY framework):
>
> - pcie@29 {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x29 0x1000
> - 0x27 0x1000
> - 0x271000 0x40>;
> - interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
> - clocks = < 28>, < 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x4000 0x4000 0 0x1000
> /* configuration space */
> - 0x8100 0 0 0x40001000 0 0x0001
/*
> downstream I/O */
> - 0x8200 0 0x40011000 0x40011000 0 0x1ffef000>;
/*
> non-prefetchable memory */
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 GIC_SPI 21
> IRQ_TYPE_LEVEL_HIGH>;
> - num-lanes = <4>;
> - };
> -
> - pcie@2a {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x2a 0x1000
> - 0x272000 0x1000
> - 0x271040 0x40>;
> - interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
> - clocks = < 29>, < 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x6000 0x6000 0 0x1000
> /* configuration space */
> - 0x8100 0 0 0x60001000 0 0x0001
/*
> downstream I/O */
> -
Re: [PATCH] PCI: exynos: remove the deprecated phy codes
On Wednesday, December 27, 2017 1:43 AM, Jaehoon Chung wrote:
>
> pci-exynos had updated to use the PHY framework.
> (drivers/phy/samsung/phy-exynos-pcie.c)
> Removed the depreccated codes relevant to phy in pci-exynos.c.
> Instead, use the phy-exynos-pcie.c file.
>
> Modified the binding documentation.
>
> Signed-off-by: Jaehoon Chung <jh80.ch...@samsung.com>
(I resend my email, because Bjorn's address was wrong in the previous
email.)
Thank you for your patch.
It looks good.
Acked-by: Jingoo Han <jingooh...@gmail.com>
Best regards,
Jingoo Han
> ---
> .../bindings/pci/samsung,exynos5440-pcie.txt | 58 ++
> drivers/pci/dwc/pci-exynos.c | 219
++---
> 2 files changed, 22 insertions(+), 255 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> pcie.txt
> index 34a11bfbfb60..651d957d1051 100644
> --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> @@ -6,9 +6,6 @@ and thus inherits all the common properties defined in
> designware-pcie.txt.
> Required properties:
> - compatible: "samsung,exynos5440-pcie"
> - reg: base addresses and lengths of the PCIe controller,
> - the PHY controller, additional register for the PHY controller.
> - (Registers for the PHY controller are DEPRECATED.
> - Use the PHY framework.)
> - reg-names : First name should be set to "elbi".
> And use the "config" instead of getting the configuration address
> space
> from "ranges".
> @@ -23,49 +20,8 @@ For other common properties, refer to
>
> Example:
>
> -SoC-specific DT Entry:
> +SoC-specific DT Entry (with using PHY framework):
>
> - pcie@29 {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x29 0x1000
> - 0x27 0x1000
> - 0x271000 0x40>;
> - interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
> - clocks = < 28>, < 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x4000 0x4000 0 0x1000
> /* configuration space */
> - 0x8100 0 0 0x40001000 0 0x0001
/*
> downstream I/O */
> - 0x8200 0 0x40011000 0x40011000 0 0x1ffef000>;
/*
> non-prefetchable memory */
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 GIC_SPI 21
> IRQ_TYPE_LEVEL_HIGH>;
> - num-lanes = <4>;
> - };
> -
> - pcie@2a {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x2a 0x1000
> - 0x272000 0x1000
> - 0x271040 0x40>;
> - interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
> - clocks = < 29>, < 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x6000 0x6000 0 0x1000
> /* configuration space */
> - 0x8100 0 0 0x60001000 0 0x0001
/*
> downstream I/O */
> - 0x8200 0 0x60011000 0x60011000 0 0x1ffef000>;
/*
> non-prefetchable memory */
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 GIC_SPI 24
> IRQ_TYPE_LEVEL_HIGH>;
> - num-lanes = <4>;
> - };
> -
> -With using PHY framework:
> pcie_phy0: pcie-phy@27 {
> ...
> reg = <0x27 0x1000>, <0x271000 0x40>;
> @@ -74,13 +30,21 @@ With using PHY framework:
> };
>
> pcie@29 {
> - ...
> + compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> reg = <0x29 0x1000>, <0x4000 0x1000>;
> reg-names = "elbi", "config";
> + clocks = < 28>, < 27>;
> + clock-names = &
Re: [PATCH] PCI: exynos: remove the deprecated phy codes
On Wednesday, December 27, 2017 1:43 AM, Jaehoon Chung wrote:
>
> pci-exynos had updated to use the PHY framework.
> (drivers/phy/samsung/phy-exynos-pcie.c)
> Removed the depreccated codes relevant to phy in pci-exynos.c.
> Instead, use the phy-exynos-pcie.c file.
>
> Modified the binding documentation.
>
> Signed-off-by: Jaehoon Chung
(I resend my email, because Bjorn's address was wrong in the previous
email.)
Thank you for your patch.
It looks good.
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> .../bindings/pci/samsung,exynos5440-pcie.txt | 58 ++
> drivers/pci/dwc/pci-exynos.c | 219
++---
> 2 files changed, 22 insertions(+), 255 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> pcie.txt
> index 34a11bfbfb60..651d957d1051 100644
> --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> @@ -6,9 +6,6 @@ and thus inherits all the common properties defined in
> designware-pcie.txt.
> Required properties:
> - compatible: "samsung,exynos5440-pcie"
> - reg: base addresses and lengths of the PCIe controller,
> - the PHY controller, additional register for the PHY controller.
> - (Registers for the PHY controller are DEPRECATED.
> - Use the PHY framework.)
> - reg-names : First name should be set to "elbi".
> And use the "config" instead of getting the configuration address
> space
> from "ranges".
> @@ -23,49 +20,8 @@ For other common properties, refer to
>
> Example:
>
> -SoC-specific DT Entry:
> +SoC-specific DT Entry (with using PHY framework):
>
> - pcie@29 {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x29 0x1000
> - 0x27 0x1000
> - 0x271000 0x40>;
> - interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
> - clocks = < 28>, < 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x4000 0x4000 0 0x1000
> /* configuration space */
> - 0x8100 0 0 0x40001000 0 0x0001
/*
> downstream I/O */
> - 0x8200 0 0x40011000 0x40011000 0 0x1ffef000>;
/*
> non-prefetchable memory */
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 GIC_SPI 21
> IRQ_TYPE_LEVEL_HIGH>;
> - num-lanes = <4>;
> - };
> -
> - pcie@2a {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x2a 0x1000
> - 0x272000 0x1000
> - 0x271040 0x40>;
> - interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
> - clocks = < 29>, < 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x6000 0x6000 0 0x1000
> /* configuration space */
> - 0x8100 0 0 0x60001000 0 0x0001
/*
> downstream I/O */
> - 0x8200 0 0x60011000 0x60011000 0 0x1ffef000>;
/*
> non-prefetchable memory */
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 GIC_SPI 24
> IRQ_TYPE_LEVEL_HIGH>;
> - num-lanes = <4>;
> - };
> -
> -With using PHY framework:
> pcie_phy0: pcie-phy@27 {
> ...
> reg = <0x27 0x1000>, <0x271000 0x40>;
> @@ -74,13 +30,21 @@ With using PHY framework:
> };
>
> pcie@29 {
> - ...
> + compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> reg = <0x29 0x1000>, <0x4000 0x1000>;
> reg-names = "elbi", "config";
> + clocks = < 28>, < 27>;
> + clock-names = "pcie", "pcie_bus";
> + #addres
Re: [PATCH] PCI: exynos: remove the deprecated phy codes
On Wednesday, December 27, 2017 1:43 AM, Jaehoon Chung wrote:
>
> pci-exynos had updated to use the PHY framework.
> (drivers/phy/samsung/phy-exynos-pcie.c)
> Removed the depreccated codes relevant to phy in pci-exynos.c.
> Instead, use the phy-exynos-pcie.c file.
>
> Modified the binding documentation.
>
> Signed-off-by: Jaehoon Chung <jh80.ch...@samsung.com>
Thank you for your patch.
It looks good.
Acked-by: Jingoo Han <jingooh...@gmail.com>
Best regards,
Jingoo Han
> ---
> .../bindings/pci/samsung,exynos5440-pcie.txt | 58 ++
> drivers/pci/dwc/pci-exynos.c | 219
++---
> 2 files changed, 22 insertions(+), 255 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> pcie.txt
> index 34a11bfbfb60..651d957d1051 100644
> --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> @@ -6,9 +6,6 @@ and thus inherits all the common properties defined in
> designware-pcie.txt.
> Required properties:
> - compatible: "samsung,exynos5440-pcie"
> - reg: base addresses and lengths of the PCIe controller,
> - the PHY controller, additional register for the PHY controller.
> - (Registers for the PHY controller are DEPRECATED.
> - Use the PHY framework.)
> - reg-names : First name should be set to "elbi".
> And use the "config" instead of getting the configuration address
> space
> from "ranges".
> @@ -23,49 +20,8 @@ For other common properties, refer to
>
> Example:
>
> -SoC-specific DT Entry:
> +SoC-specific DT Entry (with using PHY framework):
>
> - pcie@29 {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x29 0x1000
> - 0x27 0x1000
> - 0x271000 0x40>;
> - interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
> - clocks = < 28>, < 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x4000 0x4000 0 0x1000
> /* configuration space */
> - 0x8100 0 0 0x40001000 0 0x0001
/*
> downstream I/O */
> - 0x8200 0 0x40011000 0x40011000 0 0x1ffef000>;
/*
> non-prefetchable memory */
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 GIC_SPI 21
> IRQ_TYPE_LEVEL_HIGH>;
> - num-lanes = <4>;
> - };
> -
> - pcie@2a {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x2a 0x1000
> - 0x272000 0x1000
> - 0x271040 0x40>;
> - interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
> - clocks = < 29>, < 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x6000 0x6000 0 0x1000
> /* configuration space */
> - 0x8100 0 0 0x60001000 0 0x0001
/*
> downstream I/O */
> - 0x8200 0 0x60011000 0x60011000 0 0x1ffef000>;
/*
> non-prefetchable memory */
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 GIC_SPI 24
> IRQ_TYPE_LEVEL_HIGH>;
> - num-lanes = <4>;
> - };
> -
> -With using PHY framework:
> pcie_phy0: pcie-phy@27 {
> ...
> reg = <0x27 0x1000>, <0x271000 0x40>;
> @@ -74,13 +30,21 @@ With using PHY framework:
> };
>
> pcie@29 {
> - ...
> + compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> reg = <0x29 0x1000>, <0x4000 0x1000>;
> reg-names = "elbi", "config";
> + clocks = < 28>, < 27>;
> + clock-names = "pcie", "pcie_bus";
> + #address-cells = <3>;
Re: [PATCH] PCI: exynos: remove the deprecated phy codes
On Wednesday, December 27, 2017 1:43 AM, Jaehoon Chung wrote:
>
> pci-exynos had updated to use the PHY framework.
> (drivers/phy/samsung/phy-exynos-pcie.c)
> Removed the depreccated codes relevant to phy in pci-exynos.c.
> Instead, use the phy-exynos-pcie.c file.
>
> Modified the binding documentation.
>
> Signed-off-by: Jaehoon Chung
Thank you for your patch.
It looks good.
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> .../bindings/pci/samsung,exynos5440-pcie.txt | 58 ++
> drivers/pci/dwc/pci-exynos.c | 219
++---
> 2 files changed, 22 insertions(+), 255 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> pcie.txt
> index 34a11bfbfb60..651d957d1051 100644
> --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> @@ -6,9 +6,6 @@ and thus inherits all the common properties defined in
> designware-pcie.txt.
> Required properties:
> - compatible: "samsung,exynos5440-pcie"
> - reg: base addresses and lengths of the PCIe controller,
> - the PHY controller, additional register for the PHY controller.
> - (Registers for the PHY controller are DEPRECATED.
> - Use the PHY framework.)
> - reg-names : First name should be set to "elbi".
> And use the "config" instead of getting the configuration address
> space
> from "ranges".
> @@ -23,49 +20,8 @@ For other common properties, refer to
>
> Example:
>
> -SoC-specific DT Entry:
> +SoC-specific DT Entry (with using PHY framework):
>
> - pcie@29 {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x29 0x1000
> - 0x27 0x1000
> - 0x271000 0x40>;
> - interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
> - clocks = < 28>, < 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x4000 0x4000 0 0x1000
> /* configuration space */
> - 0x8100 0 0 0x40001000 0 0x0001
/*
> downstream I/O */
> - 0x8200 0 0x40011000 0x40011000 0 0x1ffef000>;
/*
> non-prefetchable memory */
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 GIC_SPI 21
> IRQ_TYPE_LEVEL_HIGH>;
> - num-lanes = <4>;
> - };
> -
> - pcie@2a {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x2a 0x1000
> - 0x272000 0x1000
> - 0x271040 0x40>;
> - interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
> - clocks = < 29>, < 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x6000 0x6000 0 0x1000
> /* configuration space */
> - 0x8100 0 0 0x60001000 0 0x0001
/*
> downstream I/O */
> - 0x8200 0 0x60011000 0x60011000 0 0x1ffef000>;
/*
> non-prefetchable memory */
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 GIC_SPI 24
> IRQ_TYPE_LEVEL_HIGH>;
> - num-lanes = <4>;
> - };
> -
> -With using PHY framework:
> pcie_phy0: pcie-phy@27 {
> ...
> reg = <0x27 0x1000>, <0x271000 0x40>;
> @@ -74,13 +30,21 @@ With using PHY framework:
> };
>
> pcie@29 {
> - ...
> + compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> reg = <0x29 0x1000>, <0x4000 0x1000>;
> reg-names = "elbi", "config";
> + clocks = < 28>, < 27>;
> + clock-names = "pcie", "pcie_bus";
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
Re: [PATCH v2] backlight: otm3225a: add support for ORISE OTM3225A LCD SoC
On Wednesday, December 27, 2017 10:20 AM, Felix Brack wrote: > > This patch adds a LCD driver supporting the OTM3225A LCD SoC > from ORISE Technology. This device can drive TFT LC panels having a > resolution of 240x320 pixels. After initializing the OTM3225A using > it's SPI interface it switches to use 16-bib RGB as external > display interface. > > Signed-off-by: Felix Brack <f...@ltec.ch> Acked-by: Jingoo Han <jingooh...@gmail.com> Best regards, Jingoo Han > > Changes in v2: > - use descriptive names for registers instead of hard coding them > - remove unnecessary registers in initialization sequence > - make use of resource-managed functions like devm_kzalloc() > instead of kzalloc() which simplifies and shortens the code > - replace mdelay() by msleep() > - use module_spi_init() since we do not do anything special > in init/exit > - use dev_name() instead of hard coding driver name multiple times > - use static storage class for structure otm3225a_ops > - sort include files alphabetically > - use standardized licensing header > - modify Makefile respecting alphabetical sort order > --- > drivers/video/backlight/Kconfig| 7 ++ > drivers/video/backlight/Makefile | 1 + > drivers/video/backlight/otm3225a.c | 251 > + > 3 files changed, 259 insertions(+) > create mode 100644 drivers/video/backlight/otm3225a.c > > diff --git a/drivers/video/backlight/Kconfig > b/drivers/video/backlight/Kconfig > index 4e1d2ad..06e187b 100644 > --- a/drivers/video/backlight/Kconfig > +++ b/drivers/video/backlight/Kconfig > @@ -150,6 +150,13 @@ config LCD_HX8357 > If you have a HX-8357 LCD panel, say Y to enable its LCD control > driver. > > + config LCD_OTM3225A > + tristate "ORISE Technology OTM3225A support" > + depends on SPI > + help > + If you have a panel based on the OTM3225A controller > + chip then say y to include a driver for it. > + > endif # LCD_CLASS_DEVICE > > # > diff --git a/drivers/video/backlight/Makefile > b/drivers/video/backlight/Makefile > index 8905129..2473377 100644 > --- a/drivers/video/backlight/Makefile > +++ b/drivers/video/backlight/Makefile > @@ -12,6 +12,7 @@ obj-$(CONFIG_LCD_LD9040)+= ld9040.o > obj-$(CONFIG_LCD_LMS283GF05) += lms283gf05.o > obj-$(CONFIG_LCD_LMS501KF03) += lms501kf03.o > obj-$(CONFIG_LCD_LTV350QV) += ltv350qv.o > +obj-$(CONFIG_LCD_OTM3225A) += otm3225a.o > obj-$(CONFIG_LCD_PLATFORM) += platform_lcd.o > obj-$(CONFIG_LCD_S6E63M0)+= s6e63m0.o > obj-$(CONFIG_LCD_TDO24M) += tdo24m.o > diff --git a/drivers/video/backlight/otm3225a.c > b/drivers/video/backlight/otm3225a.c > new file mode 100644 > index 000..cb1df6c > --- /dev/null > +++ b/drivers/video/backlight/otm3225a.c > @@ -0,0 +1,251 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* Driver for ORISE Technology OTM3225A SOC for TFT LCD > + * Copyright (C) 2017, EETS GmbH, Felix Brack <f...@ltec.ch> > + * > + * This driver implements a lcd device for the ORISE OTM3225A display > + * controller. The control interface to the display is SPI and the > display's > + * memory is updated over the 16-bit RGB interface. > + * The main source of information for writing this driver was provided by > the > + * OTM3225A datasheet from ORISE Technology. Some information arise from > the > + * ILI9328 datasheet from ILITEK as well as from the datasheets and > sample code > + * provided by Crystalfontz America Inc. who sells the CFAF240320A-032T, > a 3.2" > + * TFT LC display using the OTM3225A controller. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define OTM3225A_INDEX_REG 0x70 > +#define OTM3225A_DATA_REG0x72 > + > +/* instruncton register list */ > +#define DRIVER_OUTPUT_CTRL_1 0x01 > +#define DRIVER_WAVEFORM_CTRL 0x02 > +#define ENTRY_MODE 0x03 > +#define SCALING_CTRL 0x04 > +#define DISPLAY_CTRL_1 0x07 > +#define DISPLAY_CTRL_2 0x08 > +#define DISPLAY_CTRL_3 0x09 > +#define FRAME_CYCLE_CTRL 0x0A > +#define EXT_DISP_IFACE_CTRL_10x0C > +#define FRAME_MAKER_POS 0x0D > +#define EXT_DISP_IFACE_CTRL_20x0F > +#define POWER_CTRL_1 0x10 > +#define POWER_CTRL_2 0x11 > +#define POWER_CTRL_3 0x12 > +#define POWER_CTRL_4 0x13 > +#define GRAM_ADDR_HORIZ_SET 0x20 > +#define GRAM_ADDR_VERT_SET 0x21 > +#define GRAM_READ_WRITE 0x22 > +#define POWER_CTRL_7 0x29 > +#define F
Re: [PATCH v2] backlight: otm3225a: add support for ORISE OTM3225A LCD SoC
On Wednesday, December 27, 2017 10:20 AM, Felix Brack wrote: > > This patch adds a LCD driver supporting the OTM3225A LCD SoC > from ORISE Technology. This device can drive TFT LC panels having a > resolution of 240x320 pixels. After initializing the OTM3225A using > it's SPI interface it switches to use 16-bib RGB as external > display interface. > > Signed-off-by: Felix Brack Acked-by: Jingoo Han Best regards, Jingoo Han > > Changes in v2: > - use descriptive names for registers instead of hard coding them > - remove unnecessary registers in initialization sequence > - make use of resource-managed functions like devm_kzalloc() > instead of kzalloc() which simplifies and shortens the code > - replace mdelay() by msleep() > - use module_spi_init() since we do not do anything special > in init/exit > - use dev_name() instead of hard coding driver name multiple times > - use static storage class for structure otm3225a_ops > - sort include files alphabetically > - use standardized licensing header > - modify Makefile respecting alphabetical sort order > --- > drivers/video/backlight/Kconfig| 7 ++ > drivers/video/backlight/Makefile | 1 + > drivers/video/backlight/otm3225a.c | 251 > + > 3 files changed, 259 insertions(+) > create mode 100644 drivers/video/backlight/otm3225a.c > > diff --git a/drivers/video/backlight/Kconfig > b/drivers/video/backlight/Kconfig > index 4e1d2ad..06e187b 100644 > --- a/drivers/video/backlight/Kconfig > +++ b/drivers/video/backlight/Kconfig > @@ -150,6 +150,13 @@ config LCD_HX8357 > If you have a HX-8357 LCD panel, say Y to enable its LCD control > driver. > > + config LCD_OTM3225A > + tristate "ORISE Technology OTM3225A support" > + depends on SPI > + help > + If you have a panel based on the OTM3225A controller > + chip then say y to include a driver for it. > + > endif # LCD_CLASS_DEVICE > > # > diff --git a/drivers/video/backlight/Makefile > b/drivers/video/backlight/Makefile > index 8905129..2473377 100644 > --- a/drivers/video/backlight/Makefile > +++ b/drivers/video/backlight/Makefile > @@ -12,6 +12,7 @@ obj-$(CONFIG_LCD_LD9040)+= ld9040.o > obj-$(CONFIG_LCD_LMS283GF05) += lms283gf05.o > obj-$(CONFIG_LCD_LMS501KF03) += lms501kf03.o > obj-$(CONFIG_LCD_LTV350QV) += ltv350qv.o > +obj-$(CONFIG_LCD_OTM3225A) += otm3225a.o > obj-$(CONFIG_LCD_PLATFORM) += platform_lcd.o > obj-$(CONFIG_LCD_S6E63M0)+= s6e63m0.o > obj-$(CONFIG_LCD_TDO24M) += tdo24m.o > diff --git a/drivers/video/backlight/otm3225a.c > b/drivers/video/backlight/otm3225a.c > new file mode 100644 > index 000..cb1df6c > --- /dev/null > +++ b/drivers/video/backlight/otm3225a.c > @@ -0,0 +1,251 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* Driver for ORISE Technology OTM3225A SOC for TFT LCD > + * Copyright (C) 2017, EETS GmbH, Felix Brack > + * > + * This driver implements a lcd device for the ORISE OTM3225A display > + * controller. The control interface to the display is SPI and the > display's > + * memory is updated over the 16-bit RGB interface. > + * The main source of information for writing this driver was provided by > the > + * OTM3225A datasheet from ORISE Technology. Some information arise from > the > + * ILI9328 datasheet from ILITEK as well as from the datasheets and > sample code > + * provided by Crystalfontz America Inc. who sells the CFAF240320A-032T, > a 3.2" > + * TFT LC display using the OTM3225A controller. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define OTM3225A_INDEX_REG 0x70 > +#define OTM3225A_DATA_REG0x72 > + > +/* instruncton register list */ > +#define DRIVER_OUTPUT_CTRL_1 0x01 > +#define DRIVER_WAVEFORM_CTRL 0x02 > +#define ENTRY_MODE 0x03 > +#define SCALING_CTRL 0x04 > +#define DISPLAY_CTRL_1 0x07 > +#define DISPLAY_CTRL_2 0x08 > +#define DISPLAY_CTRL_3 0x09 > +#define FRAME_CYCLE_CTRL 0x0A > +#define EXT_DISP_IFACE_CTRL_10x0C > +#define FRAME_MAKER_POS 0x0D > +#define EXT_DISP_IFACE_CTRL_20x0F > +#define POWER_CTRL_1 0x10 > +#define POWER_CTRL_2 0x11 > +#define POWER_CTRL_3 0x12 > +#define POWER_CTRL_4 0x13 > +#define GRAM_ADDR_HORIZ_SET 0x20 > +#define GRAM_ADDR_VERT_SET 0x21 > +#define GRAM_READ_WRITE 0x22 > +#define POWER_CTRL_7 0x29 > +#define FRAME_RATE_CTRL 0x2B > +#define GA
Re: [PATCH] backlight: otm3225a: add support for ORISE OTM3225A LCD SoC
t;otm3225a", >dev, dd, _ops);
Please use devm_lcd_device_register(), then you don't need
to use lcd_device_unregister() in otm3225a_remove().
> + if (IS_ERR(ld)) {
> + ret = PTR_ERR(ld);
> + goto err;
> + }
> + dd->spi = spi;
> + dd->ld = ld;
> + dev_set_drvdata(>dev, dd);
> +
> + dev_info(>dev, "Initializing and switching to RGB interface");
> + otm3225a_write(spi, display_init, ARRAY_SIZE(display_init));
> + otm3225a_write(spi, display_enable_rgb_interface,
> +ARRAY_SIZE(display_enable_rgb_interface));
> +
> +err:
> + return ret;
> +}
> +
> +static int otm3225a_remove(struct spi_device *spi)
> +{
> + struct otm3225a_data *dd;
> +
> + dd = dev_get_drvdata(>dev);
> + lcd_device_unregister(dd->ld);
> + kfree(dd);
If you use devm_kzalloc() and devm_lcd_device_register()
in otm3225a_probe as I mentioned above, you can remove
lcd_device_unregister() and kfree() here.
If so, you don't need otm3225a_remove().
What I want to say is that you can add only probe() function
when you use devm_* functions in your otm3225a driver code.
> + return 0;
> +}
> +
> +static struct spi_driver otm3225a_driver = {
> + .driver = {
> + .name = "otm3225a",
> + .owner = THIS_MODULE,
> + },
> + .probe = otm3225a_probe,
> + .remove = otm3225a_remove,
If you use devm_kzalloc() and devm_lcd_device_register(),
you can remove otm3225a_remove() as below.
+static struct spi_driver otm3225a_driver = {
+ .driver = {
+ .name = "otm3225a",
+ .owner = THIS_MODULE,
+ },
+ .probe = otm3225a_probe,
+};
Please refer to the following driver.
./drivers/video/backlight/tps65217_bl.c
> +};
> +
> +static __init int otm3225a_init(void)
> +{
> + return (_driver);
> +}
> +
> +static __exit void otm3225a_exit(void)
> +{
> + spi_unregister_driver(_driver);
> +}
> +
> +module_init(otm3225a_init);
> +module_exit(otm3225a_exit);
Instead of adding otm3225a_init(), otm3225a_exit(),
please use module_spi_driver macro as below.
This macro can reduce source code lines.
module_spi_driver(otm3225a_driver);
Best regards,
Jingoo Han
> +
> +MODULE_AUTHOR("Felix Brack <f...@ltec.ch>");
> +MODULE_DESCRIPTION("OTM3225A TFT LCD driver");
> +MODULE_VERSION("1.0.0");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
Re: [PATCH] backlight: otm3225a: add support for ORISE OTM3225A LCD SoC
ease use devm_lcd_device_register(), then you don't need
to use lcd_device_unregister() in otm3225a_remove().
> + if (IS_ERR(ld)) {
> + ret = PTR_ERR(ld);
> + goto err;
> + }
> + dd->spi = spi;
> + dd->ld = ld;
> + dev_set_drvdata(>dev, dd);
> +
> + dev_info(>dev, "Initializing and switching to RGB interface");
> + otm3225a_write(spi, display_init, ARRAY_SIZE(display_init));
> + otm3225a_write(spi, display_enable_rgb_interface,
> +ARRAY_SIZE(display_enable_rgb_interface));
> +
> +err:
> + return ret;
> +}
> +
> +static int otm3225a_remove(struct spi_device *spi)
> +{
> + struct otm3225a_data *dd;
> +
> + dd = dev_get_drvdata(>dev);
> + lcd_device_unregister(dd->ld);
> + kfree(dd);
If you use devm_kzalloc() and devm_lcd_device_register()
in otm3225a_probe as I mentioned above, you can remove
lcd_device_unregister() and kfree() here.
If so, you don't need otm3225a_remove().
What I want to say is that you can add only probe() function
when you use devm_* functions in your otm3225a driver code.
> + return 0;
> +}
> +
> +static struct spi_driver otm3225a_driver = {
> + .driver = {
> + .name = "otm3225a",
> + .owner = THIS_MODULE,
> + },
> + .probe = otm3225a_probe,
> + .remove = otm3225a_remove,
If you use devm_kzalloc() and devm_lcd_device_register(),
you can remove otm3225a_remove() as below.
+static struct spi_driver otm3225a_driver = {
+ .driver = {
+ .name = "otm3225a",
+ .owner = THIS_MODULE,
+ },
+ .probe = otm3225a_probe,
+};
Please refer to the following driver.
./drivers/video/backlight/tps65217_bl.c
> +};
> +
> +static __init int otm3225a_init(void)
> +{
> + return (_driver);
> +}
> +
> +static __exit void otm3225a_exit(void)
> +{
> + spi_unregister_driver(_driver);
> +}
> +
> +module_init(otm3225a_init);
> +module_exit(otm3225a_exit);
Instead of adding otm3225a_init(), otm3225a_exit(),
please use module_spi_driver macro as below.
This macro can reduce source code lines.
module_spi_driver(otm3225a_driver);
Best regards,
Jingoo Han
> +
> +MODULE_AUTHOR("Felix Brack ");
> +MODULE_DESCRIPTION("OTM3225A TFT LCD driver");
> +MODULE_VERSION("1.0.0");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
Re: [RFC 2/2] pci: dwc: pci-exynos: add the codes to support the exynos5433
On Thursday, December 21, 2017 9:21 PM, Jaehoon Chung wrote:
> On 12/22/2017 01:12 AM, Jingoo Han wrote:
> > On Thursday, December 21, 2017 7:14 AM, Jaehoon Chung wrote:
> >>
> >> Exynos5433 has the PCIe for WiFi.
> >> Added the codes relevant to PCIe for supporting the exynos5433.
> >> Also changed the binding documentation name to
> >> 'samsung,exynos-pcie.txt'.
> >> (It's not only exynos5440 anymore.)
> >>
> >
> > I have no objection.
> > However, I added some comments about Exynos5440.
> >
> >> Signed-off-by: Jaehoon Chung <jh80.ch...@samsung.com>
> >> ---
> >> ...exynos5440-pcie.txt => samsung,exynos-pcie.txt} | 2 +-
> >> drivers/pci/dwc/pci-exynos.c | 183
> > -
> >> 2 files changed, 144 insertions(+), 41 deletions(-)
> >> rename Documentation/devicetree/bindings/pci/{samsung,exynos5440-
> pcie.txt
> >> => samsung,exynos-pcie.txt} (97%)
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> >> pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos-
> pcie.txt
> >> similarity index 97%
> >> rename from Documentation/devicetree/bindings/pci/samsung,exynos5440-
> >> pcie.txt
> >> rename to Documentation/devicetree/bindings/pci/samsung,exynos-pcie.txt
> >> index 34a11bfbfb60..958dcc150505 100644
> >> --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> >> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.txt
> >> @@ -4,7 +4,7 @@ This PCIe host controller is based on the Synopsys
> >> DesignWare PCIe IP
> >> and thus inherits all the common properties defined in designware-
> >> pcie.txt.
> >>
> >> Required properties:
> >> -- compatible: "samsung,exynos5440-pcie"
> >> +- compatible: "samsung,exynos5440-pcie" or "samsung,exynos5433-pcie"
> >> - reg: base addresses and lengths of the PCIe controller,
> >>the PHY controller, additional register for the PHY controller.
> >>(Registers for the PHY controller are DEPRECATED.
> >> diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-
> exynos.c
> >> index 5596fdedbb94..8dee2e90347e 100644
> >> --- a/drivers/pci/dwc/pci-exynos.c
> >> +++ b/drivers/pci/dwc/pci-exynos.c
> >> @@ -40,6 +40,8 @@
> >> #define PCIE_IRQ_SPECIAL 0x008
> >> #define PCIE_IRQ_EN_PULSE 0x00c
> >> #define PCIE_IRQ_EN_LEVEL 0x010
> >> +#define PCIE_SW_WAKE 0x018
> >> +#define PCIE_BUS_EN BIT(1)
> >> #define IRQ_MSI_ENABLEBIT(2)
> >> #define PCIE_IRQ_EN_SPECIAL 0x014
> >> #define PCIE_PWR_RESET0x018
> >> @@ -49,7 +51,8 @@
> >> #define PCIE_NONSTICKY_RESET 0x024
> >> #define PCIE_APP_INIT_RESET 0x028
> >> #define PCIE_APP_LTSSM_ENABLE 0x02c
> >> -#define PCIE_ELBI_RDLH_LINKUP 0x064
> >> +#define PCIE_ELBI_RDLH_LINKUP 0x074
> >
> > The address of this register should be 0x064 for exynos5440.
> > Howe about the following?
> >
> > +#define EXYNOS5440_PCIE_ELBI_RDLH_LINKUP 0x064
> > +#define PCIE_ELBI_RDLH_LINKUP 0x074
> >
> > Or you can add the following.
> >
> > /* Exynos5440 PCIe ELBI registers */
> > #define EXYNOS5440_PCIE_ELBI_RDLH_LINKUP0x064
>
> Maybe, you're right. Because i didn't have Exynos5440 TRM, it's problem to
> me about updating other SoCs.
> I have checked almost all variants Exynos. They are using the LINKUP
> register as 0x74.
>
> If i can get the exynos5440 TRM, it's much helpful to me. Is it possible?
I don't have Exynos5440 TRM.
Please ask other guys.
Best regards,
Jingoo Han
>
> >
> >> +#define PCIE_ELBI_XMLH_LINKUP BIT(4)
> >> #define PCIE_ELBI_LTSSM_ENABLE0x1
> >> #define PCIE_ELBI_SLV_AWMISC 0x11c
> >> #define PCIE_ELBI_SLV_ARMISC 0x120
> >> @@ -94,6 +97,10 @@
> >> #define PCIE_PHY_TRSV3_PD_TSV BIT(7)
> >> #define PCIE_PHY_TRSV3_LVCC 0x31c
> >>
> >> +/* DBI register */
> >> +#define PCIE_MISC_CONTROL_1_OFF 0x8BC
> >> +#define DBI_RO_WR_EN BIT(0)
> >> +
> >> struct exynos_pcie_mem_res {
> >>void __iomem *elbi_base; /
Re: [RFC 2/2] pci: dwc: pci-exynos: add the codes to support the exynos5433
On Thursday, December 21, 2017 9:21 PM, Jaehoon Chung wrote:
> On 12/22/2017 01:12 AM, Jingoo Han wrote:
> > On Thursday, December 21, 2017 7:14 AM, Jaehoon Chung wrote:
> >>
> >> Exynos5433 has the PCIe for WiFi.
> >> Added the codes relevant to PCIe for supporting the exynos5433.
> >> Also changed the binding documentation name to
> >> 'samsung,exynos-pcie.txt'.
> >> (It's not only exynos5440 anymore.)
> >>
> >
> > I have no objection.
> > However, I added some comments about Exynos5440.
> >
> >> Signed-off-by: Jaehoon Chung
> >> ---
> >> ...exynos5440-pcie.txt => samsung,exynos-pcie.txt} | 2 +-
> >> drivers/pci/dwc/pci-exynos.c | 183
> > -
> >> 2 files changed, 144 insertions(+), 41 deletions(-)
> >> rename Documentation/devicetree/bindings/pci/{samsung,exynos5440-
> pcie.txt
> >> => samsung,exynos-pcie.txt} (97%)
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> >> pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos-
> pcie.txt
> >> similarity index 97%
> >> rename from Documentation/devicetree/bindings/pci/samsung,exynos5440-
> >> pcie.txt
> >> rename to Documentation/devicetree/bindings/pci/samsung,exynos-pcie.txt
> >> index 34a11bfbfb60..958dcc150505 100644
> >> --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> >> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.txt
> >> @@ -4,7 +4,7 @@ This PCIe host controller is based on the Synopsys
> >> DesignWare PCIe IP
> >> and thus inherits all the common properties defined in designware-
> >> pcie.txt.
> >>
> >> Required properties:
> >> -- compatible: "samsung,exynos5440-pcie"
> >> +- compatible: "samsung,exynos5440-pcie" or "samsung,exynos5433-pcie"
> >> - reg: base addresses and lengths of the PCIe controller,
> >>the PHY controller, additional register for the PHY controller.
> >>(Registers for the PHY controller are DEPRECATED.
> >> diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-
> exynos.c
> >> index 5596fdedbb94..8dee2e90347e 100644
> >> --- a/drivers/pci/dwc/pci-exynos.c
> >> +++ b/drivers/pci/dwc/pci-exynos.c
> >> @@ -40,6 +40,8 @@
> >> #define PCIE_IRQ_SPECIAL 0x008
> >> #define PCIE_IRQ_EN_PULSE 0x00c
> >> #define PCIE_IRQ_EN_LEVEL 0x010
> >> +#define PCIE_SW_WAKE 0x018
> >> +#define PCIE_BUS_EN BIT(1)
> >> #define IRQ_MSI_ENABLEBIT(2)
> >> #define PCIE_IRQ_EN_SPECIAL 0x014
> >> #define PCIE_PWR_RESET0x018
> >> @@ -49,7 +51,8 @@
> >> #define PCIE_NONSTICKY_RESET 0x024
> >> #define PCIE_APP_INIT_RESET 0x028
> >> #define PCIE_APP_LTSSM_ENABLE 0x02c
> >> -#define PCIE_ELBI_RDLH_LINKUP 0x064
> >> +#define PCIE_ELBI_RDLH_LINKUP 0x074
> >
> > The address of this register should be 0x064 for exynos5440.
> > Howe about the following?
> >
> > +#define EXYNOS5440_PCIE_ELBI_RDLH_LINKUP 0x064
> > +#define PCIE_ELBI_RDLH_LINKUP 0x074
> >
> > Or you can add the following.
> >
> > /* Exynos5440 PCIe ELBI registers */
> > #define EXYNOS5440_PCIE_ELBI_RDLH_LINKUP0x064
>
> Maybe, you're right. Because i didn't have Exynos5440 TRM, it's problem to
> me about updating other SoCs.
> I have checked almost all variants Exynos. They are using the LINKUP
> register as 0x74.
>
> If i can get the exynos5440 TRM, it's much helpful to me. Is it possible?
I don't have Exynos5440 TRM.
Please ask other guys.
Best regards,
Jingoo Han
>
> >
> >> +#define PCIE_ELBI_XMLH_LINKUP BIT(4)
> >> #define PCIE_ELBI_LTSSM_ENABLE0x1
> >> #define PCIE_ELBI_SLV_AWMISC 0x11c
> >> #define PCIE_ELBI_SLV_ARMISC 0x120
> >> @@ -94,6 +97,10 @@
> >> #define PCIE_PHY_TRSV3_PD_TSV BIT(7)
> >> #define PCIE_PHY_TRSV3_LVCC 0x31c
> >>
> >> +/* DBI register */
> >> +#define PCIE_MISC_CONTROL_1_OFF 0x8BC
> >> +#define DBI_RO_WR_EN BIT(0)
> >> +
> >> struct exynos_pcie_mem_res {
> >>void __iomem *elbi_base; /* DT 0th resource: PCIe CTRL
Re: [PATCH v6 06/18] PCI: designware-ep: Add generic function for raising MSI irq
On Wednesday, December 20, 2017 2:33 PM, Joao Pinto wrote:
>
>
> Hi,
>
> Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> > Add a generic function for raising MSI irqs that can be used by all
> > DWC based controllers.
> >
> > Note that certain controllers, like DRA7xx, have a special convenience
> > register for raising MSI irqs that doesn't require you to explicitly map
> > the MSI address. Therefore, it is likely that certain drivers will
> > not use this generic function, even if they can.
> >
> > Signed-off-by: Niklas Cassel <niklas.cas...@axis.com>
> > ---
> > drivers/pci/dwc/pcie-designware-ep.c | 35
> +++
> > drivers/pci/dwc/pcie-designware.h| 9 +
> > 2 files changed, 44 insertions(+)
> >
> > diff --git a/drivers/pci/dwc/pcie-designware-ep.c
> b/drivers/pci/dwc/pcie-designware-ep.c
> > index 700ed2f4becf..c5aa1cac5041 100644
> > --- a/drivers/pci/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/dwc/pcie-designware-ep.c
> > @@ -282,6 +282,41 @@ static const struct pci_epc_ops epc_ops = {
> > .stop = dw_pcie_ep_stop,
> > };
> >
> > +int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep,
> > +u8 interrupt_num)
> > +{
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + struct pci_epc *epc = ep->epc;
> > + u16 msg_ctrl, msg_data;
> > + u32 msg_addr_lower, msg_addr_upper;
> > + u64 msg_addr;
> > + bool has_upper;
> > + int ret;
> > +
> > + /* Raise MSI per the PCI Local Bus Specification Revision 3.0,
> 6.8.1. */
> > + msg_ctrl = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL);
> > + has_upper = !!(msg_ctrl & PCI_MSI_FLAGS_64BIT);
> > + msg_addr_lower = dw_pcie_readl_dbi(pci, MSI_MESSAGE_ADDR_L32);
> > + if (has_upper) {
> > + msg_addr_upper = dw_pcie_readl_dbi(pci,
> MSI_MESSAGE_ADDR_U32);
> > + msg_data = dw_pcie_readw_dbi(pci, MSI_MESSAGE_DATA_64);
> > + } else {
> > + msg_addr_upper = 0;
> > + msg_data = dw_pcie_readw_dbi(pci, MSI_MESSAGE_DATA_32);
> > + }
> > + msg_addr = ((u64) msg_addr_upper) << 32 | msg_addr_lower;
> > + ret = dw_pcie_ep_map_addr(epc, ep->msi_mem_phys, msg_addr,
> > + epc->mem->page_size);
> > + if (ret)
> > + return ret;
> > +
> > + writel(msg_data | (interrupt_num - 1), ep->msi_mem);
> > +
> > + dw_pcie_ep_unmap_addr(epc, ep->msi_mem_phys);
> > +
> > + return 0;
> > +}
> > +
> > void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
> > {
> > struct pci_epc *epc = ep->epc;
> > diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-
> designware.h
> > index 37dfad8d003f..24edac035160 100644
> > --- a/drivers/pci/dwc/pcie-designware.h
> > +++ b/drivers/pci/dwc/pcie-designware.h
> > @@ -106,6 +106,8 @@
> > #define MSI_CAP_MME_MASK (7 << MSI_CAP_MME_SHIFT)
> > #define MSI_MESSAGE_ADDR_L32 0x54
> > #define MSI_MESSAGE_ADDR_U32 0x58
> > +#define MSI_MESSAGE_DATA_320x58
> > +#define MSI_MESSAGE_DATA_640x5C
> >
> > /*
> > * Maximum number of MSI IRQs can be 256 per controller. But keep
> > @@ -338,6 +340,7 @@ static inline int dw_pcie_host_init(struct pcie_port
> *pp)
> > void dw_pcie_ep_linkup(struct dw_pcie_ep *ep);
> > int dw_pcie_ep_init(struct dw_pcie_ep *ep);
> > void dw_pcie_ep_exit(struct dw_pcie_ep *ep);
> > +int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 interrupt_num);
> > void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar);
> > #else
> > static inline void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> > @@ -353,6 +356,12 @@ static inline void dw_pcie_ep_exit(struct
> dw_pcie_ep *ep)
> > {
> > }
> >
> > +static inline int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep,
> > + u8 interrupt_num)
> > +{
> > + return 0;
> > +}
> > +
> > static inline void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum
> pci_barno bar)
> > {
> > }
> >
>
> Acked-by: Joao Pinto <jpi...@synopsys.com>
Acked-by: Jingoo Han <jingooh...@gmail.com>
Best regards,
Jingoo Han
Re: [PATCH v6 06/18] PCI: designware-ep: Add generic function for raising MSI irq
On Wednesday, December 20, 2017 2:33 PM, Joao Pinto wrote:
>
>
> Hi,
>
> Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> > Add a generic function for raising MSI irqs that can be used by all
> > DWC based controllers.
> >
> > Note that certain controllers, like DRA7xx, have a special convenience
> > register for raising MSI irqs that doesn't require you to explicitly map
> > the MSI address. Therefore, it is likely that certain drivers will
> > not use this generic function, even if they can.
> >
> > Signed-off-by: Niklas Cassel
> > ---
> > drivers/pci/dwc/pcie-designware-ep.c | 35
> +++
> > drivers/pci/dwc/pcie-designware.h| 9 +
> > 2 files changed, 44 insertions(+)
> >
> > diff --git a/drivers/pci/dwc/pcie-designware-ep.c
> b/drivers/pci/dwc/pcie-designware-ep.c
> > index 700ed2f4becf..c5aa1cac5041 100644
> > --- a/drivers/pci/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/dwc/pcie-designware-ep.c
> > @@ -282,6 +282,41 @@ static const struct pci_epc_ops epc_ops = {
> > .stop = dw_pcie_ep_stop,
> > };
> >
> > +int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep,
> > +u8 interrupt_num)
> > +{
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + struct pci_epc *epc = ep->epc;
> > + u16 msg_ctrl, msg_data;
> > + u32 msg_addr_lower, msg_addr_upper;
> > + u64 msg_addr;
> > + bool has_upper;
> > + int ret;
> > +
> > + /* Raise MSI per the PCI Local Bus Specification Revision 3.0,
> 6.8.1. */
> > + msg_ctrl = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL);
> > + has_upper = !!(msg_ctrl & PCI_MSI_FLAGS_64BIT);
> > + msg_addr_lower = dw_pcie_readl_dbi(pci, MSI_MESSAGE_ADDR_L32);
> > + if (has_upper) {
> > + msg_addr_upper = dw_pcie_readl_dbi(pci,
> MSI_MESSAGE_ADDR_U32);
> > + msg_data = dw_pcie_readw_dbi(pci, MSI_MESSAGE_DATA_64);
> > + } else {
> > + msg_addr_upper = 0;
> > + msg_data = dw_pcie_readw_dbi(pci, MSI_MESSAGE_DATA_32);
> > + }
> > + msg_addr = ((u64) msg_addr_upper) << 32 | msg_addr_lower;
> > + ret = dw_pcie_ep_map_addr(epc, ep->msi_mem_phys, msg_addr,
> > + epc->mem->page_size);
> > + if (ret)
> > + return ret;
> > +
> > + writel(msg_data | (interrupt_num - 1), ep->msi_mem);
> > +
> > + dw_pcie_ep_unmap_addr(epc, ep->msi_mem_phys);
> > +
> > + return 0;
> > +}
> > +
> > void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
> > {
> > struct pci_epc *epc = ep->epc;
> > diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-
> designware.h
> > index 37dfad8d003f..24edac035160 100644
> > --- a/drivers/pci/dwc/pcie-designware.h
> > +++ b/drivers/pci/dwc/pcie-designware.h
> > @@ -106,6 +106,8 @@
> > #define MSI_CAP_MME_MASK (7 << MSI_CAP_MME_SHIFT)
> > #define MSI_MESSAGE_ADDR_L32 0x54
> > #define MSI_MESSAGE_ADDR_U32 0x58
> > +#define MSI_MESSAGE_DATA_320x58
> > +#define MSI_MESSAGE_DATA_640x5C
> >
> > /*
> > * Maximum number of MSI IRQs can be 256 per controller. But keep
> > @@ -338,6 +340,7 @@ static inline int dw_pcie_host_init(struct pcie_port
> *pp)
> > void dw_pcie_ep_linkup(struct dw_pcie_ep *ep);
> > int dw_pcie_ep_init(struct dw_pcie_ep *ep);
> > void dw_pcie_ep_exit(struct dw_pcie_ep *ep);
> > +int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 interrupt_num);
> > void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar);
> > #else
> > static inline void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> > @@ -353,6 +356,12 @@ static inline void dw_pcie_ep_exit(struct
> dw_pcie_ep *ep)
> > {
> > }
> >
> > +static inline int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep,
> > + u8 interrupt_num)
> > +{
> > + return 0;
> > +}
> > +
> > static inline void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum
> pci_barno bar)
> > {
> > }
> >
>
> Acked-by: Joao Pinto
Acked-by: Jingoo Han
Best regards,
Jingoo Han
Re: [PATCH v6 04/18] PCI: designware-ep: Pre-allocate memory for MSI in dw_pcie_ep_init
On Wednesday, December 20, 2017 2:30 PM, Joao Pinto wrote:
>
> Hi,
>
> Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> > Certain SoCs need to map the MSI address in raise_irq.
> > To map an address, you first need to call pci_epc_mem_alloc_addr(),
> > however, pci_epc_mem_alloc_addr() calls ioremap() (which can sleep).
> >
> > Since raise_irq is only called from atomic context, we can't call
> > pci_epc_mem_alloc_addr() from raise_irq.
> >
> > Pre-allocate a page in dw_pcie_ep_init(), so that this page can later
> > be used to map/unmap the MSI address in raise_irq.
> >
> > Signed-off-by: Niklas Cassel <niklas.cas...@axis.com>
> > ---
> > drivers/pci/dwc/pcie-designware-ep.c | 10 ++
> > drivers/pci/dwc/pcie-designware.h| 2 ++
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/drivers/pci/dwc/pcie-designware-ep.c
> b/drivers/pci/dwc/pcie-designware-ep.c
> > index 3fb34be99715..8d8019cdff2a 100644
> > --- a/drivers/pci/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/dwc/pcie-designware-ep.c
> > @@ -286,6 +286,9 @@ void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
> > {
> > struct pci_epc *epc = ep->epc;
> >
> > + pci_epc_mem_free_addr(epc, ep->msi_mem_phys, ep->msi_mem,
> > + epc->mem->page_size);
> > +
> > pci_epc_mem_exit(epc);
> > }
> >
> > @@ -341,6 +344,13 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> > return ret;
> > }
> >
> > + ep->msi_mem = pci_epc_mem_alloc_addr(epc, >msi_mem_phys,
> > +epc->mem->page_size);
> > + if (!ep->msi_mem) {
> > + dev_err(dev, "Failed to reserve memory for MSI\n");
> > + return -ENOMEM;
> > + }
> > +
> > ep->epc = epc;
> > epc_set_drvdata(epc, ep);
> > dw_pcie_setup(pci);
> > diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-
> designware.h
> > index 9aaf0cd04dd6..5a1da459eda5 100644
> > --- a/drivers/pci/dwc/pcie-designware.h
> > +++ b/drivers/pci/dwc/pcie-designware.h
> > @@ -198,6 +198,8 @@ struct dw_pcie_ep {
> > unsigned long ob_window_map;
> > u32 num_ib_windows;
> > u32 num_ob_windows;
> > + void __iomem*msi_mem;
> > + phys_addr_t msi_mem_phys;
> > };
> >
> > struct dw_pcie_ops {
> >
>
> Acked-by: Joao Pinto <jpi...@synopsys.com>
Acked-by: Jingoo Han <jingooh...@gmail.com>
Best regards,
Jingoo Han
Re: [PATCH v6 04/18] PCI: designware-ep: Pre-allocate memory for MSI in dw_pcie_ep_init
On Wednesday, December 20, 2017 2:30 PM, Joao Pinto wrote:
>
> Hi,
>
> Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> > Certain SoCs need to map the MSI address in raise_irq.
> > To map an address, you first need to call pci_epc_mem_alloc_addr(),
> > however, pci_epc_mem_alloc_addr() calls ioremap() (which can sleep).
> >
> > Since raise_irq is only called from atomic context, we can't call
> > pci_epc_mem_alloc_addr() from raise_irq.
> >
> > Pre-allocate a page in dw_pcie_ep_init(), so that this page can later
> > be used to map/unmap the MSI address in raise_irq.
> >
> > Signed-off-by: Niklas Cassel
> > ---
> > drivers/pci/dwc/pcie-designware-ep.c | 10 ++
> > drivers/pci/dwc/pcie-designware.h| 2 ++
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/drivers/pci/dwc/pcie-designware-ep.c
> b/drivers/pci/dwc/pcie-designware-ep.c
> > index 3fb34be99715..8d8019cdff2a 100644
> > --- a/drivers/pci/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/dwc/pcie-designware-ep.c
> > @@ -286,6 +286,9 @@ void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
> > {
> > struct pci_epc *epc = ep->epc;
> >
> > + pci_epc_mem_free_addr(epc, ep->msi_mem_phys, ep->msi_mem,
> > + epc->mem->page_size);
> > +
> > pci_epc_mem_exit(epc);
> > }
> >
> > @@ -341,6 +344,13 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> > return ret;
> > }
> >
> > + ep->msi_mem = pci_epc_mem_alloc_addr(epc, >msi_mem_phys,
> > +epc->mem->page_size);
> > + if (!ep->msi_mem) {
> > + dev_err(dev, "Failed to reserve memory for MSI\n");
> > + return -ENOMEM;
> > + }
> > +
> > ep->epc = epc;
> > epc_set_drvdata(epc, ep);
> > dw_pcie_setup(pci);
> > diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-
> designware.h
> > index 9aaf0cd04dd6..5a1da459eda5 100644
> > --- a/drivers/pci/dwc/pcie-designware.h
> > +++ b/drivers/pci/dwc/pcie-designware.h
> > @@ -198,6 +198,8 @@ struct dw_pcie_ep {
> > unsigned long ob_window_map;
> > u32 num_ib_windows;
> > u32 num_ob_windows;
> > + void __iomem*msi_mem;
> > + phys_addr_t msi_mem_phys;
> > };
> >
> > struct dw_pcie_ops {
> >
>
> Acked-by: Joao Pinto
Acked-by: Jingoo Han
Best regards,
Jingoo Han
Re: [PATCH v6 03/18] PCI: designware-ep: Read-only registers need DBI_RO_WR_EN to be writable
On Wednesday, December 20, 2017 2:19 PM, Joao Pinto wrote: > > > Hi, > > Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu: > > Certain registers that pcie-designware-ep tries to write to are read- > only > > registers. However, these registers can become read/write if we first > > enable the DBI_RO_WR_EN bit. Set/unset the DBI_RO_WR_EN bit before/after > > writing these registers. > > > > Signed-off-by: Niklas Cassel <niklas.cas...@axis.com> > > --- > > drivers/pci/dwc/pcie-designware-ep.c | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/pci/dwc/pcie-designware-ep.c > b/drivers/pci/dwc/pcie-designware-ep.c > > index c92ab87fd660..3fb34be99715 100644 > > --- a/drivers/pci/dwc/pcie-designware-ep.c > > +++ b/drivers/pci/dwc/pcie-designware-ep.c > > @@ -35,8 +35,10 @@ static void dw_pcie_ep_reset_bar(struct dw_pcie *pci, > enum pci_barno bar) > > u32 reg; > > > > reg = PCI_BASE_ADDRESS_0 + (4 * bar); > > + dw_pcie_dbi_ro_wr_en(pci); > > dw_pcie_writel_dbi2(pci, reg, 0x0); > > dw_pcie_writel_dbi(pci, reg, 0x0); > > + dw_pcie_dbi_ro_wr_dis(pci); > > } > > > > static int dw_pcie_ep_write_header(struct pci_epc *epc, > > @@ -45,6 +47,7 @@ static int dw_pcie_ep_write_header(struct pci_epc *epc, > > struct dw_pcie_ep *ep = epc_get_drvdata(epc); > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep); > > > > + dw_pcie_dbi_ro_wr_en(pci); > > dw_pcie_writew_dbi(pci, PCI_VENDOR_ID, hdr->vendorid); > > dw_pcie_writew_dbi(pci, PCI_DEVICE_ID, hdr->deviceid); > > dw_pcie_writeb_dbi(pci, PCI_REVISION_ID, hdr->revid); > > @@ -58,6 +61,7 @@ static int dw_pcie_ep_write_header(struct pci_epc *epc, > > dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_ID, hdr->subsys_id); > > dw_pcie_writeb_dbi(pci, PCI_INTERRUPT_PIN, > >hdr->interrupt_pin); > > + dw_pcie_dbi_ro_wr_dis(pci); > > > > return 0; > > } > > @@ -142,8 +146,10 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, > enum pci_barno bar, > > if (ret) > > return ret; > > > > + dw_pcie_dbi_ro_wr_en(pci); > > dw_pcie_writel_dbi2(pci, reg, size - 1); > > dw_pcie_writel_dbi(pci, reg, flags); > > + dw_pcie_dbi_ro_wr_dis(pci); > > > > return 0; > > } > > @@ -223,7 +229,9 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, > u8 encode_int) > > val = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL); > > val &= ~MSI_CAP_MMC_MASK; > > val |= (encode_int << MSI_CAP_MMC_SHIFT) & MSI_CAP_MMC_MASK; > > + dw_pcie_dbi_ro_wr_en(pci); > > dw_pcie_writew_dbi(pci, MSI_MESSAGE_CONTROL, val); > > + dw_pcie_dbi_ro_wr_dis(pci); > > > > return 0; > > } > > > > Acked-by: Joao Pinto <jpi...@synopsys.com> Acked-by: Jingoo Han <jingooh...@gmail.com> Best regards, Jingoo Han
Re: [PATCH v6 03/18] PCI: designware-ep: Read-only registers need DBI_RO_WR_EN to be writable
On Wednesday, December 20, 2017 2:19 PM, Joao Pinto wrote: > > > Hi, > > Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu: > > Certain registers that pcie-designware-ep tries to write to are read- > only > > registers. However, these registers can become read/write if we first > > enable the DBI_RO_WR_EN bit. Set/unset the DBI_RO_WR_EN bit before/after > > writing these registers. > > > > Signed-off-by: Niklas Cassel > > --- > > drivers/pci/dwc/pcie-designware-ep.c | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/pci/dwc/pcie-designware-ep.c > b/drivers/pci/dwc/pcie-designware-ep.c > > index c92ab87fd660..3fb34be99715 100644 > > --- a/drivers/pci/dwc/pcie-designware-ep.c > > +++ b/drivers/pci/dwc/pcie-designware-ep.c > > @@ -35,8 +35,10 @@ static void dw_pcie_ep_reset_bar(struct dw_pcie *pci, > enum pci_barno bar) > > u32 reg; > > > > reg = PCI_BASE_ADDRESS_0 + (4 * bar); > > + dw_pcie_dbi_ro_wr_en(pci); > > dw_pcie_writel_dbi2(pci, reg, 0x0); > > dw_pcie_writel_dbi(pci, reg, 0x0); > > + dw_pcie_dbi_ro_wr_dis(pci); > > } > > > > static int dw_pcie_ep_write_header(struct pci_epc *epc, > > @@ -45,6 +47,7 @@ static int dw_pcie_ep_write_header(struct pci_epc *epc, > > struct dw_pcie_ep *ep = epc_get_drvdata(epc); > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep); > > > > + dw_pcie_dbi_ro_wr_en(pci); > > dw_pcie_writew_dbi(pci, PCI_VENDOR_ID, hdr->vendorid); > > dw_pcie_writew_dbi(pci, PCI_DEVICE_ID, hdr->deviceid); > > dw_pcie_writeb_dbi(pci, PCI_REVISION_ID, hdr->revid); > > @@ -58,6 +61,7 @@ static int dw_pcie_ep_write_header(struct pci_epc *epc, > > dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_ID, hdr->subsys_id); > > dw_pcie_writeb_dbi(pci, PCI_INTERRUPT_PIN, > >hdr->interrupt_pin); > > + dw_pcie_dbi_ro_wr_dis(pci); > > > > return 0; > > } > > @@ -142,8 +146,10 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, > enum pci_barno bar, > > if (ret) > > return ret; > > > > + dw_pcie_dbi_ro_wr_en(pci); > > dw_pcie_writel_dbi2(pci, reg, size - 1); > > dw_pcie_writel_dbi(pci, reg, flags); > > + dw_pcie_dbi_ro_wr_dis(pci); > > > > return 0; > > } > > @@ -223,7 +229,9 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, > u8 encode_int) > > val = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL); > > val &= ~MSI_CAP_MMC_MASK; > > val |= (encode_int << MSI_CAP_MMC_SHIFT) & MSI_CAP_MMC_MASK; > > + dw_pcie_dbi_ro_wr_en(pci); > > dw_pcie_writew_dbi(pci, MSI_MESSAGE_CONTROL, val); > > + dw_pcie_dbi_ro_wr_dis(pci); > > > > return 0; > > } > > > > Acked-by: Joao Pinto Acked-by: Jingoo Han Best regards, Jingoo Han
Re: [PATCH v6 02/18] PCI: designware-ep: dw_pcie_ep_set_msi() should only set MMC bits
On Wednesday, December 20, 2017 2:18 PM, Joao Pinto wrote: > > Hi, > > Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu: > > Previously, dw_pcie_ep_set_msi() wrote all bits in the Message Control > > register, thus overwriting the PCI_MSI_FLAGS_64BIT bit. > > By clearing the PCI_MSI_FLAGS_64BIT bit, we break MSI > > on systems where the RC has set a 64 bit MSI address. > > Fix dw_pcie_ep_set_msi() so that it only sets MMC bits. > > > > Signed-off-by: Niklas Cassel <niklas.cas...@axis.com> > > --- > > drivers/pci/dwc/pcie-designware-ep.c | 4 +++- > > drivers/pci/dwc/pcie-designware.h| 1 + > > 2 files changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/pci/dwc/pcie-designware-ep.c > b/drivers/pci/dwc/pcie-designware-ep.c > > index d53d5f168363..c92ab87fd660 100644 > > --- a/drivers/pci/dwc/pcie-designware-ep.c > > +++ b/drivers/pci/dwc/pcie-designware-ep.c > > @@ -220,7 +220,9 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, > u8 encode_int) > > struct dw_pcie_ep *ep = epc_get_drvdata(epc); > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep); > > > > - val = (encode_int << MSI_CAP_MMC_SHIFT); > > + val = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL); > > + val &= ~MSI_CAP_MMC_MASK; > > + val |= (encode_int << MSI_CAP_MMC_SHIFT) & MSI_CAP_MMC_MASK; > > dw_pcie_writew_dbi(pci, MSI_MESSAGE_CONTROL, val); > > > > return 0; > > diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie- > designware.h > > index ecdede68522a..9aaf0cd04dd6 100644 > > --- a/drivers/pci/dwc/pcie-designware.h > > +++ b/drivers/pci/dwc/pcie-designware.h > > @@ -101,6 +101,7 @@ > > > > #define MSI_MESSAGE_CONTROL0x52 > > #define MSI_CAP_MMC_SHIFT 1 > > +#define MSI_CAP_MMC_MASK (7 << MSI_CAP_MMC_SHIFT) > > #define MSI_CAP_MME_SHIFT 4 > > #define MSI_CAP_MME_MASK (7 << MSI_CAP_MME_SHIFT) > > #define MSI_MESSAGE_ADDR_L32 0x54 > > > > Acked-by: Joao Pinto <jpi...@synopsys.com> Acked-by: Jingoo Han <jingooh...@gmail.com> Best regards, Jingoo Han
Re: [PATCH v6 02/18] PCI: designware-ep: dw_pcie_ep_set_msi() should only set MMC bits
On Wednesday, December 20, 2017 2:18 PM, Joao Pinto wrote: > > Hi, > > Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu: > > Previously, dw_pcie_ep_set_msi() wrote all bits in the Message Control > > register, thus overwriting the PCI_MSI_FLAGS_64BIT bit. > > By clearing the PCI_MSI_FLAGS_64BIT bit, we break MSI > > on systems where the RC has set a 64 bit MSI address. > > Fix dw_pcie_ep_set_msi() so that it only sets MMC bits. > > > > Signed-off-by: Niklas Cassel > > --- > > drivers/pci/dwc/pcie-designware-ep.c | 4 +++- > > drivers/pci/dwc/pcie-designware.h| 1 + > > 2 files changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/pci/dwc/pcie-designware-ep.c > b/drivers/pci/dwc/pcie-designware-ep.c > > index d53d5f168363..c92ab87fd660 100644 > > --- a/drivers/pci/dwc/pcie-designware-ep.c > > +++ b/drivers/pci/dwc/pcie-designware-ep.c > > @@ -220,7 +220,9 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, > u8 encode_int) > > struct dw_pcie_ep *ep = epc_get_drvdata(epc); > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep); > > > > - val = (encode_int << MSI_CAP_MMC_SHIFT); > > + val = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL); > > + val &= ~MSI_CAP_MMC_MASK; > > + val |= (encode_int << MSI_CAP_MMC_SHIFT) & MSI_CAP_MMC_MASK; > > dw_pcie_writew_dbi(pci, MSI_MESSAGE_CONTROL, val); > > > > return 0; > > diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie- > designware.h > > index ecdede68522a..9aaf0cd04dd6 100644 > > --- a/drivers/pci/dwc/pcie-designware.h > > +++ b/drivers/pci/dwc/pcie-designware.h > > @@ -101,6 +101,7 @@ > > > > #define MSI_MESSAGE_CONTROL0x52 > > #define MSI_CAP_MMC_SHIFT 1 > > +#define MSI_CAP_MMC_MASK (7 << MSI_CAP_MMC_SHIFT) > > #define MSI_CAP_MME_SHIFT 4 > > #define MSI_CAP_MME_MASK (7 << MSI_CAP_MME_SHIFT) > > #define MSI_MESSAGE_ADDR_L32 0x54 > > > > Acked-by: Joao Pinto Acked-by: Jingoo Han Best regards, Jingoo Han
Re: [PATCH v6 01/18] PCI: dwc: Use the DMA-API to get the MSI address
On Wednesday, December 20, 2017 2:10 PM, Joao Pinto wrote:
>
> Hi Niklas,
>
> Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> > Use the DMA-API to get the MSI address. This address will be written to
> > our PCI config space and to the register which determines which AXI
> > address the DWC IP will spoof for incoming MSI irqs.
> >
> > Since it is a PCIe endpoint device, rather than the CPU, that is
> supposed
> > to write to the MSI address, the proper way to get the MSI address is by
> > using the DMA API, not by using virt_to_phys().
> >
> > Using virt_to_phys() might work on some systems, but using the DMA API
> > should work on all systems.
> >
> > This is essentially the same thing as allocating a buffer in a driver
> > to which the endpoint will write to. To do this, we use the DMA API.
> >
> > Signed-off-by: Niklas Cassel <niklas.cas...@axis.com>
> > ---
> > drivers/pci/dwc/pcie-designware-host.c | 15 ---
> > drivers/pci/dwc/pcie-designware.h | 3 ++-
> > 2 files changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pci/dwc/pcie-designware-host.c
> b/drivers/pci/dwc/pcie-designware-host.c
> > index 81e2157a7cfb..bf558df5b7b3 100644
> > --- a/drivers/pci/dwc/pcie-designware-host.c
> > +++ b/drivers/pci/dwc/pcie-designware-host.c
> > @@ -83,10 +83,19 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
> >
> > void dw_pcie_msi_init(struct pcie_port *pp)
> > {
> > + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > + struct device *dev = pci->dev;
> > + struct page *page;
> > u64 msi_target;
> >
> > - pp->msi_data = __get_free_pages(GFP_KERNEL, 0);
> > - msi_target = virt_to_phys((void *)pp->msi_data);
> > + page = alloc_page(GFP_KERNEL);
> > + pp->msi_data = dma_map_page(dev, page, 0, PAGE_SIZE,
> DMA_FROM_DEVICE);
> > + if (dma_mapping_error(dev, pp->msi_data)) {
> > + dev_err(dev, "failed to map MSI data\n");
> > + __free_page(page);
> > + return;
> > + }
> > + msi_target = (u64)pp->msi_data;
> >
> > /* program the msi_data */
> > dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_LO, 4,
> > @@ -187,7 +196,7 @@ static void dw_msi_setup_msg(struct pcie_port *pp,
> unsigned int irq, u32 pos)
> > if (pp->ops->get_msi_addr)
> > msi_target = pp->ops->get_msi_addr(pp);
> > else
> > - msi_target = virt_to_phys((void *)pp->msi_data);
> > + msi_target = (u64)pp->msi_data;
> >
> > msg.address_lo = (u32)(msi_target & 0x);
> > msg.address_hi = (u32)(msi_target >> 32 & 0x);
> > diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-
> designware.h
> > index e5d9d77b778e..ecdede68522a 100644
> > --- a/drivers/pci/dwc/pcie-designware.h
> > +++ b/drivers/pci/dwc/pcie-designware.h
> > @@ -14,6 +14,7 @@
> > #ifndef _PCIE_DESIGNWARE_H
> > #define _PCIE_DESIGNWARE_H
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -168,7 +169,7 @@ struct pcie_port {
> > const struct dw_pcie_host_ops *ops;
> > int msi_irq;
> > struct irq_domain *irq_domain;
> > - unsigned long msi_data;
> > + dma_addr_t msi_data;
> > DECLARE_BITMAP(msi_irq_in_use, MAX_MSI_IRQS);
> > };
> >
> >
>
> Makes total sense! Thanks.
>
> Acked-by: Joao Pinto <jpi...@synopsys.com>
Acked-by: Jingoo Han <jingooh...@gmail.com>
Best regards,
Jingoo Han
Re: [PATCH v6 01/18] PCI: dwc: Use the DMA-API to get the MSI address
On Wednesday, December 20, 2017 2:10 PM, Joao Pinto wrote:
>
> Hi Niklas,
>
> Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> > Use the DMA-API to get the MSI address. This address will be written to
> > our PCI config space and to the register which determines which AXI
> > address the DWC IP will spoof for incoming MSI irqs.
> >
> > Since it is a PCIe endpoint device, rather than the CPU, that is
> supposed
> > to write to the MSI address, the proper way to get the MSI address is by
> > using the DMA API, not by using virt_to_phys().
> >
> > Using virt_to_phys() might work on some systems, but using the DMA API
> > should work on all systems.
> >
> > This is essentially the same thing as allocating a buffer in a driver
> > to which the endpoint will write to. To do this, we use the DMA API.
> >
> > Signed-off-by: Niklas Cassel
> > ---
> > drivers/pci/dwc/pcie-designware-host.c | 15 ---
> > drivers/pci/dwc/pcie-designware.h | 3 ++-
> > 2 files changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pci/dwc/pcie-designware-host.c
> b/drivers/pci/dwc/pcie-designware-host.c
> > index 81e2157a7cfb..bf558df5b7b3 100644
> > --- a/drivers/pci/dwc/pcie-designware-host.c
> > +++ b/drivers/pci/dwc/pcie-designware-host.c
> > @@ -83,10 +83,19 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
> >
> > void dw_pcie_msi_init(struct pcie_port *pp)
> > {
> > + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > + struct device *dev = pci->dev;
> > + struct page *page;
> > u64 msi_target;
> >
> > - pp->msi_data = __get_free_pages(GFP_KERNEL, 0);
> > - msi_target = virt_to_phys((void *)pp->msi_data);
> > + page = alloc_page(GFP_KERNEL);
> > + pp->msi_data = dma_map_page(dev, page, 0, PAGE_SIZE,
> DMA_FROM_DEVICE);
> > + if (dma_mapping_error(dev, pp->msi_data)) {
> > + dev_err(dev, "failed to map MSI data\n");
> > + __free_page(page);
> > + return;
> > + }
> > + msi_target = (u64)pp->msi_data;
> >
> > /* program the msi_data */
> > dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_LO, 4,
> > @@ -187,7 +196,7 @@ static void dw_msi_setup_msg(struct pcie_port *pp,
> unsigned int irq, u32 pos)
> > if (pp->ops->get_msi_addr)
> > msi_target = pp->ops->get_msi_addr(pp);
> > else
> > - msi_target = virt_to_phys((void *)pp->msi_data);
> > + msi_target = (u64)pp->msi_data;
> >
> > msg.address_lo = (u32)(msi_target & 0x);
> > msg.address_hi = (u32)(msi_target >> 32 & 0x);
> > diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-
> designware.h
> > index e5d9d77b778e..ecdede68522a 100644
> > --- a/drivers/pci/dwc/pcie-designware.h
> > +++ b/drivers/pci/dwc/pcie-designware.h
> > @@ -14,6 +14,7 @@
> > #ifndef _PCIE_DESIGNWARE_H
> > #define _PCIE_DESIGNWARE_H
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -168,7 +169,7 @@ struct pcie_port {
> > const struct dw_pcie_host_ops *ops;
> > int msi_irq;
> > struct irq_domain *irq_domain;
> > - unsigned long msi_data;
> > + dma_addr_t msi_data;
> > DECLARE_BITMAP(msi_irq_in_use, MAX_MSI_IRQS);
> > };
> >
> >
>
> Makes total sense! Thanks.
>
> Acked-by: Joao Pinto
Acked-by: Jingoo Han
Best regards,
Jingoo Han
Re: [PATCH] PCI: dwc: designware: don't sleep in atomic context
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 > --- > 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
Re: [PATCH] PCI: dwc: designware: don't sleep in atomic context
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 > --- > 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
Re: [PATCH] PCI: designware: move dw_pcie_iatu_unroll_enabled to pcie-designware.c
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
> ---
> 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
Re: [PATCH] PCI: designware: move dw_pcie_iatu_unroll_enabled to pcie-designware.c
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
> ---
> 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
Re: [RFC 2/2] pci: dwc: pci-exynos: add the codes to support the exynos5433
On Thursday, December 21, 2017 11:13 AM, Jingoo Han wrote:
> On Thursday, December 21, 2017 7:14 AM, Jaehoon Chung wrote:
> >
> > Exynos5433 has the PCIe for WiFi.
> > Added the codes relevant to PCIe for supporting the exynos5433.
> > Also changed the binding documentation name to
> > 'samsung,exynos-pcie.txt'.
> > (It's not only exynos5440 anymore.)
> >
>
> I have no objection.
> However, I added some comments about Exynos5440.
>
> > Signed-off-by: Jaehoon Chung <jh80.ch...@samsung.com>
> > ---
> > ...exynos5440-pcie.txt => samsung,exynos-pcie.txt} | 2 +-
> > drivers/pci/dwc/pci-exynos.c | 183
> -
> > 2 files changed, 144 insertions(+), 41 deletions(-)
> > rename Documentation/devicetree/bindings/pci/{samsung,exynos5440-
> pcie.txt
> > => samsung,exynos-pcie.txt} (97%)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> > pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.txt
> > similarity index 97%
> > rename from Documentation/devicetree/bindings/pci/samsung,exynos5440-
> > pcie.txt
> > rename to Documentation/devicetree/bindings/pci/samsung,exynos-pcie.txt
> > index 34a11bfbfb60..958dcc150505 100644
> > --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.txt
> > @@ -4,7 +4,7 @@ This PCIe host controller is based on the Synopsys
> > DesignWare PCIe IP
> > and thus inherits all the common properties defined in designware-
> > pcie.txt.
> >
> > Required properties:
> > -- compatible: "samsung,exynos5440-pcie"
> > +- compatible: "samsung,exynos5440-pcie" or "samsung,exynos5433-pcie"
> > - reg: base addresses and lengths of the PCIe controller,
> > the PHY controller, additional register for the PHY controller.
> > (Registers for the PHY controller are DEPRECATED.
> > diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-exynos.c
> > index 5596fdedbb94..8dee2e90347e 100644
> > --- a/drivers/pci/dwc/pci-exynos.c
> > +++ b/drivers/pci/dwc/pci-exynos.c
> > @@ -40,6 +40,8 @@
> > #define PCIE_IRQ_SPECIAL 0x008
> > #define PCIE_IRQ_EN_PULSE 0x00c
> > #define PCIE_IRQ_EN_LEVEL 0x010
> > +#define PCIE_SW_WAKE 0x018
> > +#define PCIE_BUS_ENBIT(1)
> > #define IRQ_MSI_ENABLE BIT(2)
> > #define PCIE_IRQ_EN_SPECIAL0x014
> > #define PCIE_PWR_RESET 0x018
> > @@ -49,7 +51,8 @@
> > #define PCIE_NONSTICKY_RESET 0x024
> > #define PCIE_APP_INIT_RESET0x028
> > #define PCIE_APP_LTSSM_ENABLE 0x02c
> > -#define PCIE_ELBI_RDLH_LINKUP 0x064
> > +#define PCIE_ELBI_RDLH_LINKUP 0x074
>
> The address of this register should be 0x064 for exynos5440.
> Howe about the following?
>
> +#define EXYNOS5440_PCIE_ELBI_RDLH_LINKUP 0x064
> +#define PCIE_ELBI_RDLH_LINKUP0x074
>
> Or you can add the following.
>
> /* Exynos5440 PCIe ELBI registers */
> #define EXYNOS5440_PCIE_ELBI_RDLH_LINKUP 0x064
>
> > +#define PCIE_ELBI_XMLH_LINKUP BIT(4)
> > #define PCIE_ELBI_LTSSM_ENABLE 0x1
> > #define PCIE_ELBI_SLV_AWMISC 0x11c
> > #define PCIE_ELBI_SLV_ARMISC 0x120
> > @@ -94,6 +97,10 @@
> > #define PCIE_PHY_TRSV3_PD_TSV BIT(7)
> > #define PCIE_PHY_TRSV3_LVCC0x31c
> >
> > +/* DBI register */
> > +#define PCIE_MISC_CONTROL_1_OFF0x8BC
> > +#define DBI_RO_WR_EN BIT(0)
> > +
> > struct exynos_pcie_mem_res {
> > void __iomem *elbi_base; /* DT 0th resource: PCIe CTRL */
> > void __iomem *phy_base;/* DT 1st resource: PHY CTRL */
> > @@ -221,6 +228,96 @@ static const struct exynos_pcie_ops
> > exynos5440_pcie_ops = {
> > .deinit_clk_resources = exynos5440_pcie_deinit_clk_resources,
> > };
> >
> > +static int exynos5433_pcie_get_mem_resources(struct platform_device
> *pdev,
> > +struct exynos_pcie *ep)
> > +{
> > + struct dw_pcie *pci = ep->pci;
> > + struct device *dev = pci->dev;
> > + struct resource *res;
> > +
> > + ep->mem_res = devm_kzalloc(dev, sizeof(*ep->mem_res), GFP_KERNEL);
> > + if (!ep->mem_res)
> >
Re: [RFC 2/2] pci: dwc: pci-exynos: add the codes to support the exynos5433
On Thursday, December 21, 2017 11:13 AM, Jingoo Han wrote:
> On Thursday, December 21, 2017 7:14 AM, Jaehoon Chung wrote:
> >
> > Exynos5433 has the PCIe for WiFi.
> > Added the codes relevant to PCIe for supporting the exynos5433.
> > Also changed the binding documentation name to
> > 'samsung,exynos-pcie.txt'.
> > (It's not only exynos5440 anymore.)
> >
>
> I have no objection.
> However, I added some comments about Exynos5440.
>
> > Signed-off-by: Jaehoon Chung
> > ---
> > ...exynos5440-pcie.txt => samsung,exynos-pcie.txt} | 2 +-
> > drivers/pci/dwc/pci-exynos.c | 183
> -
> > 2 files changed, 144 insertions(+), 41 deletions(-)
> > rename Documentation/devicetree/bindings/pci/{samsung,exynos5440-
> pcie.txt
> > => samsung,exynos-pcie.txt} (97%)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-
> > pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.txt
> > similarity index 97%
> > rename from Documentation/devicetree/bindings/pci/samsung,exynos5440-
> > pcie.txt
> > rename to Documentation/devicetree/bindings/pci/samsung,exynos-pcie.txt
> > index 34a11bfbfb60..958dcc150505 100644
> > --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.txt
> > @@ -4,7 +4,7 @@ This PCIe host controller is based on the Synopsys
> > DesignWare PCIe IP
> > and thus inherits all the common properties defined in designware-
> > pcie.txt.
> >
> > Required properties:
> > -- compatible: "samsung,exynos5440-pcie"
> > +- compatible: "samsung,exynos5440-pcie" or "samsung,exynos5433-pcie"
> > - reg: base addresses and lengths of the PCIe controller,
> > the PHY controller, additional register for the PHY controller.
> > (Registers for the PHY controller are DEPRECATED.
> > diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-exynos.c
> > index 5596fdedbb94..8dee2e90347e 100644
> > --- a/drivers/pci/dwc/pci-exynos.c
> > +++ b/drivers/pci/dwc/pci-exynos.c
> > @@ -40,6 +40,8 @@
> > #define PCIE_IRQ_SPECIAL 0x008
> > #define PCIE_IRQ_EN_PULSE 0x00c
> > #define PCIE_IRQ_EN_LEVEL 0x010
> > +#define PCIE_SW_WAKE 0x018
> > +#define PCIE_BUS_ENBIT(1)
> > #define IRQ_MSI_ENABLE BIT(2)
> > #define PCIE_IRQ_EN_SPECIAL0x014
> > #define PCIE_PWR_RESET 0x018
> > @@ -49,7 +51,8 @@
> > #define PCIE_NONSTICKY_RESET 0x024
> > #define PCIE_APP_INIT_RESET0x028
> > #define PCIE_APP_LTSSM_ENABLE 0x02c
> > -#define PCIE_ELBI_RDLH_LINKUP 0x064
> > +#define PCIE_ELBI_RDLH_LINKUP 0x074
>
> The address of this register should be 0x064 for exynos5440.
> Howe about the following?
>
> +#define EXYNOS5440_PCIE_ELBI_RDLH_LINKUP 0x064
> +#define PCIE_ELBI_RDLH_LINKUP0x074
>
> Or you can add the following.
>
> /* Exynos5440 PCIe ELBI registers */
> #define EXYNOS5440_PCIE_ELBI_RDLH_LINKUP 0x064
>
> > +#define PCIE_ELBI_XMLH_LINKUP BIT(4)
> > #define PCIE_ELBI_LTSSM_ENABLE 0x1
> > #define PCIE_ELBI_SLV_AWMISC 0x11c
> > #define PCIE_ELBI_SLV_ARMISC 0x120
> > @@ -94,6 +97,10 @@
> > #define PCIE_PHY_TRSV3_PD_TSV BIT(7)
> > #define PCIE_PHY_TRSV3_LVCC0x31c
> >
> > +/* DBI register */
> > +#define PCIE_MISC_CONTROL_1_OFF0x8BC
> > +#define DBI_RO_WR_EN BIT(0)
> > +
> > struct exynos_pcie_mem_res {
> > void __iomem *elbi_base; /* DT 0th resource: PCIe CTRL */
> > void __iomem *phy_base;/* DT 1st resource: PHY CTRL */
> > @@ -221,6 +228,96 @@ static const struct exynos_pcie_ops
> > exynos5440_pcie_ops = {
> > .deinit_clk_resources = exynos5440_pcie_deinit_clk_resources,
> > };
> >
> > +static int exynos5433_pcie_get_mem_resources(struct platform_device
> *pdev,
> > +struct exynos_pcie *ep)
> > +{
> > + struct dw_pcie *pci = ep->pci;
> > + struct device *dev = pci->dev;
> > + struct resource *res;
> > +
> > + ep->mem_res = devm_kzalloc(dev, sizeof(*ep->mem_res), GFP_KERNEL);
> > + if (!ep->mem_res)
> > + return -ENOMEM;
> >
Re: [RFC 2/2] pci: dwc: pci-exynos: add the codes to support the exynos5433
deassert_core_reset(ep);
}
> + /*
> + * Enable DBI_RO_WR_EN bit.
> + * - When set to 1, some RO and HWinit bits are wriatble from
> + * the local application through the DBI.
> + */
> + dw_pcie_writel_dbi(pci, PCIE_MISC_CONTROL_1_OFF, DBI_RO_WR_EN);
>
> - exynos_pcie_deassert_core_reset(ep);
> dw_pcie_setup_rc(pp);
> exynos_pcie_assert_reset(ep);
>
> @@ -472,16 +570,6 @@ static void exynos_pcie_clear_irq_pulse(struct
> exynos_pcie *ep)
> exynos_pcie_writel(ep->mem_res->elbi_base, val, PCIE_IRQ_PULSE);
> }
>
> -static void exynos_pcie_enable_irq_pulse(struct exynos_pcie *ep)
> -{
> - u32 val;
> -
> - /* enable INTX interrupt */
> - val = IRQ_INTA_ASSERT | IRQ_INTB_ASSERT |
> - IRQ_INTC_ASSERT | IRQ_INTD_ASSERT;
> - exynos_pcie_writel(ep->mem_res->elbi_base, val, PCIE_IRQ_EN_PULSE);
> -}
> -
> static irqreturn_t exynos_pcie_irq_handler(int irq, void *arg)
> {
> struct exynos_pcie *ep = arg;
> @@ -513,9 +601,16 @@ static void exynos_pcie_msi_init(struct exynos_pcie
> *ep)
> exynos_pcie_writel(ep->mem_res->elbi_base, val, PCIE_IRQ_EN_LEVEL);
> }
>
> -static void exynos_pcie_enable_interrupts(struct exynos_pcie *ep)
> +static void exynos_pcie_enable_irq_pulse(struct exynos_pcie *ep)
> {
> - exynos_pcie_enable_irq_pulse(ep);
> + u32 val;
> +
> + val = IRQ_INTA_ASSERT | IRQ_INTB_ASSERT |
> + IRQ_INTC_ASSERT | IRQ_INTD_ASSERT;
> + exynos_pcie_writel(ep->mem_res->elbi_base, val, PCIE_IRQ_EN_PULSE);
> +
> + exynos_pcie_writel(ep->mem_res->elbi_base, 0, PCIE_IRQ_EN_LEVEL);
> + exynos_pcie_writel(ep->mem_res->elbi_base, 0, PCIE_IRQ_EN_SPECIAL);
Good.
>
> if (IS_ENABLED(CONFIG_PCI_MSI))
> exynos_pcie_msi_init(ep);
> @@ -575,10 +670,8 @@ static int exynos_pcie_link_up(struct dw_pcie *pci)
> u32 val;
>
> val = exynos_pcie_readl(ep->mem_res->elbi_base,
> PCIE_ELBI_RDLH_LINKUP);
> - if (val == PCIE_ELBI_LTSSM_ENABLE)
> - return 1;
Exynos5440 uses 'PCIE_ELBI_LTSSM_ENABLE'.
Can you keep this code for Exyno5440?
This register can be added as below.
/* Exynos5440 PCIe ELBI registers */
#define EXYNOS5440_PCIE_ELBI_RDLH_LINKUP0x064
#define EXYNOS5440_PCIE_ELBI_LTSSM_ENABLE BIT(0)
Best regards,
Jingoo Han
>
> - return 0;
> + return (val & PCIE_ELBI_XMLH_LINKUP);
> }
>
> static int exynos_pcie_host_init(struct pcie_port *pp)
> @@ -587,7 +680,7 @@ static int exynos_pcie_host_init(struct pcie_port *pp)
> struct exynos_pcie *ep = to_exynos_pcie(pci);
>
> exynos_pcie_establish_link(ep);
> - exynos_pcie_enable_interrupts(ep);
> + exynos_pcie_enable_irq_pulse(ep);
>
> return 0;
> }
> @@ -608,8 +701,11 @@ static int __init exynos_add_pcie_port(struct
> exynos_pcie *ep,
>
> pp->irq = platform_get_irq(pdev, 1);
> if (pp->irq < 0) {
> - dev_err(dev, "failed to get irq\n");
> - return pp->irq;
> + pp->irq = platform_get_irq_byname(pdev, "intr");
> + if (pp->irq < 0) {
> + dev_err(dev, "failed to get irq\n");
> + return pp->irq;
> + }
> }
> ret = devm_request_irq(dev, pp->irq, exynos_pcie_irq_handler,
> IRQF_SHARED, "exynos-pcie", ep);
> @@ -678,13 +774,23 @@ static int __init exynos_pcie_probe(struct
> platform_device *pdev)
>
> ep->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
>
> - /* Assume that controller doesn't use the PHY framework */
> - ep->using_phy = false;
> + /*
> + * In case of Exynos5440,
> + * Assume that controller doesn't use the PHY frameork.
> + * Other SoCs might be used the PHY framework.
> + */
> +
> + if (of_device_is_compatible(np, "samsung,exynos5440-pcie"))
> + ep->using_phy = false;
>
> - ep->phy = devm_of_phy_get(dev, np, NULL);
> + ep->phy = devm_of_phy_get(dev, np, "pcie-phy");
> if (IS_ERR(ep->phy)) {
> if (PTR_ERR(ep->phy) == -EPROBE_DEFER)
> return PTR_ERR(ep->phy);
> + if (!of_device_is_compatible(np, "samsung,exynos5440-pcie"))
> {
> + dev_err(dev, "Can't find the pcie-phy\n");
> + return PTR_ERR(ep->phy);
> + }
> dev_warn(dev, "Use the 'phy' property. Current DT of pci-
> exynos was deprecated!!\n");
> } else
> ep->using_phy = true;
> @@ -734,23 +840,20 @@ static int __exit exynos_pcie_remove(struct
> platform_device *pdev)
> static const struct of_device_id exynos_pcie_of_match[] = {
> {
> .compatible = "samsung,exynos5440-pcie",
> - .data = _pcie_ops
> + .data = _pcie_ops,
> + }, {
> + .compatible = "samsung,exynos5433-pcie",
> + .data = _pcie_ops,
> },
> {},
> };
>
> static struct platform_driver exynos_pcie_driver = {
> + .probe = exynos_pcie_probe,
> .remove = __exit_p(exynos_pcie_remove),
> .driver = {
> .name = "exynos-pcie",
> .of_match_table = exynos_pcie_of_match,
> },
> };
> -
> -/* Exynos PCIe driver does not allow module unload */
> -
> -static int __init exynos_pcie_init(void)
> -{
> - return platform_driver_probe(_pcie_driver,
> exynos_pcie_probe);
> -}
> -subsys_initcall(exynos_pcie_init);
> +builtin_platform_driver(exynos_pcie_driver);
> --
> 2.15.1
