* [PATCH 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Russell King @ 2017-12-20 23:12 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo, Stefan Agner,
Andrew Lunn, Florian Fainelli, Linus Walleij
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171220231108.GJ10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
The 88e1545 PHY has its interrupts wired to the VF610, so we might as
well use them.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
This is certainly not correct, as all PHYs on this device share the
same interrupt line, but we can't specify the pinmux settings
individually on each PHY. How should this be handled?
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index 782b69a3acdf..d6786c5d0109 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -312,12 +312,20 @@
#size-cells = <0>;
switch2phy0: phy@0 {
+ interrupt-parent = <&gpio0>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mv88e1545>;
};
switch2phy1: phy@1 {
+ interrupt-parent = <&gpio0>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
reg = <1>;
};
switch2phy2: phy@2 {
+ interrupt-parent = <&gpio0>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
reg = <2>;
};
};
@@ -488,6 +496,12 @@
>;
};
+ pinctrl_mv88e1545: pinctrl-mv88e1545 {
+ fsl,pins = <
+ VF610_PAD_PTB0__GPIO_22 0x219d
+ >;
+ };
+
pinctrl_pca9554_22: pinctrl-pca95540-22 {
fsl,pins = <
VF610_PAD_PTB28__GPIO_98 0x219d
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v6 00/18] dwc MSI fixes, ARTPEC-6 EP mode support, ARTPEC-7 SoC support
From: Niklas Cassel @ 2017-12-20 23:22 UTC (permalink / raw)
To: Joao Pinto
Cc: Lorenzo Pieralisi, Jingoo Han, linux-arm-kernel, linux-pci,
linux-omap, devicetree, linux-kernel, gustavo.pimentel, kishon
In-Reply-To: <32f6e02c-4230-9222-0ee1-54a045e78bd5@synopsys.com>
On Wed, Dec 20, 2017 at 07:47:41PM +0000, Joao Pinto wrote:
>
> Hello to all,
>
> Às 5:34 PM de 12/20/2017, Lorenzo Pieralisi escreveu:
> > On Wed, Dec 20, 2017 at 12:29:21AM +0100, Niklas Cassel wrote:
> >> This is a series that adds:
> >> - PCI endpoint mode support in the ARTPEC-6 driver.
> >> - ARTPEC-7 SoC support in the ARTPEC-6 driver (the SoCs are very similar).
> >> - Small fixes for MSI in designware-ep and designware-host,
> >> needed to get endpoint mode support working for ARTPEC-6.
> >> - Cleanups in pci-dra7xx to better prepare for endpoint mode in other
> >> DWC based PCIe drivers.
> >
> > Joao, Jingoo,
> >
> > Gustavo tested the series and Kishon ACK'ed the relevant patches,
> > I need your ACKs on designware patches to queue this series for
> > v4.16.
> >
> > I am away from tomorrow (noon) till beginning of January which means
> > that either I queue this series tomorrow or at -rc6, please do
> > chime in if you can.
>
> Sorry, I have been a bit tied up! Already checked each patch related to DWC.
> Could anyone from artpec finish the revision, since there are some patches
> related to that SoC?
Thanks for looking at the patches.
Thanks to everyone that has helped in any way.
Since I am the maintainer for pcie-artpec6.c
(at least according to MAINTAINERS ;)),
I'm supposing that my sign-off will suffice.
Regards,
Niklas
^ permalink raw reply
* Re: [PATCH v16 0/5] ZII RAVE platform driver
From: Andrey Smirnov @ 2017-12-21 0:20 UTC (permalink / raw)
To: Philippe Ombredanne
Cc: Lee Jones, Pavel Machek, Greg Kroah-Hartman, Chris Healy,
Andy Shevchenko, Lucas Stach, Nikita Yushchenko, Guenter Roeck,
Rob Herring, Mark Rutland, Johan Hovold,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
Sebastian Reichel
In-Reply-To: <CAOFm3uHLT5R6SLYpRApFOOh4_=qrhc234EKfk1n-_3AGzgN9RA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Dec 20, 2017 at 1:51 PM, Philippe Ombredanne
<pombredanne-od1rfyK75/E@public.gmane.org> wrote:
> Andrey,
>
> On Wed, Dec 20, 2017 at 9:45 PM, Andrey Smirnov
> <andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Everyone:
>>
>> This patch series is v16 of the driver for supervisory processor found
>> on RAVE series of devices from ZII. Supervisory processor is a PIC
>> microcontroller connected to various electrical subsystems on RAVE
>> devices whose firmware implements protocol to command/qery them.
>>
>> NOTE:
>>
>> * This driver dependends on crc_ccitt_false(), added by
>> 2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next', the patch
>> was pulled in by Andrew Morton and is currently avaiting users, so
>> this series might have to go in through Andrew's tree
>>
>> Changes since [v15]:
>>
>> - Adopted SPDX tags for licensing information per Philippe's
>> request
>
> Thank you for using the SPDX tags: you have my cheerful ack for the
> SPDX tags for the whole patch set
>
> There is one minor problem though: your comment style for the SPDX tag
> lines. Check Thomas doc patches and Linus comments on this topic: you
> should use // C++ style commnent in .c files and /* */ C-style
> comments in .h files.
>
> e.g. do not use this for a .c file:
>
>> +++ b/drivers/watchdog/rave-sp-wdt.c
>> @@ -0,0 +1,337 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>
> But this instead:
>
>> +++ b/drivers/watchdog/rave-sp-wdt.c
>> @@ -0,0 +1,337 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>
>
> Acked-by: Philippe Ombredanne <pombredanne-kIH2VFuay/A@public.gmane.org>
>
OK, good to know, will fix in v17 soon.
Thanks,
Andrey Smirnov
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: exynos: Use lower case hex addresses in node unit addresses
From: Chanwoo Choi @ 2017-12-21 0:51 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Marek Szyprowski, Andrzej Hajda,
Alim Akhtar, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171220192702.32515-1-krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Dear Krzysztof,
On 2017년 12월 21일 04:27, Krzysztof Kozlowski wrote:
> Convert all hex addresses in node unit addresses to lower case to
> fix warnings like:
> arch/arm64/boot/dts/exynos/exynos5433-tm2e.dtb: Warning (simple_bus_reg):
> Node /soc/video-scaler@13C00000 simple-bus unit address format error, expected "13c00000"
>
> Conversion was done using sed:
> $ sed -e 's/@\([a-zA-Z0-9_-]*\) {/@\L\1 {/' -i arch/arm64/boot/dts/exynos/*.dts*
>
> Signed-off-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 8 ++++----
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 4 ++--
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 1962b8074349..0ba5df825eff 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -994,7 +994,7 @@
> reg = <0x145f0000 0x1038>;
> };
>
> - gsc_0: video-scaler@13C00000 {
> + gsc_0: video-scaler@13c00000 {
> compatible = "samsung,exynos5433-gsc";
> reg = <0x13c00000 0x1000>;
> interrupts = <GIC_SPI 297 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1008,7 +1008,7 @@
> power-domains = <&pd_gscl>;
> };
>
> - gsc_1: video-scaler@13C10000 {
> + gsc_1: video-scaler@13c10000 {
> compatible = "samsung,exynos5433-gsc";
> reg = <0x13c10000 0x1000>;
> interrupts = <GIC_SPI 298 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1022,7 +1022,7 @@
> power-domains = <&pd_gscl>;
> };
>
> - gsc_2: video-scaler@13C20000 {
> + gsc_2: video-scaler@13c20000 {
> compatible = "samsung,exynos5433-gsc";
> reg = <0x13c20000 0x1000>;
> interrupts = <GIC_SPI 299 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1049,7 +1049,7 @@
> power-domains = <&pd_mscl>;
> };
>
> - mfc: codec@152E0000 {
> + mfc: codec@152e0000 {
> compatible = "samsung,exynos5433-mfc";
> reg = <0x152E0000 0x10000>;
> interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index 9a3fbed1765a..3504837b1d43 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -103,7 +103,7 @@
> #size-cells = <1>;
> ranges;
>
> - pdma0: pdma@10E10000 {
> + pdma0: pdma@10e10000 {
> compatible = "arm,pl330", "arm,primecell";
> reg = <0x10E10000 0x1000>;
> interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
> @@ -114,7 +114,7 @@
> #dma-requests = <32>;
> };
>
> - pdma1: pdma@10EB0000 {
> + pdma1: pdma@10eb0000 {
> compatible = "arm,pl330", "arm,primecell";
> reg = <0x10EB0000 0x1000>;
> interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
>
Looks good to me.
Reviewed-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] PCI: Mediatek: clear irq status after irq dispathed to avoid reentry
From: Bjorn Helgaas @ 2017-12-21 0:52 UTC (permalink / raw)
To: honghui.zhang-NuS5LvNUpcJWk0Htik3J/w
Cc: bhelgaas-hpIqsD4AKlfQT0dZR+AlfA,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
eddie.huang-NuS5LvNUpcJWk0Htik3J/w,
ryder.lee-NuS5LvNUpcJWk0Htik3J/w,
youlin.pei-NuS5LvNUpcJWk0Htik3J/w,
hongkun.cao-NuS5LvNUpcJWk0Htik3J/w,
sean.wang-NuS5LvNUpcJWk0Htik3J/w,
xinping.qian-NuS5LvNUpcJWk0Htik3J/w,
yt.shen-NuS5LvNUpcJWk0Htik3J/w, yong.wu-NuS5LvNUpcJWk0Htik3J/w,
Lorenzo Pieralisi
In-Reply-To: <1513738334-26213-1-git-send-email-honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
[+cc Lorenzo, please cc him on all drivers/{host,dwc,endpoint} material]
Please run "git log --oneline drivers/pci/host/pcie-mediatek.c" and
make yours match. Same capitalization, same sentence structure, etc.,
e.g.,
PCI: mediatek: Clear IRQ status ...
s/dispathed/dispatched/
s/irq/IRQ/ in the summary and all the English text below.
On Wed, Dec 20, 2017 at 10:52:14AM +0800, honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> There maybe a same irq reentry scenario after irq received in current
> irq handle flow:
> EP device PCIe host driver EP driver
> 1. issue an irq
> 2. received irq
> 3. clear irq status
> 4. dispatch irq
> 5. clear irq source
> The irq status was not successfully cleared at step 2 since the irq
> source was not cleared yet. So the PCIe host driver may receive the
> same irq after step 5. Then there's an irq reentry occurred.
> Even worse, if the reentry irq was not an irq that EP driver expected,
> it may not handle the irq. Then we may run into the dead loop from
By "dead loop" I assume you mean "infinite loop"? I don't think it's
a deadlock since nothing is waiting.
> step 2 to step 4.
> Clear the irq status after irq have been dispatched to avoid the irq
> reentry.
>
> Signed-off-by: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> drivers/pci/host/pcie-mediatek.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> index db93efd..3248771 100644
> --- a/drivers/pci/host/pcie-mediatek.c
> +++ b/drivers/pci/host/pcie-mediatek.c
> @@ -605,11 +605,11 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
>
> while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
> for_each_set_bit_from(bit, &status, PCI_NUM_INTX + INTX_SHIFT) {
> - /* Clear the INTx */
> - writel(1 << bit, port->base + PCIE_INT_STATUS);
> virq = irq_find_mapping(port->irq_domain,
> bit - INTX_SHIFT);
> generic_handle_irq(virq);
> + /* Clear the INTx */
> + writel(1 << bit, port->base + PCIE_INT_STATUS);
> }
> }
>
> @@ -619,10 +619,10 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
>
> while ((imsi_status = readl(port->base + PCIE_IMSI_STATUS))) {
> for_each_set_bit(bit, &imsi_status, MTK_MSI_IRQS_NUM) {
> - /* Clear the MSI */
> - writel(1 << bit, port->base + PCIE_IMSI_STATUS);
> virq = irq_find_mapping(port->msi_domain, bit);
> generic_handle_irq(virq);
> + /* Clear the MSI */
> + writel(1 << bit, port->base + PCIE_IMSI_STATUS);
> }
> }
> /* Clear MSI interrupt status */
> --
> 2.6.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: exynos: Fix typo in MSCL clock controller unit address
From: Chanwoo Choi @ 2017-12-21 0:54 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Marek Szyprowski, Andrzej Hajda,
Alim Akhtar, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171220192702.32515-2-krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On 2017년 12월 21일 04:27, Krzysztof Kozlowski wrote:
> Fix typo in unit address of MSCL clock controller (the reg entry is
> correct).
>
> Signed-off-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 0ba5df825eff..3e8311c60d1b 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -468,7 +468,7 @@
> clocks = <&xxti>, <&cmu_mif CLK_SCLK_BUS_PLL_ATLAS>;
> };
>
> - cmu_mscl: clock-controller@105d0000 {
> + cmu_mscl: clock-controller@150d0000 {
> compatible = "samsung,exynos5433-cmu-mscl";
> reg = <0x150d0000 0x1000>;
> #clock-cells = <1>;
>
Looks good to me.
Reviewed-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: soc: qcom: Add label for GLINK bindings
From: Bjorn Andersson @ 2017-12-21 1:35 UTC (permalink / raw)
To: Rob Herring
Cc: Chris Lew, andy.gross, david.brown, aneela, linux-arm-msm,
linux-remoteproc, linux-soc, devicetree, linux-kernel
In-Reply-To: <20171220183000.rhxgyikfqzxmqkjo@rob-hp-laptop>
On Wed 20 Dec 10:30 PST 2017, Rob Herring wrote:
> On Mon, Dec 18, 2017 at 02:02:09PM -0800, Chris Lew wrote:
> > Add a label property to identify the edge this node represents.
>
> Why does a user need to know this?
>
We have multiple remoteproc instances, each one having one or more
associated SMD or GLINK links (this node), exposing logical
communication channels. Some of these logical channels are exposed to
user space and we need a way to distinguish them there.
In the current implementation of SMD this value goes straight into an
sysfs attribute that we can use when writing udev rules and for the DIAG
implementation to pair up channels related to the same remoteproc. This
adds the equivalent information for glink-backed channels.
I'm therefor in favor of picking this patch.
Regards,
Bjorn
> >
> > Signed-off-by: Chris Lew <clew@codeaurora.org>
> > ---
> > Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> > index 9663cab52246..0b8cc533ca83 100644
> > --- a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> > @@ -10,6 +10,11 @@ edge.
> > Value type: <stringlist>
> > Definition: must be "qcom,glink-rpm"
> >
> > +- label:
> > + Usage: optional
> > + Value type: <string>
> > + Definition: should specify the subsystem name this edge corresponds to.
> > +
> > - interrupts:
> > Usage: required
> > Value type: <prop-encoded-array>
> > --
> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
^ permalink raw reply
* Re: [PATCH] PCI: Mediatek: clear irq status after irq dispathed to avoid reentry
From: Honghui Zhang @ 2017-12-21 1:37 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: bhelgaas-hpIqsD4AKlfQT0dZR+AlfA,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
eddie.huang-NuS5LvNUpcJWk0Htik3J/w,
ryder.lee-NuS5LvNUpcJWk0Htik3J/w,
youlin.pei-NuS5LvNUpcJWk0Htik3J/w,
hongkun.cao-NuS5LvNUpcJWk0Htik3J/w,
sean.wang-NuS5LvNUpcJWk0Htik3J/w,
xinping.qian-NuS5LvNUpcJWk0Htik3J/w,
yt.shen-NuS5LvNUpcJWk0Htik3J/w, yong.wu-NuS5LvNUpcJWk0Htik3J/w,
Lorenzo Pieralisi
In-Reply-To: <20171221005240.GC30595-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
On Wed, 2017-12-20 at 18:52 -0600, Bjorn Helgaas wrote:
> [+cc Lorenzo, please cc him on all drivers/{host,dwc,endpoint} material]
>
> Please run "git log --oneline drivers/pci/host/pcie-mediatek.c" and
> make yours match. Same capitalization, same sentence structure, etc.,
> e.g.,
>
> PCI: mediatek: Clear IRQ status ...
>
> s/dispathed/dispatched/
>
> s/irq/IRQ/ in the summary and all the English text below.
Thanks for your review and sorry for the mismatch, I will fix that in
next version.
>
> On Wed, Dec 20, 2017 at 10:52:14AM +0800, honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> > From: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >
> > There maybe a same irq reentry scenario after irq received in current
> > irq handle flow:
> > EP device PCIe host driver EP driver
> > 1. issue an irq
> > 2. received irq
> > 3. clear irq status
> > 4. dispatch irq
> > 5. clear irq source
> > The irq status was not successfully cleared at step 2 since the irq
> > source was not cleared yet. So the PCIe host driver may receive the
> > same irq after step 5. Then there's an irq reentry occurred.
> > Even worse, if the reentry irq was not an irq that EP driver expected,
> > it may not handle the irq. Then we may run into the dead loop from
>
> By "dead loop" I assume you mean "infinite loop"? I don't think it's
> a deadlock since nothing is waiting.
>
Yes, it should be "infinite loop", I will update the commit message in
next version.
thanks.
> > step 2 to step 4.
> > Clear the irq status after irq have been dispatched to avoid the irq
> > reentry.
> >
> > Signed-off-by: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > ---
> > drivers/pci/host/pcie-mediatek.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> > index db93efd..3248771 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -605,11 +605,11 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
> >
> > while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
> > for_each_set_bit_from(bit, &status, PCI_NUM_INTX + INTX_SHIFT) {
> > - /* Clear the INTx */
> > - writel(1 << bit, port->base + PCIE_INT_STATUS);
> > virq = irq_find_mapping(port->irq_domain,
> > bit - INTX_SHIFT);
> > generic_handle_irq(virq);
> > + /* Clear the INTx */
> > + writel(1 << bit, port->base + PCIE_INT_STATUS);
> > }
> > }
> >
> > @@ -619,10 +619,10 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
> >
> > while ((imsi_status = readl(port->base + PCIE_IMSI_STATUS))) {
> > for_each_set_bit(bit, &imsi_status, MTK_MSI_IRQS_NUM) {
> > - /* Clear the MSI */
> > - writel(1 << bit, port->base + PCIE_IMSI_STATUS);
> > virq = irq_find_mapping(port->msi_domain, bit);
> > generic_handle_irq(virq);
> > + /* Clear the MSI */
> > + writel(1 << bit, port->base + PCIE_IMSI_STATUS);
> > }
> > }
> > /* Clear MSI interrupt status */
> > --
> > 2.6.4
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/9] soc: brcmstb: biuctrl updates for 64-bit chips
From: Florian Fainelli @ 2017-12-21 1:38 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w
Cc: Rob Herring, Mark Rutland, Brian Norris, Gregory Fong,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE, open list
In-Reply-To: <20171219192247.29799-1-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Le 12/19/17 à 11:22, Florian Fainelli a écrit :
> Hi all,
>
> This patch series updates the Broadcom STB Bus Interface Unit controller to
> support newer chips such as 7260, 7268, 7271 and 7278. These chips require
> additional tuning in order to provide the expected bus throughput.
>
> In the process, we need to re-organize the common.c file a little bit in order
> to extract the family and product identifiers a little earlier.
>
> Finally, by moving the biuctrl initialization an early_initcall level, we can
> remove some code from the ARM-32bit machine descriptor file.
>
> Provided that we are happy with these changes, I would route them through my
> drivers/next branch and a subsequent Broadcom ARM SoC pull request.
>
> Thank you
>
> Changes in v2:
>
> - collect Rob's acked-by on the first patch
> - fixed the binding as suggested by Rob
>
> Florian Fainelli (9):
> dt-bindings: arm: Add entry for Broadcom Brahma-B53
> dt-bindings: arm: brcmstb: Correct BIUCTRL node documentation
> soc: brcmstb: Make CPU credit offset more parameterized
> soc: brcmstb: Correct CPU_CREDIT_REG offset for Brahma-B53 CPUs
> soc: brcmstb: biuctrl: Prepare for saving/restoring other registers
> soc: brcmstb: biuctrl: Wire-up new registers
> soc: brcmstb: biuctrl: Fine tune B53 MCP interface settings
> soc: brcmstb: Split initialization
> soc: brcmstb: biuctrl: Move to early_initcall
Series applied to drivers/next.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: samsung: document bindings for Midas family boards
From: Simon Shields @ 2017-12-21 1:42 UTC (permalink / raw)
To: Rob Herring
Cc: linux-samsung-soc, Kukjin Kim, Krzysztof Kozlowski, devicetree,
Marek Szyprowski, Bartłomiej Żołnierkiewicz
In-Reply-To: <20171220181759.6r4waz4seerh6q4i@rob-hp-laptop>
Hi Rob,
Thanks for the review.
On Wed, Dec 20, 2017 at 12:17:59PM -0600, Rob Herring wrote:
> On Mon, Dec 18, 2017 at 11:38:02PM +1100, Simon Shields wrote:
> > Document GT-I9300, GT-I9305, GT-N7100, and GT-N7105 bindings, along
> > with the shared "midas" binding.
> >
> > Signed-off-by: Simon Shields <simon@lineageos.org>
> > ---
> > Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt | 4 ++++
> > 1 file changed, 4 insertions(+)
>
> My comment on v2 remains.
Do you have any example of a better description? All the other ARM board
descriptions seem similarly terse.
Alternatively, maybe changing the compatible strings is a better
solution? "samsung,n710x" for t0, "samsung,i9300" for m0, and
"samsung,i9305" for m3?
Cheers,
Simon
^ permalink raw reply
* Re: [PATCH v3 2/4] ARM: dts: split trats2 DTS in preparation for midas boards
From: Simon Shields @ 2017-12-21 1:54 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, linux-samsung-soc, Kukjin Kim, devicetree,
Marek Szyprowski, Bartłomiej Żołnierkiewicz
In-Reply-To: <20171220181908.vl7jmcyrt7ow6rni@rob-hp-laptop>
Hi Rob,
On Wed, Dec 20, 2017 at 12:19:08PM -0600, Rob Herring wrote:
> On Wed, Dec 20, 2017 at 03:05:18PM +0100, Krzysztof Kozlowski wrote:
> > On Mon, Dec 18, 2017 at 1:38 PM, Simon Shields <simon@lineageos.org> wrote:
> > > The midas boards share a lot with trats2. Split the common parts
> > > out of trats2 into a common midas dtsi and a common "galaxy s3" dts.
> > >
> > > Signed-off-by: Simon Shields <simon@lineageos.org>
> > > ---
> > > arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi | 145 ++
> > > ...exynos4412-trats2.dts => exynos4412-midas.dtsi} | 117 +-
> > > arch/arm/boot/dts/exynos4412-trats2.dts | 1446 +-------------------
> > > 3 files changed, 184 insertions(+), 1524 deletions(-)
> > > create mode 100644 arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
> > > copy arch/arm/boot/dts/{exynos4412-trats2.dts => exynos4412-midas.dtsi} (92%)
> > > rewrite arch/arm/boot/dts/exynos4412-trats2.dts (97%)
> > >
> > > diff --git a/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi b/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
> > > new file mode 100644
> > > index 000000000000..2806236484a6
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
> > > @@ -0,0 +1,145 @@
> > > +/*
> > > + * Samsung's Exynos4412 based Galaxy S3 board device tree source
> > > + *
> > > + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> > > + * http://www.samsung.com
> > > + *
> > > + * Device tree source file for Samsung's Galaxy S3 boards which are based on
> > > + * Samsung's Exynos4412 SoC.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + */
> >
> > One new line to make it consistent with others.
>
> If you're going to change it, use an SPDX tag.
>
I initially did this in v2[1], but Krzysztof said to keep
the trats2 copyright header, since the galaxy-s3 dts is a
subset of the old trats2 DTS. Is adding the SPDX tag and
keeping the Samsung copyright stanza the preferred approach
here?
[1]: https://patchwork.kernel.org/patch/10111971/
> Rob
Cheers,
Simon
^ permalink raw reply
* [PATCH v2 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code
From: honghui.zhang-NuS5LvNUpcJWk0Htik3J/w @ 2017-12-21 2:08 UTC (permalink / raw)
To: joro-zLv9SwRftAIdnm+yROfE0A, lorenzo.pieralisi-5wv7dgnIgG8,
treding-DDmLM1+adcrQT0dZR+AlfA, mark.rutland-5wv7dgnIgG8,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w, robh-DgEjT+Ai2ygdnm+yROfE0A,
robin.murphy-5wv7dgnIgG8
Cc: catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
youlin.pei-NuS5LvNUpcJWk0Htik3J/w,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
kendrick.hsu-NuS5LvNUpcJWk0Htik3J/w,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, arnd-r2nGTMty4D4,
tfiga-hpIqsD4AKlfQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
eddie.huang-NuS5LvNUpcJWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
pebolle-IWqWACnzNjzz+pZb47iToQ,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
erin.lo-NuS5LvNUpcJWk0Htik3J/w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
djkurtz-hpIqsD4AKlfQT0dZR+AlfA, p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
l.stach-bIcnvbaLZ9MEGnE8C9+IrQ
From: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Two fixups for mediatek's host bridge:
The first patch fixup the IRQ handle routine to avoid IRQ reentry which
may exist for both MT2712 and MT7622.
The second patch fixup class type for MT7622.
Change Since v1:
- Add the second patch.
- Make the first patch's commit message more standard.
Honghui Zhang (2):
PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
PCI: mediatek: Fixup class type for MT7622
drivers/pci/host/pcie-mediatek.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
--
2.6.4
^ permalink raw reply
* [PATCH v2 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
From: honghui.zhang-NuS5LvNUpcJWk0Htik3J/w @ 2017-12-21 2:08 UTC (permalink / raw)
To: joro-zLv9SwRftAIdnm+yROfE0A, lorenzo.pieralisi-5wv7dgnIgG8,
treding-DDmLM1+adcrQT0dZR+AlfA, mark.rutland-5wv7dgnIgG8,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w, robh-DgEjT+Ai2ygdnm+yROfE0A,
robin.murphy-5wv7dgnIgG8
Cc: p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
pebolle-IWqWACnzNjzz+pZb47iToQ,
kendrick.hsu-NuS5LvNUpcJWk0Htik3J/w, arnd-r2nGTMty4D4,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, tfiga-hpIqsD4AKlfQT0dZR+AlfA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, djkurtz-hpIqsD4AKlfQT0dZR+AlfA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
l.stach-bIcnvbaLZ9MEGnE8C9+IrQ,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
eddie.huang-NuS5LvNUpcJWk0Htik3J/w,
youlin.pei-NuS5LvNUpcJWk0Htik3J/w, erin.lo-NuS5LvNUpcJWk0Htik3J/w,
Honghui Zhang
In-Reply-To: <1513822130-18213-1-git-send-email-honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
From: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
There maybe a same IRQ reentry scenario after IRQ received in current
IRQ handle flow:
EP device PCIe host driver EP driver
1. issue an IRQ
2. received IRQ
3. clear IRQ status
4. dispatch IRQ
5. clear IRQ source
The IRQ status was not successfully cleared at step 2 since the IRQ
source was not cleared yet. So the PCIe host driver may receive the
same IRQ after step 5. Then there's an IRQ reentry occurred.
Even worse, if the reentry IRQ was not an IRQ that EP driver expected,
it may not handle the IRQ. Then we may run into the infinite loop from
step 2 to step 4.
Clear the IRQ status after IRQ have been dispatched to avoid the IRQ
reentry.
Signed-off-by: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Acked-by: Ryder Lee <ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/pci/host/pcie-mediatek.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index db93efd..3248771 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -605,11 +605,11 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
for_each_set_bit_from(bit, &status, PCI_NUM_INTX + INTX_SHIFT) {
- /* Clear the INTx */
- writel(1 << bit, port->base + PCIE_INT_STATUS);
virq = irq_find_mapping(port->irq_domain,
bit - INTX_SHIFT);
generic_handle_irq(virq);
+ /* Clear the INTx */
+ writel(1 << bit, port->base + PCIE_INT_STATUS);
}
}
@@ -619,10 +619,10 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
while ((imsi_status = readl(port->base + PCIE_IMSI_STATUS))) {
for_each_set_bit(bit, &imsi_status, MTK_MSI_IRQS_NUM) {
- /* Clear the MSI */
- writel(1 << bit, port->base + PCIE_IMSI_STATUS);
virq = irq_find_mapping(port->msi_domain, bit);
generic_handle_irq(virq);
+ /* Clear the MSI */
+ writel(1 << bit, port->base + PCIE_IMSI_STATUS);
}
}
/* Clear MSI interrupt status */
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 2/2] PCI: mediatek: Fixup class type for MT7622
From: honghui.zhang-NuS5LvNUpcJWk0Htik3J/w @ 2017-12-21 2:08 UTC (permalink / raw)
To: joro-zLv9SwRftAIdnm+yROfE0A, lorenzo.pieralisi-5wv7dgnIgG8,
treding-DDmLM1+adcrQT0dZR+AlfA, mark.rutland-5wv7dgnIgG8,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w, robh-DgEjT+Ai2ygdnm+yROfE0A,
robin.murphy-5wv7dgnIgG8
Cc: catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
youlin.pei-NuS5LvNUpcJWk0Htik3J/w,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
kendrick.hsu-NuS5LvNUpcJWk0Htik3J/w,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, arnd-r2nGTMty4D4,
tfiga-hpIqsD4AKlfQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
eddie.huang-NuS5LvNUpcJWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
pebolle-IWqWACnzNjzz+pZb47iToQ,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
erin.lo-NuS5LvNUpcJWk0Htik3J/w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
djkurtz-hpIqsD4AKlfQT0dZR+AlfA, p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
l.stach-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <1513822130-18213-1-git-send-email-honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
From: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
The host bridge of MT7622 has hardware code the class code to an
arbitrary, meaningless value, fix that.
Signed-off-by: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/pci/host/pcie-mediatek.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index 3248771..ae8d367 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -1174,3 +1174,15 @@ static struct platform_driver mtk_pcie_driver = {
},
};
builtin_platform_driver(mtk_pcie_driver);
+
+/* The host bridge of MT7622 advertises the wrong device class. */
+static void mtk_fixup_class(struct pci_dev *dev)
+{
+ dev->class = PCI_CLASS_BRIDGE_PCI << 8;
+}
+
+/*
+ * The HW default value of vendor id and device id for mt7622 are 0x0e8d,
+ * 0x3258, which are arbitrary, meaningless values.
+ */
+DECLARE_PCI_FIXUP_EARLY(0x0e8d, 0x3258, mtk_fixup_class);
--
2.6.4
^ permalink raw reply related
* [PATCH v2 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code
From: honghui.zhang @ 2017-12-21 2:11 UTC (permalink / raw)
To: bhelgaas, matthias.bgg, linux-arm-kernel, linux-mediatek,
linux-pci, linux-kernel, devicetree, yingjoe.chen, eddie.huang,
ryder.lee, lorenzo.pieralisi
Cc: honghui.zhang, hongkun.cao, youlin.pei, yong.wu, yt.shen,
sean.wang, xinping.qian
From: Honghui Zhang <honghui.zhang@mediatek.com>
Two fixups for mediatek's host bridge:
The first patch fixup the IRQ handle routine to avoid IRQ reentry which
may exist for both MT2712 and MT7622.
The second patch fixup class type for MT7622.
Change Since v1:
- Add the second patch.
- Make the first patch's commit message more standard.
Honghui Zhang (2):
PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
PCI: mediatek: Fixup class type for MT7622
drivers/pci/host/pcie-mediatek.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
--
2.6.4
^ permalink raw reply
* [PATCH v2 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
From: honghui.zhang-NuS5LvNUpcJWk0Htik3J/w @ 2017-12-21 2:11 UTC (permalink / raw)
To: bhelgaas-hpIqsD4AKlfQT0dZR+AlfA,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
eddie.huang-NuS5LvNUpcJWk0Htik3J/w,
ryder.lee-NuS5LvNUpcJWk0Htik3J/w, lorenzo.pieralisi-5wv7dgnIgG8
Cc: honghui.zhang-NuS5LvNUpcJWk0Htik3J/w,
hongkun.cao-NuS5LvNUpcJWk0Htik3J/w,
youlin.pei-NuS5LvNUpcJWk0Htik3J/w, yong.wu-NuS5LvNUpcJWk0Htik3J/w,
yt.shen-NuS5LvNUpcJWk0Htik3J/w, sean.wang-NuS5LvNUpcJWk0Htik3J/w,
xinping.qian-NuS5LvNUpcJWk0Htik3J/w
In-Reply-To: <1513822277-18329-1-git-send-email-honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
From: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
There maybe a same IRQ reentry scenario after IRQ received in current
IRQ handle flow:
EP device PCIe host driver EP driver
1. issue an IRQ
2. received IRQ
3. clear IRQ status
4. dispatch IRQ
5. clear IRQ source
The IRQ status was not successfully cleared at step 2 since the IRQ
source was not cleared yet. So the PCIe host driver may receive the
same IRQ after step 5. Then there's an IRQ reentry occurred.
Even worse, if the reentry IRQ was not an IRQ that EP driver expected,
it may not handle the IRQ. Then we may run into the infinite loop from
step 2 to step 4.
Clear the IRQ status after IRQ have been dispatched to avoid the IRQ
reentry.
Signed-off-by: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Acked-by: Ryder Lee <ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/pci/host/pcie-mediatek.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index db93efd..3248771 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -605,11 +605,11 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
for_each_set_bit_from(bit, &status, PCI_NUM_INTX + INTX_SHIFT) {
- /* Clear the INTx */
- writel(1 << bit, port->base + PCIE_INT_STATUS);
virq = irq_find_mapping(port->irq_domain,
bit - INTX_SHIFT);
generic_handle_irq(virq);
+ /* Clear the INTx */
+ writel(1 << bit, port->base + PCIE_INT_STATUS);
}
}
@@ -619,10 +619,10 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
while ((imsi_status = readl(port->base + PCIE_IMSI_STATUS))) {
for_each_set_bit(bit, &imsi_status, MTK_MSI_IRQS_NUM) {
- /* Clear the MSI */
- writel(1 << bit, port->base + PCIE_IMSI_STATUS);
virq = irq_find_mapping(port->msi_domain, bit);
generic_handle_irq(virq);
+ /* Clear the MSI */
+ writel(1 << bit, port->base + PCIE_IMSI_STATUS);
}
}
/* Clear MSI interrupt status */
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 2/2] PCI: mediatek: Fixup class type for MT7622
From: honghui.zhang-NuS5LvNUpcJWk0Htik3J/w @ 2017-12-21 2:11 UTC (permalink / raw)
To: bhelgaas-hpIqsD4AKlfQT0dZR+AlfA,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
eddie.huang-NuS5LvNUpcJWk0Htik3J/w,
ryder.lee-NuS5LvNUpcJWk0Htik3J/w, lorenzo.pieralisi-5wv7dgnIgG8
Cc: honghui.zhang-NuS5LvNUpcJWk0Htik3J/w,
hongkun.cao-NuS5LvNUpcJWk0Htik3J/w,
youlin.pei-NuS5LvNUpcJWk0Htik3J/w, yong.wu-NuS5LvNUpcJWk0Htik3J/w,
yt.shen-NuS5LvNUpcJWk0Htik3J/w, sean.wang-NuS5LvNUpcJWk0Htik3J/w,
xinping.qian-NuS5LvNUpcJWk0Htik3J/w
In-Reply-To: <1513822277-18329-1-git-send-email-honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
From: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
The host bridge of MT7622 has hardware code the class code to an
arbitrary, meaningless value, fix that.
Signed-off-by: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/pci/host/pcie-mediatek.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index 3248771..ae8d367 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -1174,3 +1174,15 @@ static struct platform_driver mtk_pcie_driver = {
},
};
builtin_platform_driver(mtk_pcie_driver);
+
+/* The host bridge of MT7622 advertises the wrong device class. */
+static void mtk_fixup_class(struct pci_dev *dev)
+{
+ dev->class = PCI_CLASS_BRIDGE_PCI << 8;
+}
+
+/*
+ * The HW default value of vendor id and device id for mt7622 are 0x0e8d,
+ * 0x3258, which are arbitrary, meaningless values.
+ */
+DECLARE_PCI_FIXUP_EARLY(0x0e8d, 0x3258, mtk_fixup_class);
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code
From: Honghui Zhang @ 2017-12-21 2:13 UTC (permalink / raw)
To: joro-zLv9SwRftAIdnm+yROfE0A
Cc: mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, youlin.pei-NuS5LvNUpcJWk0Htik3J/w,
robh-DgEjT+Ai2ygdnm+yROfE0A, yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
treding-DDmLM1+adcrQT0dZR+AlfA, devicetree-u79uwXL29TY76Z2rM5mHXA,
kendrick.hsu-NuS5LvNUpcJWk0Htik3J/w,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, arnd-r2nGTMty4D4,
tfiga-hpIqsD4AKlfQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
eddie.huang-NuS5LvNUpcJWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
pebolle-IWqWACnzNjzz+pZb47iToQ,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
erin.lo-NuS5LvNUpcJWk0Htik3J/w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
djkurtz-hpIqsD4AKlfQT0dZR+AlfA, p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
l.stach-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <1513822130-18213-1-git-send-email-honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Thu, 2017-12-21 at 10:08 +0800, honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Two fixups for mediatek's host bridge:
> The first patch fixup the IRQ handle routine to avoid IRQ reentry which
> may exist for both MT2712 and MT7622.
> The second patch fixup class type for MT7622.
>
Sorry about the noise, to the wrong mail group, please ignore this.
thanks.
> Change Since v1:
> - Add the second patch.
> - Make the first patch's commit message more standard.
>
> Honghui Zhang (2):
> PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
> PCI: mediatek: Fixup class type for MT7622
>
> drivers/pci/host/pcie-mediatek.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v3 1/6] media: rc: update sunxi-ir driver to get base clock frequency from devicetree
From: Andi Shyti @ 2017-12-21 2:16 UTC (permalink / raw)
To: Philipp Rossak
Cc: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171219080747.4507-2-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Philipp,
On Tue, Dec 19, 2017 at 09:07:42AM +0100, Philipp Rossak wrote:
> This patch updates the sunxi-ir driver to set the base clock frequency from
> devicetree.
>
> This is necessary since there are different ir receivers on the
> market, that operate with different frequencies. So this value could be
> set if the attached ir receiver needs a different base clock frequency,
> than the default 8 MHz.
>
> Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
feel free to add
Reviewed-by: Andi Shyti <andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Andi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/3] media: V3s: Add support for Allwinner CSI.
From: Yong @ 2017-12-21 2:38 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
David S. Miller, Greg Kroah-Hartman, Hans Verkuil, Randy Dunlap,
Benoit Parrot, Stanimir Varbanov, Arnd Bergmann, Hugues Fruchet,
Philipp Zabel, Benjamin Gaignard, Ramesh Shanmugasundaram,
Yannick Fertre, Sakari Ailus, Rick Chang,
Linux Media Mailing List, devicetree
In-Reply-To: <CAGb2v65vSRs-OzR91VWG=LMk2z0y=f9CSSJm_3-U_ywyMidgaw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On Tue, 19 Dec 2017 18:35:49 +0800
Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> On Mon, Nov 13, 2017 at 3:30 PM, Yong Deng <yong.deng-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org> wrote:
> > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > and CSI1 is used for parallel interface. This is not documented in
> > datasheet but by testing and guess.
> >
> > This patch implement a v4l2 framework driver for it.
> >
> > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > ISP's support are not included in this patch.
> >
> > Signed-off-by: Yong Deng <yong.deng-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
> > ---
> > drivers/media/platform/Kconfig | 1 +
> > drivers/media/platform/Makefile | 2 +
> > drivers/media/platform/sunxi/sun6i-csi/Kconfig | 9 +
> > drivers/media/platform/sunxi/sun6i-csi/Makefile | 3 +
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 918 +++++++++++++++++++++
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 146 ++++
> > .../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 203 +++++
> > .../media/platform/sunxi/sun6i-csi/sun6i_video.c | 722 ++++++++++++++++
> > .../media/platform/sunxi/sun6i-csi/sun6i_video.h | 61 ++
> > 9 files changed, 2065 insertions(+)
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
> > create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
> >
>
> [...]
>
> > diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c b/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
> > new file mode 100644
> > index 0000000..0cebcbd
> > --- /dev/null
> > +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
>
> [...]
>
> > +/* -----------------------------------------------------------------------------
> > + * Media Operations
> > + */
> > +static int sun6i_video_formats_init(struct sun6i_video *video)
> > +{
> > + struct v4l2_subdev_mbus_code_enum mbus_code = { 0 };
> > + struct sun6i_csi *csi = video->csi;
> > + struct v4l2_format format;
> > + struct v4l2_subdev *subdev;
> > + u32 pad;
> > + const u32 *pixformats;
> > + int pixformat_count = 0;
> > + u32 subdev_codes[32]; /* subdev format codes, 32 should be enough */
> > + int codes_count = 0;
> > + int num_fmts = 0;
> > + int i, j;
> > +
> > + subdev = sun6i_video_remote_subdev(video, &pad);
> > + if (subdev == NULL)
> > + return -ENXIO;
> > +
> > + /* Get supported pixformats of CSI */
> > + pixformat_count = sun6i_csi_get_supported_pixformats(csi, &pixformats);
> > + if (pixformat_count <= 0)
> > + return -ENXIO;
> > +
> > + /* Get subdev formats codes */
> > + mbus_code.pad = pad;
> > + mbus_code.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> > + while (!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL,
> > + &mbus_code)) {
> > + if (codes_count >= ARRAY_SIZE(subdev_codes)) {
> > + dev_warn(video->csi->dev,
> > + "subdev_codes array is full!\n");
> > + break;
> > + }
> > + subdev_codes[codes_count] = mbus_code.code;
> > + codes_count++;
> > + mbus_code.index++;
> > + }
> > +
> > + if (!codes_count)
> > + return -ENXIO;
> > +
> > + /* Get supported formats count */
> > + for (i = 0; i < codes_count; i++) {
> > + for (j = 0; j < pixformat_count; j++) {
> > + if (!sun6i_csi_is_format_support(csi, pixformats[j],
> > + mbus_code.code)) {
>
> Bug here. You are testing against mbus_code.code, which would be whatever
> was leftover from the previous section. Instead you should be testing
> against subdev_codes[i], the list you just built.
>
> Without it, it won't get past this part of the code if the last enumerated
> media bus format isn't supported.
>
> > + continue;
> > + }
> > + num_fmts++;
> > + }
> > + }
> > +
> > + if (!num_fmts)
> > + return -ENXIO;
> > +
> > + video->num_formats = num_fmts;
> > + video->formats = devm_kcalloc(video->csi->dev, num_fmts,
> > + sizeof(struct sun6i_csi_format), GFP_KERNEL);
> > + if (!video->formats)
> > + return -ENOMEM;
> > +
> > + /* Get supported formats */
> > + num_fmts = 0;
> > + for (i = 0; i < codes_count; i++) {
> > + for (j = 0; j < pixformat_count; j++) {
> > + if (!sun6i_csi_is_format_support(csi, pixformats[j],
> > + mbus_code.code)) {
>
> Same here.
>
> This gets me past the enumeration part of things...
>
> > + continue;
> > + }
> > +
> > + video->formats[num_fmts].fourcc = pixformats[j];
> > + video->formats[num_fmts].mbus_code =
> > + mbus_code.code;
> > + video->formats[num_fmts].bpp =
> > + v4l2_pixformat_get_bpp(pixformats[j]);
> > + num_fmts++;
> > + }
> > + }
> > +
> > + /* setup default format */
> > + format.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> > + format.fmt.pix.width = 1280;
> > + format.fmt.pix.height = 720;
> > + format.fmt.pix.pixelformat = video->formats[0].fourcc;
> > + sun6i_video_set_fmt(video, &format);
>
> But my system crashes here within the OV5640 driver.
> So no tests about the actual functionality. This was on the Bananapi M3,
> which has an A83T SoC.
>
>
> In general I think you should make your driver much more noisy than it
> currently is. I spent the whole afternoon adding error messages and
> debug traces to narrow down the issue.
Sorry for making such a simple mistake.
>
> ChenYu
Thanks,
Yong
^ permalink raw reply
* Re: [PATCH v2 3/3] media: MAINTAINERS: add entries for Allwinner V3s CSI
From: Yong @ 2017-12-21 2:40 UTC (permalink / raw)
To: Sakari Ailus
Cc: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Greg Kroah-Hartman, David S. Miller, Hans Verkuil, Arnd Bergmann,
Hugues Fruchet, Yannick Fertre, Philipp Zabel, Benoit Parrot,
Benjamin Gaignard, Jean-Christophe Trotin,
Ramesh Shanmugasundaram, Minghsiu Tsai, Krzysztof Kozlowski,
Robert Jarzmik, linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171219114802.gi7db7xhm3eh4udt-S+BSfZ9RZZmRSg0ZkenSGLdO1Tsj/99ntUK59QYPAWc@public.gmane.org>
On Tue, 19 Dec 2017 13:48:03 +0200
Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org> wrote:
> On Thu, Jul 27, 2017 at 01:01:37PM +0800, Yong Deng wrote:
> > Signed-off-by: Yong Deng <yong.deng-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
> > ---
> > MAINTAINERS | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 9826a91..b91fa27 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -3686,6 +3686,14 @@ M: Jaya Kumar <jayakumar.alsa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > S: Maintained
> > F: sound/pci/cs5535audio/
> >
> > +CSI DRIVERS FOR ALLWINNER V3s
> > +M: Yong Deng <yong.deng-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
> > +L: linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > +T: git git://linuxtv.org/media_tree.git
> > +S: Maintained
> > +F: drivers/media/platform/sun6i-csi/
> > +F: Documentation/devicetree/bindings/media/sun6i-csi.txt
> > +
> > CW1200 WLAN driver
> > M: Solomon Peachy <pizza-pCgMCH4qpMRg9hUCZPvPmw@public.gmane.org>
> > S: Maintained
>
> Please squash to the driver patch. Thanks.
OK.
>
> --
> Sakari Ailus
> e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org
Thanks,
Yong
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Yong @ 2017-12-21 2:49 UTC (permalink / raw)
To: Sakari Ailus
Cc: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Greg Kroah-Hartman, David S. Miller, Hans Verkuil, Arnd Bergmann,
Hugues Fruchet, Yannick Fertre, Philipp Zabel, Benoit Parrot,
Benjamin Gaignard, Jean-Christophe Trotin,
Ramesh Shanmugasundaram, Minghsiu Tsai, Krzysztof Kozlowski,
Robert
In-Reply-To: <20171219115327.ofs5xwwimpn7x72n-S+BSfZ9RZZmRSg0ZkenSGLdO1Tsj/99ntUK59QYPAWc@public.gmane.org>
Hi,
On Tue, 19 Dec 2017 13:53:28 +0200
Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org> wrote:
> Hi Yong,
>
> On Thu, Jul 27, 2017 at 01:01:36PM +0800, Yong Deng wrote:
> > Add binding documentation for Allwinner V3s CSI.
> >
> > Signed-off-by: Yong Deng <yong.deng-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
>
> DT bindings should precede the driver.
OK.
>
> > ---
> > .../devicetree/bindings/media/sun6i-csi.txt | 49 ++++++++++++++++++++++
> > 1 file changed, 49 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > new file mode 100644
> > index 0000000..f8d83f6
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > @@ -0,0 +1,49 @@
> > +Allwinner V3s Camera Sensor Interface
> > +------------------------------
> > +
> > +Required properties:
> > + - compatible: value must be "allwinner,sun8i-v3s-csi"
>
> What are sun6i and sun8i? Is this device first present in sun6i SoCs,
> whereas you have only defined bindings for sun8i?
Yes, some sun6i SoCs has the almost same CSI module.
There is only V3s on my hand. So, I only tested it on V3s. But
some people work on the others.
>
> > + - reg: base address and size of the memory-mapped region.
> > + - interrupts: interrupt associated to this IP
> > + - clocks: phandles to the clocks feeding the CSI
> > + * ahb: the CSI interface clock
> > + * mod: the CSI module clock
> > + * ram: the CSI DRAM clock
> > + - clock-names: the clock names mentioned above
> > + - resets: phandles to the reset line driving the CSI
> > +
> > +- ports: A ports node with endpoint definitions as defined in
> > + Documentation/devicetree/bindings/media/video-interfaces.txt.
>
> Please document mandatory and optional endpoint properties relevant for the
> hardware.
I have added below commit in my v3:
Currently, the driver only support the parallel interface. So, a single port
node with one endpoint and parallel bus is supported.
>
> > +
> > +Example:
> > +
> > + csi1: csi@01cb4000 {
> > + compatible = "allwinner,sun8i-v3s-csi";
> > + reg = <0x01cb4000 0x1000>;
> > + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_CSI>,
> > + <&ccu CLK_CSI1_SCLK>,
> > + <&ccu CLK_DRAM_CSI>;
> > + clock-names = "ahb", "mod", "ram";
> > + resets = <&ccu RST_BUS_CSI>;
> > +
> > + port {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + /* Parallel bus endpoint */
> > + csi1_ep: endpoint {
> > + remote-endpoint = <&adv7611_ep>;
> > + bus-width = <16>;
> > + data-shift = <0>;
> > +
> > + /* If hsync-active/vsync-active are missing,
> > + embedded BT.656 sync is used */
> > + hsync-active = <0>; /* Active low */
> > + vsync-active = <0>; /* Active low */
> > + data-active = <1>; /* Active high */
> > + pclk-sample = <1>; /* Rising */
> > + };
> > + };
> > + };
> > +
>
> --
> Kind regards,
>
> Sakari Ailus
> e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org
Thanks,
Yong
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
From: Prabhakar Kushwaha @ 2017-12-21 5:14 UTC (permalink / raw)
To: Prabhakar Kushwaha,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Jagdish Gediya, Alison Wang
In-Reply-To: <1512013344-4042-2-git-send-email-prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
Hi Shawn,
> -----Original Message-----
> From: Prabhakar Kushwaha [mailto:prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org]
> Sent: Thursday, November 30, 2017 9:12 AM
> To: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org;
> shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Jagdish Gediya
> <jagdish.gediya-3arQi8VN3Tc@public.gmane.org>; Alison Wang <alison.wang-3arQi8VN3Tc@public.gmane.org>; Prabhakar
> Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
> Subject: [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
>
> From: Jagdish Gediya <jagdish.gediya-3arQi8VN3Tc@public.gmane.org>
>
> For the patch to update struct map_info's swap field based on device
> characteristics defined in device tree, big-endian parameter is added
> for LS1021A.
>
> Signed-off-by: Alison Wang <alison.wang-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Jagdish Gediya <jagdish.gediya-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
> ---
> Changes for v2: updated subject
>
> arch/arm/boot/dts/ls1021a.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 9319e1f..babb086 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -145,6 +145,7 @@
> ifc: ifc@1530000 {
> compatible = "fsl,ifc", "simple-bus";
> reg = <0x0 0x1530000 0x0 0x10000>;
> + big-endian;
> interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> --
> 1.9.1
There are no review comments on this patch.
Can you please accept this patch
--pk
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 2/2][v2] ARM: dts: ls1021aqds: Add nand node for ifc controller
From: Prabhakar Kushwaha @ 2017-12-21 5:14 UTC (permalink / raw)
To: Prabhakar Kushwaha,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Jagdish Gediya
In-Reply-To: <1512013344-4042-3-git-send-email-prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
Hi Shawn,
> -----Original Message-----
> From: Prabhakar Kushwaha [mailto:prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org]
> Sent: Thursday, November 30, 2017 9:12 AM
> To: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org;
> shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Prabhakar Kushwaha
> <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>; Jagdish Gediya <jagdish.gediya-3arQi8VN3Tc@public.gmane.org>
> Subject: [PATCH 2/2][v2] ARM: dts: ls1021aqds: Add nand node for ifc controller
>
> LS1021AQDS support NAND flash on IFC chip-select 2.
>
> So add NAND node in device tree for IFC controller.
>
> Signed-off-by: Jagdish Gediya <jagdish.gediya-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
> ---
> Changes for v2: updated subject
>
> arch/arm/boot/dts/ls1021a-qds.dts | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/ls1021a-qds.dts b/arch/arm/boot/dts/ls1021a-
> qds.dts
> index 9408753..2b37d04 100644
> --- a/arch/arm/boot/dts/ls1021a-qds.dts
> +++ b/arch/arm/boot/dts/ls1021a-qds.dts
> @@ -239,6 +239,11 @@
> device-width = <1>;
> };
>
> + nand@2,0 {
> + compatible = "fsl,ifc-nand";
> + reg = <0x2 0x0 0x10000>;
> + };
> +
> fpga: board-control@3,0 {
> #address-cells = <1>;
> #size-cells = <1>;
> --
There are no review comments on this patch.
Can you please accept this patch
--pk
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH] Documentation: binding: Update endianness usage
From: Prabhakar Kushwaha @ 2017-12-21 5:20 UTC (permalink / raw)
To: Prabhakar Kushwaha, Scott Wood,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: dedekind1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <HE1PR04MB124174461F845000614CDAA197320-6LN7OEpIatU9TB6uw0n1oM9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Hi Scott,
> -----Original Message-----
> From: devicetree-owner@vger.kernel.org [mailto:devicetree-
> owner@vger.kernel.org] On Behalf Of Prabhakar Kushwaha
> Sent: Wednesday, December 06, 2017 4:29 PM
> To: Scott Wood <oss@buserror.net>; linux-mtd@lists.infradead.org;
> devicetree@vger.kernel.org
> Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> Subject: RE: [PATCH] Documentation: binding: Update endianness usage
>
>
>
> > -----Original Message-----
> > From: Prabhakar Kushwaha
> > Sent: Wednesday, December 06, 2017 4:05 PM
> > To: 'Scott Wood' <oss@buserror.net>; linux-mtd@lists.infradead.org;
> > devicetree@vger.kernel.org
> > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > Subject: RE: [PATCH] Documentation: binding: Update endianness usage
> >
> >
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss@buserror.net]
> > > Sent: Wednesday, December 06, 2017 1:38 AM
> > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > mtd@lists.infradead.org; devicetree@vger.kernel.org
> > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > >
> > > On Tue, 2017-12-05 at 09:45 +0000, Prabhakar Kushwaha wrote:
> > > > > -----Original Message-----
> > > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > > Sent: Tuesday, December 05, 2017 8:16 AM
> > > > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > > > mtd@lists.infradead.org; devicetree@vger.kernel.org
> > > > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > > > >
> > > > > I now see your patch to of_flash_probe... where is the non-IFC-specific
> > > > > binding that says the *parent* of a CFI node should be looked at for this?
> > > > > Where in general are endian properties kept in the parent of the node
> with
> > > > > "reg"? The right answer is to add endianness to mtd-physmap.txt.
> > > > >
> > > >
> > > > Flashes are always littler endian.
> > >
> > > We wouldn't be having this discussion if that were true... This is about how
> > > it presents to the CPU, not about how the actual pins on the chip are
> > > numbered.
> > >
> >
> > Got your point :)
> >
> > > > It is because of IFC controller behavior, endianness is required.
> > > > So as per my understanding, this info should go in IFC binding.
> > >
> > > If the info should go in the IFC binding why is the code in a non-IFC-specific
> > > place?
> > >
> >
> > Now I understand your point.
> > So I should be moving endianness property detail in mtd-physmap.txt.
> >
> > Is my understanding correct?
> >
>
> A second thought,
> IFC binding was updated because there is no IFC-NOR driver. It uses generic Flash
> framework.
>
> I am just trying to get more understanding.
>
Do you have any comment/concern on this patch.
May I go ahead and request for the merger of updated patch i.e. https://patchwork.kernel.org/patch/10084331/
--prabhakar
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox