* [PATCH v2 3/3] media: MAINTAINERS: add entries for Allwinner V3s CSI
From: Yong @ 2017-12-21 2:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219114802.gi7db7xhm3eh4udt@valkosipuli.retiisi.org.uk>
On Tue, 19 Dec 2017 13:48:03 +0200
Sakari Ailus <sakari.ailus@iki.fi> wrote:
> On Thu, Jul 27, 2017 at 01:01:37PM +0800, Yong Deng wrote:
> > Signed-off-by: Yong Deng <yong.deng@magewell.com>
> > ---
> > 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@gmail.com>
> > S: Maintained
> > F: sound/pci/cs5535audio/
> >
> > +CSI DRIVERS FOR ALLWINNER V3s
> > +M: Yong Deng <yong.deng@magewell.com>
> > +L: linux-media at vger.kernel.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@shaftnet.org>
> > S: Maintained
>
> Please squash to the driver patch. Thanks.
OK.
>
> --
> Sakari Ailus
> e-mail: sakari.ailus at iki.fi
Thanks,
Yong
^ permalink raw reply
* [linux-sunxi] [PATCH v3 1/3] media: V3s: Add support for Allwinner CSI.
From: Yong @ 2017-12-21 2:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65vSRs-OzR91VWG=LMk2z0y=f9CSSJm_3-U_ywyMidgaw@mail.gmail.com>
Hi,
On Tue, 19 Dec 2017 18:35:49 +0800
Chen-Yu Tsai <wens@csie.org> wrote:
> On Mon, Nov 13, 2017 at 3:30 PM, Yong Deng <yong.deng@magewell.com> 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@magewell.com>
> > ---
> > 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
* [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: linux-arm-kernel
In-Reply-To: <20171219080747.4507-2-embed3d@gmail.com>
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@gmail.com>
feel free to add
Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
Andi
^ permalink raw reply
* [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: linux-arm-kernel
In-Reply-To: <1513822130-18213-1-git-send-email-honghui.zhang@mediatek.com>
On Thu, 2017-12-21 at 10:08 +0800, honghui.zhang at mediatek.com wrote:
> 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.
>
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
* [PATCH v2 2/2] PCI: mediatek: Fixup class type for MT7622
From: honghui.zhang at mediatek.com @ 2017-12-21 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513822277-18329-1-git-send-email-honghui.zhang@mediatek.com>
From: Honghui Zhang <honghui.zhang@mediatek.com>
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@mediatek.com>
---
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 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
From: honghui.zhang at mediatek.com @ 2017-12-21 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513822277-18329-1-git-send-email-honghui.zhang@mediatek.com>
From: Honghui Zhang <honghui.zhang@mediatek.com>
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@mediatek.com>
Acked-by: Ryder Lee <ryder.lee@mediatek.com>
---
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
^ permalink raw reply related
* [PATCH v2 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code
From: honghui.zhang at mediatek.com @ 2017-12-21 2:11 UTC (permalink / raw)
To: linux-arm-kernel
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 2/2] PCI: mediatek: Fixup class type for MT7622
From: honghui.zhang at mediatek.com @ 2017-12-21 2:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513822130-18213-1-git-send-email-honghui.zhang@mediatek.com>
From: Honghui Zhang <honghui.zhang@mediatek.com>
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@mediatek.com>
---
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 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
From: honghui.zhang at mediatek.com @ 2017-12-21 2:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513822130-18213-1-git-send-email-honghui.zhang@mediatek.com>
From: Honghui Zhang <honghui.zhang@mediatek.com>
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@mediatek.com>
Acked-by: Ryder Lee <ryder.lee@mediatek.com>
---
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
^ permalink raw reply related
* [PATCH v2 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code
From: honghui.zhang at mediatek.com @ 2017-12-21 2:08 UTC (permalink / raw)
To: linux-arm-kernel
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
* [GIT PULL] arm64: Updates of aarch64 DTS files for v4.15-next
From: Sean Wang @ 2017-12-21 2:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2f497c32-0947-8185-d794-50f3ba539e96@gmail.com>
Hi, Matthias
title and content seems not consistent, and the other git pull for armv7
does too.
Sean
On Wed, 2017-12-20 at 20:19 +0100, Matthias Brugger wrote:
> Hi Olof, hi Arnd,
>
> Please take the patches below into consideration.
>
> Thanks a lot,
> Matthias
>
> ---
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git
> tags/v4.15-next-dts32
>
> for you to fetch changes up to a227cf4dfd74a873857c9cc017100168d01539ed:
>
> dt-bindings: ARM: Mediatek: Fix ethsys documentation (2017-12-20 18:10:12 +0100)
>
> ----------------------------------------------------------------
> - add reset cells mt2701 and mt7623 ethsys
> - update mmc nodes for mt7623
> - mt7623 change mmc card detection pin to active low
> - mt7623 set unit address to lower case
>
> ----------------------------------------------------------------
> Mathieu Malaterre (1):
> arm: mt7: dts: Remove leading 0x and 0s from bindings notation
>
> Matthias Brugger (3):
> arm: dts: mt7623: Update ethsys binding
> arm: dts: mt2701: Add reset-cells
> dt-bindings: ARM: Mediatek: Fix ethsys documentation
>
> Sean Wang (2):
> arm: dts: mt7623: update mmc related nodes with the appropriate fallback
> arm: dts: mt7623: fix card detection issue on bananapi-r2
> Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
> arch/arm/boot/dts/mt2701.dtsi | 2 ++
> arch/arm/boot/dts/mt7623.dtsi | 5 +++--
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +-
> arch/arm/boot/dts/mt7623n-rfb-nand.dts | 2 +-
> 5 files changed, 8 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH v2 0/9] soc: brcmstb: biuctrl updates for 64-bit chips
From: Florian Fainelli @ 2017-12-21 1:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-1-f.fainelli@gmail.com>
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
^ permalink raw reply
* [PATCH] PCI: Mediatek: clear irq status after irq dispathed to avoid reentry
From: Honghui Zhang @ 2017-12-21 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221005240.GC30595@bhelgaas-glaptop.roam.corp.google.com>
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 at mediatek.com wrote:
> > From: Honghui Zhang <honghui.zhang@mediatek.com>
> >
> > 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@mediatek.com>
> > ---
> > 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 at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 2/2] bcm2835-drivers-next-2017-12-19
From: Florian Fainelli @ 2017-12-21 1:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220004257.16764-2-eric@anholt.net>
Le 12/19/17 ? 16:42, Eric Anholt a ?crit?:
> The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:
>
> Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)
>
> are available in the Git repository at:
>
> git://github.com/anholt/linux tags/bcm2835-drivers-next-2017-12-19
>
> for you to fetch changes up to 9107ee6a50b81180f29a9f6588b21917dde2abdd:
>
> firmware: raspberrypi: print time using time64_t (2017-11-28 16:24:33 -0800)
>
> ----------------------------------------------------------------
> This pull request brings in a (cosmetic) y2038 fix for the Raspberry
> Pi firmware driver.
>
> ----------------------------------------------------------------
> Arnd Bergmann (1):
> firmware: raspberrypi: print time using time64_t
Merged, thanks Eric!
--
Florian
^ permalink raw reply
* [GIT PULL 1/2] bcm2835-dt-next-2017-12-19
From: Florian Fainelli @ 2017-12-21 1:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220004257.16764-1-eric@anholt.net>
Le 12/19/17 ? 16:42, Eric Anholt a ?crit?:
> Hi Florian,
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> git://github.com/anholt/linux tags/bcm2835-dt-next-2017-12-19
>
> for you to fetch changes up to 3edb73d87e9e824326f588b5d5c5661bf53449be:
>
> ARM: dts: bcm283x: Use GPIO polarity defines consistently (2017-12-08 13:10:09 -0800)
>
> ----------------------------------------------------------------
> This pull request cleans up the bcm2835 DT to use #defines for GPIO
> polarity.
>
> ----------------------------------------------------------------
> Stefan Wahren (1):
> ARM: dts: bcm283x: Use GPIO polarity defines consistently
Merged; thanks Eric!
--
Florian
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-21 1:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221003947.GJ7997@codeaurora.org>
On 12/20/17 6:39 PM, Stephen Boyd wrote:
> I don't see how it hurts to treat it generically. Presumably
> that's the way it will be done on ACPI platforms going forward?
> No need to tie it to some ACPI HID.
But it is tied to a HID. The "num-gpios" and "gpios" properties belong
to a specific HID. Someone could create a new HID with different
properties, and then what? That's why I want all the ACPI stuff in the
client driver.
At this point I don't really care any more about what the patches look
like, but I really do think that putting the ACPI code in pinctrl-msm is
a bad idea.
We're debating adding support for multiple TLMMs, and we may create a
new HID for that, so that we can define all pins on all TLMMs in one
device. We would need to create a new HID and new DSDs to go with it.
> I'm trying to resolve everything at once: gpios, pinctrl pins,
> and irqs exposed by the TLMM hardware. The value is that we solve
> it all, once, now.
Keep in mind that I am now in vacation, and so I won't be able to submit
any more patches for a while.
> The DT binding can also be resolved at the
> same time, so when we need to express this in DT it's already
> done.
Ok.
> Otherwise, something can request irqs from the irqdomain
> even if the irq can't be enabled, or it can try to mux the pin to
> some other function, even if the function selection can't be
> configured.
Is it possible to request an IRQ for a pin if the pin itself can't be
requested?
> Boiling everything down into the irq valid mask should cover all
> these cases, and not require us to strip const from all the data
> in the non-ACPI pinctrl drivers to replace the value in the npins
> field at runtime.
Ok.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [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: linux-arm-kernel
In-Reply-To: <20171220192702.32515-2-krzk@kernel.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@kernel.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 at 105d0000 {
> + cmu_mscl: clock-controller at 150d0000 {
> compatible = "samsung,exynos5433-cmu-mscl";
> reg = <0x150d0000 0x1000>;
> #clock-cells = <1>;
>
Looks good to me.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH] PCI: Mediatek: clear irq status after irq dispathed to avoid reentry
From: Bjorn Helgaas @ 2017-12-21 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513738334-26213-1-git-send-email-honghui.zhang@mediatek.com>
[+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 at mediatek.com wrote:
> From: Honghui Zhang <honghui.zhang@mediatek.com>
>
> 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@mediatek.com>
> ---
> 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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [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: linux-arm-kernel
In-Reply-To: <20171220192702.32515-1-krzk@kernel.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 at 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@kernel.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 at 13C00000 {
> + gsc_0: video-scaler at 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 at 13C10000 {
> + gsc_1: video-scaler at 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 at 13C20000 {
> + gsc_2: video-scaler at 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 at 152E0000 {
> + mfc: codec at 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 at 10E10000 {
> + pdma0: pdma at 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 at 10EB0000 {
> + pdma1: pdma at 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@samsung.com>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Stephen Boyd @ 2017-12-21 0:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a5809701-3f81-3f79-f558-a831ce4091c2@codeaurora.org>
On 12/20, Timur Tabi wrote:
> On 12/20/2017 02:15 AM, Stephen Boyd wrote:
> >Here's the patch. I get a hang when dumping debugfs, but at least
> >sysfs expose fails when trying to request blocked gpios. I need
> >to check if we need to say "yes" to pins that are above the gpio
> >max for pinctrl. I'll do that tomorrow.
>
> Sorry, I just don't see how this is better than my patches. I don't
> understand the need for involving the IRQ valid mask. I also don't
> see the value in adding code to look for a property that exists only
> in one ACPI HID (QCOM8002) as if it were generic. The "num-gpios"
> and "gpios" DSDs are not supposed to exist in any other HID, so
> there should be no code that reads it in pinctrl-msm.
I don't see how it hurts to treat it generically. Presumably
that's the way it will be done on ACPI platforms going forward?
No need to tie it to some ACPI HID.
I'm trying to resolve everything at once: gpios, pinctrl pins,
and irqs exposed by the TLMM hardware. The value is that we solve
it all, once, now. The DT binding can also be resolved at the
same time, so when we need to express this in DT it's already
done. Otherwise, something can request irqs from the irqdomain
even if the irq can't be enabled, or it can try to mux the pin to
some other function, even if the function selection can't be
configured.
Boiling everything down into the irq valid mask should cover all
these cases, and not require us to strip const from all the data
in the non-ACPI pinctrl drivers to replace the value in the npins
field at runtime.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] spi: pxa2xx: avoid redundant gpio_to_desc(desc_to_gpio()) round-trip
From: Rasmus Villemoes @ 2017-12-21 0:37 UTC (permalink / raw)
To: linux-arm-kernel
gpio_free(gpio) simply does gpiod_free(gpio_to_desc(gpio)), so it's
simpler and cleaner to use gpiod_free directly.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
drivers/spi/spi-pxa2xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 4cb515a3104c..c209dc1047b5 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1237,7 +1237,7 @@ static int setup_cs(struct spi_device *spi, struct chip_data *chip,
* different chip_info, release previously requested GPIO
*/
if (chip->gpiod_cs) {
- gpio_free(desc_to_gpio(chip->gpiod_cs));
+ gpiod_free(chip->gpiod_cs);
chip->gpiod_cs = NULL;
}
@@ -1417,7 +1417,7 @@ static void cleanup(struct spi_device *spi)
if (drv_data->ssp_type != CE4100_SSP && !drv_data->cs_gpiods &&
chip->gpiod_cs)
- gpio_free(desc_to_gpio(chip->gpiod_cs));
+ gpiod_free(chip->gpiod_cs);
kfree(chip);
}
--
2.11.0
^ permalink raw reply related
* [PATCH] MAINTAINERS: Add self as extended maintainer for a slew of files
From: Alessandro Rubini @ 2017-12-20 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a2LFGyTfdQ2AYd=jeu4vCbu5oVqQJhVjFwwc-zChLyj=A@mail.gmail.com>
>> Alessandro is not working on this platform any more.
>>
>> Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Yes, that's true. Thanks Linusw, and Arnd.
Acked-by: Alessandro Rubini <rubini@unipv.it>
/alessandro
^ permalink raw reply
* [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: linux-arm-kernel
In-Reply-To: <20171220231108.GJ10595@n2100.armlinux.org.uk>
The 88e1545 PHY has its interrupts wired to the VF610, so we might as
well use them.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
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 at 0 {
+ interrupt-parent = <&gpio0>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mv88e1545>;
};
switch2phy1: phy at 1 {
+ interrupt-parent = <&gpio0>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
reg = <1>;
};
switch2phy2: phy at 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
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: vf610-zii-dev-rev-b: add PHYs for switch2
From: Russell King @ 2017-12-20 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220231108.GJ10595@n2100.armlinux.org.uk>
Switch 2 has an 88e1545 PHY behind it, which is a quad PHY. Only the
first three PHYs are used, the remaining PHY is unused. When we wire
up the SFF sockets in a later commit, the omission of this causes the
fourth PHY to be used for port 3. Specifying the PHYs in DT avoids
the auto-probing of the bus, and discovery of this PHY.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 17 +++++++++++++++++
1 file changed, 17 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 ede8649ba515..782b69a3acdf 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -255,16 +255,19 @@
port at 0 {
reg = <0>;
label = "lan6";
+ phy-handle = <&switch2phy0>;
};
port at 1 {
reg = <1>;
label = "lan7";
+ phy-handle = <&switch2phy1>;
};
port at 2 {
reg = <2>;
label = "lan8";
+ phy-handle = <&switch2phy2>;
};
port at 3 {
@@ -304,6 +307,20 @@
};
};
};
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch2phy0: phy at 0 {
+ reg = <0>;
+ };
+ switch2phy1: phy at 1 {
+ reg = <1>;
+ };
+ switch2phy2: phy at 2 {
+ reg = <2>;
+ };
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: vf610-zii-dev-rev-b: fix interrupt for GPIO expander
From: Russell King @ 2017-12-20 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220231108.GJ10595@n2100.armlinux.org.uk>
The interrupt specification for the GPIO expander is wrong - the
expander is wired to PTB28, which is GPIO98. GPIO98 is on gpio chip
3, not 2.
In addition, the device is missing a required property. Interrupt
controllers must have the "interrupt-controller" property specified.
Add this.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
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 acdf12ad0622..ede8649ba515 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -371,7 +371,8 @@
reg = <0x22>;
gpio-controller;
#gpio-cells = <2>;
- interrupt-parent = <&gpio2>;
+ interrupt-controller;
+ interrupt-parent = <&gpio3>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
};
};
--
2.7.4
^ permalink raw reply related
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