* [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
* [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 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 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 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 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 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 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
* [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 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
* [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: linux-arm-kernel
In-Reply-To: <20171219115327.ofs5xwwimpn7x72n@valkosipuli.retiisi.org.uk>
Hi,
On Tue, 19 Dec 2017 13:53:28 +0200
Sakari Ailus <sakari.ailus@iki.fi> 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@magewell.com>
>
> 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 at 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 at iki.fi
Thanks,
Yong
^ permalink raw reply
* [PATCH] ARM: NOMMU: Setup VBAR/Hivecs for secondaries cores
From: afzal mohammed @ 2017-12-21 3:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <db12818a-509f-2b28-7df0-dd923d956057@arm.com>
Hi,
On Wed, Dec 20, 2017 at 12:22:16PM +0000, Vladimir Murzin wrote:
> >> Additionally, patch is not about Hivec only, but VBAR as well and TBH I
> >> don't follow what is your proposal...
> >
> > i was referring to the fact that vector remapping can't be done in
> > Cortex-R, as security extension is a requisite for this feature, which
> > Cortex-R don't have on ARMv7.
>
> For instance, just think of ARMv7A with 1:1 MMU running in SMP...
Hmm, 3 things,
1. MMU on would not take the path being patched here
2. w/ MMU on, currently it is always Hivecs
3. w/ MMU on & 1:1 mapping & due to pt. 2 above, if there is no memory
@0xFFFF0000, suspect things might go wrong.
afzal
^ permalink raw reply
* [PATCH] ARM: NOMMU: Setup VBAR/Hivecs for secondaries cores
From: afzal mohammed @ 2017-12-21 4:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <38fb32ef-9e2f-01c0-c89f-7d05fe8bcf60@arm.com>
Hi Vladimir,
On Wed, Dec 20, 2017 at 12:22:38PM +0000, Vladimir Murzin wrote:
> > To add, i am not against your patch, just seeing if we can avoid
> > having this change, lesser code ... lesser bugs.
>
> Look, I hit that issue and without this change the issue does not
> magically disappear for me - the only way to avoid this change is
> to propose alternative patch.
> I don't want to jump into these "it should not happen" or "nobody"
> cares" discussions just because it is not true - it happened to
> me and I do care. However, I do open to discuss technical aspects.
Okay sir, my reading of your other mail was that you caught this issue
by code inspection and not by hitting the issue in practice, seems
there was a communication gap. Now i am deducing from your mails you
actually have hit some issue because of my change, then your fix is
absolutely required, no question about it.
i was trying to find out the specific scenario where the issue would
be be hit because of my change. But since you are able to fix the
issue in your specific scenario w/ with this fix, no more questions
from my side. Some of my comments are made jokingly to keep the
spirits high, but at times it is being misread it seems.
afzal
^ permalink raw reply
* [PATCH v2] ARM: NOMMU: Setup VBAR/Hivecs for secondaries cores
From: afzal mohammed @ 2017-12-21 4:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513694293-5441-1-git-send-email-vladimir.murzin@arm.com>
Hi,
On Tue, Dec 19, 2017 at 02:38:13PM +0000, Vladimir Murzin wrote:
> With switch to dynamic exception base address setting, VBAR/Hivecs
> set only for boot CPU, but secondaries stay unaware of that. That
> might lead to weird effects when trying up to bring up secondaries.
>
> Fixes: ad475117d201 ("ARM: 8649/2: nommu: remove Hivecs configuration is asm")
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> +#ifndef CONFIG_MMU
> + setup_vectors_base();
> +#endif
i would have preferred instead,
if (!IS_ENABLED(CONFIG_MMU))
setup_vectors_base();
either way,
Acked-by: afzal mohammed <afzal.mohd.ma@gmail.com>
afzal
^ permalink raw reply
* [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: linux-arm-kernel
In-Reply-To: <1512013344-4042-2-git-send-email-prabhakar.kushwaha@nxp.com>
Hi Shawn,
> -----Original Message-----
> From: Prabhakar Kushwaha [mailto:prabhakar.kushwaha at nxp.com]
> Sent: Thursday, November 30, 2017 9:12 AM
> To: devicetree at vger.kernel.org; robh at kernel.org; mark.rutland at arm.com;
> shawnguo at kernel.org
> Cc: linux-arm-kernel at lists.infradead.org; Jagdish Gediya
> <jagdish.gediya@nxp.com>; Alison Wang <alison.wang@nxp.com>; Prabhakar
> Kushwaha <prabhakar.kushwaha@nxp.com>
> Subject: [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
>
> From: Jagdish Gediya <jagdish.gediya@nxp.com>
>
> 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@nxp.com>
> Signed-off-by: Jagdish Gediya <jagdish.gediya@nxp.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> ---
> 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 at 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
^ permalink raw reply
* [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: linux-arm-kernel
In-Reply-To: <1512013344-4042-3-git-send-email-prabhakar.kushwaha@nxp.com>
Hi Shawn,
> -----Original Message-----
> From: Prabhakar Kushwaha [mailto:prabhakar.kushwaha at nxp.com]
> Sent: Thursday, November 30, 2017 9:12 AM
> To: devicetree at vger.kernel.org; robh at kernel.org; mark.rutland at arm.com;
> shawnguo at kernel.org
> Cc: linux-arm-kernel at lists.infradead.org; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>; Jagdish Gediya <jagdish.gediya@nxp.com>
> 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@nxp.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> ---
> 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 at 2,0 {
> + compatible = "fsl,ifc-nand";
> + reg = <0x2 0x0 0x10000>;
> + };
> +
> fpga: board-control at 3,0 {
> #address-cells = <1>;
> #size-cells = <1>;
> --
There are no review comments on this patch.
Can you please accept this patch
--pk
^ permalink raw reply
* [PATCH 00/13] replace print_symbol() with printk()-s
From: Sergey Senozhatsky @ 2017-12-21 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513048252.3036.23.camel@perches.com>
On (12/11/17 19:10), Joe Perches wrote:
[..]
> As far as I'm concerned, as soon as there is
> no longer a single user in the kernel tree,
> better to delete it instead.
sounds good to me. can drop it, once the series upstreamed.
8< ---
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: [PATCH] kallsyms: remove print_symbol() function
No more print_symbol()/__print_symbol() users left, remove these
symbols.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Suggested-by: Joe Perches <joe@perches.com>
---
Documentation/filesystems/sysfs.txt | 4 ++--
Documentation/translations/zh_CN/filesystems/sysfs.txt | 4 ++--
include/linux/kallsyms.h | 18 ------------------
kernel/kallsyms.c | 11 -----------
4 files changed, 4 insertions(+), 33 deletions(-)
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt
index 9a3658cc399e..a1426cabcef1 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -154,8 +154,8 @@ static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr,
if (dev_attr->show)
ret = dev_attr->show(dev, dev_attr, buf);
if (ret >= (ssize_t)PAGE_SIZE) {
- print_symbol("dev_attr_show: %s returned bad count\n",
- (unsigned long)dev_attr->show);
+ printk("dev_attr_show: %pS returned bad count\n",
+ dev_attr->show);
}
return ret;
}
diff --git a/Documentation/translations/zh_CN/filesystems/sysfs.txt b/Documentation/translations/zh_CN/filesystems/sysfs.txt
index 7d3b05edb8ce..452271dda141 100644
--- a/Documentation/translations/zh_CN/filesystems/sysfs.txt
+++ b/Documentation/translations/zh_CN/filesystems/sysfs.txt
@@ -167,8 +167,8 @@ static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr,
if (dev_attr->show)
ret = dev_attr->show(dev, dev_attr, buf);
if (ret >= (ssize_t)PAGE_SIZE) {
- print_symbol("dev_attr_show: %s returned bad count\n",
- (unsigned long)dev_attr->show);
+ printk("dev_attr_show: %pS returned bad count\n",
+ dev_attr->show);
}
return ret;
}
diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
index 7288f9c395b6..d79d1e7486bd 100644
--- a/include/linux/kallsyms.h
+++ b/include/linux/kallsyms.h
@@ -94,9 +94,6 @@ extern int sprint_symbol(char *buffer, unsigned long address);
extern int sprint_symbol_no_offset(char *buffer, unsigned long address);
extern int sprint_backtrace(char *buffer, unsigned long address);
-/* Look up a kernel symbol and print it to the kernel messages. */
-extern void __print_symbol(const char *fmt, unsigned long address);
-
int lookup_symbol_name(unsigned long addr, char *symname);
int lookup_symbol_attrs(unsigned long addr, unsigned long *size, unsigned long *offset, char *modname, char *name);
@@ -166,23 +163,8 @@ static inline int kallsyms_show_value(void)
return false;
}
-/* Stupid that this does nothing, but I didn't create this mess. */
-#define __print_symbol(fmt, addr)
#endif /*CONFIG_KALLSYMS*/
-/* This macro allows us to keep printk typechecking */
-static __printf(1, 2)
-void __check_printsym_format(const char *fmt, ...)
-{
-}
-
-static inline void print_symbol(const char *fmt, unsigned long addr)
-{
- __check_printsym_format(fmt, "");
- __print_symbol(fmt, (unsigned long)
- __builtin_extract_return_addr((void *)addr));
-}
-
static inline void print_ip_sym(unsigned long ip)
{
printk("[<%p>] %pS\n", (void *) ip, (void *) ip);
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 24f456689f9c..a23e21ada81b 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -429,17 +429,6 @@ int sprint_backtrace(char *buffer, unsigned long address)
return __sprint_symbol(buffer, address, -1, 1);
}
-/* Look up a kernel symbol and print it to the kernel messages. */
-void __print_symbol(const char *fmt, unsigned long address)
-{
- char buffer[KSYM_SYMBOL_LEN];
-
- sprint_symbol(buffer, address);
-
- printk(fmt, buffer);
-}
-EXPORT_SYMBOL(__print_symbol);
-
/* To avoid using get_symbol_offset for every symbol, we carry prefix along. */
struct kallsym_iter {
loff_t pos;
--
2.15.1
^ permalink raw reply related
* [PATCH v2 2/2] PCI: mediatek: Fixup class type for MT7622
From: Yong Wu @ 2017-12-21 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513822277-18329-3-git-send-email-honghui.zhang@mediatek.com>
On Thu, 2017-12-21 at 10:11 +0800, honghui.zhang at mediatek.com wrote:
> 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.
> + */
What's the right vendor id and device id? is it possible to fix them
too?
> +DECLARE_PCI_FIXUP_EARLY(0x0e8d, 0x3258, mtk_fixup_class);
^ permalink raw reply
* [PATCH 0/7] Add USB remote wakeup driver
From: Chunfeng Yun @ 2017-12-21 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215205504.r6ol7fbbeyghb73w@rob-hp-laptop>
On Fri, 2017-12-15 at 14:55 -0600, Rob Herring wrote:
> On Sat, Dec 09, 2017 at 04:45:29PM +0800, Chunfeng Yun wrote:
> > These patches introduce the SSUSB and SPM glue layer driver which is
> > used to support usb remote wakeup. Usually the glue layer is put into
> > a system controller, such as PERICFG module.
> > The old way to support usb wakeup is put into SSUSB controller drivers,
> > including xhci-mtk driver and mtu3 driver, but there are some problems:
> > 1. can't disdinguish the relation between glue layer and SSUSB IP
> > when SoCs supports multi SSUSB IPs;
> > 2. duplicated code for wakeup are put into both xhci-mtk and mtu3
> > drivers;
> > 3. the glue layer may vary on different SoCs with SSUSB IP, and will
> > make SSUSB controller drivers complicated;
> > In order to resolve these problems, it's useful to make the glue layer
> > transparent by extracting a seperated driver, meanwhile to reduce the
> > duplicated code and simplify SSUSB controller drivers.
>
> Both the driver and binding look overly complicated to me when it looks
> like you just have 2 versions of enable/disable functions which modify
> a single register. The complexity may be justified if this was a common
> binding and driver, but it is not.
>
> You already have a phandle to the system controller. Can't you add cells
> to it to handle any differences between instances? That and SoC specific
> compatible strings should be enough to handle differences.
Yes, adding cells will also work well, I'll try it, thanks a lot
>
> Rob
^ permalink raw reply
* [PATCH] irqchip/gic-v3-its: Flush GICR caching for a cross node collection move of an irq
From: Ganapatrao Kulkarni @ 2017-12-21 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <acac628e-d4fa-5b16-2619-144818f2261a@arm.com>
On Wed, Dec 20, 2017 at 6:42 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 20/12/17 09:34, Ganapatrao Kulkarni wrote:
>> Hi Marc,
>>
>> On Wed, Dec 20, 2017 at 2:56 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>> On 20/12/17 09:15, Ganapatrao Kulkarni wrote:
>>>> When an interrupt is moved, it is possible that an implementation that
>>>> supports caching might still have cached data for a previous
>>>> (no longer valid) mapping of the interrupt. In particular, in a distributed
>>>> GIC implementation like multi-socket SoC platfroms. Hence it is necessary
>>>> to flush cached entries after cross node collection migration.
>>>>
>>>> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
>>>> ---
>>>> drivers/irqchip/irq-gic-v3-its.c | 6 ++++++
>>>> 1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>>>> index 4039e64..ea849a1 100644
>>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>>> @@ -1119,6 +1119,12 @@ static int its_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
>>>> if (cpu != its_dev->event_map.col_map[id]) {
>>>> target_col = &its_dev->its->collections[cpu];
>>>> its_send_movi(its_dev, target_col, id);
>>>> + /* Issue INV for cross node collection move on
>>>> + * multi socket systems.
>>>> + */
>>>> + if (cpu_to_node(cpu) !=
>>>> + cpu_to_node(its_dev->event_map.col_map[id]))
>>>> + its_send_inv(its_dev, id);
>>>> its_dev->event_map.col_map[id] = cpu;
>>>> irq_data_update_effective_affinity(d, cpumask_of(cpu));
>>>> }
>>>>
>>>
>>> The MOVI command doesn't have any such requirement (it only mandates
>>> synchronization), and doesn't say anything about distributed vs monolithic.
>>
>> GIC-v3 spec do mention to issue ITS INV command or a write to GICR_INVLPIR.
>> pasting below snippet of MOVI command description.
>>
>> "When an interrupt is moved to a collection, it is possible that an
>> implementation that supports speculative caching
>> might still have cached data for a previous (no longer valid) mapping
>> of the interrupt. Hence, implementations
>> must take care to invalidate any data associated with an interrupt
>> when it is moved. In particular, in a distributed
>> implementation, the ITS must write to the appropriate GICR_* register
>> to perform the invalidation in the redistributor."
>
> Doing some documentation archaeology, I found that this wording has been
> dropped from the engineering specification in August 2014, and was never
> included in the architecture specification. I suggest you start using a
> slightly more up-to-date set of documentation...
thanks Marc for digging in to archive.
>
> Now, back to your point: what it says in the bit of (confidential)
> document that you quoted is that the *HW* must perform the invalidation
> (that's what the words "implementations" and "ITS" refer to), not some
> random bits of SW.
>
> If you know of an implementation that suffers from this, please resend a
> patch that handles this as a quirk, with a proper erratum number.
Sure, this is being discussed internally and will repost as errata fix
at the earliest.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
thanks
Ganapat
^ permalink raw reply
* [PATCH 1/7] soc: mediatek: Add USB wakeup driver
From: Chunfeng Yun @ 2017-12-21 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215205550.dkiymkok6arheidg@rob-hp-laptop>
On Fri, 2017-12-15 at 14:55 -0600, Rob Herring wrote:
> On Sat, Dec 09, 2017 at 04:45:30PM +0800, Chunfeng Yun wrote:
> > This driver is used to support usb wakeup which is controlled by
> > the glue layer between SSUSB and SPM. Usually the glue layer is put
> > into a system controller, such as pericfg module, which is
> > represented by a syscon node in DTS.
> > Due to the glue layer may vary on different SoCs, it's useful to
> > extract a separated driver to simplify usb controller drivers.
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > drivers/soc/mediatek/Kconfig | 8 +
> > drivers/soc/mediatek/Makefile | 1 +
> > drivers/soc/mediatek/mtk-usb-wakeup.c | 519 ++++++++++++++++++++++++++
> > include/dt-bindings/soc/mediatek,usb-wakeup.h | 15 +
>
> This belongs in the binding patch and that should come first.
>
> > include/linux/soc/mediatek/usb-wakeup.h | 88 +++++
> > 5 files changed, 631 insertions(+)
> > create mode 100644 drivers/soc/mediatek/mtk-usb-wakeup.c
> > create mode 100644 include/dt-bindings/soc/mediatek,usb-wakeup.h
> > create mode 100644 include/linux/soc/mediatek/usb-wakeup.h
>
> > +++ b/drivers/soc/mediatek/mtk-usb-wakeup.c
> > @@ -0,0 +1,519 @@
> > +/*
> > + * Copyright (c) 2017 MediaTek Inc.
> > + * Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > + *
> > + * SPDX-License-Identifier: GPL-2.0
>
> This should be the first line of the file and use a // style comment.
>
> [...]
>
> > diff --git a/include/dt-bindings/soc/mediatek,usb-wakeup.h b/include/dt-bindings/soc/mediatek,usb-wakeup.h
> > new file mode 100644
> > index 0000000..2461795
> > --- /dev/null
> > +++ b/include/dt-bindings/soc/mediatek,usb-wakeup.h
> > @@ -0,0 +1,15 @@
> > +/*
> > + * Copyright (c) 2017 MediaTek Inc.
> > + * Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > + *
> > + * SPDX-License-Identifier: GPL-2.0
>
> ditto. Except headers use /* */ comments...
modify it next version. Thanks
^ permalink raw reply
* [PATCH v2 2/2] PCI: mediatek: Fixup class type for MT7622
From: Honghui Zhang @ 2017-12-21 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513838476.23174.3.camel@mhfsdcap03>
On Thu, 2017-12-21 at 14:41 +0800, Yong Wu wrote:
> On Thu, 2017-12-21 at 10:11 +0800, honghui.zhang at mediatek.com wrote:
> > 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.
> > + */
>
> What's the right vendor id and device id? is it possible to fix them
> too?
Vendor ID is managed by PCI-SIG, you may get the assigned vendor ID
from:
https://pci-ids.ucw.cz/read/PC?restrict=
The vendor ID for Mediatek Corp. should be 14c3.
Device ID is something like vendor-defined.
Those values are in the configuration space and are read-only defined by
spec, it's been stored at the pci_dev, we may change the vendor and
device values in pci_dev, but I don't think it's necessary to change
that.
BTW, Does anyone really cares about the vendor ID and device ID except
the device's driver?
thanks.
>
> > +DECLARE_PCI_FIXUP_EARLY(0x0e8d, 0x3258, mtk_fixup_class);
>
>
^ permalink raw reply
* [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
From: Shawn Guo @ 2017-12-21 7:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB1241E7538E97597B76606FF4970D0@HE1PR04MB1241.eurprd04.prod.outlook.com>
On Thu, Dec 21, 2017 at 05:14:36AM +0000, Prabhakar Kushwaha wrote:
> Hi Shawn,
>
> > -----Original Message-----
> > From: Prabhakar Kushwaha [mailto:prabhakar.kushwaha at nxp.com]
> > Sent: Thursday, November 30, 2017 9:12 AM
> > To: devicetree at vger.kernel.org; robh at kernel.org; mark.rutland at arm.com;
> > shawnguo at kernel.org
> > Cc: linux-arm-kernel at lists.infradead.org; Jagdish Gediya
> > <jagdish.gediya@nxp.com>; Alison Wang <alison.wang@nxp.com>; Prabhakar
> > Kushwaha <prabhakar.kushwaha@nxp.com>
> > Subject: [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
> >
> > From: Jagdish Gediya <jagdish.gediya@nxp.com>
> >
> > 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@nxp.com>
> > Signed-off-by: Jagdish Gediya <jagdish.gediya@nxp.com>
> > Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> > ---
> > 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 at 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
It seems that the bindings hasn't been ACK-ed by DT maintainer.
Shawn
^ permalink raw reply
* [PATCH 2/2][v2] ARM: dts: ls1021aqds: Add nand node for ifc controller
From: Shawn Guo @ 2017-12-21 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512013344-4042-3-git-send-email-prabhakar.kushwaha@nxp.com>
On Thu, Nov 30, 2017 at 09:12:24AM +0530, Prabhakar Kushwaha wrote:
> 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@nxp.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
From: Prabhakar Kushwaha @ 2017-12-21 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221071056.GF3766@dragon>
Hi Shawn,
> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo at kernel.org]
> Sent: Thursday, December 21, 2017 12:41 PM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> Cc: devicetree at vger.kernel.org; robh at kernel.org; mark.rutland at arm.com;
> Alison Wang <alison.wang@nxp.com>; Jagdish Gediya
> <jagdish.gediya@nxp.com>; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
>
> On Thu, Dec 21, 2017 at 05:14:36AM +0000, Prabhakar Kushwaha wrote:
> > Hi Shawn,
> >
> > > -----Original Message-----
> > > From: Prabhakar Kushwaha [mailto:prabhakar.kushwaha at nxp.com]
> > > Sent: Thursday, November 30, 2017 9:12 AM
> > > To: devicetree at vger.kernel.org; robh at kernel.org; mark.rutland at arm.com;
> > > shawnguo at kernel.org
> > > Cc: linux-arm-kernel at lists.infradead.org; Jagdish Gediya
> > > <jagdish.gediya@nxp.com>; Alison Wang <alison.wang@nxp.com>;
> Prabhakar
> > > Kushwaha <prabhakar.kushwaha@nxp.com>
> > > Subject: [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
> > >
> > > From: Jagdish Gediya <jagdish.gediya@nxp.com>
> > >
> > > 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@nxp.com>
> > > Signed-off-by: Jagdish Gediya <jagdish.gediya@nxp.com>
> > > Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> > > ---
> > > 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 at 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
>
> It seems that the bindings hasn't been ACK-ed by DT maintainer.
>
Are you referring to this discussion https://patchwork.ozlabs.org/patch/842543/?
Due to which binding are not ACK-ed.
--pk
^ 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