* [PATCH v4 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Robin Murphy @ 2016-11-14 12:16 UTC (permalink / raw)
To: linux-arm-kernel
With the new dma_{map,unmap}_resource() functions added to the DMA API
for the benefit of cases like slave DMA, add suitable implementations to
the arsenal of our generic layer. Since cache maintenance should not be
a concern, these can both be standalone callback implementations without
the need for arch code wrappers.
CC: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v4: Add the missed static qualifier (thanks Catalin)
drivers/iommu/dma-iommu.c | 24 +++++++++++++++++++++---
include/linux/dma-iommu.h | 4 ++++
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c5ab8667e6f2..2db0d641cf45 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -432,13 +432,12 @@ int iommu_dma_mmap(struct page **pages, size_t size, struct vm_area_struct *vma)
return ret;
}
-dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
- unsigned long offset, size_t size, int prot)
+static dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
+ size_t size, int prot)
{
dma_addr_t dma_addr;
struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
struct iova_domain *iovad = cookie_iovad(domain);
- phys_addr_t phys = page_to_phys(page) + offset;
size_t iova_off = iova_offset(iovad, phys);
size_t len = iova_align(iovad, size + iova_off);
struct iova *iova = __alloc_iova(domain, len, dma_get_mask(dev));
@@ -454,6 +453,12 @@ dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
return dma_addr + iova_off;
}
+dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size, int prot)
+{
+ return __iommu_dma_map(dev, page_to_phys(page) + offset, size, prot);
+}
+
void iommu_dma_unmap_page(struct device *dev, dma_addr_t handle, size_t size,
enum dma_data_direction dir, unsigned long attrs)
{
@@ -624,6 +629,19 @@ void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
__iommu_dma_unmap(iommu_get_domain_for_dev(dev), sg_dma_address(sg));
}
+dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ return __iommu_dma_map(dev, phys, size,
+ dma_direction_to_prot(dir, false) | IOMMU_MMIO);
+}
+
+void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ __iommu_dma_unmap(iommu_get_domain_for_dev(dev), handle);
+}
+
int iommu_dma_supported(struct device *dev, u64 mask)
{
/*
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 32c589062bd9..7f7e9a7e3839 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -61,6 +61,10 @@ void iommu_dma_unmap_page(struct device *dev, dma_addr_t handle, size_t size,
enum dma_data_direction dir, unsigned long attrs);
void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
enum dma_data_direction dir, unsigned long attrs);
+dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size, enum dma_data_direction dir, unsigned long attrs);
+void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs);
int iommu_dma_supported(struct device *dev, u64 mask);
int iommu_dma_mapping_error(struct device *dev, dma_addr_t dma_addr);
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v4 2/2] arm64: Wire up iommu_dma_{map, unmap}_resource()
From: Robin Murphy @ 2016-11-14 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d1cbd5ce714ce3c978aa8bfcb31def87d7919198.1479125555.git.robin.murphy@arm.com>
With no coherency to worry about, just plug'em straight in.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
arch/arm64/mm/dma-mapping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 3f74d0d98de6..5cd0a383b14b 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -796,6 +796,8 @@ static struct dma_map_ops iommu_dma_ops = {
.sync_single_for_device = __iommu_sync_single_for_device,
.sync_sg_for_cpu = __iommu_sync_sg_for_cpu,
.sync_sg_for_device = __iommu_sync_sg_for_device,
+ .map_resource = iommu_dma_map_resource,
+ .unmap_resource = iommu_dma_unmap_resource,
.dma_supported = iommu_dma_supported,
.mapping_error = iommu_dma_mapping_error,
};
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v2 10/10] ARM: dts: rockchip: add rockchip RK1108 Evaluation board
From: Andy Yan @ 2016-11-14 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479124550-24037-1-git-send-email-andy.yan@rock-chips.com>
RK1108 EVB is designed by Rockchip for CVR field.
This patch add basic support for it, which can boot with
initramfs into shell.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v2:
- move the board in the rockchip.txt to the block of Rockchip boards
Documentation/devicetree/bindings/arm/rockchip.txt | 5 +-
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk1108-evb.dts | 69 ++++++++++++++++++++++
3 files changed, 74 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/rk1108-evb.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index 10b92b5..e658b62 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -1,6 +1,5 @@
Rockchip platforms device tree bindings
---------------------------------------
-
- Kylin RK3036 board:
Required root node properties:
- compatible = "rockchip,kylin-rk3036", "rockchip,rk3036";
@@ -111,6 +110,10 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "rockchip,px5-evb", "rockchip,px5", "rockchip,rk3368";
+- Rockchip RK1108 Evaluation board
+ Required root node properties:
+ - compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
+
- Rockchip RK3368 evb:
Required root node properties:
- compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e49476a..249dca9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -635,6 +635,7 @@ dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pba8.dtb \
arm-realview-pbx-a9.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
+ rk1108-evb.dtb \
rk3036-evb.dtb \
rk3036-kylin.dtb \
rk3066a-bqcurie2.dtb \
diff --git a/arch/arm/boot/dts/rk1108-evb.dts b/arch/arm/boot/dts/rk1108-evb.dts
new file mode 100644
index 0000000..3956cff
--- /dev/null
+++ b/arch/arm/boot/dts/rk1108-evb.dts
@@ -0,0 +1,69 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk1108.dtsi"
+
+/ {
+ model = "Rockchip RK1108 Evaluation board";
+ compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
+
+ memory at 60000000 {
+ device_type = "memory";
+ reg = <0x60000000 0x08000000>;
+ };
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: tomas.hlavacek at nic.cz @ 2016-11-14 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105203841.9661-1-uwe@kleine-koenig.org>
Hello Uwe and all!
On Sat, Nov 5, 2016 at 9:38 PM, Uwe Kleine-K?nig
<uwe@kleine-koenig.org> wrote:
> This machine is an open hardware router by cz.nic driven by a
> Marvell Armada 385.
>
> Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> ---
>
> Hello,
>
> the following components are working:
>
> - WAN port
> - eMMC
But I not not sure about DDR50 mode. At least with kernel 4.4, that we
use in production, we had to limit to SDR50 to overcome I/O errors and
communication instability, if I can remember it correctly. So it might
need more testing with the current kernel.
>
> - UART0
> - USB
It is worth noting that the USB 2.0 interface of Armada 385 is wired to
USB pinout of the last (right-most) PCIe connector. The two USB3
interfaces routed through SERDES 1 and 3 go directly to the external
USB connectors.
>
> Still missing is support for the switch. Wireless fails to probe,
> didn't
> debug this up to now. SFP is untested as is UART1.
Actually SFP is connected to SGMII interface of eth1, which is routed
through SERDES 5. The SGMII line is shared between the SFP and metallic
PHY 88E1514. There is a autonomous high-speed switch connected to the
SFPDET signal from SFP cage. It disconnects the metallic SFP and
connects SGMII to SFP once the module is connected.
The SFP is also connected to the I2C mux port 4 and to GPIO expander
for reading/driving SFPDET, LOS, TXFLT, TXDIS signals:
&i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins>;
status = "okay";
clock-frequency = <100000>;
i2cmux at 70 {
compatible = "nxp,pca9547";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
status = "okay";
...
i2c at 7 {
/* SFP+ GPIO expander */
#address-cells = <1>;
#size-cells = <0>;
reg = <7>;
sfpgpio: gpio at 71 {
compatible = "nxp,pca9538";
reg = <0x71>;
interrupt-parent = <&gpio1>;
interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
gpio-controller;
#gpio-cells = <2>;
};
};
};
};
We have our proprietary support hacked onto mvneta driver for
disconnecting PHY on the fly. It is a bit nasty, so I suggest to ignore
SFP in this DTS altogether and let's wait till "phylink based SFP
module support" or something alike hits upstream, so we can base the
SFP support on solid code; unless somebody has a better idea, of course.
>
>
> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> new file mode 100644
> index 000000000000..d3cd8a4d713d
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -0,0 +1,246 @@
...
> +
> + /* USB part of the eSATA/USB 2.0 port */
This comment is perhaps some error inherited from my development DTS.
We do not have any eSATA, perhaps PCIe/USB 2.0 slot.
>
> + usb at 58000 {
> + status = "okay";
> + };
> +
> +
> +ð0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ge0_rgmii_pins>;
> + status = "okay";
> + phy-mode = "rgmii-id";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> +};
> +
> +ð1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ge1_rgmii_pins>;
> + status = "okay";
> + phy-mode = "rgmii-id";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> +};
> +
Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176
switch. The problem is that from what I have read so far the switch can
not operate in DSA mode with two CPU ports. We currently operate the
switch in "normal mode" with the eth0 and eth1 set to fixed-link
1000/full and with proprietary driver (derived from OpenWRT switch
drivers). I would say that these records for eth0 and eth1 are
therefore redundant, because it does nothing without the switch support
and it would most likely change once we have DSA driver (using only
eth0).
Tomas
^ permalink raw reply
* [PATCH 1/2] pinctrl: bcm2835: Fix ints for GPIOs 28-31 & 46-53
From: Linus Walleij @ 2016-11-14 12:23 UTC (permalink / raw)
To: linux-arm-kernel
From: Phil Elwell <phil@raspberrypi.org>
Contrary to the documentation, the BCM2835 GPIO controller actually
has four interrupt lines - one each for the three IRQ groups and one
common. Confusingly, the GPIO interrupt groups don't correspond
directly with the GPIO control banks. Instead, GPIOs 0-27 generate IRQ
GPIO0, 28-45 IRQ GPIO1 and 46-53 IRQ GPIO2.
Awkwardly, the GPIOs for IRQ GPIO1 straddle two 32-entry GPIO banks,
so split out a function to process the interrupts for a single GPIO
bank.
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
I want to apply this to cater for my GPIOLIB_IRQCHIP
refactorings.
---
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 51 ++++++++++++++++++++++++++---------
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index b2dd278f18b1..1d8fc104e26b 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -47,6 +47,7 @@
#define MODULE_NAME "pinctrl-bcm2835"
#define BCM2835_NUM_GPIOS 54
#define BCM2835_NUM_BANKS 2
+#define BCM2835_NUM_IRQS 3
#define BCM2835_PIN_BITMAP_SZ \
DIV_ROUND_UP(BCM2835_NUM_GPIOS, sizeof(unsigned long) * 8)
@@ -88,13 +89,13 @@ enum bcm2835_pinconf_pull {
struct bcm2835_gpio_irqdata {
struct bcm2835_pinctrl *pc;
- int bank;
+ int irqgroup;
};
struct bcm2835_pinctrl {
struct device *dev;
void __iomem *base;
- int irq[BCM2835_NUM_BANKS];
+ int irq[BCM2835_NUM_IRQS];
/* note: locking assumes each bank will have its own unsigned long */
unsigned long enabled_irq_map[BCM2835_NUM_BANKS];
@@ -105,7 +106,7 @@ struct bcm2835_pinctrl {
struct gpio_chip gpio_chip;
struct pinctrl_gpio_range gpio_range;
- struct bcm2835_gpio_irqdata irq_data[BCM2835_NUM_BANKS];
+ struct bcm2835_gpio_irqdata irq_data[BCM2835_NUM_IRQS];
spinlock_t irq_lock[BCM2835_NUM_BANKS];
};
@@ -391,17 +392,16 @@ static struct gpio_chip bcm2835_gpio_chip = {
.can_sleep = false,
};
-static irqreturn_t bcm2835_gpio_irq_handler(int irq, void *dev_id)
+static int bcm2835_gpio_irq_handle_bank(struct bcm2835_pinctrl *pc,
+ unsigned int bank, u32 mask)
{
- struct bcm2835_gpio_irqdata *irqdata = dev_id;
- struct bcm2835_pinctrl *pc = irqdata->pc;
- int bank = irqdata->bank;
unsigned long events;
unsigned offset;
unsigned gpio;
unsigned int type;
events = bcm2835_gpio_rd(pc, GPEDS0 + bank * 4);
+ events &= mask;
events &= pc->enabled_irq_map[bank];
for_each_set_bit(offset, &events, 32) {
gpio = (32 * bank) + offset;
@@ -409,7 +409,30 @@ static irqreturn_t bcm2835_gpio_irq_handler(int irq, void *dev_id)
generic_handle_irq(irq_linear_revmap(pc->irq_domain, gpio));
}
- return events ? IRQ_HANDLED : IRQ_NONE;
+
+ return (events != 0);
+}
+
+static irqreturn_t bcm2835_gpio_irq_handler(int irq, void *dev_id)
+{
+ struct bcm2835_gpio_irqdata *irqdata = dev_id;
+ struct bcm2835_pinctrl *pc = irqdata->pc;
+ int handled = 0;
+
+ switch (irqdata->irqgroup) {
+ case 0: /* IRQ0 covers GPIOs 0-27 */
+ handled = bcm2835_gpio_irq_handle_bank(pc, 0, 0x0fffffff);
+ break;
+ case 1: /* IRQ1 covers GPIOs 28-45 */
+ handled = bcm2835_gpio_irq_handle_bank(pc, 0, 0xf0000000) |
+ bcm2835_gpio_irq_handle_bank(pc, 1, 0x00003fff);
+ break;
+ case 2: /* IRQ2 covers GPIOs 46-53 */
+ handled = bcm2835_gpio_irq_handle_bank(pc, 1, 0x003fc000);
+ break;
+ }
+
+ return handled ? IRQ_HANDLED : IRQ_NONE;
}
static inline void __bcm2835_gpio_irq_config(struct bcm2835_pinctrl *pc,
@@ -1000,8 +1023,6 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
for (i = 0; i < BCM2835_NUM_BANKS; i++) {
unsigned long events;
unsigned offset;
- int len;
- char *name;
/* clear event detection flags */
bcm2835_gpio_wr(pc, GPREN0 + i * 4, 0);
@@ -1016,10 +1037,15 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
for_each_set_bit(offset, &events, 32)
bcm2835_gpio_wr(pc, GPEDS0 + i * 4, BIT(offset));
+ spin_lock_init(&pc->irq_lock[i]);
+ }
+
+ for (i = 0; i < BCM2835_NUM_IRQS; i++) {
+ int len;
+ char *name;
pc->irq[i] = irq_of_parse_and_map(np, i);
pc->irq_data[i].pc = pc;
- pc->irq_data[i].bank = i;
- spin_lock_init(&pc->irq_lock[i]);
+ pc->irq_data[i].irqgroup = i;
len = strlen(dev_name(pc->dev)) + 16;
name = devm_kzalloc(pc->dev, len, GFP_KERNEL);
@@ -1076,6 +1102,7 @@ static struct platform_driver bcm2835_pinctrl_driver = {
.remove = bcm2835_pinctrl_remove,
.driver = {
.name = MODULE_NAME,
+ .owner = THIS_MODULE,
.of_match_table = bcm2835_pinctrl_match,
},
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] pinctrl: bcm2835: Return pins to inputs when freed
From: Linus Walleij @ 2016-11-14 12:23 UTC (permalink / raw)
To: linux-arm-kernel
From: Phil Elwell <phil@raspberrypi.org>
When dynamically unloading overlays, it is important that freed pins are
restored to being inputs to prevent functions from being enabled in
multiple places at once.
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
I want to apply this to cater for my GPIOLIB_IRQCHIP
refactorings.
---
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 1d8fc104e26b..2df59d9964a2 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -844,6 +844,16 @@ static const struct pinctrl_ops bcm2835_pctl_ops = {
.dt_free_map = bcm2835_pctl_dt_free_map,
};
+static int bcm2835_pmx_free(struct pinctrl_dev *pctldev,
+ unsigned offset)
+{
+ struct bcm2835_pinctrl *pc = pinctrl_dev_get_drvdata(pctldev);
+
+ /* disable by setting to GPIO_IN */
+ bcm2835_pinctrl_fsel_set(pc, offset, BCM2835_FSEL_GPIO_IN);
+ return 0;
+}
+
static int bcm2835_pmx_get_functions_count(struct pinctrl_dev *pctldev)
{
return BCM2835_FSEL_COUNT;
@@ -903,6 +913,7 @@ static int bcm2835_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
}
static const struct pinmux_ops bcm2835_pmx_ops = {
+ .free = bcm2835_pmx_free,
.get_functions_count = bcm2835_pmx_get_functions_count,
.get_function_name = bcm2835_pmx_get_function_name,
.get_function_groups = bcm2835_pmx_get_function_groups,
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] net: thunderx: Fix configuration of L3/L4 length checking
From: Corentin Labbe @ 2016-11-14 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479120886-13425-4-git-send-email-sunil.kovvuri@gmail.com>
On Mon, Nov 14, 2016 at 04:24:44PM +0530, sunil.kovvuri at gmail.com wrote:
> From: Sunil Goutham <sgoutham@cavium.com>
>
> This patch fixes enabling of HW verification of L3/L4 length and
> TCP/UDP checksum which is currently being cleared. Also fixed VLAN
> stripping config which is being cleared when multiqset is enabled.
>
> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
> ---
> drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
> index f0e0ca6..3050177 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
> @@ -538,9 +538,12 @@ static void nicvf_rcv_queue_config(struct nicvf *nic, struct queue_set *qs,
> mbx.rq.cfg = (1ULL << 62) | (RQ_CQ_DROP << 8);
> nicvf_send_msg_to_pf(nic, &mbx);
>
> - nicvf_queue_reg_write(nic, NIC_QSET_RQ_GEN_CFG, 0, 0x00);
> - if (!nic->sqs_mode)
> + if (!nic->sqs_mode && (qidx == 0)) {
> + /* Enable checking L3/L4 length and TCP/UDP checksums */
> + nicvf_queue_reg_write(nic, NIC_QSET_RQ_GEN_CFG, 0,
> + ((1 << 24) | (1 << 23) | (1 << 21)));
Hello
You could use the BIT() macro here
Regards
^ permalink raw reply
* [RFC v2 3/8] iommu/dma: Allow MSI-only cookies
From: Robin Murphy @ 2016-11-14 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258646-3117-4-git-send-email-eric.auger@redhat.com>
On 04/11/16 11:24, Eric Auger wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> IOMMU domain users such as VFIO face a similar problem to DMA API ops
> with regard to mapping MSI messages in systems where the MSI write is
> subject to IOMMU translation. With the relevant infrastructure now in
> place for managed DMA domains, it's actually really simple for other
> users to piggyback off that and reap the benefits without giving up
> their own IOVA management, and without having to reinvent their own
> wheel in the MSI layer.
>
> Allow such users to opt into automatic MSI remapping by dedicating a
> region of their IOVA space to a managed cookie.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
OK, following the discussion elsewhere I've had a go at the less stupid,
but more involved, version. Thoughts?
Robin.
----->8-----
From: Robin Murphy <robin.murphy@arm.com>
Subject: [RFC PATCH] iommu/dma: Allow MSI-only cookies
IOMMU domain users such as VFIO face a similar problem to DMA API ops
with regard to mapping MSI messages in systems where the MSI write is
subject to IOMMU translation. With the relevant infrastructure now in
place for managed DMA domains, it's actually really simple for other
users to piggyback off that and reap the benefits without giving up
their own IOVA management, and without having to reinvent their own
wheel in the MSI layer.
Allow such users to opt into automatic MSI remapping by dedicating a
region of their IOVA space to a managed cookie, and extend the mapping
routine to implement a trivial linear allocator in such cases, to avoid
the needless overhead of a full-blown IOVA domain.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/dma-iommu.c | 118 ++++++++++++++++++++++++++++++++++++----------
include/linux/dma-iommu.h | 6 +++
2 files changed, 100 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c5ab8667e6f2..33d66a8273c6 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -37,10 +37,19 @@ struct iommu_dma_msi_page {
phys_addr_t phys;
};
+enum iommu_dma_cookie_type {
+ IOMMU_DMA_IOVA_COOKIE,
+ IOMMU_DMA_MSI_COOKIE,
+};
+
struct iommu_dma_cookie {
- struct iova_domain iovad;
- struct list_head msi_page_list;
- spinlock_t msi_lock;
+ union {
+ struct iova_domain iovad;
+ dma_addr_t msi_iova;
+ };
+ struct list_head msi_page_list;
+ spinlock_t msi_lock;
+ enum iommu_dma_cookie_type type;
};
static inline struct iova_domain *cookie_iovad(struct iommu_domain *domain)
@@ -53,6 +62,19 @@ int iommu_dma_init(void)
return iova_cache_get();
}
+static struct iommu_dma_cookie *__cookie_alloc(enum iommu_dma_cookie_type type)
+{
+ struct iommu_dma_cookie *cookie;
+
+ cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
+ if (cookie) {
+ spin_lock_init(&cookie->msi_lock);
+ INIT_LIST_HEAD(&cookie->msi_page_list);
+ cookie->type = type;
+ }
+ return cookie;
+}
+
/**
* iommu_get_dma_cookie - Acquire DMA-API resources for a domain
* @domain: IOMMU domain to prepare for DMA-API usage
@@ -62,25 +84,53 @@ int iommu_dma_init(void)
*/
int iommu_get_dma_cookie(struct iommu_domain *domain)
{
- struct iommu_dma_cookie *cookie;
-
if (domain->iova_cookie)
return -EEXIST;
- cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
- if (!cookie)
+ domain->iova_cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
+ if (!domain->iova_cookie)
return -ENOMEM;
- spin_lock_init(&cookie->msi_lock);
- INIT_LIST_HEAD(&cookie->msi_page_list);
- domain->iova_cookie = cookie;
return 0;
}
EXPORT_SYMBOL(iommu_get_dma_cookie);
/**
+ * iommu_get_msi_cookie - Acquire just MSI remapping resources
+ * @domain: IOMMU domain to prepare
+ * @base: Start address of IOVA region for MSI mappings
+ *
+ * Users who manage their own IOVA allocation and do not want DMA API support,
+ * but would still like to take advantage of automatic MSI remapping, can use
+ * this to initialise their own domain appropriately. Users should reserve a
+ * contiguous IOVA region, starting at @base, large enough to accommodate the
+ * number of PAGE_SIZE mappings necessary to cover every MSI doorbell address
+ * used by the devices attached to @domain.
+ */
+int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
+{
+ struct iommu_dma_cookie *cookie;
+
+ if (domain->type != IOMMU_DOMAIN_UNMANAGED)
+ return -EINVAL;
+
+ if (domain->iova_cookie)
+ return -EEXIST;
+
+ cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
+ if (!cookie)
+ return -ENOMEM;
+
+ cookie->msi_iova = base;
+ domain->iova_cookie = cookie;
+ return 0;
+}
+EXPORT_SYMBOL(iommu_get_msi_cookie);
+
+/**
* iommu_put_dma_cookie - Release a domain's DMA mapping resources
- * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
+ * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie() or
+ * iommu_get_msi_cookie()
*
* IOMMU drivers should normally call this from their domain_free callback.
*/
@@ -92,7 +142,7 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
if (!cookie)
return;
- if (cookie->iovad.granule)
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE && cookie->iovad.granule)
put_iova_domain(&cookie->iovad);
list_for_each_entry_safe(msi, tmp, &cookie->msi_page_list, list) {
@@ -137,11 +187,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
u64 size, struct device *dev)
{
- struct iova_domain *iovad = cookie_iovad(domain);
+ struct iommu_dma_cookie *cookie = domain->iova_cookie;
+ struct iova_domain *iovad = &cookie->iovad;
unsigned long order, base_pfn, end_pfn;
- if (!iovad)
- return -ENODEV;
+ if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
+ return -EINVAL;
/* Use the smallest supported page size for IOVA granularity */
order = __ffs(domain->pgsize_bitmap);
@@ -644,11 +695,21 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
{
struct iommu_dma_cookie *cookie = domain->iova_cookie;
struct iommu_dma_msi_page *msi_page;
- struct iova_domain *iovad = &cookie->iovad;
+ struct iova_domain *iovad;
struct iova *iova;
int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+ size_t size;
+
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE) {
+ iovad = &cookie->iovad;
+ size = iovad->granule;
+ } else {
+ iovad = NULL;
+ size = PAGE_SIZE;
+ }
+
+ msi_addr &= ~(phys_addr_t)(size - 1);
- msi_addr &= ~(phys_addr_t)iova_mask(iovad);
list_for_each_entry(msi_page, &cookie->msi_page_list, list)
if (msi_page->phys == msi_addr)
return msi_page;
@@ -657,13 +718,18 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
if (!msi_page)
return NULL;
- iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));
- if (!iova)
- goto out_free_page;
-
msi_page->phys = msi_addr;
- msi_page->iova = iova_dma_addr(iovad, iova);
- if (iommu_map(domain, msi_page->iova, msi_addr, iovad->granule, prot))
+ if (iovad) {
+ iova = __alloc_iova(domain, size, dma_get_mask(dev));
+ if (!iova)
+ goto out_free_page;
+ msi_page->iova = iova_dma_addr(iovad, iova);
+ } else {
+ msi_page->iova = cookie->msi_iova;
+ cookie->msi_iova += size;
+ }
+
+ if (iommu_map(domain, msi_page->iova, msi_addr, size, prot))
goto out_free_iova;
INIT_LIST_HEAD(&msi_page->list);
@@ -671,7 +737,10 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
return msi_page;
out_free_iova:
- __free_iova(iovad, iova);
+ if (iovad)
+ __free_iova(iovad, iova);
+ else
+ cookie->msi_iova -= size;
out_free_page:
kfree(msi_page);
return NULL;
@@ -716,3 +785,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
msg->address_lo += lower_32_bits(msi_page->iova);
}
}
+
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 32c589062bd9..d69932474576 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -27,6 +27,7 @@ int iommu_dma_init(void);
/* Domain management interface for IOMMU drivers */
int iommu_get_dma_cookie(struct iommu_domain *domain);
+int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
void iommu_put_dma_cookie(struct iommu_domain *domain);
/* Setup call for arch DMA mapping code */
@@ -82,6 +83,11 @@ static inline int iommu_get_dma_cookie(struct iommu_domain *domain)
return -ENODEV;
}
+static inline int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
+{
+ return -ENODEV;
+}
+
static inline void iommu_put_dma_cookie(struct iommu_domain *domain)
{
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v2] ARM: dts: vfxxx: Enable DMA for DSPI2 and DSPI3
From: Sanchayan Maity @ 2016-11-14 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110114505.17618-1-maitysanchayan@gmail.com>
Enable DMA for DSPI2 and DSPI3 on Vybrid.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
Changes since v1:
Add signed-off-by missing in v1.
---
arch/arm/boot/dts/vfxxx.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 000550f..e9d2847 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -573,6 +573,9 @@
clocks = <&clks VF610_CLK_DSPI2>;
clock-names = "dspi";
spi-num-chipselects = <2>;
+ dmas = <&edma1 0 10>,
+ <&edma1 0 11>;
+ dma-names = "rx", "tx";
status = "disabled";
};
@@ -585,6 +588,9 @@
clocks = <&clks VF610_CLK_DSPI3>;
clock-names = "dspi";
spi-num-chipselects = <2>;
+ dmas = <&edma1 0 12>,
+ <&edma1 0 13>;
+ dma-names = "rx", "tx";
status = "disabled";
};
--
2.10.2
^ permalink raw reply related
* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-14 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <127cdd42-6fd8-c671-60b7-3826b351577f@samsung.com>
Hi,
On 14-11-16 10:12, Jacek Anaszewski wrote:
> Hi,
>
> On 11/13/2016 02:52 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 13-11-16 12:44, Jacek Anaszewski wrote:
>>> Hi,
>>>
>>> On 11/12/2016 10:14 PM, Hans de Goede wrote:
>>
>> <snip>
>>
>>>>>> So I would like to propose creating a new read-write
>>>>>> user_brightness file.
>>>>>>
>>>>>> The write behavior would be 100% identical to the brightness
>>>>>> file (in code terms it will call the same store function).
>>>>>>
>>>>>> The the read behavior otoh will be different: it will shows
>>>>>> the last brightness as set by the user, this would show the
>>>>>> read behavior we really want of brightness: show the real
>>>>>> brightness when not blinking / triggers are active and show
>>>>>> the brightness used when on when blinking / triggers are active.
>>>>>>
>>>>>> We could then add poll support on this new user_brightness
>>>>>> file, thus avoiding the problem with the extra cpu-load on
>>>>>> notifications on blinking / triggers.
>>>>>
>>>>> I agree that user_brightness allows to solve the issues you raised
>>>>> about inconsistent write and read brightness' semantics
>>>>> (which is not that painful IMHO).
>>>>>
>>>>> Reporting non-user brightness changes on user_brightness file
>>>>> doesn't sound reasonable though.
>>>>
>>>> The changes I'm interested in are user brightness changes they
>>>> are just not done through sysfs, but through a hardwired hotkey,
>>>> they are however very much done by the user.
>>>
>>> Ah, so this file name would be misleading especially taking into account
>>> the context in which "user" is used in kernel, which predominantly
>>> means "userspace", e.g. copy_to_user(), copy_from_user().
>>>
>>>>> Also, how would we read the
>>>>> brightness set by the firmware? We'd have to read brightness
>>>>> file, so still two files would have to be opened which is
>>>>> a second drawback of this approach.
>>>>
>>>> No, look carefully at the definition of the read behavior
>>>> I plan to put in the ABI doc:
>>>
>>> OK, "user" was what confused me. So in this case changes made
>>> by the firmware even if in a result of user activity
>>> (pressing hardware key) obviously cannot be treated similarly
>>> to the changes made from the userspace context.
>>
>> In the end both result on the brightness of the device
>> changing, so any userspace process interested in monitoring
>> the brightness will want to know about both type of changes.
>>
>>> Unless you're able to give references to the kernel code which
>>> contradict my judgement.
>>
>> AFAIK the audio code will signal volume changes done by
>> hardwired buttons the same way as audio changes done
>> by userspace calling into the kernel. This also makes
>> sense because in the end, what is interesting for a
>> mixer app, is that the volume changed, and what the
>> new volume is.
>
> OK, so it is indeed similar to your LED use case. Nonetheless
> in case of LED controllers it is also possible that hardware
> adjusts LED brightness in case of low battery voltage.
>
> If a device is able e.g. to generate an interrupt to notify this
> kind of event, then we would like also to be able to notify the client
> about that. It wouldn't be user generated brightness change though.
>
>>>> "Reading this file will return the actual led brightness
>>>> when not blinking and no triggers are active; reading this
>>>> file will return the brightness used when the led is on
>>>> when blinking or triggers are active."
>>>
>>> This is unnecessarily entangled. Blinking means timer trigger
>>> is active.
>>
>> Ok.
>>
>>>> So for e.g. the backlit keyboard case reading this single
>>>> file will return the actual brightness of the backlight,
>>>> since this does not involve blinking or triggers.
>>>>
>>>> Basically the idea is that the user_brightness file
>>>> will have the semantics which IMHO the brightness file
>>>> itself should have had from the beginning, but which
>>>> we can't change now due to ABI reasons.
>>>
>>> And in fact introducing user_brightness file would indeed
>>> fix that shortcoming. However without providing notifications
>>> of hw brightness changes on it.
>>
>> See above, I believe such a file should report any
>> changes in brightness, except those caused by triggers,
>> so it would report hw brightness changes.
>>
>> Anyways if you're not interested in fixing the
>> shortcomings of the current read behavior on the
>> brightness file (I'm fine with that, I can live
>> with the shortcomings) I suggest that we simply go
>> with v2 of my poll() patch.
>
> v2 entails power consumption related issues.
>
> Generally I think that we could add the file you proposed,
> however it would be good to devise a name which will cover
> also the cases when brightness is changed by firmware without
> user interaction.
>
>>>>> Having no difference in this area between the two approaches
>>>>> I'm still in favour of the read-only file for notifying
>>>>> brightness changes procured by hardware.
>>>>
>>>> That brings back the needing 2 fds problem; and does
>>>> not solve userspace not being able to reliably read
>>>> the led on brightness when blinking or using triggers.
>>>>
>>>> And this also has the issue that one is doing poll() on
>>>> one fd to detect changes on another fd,
>>>
>>> It is not necessarily true. We can treat the polling on
>>> hw_brightness_change file as a means to detect brightness
>>> changes procured by hardware and we can read that brightness
>>> by executing read on this same fd. It could return -ENODATA
>>> if no such an event has occurred so far.
>>
>> That would still require 2 fds as userspace also wants to
>> be able to set the keyboard backlight, but allowing read()
>> on the hw_brightness_change file at least fixes the weirdness
>> where userspace gets woken from poll() without being able to
>> read. So if you insist on going the hw_brightness_change file
>> route, then I can live with that (and upower will simply
>> need to open 2 fds, that is doable).
>>
>> But, BUT, I would greatly prefer to just go for v4 of my
>> patch, which fixes the only real problem we've seen with
>> my patch as original merged without adding a new, somewhat
>> convoluted sysfs attribute.
>
> Hmm, v4 still calls led_notify_brightness_change(led_cdev)
> from both __led_set_brightness() and __led_set_brightness_blocking().
Ugh, I see I accidentally send a v4 twice, instead of
calling the version which dropped those called v5 as
I should have, sorry.
The v4 which I would like to see merged, the one with
those calls dropped, is here:
https://patchwork.kernel.org/patch/9423093/
Regards,
Hans
^ permalink raw reply
* [PATCH 1/2] ARM: always store CPU ID early into percpu data
From: Russell King @ 2016-11-14 12:57 UTC (permalink / raw)
To: linux-arm-kernel
Always store the CPU ID into the percpu data so that it is available
early on. This allows us to eliminate various is_smp() tests that
select between reading the hardware CPU ID directly and reading from
the percpu data.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/include/asm/smp_plat.h | 5 +----
arch/arm/kernel/setup.c | 5 ++++-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index f9080717fc88..43f246b73ce7 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -34,10 +34,7 @@ static inline bool is_smp(void)
*/
static inline unsigned int smp_cpuid_part(int cpu)
{
- struct cpuinfo_arm *cpu_info = &per_cpu(cpu_data, cpu);
-
- return is_smp() ? cpu_info->cpuid & ARM_CPU_PART_MASK :
- read_cpuid_part();
+ return per_cpu(cpu_data, cpu).cpuid;
}
/* all SMP configurations have the extended CPUID registers */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 34e3f3c45634..80f45b01fbaa 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -724,6 +724,9 @@ static void __init setup_processor(void)
cacheid_init();
cpu_init();
+
+ /* Always setup the boot CPU ID in the per-cpu data */
+ per_cpu(cpu_data, smp_processor_id()).cpuid = read_cpuid_id();
}
void __init dump_machine_table(void)
@@ -1217,7 +1220,7 @@ static int c_show(struct seq_file *m, void *v)
* "processor". Give glibc what it expects.
*/
seq_printf(m, "processor\t: %d\n", i);
- cpuid = is_smp() ? per_cpu(cpu_data, i).cpuid : read_cpuid_id();
+ cpuid = per_cpu(cpu_data, i).cpuid;
seq_printf(m, "model name\t: %s rev %d (%s)\n",
cpu_name, cpuid & 15, elf_platform);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: rename is_smp()
From: Russell King @ 2016-11-14 12:57 UTC (permalink / raw)
To: linux-arm-kernel
is_smp() is causing some confusion - rename it to indicate that it's a
property of the CPU that we're running on, which is not the same as the
system. Document what and why it is being used at most sites.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
Some people are reporting that "is_smp()" is broken wrt Cortex-A15 CPUs
when they integrate a single Cortex-A15 SMP capable CPU into a
uniprocessor system. This is most likely because of a misunderstanding
about what is_smp() is really detected from: it's detected from the CPU
capabilities, not from the system capabilities. If the CPU says that it
is SMP capable (and it's not a broken Cortex-A9 core) we will make use
of various instructions which appear on SMP cores, and we set is_smp()
to follow that. So, is_smp() is more of a CPU capability rather than a
system capability.
Trying to use it as a system capability will lead to problems.
Arguably, the use of it in arch_irq_work_has_interrupt() is wrong,
because we don't know whether the GIC is SMP capable or not, but it's
currently the best we can do.
I felt the other two sites I left undocumented (which read the MPIDR)
were rather obvious - a uniprocessor only capable CPU doesn't have a
MPIDR.
Really, !cpu_smp() is an indication that the CPU is UP-only, not that
it is _S_MP capable, so even this is lightly misleading. I suppose
we could replace it with cpu_up_only() but I think that makes the code
harder to understand (due to double-negatives appearing in places.)
arch/arm/include/asm/cputype.h | 2 +-
arch/arm/include/asm/irq_work.h | 2 +-
arch/arm/include/asm/smp_plat.h | 11 +++++++----
arch/arm/kernel/devtree.c | 2 +-
arch/arm/kernel/module.c | 10 +++++++++-
arch/arm/kernel/setup.c | 7 ++++---
arch/arm/mach-mvebu/coherency.c | 4 ++--
arch/arm/mm/mmu.c | 13 ++++++++++++-
8 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 522b5feb4eaa..8c82e6b4961d 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -109,7 +109,7 @@ extern unsigned int processor_id;
/*
* The memory clobber prevents gcc 4.5 from reordering the mrc before
- * any is_smp() tests, which can cause undefined instruction aborts on
+ * any cpu_smp() tests, which can cause undefined instruction aborts on
* ARM1136 r0 due to the missing extended CP15 registers.
*/
#define read_cpuid_ext(ext_reg) \
diff --git a/arch/arm/include/asm/irq_work.h b/arch/arm/include/asm/irq_work.h
index 712d03e5973a..2dc8d7995b48 100644
--- a/arch/arm/include/asm/irq_work.h
+++ b/arch/arm/include/asm/irq_work.h
@@ -5,7 +5,7 @@
static inline bool arch_irq_work_has_interrupt(void)
{
- return is_smp();
+ return cpu_smp();
}
#endif /* _ASM_ARM_IRQ_WORK_H */
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 43f246b73ce7..bdba301d01e4 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -12,9 +12,10 @@
#include <asm/cputype.h>
/*
- * Return true if we are running on a SMP platform
+ * Return true if we are running on a CPU which supports SMP, and the
+ * kernel supports SMP.
*/
-static inline bool is_smp(void)
+static inline bool cpu_smp(void)
{
#ifndef CONFIG_SMP
return false;
@@ -43,7 +44,8 @@ static inline unsigned int smp_cpuid_part(int cpu)
#else
static inline int tlb_ops_need_broadcast(void)
{
- if (!is_smp())
+ /* Non-SMP CPUs don't need to check for broadcast */
+ if (!cpu_smp())
return 0;
return ((read_cpuid_ext(CPUID_EXT_MMFR3) >> 12) & 0xf) < 2;
@@ -55,7 +57,8 @@ static inline int tlb_ops_need_broadcast(void)
#else
static inline int cache_ops_need_broadcast(void)
{
- if (!is_smp())
+ /* Non-SMP CPUs don't need to check for broadcast */
+ if (!cpu_smp())
return 0;
return ((read_cpuid_ext(CPUID_EXT_MMFR3) >> 12) & 0xf) < 1;
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index f676febbb270..19a9653df6d2 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -78,7 +78,7 @@ void __init arm_dt_init_cpu_maps(void)
struct device_node *cpu, *cpus;
int found_method = 0;
u32 i, j, cpuidx = 1;
- u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
+ u32 mpidr = cpu_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
bool bootcpu_valid = false;
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 4f14b5ce6535..0b49aa426180 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -374,12 +374,20 @@ int module_finalize(const Elf32_Ehdr *hdr, const Elf_Shdr *sechdrs,
fixup_pv_table((void *)s->sh_addr, s->sh_size);
#endif
s = find_mod_section(hdr, sechdrs, ".alt.smp.init");
- if (s && !is_smp())
+ if (s && !cpu_smp()) {
+ /*
+ * Modules running on non-SMP capable CPUs must not use SMP
+ * instructions, as they may cause undefined instruction
+ * exceptions. This means we have to fix up the SMP
+ * alternatives on SMP-on-UP modules, and are unable to load
+ * modules built for SMP-only configurations.
+ */
#ifdef CONFIG_SMP_ON_UP
fixup_smp((void *)s->sh_addr, s->sh_size);
#else
return -EINVAL;
#endif
+ }
return 0;
}
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 80f45b01fbaa..cdf71941c129 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -584,7 +584,7 @@ u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
void __init smp_setup_processor_id(void)
{
int i;
- u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
+ u32 mpidr = cpu_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
u32 cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
cpu_logical_map(0) = cpu;
@@ -1112,7 +1112,8 @@ void __init setup_arch(char **cmdline_p)
arm_dt_init_cpu_maps();
psci_dt_init();
#ifdef CONFIG_SMP
- if (is_smp()) {
+ if (cpu_smp()) {
+ /* Ignore SMP on non-SMP capable CPUs */
if (!mdesc->smp_init || !mdesc->smp_init()) {
if (psci_smp_available())
smp_set_ops(&psci_smp_ops);
@@ -1124,7 +1125,7 @@ void __init setup_arch(char **cmdline_p)
}
#endif
- if (!is_smp())
+ if (!cpu_smp())
hyp_mode_check();
reserve_crashkernel();
diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index ae2a018b9305..fe4b1e15ebb8 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -216,7 +216,7 @@ static int coherency_type(void)
*
* Note that this means that on Armada 370, there is currently
* no way to use hardware I/O coherency, because even when
- * CONFIG_SMP is enabled, is_smp() returns false due to the
+ * CONFIG_SMP is enabled, cpu_smp() returns false due to the
* Armada 370 being a single-core processor. To lift this
* limitation, we would have to find a way to make the cache
* policy set to write-allocate (on all Armada SoCs), and to
@@ -226,7 +226,7 @@ static int coherency_type(void)
* where we don't know yet on which SoC we are running.
*/
- if (!is_smp())
+ if (!cpu_smp())
return COHERENCY_FABRIC_TYPE_NONE;
np = of_find_matching_node_and_match(NULL, of_coherency_table, &match);
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 4001dd15818d..d3dc758d5391 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -449,11 +449,22 @@ static void __init build_mem_type_table(void)
ecc_mask = 0;
}
- if (is_smp()) {
+ if (cpu_smp()) {
+ /*
+ * SMP requires a write-allocate cache policy for proper
+ * functioning of the coherency protocol. If the CPU supports
+ * MP extensions, assume we are part of a SMP system.
+ */
if (cachepolicy != CPOLICY_WRITEALLOC) {
pr_warn("Forcing write-allocate cache policy for SMP\n");
cachepolicy = CPOLICY_WRITEALLOC;
}
+
+ /*
+ * SMP systems depend on the S bit being shared for coherency
+ * between the CPUs. However, setting this for non-SMP CPUs
+ * may result in the mappings being treated as uncached.
+ */
if (!(initial_pmd_value & PMD_SECT_S)) {
pr_warn("Forcing shared mappings for SMP\n");
initial_pmd_value |= PMD_SECT_S;
--
2.7.4
^ permalink raw reply related
* [GIT PULL] DaVinci additional driver support for v4.10
From: Sekhar Nori @ 2016-11-14 12:58 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.10/drivers
for you to fetch changes up to 8e7223fc8626db7c302136747bb68213100d290c:
bus: davinci: add support for da8xx bus master priority control (2016-11-14 17:20:29 +0530)
----------------------------------------------------------------
This pull request adds two new drivers for better
support for LCD found on DaVinci DA8xx devices.
They allow configuration of memory interface and
bus priorities on the SoC to allow sufficient
bandwidth for the LCD and prevent underruns.
The DT bindings have been reviewed by Rob and
patches have been reviewed by Kevin.
----------------------------------------------------------------
Bartosz Golaszewski (2):
memory: davinci: add support for da8xx DDR2/mDDR controller
bus: davinci: add support for da8xx bus master priority control
.../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
.../memory-controllers/ti-da8xx-ddrctl.txt | 20 ++
drivers/bus/Kconfig | 9 +
drivers/bus/Makefile | 2 +
drivers/bus/da8xx-mstpri.c | 269 +++++++++++++++++++++
drivers/memory/Kconfig | 8 +
drivers/memory/Makefile | 1 +
drivers/memory/da8xx-ddrctl.c | 175 ++++++++++++++
8 files changed, 504 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
create mode 100644 drivers/bus/da8xx-mstpri.c
create mode 100644 drivers/memory/da8xx-ddrctl.c
^ permalink raw reply
* [PATCH] ARM: ftrace: fix syscall name matching
From: Rabin Vincent @ 2016-11-14 13:03 UTC (permalink / raw)
To: linux-arm-kernel
From: Rabin Vincent <rabinv@axis.com>
ARM has a few system calls (most notably mmap) for which the names of
the functions which are referenced in the syscall table do not match the
names of the syscall tracepoints. As a consequence of this, these
tracepoints are not made available. Implement
arch_syscall_match_sym_name to fix this and allow tracing even these
system calls.
Signed-off-by: Rabin Vincent <rabinv@axis.com>
---
arch/arm/include/asm/ftrace.h | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index bfe2a2f..8467909 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -54,6 +54,27 @@ static inline void *return_address(unsigned int level)
#define ftrace_return_address(n) return_address(n)
+#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
+
+static inline bool arch_syscall_match_sym_name(const char *sym,
+ const char *name)
+{
+ /* Skip sys_ */
+ sym += 4;
+ name += 4;
+
+ if (!strcmp(sym, "mmap2"))
+ sym = "mmap_pgoff";
+ else if (!strcmp(sym, "statfs64_wrapper"))
+ sym = "statfs64";
+ else if (!strcmp(sym, "fstatfs64_wrapper"))
+ sym = "fstatfs64";
+ else if (!strcmp(sym, "arm_fadvise64_64"))
+ sym = "fadvise64_64";
+
+ return !strcmp(sym, name);
+}
+
#endif /* ifndef __ASSEMBLY__ */
#endif /* _ASM_ARM_FTRACE */
--
2.1.4
^ permalink raw reply related
* [PATCH] input: bma150: Only claim to support the bma180 if the separate iio bma180 driver is not build
From: Hans de Goede @ 2016-11-14 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114053523.GA21471@dtor-ws>
Hi,
On 14-11-16 06:35, Dmitry Torokhov wrote:
> Hi Hans,
>
> On Sun, Nov 13, 2016 at 07:34:07PM +0100, Hans de Goede wrote:
>> commit ef3714fdbc8d ("Input: bma150 - extend chip detection for bma180"),
>> adds bma180 chip-ids to the input bma150 driver, assuming that they are
>> 100% compatible, but the bma180 is not compatible with the bma150 at all,
>> it has 14 bits resolution instead of 10, and it has quite different
>> control registers too.
>>
>> Treating the bma180 as a bma150 wrt its data registers will just result
>> in throwing away the lowest 4 bits, which is not too bad. But the ctrl
>> registers are a different story. Things happen to just work but supporting
>> that certainly does not make treating the bma180 the same as the bma150
>> right.
>>
>> Since some setups depend on the evdev interface the bma150 driver offers
>> on top of the bma180, we cannot simply remove the bma180 ids.
>>
>> So this commit only removes the bma180 id when the bma180 iio driver,
>> which does treat the bma180 properly, is enabled.
>>
>> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/input/misc/bma150.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
>> index b0d4453..9fa1c9a 100644
>> --- a/drivers/input/misc/bma150.c
>> +++ b/drivers/input/misc/bma150.c
>> @@ -539,7 +539,11 @@ static int bma150_probe(struct i2c_client *client,
>> }
>>
>> chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
>> - if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
>> + if (chip_id != BMA150_CHIP_ID
>> +#ifndef CONFIG_BMA180
>> + && chip_id != BMA180_CHIP_ID
>> +#endif
>
> Does not this break if bma180 is compiled as module? I'd rather we did
>
> if (chip_id != BMA150_CHIP_ID &&
> (IS_ENABLED(CONFIG_BMA180) || chip_id != BMA180_CHIP_ID)) {
> ...
Yes using IS_ENABLED() is a good idea, both for readability and for
the building as module reason. I'll send a v2.
Regards,
Hans
>
>
>> + ) {
>> dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
>> return -EINVAL;
>> }
>> @@ -643,7 +647,9 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
>>
>> static const struct i2c_device_id bma150_id[] = {
>> { "bma150", 0 },
>> +#ifndef CONFIG_BMA180
> #if !IS_ENABLED(CONFIG_BMA180)
>
>> { "bma180", 0 },
>> +#endif
>> { "smb380", 0 },
>> { "bma023", 0 },
>> { }
>> --
>> 2.9.3
>>
>
> Thanks.
>
^ permalink raw reply
* [PATCH] spi: atmel: Fix scheduling while atomic
From: Alexandre Belloni @ 2016-11-14 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478792090-6376-1-git-send-email-ben.whitten@gmail.com>
Hi,
On 10/11/2016 at 15:34:50 +0000, ben.whitten at gmail.com wrote :
> From: Ben Whitten <ben.whitten@lairdtech.com>
>
> A call to clk_get_rate appears to be called in the context of an interrupt,
> cache the bus clock for the frequency calculations in transmission.
>
> This fixes a 'BUG: scheduling while atomic' and
> 'WARNING: CPU: 0 PID: 777 at kernel/sched/core.c:2960 atmel_spi_unlock'
>
> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> Signed-off-by: Steve deRosier <steve.derosier@lairdtech.com>
The spi subsystem maintainer is not copied so this fix will not be
applied.
Else, it seems ok to me.
> ---
> drivers/spi/spi-atmel.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index 8feac59..c281d1a 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -295,6 +295,7 @@ struct atmel_spi {
> int irq;
> struct clk *clk;
> struct platform_device *pdev;
> + unsigned long spi_clk;
>
> struct spi_transfer *current_transfer;
> int current_remaining_bytes;
> @@ -864,7 +865,7 @@ static int atmel_spi_set_xfer_speed(struct atmel_spi *as,
> unsigned long bus_hz;
>
> /* v1 chips start out at half the peripheral bus speed. */
> - bus_hz = clk_get_rate(as->clk);
> + bus_hz = as->spi_clk;
> if (!atmel_spi_is_v2(as))
> bus_hz /= 2;
>
> @@ -1606,6 +1607,9 @@ static int atmel_spi_probe(struct platform_device *pdev)
> ret = clk_prepare_enable(clk);
> if (ret)
> goto out_free_irq;
> +
> + as->spi_clk = clk_get_rate(clk);
> +
> spi_writel(as, CR, SPI_BIT(SWRST));
> spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
> if (as->caps.has_wdrbt) {
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Andrew Lunn @ 2016-11-14 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479126185.15557.5@smtp.gmail.com>
> Actually SFP is connected to SGMII interface of eth1, which is
> routed through SERDES 5.
You say eth1 here. Yet lower down you say got eth0 and eth1 are
connected to the switch?
> We have our proprietary support hacked onto mvneta driver for
> disconnecting PHY on the fly. It is a bit nasty, so I suggest to
> ignore SFP in this DTS altogether and let's wait till "phylink based
> SFP module support" or something alike hits upstream, so we can base
> the SFP support on solid code;
It would be great if you could work on getting the phylink patches
into mainline. It is something i have wanted to do for a long time,
but it is too low down on my priority list to get to. The code is high
quality, so i don't think there will be too many issues. It probably
just needs splitting up into smaller batches, submitting, and working
on any comments.
> Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176
> switch. The problem is that from what I have read so far the switch
> can not operate in DSA mode with two CPU ports.
Again, this is something i wanted to do, and i did have a prototype at
one point. But again, not enough time. If you have resources to work
on this, i can find my code, explain my ideas, and let you complete
it.
Andrew
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 3/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-11-14 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cbbf8ae1-ff29-2a83-265b-a9ff5bacf97b@redhat.com>
On Mon, Nov 14, 2016 at 11:00:32AM +0100, Hans de Goede wrote:
> > > > +&usbphy {
> > > > + /* USB VBUS is always on */
> > >
> > > You can put the always on regulators (I'm guessing reg_vcc5v0 ?) here.
> >
> > AFAIK the regulator properties are optional the the USB PHY.
> > So we probably don't need to add it. Hans (CC-ed) could explain
> > his original intent?
>
> I've made the regulators optional exactly for boards like these,
> where there is no regulator. Likely the Vbus is simply wired
> directly to the 5V DC-in jack. So IMHO adding something like
> the fixed reg_vcc5v0 a supply here just makes the dt
> harder to read.
It also makes the regulator tree more complete and accurate because
you'd list all the devices that are needing those regulators. That
would also make it easier to deal with in the future.
But fair enough.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/4cfb2c48/attachment.sig>
^ permalink raw reply
* [PATCH v2] input: bma150: Only claim to support the bma180 if the separate iio bma180 driver is not build
From: Hans de Goede @ 2016-11-14 13:11 UTC (permalink / raw)
To: linux-arm-kernel
commit ef3714fdbc8d ("Input: bma150 - extend chip detection for bma180"),
adds bma180 chip-ids to the input bma150 driver, assuming that they are
100% compatible, but the bma180 is not compatible with the bma150 at all,
it has 14 bits resolution instead of 10, and it has quite different
control registers too.
Treating the bma180 as a bma150 wrt its data registers will just result
in throwing away the lowest 4 bits, which is not too bad. But the ctrl
registers are a different story. Things happen to just work but supporting
that certainly does not make treating the bma180 the same as the bma150
right.
Since some setups depend on the evdev interface the bma150 driver offers
on top of the bma180, we cannot simply remove the bma180 ids.
So this commit only removes the bma180 id when the bma180 iio driver,
which does treat the bma180 properly, is enabled.
Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Use IS_ENABLED(CONFIG_BMA180) instead of #ifdef CONFIG_BMA180
---
drivers/input/misc/bma150.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
index b0d4453..2124390 100644
--- a/drivers/input/misc/bma150.c
+++ b/drivers/input/misc/bma150.c
@@ -538,8 +538,13 @@ static int bma150_probe(struct i2c_client *client,
return -EIO;
}
+ /*
+ * Note if the IIO CONFIG_BMA180 driver is enabled we want to fail
+ * the probe for the bma180 as the iio driver is preferred.
+ */
chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
- if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
+ if (chip_id != BMA150_CHIP_ID &&
+ (IS_ENABLED(CONFIG_BMA180) || chip_id != BMA180_CHIP_ID)) {
dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
return -EINVAL;
}
@@ -643,7 +648,9 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
static const struct i2c_device_id bma150_id[] = {
{ "bma150", 0 },
+#if !IS_ENABLED(CONFIG_BMA180)
{ "bma180", 0 },
+#endif
{ "smb380", 0 },
{ "bma023", 0 },
{ }
--
2.9.3
^ permalink raw reply related
* Tegra baseline test results for v4.9-rc5
From: Jon Hunter @ 2016-11-14 13:19 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.9-rc5.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.9-rc5/20161114020102/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.9-rc4 (bc33b0ca11e3df467777a4fa7639ba488c9d4911)):
text data bss total kernel
-1032 -2736 0 -3768 defconfig
+1056 -8 0 +1048 multi_v7_defconfig
+688 -4104 0 -3416 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.9-rc4 (bc33b0ca11e3df467777a4fa7639ba488c9d4911))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
--
nvpublic
^ permalink raw reply
* [PATCH 04/16] ARM: realview: use generic API for enabling SCU
From: Pankaj Dubey @ 2016-11-14 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3587281.4kOCcW9Ryd@wuerfel>
Hi Arnd,
On 14 November 2016 at 17:26, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, November 14, 2016 10:31:59 AM CET Pankaj Dubey wrote:
>> static const struct of_device_id realview_scu_match[] = {
>> { .compatible = "arm,arm11mp-scu", },
>> - { .compatible = "arm,cortex-a9-scu", },
>> - { .compatible = "arm,cortex-a5-scu", },
>> { }
>> };
>>
>> @@ -41,27 +39,18 @@ static void __init realview_smp_prepare_cpus(unsigned int max_cpus)
>> struct device_node *np;
>> void __iomem *scu_base;
>> struct regmap *map;
>> - unsigned int ncores;
>> int i;
>>
>> - np = of_find_matching_node(NULL, realview_scu_match);
>> - if (!np) {
>> - pr_err("PLATSMP: No SCU base address\n");
>> - return;
>> + if (of_scu_enable()) {
>> + np = of_find_matching_node(NULL, realview_scu_match);
>> + scu_base = of_iomap(np, 0);
>> + of_node_put(np);
>> + if (!scu_base) {
>> + pr_err("PLATSMP: No SCU remap\n");
>> + return;
>> + }
>> + scu_enable(scu_base);
>> }
>>
>
> The only difference here seems to be that realview also needs to handle
> "arm,arm11mp-scu". Why not move that into the generic implementation?
>
Just checked scu binding documentation for "arm,arm11mp-scu" and came
to know its for ARM11 MPCore based SoC's SCU. So as you said, it can
surely be moved to genenric imeplemenation. Will do this change and
resubmit again.
Thanks,
Pankaj Dubey
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] ARM: rename is_smp()
From: Gregory CLEMENT @ 2016-11-14 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1c6GpW-0008DO-BD@rmk-PC.armlinux.org.uk>
Hi Russell,
On lun., nov. 14 2016, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> is_smp() is causing some confusion - rename it to indicate that it's a
> property of the CPU that we're running on, which is not the same as the
> system. Document what and why it is being used at most sites.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> Some people are reporting that "is_smp()" is broken wrt Cortex-A15 CPUs
> when they integrate a single Cortex-A15 SMP capable CPU into a
> uniprocessor system. This is most likely because of a misunderstanding
> about what is_smp() is really detected from: it's detected from the CPU
> capabilities, not from the system capabilities. If the CPU says that it
> is SMP capable (and it's not a broken Cortex-A9 core) we will make use
> of various instructions which appear on SMP cores, and we set is_smp()
> to follow that. So, is_smp() is more of a CPU capability rather than a
> system capability.
>
> Trying to use it as a system capability will lead to problems.
> Arguably, the use of it in arch_irq_work_has_interrupt() is wrong,
> because we don't know whether the GIC is SMP capable or not, but it's
> currently the best we can do.
>
> I felt the other two sites I left undocumented (which read the MPIDR)
> were rather obvious - a uniprocessor only capable CPU doesn't have a
> MPIDR.
>
> Really, !cpu_smp() is an indication that the CPU is UP-only, not that
> it is _S_MP capable, so even this is lightly misleading. I suppose
> we could replace it with cpu_up_only() but I think that makes the code
> harder to understand (due to double-negatives appearing in places.)
>
> arch/arm/include/asm/cputype.h | 2 +-
> arch/arm/include/asm/irq_work.h | 2 +-
> arch/arm/include/asm/smp_plat.h | 11 +++++++----
> arch/arm/kernel/devtree.c | 2 +-
> arch/arm/kernel/module.c | 10 +++++++++-
> arch/arm/kernel/setup.c | 7 ++++---
> arch/arm/mach-mvebu/coherency.c | 4 ++--
> arch/arm/mm/mmu.c | 13 ++++++++++++-
> 8 files changed, 37 insertions(+), 14 deletions(-)
[...]
> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
> index ae2a018b9305..fe4b1e15ebb8 100644
> --- a/arch/arm/mach-mvebu/coherency.c
> +++ b/arch/arm/mach-mvebu/coherency.c
> @@ -216,7 +216,7 @@ static int coherency_type(void)
> *
> * Note that this means that on Armada 370, there is currently
> * no way to use hardware I/O coherency, because even when
> - * CONFIG_SMP is enabled, is_smp() returns false due to the
> + * CONFIG_SMP is enabled, cpu_smp() returns false due to the
> * Armada 370 being a single-core processor. To lift this
> * limitation, we would have to find a way to make the cache
> * policy set to write-allocate (on all Armada SoCs), and to
> @@ -226,7 +226,7 @@ static int coherency_type(void)
> * where we don't know yet on which SoC we are running.
>
> */
> - if (!is_smp())
> + if (!cpu_smp())
> return COHERENCY_FABRIC_TYPE_NONE;
>
> np = of_find_matching_node_and_match(NULL, of_coherency_table, &match);
Unless I am wrong I don't see any modification of the code behavior:
just renaming the function and adding more comments. So it won't affect
our platform and I am OK with the new name which also match our
comments.
So, for this chunk:
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Thanks,
Gregory
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 4001dd15818d..d3dc758d5391 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -449,11 +449,22 @@ static void __init build_mem_type_table(void)
> ecc_mask = 0;
> }
>
> - if (is_smp()) {
> + if (cpu_smp()) {
> + /*
> + * SMP requires a write-allocate cache policy for proper
> + * functioning of the coherency protocol. If the CPU supports
> + * MP extensions, assume we are part of a SMP system.
> + */
> if (cachepolicy != CPOLICY_WRITEALLOC) {
> pr_warn("Forcing write-allocate cache policy for SMP\n");
> cachepolicy = CPOLICY_WRITEALLOC;
> }
> +
> + /*
> + * SMP systems depend on the S bit being shared for coherency
> + * between the CPUs. However, setting this for non-SMP CPUs
> + * may result in the mappings being treated as uncached.
> + */
> if (!(initial_pmd_value & PMD_SECT_S)) {
> pr_warn("Forcing shared mappings for SMP\n");
> initial_pmd_value |= PMD_SECT_S;
> --
> 2.7.4
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/1] ARM: dts: enable GPIO-b for Broadcom NSP
From: Yendapally Reddy Dhananjaya Reddy @ 2016-11-14 13:30 UTC (permalink / raw)
To: linux-arm-kernel
This enables the GPIO-b support for Broadcom NSP SoC
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 7c9e0fa..2f699a0 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -241,6 +241,16 @@
brcm,nand-has-wp;
};
+ gpiob: gpio at 30000 {
+ compatible = "brcm,iproc-nsp-gpio", "brcm,iproc-gpio";
+ reg = <0x30000 0x50>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ ngpios = <4>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
pwm: pwm at 31000 {
compatible = "brcm,iproc-pwm";
reg = <0x31000 0x28>;
--
2.1.0
^ permalink raw reply related
* [PATCH 2/2] ARM: rename is_smp()
From: Russell King - ARM Linux @ 2016-11-14 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <878tsmchyc.fsf@free-electrons.com>
On Mon, Nov 14, 2016 at 02:24:43PM +0100, Gregory CLEMENT wrote:
> Hi Russell,
>
> Unless I am wrong I don't see any modification of the code behavior:
> just renaming the function and adding more comments. So it won't affect
> our platform and I am OK with the new name which also match our
> comments.
That's correct - it's an exercise in renaming to a clearer name.
Thanks for the ack.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: ftrace: fix syscall name matching
From: Russell King - ARM Linux @ 2016-11-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479128625-20948-1-git-send-email-rabin.vincent@axis.com>
On Mon, Nov 14, 2016 at 02:03:45PM +0100, Rabin Vincent wrote:
> From: Rabin Vincent <rabinv@axis.com>
>
> ARM has a few system calls (most notably mmap) for which the names of
> the functions which are referenced in the syscall table do not match the
> names of the syscall tracepoints. As a consequence of this, these
> tracepoints are not made available. Implement
> arch_syscall_match_sym_name to fix this and allow tracing even these
> system calls.
>
> Signed-off-by: Rabin Vincent <rabinv@axis.com>
> ---
> arch/arm/include/asm/ftrace.h | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
> index bfe2a2f..8467909 100644
> --- a/arch/arm/include/asm/ftrace.h
> +++ b/arch/arm/include/asm/ftrace.h
> @@ -54,6 +54,27 @@ static inline void *return_address(unsigned int level)
>
> #define ftrace_return_address(n) return_address(n)
>
> +#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
> +
> +static inline bool arch_syscall_match_sym_name(const char *sym,
> + const char *name)
> +{
> + /* Skip sys_ */
> + sym += 4;
> + name += 4;
Is this really safe? What guarantees that we can wind forward four
bytes here? If it's always safe, it needs a better comment than just
two words.
> +
> + if (!strcmp(sym, "mmap2"))
> + sym = "mmap_pgoff";
> + else if (!strcmp(sym, "statfs64_wrapper"))
> + sym = "statfs64";
> + else if (!strcmp(sym, "fstatfs64_wrapper"))
> + sym = "fstatfs64";
> + else if (!strcmp(sym, "arm_fadvise64_64"))
> + sym = "fadvise64_64";
> +
> + return !strcmp(sym, name);
> +}
> +
> #endif /* ifndef __ASSEMBLY__ */
>
> #endif /* _ASM_ARM_FTRACE */
> --
> 2.1.4
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ 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