* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
From: Frank Rowand @ 2018-05-29 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529173314.GN17671@n2100.armlinux.org.uk>
On 05/29/18 10:33, Russell King - ARM Linux wrote:
> On Tue, May 29, 2018 at 10:05:37AM -0700, Frank Rowand wrote:
>> On 05/22/18 13:01, Rob Herring wrote:
>>> I'll tell you up front, I'm not a fan of FIT image (nor uImage,
>>> Android boot image, $bootloader image). If you want a collection of
>>> files and some configuration data, use a filesystem and a text file.
>
> Me neither.
>
>> My gut feel is that using a filesystem and a text file is the easier way
>> to create the boot info. But that also makes applying the overlay(s)
>> during early Linux boot (at the point of FDT unflattening) impractical
>> (can't access the file system without a driver, the driver depends on
>> the devicetree, the devicetree depends upon the overlay).
>
> Why do you want to apply overlays during the kernel boot? The boot
> loader should be providing the kernel with the merged DT to describe
> the system that the kernel is running on - it's not the kernel's
> job to put that together.
I would much prefer that overlays get applied before the unflattened
devicetree is made available to the kernel instead of applying overlays
late in the boot (after many susbsystems and drivers are initialized)
or after boot.
If overlays are applied before the unflattened devicetree is made
available to the kernel then subsystems and drivers do not have to be
aware of the possibility of the data in the devicetree changing instead
of being invariant. (I will call this "apply early overlays" later in
this email.)
There are use cases of overlays where the overlay is not available until
late in the boot, or after the boot completes. I am not suggesting that
those use cases be ignored. That is a completely different conversation.
If overlays are applied before the unflattened devicetree is made
available to the kernel, there are at least two obvious methods
(and I can think of at least one more) -- either the kernel does it
or the bootloader does it. I do not see either of the two as being
the obvious and only correct choice. If the kernel does it, then
there is no need for multiple bootloaders to implement the same code.
If the bootloaders do it, then there is no need for multiple kernels
(Linux, BSD, etc) to implement the same code. I do not have a
strong opinion about whether the bootloaders or the kernels are a
better place to apply early overlays.
> The whole point of DT is to make the kernel _less_ tied to the hardware
> and more generic. If we're going to introduce an entirely new set of
> drivers into the kernel to "probe" the hardware to determine which
> overlays are required, then that's really defeating the purpose of DT.
If you read my circular dependency sentence carefully, I said a kernel
driver is impractical for the task of getting the overlay. So I agree.
If the kernel applies the overlay, an alternative to drivers is that the
kernel could receive the overlay(s) in a similar manner as the method it
currently receives the base devicetree. (The overlay(s) could be
appended to the base devicetree, a wrapper could be placed around the
base devicetree and the overlay(s), or some other implementation. There
are multiple ways to achieve the same result.)
^ permalink raw reply
* v4.17-rc1: regressions on N900, N950
From: Pavel Machek @ 2018-05-29 22:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529210909.7m4cyhh524xqipju@earth.universe>
On Tue 2018-05-29 23:09:09, Sebastian Reichel wrote:
> Hi Pavel,
>
> On Tue, May 29, 2018 at 10:45:17PM +0200, Pavel Machek wrote:
> > > > > still results in working touchscreen, removing any of the three fields
> > > > > breaks it again.
> > > >
> > > > I bisected one regression down, see "omapdrm regression in v4.17-rc series"
> > > > not sure if it covers all the issues being discussed here though.
> > >
> > > Reverting 24aac6011f70 fixes screen on n900 in v4.17-rc for me. (But
> > > strange dependency on tsc2005 at 0 is still there).
> >
> > Laurent, your patch looks pretty obvious, but unfortunately breaks
> > display on Nokia N900.
> >
> > The patch is pretty big as is, perhaps you have version split to sdi
> > => *sdi and then static => dynamic allocation?
>
> There is a queued fix:
>
> https://github.com/freedesktop/drm-misc/commit/2bc5ff0bdc00d81d719dad74589317a260d583ed
Thanks for the pointer! I hope it makes it in time for v4.17...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/1dd6ade5/attachment.sig>
^ permalink raw reply
* Regression in Linux next again
From: Tony Lindgren @ 2018-05-29 22:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Linux next has a regression at least on beaglebone-x15 where
booting Linux hangs shortly after starting init when loading
modules with no output. I bisected it down to commit
456e7cdf3b1a ("regulator: core: Change voltage setting path")
I think I bisected this same issue for the second time now
but for a different merge window. What's up with that?
And then we also have commit 696861761a58 ("regulator: core: Add
voltage balancing mechanism") that fails to compile breaking
git bisect:
drivers/regulator/core.c: In function 'regulator_balance_voltage':
drivers/regulator/core.c:3284:9: error: implicit declaration of
function 'regulator_set_voltage'.
Reverting both patches fixes the issue for me. I could
not debug it further because of the compile error(s).
Regards,
Tony
^ permalink raw reply
* [PATCH 6/6] arm64: dts: Change PCIe INTx mapping for NS2
From: Ray Jui @ 2018-05-29 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-1-git-send-email-ray.jui@broadcom.com>
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
index 4a2a6af..0373ebe 100644
--- a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
@@ -116,9 +116,14 @@
reg = <0 0x20020000 0 0x1000>;
dma-coherent;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 281 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0 1>,
+ <0 0 0 2 &pcie0 2>,
+ <0 0 0 3 &pcie0 3>,
+ <0 0 0 4 &pcie0 4>;
+ interrupts = <GIC_SPI 281 IRQ_TYPE_NONE>;
linux,pci-domain = <0>;
@@ -147,9 +152,14 @@
reg = <0 0x50020000 0 0x1000>;
dma-coherent;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 305 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie4 1>,
+ <0 0 0 2 &pcie4 2>,
+ <0 0 0 3 &pcie4 3>,
+ <0 0 0 4 &pcie4 4>;
+ interrupts = <GIC_SPI 305 IRQ_TYPE_NONE>;
linux,pci-domain = <4>;
@@ -169,7 +179,6 @@
phys = <&pci_phy1>;
phy-names = "pcie-phy";
-
msi-parent = <&v2m0>;
};
--
2.1.4
^ permalink raw reply related
* [PATCH 5/6] arm: dts: Change PCIe INTx mapping for HR2
From: Ray Jui @ 2018-05-29 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-1-git-send-email-ray.jui@broadcom.com>
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm/boot/dts/bcm-hr2.dtsi | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-hr2.dtsi b/arch/arm/boot/dts/bcm-hr2.dtsi
index 3f9cedd..20e3161 100644
--- a/arch/arm/boot/dts/bcm-hr2.dtsi
+++ b/arch/arm/boot/dts/bcm-hr2.dtsi
@@ -298,9 +298,14 @@
compatible = "brcm,iproc-pcie";
reg = <0x18012000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 186 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0 1>,
+ <0 0 0 2 &pcie0 2>,
+ <0 0 0 3 &pcie0 3>,
+ <0 0 0 4 &pcie0 4>;
+ interrupts = <GIC_SPI 186 IRQ_TYPE_NONE>;
linux,pci-domain = <0>;
@@ -334,9 +339,14 @@
compatible = "brcm,iproc-pcie";
reg = <0x18013000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 192 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1 1>,
+ <0 0 0 2 &pcie1 2>,
+ <0 0 0 3 &pcie1 3>,
+ <0 0 0 4 &pcie1 4>;
+ interrupts = <GIC_SPI 192 IRQ_TYPE_NONE>;
linux,pci-domain = <1>;
--
2.1.4
^ permalink raw reply related
* [PATCH 4/6] arm: dts: Change PCIe INTx mapping for NSP
From: Ray Jui @ 2018-05-29 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-1-git-send-email-ray.jui@broadcom.com>
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index dcc55aa..8c4c8b2 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -494,9 +494,14 @@
compatible = "brcm,iproc-pcie";
reg = <0x18012000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 131 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0 1>,
+ <0 0 0 2 &pcie0 2>,
+ <0 0 0 3 &pcie0 3>,
+ <0 0 0 4 &pcie0 4>;
+ interrupts = <GIC_SPI 131 IRQ_TYPE_NONE>;
linux,pci-domain = <0>;
@@ -531,9 +536,14 @@
compatible = "brcm,iproc-pcie";
reg = <0x18013000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 137 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1 1>,
+ <0 0 0 2 &pcie1 2>,
+ <0 0 0 3 &pcie1 3>,
+ <0 0 0 4 &pcie1 4>;
+ interrupts = <GIC_SPI 137 IRQ_TYPE_NONE>;
linux,pci-domain = <1>;
@@ -568,9 +578,14 @@
compatible = "brcm,iproc-pcie";
reg = <0x18014000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 143 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie2 1>,
+ <0 0 0 2 &pcie2 2>,
+ <0 0 0 3 &pcie2 3>,
+ <0 0 0 4 &pcie2 4>;
+ interrupts = <GIC_SPI 143 IRQ_TYPE_NONE>;
linux,pci-domain = <2>;
--
2.1.4
^ permalink raw reply related
* [PATCH 3/6] arm: dts: Change PCIe INTx mapping for Cygnus
From: Ray Jui @ 2018-05-29 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-1-git-send-email-ray.jui@broadcom.com>
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 699fdf9..6de21ef 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -254,9 +254,14 @@
compatible = "brcm,iproc-pcie";
reg = <0x18012000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0 1>,
+ <0 0 0 2 &pcie0 2>,
+ <0 0 0 3 &pcie0 3>,
+ <0 0 0 4 &pcie0 4>;
+ interrupts = <GIC_SPI 100 IRQ_TYPE_NONE>;
linux,pci-domain = <0>;
@@ -289,9 +294,14 @@
compatible = "brcm,iproc-pcie";
reg = <0x18013000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1 1>,
+ <0 0 0 2 &pcie1 2>,
+ <0 0 0 3 &pcie1 3>,
+ <0 0 0 4 &pcie1 4>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_NONE>;
linux,pci-domain = <1>;
--
2.1.4
^ permalink raw reply related
* [PATCH 2/6] PCI: iproc: Add INTx support with better modeling
From: Ray Jui @ 2018-05-29 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-1-git-send-email-ray.jui@broadcom.com>
Add PCIe legacy interrupt INTx support to the iProc PCIe driver by
modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC,
INTD share the same interrupt line connected to the GIC in the system,
while the status of each INTx can be obtained through the INTX CSR
register
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
drivers/pci/host/pcie-iproc-platform.c | 2 +
drivers/pci/host/pcie-iproc.c | 95 +++++++++++++++++++++++++++++++++-
drivers/pci/host/pcie-iproc.h | 6 +++
3 files changed, 101 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/host/pcie-iproc-platform.c b/drivers/pci/host/pcie-iproc-platform.c
index e764a2a..7a51e6c 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -70,6 +70,8 @@ static int iproc_pcie_pltfm_probe(struct platform_device *pdev)
}
pcie->base_addr = reg.start;
+ pcie->irq = platform_get_irq(pdev, 0);
+
if (of_property_read_bool(np, "brcm,pcie-ob")) {
u32 val;
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 14f374d..0bd2c14 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -14,6 +14,7 @@
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/irqchip/arm-gic-v3.h>
+#include <linux/irqchip/chained_irq.h>
#include <linux/platform_device.h>
#include <linux/of_address.h>
#include <linux/of_pci.h>
@@ -264,6 +265,7 @@ enum iproc_pcie_reg {
/* enable INTx */
IPROC_PCIE_INTX_EN,
+ IPROC_PCIE_INTX_CSR,
/* outbound address mapping */
IPROC_PCIE_OARR0,
@@ -305,6 +307,7 @@ static const u16 iproc_pcie_reg_paxb_bcma[] = {
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
[IPROC_PCIE_CFG_DATA] = 0x1fc,
[IPROC_PCIE_INTX_EN] = 0x330,
+ [IPROC_PCIE_INTX_CSR] = 0x334,
[IPROC_PCIE_LINK_STATUS] = 0xf0c,
};
@@ -316,6 +319,7 @@ static const u16 iproc_pcie_reg_paxb[] = {
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
[IPROC_PCIE_CFG_DATA] = 0x1fc,
[IPROC_PCIE_INTX_EN] = 0x330,
+ [IPROC_PCIE_INTX_CSR] = 0x334,
[IPROC_PCIE_OARR0] = 0xd20,
[IPROC_PCIE_OMAP0] = 0xd40,
[IPROC_PCIE_OARR1] = 0xd28,
@@ -332,6 +336,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
[IPROC_PCIE_CFG_DATA] = 0x1fc,
[IPROC_PCIE_INTX_EN] = 0x330,
+ [IPROC_PCIE_INTX_CSR] = 0x334,
[IPROC_PCIE_OARR0] = 0xd20,
[IPROC_PCIE_OMAP0] = 0xd40,
[IPROC_PCIE_OARR1] = 0xd28,
@@ -782,9 +787,90 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
return link_is_active ? 0 : -ENODEV;
}
-static void iproc_pcie_enable(struct iproc_pcie *pcie)
+static int iproc_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
+ irq_hw_number_t hwirq)
{
+ irq_set_chip_and_handler(irq, &dummy_irq_chip, handle_simple_irq);
+ irq_set_chip_data(irq, domain->host_data);
+
+ return 0;
+}
+
+static const struct irq_domain_ops intx_domain_ops = {
+ .map = iproc_pcie_intx_map,
+};
+
+static void iproc_pcie_isr(struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct iproc_pcie *pcie;
+ struct device *dev;
+ unsigned long status;
+ u32 bit, virq;
+
+ chained_irq_enter(chip, desc);
+ pcie = irq_desc_get_handler_data(desc);
+ dev = pcie->dev;
+
+ /* go through INTx A, B, C, D until all interrupts are handled */
+ while ((status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR) &
+ SYS_RC_INTX_MASK) != 0) {
+ for_each_set_bit(bit, &status, PCI_NUM_INTX) {
+ virq = irq_find_mapping(pcie->irq_domain, bit + 1);
+ if (virq)
+ generic_handle_irq(virq);
+ else
+ dev_err(dev, "unexpected INTx%u\n", bit);
+ }
+ }
+
+ chained_irq_exit(chip, desc);
+}
+
+static int iproc_pcie_intx_enable(struct iproc_pcie *pcie)
+{
+ struct device *dev = pcie->dev;
+ struct device_node *node = dev->of_node;
+ int ret;
+
iproc_pcie_write_reg(pcie, IPROC_PCIE_INTX_EN, SYS_RC_INTX_MASK);
+
+ /*
+ * BCMA devices do not map INTx the same way as platform devices. All
+ * BCMA needs is the above code to enable INTx
+ */
+ if (pcie->irq <= 0)
+ return 0;
+
+ /* set IRQ handler */
+ irq_set_chained_handler_and_data(pcie->irq, iproc_pcie_isr, pcie);
+
+ /* add IRQ domain for INTx */
+ pcie->irq_domain = irq_domain_add_linear(node, PCI_NUM_INTX + 1,
+ &intx_domain_ops, pcie);
+ if (!pcie->irq_domain) {
+ dev_err(dev, "failed to add INTx IRQ domain\n");
+ ret = -ENOMEM;
+ goto err_rm_handler_data;
+ }
+
+ return 0;
+
+err_rm_handler_data:
+ irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
+
+ return ret;
+}
+
+static void iproc_pcie_intx_disable(struct iproc_pcie *pcie)
+{
+ iproc_pcie_write_reg(pcie, IPROC_PCIE_INTX_EN, 0x0);
+
+ if (pcie->irq <= 0)
+ return;
+
+ irq_domain_remove(pcie->irq_domain);
+ irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
}
static inline bool iproc_pcie_ob_is_valid(struct iproc_pcie *pcie,
@@ -1410,7 +1496,11 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)
goto err_power_off_phy;
}
- iproc_pcie_enable(pcie);
+ ret = iproc_pcie_intx_enable(pcie);
+ if (ret) {
+ dev_err(dev, "failed to enable INTx\n");
+ goto err_power_off_phy;
+ }
if (IS_ENABLED(CONFIG_PCI_MSI))
if (iproc_pcie_msi_enable(pcie))
@@ -1455,6 +1545,7 @@ int iproc_pcie_remove(struct iproc_pcie *pcie)
pci_remove_root_bus(pcie->root_bus);
iproc_pcie_msi_disable(pcie);
+ iproc_pcie_intx_disable(pcie);
phy_power_off(pcie->phy);
phy_exit(pcie->phy);
diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
index 67081cb..cbcaf9d 100644
--- a/drivers/pci/host/pcie-iproc.h
+++ b/drivers/pci/host/pcie-iproc.h
@@ -72,6 +72,9 @@ struct iproc_msi;
* @ib: inbound mapping related parameters
* @ib_map: outbound mapping region related parameters
*
+ * @irq: interrupt line wired to the generic GIC for INTx
+ * @irq_domain: IRQ domain for INTx
+ *
* @need_msi_steer: indicates additional configuration of the iProc PCIe
* controller is required to steer MSI writes to external interrupt controller
* @msi: MSI data
@@ -99,6 +102,9 @@ struct iproc_pcie {
struct iproc_pcie_ib ib;
const struct iproc_pcie_ib_map *ib_map;
+ int irq;
+ struct irq_domain *irq_domain;
+
bool need_msi_steer;
struct iproc_msi *msi;
};
--
2.1.4
^ permalink raw reply related
* [PATCH 1/6] PCI: iproc: Update iProc PCI binding for INTx support
From: Ray Jui @ 2018-05-29 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-1-git-send-email-ray.jui@broadcom.com>
Update the iProc PCIe binding document for better modeling of the legacy
interrupt (INTx) support
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
.../devicetree/bindings/pci/brcm,iproc-pcie.txt | 31 +++++++++++++++++-----
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
index b8e48b4..7ea24dc 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -13,9 +13,6 @@ controller, used in Stingray
PAXB-based root complex is used for external endpoint devices. PAXC-based
root complex is connected to emulated endpoint devices internal to the ASIC
- reg: base address and length of the PCIe controller I/O register space
-- #interrupt-cells: set to <1>
-- interrupt-map-mask and interrupt-map, standard PCI properties to define the
- mapping of the PCIe interface to interrupt numbers
- linux,pci-domain: PCI domain ID. Should be unique for each host controller
- bus-range: PCI bus numbers covered
- #address-cells: set to <3>
@@ -41,6 +38,16 @@ Required:
- brcm,pcie-ob-axi-offset: The offset from the AXI address to the internal
address used by the iProc PCIe core (not the PCIe address)
+Legacy interrupt (INTx) support (optional):
+
+Note INTx is for PAXB only.
+
+- interrupt-controller: claims itself as an interrupt controller for INTx
+- #interrupt-cells: set to <1>
+- interrupt-map-mask and interrupt-map, standard PCI properties to define
+the mapping of the PCIe interface to interrupt numbers
+- interrupts: interrupt line wired to the generic GIC for INTx support
+
MSI support (optional):
For older platforms without MSI integrated in the GIC, iProc PCIe core provides
@@ -77,9 +84,14 @@ Example:
compatible = "brcm,iproc-pcie";
reg = <0x18012000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0 1>,
+ <0 0 0 2 &pcie0 2>,
+ <0 0 0 3 &pcie0 3>,
+ <0 0 0 4 &pcie0 4>;
+ interrupts = <GIC_SPI 100 IRQ_TYPE_NONE>;
linux,pci-domain = <0>;
@@ -115,9 +127,14 @@ Example:
compatible = "brcm,iproc-pcie";
reg = <0x18013000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1 1>,
+ <0 0 0 2 &pcie1 2>,
+ <0 0 0 3 &pcie1 3>,
+ <0 0 0 4 &pcie1 4>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_NONE>;
linux,pci-domain = <1>;
--
2.1.4
^ permalink raw reply related
* [PATCH 0/6] PAXB INTx support with proper model
From: Ray Jui @ 2018-05-29 21:58 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds PCIe legacy interrupt (INTx) support to the iProc
PCIe driver by modeling it with its own IRQ domain. All 4 interrupts INTA,
INTB, INTC, INTD share the same interrupt line connected to the GIC
in the system. This is now modeled by using its own IRQ domain.
Also update all relevant devicetree files to adapt to the new model
This patch series is available on GIHUB:
repo: https://github.com/Broadcom/arm64-linux.git
branch: pcie-intx-v1
Ray Jui (6):
PCI: iproc: Update iProc PCI binding for INTx support
PCI: iproc: Add INTx support with better modeling
arm: dts: Change PCIe INTx mapping for Cygnus
arm: dts: Change PCIe INTx mapping for NSP
arm: dts: Change PCIe INTx mapping for HR2
arm64: dts: Change PCIe INTx mapping for NS2
.../devicetree/bindings/pci/brcm,iproc-pcie.txt | 31 +++++--
arch/arm/boot/dts/bcm-cygnus.dtsi | 18 +++-
arch/arm/boot/dts/bcm-hr2.dtsi | 18 +++-
arch/arm/boot/dts/bcm-nsp.dtsi | 27 ++++--
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 19 +++--
drivers/pci/host/pcie-iproc-platform.c | 2 +
drivers/pci/host/pcie-iproc.c | 95 +++++++++++++++++++++-
drivers/pci/host/pcie-iproc.h | 6 ++
8 files changed, 188 insertions(+), 28 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v9 00/12] Support PPTT for ARM64
From: Jeremy Linton @ 2018-05-29 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdU0yET6+-FfS8e9HJdKB7h0gDn7kzWGpJZV=UiWn5fLkA@mail.gmail.com>
Hi,
On 05/29/2018 10:51 AM, Geert Uytterhoeven wrote:
> Hi Will,
>
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>> System supend still works fine on systems with big cores only:
>>>>>>
>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>> R-Car M3-N (2xCA57)
>>>>>>
>>>>>> Reverting this commit fixes the issue for me.
>>>>>
>>>>> I can't find anything that relates to system suspend in these patches
>>>>> unless they are messing with something during CPU hot plug-in back
>>>>> during resume.
>>>>
>>>> It's only the last patch that introduces the breakage.
>>>>
>>>
>>> As specified in the commit log, it won't change any behavior for DT
>>> systems if it's non-NUMA or single node system. So I am still wondering
>>> what could trigger this regression.
>>
>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>> to the scheduler, although I can't see how this would happen.
>>
>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>> do you see anything shouting in dmesg?
>
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.
I suspect most of the problem is related to the node mask changing at
unexpected times (particularly cores being removed from the mask). Once
I understand that more, there may be a simpler patch.
OTOH, I've been testing with this, and with it, I can't seem to
duplicate the problem with CONFIG_NUMA disabled I found.
diff --git a/arch/arm64/include/asm/topology.h
b/arch/arm64/include/asm/topology.h
index df48212f767b..7450ef5ed733 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -12,6 +12,7 @@ struct cpu_topology {
cpumask_t thread_sibling;
cpumask_t core_sibling;
cpumask_t llc_siblings;
+ cpumask_t node_siblings; /* maintain a stable node sibling list */
};
extern struct cpu_topology cpu_topology[NR_CPUS];
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index f3e2e3aec0b0..f4eb80852d78 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -677,8 +677,9 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
init_cpu_topology();
this_cpu = smp_processor_id();
- store_cpu_topology(this_cpu);
numa_store_cpu_info(this_cpu);
+ store_cpu_topology(this_cpu);
+
/*
* If UP is mandated by "nosmp" (which implies "maxcpus=0"),
don't set
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7415c166281f..6819c764537d 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -215,7 +215,7 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
+ const cpumask_t *core_mask = &cpu_topology[cpu].node_siblings;
/* Find the smaller of NUMA, core or LLC siblings */
if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
@@ -233,12 +233,16 @@ const struct cpumask *cpu_coregroup_mask(int cpu)
static void update_siblings_masks(unsigned int cpuid)
{
struct cpu_topology *cpu_topo, *cpuid_topo = &cpu_topology[cpuid];
+ int node = cpu_to_node(cpuid);
int cpu;
/* update core and thread sibling masks */
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
+ if (cpu_to_node(cpu) == node)
+ cpumask_set_cpu(cpu, &cpu_topo->node_siblings);
+
if (cpuid_topo->llc_id == cpu_topo->llc_id)
cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
@@ -311,6 +315,9 @@ static void __init reset_cpu_topology(void)
cpumask_clear(&cpu_topo->llc_siblings);
cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
+ cpumask_clear(&cpu_topo->node_siblings);
+ cpumask_set_cpu(cpu, &cpu_topo->node_siblings);
+
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
--
2.14.3
^ permalink raw reply related
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Peter Rosin @ 2018-05-29 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529195708.1fa41027@bbrezillon>
Hi again!
I have spent some hours bringing out the old hardware with the 1024x768
panel from underneath the usual piles of junk and layers of dust...and
tried the current kernel on that one. And the display was stable even
when stressing with lots of NAND accesses. *boggle*
Then I remembered that I had lowered the pixel clock (from 71.1 MHz to
65 MHz (and reduced the vertical blanking to maintain the refresh rate).
I didn't notice that this fixed the NAND interference, probably because
I ran NAND without DMA at the time? Anyway, if I reset the pixel clock
to 71.1 MHz (without increasing the vertical blanking, just to be nasty)
I can get the artifacts easily. But running with a pixel clock of 65 MHz
is not a problem at all, so we can consider NAND-DMA with that panel
solved.
However, now we know that this setup needs relatively little to start
working, and that might be good if we want to see if other changes has
any effect. I will look into that tomorrow. And we can also get a grip
on the critical bandwidth.
But first, answers to some random questions...
On 2018-05-29 09:25, Eugen Hristev wrote:
> One more thing: what are the actual nand commands which you use when you
> get the glitches? read/write/erase ... ?
Erase seems to be least sensitive, read or write are worse (and similar)
according to my unscientific observations.
> What happens if you try to minimize the nand access? you also said at
> some point that only *some* nand accesses cause glitches.
These systems will normally not access the NAND, but the displays look
like total crap when this happens. It can happen even when sync()ing
small files, but doesn't happen for every little file. Writing out or
reading a large file to/from NAND invariably triggers the issue.
> Another thing : even if the LCD displays a still image, the DMA still
> feeds data to the LCD right ?
Absolutely. But since we are not playing some large video file (which
could have been stored on the NAND) we typically don't see the problem. It
only turns up in special circumstances. But these circumstances can't be
avoided and the display looks so freaking ugly when it happens...
On 2018-05-29 17:01, Eugen Hristev wrote:
> Then we can then try to force NFC SRAM DMA channels to use just DDR port
> 1 or 2 for memcpy ?
I *think* my "horrid" patch does that. Specifically this line
+ desc->txd.phys = (desc->txd.phys & ~3) | 1;
On 2018-05-28 18:09, Nicolas Ferre wrote:
> Can you try to make all that you can to maximize the blanking period of
> your screen (some are more tolerant than others according to that). By
> doing so, you would allow the LCD FIFO to recover better after each
> line. You might loose some columns on the side of your display but it
> would give us a good idea of how far we are from getting rid of those
> annoying LCD reset glitches (that are due to underruns on LCD FIFO).
I noticed that the 1024x768 panel is using 24bpp, not 16bpp as I
stated previously. Also, the horizontal blanking is 320 pixels, so a
total of 1024+320=1344 pixels/row and a pixel clock of 71.1 Mhz yields
18.9 us/row. The needed data during that time is 1024*24 bits so
1.30 Gbit/s. For the 65 MHz pixel clock, I get 1.19 Gbit/s. Assuming,
of course, that the pixel clock is actually what was requested... What
is the granularity of the pixel clock anyway?
For the bigger 1920x1080 panel, I have a horizontal blanking of 200
pixels and a pixel clock of 144 MHz, so 14.7 us/row -> 2.09 Gbit/s.
I suspect that no amount of fiddling with blanking is going to get
that anyway near the needed ~1.25 Gbit/s. Besides, the specs of the
panel say that the maximum horizontal blanking time is 280 pixels.
Seems futile to even try since this horizontal blanking time is so
much shorter for the larger panel (fewer and faster pixels) and the
longer time wasn't enough for the smaller panel to catch up. But ok,
in combination with something else it might be just enough. Will try
tomorrow...
On 2018-05-28 18:09, Boris Brezillon wrote:
> On Mon, 28 May 2018 17:52:53 +0200 Peter Rosin <peda@axentia.se> wrote:
>> The panels we are using only supports one resolution (each), but the issue
>> is there with both 1920x1080 at 16bpp and 1024x768 at 8bpp (~60Hz).
>
> Duh! This adds to the weirdness of this issue. I'd thought that by
> dividing the required bandwidth by 2 you would get a reliable setup.
I think I might have misremembered seeing the issue with 1024x768 at 8bpp.
Sorry. But it *is* there for (the old variant of) 1024x768 at 24bpp, and
that is still only 60% or so of the bandwidth compared to 1920x1080 at 16bpp.
Cheers,
Peter
^ permalink raw reply
* [PATCH 0/4] arm64: align KPTI interface with x86
From: Laura Abbott @ 2018-05-29 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524190932.32118-1-mlangsdo@redhat.com>
On 05/24/2018 12:09 PM, Mark Langsdorf wrote:
> ARM64 supports KPTI, but is missing some user interface features such as
> a debugfs entry compared to the x86 implementation.
I don't see an x86 debugfs entry for PTI, only the sysfs files. Was
this something that was discussed bug never merged?
Thanks,
Laura
^ permalink raw reply
* [PATCH 4/4] arm64: cpufeature: always log KPTI setting on boot
From: Laura Abbott @ 2018-05-29 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524190932.32118-5-mlangsdo@redhat.com>
On 05/24/2018 12:09 PM, Mark Langsdorf wrote:
> Always log KPTI setting at boot time, whether or not KPTI was forced
> by a kernel parameter.
>
> Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
> ---
> arch/arm64/kernel/cpufeature.c | 22 +++++++++++++---------
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 697a6ef..e50bf3c 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -889,16 +889,20 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> __pti_enabled = __kpti_forced > 0;
> pr_info_once("kernel page table isolation forced %s by %s\n",
> __pti_enabled ? "ON" : "OFF", str);
> + } else {
> + /* Useful for KASLR robustness */
> + if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> + __pti_enabled = true;
> + /* Don't force KPTI for CPUs that are not vulnerable */
> + else if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
> + __pti_enabled = false;
> + /* Defer to CPU feature registers */
> + else
> + __pti_enabled = !has_cpuid_feature(entry, scope);
> +
> + pr_info_once("kernel page table isolation %s by %s\n",
> + __pti_enabled ? "ON" : "OFF", str);
I think this needs an update for the default logged, otherwise it
incorrectly states it was set by command line:
# dmesg | grep isolation
[ 0.000000] CPU features: kernel page table isolation ON by command line option
[ 0.000000] CPU features: detected: Kernel page table isolation (KPTI)
# cat /proc/cmdline
nokaslr slub_debug=- console=ttyAMA0 debug_pagealloc=on earlycon=pl011,0x9000000
> }
> - /* Useful for KASLR robustness */
> - else if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> - __pti_enabled = true;
> - /* Don't force KPTI for CPUs that are not vulnerable */
> - else if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
> - __pti_enabled = false;
> - /* Defer to CPU feature registers */
> - else
> - __pti_enabled = !has_cpuid_feature(entry, scope);
>
> return __pti_enabled;
> }
>
^ permalink raw reply
* v4.17-rc1: regressions on N900, N950
From: Sebastian Reichel @ 2018-05-29 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529204517.GA6765@amd>
Hi Pavel,
On Tue, May 29, 2018 at 10:45:17PM +0200, Pavel Machek wrote:
> > > > still results in working touchscreen, removing any of the three fields
> > > > breaks it again.
> > >
> > > I bisected one regression down, see "omapdrm regression in v4.17-rc series"
> > > not sure if it covers all the issues being discussed here though.
> >
> > Reverting 24aac6011f70 fixes screen on n900 in v4.17-rc for me. (But
> > strange dependency on tsc2005 at 0 is still there).
>
> Laurent, your patch looks pretty obvious, but unfortunately breaks
> display on Nokia N900.
>
> The patch is pretty big as is, perhaps you have version split to sdi
> => *sdi and then static => dynamic allocation?
There is a queued fix:
https://github.com/freedesktop/drm-misc/commit/2bc5ff0bdc00d81d719dad74589317a260d583ed
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180529/77c08194/attachment.sig>
^ permalink raw reply
* [PATCH v9 00/12] Support PPTT for ARM64
From: Jeremy Linton @ 2018-05-29 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529201623.GA591@arm.com>
On 05/29/2018 03:16 PM, Will Deacon wrote:
> Hi Geert,
>
> On Tue, May 29, 2018 at 05:51:29PM +0200, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>>
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> Damn, sorry for wasting your time. For the record, Catalin's been seeing
> boot failures under KVM on a non-big/LITTLE machine that bisect reliably
> to this patch, but we've also not been able to explain them. Worse, adding
> so much as a printk makes the problem disappear.
I was about to post a patch to remove the numa check if CONFIG_NUMA
disabled. But that seems pointless if the its happening with numa
enabled. So assuming, its the removal of the core from the numa mask
which is causing problems. It looks like numa_clear_node() might cause
similar problems when numa is enabled. In my case the problem I see is
NULL dereference in __bitmap_intersect called from select_task_rq_fair.
That said, I only see the problem when CONFIG_NUMA isn't set.
So, I've also got another work around which caches the numa node to the
cpu_topology and then only builds it when store_cpu_topology() is
called. That should stabilize the numa mask, and assure that the bit
maps are correct when the scheduler requests them.
Do you guys want that patch, or are we looking for a deeper root cause?
^ permalink raw reply
* [PATCH v4 5/7] scsi: ipr: Eliminate duplicate barriers on weakly-ordered archs
From: Brian King @ 2018-05-29 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1521514207-10695-6-git-send-email-okaya@codeaurora.org>
On 03/19/2018 09:50 PM, Sinan Kaya wrote:
> Code includes barrier() followed by writel(). writel() already has a
> barrier
> on some architectures like arm64.
>
> This ends up CPU observing two barriers back to back before executing the
> register write.
>
> Since code already has an explicit barrier call, changing writeX() to
> writeX_relaxed().
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/scsi/ipr.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
> index e07dd99..209adac 100644
> --- a/drivers/scsi/ipr.c
> +++ b/drivers/scsi/ipr.c
> @@ -762,9 +762,9 @@ static void ipr_mask_and_clear_interrupts(struct ipr_ioa_cfg *ioa_cfg,
>
> /* Set interrupt mask to stop all new interrupts */
> if (ioa_cfg->sis64)
> - writeq(~0, ioa_cfg->regs.set_interrupt_mask_reg);
> + writeq_relaxed(~0, ioa_cfg->regs.set_interrupt_mask_reg);
> else
> - writel(~0, ioa_cfg->regs.set_interrupt_mask_reg);
> + writel_relaxed(~0, ioa_cfg->regs.set_interrupt_mask_reg);
>
> /* Clear any pending interrupts */
> if (ioa_cfg->sis64)
> @@ -8435,7 +8435,8 @@ static int ipr_reset_enable_ioa(struct ipr_cmnd *ipr_cmd)
> wmb();
> if (ioa_cfg->sis64) {
> /* Set the adapter to the correct endian mode. */
> - writel(IPR_ENDIAN_SWAP_KEY, ioa_cfg->regs.endian_swap_reg);
> + writel_relaxed(IPR_ENDIAN_SWAP_KEY,
> + ioa_cfg->regs.endian_swap_reg);
> int_reg = readl(ioa_cfg->regs.endian_swap_reg);
> }
>
Looks fine to me. Thanks.
Acked-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* v4.17-rc1: regressions on N900, N950
From: Pavel Machek @ 2018-05-29 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524094705.GA16705@amd>
Hi!
> > > still results in working touchscreen, removing any of the three fields
> > > breaks it again.
> >
> > I bisected one regression down, see "omapdrm regression in v4.17-rc series"
> > not sure if it covers all the issues being discussed here though.
>
> Reverting 24aac6011f70 fixes screen on n900 in v4.17-rc for me. (But
> strange dependency on tsc2005 at 0 is still there).
Laurent, your patch looks pretty obvious, but unfortunately breaks
display on Nokia N900.
The patch is pretty big as is, perhaps you have version split to sdi
=> *sdi and then static => dynamic allocation?
Thanks,
Pavel
commit 24aac6011f704d69b5f34514923413f85669f282
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: Tue Feb 13 14:00:47 2018 +0200
drm: omapdrm: sdi: Allocate the sdi private data structure
dynamically
The sdi private data structure is currently stored as a global
variable. While no platform with multiple SDI encoders
currently exists
nor is planned, this doesn't comply with the kernel device
model and
should thus be fixed.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180529/4beb1f9c/attachment.sig>
^ permalink raw reply
* [PATCH v5 2/2] arm64: signal: Report signal frame size to userspace via auxv
From: Will Deacon @ 2018-05-29 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527261428-6662-3-git-send-email-Dave.Martin@arm.com>
Hi Dave,
Cheers for respinning this. Just one observation below, which I only just
thought about.
On Fri, May 25, 2018 at 04:17:08PM +0100, Dave Martin wrote:
> Stateful CPU architecture extensions may require the signal frame
> to grow to a size that exceeds the arch's MINSIGSTKSZ #define.
> However, changing this #define is an ABI break.
>
> To allow userspace the option of determining the signal frame size
> in a more forwards-compatible way, this patch adds a new auxv entry
> tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame
> size that the process can observe during its lifetime.
>
> If AT_MINSIGSTKSZ is absent from the aux vector, the caller can
> assume that the MINSIGSTKSZ #define is sufficient. This allows for
> a consistent interface with older kernels that do not provide
> AT_MINSIGSTKSZ.
>
> The idea is that libc could expose this via sysconf() or some
> similar mechanism.
>
> There is deliberately no AT_SIGSTKSZ. The kernel knows nothing
> about userspace's own stack overheads and should not pretend to
> know.
[...]
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index fac1c4d..8cf112b 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -121,6 +121,9 @@
>
> #ifndef __ASSEMBLY__
>
> +#include <linux/bug.h>
> +#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
> +
> typedef unsigned long elf_greg_t;
>
> #define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))
> @@ -148,6 +151,14 @@ typedef struct user_fpsimd_state elf_fpregset_t;
> do { \
> NEW_AUX_ENT(AT_SYSINFO_EHDR, \
> (elf_addr_t)current->mm->context.vdso); \
> + \
> + /* \
> + * Should always be nonzero unless there's a kernel bug. \
> + * If we haven't determined a sensible value to give to \
> + * userspace, omit the entry: \
> + */ \
> + if (likely(signal_minsigstksz)) \
> + NEW_AUX_ENT(AT_MINSIGSTKSZ, signal_minsigstksz); \
> } while (0)
I think this is the desired behaviour, but now I'm worried that we're forced
to have AT_VECTOR_SIZE_ARCH defined as 2 and, whilst you're correct that the
ELF loader deals with this gracefuly, the FDPIC loader looks a lot less
robust (in particular, my reading is that it decrements the stack pointer
and then pushes these entries in reverse order by overloading NEW_AUX_ENT).
There's also some checkpoint save/restore code in kernel/sys.c that looks
like it could end up with uninitialised stack for the omitted entry.
Can we spit out an AT_IGNORE entry as an else clause if signal_minsigstksz
is zero?
Will
^ permalink raw reply
* [GIT PULL] ARM: dts: socfpga: NAND fixes for v4.17
From: Dinh Nguyen @ 2018-05-29 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515134416.11349-1-dinguyen@kernel.org>
Ping?
On 05/15/2018 08:44 AM, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
>
> Please pull in these NAND fixes for v4.17.
>
> Thanks,
> Dinh
>
> The following changes since commit 67b8d5c7081221efa252e111cd52532ec6d4266f:
>
> Linux 4.17-rc5 (2018-05-13 16:15:17 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_nand_fix_v4.17
>
> for you to fetch changes up to 3877ef7a1ccecaae378c497e1dcddbc2dccb664c:
>
> ARM: dts: socfpga: Fix NAND controller node compatible for Arria10 (2018-05-14 10:16:56 -0500)
>
> ----------------------------------------------------------------
> ARM: dts: socfpga: fix NAND support
> - NAND should be using nand_x_clk, not nand_clk
> - fix NAND node compatible for Cyclone5 and Arria10
>
> ----------------------------------------------------------------
> Dinh Nguyen (1):
> ARM: dts: socfpga: Fix NAND controller node compatible for Arria10
>
> Marek Vasut (2):
> ARM: dts: socfpga: Fix NAND controller clock supply
> ARM: dts: socfpga: Fix NAND controller node compatible
>
> arch/arm/boot/dts/socfpga.dtsi | 4 ++--
> arch/arm/boot/dts/socfpga_arria10.dtsi | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
^ permalink raw reply
* [GIT PULL] ARM: dts: socfpga: NAND fixes for v4.17
From: Dinh Nguyen @ 2018-05-29 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515134416.11349-1-dinguyen@kernel.org>
Ping?
On 05/15/2018 08:44 AM, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
>
> Please pull in these NAND fixes for v4.17.
>
> Thanks,
> Dinh
>
> The following changes since commit 67b8d5c7081221efa252e111cd52532ec6d4266f:
>
> Linux 4.17-rc5 (2018-05-13 16:15:17 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_nand_fix_v4.17
>
> for you to fetch changes up to 3877ef7a1ccecaae378c497e1dcddbc2dccb664c:
>
> ARM: dts: socfpga: Fix NAND controller node compatible for Arria10 (2018-05-14 10:16:56 -0500)
>
> ----------------------------------------------------------------
> ARM: dts: socfpga: fix NAND support
> - NAND should be using nand_x_clk, not nand_clk
> - fix NAND node compatible for Cyclone5 and Arria10
>
> ----------------------------------------------------------------
> Dinh Nguyen (1):
> ARM: dts: socfpga: Fix NAND controller node compatible for Arria10
>
> Marek Vasut (2):
> ARM: dts: socfpga: Fix NAND controller clock supply
> ARM: dts: socfpga: Fix NAND controller node compatible
>
> arch/arm/boot/dts/socfpga.dtsi | 4 ++--
> arch/arm/boot/dts/socfpga_arria10.dtsi | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
^ permalink raw reply
* [patch v25 0/4] JTAG driver introduction
From: Andy Shevchenko @ 2018-05-29 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527605618-15705-1-git-send-email-oleksandrs@mellanox.com>
On Tue, May 29, 2018 at 5:53 PM, Oleksandr Shamray
<oleksandrs@mellanox.com> wrote:
Please, STOP spamming mailing lists. Give (potential) reviewers time
to look at this.
In any case you already missed a next cycle, so, calm down and better
collect reports and address comments thoroughly.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [GIT PULL] SoCFPGA DTS updates for v4.18, part 2
From: Dinh Nguyen @ 2018-05-29 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514135144.26872-1-dinguyen@kernel.org>
Ping?
On 05/14/2018 08:51 AM, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
>
> Please pull in more updates for SoCFPGA Stratix10 DTS for v4.18.
>
> Thanks,
> Dinh
>
> The following changes since commit ab50a44404a53b12554005ed4c5a1b3547ac9492:
>
> arm64: dts: stratix10: Add PL330 DMAC to Stratix10 dts (2018-04-16 15:58:58 -0500)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git socfpga_for_next_v4.18_dts_v2
>
> for you to fetch changes up to 91fdd8274f32987760bbdb2981b4a896e338c09e:
>
> arm64: dts: stratix10: add sdram ecc (2018-05-08 08:11:29 -0500)
>
> ----------------------------------------------------------------
> Bartosz Golaszewski (1):
> ARM: dts: consistently use 'atmel' as at24 manufacturer in cyclone5
>
> Ooi, Joyce (1):
> arm64: dts: stratix10: Change pad skew values for EMAC0 PHY driver
>
> Thor Thayer (1):
> arm64: dts: stratix10: add sdram ecc
>
> arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 6 +++---
> arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 12 ++++++++++++
> arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts | 2 +-
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
^ permalink raw reply
* [GIT PULL] SoCFPGA DTS updates for v4.18
From: Dinh Nguyen @ 2018-05-29 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1524494393-8052-1-git-send-email-dinguyen@kernel.org>
Ping?
On 04/23/2018 09:39 AM, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
>
> Please full in these SoCFPGA Stratix10 DTS updates for v4.18.
>
> Thanks,
> Dinh
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_updates_for_v4.18_part1
>
> for you to fetch changes up to ab50a44404a53b12554005ed4c5a1b3547ac9492:
>
> arm64: dts: stratix10: Add PL330 DMAC to Stratix10 dts (2018-04-16 15:58:58 -0500)
>
> ----------------------------------------------------------------
> SoCFPGA DTS updates for v4.18
> - Stratix10 platform updates
> - Populate clock properties for platform
> - Enable DMA and I2C
>
> ----------------------------------------------------------------
> Alan Tull (1):
> arm64: dts: stratix10: enable i2c, add i2c periperals
>
> Dinh Nguyen (1):
> arm64: dts: stratix10: use clock bindings for the Stratix10 platform
>
> Graham Moore (1):
> arm64: dts: stratix10: Add PL330 DMAC to Stratix10 dts
>
> arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 71 +++++++++++++++++++++-
> .../boot/dts/altera/socfpga_stratix10_socdk.dts | 42 +++++++++++++
> 2 files changed, 111 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* [GIT PULL] SoCFPGA DTS updates for v4.18
From: Dinh Nguyen @ 2018-05-29 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1524494393-8052-1-git-send-email-dinguyen@kernel.org>
Ping?
On 04/23/2018 09:39 AM, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
>
> Please full in these SoCFPGA Stratix10 DTS updates for v4.18.
>
> Thanks,
> Dinh
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_updates_for_v4.18_part1
>
> for you to fetch changes up to ab50a44404a53b12554005ed4c5a1b3547ac9492:
>
> arm64: dts: stratix10: Add PL330 DMAC to Stratix10 dts (2018-04-16 15:58:58 -0500)
>
> ----------------------------------------------------------------
> SoCFPGA DTS updates for v4.18
> - Stratix10 platform updates
> - Populate clock properties for platform
> - Enable DMA and I2C
>
> ----------------------------------------------------------------
> Alan Tull (1):
> arm64: dts: stratix10: enable i2c, add i2c periperals
>
> Dinh Nguyen (1):
> arm64: dts: stratix10: use clock bindings for the Stratix10 platform
>
> Graham Moore (1):
> arm64: dts: stratix10: Add PL330 DMAC to Stratix10 dts
>
> arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 71 +++++++++++++++++++++-
> .../boot/dts/altera/socfpga_stratix10_socdk.dts | 42 +++++++++++++
> 2 files changed, 111 insertions(+), 2 deletions(-)
>
^ 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