* [PATCH 01/14] ARM: OMAP2+: Remove legacy serial.c
From: Tony Lindgren @ 2016-11-11 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111191711.5079-1-tony@atomide.com>
We can now initialize the UARTs using device tree.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/serial.c | 332 -------------------------------------------
2 files changed, 1 insertion(+), 333 deletions(-)
delete mode 100644 arch/arm/mach-omap2/serial.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -6,7 +6,7 @@ ccflags-y := -I$(srctree)/$(src)/include \
-I$(srctree)/arch/arm/plat-omap/include
# Common support
-obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o timer.o pm.o \
+obj-y := id.o io.o control.o mux.o devices.o fb.o timer.o pm.o \
common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \
omap_device.o omap-headsmp.o sram.o drm.o
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
deleted file mode 100644
--- a/arch/arm/mach-omap2/serial.c
+++ /dev/null
@@ -1,332 +0,0 @@
-/*
- * arch/arm/mach-omap2/serial.c
- *
- * OMAP2 serial support.
- *
- * Copyright (C) 2005-2008 Nokia Corporation
- * Author: Paul Mundt <paul.mundt@nokia.com>
- *
- * Major rework for PM support by Kevin Hilman
- *
- * Based off of arch/arm/mach-omap/omap1/serial.c
- *
- * Copyright (C) 2009 Texas Instruments
- * Added OMAP4 support - Santosh Shilimkar <santosh.shilimkar@ti.com
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- */
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/clk.h>
-#include <linux/io.h>
-#include <linux/delay.h>
-#include <linux/platform_device.h>
-#include <linux/slab.h>
-#include <linux/pm_runtime.h>
-#include <linux/console.h>
-#include <linux/omap-dma.h>
-#include <linux/platform_data/serial-omap.h>
-
-#include "common.h"
-#include "omap_hwmod.h"
-#include "omap_device.h"
-#include "omap-pm.h"
-#include "soc.h"
-#include "prm2xxx_3xxx.h"
-#include "pm.h"
-#include "cm2xxx_3xxx.h"
-#include "prm-regbits-34xx.h"
-#include "control.h"
-#include "mux.h"
-#include "serial.h"
-
-/*
- * NOTE: By default the serial auto_suspend timeout is disabled as it causes
- * lost characters over the serial ports. This means that the UART clocks will
- * stay on until power/autosuspend_delay is set for the uart from sysfs.
- * This also causes that any deeper omap sleep states are blocked.
- */
-#define DEFAULT_AUTOSUSPEND_DELAY -1
-
-#define MAX_UART_HWMOD_NAME_LEN 16
-
-struct omap_uart_state {
- int num;
-
- struct list_head node;
- struct omap_hwmod *oh;
- struct omap_device_pad default_omap_uart_pads[2];
-};
-
-static LIST_HEAD(uart_list);
-static u8 num_uarts;
-static u8 console_uart_id = -1;
-static u8 uart_debug;
-
-#define DEFAULT_RXDMA_POLLRATE 1 /* RX DMA polling rate (us) */
-#define DEFAULT_RXDMA_BUFSIZE 4096 /* RX DMA buffer size */
-#define DEFAULT_RXDMA_TIMEOUT (3 * HZ)/* RX DMA timeout (jiffies) */
-
-static struct omap_uart_port_info omap_serial_default_info[] __initdata = {
- {
- .dma_enabled = false,
- .dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
- .dma_rx_poll_rate = DEFAULT_RXDMA_POLLRATE,
- .dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
- .autosuspend_timeout = DEFAULT_AUTOSUSPEND_DELAY,
- },
-};
-
-#ifdef CONFIG_PM
-static void omap_uart_enable_wakeup(struct device *dev, bool enable)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct omap_device *od = to_omap_device(pdev);
-
- if (!od)
- return;
-
- if (enable)
- omap_hwmod_enable_wakeup(od->hwmods[0]);
- else
- omap_hwmod_disable_wakeup(od->hwmods[0]);
-}
-
-#else
-static void omap_uart_enable_wakeup(struct device *dev, bool enable)
-{}
-#endif /* CONFIG_PM */
-
-#ifdef CONFIG_OMAP_MUX
-
-#define OMAP_UART_DEFAULT_PAD_NAME_LEN 28
-static char rx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN],
- tx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN] __initdata;
-
-static void __init
-omap_serial_fill_uart_tx_rx_pads(struct omap_board_data *bdata,
- struct omap_uart_state *uart)
-{
- uart->default_omap_uart_pads[0].name = rx_pad_name;
- uart->default_omap_uart_pads[0].flags = OMAP_DEVICE_PAD_REMUX |
- OMAP_DEVICE_PAD_WAKEUP;
- uart->default_omap_uart_pads[0].enable = OMAP_PIN_INPUT |
- OMAP_MUX_MODE0;
- uart->default_omap_uart_pads[0].idle = OMAP_PIN_INPUT | OMAP_MUX_MODE0;
- uart->default_omap_uart_pads[1].name = tx_pad_name;
- uart->default_omap_uart_pads[1].enable = OMAP_PIN_OUTPUT |
- OMAP_MUX_MODE0;
- bdata->pads = uart->default_omap_uart_pads;
- bdata->pads_cnt = ARRAY_SIZE(uart->default_omap_uart_pads);
-}
-
-static void __init omap_serial_check_wakeup(struct omap_board_data *bdata,
- struct omap_uart_state *uart)
-{
- struct omap_mux_partition *tx_partition = NULL, *rx_partition = NULL;
- struct omap_mux *rx_mux = NULL, *tx_mux = NULL;
- char *rx_fmt, *tx_fmt;
- int uart_nr = bdata->id + 1;
-
- if (bdata->id != 2) {
- rx_fmt = "uart%d_rx.uart%d_rx";
- tx_fmt = "uart%d_tx.uart%d_tx";
- } else {
- rx_fmt = "uart%d_rx_irrx.uart%d_rx_irrx";
- tx_fmt = "uart%d_tx_irtx.uart%d_tx_irtx";
- }
-
- snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, rx_fmt,
- uart_nr, uart_nr);
- snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, tx_fmt,
- uart_nr, uart_nr);
-
- if (omap_mux_get_by_name(rx_pad_name, &rx_partition, &rx_mux) >= 0 &&
- omap_mux_get_by_name
- (tx_pad_name, &tx_partition, &tx_mux) >= 0) {
- u16 tx_mode, rx_mode;
-
- tx_mode = omap_mux_read(tx_partition, tx_mux->reg_offset);
- rx_mode = omap_mux_read(rx_partition, rx_mux->reg_offset);
-
- /*
- * Check if uart is used in default tx/rx mode i.e. in mux mode0
- * if yes then configure rx pin for wake up capability
- */
- if (OMAP_MODE_UART(rx_mode) && OMAP_MODE_UART(tx_mode))
- omap_serial_fill_uart_tx_rx_pads(bdata, uart);
- }
-}
-#else
-static void __init omap_serial_check_wakeup(struct omap_board_data *bdata,
- struct omap_uart_state *uart)
-{
-}
-#endif
-
-static char *cmdline_find_option(char *str)
-{
- extern char *saved_command_line;
-
- return strstr(saved_command_line, str);
-}
-
-static int __init omap_serial_early_init(void)
-{
- if (of_have_populated_dt())
- return -ENODEV;
-
- do {
- char oh_name[MAX_UART_HWMOD_NAME_LEN];
- struct omap_hwmod *oh;
- struct omap_uart_state *uart;
- char uart_name[MAX_UART_HWMOD_NAME_LEN];
-
- snprintf(oh_name, MAX_UART_HWMOD_NAME_LEN,
- "uart%d", num_uarts + 1);
- oh = omap_hwmod_lookup(oh_name);
- if (!oh)
- break;
-
- uart = kzalloc(sizeof(struct omap_uart_state), GFP_KERNEL);
- if (WARN_ON(!uart))
- return -ENODEV;
-
- uart->oh = oh;
- uart->num = num_uarts++;
- list_add_tail(&uart->node, &uart_list);
- snprintf(uart_name, MAX_UART_HWMOD_NAME_LEN,
- "%s%d", OMAP_SERIAL_NAME, uart->num);
-
- if (cmdline_find_option(uart_name)) {
- console_uart_id = uart->num;
-
- if (console_loglevel >= CONSOLE_LOGLEVEL_DEBUG) {
- uart_debug = true;
- pr_info("%s used as console in debug mode: uart%d clocks will not be gated",
- uart_name, uart->num);
- }
- }
- } while (1);
-
- return 0;
-}
-omap_postcore_initcall(omap_serial_early_init);
-
-/**
- * omap_serial_init_port() - initialize single serial port
- * @bdata: port specific board data pointer
- * @info: platform specific data pointer
- *
- * This function initialies serial driver for given port only.
- * Platforms can call this function instead of omap_serial_init()
- * if they don't plan to use all available UARTs as serial ports.
- *
- * Don't mix calls to omap_serial_init_port() and omap_serial_init(),
- * use only one of the two.
- */
-void __init omap_serial_init_port(struct omap_board_data *bdata,
- struct omap_uart_port_info *info)
-{
- struct omap_uart_state *uart;
- struct omap_hwmod *oh;
- struct platform_device *pdev;
- void *pdata = NULL;
- u32 pdata_size = 0;
- char *name;
- struct omap_uart_port_info omap_up;
-
- if (WARN_ON(!bdata))
- return;
- if (WARN_ON(bdata->id < 0))
- return;
- if (WARN_ON(bdata->id >= num_uarts))
- return;
-
- list_for_each_entry(uart, &uart_list, node)
- if (bdata->id == uart->num)
- break;
- if (!info)
- info = omap_serial_default_info;
-
- oh = uart->oh;
- name = OMAP_SERIAL_DRIVER_NAME;
-
- omap_up.dma_enabled = info->dma_enabled;
- omap_up.uartclk = OMAP24XX_BASE_BAUD * 16;
- omap_up.flags = UPF_BOOT_AUTOCONF;
- omap_up.get_context_loss_count = omap_pm_get_dev_context_loss_count;
- omap_up.enable_wakeup = omap_uart_enable_wakeup;
- omap_up.dma_rx_buf_size = info->dma_rx_buf_size;
- omap_up.dma_rx_timeout = info->dma_rx_timeout;
- omap_up.dma_rx_poll_rate = info->dma_rx_poll_rate;
- omap_up.autosuspend_timeout = info->autosuspend_timeout;
-
- pdata = &omap_up;
- pdata_size = sizeof(struct omap_uart_port_info);
-
- if (WARN_ON(!oh))
- return;
-
- pdev = omap_device_build(name, uart->num, oh, pdata, pdata_size);
- if (IS_ERR(pdev)) {
- WARN(1, "Could not build omap_device for %s: %s.\n", name,
- oh->name);
- return;
- }
-
- oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);
-
- if (console_uart_id == bdata->id) {
- omap_device_enable(pdev);
- pm_runtime_set_active(&pdev->dev);
- }
-
- oh->dev_attr = uart;
-
- if (((cpu_is_omap34xx() || cpu_is_omap44xx()) && bdata->pads)
- && !uart_debug)
- device_init_wakeup(&pdev->dev, true);
-}
-
-/**
- * omap_serial_board_init() - initialize all supported serial ports
- * @info: platform specific data pointer
- *
- * Initializes all available UARTs as serial ports. Platforms
- * can call this function when they want to have default behaviour
- * for serial ports (e.g initialize them all as serial ports).
- */
-void __init omap_serial_board_init(struct omap_uart_port_info *info)
-{
- struct omap_uart_state *uart;
- struct omap_board_data bdata;
-
- list_for_each_entry(uart, &uart_list, node) {
- bdata.id = uart->num;
- bdata.flags = 0;
- bdata.pads = NULL;
- bdata.pads_cnt = 0;
-
- omap_serial_check_wakeup(&bdata, uart);
-
- if (!info)
- omap_serial_init_port(&bdata, NULL);
- else
- omap_serial_init_port(&bdata, &info[uart->num]);
- }
-}
-
-/**
- * omap_serial_init() - initialize all supported serial ports
- *
- * Initializes all available UARTs.
- * Platforms can call this function when they want to have default behaviour
- * for serial ports (e.g initialize them all as serial ports).
- */
-void __init omap_serial_init(void)
-{
- omap_serial_board_init(NULL);
-}
--
2.10.2
^ permalink raw reply
* [PATCH 00/14] Drop some unused omap platform_data
From: Tony Lindgren @ 2016-11-11 19:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I've rebased the earlier legacy platform data removal
patches from few years ago that I've kept stashed in the
omap-for-v3.14/omap3-board-removal branch until omap3
became device tree only.
Looks like we still have hwmod data at least for omap4
that is not yet populated in the dts files. I'll fix
that up later on.
Meanwhile, if you notice some other unused platform_data
related code in mach-omap2, please send patches. I'll
be queueing them into omap-for-v4.10/legacy branch.
Regards,
Tony
Javier Martinez Canillas (2):
ARM: OMAP2+: Remove legacy smsc911x and smc91x GPMC support
ARM: OMAP2+: Remove legacy board-flash.c
Tony Lindgren (12):
ARM: OMAP2+: Remove legacy serial.c
ARM: OMAP2+: Remove legacy i2c.c platform init code
ARM: OMAP2+: Remove legacy PM init
ARM: OMAP2+: Remove legacy twl4030 platform init code
ARM: OMAP2+: Remove legacy usb-host.c platform init code
ARM: OMAP2+: Remove legacy muxing for usb-tusb6010.c
ARM: OMAP2+: Remove legacy usb-musb.c platform init code
ARM: OMAP2+: Remove legacy hwmod mux code
ARM: OMAP2+: Remove legacy mux code
ARM: OMAP2+: Remove legacy data from hwmod for omap3
ARM: OMAP2+: Drop legacy ads7846 init
ARM: OMAP2+: Drop legacy sdram timings
arch/arm/mach-omap1/Kconfig | 26 +
arch/arm/mach-omap1/i2c.c | 83 +
arch/arm/mach-omap2/Makefile | 16 +-
arch/arm/mach-omap2/board-flash.c | 242 ---
arch/arm/mach-omap2/board-flash.h | 56 -
arch/arm/mach-omap2/common-board-devices.c | 102 -
arch/arm/mach-omap2/common-board-devices.h | 8 -
arch/arm/mach-omap2/common.h | 9 -
arch/arm/mach-omap2/devices.c | 1 -
arch/arm/mach-omap2/dss-common.c | 37 -
arch/arm/mach-omap2/dss-common.h | 13 -
arch/arm/mach-omap2/gpmc-smsc911x.c | 100 -
arch/arm/mach-omap2/gpmc-smsc911x.h | 35 -
arch/arm/mach-omap2/hsmmc.c | 88 -
arch/arm/mach-omap2/i2c.c | 97 -
arch/arm/mach-omap2/io.c | 1 -
arch/arm/mach-omap2/msdi.c | 1 -
arch/arm/mach-omap2/mux.c | 1153 -----------
arch/arm/mach-omap2/mux.h | 352 ----
arch/arm/mach-omap2/mux34xx.c | 2061 --------------------
arch/arm/mach-omap2/mux34xx.h | 402 ----
arch/arm/mach-omap2/omap_hwmod.c | 107 +-
.../omap_hwmod_2xxx_3xxx_interconnect_data.c | 149 +-
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 201 +-
.../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 4 -
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 1 -
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 787 +-------
arch/arm/mach-omap2/omap_hwmod_common_data.h | 15 -
arch/arm/mach-omap2/pdata-quirks.c | 1 -
arch/arm/mach-omap2/pm.c | 66 +-
arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h | 51 -
arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h | 55 -
arch/arm/mach-omap2/sdram-nokia.c | 299 ---
arch/arm/mach-omap2/sdram-nokia.h | 12 -
arch/arm/mach-omap2/sdram-numonyx-m65kxxxxam.h | 51 -
.../mach-omap2/sdram-qimonda-hyb18m512160af-6.h | 54 -
arch/arm/mach-omap2/serial.c | 332 ----
arch/arm/mach-omap2/twl-common.c | 81 -
arch/arm/mach-omap2/twl-common.h | 42 -
arch/arm/mach-omap2/usb-host.c | 496 -----
arch/arm/mach-omap2/usb-musb.c | 106 -
arch/arm/mach-omap2/usb-tusb6010.c | 21 -
arch/arm/plat-omap/Kconfig | 26 -
arch/arm/plat-omap/Makefile | 3 -
arch/arm/plat-omap/i2c.c | 116 --
45 files changed, 160 insertions(+), 7799 deletions(-)
delete mode 100644 arch/arm/mach-omap2/board-flash.c
delete mode 100644 arch/arm/mach-omap2/board-flash.h
delete mode 100644 arch/arm/mach-omap2/common-board-devices.c
delete mode 100644 arch/arm/mach-omap2/dss-common.c
delete mode 100644 arch/arm/mach-omap2/dss-common.h
delete mode 100644 arch/arm/mach-omap2/gpmc-smsc911x.c
delete mode 100644 arch/arm/mach-omap2/gpmc-smsc911x.h
delete mode 100644 arch/arm/mach-omap2/mux.c
delete mode 100644 arch/arm/mach-omap2/mux.h
delete mode 100644 arch/arm/mach-omap2/mux34xx.c
delete mode 100644 arch/arm/mach-omap2/mux34xx.h
delete mode 100644 arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
delete mode 100644 arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h
delete mode 100644 arch/arm/mach-omap2/sdram-nokia.c
delete mode 100644 arch/arm/mach-omap2/sdram-nokia.h
delete mode 100644 arch/arm/mach-omap2/sdram-numonyx-m65kxxxxam.h
delete mode 100644 arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
delete mode 100644 arch/arm/mach-omap2/serial.c
delete mode 100644 arch/arm/mach-omap2/twl-common.c
delete mode 100644 arch/arm/mach-omap2/twl-common.h
delete mode 100644 arch/arm/mach-omap2/usb-host.c
delete mode 100644 arch/arm/mach-omap2/usb-musb.c
delete mode 100644 arch/arm/plat-omap/i2c.c
--
2.10.2
^ permalink raw reply
* [PATCH] iommu/dma: Stop getting dma_32bit_pfn wrong
From: Robin Murphy @ 2016-11-11 18:30 UTC (permalink / raw)
To: linux-arm-kernel
iommu_dma_init_domain() was originally written under the misconception
that dma_32bit_pfn represented some sort of size limit for IOVA domains.
Since the truth is almost the exact opposite of that, rework the logic
and comments to reflect its real purpose of optimising lookups when
allocating from a subset of the available space.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/dma-iommu.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c5ab8667e6f2..ae045a14b530 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -139,6 +139,7 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
{
struct iova_domain *iovad = cookie_iovad(domain);
unsigned long order, base_pfn, end_pfn;
+ bool pci = dev && dev_is_pci(dev);
if (!iovad)
return -ENODEV;
@@ -161,19 +162,31 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
end_pfn = min_t(unsigned long, end_pfn,
domain->geometry.aperture_end >> order);
}
+ /*
+ * PCI devices may have larger DMA masks, but still prefer allocating
+ * within a 32-bit mask to avoid DAC addressing. Such limitations don't
+ * apply to the typical platform device, so for those we may as well
+ * leave the cache limit at the top of the range they're likely to use.
+ */
+ if (pci)
+ end_pfn = min_t(unsigned long, end_pfn,
+ DMA_BIT_MASK(32) >> order);
- /* All we can safely do with an existing domain is enlarge it */
+ /* start_pfn is always nonzero for an already-initialised domain */
if (iovad->start_pfn) {
if (1UL << order != iovad->granule ||
- base_pfn != iovad->start_pfn ||
- end_pfn < iovad->dma_32bit_pfn) {
+ base_pfn != iovad->start_pfn) {
pr_warn("Incompatible range for DMA domain\n");
return -EFAULT;
}
- iovad->dma_32bit_pfn = end_pfn;
+ /*
+ * If we have devices with different DMA masks, move the free
+ * area cache limit down for the benefit of the smaller one.
+ */
+ iovad->dma_32bit_pfn = min(end_pfn, iovad->dma_32bit_pfn);
} else {
init_iova_domain(iovad, 1UL << order, base_pfn, end_pfn);
- if (dev && dev_is_pci(dev))
+ if (pci)
iova_reserve_pci_windows(to_pci_dev(dev), iovad);
}
return 0;
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v3 2/2] arm64: Wire up iommu_dma_{map, unmap}_resource()
From: Robin Murphy @ 2016-11-11 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7d54803d32968be46a1a525d7160feb13af72f00.1478887214.git.robin.murphy@arm.com>
With no coherency to worry about, just plug'em straight in.
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Will Deacon <will.deacon@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 v3 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Robin Murphy @ 2016-11-11 18:27 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>
---
v3: Don't misuse phys_to_page()
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..8b745260b3bc 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)
+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 V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: liviu.dudau at arm.com @ 2016-11-11 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F8F9909@lhreml507-mbx>
On Fri, Nov 11, 2016 at 03:53:53PM +0000, Gabriele Paoloni wrote:
> Hi Liviu
Hi Gabriele,
>
> > -----Original Message-----
> > From: liviu.dudau at arm.com [mailto:liviu.dudau at arm.com]
> > Sent: 11 November 2016 14:46
> > To: Gabriele Paoloni
> > Cc: Arnd Bergmann; linux-arm-kernel at lists.infradead.org; Yuanzhichang;
> > mark.rutland at arm.com; devicetree at vger.kernel.org;
> > lorenzo.pieralisi at arm.com; minyard at acm.org; linux-pci at vger.kernel.org;
> > benh at kernel.crashing.org; John Garry; will.deacon at arm.com; linux-
> > kernel at vger.kernel.org; xuwei (O); Linuxarm; zourongrong at gmail.com;
> > robh+dt at kernel.org; kantyzc at 163.com; linux-serial at vger.kernel.org;
> > catalin.marinas at arm.com; olof at lixom.net; bhelgaas at googl e.com;
> > zhichang.yuan02 at gmail.com
> > Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> > Hip06
> >
> > On Fri, Nov 11, 2016 at 01:39:35PM +0000, Gabriele Paoloni wrote:
> > > Hi Arnd
> > >
> > > > -----Original Message-----
> > > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > > Sent: 10 November 2016 16:07
> > > > To: Gabriele Paoloni
> > > > Cc: linux-arm-kernel at lists.infradead.org; Yuanzhichang;
> > > > mark.rutland at arm.com; devicetree at vger.kernel.org;
> > > > lorenzo.pieralisi at arm.com; minyard at acm.org; linux-
> > pci at vger.kernel.org;
> > > > benh at kernel.crashing.org; John Garry; will.deacon at arm.com; linux-
> > > > kernel at vger.kernel.org; xuwei (O); Linuxarm; zourongrong at gmail.com;
> > > > robh+dt at kernel.org; kantyzc at 163.com; linux-serial at vger.kernel.org;
> > > > catalin.marinas at arm.com; olof at lixom.net; liviu.dudau at arm.com;
> > > > bhelgaas at googl e.com; zhichang.yuan02 at gmail.com
> > > > Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> > > > Hip06
> > > >
> > > > On Thursday, November 10, 2016 3:36:49 PM CET Gabriele Paoloni
> > wrote:
> > > > >
> > > > > Where should we get the range from? For LPC we know that it is
> > going
> > > > > Work on anything that is not used by PCI I/O space, and this is
> > > > > why we use [0, PCIBIOS_MIN_IO]
> > > >
> > > > It should be allocated the same way we allocate PCI config space
> > > > segments. This is currently done with the io_range list in
> > > > drivers/pci/pci.c, which isn't perfect but could be extended
> > > > if necessary. Based on what others commented here, I'd rather
> > > > make the differences between ISA/LPC and PCI I/O ranges smaller
> > > > than larger.
> >
> > Gabriele,
> >
> > >
> > > I am not sure this would make sense...
> > >
> > > IMHO all the mechanism around io_range_list is needed to provide the
> > > "mapping" between I/O tokens and physical CPU addresses.
> > >
> > > Currently the available tokens range from 0 to IO_SPACE_LIMIT.
> > >
> > > As you know the I/O memory accessors operate on whatever
> > > __of_address_to_resource sets into the resource (start, end).
> > >
> > > With this special device in place we cannot know if a resource is
> > > assigned with an I/O token or a physical address, unless we forbid
> > > the I/O tokens to be in a specific range.
> > >
> > > So this is why we are changing the offsets of all the functions
> > > handling io_range_list (to make sure that a range is forbidden to
> > > the tokens and is available to the physical addresses).
> > >
> > > We have chosen this forbidden range to be [0, PCIBIOS_MIN_IO)
> > > because this is the maximum physical I/O range that a non PCI device
> > > can operate on and because we believe this does not impose much
> > > restriction on the available I/O token range; that now is
> > > [PCIBIOS_MIN_IO, IO_SPACE_LIMIT].
> > > So we believe that the chosen forbidden range can accommodate
> > > any special ISA bus device with no much constraint on the rest
> > > of I/O tokens...
> >
> > Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and you
> > actually need another variable for "reserving" an area in the I/O space
> > that can be used for physical addresses rather than I/O tokens.
> >
> > The one good example for using PCIBIOS_MIN_IO is when your
> > platform/architecture
> > does not support legacy ISA operations *at all*. In that case someone
> > sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O range
> > so that it doesn't get used. With Zhichang's patch you now start
> > forcing
> > those platforms to have a valid address below PCIBIOS_MIN_IO.
>
> But if PCIBIOS_MIN_IO is 0 then it means that all I/O space is to be used
> by PCI controllers only...
Nope, that is not what it means. It means that PCI devices can see I/O addresses
on the bus that start from 0. There never was any usage for non-PCI controllers
when PCIBIOS_MIN_IO != 0. That is what Zhichang is trying to do now and what
I think is not the right thing (and not enough anyway).
> so if you have a special bus device using
> an I/O range in this case should be a PCI controller...
That has always been the case. It is this series that wants to introduce the
new meaning.
> i.e. I would
> expect it to fall back into the case of I/O tokens redirection rather than
> physical addresses redirection (as mentioned below from my previous reply).
> What do you think?
I think you have looked too much at the code *with* Zhichang's patches applied.
Take a step back and look at how PCIBIOS_MIN_IO is used now, before you apply
the patches. It is all about PCI addresses and there is no notion of non-PCI
busses using PCI framework. Only platforms and architectures that try to work
around some legacy standards (ISA) or HW restrictions.
Best regards,
Liviu
>
> Thanks
>
> Gab
>
>
> >
> > For the general case you also have to bear in mind that PCIBIOS_MIN_IO
> > could
> > be zero. In that case, what is your "forbidden" range? [0, 0) ? So it
> > makes
> > sense to add a new #define that should only be defined by those
> > architectures/
> > platforms that want to reserve on top of PCIBIOS_MIN_IO another region
> > where I/O tokens can't be generated for.
> >
> > Best regards,
> > Liviu
> >
> > >
> > > >
> > > > > > Your current version has
> > > > > >
> > > > > > if (arm64_extio_ops->pfout)
> > \
> > > > > > arm64_extio_ops->pfout(arm64_extio_ops-
> > >devpara,\
> > > > > > addr, value, sizeof(type));
> > \
> > > > > >
> > > > > > Instead, just subtract the start of the range from the logical
> > > > > > port number to transform it back into a bus-local port number:
> > > > >
> > > > > These accessors do not operate on IO tokens:
> > > > >
> > > > > If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
> > > > > addr is not going to be an I/O token; in fact patch 2/3 imposes
> > that
> > > > > the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
> > > > PCIBIOS_MIN_IO
> > > > > we have free physical addresses that the accessors can operate
> > on.
> > > >
> > > > Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to refer
> > to
> > > > the logical I/O tokens, the purpose of that macro is really meant
> > > > for allocating PCI I/O port numbers within the address space of
> > > > one bus.
> > >
> > > As I mentioned above, special devices operate on CPU addresses
> > directly,
> > > not I/O tokens. For them there is no way to distinguish....
> > >
> > > >
> > > > Note that it's equally likely that whichever next platform needs
> > > > non-mapped I/O access like this actually needs them for PCI I/O
> > space,
> > > > and that will use it on addresses registered to a PCI host bridge.
> > >
> > > Ok so here you are talking about a platform that has got an I/O range
> > > under the PCI host controller, right?
> > > And this I/O range cannot be directly memory mapped but needs special
> > > redirections for the I/O tokens, right?
> > >
> > > In this scenario registering the I/O ranges with the forbidden range
> > > implemented by the current patch would still allow to redirect I/O
> > > tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
> > >
> > > So effectively the special PCI host controller
> > > 1) knows the physical range that needs special redirection
> > > 2) register such range
> > > 3) uses pci_pio_to_address() to retrieve the IO tokens for the
> > > special accessors
> > > 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in 3)
> > >
> > > So to be honest I think this patch can fit well both with
> > > special PCI controllers that need I/O tokens redirection and with
> > > special non-PCI controllers that need non-PCI I/O physical
> > > address redirection...
> > >
> > > Thanks (and sorry for the long reply but I didn't know how
> > > to make the explanation shorter :) )
> > >
> > > Gab
> > >
> > > >
> > > > If we separate the two steps:
> > > >
> > > > a) assign a range of logical I/O port numbers to a bus
> > > > b) register a set of helpers for redirecting logical I/O
> > > > port to a helper function
> > > >
> > > > then I think the code will get cleaner and more flexible.
> > > > It should actually then be able to replace the powerpc
> > > > specific implementation.
> > > >
> > > > Arnd
> >
> > --
> > ====================
> > | I would like to |
> > | fix the world, |
> > | but they're not |
> > | giving me the |
> > \ source code! /
> > ---------------
> > ?\_(?)_/?
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH v2 5/5] iommu/mediatek: Fix M4Uv1 group refcounting
From: Robin Murphy @ 2016-11-11 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37029eb869380edb0d5ce8cc6601ce7e69c80458.1478886974.git.robin.murphy@arm.com>
For each subsequent device assigned to the m4u_group after its initial
allocation, we need to take an additional reference. Otherwise, the
caller of iommu_group_get_for_dev() will inadvertently remove the
reference taken by iommu_group_add_device(), and the group will be
freed prematurely if any device is removed.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/mtk_iommu_v1.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index b8aeb0768483..c7063e9d67d8 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -502,6 +502,8 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ } else {
+ iommu_group_ref_get(data->m4u_group);
}
return data->m4u_group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v2 4/5] iommu/mediatek: Fix M4Uv2 group refcounting
From: Robin Murphy @ 2016-11-11 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37029eb869380edb0d5ce8cc6601ce7e69c80458.1478886974.git.robin.murphy@arm.com>
For each subsequent device assigned to the m4u_group after its initial
allocation, we need to take an additional reference. Otherwise, the
caller of iommu_group_get_for_dev() will inadvertently remove the
reference taken by iommu_group_add_device(), and the group will be
freed prematurely if any device is removed.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/mtk_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index b12c12d74c33..9799daeaacde 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -410,6 +410,8 @@ static struct iommu_group *mtk_iommu_device_group(struct device *dev)
data->m4u_group = iommu_group_alloc();
if (IS_ERR(data->m4u_group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ } else {
+ iommu_group_ref_get(data->m4u_group);
}
return data->m4u_group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v2 3/5] iommu/amd: Fix group refcounting
From: Robin Murphy @ 2016-11-11 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37029eb869380edb0d5ce8cc6601ce7e69c80458.1478886974.git.robin.murphy@arm.com>
If acpihid_device_group() finds an existing group for the relevant
devid, it should be taking an additional reference on that group.
Otherwise, the caller of iommu_group_get_for_dev() will inadvertently
remove the reference taken by iommu_group_add_device(), and the group
will be freed prematurely if any device is removed.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/amd_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 754595ee11b6..019e02707cd5 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -373,6 +373,8 @@ static struct iommu_group *acpihid_device_group(struct device *dev)
if (!entry->group)
entry->group = generic_device_group(dev);
+ else
+ iommu_group_ref_get(entry->group);
return entry->group;
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v2 2/5] iommu/arm-smmu: Fix group refcounting
From: Robin Murphy @ 2016-11-11 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37029eb869380edb0d5ce8cc6601ce7e69c80458.1478886974.git.robin.murphy@arm.com>
When arm_smmu_device_group() finds an existing group due to Stream ID
aliasing, it should be taking an additional reference on that group.
Otherwise, the caller of iommu_group_get_for_dev() will inadvertently
remove the reference taken by iommu_group_add_device(), and the group
will be freed prematurely if any device is removed.
Reported-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 8f7281444551..b8cd5579a953 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1478,7 +1478,7 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
}
if (group)
- return group;
+ return iommu_group_ref_get(group);
if (dev_is_pci(dev))
group = pci_device_group(dev);
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v2 1/5] iommu: Allow taking a reference on a group directly
From: Robin Murphy @ 2016-11-11 17:59 UTC (permalink / raw)
To: linux-arm-kernel
iommu_group_get_for_dev() expects that the IOMMU driver's device_group
callback return a group with a reference held for the given device.
Whilst allocating a new group is fine, and pci_device_group() correctly
handles reusing an existing group, there is no general means for IOMMU
drivers doing their own group lookup to take additional references on an
existing group pointer without having to also store device pointers or
resort to elaborate trickery.
Add an IOMMU-driver-specific function to fill the hole.
Acked-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v2: Fix the function name; clarify what exactly its callers are fixing.
drivers/iommu/iommu.c | 13 +++++++++++++
include/linux/iommu.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 9a2f1960873b..9408c3145483 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -552,6 +552,19 @@ struct iommu_group *iommu_group_get(struct device *dev)
EXPORT_SYMBOL_GPL(iommu_group_get);
/**
+ * iommu_group_ref_get - Increment reference on a group
+ * @group: the group to use, must not be NULL
+ *
+ * This function is called by iommu drivers to take additional references on an
+ * existing group. Returns the given group for convenience.
+ */
+struct iommu_group *iommu_group_ref_get(struct iommu_group *group)
+{
+ kobject_get(group->devices_kobj);
+ return group;
+}
+
+/**
* iommu_group_put - Decrement group reference
* @group: the group to use
*
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 436dc21318af..431638110c6a 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -253,6 +253,7 @@ extern void iommu_group_remove_device(struct device *dev);
extern int iommu_group_for_each_dev(struct iommu_group *group, void *data,
int (*fn)(struct device *, void *));
extern struct iommu_group *iommu_group_get(struct device *dev);
+extern struct iommu_group *iommu_group_ref_get(struct iommu_group *group);
extern void iommu_group_put(struct iommu_group *group);
extern int iommu_group_register_notifier(struct iommu_group *group,
struct notifier_block *nb);
--
2.10.2.dirty
^ permalink raw reply related
* [RFC PATCH 0/6] media: davinci: VPIF: add DT support
From: Kevin Hilman @ 2016-11-11 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6058d790-5409-01c0-1d3f-b1bb45f8f85c@xs4all.nl>
Hans Verkuil <hverkuil@xs4all.nl> writes:
> Hi Kevin,
>
> On 10/26/2016 01:55 AM, Kevin Hilman wrote:
>> This series attempts to add DT support to the davinci VPIF capture
>> driver.
>>
>> I'm not sure I've completely grasped the proper use of the ports and
>> endpoints stuff, so this RFC is primarily to get input on whether I'm
>> on the right track.
>>
>> The last patch is the one where all my questions are, the rest are
>> just prep work to ge there.
>>
>> Tested on da850-lcdk and was able to do basic frame capture from the
>> composite input.
>>
>> Series applies on v4.9-rc1
>>
>> Kevin Hilman (6):
>> [media] davinci: add support for DT init
>> ARM: davinci: da8xx: VPIF: enable DT init
>> ARM: dts: davinci: da850: add VPIF
>> ARM: dts: davinci: da850-lcdk: enable VPIF capture
>> [media] davinci: vpif_capture: don't lock over s_stream
>> [media] davinci: vpif_capture: get subdevs from DT
>
> Looks good, but wouldn't it be better to do the dts changes last when all the
> supporting code is in?
I guess it doesn't really matter in this case, because the DT nodes will
be nops until the driver changes are in.
Either way, next week I'll repost a non-RFC version and separate out the
arch and DT patches, since those will go through Sekhar's davinci tree,
and then via arm-soc.
Thanks for the review,
Kevin
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Robin Murphy @ 2016-11-11 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111162736.GV2078@8bytes.org>
On 11/11/16 16:27, Joerg Roedel wrote:
> On Fri, Nov 11, 2016 at 04:17:37PM +0000, Robin Murphy wrote:
>> In the original of_iommu_configure design, the thought was that an ops
>> structure could be IOMMU-instance-specific (hence the later-removed
>> "priv" member), so I suppose right now it is mostly a hangover from
>> that. However, it's also what we initialise a device's fwspec with, so
>> becomes important again if we're ever going to get past the limitations
>> of buses-which-are-not-actually-buses[1].
>
> Yeah, I discussed this with a few others at LPC. My current idea is to
> tell the iommu-core which hardware-iommus exist in the system and a
> seperate iommu_ops ptr for each of them. Then every struct device can
> link to the iommu-instance it is translated by.
Er, that sounds very much like a description of what we already have in
4.9-rc. Every struct device now has an iommu_fwspec which encapsulates
both an iommu_ops pointer (which can perfectly well be per-instance if
the IOMMU driver wants) and a place for the IOMMU-private data to
replace the mess of archdata.iommu and driver-internal globals.
> We are not there yet, but this will give you the same per-device
> iommu-ops as implemented here.
With those two patches I linked to, which make the bulk of the IOMMU
core code per-device-ops-aware off the bat, I'd say we *are* already
pretty much there. It's only iommu_domain_alloc() which needs a
device-based alternative, and the non-of_xlate-based IOMMU drivers to
either call iommu_fwspec_init() for themselves, or perhaps for x86
plumbing in DMAR/IVRS equivalents of the IORT parsing to the
infrastructure provided by this series.
Robin.
^ permalink raw reply
* [PATCH] ARM64: dts: bcm2837-rpi-3-b: remove incorrect pwr LED
From: Eric Anholt @ 2016-11-11 17:38 UTC (permalink / raw)
To: linux-arm-kernel
From: Andrea Merello <andrea.merello@gmail.com>
We are incorrectly defining the pwr LED, attaching it to a gpio line
that is wired to the Wi-Fi SDIO module (which fails due to this).
The actual power LED is connected to the GPIO expander, which we don't
expose currently.
Thanks-to: Eric Anholt <eric@anholt.net> [for clarifying we can't control the LED]
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
---
arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts | 7 -------
1 file changed, 7 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
index 7625e57a64b5..c309633a1e87 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
@@ -16,13 +16,6 @@
act {
gpios = <&gpio 47 0>;
};
-
- pwr {
- label = "PWR";
- gpios = <&gpio 35 0>;
- default-state = "keep";
- linux,default-trigger = "default-on";
- };
};
};
--
2.10.2
^ permalink raw reply related
* [PATCH RFT] irqchip: mxs: Enable SKIP_SET_WAKE and MASK_ON_SUSPEND
From: Stefan Wahren @ 2016-11-11 17:26 UTC (permalink / raw)
To: linux-arm-kernel
The ICOLL controller doesn't provide any facility to configure the
wakeup sources. That's the reason why this implementation lacks
the irq_set_wake implementation. But this prevent us from properly
entering power management states like "suspend to idle".
So enable the flags IRQCHIP_SKIP_SET_WAKE and IRQCHIP_MASK_ON_SUSPEND
to let the irqchip core allows and handles the power management.
This patch has been tested with a MX23 and a MX28 board. Any further
tests especially with ASM9260 would be appreciated.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
drivers/irqchip/irq-mxs.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/irqchip/irq-mxs.c b/drivers/irqchip/irq-mxs.c
index 1730470..05fa9f7 100644
--- a/drivers/irqchip/irq-mxs.c
+++ b/drivers/irqchip/irq-mxs.c
@@ -131,12 +131,16 @@ static void asm9260_unmask_irq(struct irq_data *d)
.irq_ack = icoll_ack_irq,
.irq_mask = icoll_mask_irq,
.irq_unmask = icoll_unmask_irq,
+ .flags = IRQCHIP_MASK_ON_SUSPEND |
+ IRQCHIP_SKIP_SET_WAKE,
};
static struct irq_chip asm9260_icoll_chip = {
.irq_ack = icoll_ack_irq,
.irq_mask = asm9260_mask_irq,
.irq_unmask = asm9260_unmask_irq,
+ .flags = IRQCHIP_MASK_ON_SUSPEND |
+ IRQCHIP_SKIP_SET_WAKE,
};
asmlinkage void __exception_irq_entry icoll_handle_irq(struct pt_regs *regs)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Eric Anholt @ 2016-11-11 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a5c1318-de70-bcfc-648d-fd5a43c2fac5@wwwdotorg.org>
Stephen Warren <swarren@wwwdotorg.org> writes:
> On 10/27/2016 10:52 AM, Eric Anholt wrote:
>> From: Linus Walleij <linus.walleij@linaro.org>
>>
>> The idea is to give useful names to GPIO lines that an implementer
>> will be using from userspace, e.g. for maker type projects. These are
>> user-visible using tools/gpio/lsgpio.c
>
>> arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 65 +++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm2835-rpi-a.dts | 67 ++++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 66 +++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 66 +++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm2835-rpi-b.dts | 67 ++++++++++++++++++++++++++++++++
>
> Aren't the A and B rev 2 pinouts the same.
Looking at the contents of the patches and the schematics referenced
>From them: no, they aren't.
> If so, why duplicate the
> content between the files instead of creating an inclue file? Same for
> A+, B+, Pi 2, and Pi 3. Shouldn't this patch update the Pi 2 and Pi 3
> DTs too?
Pi2 and 3 would be lovely. If someone wants to write them, I'd
encourage them to.
> I think the whole point of naming GPIOs is to give users the same
> experience across the different boards where the same semantics exist in
> HW. Both the A+ and B+ use GPIO0/1 (a/k/a ID_SD/ID_SC a/k/a SDA0/SCL0)
> for the same semantic purpose and are exposed in the same externally
> visible way (same pins on the expansion header); the board ID EEPROM.
> Therefore I assert the names of these GPIOs should be identical on all
> boards that use them for that purpose, to allow SW (or human knowledge)
> portability between the boards.
I weakly agree with this, but find the idea of "consistent semantics"
attached to the names rather silly given the number of ways people
reconfigure the boards (particularly given that people can pinmux
things).
That said, I agree with you on renaming ID_SD to disagree with the
schematic in favor of consistency, and I've done so.
>> + "GPIO17",
>
> This pin is known as GPIO_GEN0 on the expansion header. Given the
> expansion header is all end-users likely care about, and other pins
> (e.g. SPI_CE1_N) are named after the expansion header, shouldn't this
> patch use the GPIO expansion header naming for all pins that are routed
> to that header?
We've already been through this. Users *don't* know the GENx names and
they were confusing and got eliminated in the later schematics. This
was done for consistency, like you asked for above!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/1ba7017a/attachment.sig>
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Jacek Anaszewski @ 2016-11-11 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111120114.GA1076@amd>
On 11/11/2016 01:01 PM, Pavel Machek wrote:
> On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote:
>> Hi,
>>
>> On 11/10/2016 09:29 PM, Pavel Machek wrote:
>>> On Thu 2016-11-10 10:55:37, Tony Lindgren wrote:
>>>> * Pavel Machek <pavel@ucw.cz> [161110 09:29]:
>>>>> Hi!
>>>>>
>>>>>>>>> Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
>>>>>>>>> the sysfs brightness attr for changes.") breaks runtime PM for me.
>>>>>>>>>
>>>>>>>>> On my omap dm3730 based test system, idle power consumption is over 70
>>>>>>>>> times higher now with this patch! It goes from about 6mW for the core
>>>>>>>>> system to over 440mW during idle meaning there's some busy timer now
>>>>>>>>> active.
>>>>>>>>>
>>>>>>>>> Reverting this patch fixes the issue. Any ideas?
>>>>>
>>>>> Are you using any LED that toggles with high frequency? Like perhaps
>>>>> LED that is lit when CPU is active?
>>>>
>>>> Yeah one of them seems to have cpu0 as the default trigger.
>>>
>>> Aha. Its quite obvious we don't want to notify sysfs each time that
>>> one is toggled, right?
>>>
>>> IMO brightness should display max brightness for the trigger, as Hans
>>> suggested, anything else is madness for trigger such as cpu activity.
>>
>> Are you suggesting that we should revert changes introduced
>> by below patch?
>>
>> commit 29d76dfa29fe22583aefddccda0bc56aa81035dc
>> Author: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
>> Date: Tue Mar 18 09:47:48 2008 +0000
>>
>> leds: Add support to leds with readable status
>>
>> Some led hardware allows drivers to query the led state, and this patch
>> adds a hook to let the led class take advantage of that information when
>> available.
>>
>> Without this functionality, when access to the led hardware is not
>> exclusive (i.e. firmware or hardware might change its state behind the
>> kernel's back), reality goes out of sync with the led class' idea of
>> what
>> the led is doing, which is annoying at best.
>
> Hmm. So userland can read the LED state, and it can get _some_ value
> back, but it can not know if it is current state or not.
>
> I don't think that's a good interface. I see it is from 2008... is
> someone using it? Maybe it is too late for revert.
I can imagine it being used in flash LED use case. E.g. one
could use oneshot trigger to trigger flash strobe, and then
he could periodically read brightness file to check, for whatever
reason, whether the flash is strobing.
> But I'd certainly not extend it with poll.
We could add a dedicated file e.g. hw_brightness_change for that
(maybe someone will have a better candidate for the file name).
This way it would be semantically consistent to report only
hardware originating brightness changes on it, which was the
initial reason for adding the brightness change notification
feature.
Moreover, LED class drivers could report on this file the
brightness level which was set by the firmware, which wouldn't
affect current LED class device brightness setting, unless
brightness file is read (and brightness_get op is supported).
> IMO reading/polling should only be available with some triggers. It
> does not make sense with "CPU load" trigger. It makes sense with
> "keyboard light changeable by hardware" trigger.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH V8 0/6] thermal: bcm2835: add thermal driver
From: Eric Anholt @ 2016-11-11 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478081906-12009-1-git-send-email-kernel@martin.sperl.org>
kernel at martin.sperl.org writes:
> From: Martin Sperl <kernel@martin.sperl.org>
Since Eduardo seems to be AFK, I've pulled this series to my -next
branches.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/b4d84fe9/attachment.sig>
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang.yuan @ 2016-11-11 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111144539.GL10219@e106497-lin.cambridge.arm.com>
Hi, Liviu,
On 11/11/2016 10:45 PM, liviu.dudau at arm.com wrote:
> On Fri, Nov 11, 2016 at 01:39:35PM +0000, Gabriele Paoloni wrote:
>> Hi Arnd
>>
>>> -----Original Message-----
>>> From: Arnd Bergmann [mailto:arnd at arndb.de]
>>> Sent: 10 November 2016 16:07
>>> To: Gabriele Paoloni
>>> Cc: linux-arm-kernel at lists.infradead.org; Yuanzhichang;
>>> mark.rutland at arm.com; devicetree at vger.kernel.org;
>>> lorenzo.pieralisi at arm.com; minyard at acm.org; linux-pci at vger.kernel.org;
>>> benh at kernel.crashing.org; John Garry; will.deacon at arm.com; linux-
>>> kernel at vger.kernel.org; xuwei (O); Linuxarm; zourongrong at gmail.com;
>>> robh+dt at kernel.org; kantyzc at 163.com; linux-serial at vger.kernel.org;
>>> catalin.marinas at arm.com; olof at lixom.net; liviu.dudau at arm.com;
>>> bhelgaas at googl e.com; zhichang.yuan02 at gmail.com
>>> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
>>> Hip06
>>>
>>> On Thursday, November 10, 2016 3:36:49 PM CET Gabriele Paoloni wrote:
>>>>
>>>> Where should we get the range from? For LPC we know that it is going
>>>> Work on anything that is not used by PCI I/O space, and this is
>>>> why we use [0, PCIBIOS_MIN_IO]
>>>
>>> It should be allocated the same way we allocate PCI config space
>>> segments. This is currently done with the io_range list in
>>> drivers/pci/pci.c, which isn't perfect but could be extended
>>> if necessary. Based on what others commented here, I'd rather
>>> make the differences between ISA/LPC and PCI I/O ranges smaller
>>> than larger.
>
> Gabriele,
>
>>
>> I am not sure this would make sense...
>>
>> IMHO all the mechanism around io_range_list is needed to provide the
>> "mapping" between I/O tokens and physical CPU addresses.
>>
>> Currently the available tokens range from 0 to IO_SPACE_LIMIT.
>>
>> As you know the I/O memory accessors operate on whatever
>> __of_address_to_resource sets into the resource (start, end).
>>
>> With this special device in place we cannot know if a resource is
>> assigned with an I/O token or a physical address, unless we forbid
>> the I/O tokens to be in a specific range.
>>
>> So this is why we are changing the offsets of all the functions
>> handling io_range_list (to make sure that a range is forbidden to
>> the tokens and is available to the physical addresses).
>>
>> We have chosen this forbidden range to be [0, PCIBIOS_MIN_IO)
>> because this is the maximum physical I/O range that a non PCI device
>> can operate on and because we believe this does not impose much
>> restriction on the available I/O token range; that now is
>> [PCIBIOS_MIN_IO, IO_SPACE_LIMIT].
>> So we believe that the chosen forbidden range can accommodate
>> any special ISA bus device with no much constraint on the rest
>> of I/O tokens...
>
> Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and you
> actually need another variable for "reserving" an area in the I/O space
> that can be used for physical addresses rather than I/O tokens.
>
I think selecting PCIBIOS_MIN_IO as the separator of mapped and non-mapped I/O
range probably is not so reasonable.
PCIBIOS_MIN_IN is specific to PCI devices, it seems as the recommended minimal
start I/O address when assigning the pci device I/O region. It is probably not
defined in some platforms/architectures when no PCI is needed there. That is why
my patch caused some compile error on some archs;
But more important thing is that the PCIBIOS_MIN_IO has different value on
different platforms/architectures. On Arm64, it is 4K currently, but in other
archs, it is not true. And the maximum LPC I/O address should be 64K
theoretically, although for compatible ISA, 2K is enough.
So, It means using PCIBIOS_MIN_IO on arm64 can match our I/O reservation
require. But we can not make this indirectIO work well on other architectures.
I am thinking Arnd's suggestion. But I worry about I haven't completely
understood his idea. What about create a new bus host for LPC/ISA whose I/O
range can be 64KB? This LPC/ISA I/O range works similar to PCI host bridge's I/O
window, all the downstream devices under LPC/ISA should request I/O from that
root resource. But it seems Arnd want this root resource registered dynamically,
I am not sure how to do...
Anyway, if we have this root I/O resource, we don't need any new macro or
variable for the LPC/ISA I/O reservation.
Hope my thought is right.
Best,
Zhichang
> The one good example for using PCIBIOS_MIN_IO is when your platform/architecture
> does not support legacy ISA operations *at all*. In that case someone
> sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O range
> so that it doesn't get used. With Zhichang's patch you now start forcing
> those platforms to have a valid address below PCIBIOS_MIN_IO.
>
> For the general case you also have to bear in mind that PCIBIOS_MIN_IO could
> be zero. In that case, what is your "forbidden" range? [0, 0) ? So it makes
> sense to add a new #define that should only be defined by those architectures/
> platforms that want to reserve on top of PCIBIOS_MIN_IO another region
> where I/O tokens can't be generated for.
>
> Best regards,
> Liviu
>
>>
>>>
>>>>> Your current version has
>>>>>
>>>>> if (arm64_extio_ops->pfout) \
>>>>> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
>>>>> addr, value, sizeof(type)); \
>>>>>
>>>>> Instead, just subtract the start of the range from the logical
>>>>> port number to transform it back into a bus-local port number:
>>>>
>>>> These accessors do not operate on IO tokens:
>>>>
>>>> If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
>>>> addr is not going to be an I/O token; in fact patch 2/3 imposes that
>>>> the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
>>> PCIBIOS_MIN_IO
>>>> we have free physical addresses that the accessors can operate on.
>>>
>>> Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to refer to
>>> the logical I/O tokens, the purpose of that macro is really meant
>>> for allocating PCI I/O port numbers within the address space of
>>> one bus.
>>
>> As I mentioned above, special devices operate on CPU addresses directly,
>> not I/O tokens. For them there is no way to distinguish....
>>
>>>
>>> Note that it's equally likely that whichever next platform needs
>>> non-mapped I/O access like this actually needs them for PCI I/O space,
>>> and that will use it on addresses registered to a PCI host bridge.
>>
>> Ok so here you are talking about a platform that has got an I/O range
>> under the PCI host controller, right?
>> And this I/O range cannot be directly memory mapped but needs special
>> redirections for the I/O tokens, right?
>>
>> In this scenario registering the I/O ranges with the forbidden range
>> implemented by the current patch would still allow to redirect I/O
>> tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
>>
>> So effectively the special PCI host controller
>> 1) knows the physical range that needs special redirection
>> 2) register such range
>> 3) uses pci_pio_to_address() to retrieve the IO tokens for the
>> special accessors
>> 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in 3)
>>
>> So to be honest I think this patch can fit well both with
>> special PCI controllers that need I/O tokens redirection and with
>> special non-PCI controllers that need non-PCI I/O physical
>> address redirection...
>>
>> Thanks (and sorry for the long reply but I didn't know how
>> to make the explanation shorter :) )
>>
>> Gab
>>
>>>
>>> If we separate the two steps:
>>>
>>> a) assign a range of logical I/O port numbers to a bus
>>> b) register a set of helpers for redirecting logical I/O
>>> port to a helper function
>>>
>>> then I think the code will get cleaner and more flexible.
>>> It should actually then be able to replace the powerpc
>>> specific implementation.
>>>
>>> Arnd
>
^ permalink raw reply
* [PATCH 3/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Icenowy Zheng @ 2016-11-11 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111164654.15273-1-icenowy@aosc.xyz>
Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
Add a device tree file for it.
As there's still no mainline-compatible driver for the SDIO WLAN card on
board (a new card by Allwinner), the mmc1 controller is not enabled yet.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 148 +++++++++++++++++++++++
2 files changed, 149 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..9843fb0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -818,6 +818,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a33-sinlinx-sina33.dtb \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
+ sun8i-h2plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-orangepi-2.dtb \
diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
new file mode 100644
index 0000000..581f56e
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
@@ -0,0 +1,148 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * Based on sun8i-h3-orangepi-one.dts, which is:
+ * Copyright (C) 2016 Hans de Goede <hdegoede@redhat.com>
+ *
+ * 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 "sun8i-h2plus.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+ model = "Xunlong Orange Pi Zero";
+ compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus",
+ "allwinner,sun8i-h3";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
+
+ pwr_led {
+ label = "orangepi:green:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ status_led {
+ label = "orangepi:red:status";
+ gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+ cd-inverted;
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&pio {
+ leds_opi0: led_pins at 0 {
+ allwinner,pins = "PA17";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
+
+&r_pio {
+ leds_r_opi0: led_pins at 0 {
+ allwinner,pins = "PL10";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "disabled";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+ status = "disabled";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins>;
+ status = "disabled";
+};
+
+&usbphy {
+ /* USB VBUS is always on */
+ status = "okay";
+};
--
2.10.1
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: sunxi: add Allwinner H2+ dtsi
From: Icenowy Zheng @ 2016-11-11 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111164654.15273-1-icenowy@aosc.xyz>
Allwinner H2+ is a SoC so similar with H3 that H3 drivers and memory map
is known to work well on H2+, with both BSP kernel/firmware or the
mainline ones.
So add a dtsi file which only include the H3 dtsi only, so we can add
H2+-specified nodes in the dtsi file when we find any software
difference between H2+ and H3.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun8i-h2plus.dtsi | 43 +++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h2plus.dtsi
diff --git a/arch/arm/boot/dts/sun8i-h2plus.dtsi b/arch/arm/boot/dts/sun8i-h2plus.dtsi
new file mode 100644
index 0000000..76fc3d0
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h2plus.dtsi
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * 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.
+ */
+
+#include "sun8i-h3.dtsi"
--
2.10.1
^ permalink raw reply related
* [PATCH 1/3] ARM: sunxi: add support for H2+ SoC
From: Icenowy Zheng @ 2016-11-11 16:46 UTC (permalink / raw)
To: linux-arm-kernel
Allwinner H2+ is a quad-core Cortex-A7 SoC.
It is very like H3, that they share the same SoC ID (0x1680), and H3
memory maps as well as drivers works well on the SoC.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Documentation/arm/sunxi/README | 4 ++++
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
arch/arm/mach-sunxi/sunxi.c | 1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index cd02433..1fe4d99c 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -63,6 +63,10 @@ SunXi family
+ User Manual
http://dl.linux-sunxi.org/A33/A33%20user%20manual%20release%201.1.pdf
+ - Allwinner H2+ (sun8i)
+ + No document available now, but is known to be working properly with
+ H3 drivers and memory map.
+
- Allwinner H3 (sun8i)
+ Datasheet
http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
index 3975d0a..0c0f277 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -13,5 +13,6 @@ using one of the following compatible strings:
allwinner,sun8i-a33
allwinner,sun8i-a83t
allwinner,sun8i-h3
+ allwinner,sun8i-h2plus
allwinner,sun9i-a80
nextthing,gr8
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 2e2bde2..3647ad7 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -63,6 +63,7 @@ static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-a23",
"allwinner,sun8i-a33",
"allwinner,sun8i-a83t",
+ "allwinner,sun8i-h2plus",
"allwinner,sun8i-h3",
NULL,
};
--
2.10.1
^ permalink raw reply related
* [PATCH v2 1/2] regulator: Add coupled regulator
From: Mark Brown @ 2016-11-11 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107154738.ewliwzx5plams4ni@lukather>
On Mon, Nov 07, 2016 at 04:47:38PM +0100, Maxime Ripard wrote:
> Since regulator_get returns a struct regulator pointer, it felt
> logical to try to add the list of parent regulators to it, especially
> as this structure is per-consumer, and different consumers might have
> different combinations of regulators.
> However, this structure embeds a pointer to a struct regulator_dev,
> which seems to model the regulator itself, but will also contain
> pointer to the struct regulator, probably to model its parent? I guess
It'd be a lot easier to follow this if you named the fields... The rdev
in the struct regulator is indeed the physical device. The struct
regulator called supply in struct regulator_dev is indeed the parent
regulator.
> my first question would be do we care about nesting? or having a
> regulator with multiple parents?
Well, it seems that your use case here is multiple parents so I guess we
do care about it. :)
> It also contains the constraints on each regulator, which might or
> might not be different for each of the coupled regulators, but I'm
> guessing the couple might have contraints of its own too I guess. Is
> it something that might happen? Should we care about it?
I can't see how one could physically have constraints that didn't apply
to both parents.
> And finally, my real question is, do we want to aggregate them in
> struct regulator, at the consumer level, which might make the more
> sense, or do we want to create an intermediate regulator internally?
> What is your take on this?
My initial thought without having tried to implement this is that doing
things in an intermediate regulator might do a better job of
encapsulating things it if it works out but I've got a feeling that it's
not going to work out well and that therefore doing it in the consumer
with multiple rdevs will be better. But really either approach is fine
if it doesn't look horrible.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/8ecde8e8/attachment.sig>
^ permalink raw reply
* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Auger Eric @ 2016-11-11 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111162211.GU2078@8bytes.org>
Hi Joerg,
On 11/11/2016 17:22, Joerg Roedel wrote:
> Hi Eric,
>
> On Fri, Nov 11, 2016 at 04:47:01PM +0100, Auger Eric wrote:
>> Effectively in passthrough use case, the userspace defines the address
>> space layout and maps guest RAM PA=IOVA to PAs (using
>> VFIO_IOMMU_MAP_DMA). But this address space does not comprise the MSI
>> IOVAs. Userspace does not care about MSI IOMMU mapping. So the MSI IOVA
>> region must be allocated by either the VFIO driver or the IOMMU driver I
>> think. Who else could initialize the IOVA allocator domain?
>
> So I think we need a way to tell userspace about the reserved regions
> (per iommu-group) so that userspace knows where it can not map anything,
Current plan is to expose that info through an iommu-group sysfs
attribute, as you and Robin advised.
> and VFIO can enforce that. But the right struct here is not an
> iova-allocator rb-tree, a ordered linked list should be sufficient.
I plan a linked list to store the reserved regions (P2P regions, MSI
region, ...). get_dma_regions is called with a list local to a function
for that. Might be needed to move that list head in the iommu_group to
avoid calling the get_dm_regions again in the attribute show function?
But to allocate the IOVAs within the MSI reserved region, I understand
you don't want us to use the iova.c allocator, is that correct? We need
an allocator though, even a very basic one based on bitmap or whatever.
There potentially have several different physical MSI frame pages to map.
Best Regards
Eric
>
>
> Joerg
>
^ permalink raw reply
* [PATCH] ARM: davinci: enable PM for DT boot
From: Kevin Hilman @ 2016-11-11 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c73eab0-dadd-f8a0-f822-84296d319443@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> On Tuesday 08 November 2016 11:43 PM, Kevin Hilman wrote:
>> Hi Sekhar,
>>
>> Sekhar Nori <nsekhar@ti.com> writes:
>>
>>> On Wednesday 26 October 2016 03:17 AM, Kevin Hilman wrote:
>>>> Currently system PM is only enabled for legacy (non-DT) boot. Enable
>>>> for DT boot also.
>>>>
>>>> Tested on da850-lcdk using "rtcwake -m mem -s5 -d rtc0".
>>>>
>>>> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>>>> ---
>>>> arch/arm/mach-davinci/da8xx-dt.c | 18 ++++++++++++++++++
>>>> 1 file changed, 18 insertions(+)
>>>>
>>>> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
>>>> index c9f7e9274aa8..a8089fa40d86 100644
>>>> --- a/arch/arm/mach-davinci/da8xx-dt.c
>>>> +++ b/arch/arm/mach-davinci/da8xx-dt.c
>>>> @@ -43,8 +43,26 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
>>>>
>>>> #ifdef CONFIG_ARCH_DAVINCI_DA850
>>>>
>>>> +static struct davinci_pm_config da850_pm_pdata = {
>>>> + .sleepcount = 128,
>>>> +};
>>>> +
>>>> +static struct platform_device da850_pm_device = {
>>>> + .name = "pm-davinci",
>>>> + .dev = {
>>>> + .platform_data = &da850_pm_pdata,
>>>> + },
>>>> + .id = -1,
>>>> +};
>>>> +
>>>> static void __init da850_init_machine(void)
>>>> {
>>>> + int ret;
>>>> +
>>>> + ret = da850_register_pm(&da850_pm_device);
>>>
>>> I am not sure if it makes sense to keep the "pm device" around anymore.
>>> I think for both DT and non-DT boot, we can get rid of the fake PM
>>> device and combine da850_register_pm() and davinci_pm_probe() into a
>>> single davinci_init_suspend() function which can then be called both for
>>> DT and non-DT boot.
>>
>> Looking closer at this, where do you propose the pdata comes from for
>> the non-DT boot?
>>
>> It seems to me that we can't currently remove the pdata dependency
>> without breaking the non-DT platforms, so the approach proposed here is
>> the least invasive.
>
> There is a single value of sleep count that is used today (128). So I
> was thinking we can hardcode that in pm.c. We are not going to add more
> board files anyway so there is no risk here.
>
> For future, if a different sleepcount value is needed, it will need to
> be a new DT property.
Right, but getting rid of the pdata is more than just hard-coding the
sleep count. There are a bunch of other fields in the pdata, which are
filled out to some standard defaults in da850.c. Are you proposing to
hard-code those in pm.c also?
An intermediate step might be to start by removing the
platform_device/pdata from the board files, but keep it in da850.c for
now. Then, a follow-up cleanup could be done to either move all of that
into pm.c, or use DT.
Kevin
^ 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