* [PATCH 1/3] ARM: dts: STiH410-b2260: Identify the UART RTS line
From: Lee Jones @ 2016-12-02 14:11 UTC (permalink / raw)
To: linux-arm-kernel
Configure the UART RTS line as a GPIO for manipulation within the UART driver.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/stih410-b2260.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stih410-b2260.dts b/arch/arm/boot/dts/stih410-b2260.dts
index 7fb507f..f46603f 100644
--- a/arch/arm/boot/dts/stih410-b2260.dts
+++ b/arch/arm/boot/dts/stih410-b2260.dts
@@ -63,6 +63,7 @@
uart0: serial at 9830000 {
label = "LS-UART0";
status = "okay";
+ rts-gpios = <&pio17 3 GPIO_ACTIVE_LOW>;
};
/* Low speed expansion connector */
--
2.10.2
^ permalink raw reply related
* [PATCH 2/3] serial: st-asc: Provide RTS functionality
From: Lee Jones @ 2016-12-02 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202141146.31281-1-lee.jones@linaro.org>
Until this point, it has not been possible for serial applications
to toggle the UART RTS line. This can be useful with certain
configurations. For example, when using a Mezzanine on a Linaro
96board, RTS line is used to take the the on-board microcontroller
in and out of reset.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/tty/serial/st-asc.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
index 379e5bd..ce46898 100644
--- a/drivers/tty/serial/st-asc.c
+++ b/drivers/tty/serial/st-asc.c
@@ -30,6 +30,7 @@
#include <linux/of_platform.h>
#include <linux/serial_core.h>
#include <linux/clk.h>
+#include <linux/gpio/consumer.h>
#define DRIVER_NAME "st-asc"
#define ASC_SERIAL_NAME "ttyAS"
@@ -38,6 +39,7 @@
struct asc_port {
struct uart_port port;
+ struct gpio_desc *rts;
struct clk *clk;
unsigned int hw_flow_control:1;
unsigned int force_m1:1;
@@ -381,12 +383,16 @@ static unsigned int asc_tx_empty(struct uart_port *port)
static void asc_set_mctrl(struct uart_port *port, unsigned int mctrl)
{
+ struct asc_port *ascport = to_asc_port(port);
+
/*
* This routine is used for seting signals of: DTR, DCD, CTS/RTS
* We use ASC's hardware for CTS/RTS, so don't need any for that.
* Some boards have DTR and DCD implemented using PIO pins,
* code to do this should be hooked in here.
*/
+
+ gpiod_set_value(ascport->rts, mctrl & TIOCM_RTS);
}
static unsigned int asc_get_mctrl(struct uart_port *port)
@@ -731,12 +737,20 @@ MODULE_DEVICE_TABLE(of, asc_match);
static int asc_serial_probe(struct platform_device *pdev)
{
int ret;
+ struct device_node *np = pdev->dev.of_node;
struct asc_port *ascport;
+ struct gpio_desc *gpiod;
ascport = asc_of_get_asc_port(pdev);
if (!ascport)
return -ENODEV;
+ gpiod = devm_get_gpiod_from_child(&pdev->dev, "rts", &np->fwnode);
+ if (!IS_ERR(gpiod)) {
+ gpiod_direction_output(gpiod, 0);
+ ascport->rts = gpiod;
+ }
+
ret = asc_init_port(ascport, pdev);
if (ret)
return ret;
--
2.10.2
^ permalink raw reply related
* [PATCH 3/3] serial: st-asc: Ignore the parity error bit if 8-bit mode is enabled
From: Lee Jones @ 2016-12-02 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202141146.31281-1-lee.jones@linaro.org>
The datasheet states:
"If the MODE field selects an 8-bit frame then this [parity error] bit
is undefined. Software should ignore this bit when reading 8-bit frames."
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/tty/serial/st-asc.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
index ce46898..7008eb7 100644
--- a/drivers/tty/serial/st-asc.c
+++ b/drivers/tty/serial/st-asc.c
@@ -289,9 +289,19 @@ static void asc_transmit_chars(struct uart_port *port)
static void asc_receive_chars(struct uart_port *port)
{
struct tty_port *tport = &port->state->port;
- unsigned long status;
+ unsigned long status, mode;
unsigned long c = 0;
char flag;
+ bool ignore_pe = false;
+
+ /*
+ * Datasheet states: If the MODE field selects an 8-bit frame then
+ * this [parity error] bit is undefined. Software should ignore this
+ * bit when reading 8-bit frames.
+ */
+ mode = asc_in(port, ASC_CTL) & ASC_CTL_MODE_MSK;
+ if (mode == ASC_CTL_MODE_8BIT || mode == ASC_CTL_MODE_8BIT_PAR)
+ ignore_pe = true;
if (port->irq_wake)
pm_wakeup_event(tport->tty->dev, 0);
@@ -301,8 +311,8 @@ static void asc_receive_chars(struct uart_port *port)
flag = TTY_NORMAL;
port->icount.rx++;
- if ((c & (ASC_RXBUF_FE | ASC_RXBUF_PE)) ||
- status & ASC_STA_OE) {
+ if (status & ASC_STA_OE || c & ASC_RXBUF_FE ||
+ (c & ASC_RXBUF_PE && !ignore_pe)) {
if (c & ASC_RXBUF_FE) {
if (c == (ASC_RXBUF_FE | ASC_RXBUF_DUMMY_RX)) {
--
2.10.2
^ permalink raw reply related
* [PATCH v2] arm/arm64: xen: Move shared architecture headers to include/xen/arm
From: Marc Zyngier @ 2016-12-02 14:19 UTC (permalink / raw)
To: linux-arm-kernel
ARM and arm64 Xen ports share a number of headers, leading to
packaging issues when these headers needs to be exported, as it
breaks the reasonable requirement that an architecture port
has self-contained headers.
Fix the issue by moving the 5 header files to include/xen/arm,
and keep local placeholders to include the relevant files.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
* From v1:
- Move offending include files to include/xen/arm
arch/arm/include/asm/xen/hypercall.h | 88 +--------------
arch/arm/include/asm/xen/hypervisor.h | 40 +------
arch/arm/include/asm/xen/interface.h | 86 +-------------
arch/arm/include/asm/xen/page-coherent.h | 99 +----------------
arch/arm/include/asm/xen/page.h | 123 +--------------------
arch/arm64/include/asm/xen/hypercall.h | 2 +-
arch/arm64/include/asm/xen/hypervisor.h | 2 +-
arch/arm64/include/asm/xen/interface.h | 2 +-
arch/arm64/include/asm/xen/page-coherent.h | 2 +-
arch/arm64/include/asm/xen/page.h | 2 +-
.../asm/xen => include/xen/arm}/hypercall.h | 0
.../asm/xen => include/xen/arm}/hypervisor.h | 0
.../asm/xen => include/xen/arm}/interface.h | 0
.../asm/xen => include/xen/arm}/page-coherent.h | 0
.../arm/include/asm/xen => include/xen/arm}/page.h | 0
15 files changed, 10 insertions(+), 436 deletions(-)
copy {arch/arm/include/asm/xen => include/xen/arm}/hypercall.h (100%)
copy {arch/arm/include/asm/xen => include/xen/arm}/hypervisor.h (100%)
copy {arch/arm/include/asm/xen => include/xen/arm}/interface.h (100%)
copy {arch/arm/include/asm/xen => include/xen/arm}/page-coherent.h (100%)
copy {arch/arm/include/asm/xen => include/xen/arm}/page.h (100%)
diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 9d874db..3522cba 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -1,87 +1 @@
-/******************************************************************************
- * hypercall.h
- *
- * Linux-specific hypervisor handling.
- *
- * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version 2
- * as published by the Free Software Foundation; or, when distributed
- * separately from the Linux kernel or incorporated into other
- * software packages, subject to the following license:
- *
- * Permission is hereby granted, free of charge, to any person obtaining a copy
- * of this source file (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.
- */
-
-#ifndef _ASM_ARM_XEN_HYPERCALL_H
-#define _ASM_ARM_XEN_HYPERCALL_H
-
-#include <linux/bug.h>
-
-#include <xen/interface/xen.h>
-#include <xen/interface/sched.h>
-#include <xen/interface/platform.h>
-
-long privcmd_call(unsigned call, unsigned long a1,
- unsigned long a2, unsigned long a3,
- unsigned long a4, unsigned long a5);
-int HYPERVISOR_xen_version(int cmd, void *arg);
-int HYPERVISOR_console_io(int cmd, int count, char *str);
-int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
-int HYPERVISOR_sched_op(int cmd, void *arg);
-int HYPERVISOR_event_channel_op(int cmd, void *arg);
-unsigned long HYPERVISOR_hvm_op(int op, void *arg);
-int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
-int HYPERVISOR_physdev_op(int cmd, void *arg);
-int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
-int HYPERVISOR_tmem_op(void *arg);
-int HYPERVISOR_vm_assist(unsigned int cmd, unsigned int type);
-int HYPERVISOR_platform_op_raw(void *arg);
-static inline int HYPERVISOR_platform_op(struct xen_platform_op *op)
-{
- op->interface_version = XENPF_INTERFACE_VERSION;
- return HYPERVISOR_platform_op_raw(op);
-}
-int HYPERVISOR_multicall(struct multicall_entry *calls, uint32_t nr);
-
-static inline int
-HYPERVISOR_suspend(unsigned long start_info_mfn)
-{
- struct sched_shutdown r = { .reason = SHUTDOWN_suspend };
-
- /* start_info_mfn is unused on ARM */
- return HYPERVISOR_sched_op(SCHEDOP_shutdown, &r);
-}
-
-static inline void
-MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
- unsigned int new_val, unsigned long flags)
-{
- BUG();
-}
-
-static inline void
-MULTI_mmu_update(struct multicall_entry *mcl, struct mmu_update *req,
- int count, int *success_count, domid_t domid)
-{
- BUG();
-}
-
-#endif /* _ASM_ARM_XEN_HYPERCALL_H */
+#include <xen/arm/hypercall.h>
diff --git a/arch/arm/include/asm/xen/hypervisor.h b/arch/arm/include/asm/xen/hypervisor.h
index 9525151..d6e7709 100644
--- a/arch/arm/include/asm/xen/hypervisor.h
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -1,39 +1 @@
-#ifndef _ASM_ARM_XEN_HYPERVISOR_H
-#define _ASM_ARM_XEN_HYPERVISOR_H
-
-#include <linux/init.h>
-
-extern struct shared_info *HYPERVISOR_shared_info;
-extern struct start_info *xen_start_info;
-
-/* Lazy mode for batching updates / context switch */
-enum paravirt_lazy_mode {
- PARAVIRT_LAZY_NONE,
- PARAVIRT_LAZY_MMU,
- PARAVIRT_LAZY_CPU,
-};
-
-static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
-{
- return PARAVIRT_LAZY_NONE;
-}
-
-extern struct dma_map_ops *xen_dma_ops;
-
-#ifdef CONFIG_XEN
-void __init xen_early_init(void);
-#else
-static inline void xen_early_init(void) { return; }
-#endif
-
-#ifdef CONFIG_HOTPLUG_CPU
-static inline void xen_arch_register_cpu(int num)
-{
-}
-
-static inline void xen_arch_unregister_cpu(int num)
-{
-}
-#endif
-
-#endif /* _ASM_ARM_XEN_HYPERVISOR_H */
+#include <xen/arm/hypervisor.h>
diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 75d5968..88c0d75 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -1,85 +1 @@
-/******************************************************************************
- * Guest OS interface to ARM Xen.
- *
- * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
- */
-
-#ifndef _ASM_ARM_XEN_INTERFACE_H
-#define _ASM_ARM_XEN_INTERFACE_H
-
-#include <linux/types.h>
-
-#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
-
-#define __DEFINE_GUEST_HANDLE(name, type) \
- typedef struct { union { type *p; uint64_aligned_t q; }; } \
- __guest_handle_ ## name
-
-#define DEFINE_GUEST_HANDLE_STRUCT(name) \
- __DEFINE_GUEST_HANDLE(name, struct name)
-#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
-#define GUEST_HANDLE(name) __guest_handle_ ## name
-
-#define set_xen_guest_handle(hnd, val) \
- do { \
- if (sizeof(hnd) == 8) \
- *(uint64_t *)&(hnd) = 0; \
- (hnd).p = val; \
- } while (0)
-
-#define __HYPERVISOR_platform_op_raw __HYPERVISOR_platform_op
-
-#ifndef __ASSEMBLY__
-/* Explicitly size integers that represent pfns in the interface with
- * Xen so that we can have one ABI that works for 32 and 64 bit guests.
- * Note that this means that the xen_pfn_t type may be capable of
- * representing pfn's which the guest cannot represent in its own pfn
- * type. However since pfn space is controlled by the guest this is
- * fine since it simply wouldn't be able to create any sure pfns in
- * the first place.
- */
-typedef uint64_t xen_pfn_t;
-#define PRI_xen_pfn "llx"
-typedef uint64_t xen_ulong_t;
-#define PRI_xen_ulong "llx"
-typedef int64_t xen_long_t;
-#define PRI_xen_long "llx"
-/* Guest handles for primitive C types. */
-__DEFINE_GUEST_HANDLE(uchar, unsigned char);
-__DEFINE_GUEST_HANDLE(uint, unsigned int);
-DEFINE_GUEST_HANDLE(char);
-DEFINE_GUEST_HANDLE(int);
-DEFINE_GUEST_HANDLE(void);
-DEFINE_GUEST_HANDLE(uint64_t);
-DEFINE_GUEST_HANDLE(uint32_t);
-DEFINE_GUEST_HANDLE(xen_pfn_t);
-DEFINE_GUEST_HANDLE(xen_ulong_t);
-
-/* Maximum number of virtual CPUs in multi-processor guests. */
-#define MAX_VIRT_CPUS 1
-
-struct arch_vcpu_info { };
-struct arch_shared_info { };
-
-/* TODO: Move pvclock definitions some place arch independent */
-struct pvclock_vcpu_time_info {
- u32 version;
- u32 pad0;
- u64 tsc_timestamp;
- u64 system_time;
- u32 tsc_to_system_mul;
- s8 tsc_shift;
- u8 flags;
- u8 pad[2];
-} __attribute__((__packed__)); /* 32 bytes */
-
-/* It is OK to have a 12 bytes struct with no padding because it is packed */
-struct pvclock_wall_clock {
- u32 version;
- u32 sec;
- u32 nsec;
- u32 sec_hi;
-} __attribute__((__packed__));
-#endif
-
-#endif /* _ASM_ARM_XEN_INTERFACE_H */
+#include <xen/arm/interface.h>
diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index 95ce6ac..b3ef061 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -1,98 +1 @@
-#ifndef _ASM_ARM_XEN_PAGE_COHERENT_H
-#define _ASM_ARM_XEN_PAGE_COHERENT_H
-
-#include <asm/page.h>
-#include <linux/dma-mapping.h>
-
-void __xen_dma_map_page(struct device *hwdev, struct page *page,
- dma_addr_t dev_addr, unsigned long offset, size_t size,
- enum dma_data_direction dir, unsigned long attrs);
-void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
- size_t size, enum dma_data_direction dir,
- unsigned long attrs);
-void __xen_dma_sync_single_for_cpu(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir);
-
-void __xen_dma_sync_single_for_device(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir);
-
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
- dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
-{
- return __generic_dma_ops(hwdev)->alloc(hwdev, size, dma_handle, flags, attrs);
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
- void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
-{
- __generic_dma_ops(hwdev)->free(hwdev, size, cpu_addr, dma_handle, attrs);
-}
-
-static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
- dma_addr_t dev_addr, unsigned long offset, size_t size,
- enum dma_data_direction dir, unsigned long attrs)
-{
- unsigned long page_pfn = page_to_xen_pfn(page);
- unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
- unsigned long compound_pages =
- (1<<compound_order(page)) * XEN_PFN_PER_PAGE;
- bool local = (page_pfn <= dev_pfn) &&
- (dev_pfn - page_pfn < compound_pages);
-
- /*
- * Dom0 is mapped 1:1, while the Linux page can span across
- * multiple Xen pages, it's not possible for it to contain a
- * mix of local and foreign Xen pages. So if the first xen_pfn
- * == mfn the page is local otherwise it's a foreign page
- * grant-mapped in dom0. If the page is local we can safely
- * call the native dma_ops function, otherwise we call the xen
- * specific function.
- */
- if (local)
- __generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
- else
- __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
-}
-
-static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
- size_t size, enum dma_data_direction dir, unsigned long attrs)
-{
- unsigned long pfn = PFN_DOWN(handle);
- /*
- * Dom0 is mapped 1:1, while the Linux page can be spanned accross
- * multiple Xen page, it's not possible to have a mix of local and
- * foreign Xen page. Dom0 is mapped 1:1, so calling pfn_valid on a
- * foreign mfn will always return false. If the page is local we can
- * safely call the native dma_ops function, otherwise we call the xen
- * specific function.
- */
- if (pfn_valid(pfn)) {
- if (__generic_dma_ops(hwdev)->unmap_page)
- __generic_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);
- } else
- __xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
-}
-
-static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- unsigned long pfn = PFN_DOWN(handle);
- if (pfn_valid(pfn)) {
- if (__generic_dma_ops(hwdev)->sync_single_for_cpu)
- __generic_dma_ops(hwdev)->sync_single_for_cpu(hwdev, handle, size, dir);
- } else
- __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
-}
-
-static inline void xen_dma_sync_single_for_device(struct device *hwdev,
- dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
- unsigned long pfn = PFN_DOWN(handle);
- if (pfn_valid(pfn)) {
- if (__generic_dma_ops(hwdev)->sync_single_for_device)
- __generic_dma_ops(hwdev)->sync_single_for_device(hwdev, handle, size, dir);
- } else
- __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
-}
-
-#endif /* _ASM_ARM_XEN_PAGE_COHERENT_H */
+#include <xen/arm/page-coherent.h>
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 415dbc6..31bbc80 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -1,122 +1 @@
-#ifndef _ASM_ARM_XEN_PAGE_H
-#define _ASM_ARM_XEN_PAGE_H
-
-#include <asm/page.h>
-#include <asm/pgtable.h>
-
-#include <linux/pfn.h>
-#include <linux/types.h>
-#include <linux/dma-mapping.h>
-
-#include <xen/xen.h>
-#include <xen/interface/grant_table.h>
-
-#define phys_to_machine_mapping_valid(pfn) (1)
-
-/* Xen machine address */
-typedef struct xmaddr {
- phys_addr_t maddr;
-} xmaddr_t;
-
-/* Xen pseudo-physical address */
-typedef struct xpaddr {
- phys_addr_t paddr;
-} xpaddr_t;
-
-#define XMADDR(x) ((xmaddr_t) { .maddr = (x) })
-#define XPADDR(x) ((xpaddr_t) { .paddr = (x) })
-
-#define INVALID_P2M_ENTRY (~0UL)
-
-/*
- * The pseudo-physical frame (pfn) used in all the helpers is always based
- * on Xen page granularity (i.e 4KB).
- *
- * A Linux page may be split across multiple non-contiguous Xen page so we
- * have to keep track with frame based on 4KB page granularity.
- *
- * PV drivers should never make a direct usage of those helpers (particularly
- * pfn_to_gfn and gfn_to_pfn).
- */
-
-unsigned long __pfn_to_mfn(unsigned long pfn);
-extern struct rb_root phys_to_mach;
-
-/* Pseudo-physical <-> Guest conversion */
-static inline unsigned long pfn_to_gfn(unsigned long pfn)
-{
- return pfn;
-}
-
-static inline unsigned long gfn_to_pfn(unsigned long gfn)
-{
- return gfn;
-}
-
-/* Pseudo-physical <-> BUS conversion */
-static inline unsigned long pfn_to_bfn(unsigned long pfn)
-{
- unsigned long mfn;
-
- if (phys_to_mach.rb_node != NULL) {
- mfn = __pfn_to_mfn(pfn);
- if (mfn != INVALID_P2M_ENTRY)
- return mfn;
- }
-
- return pfn;
-}
-
-static inline unsigned long bfn_to_pfn(unsigned long bfn)
-{
- return bfn;
-}
-
-#define bfn_to_local_pfn(bfn) bfn_to_pfn(bfn)
-
-/* VIRT <-> GUEST conversion */
-#define virt_to_gfn(v) (pfn_to_gfn(virt_to_phys(v) >> XEN_PAGE_SHIFT))
-#define gfn_to_virt(m) (__va(gfn_to_pfn(m) << XEN_PAGE_SHIFT))
-
-/* Only used in PV code. But ARM guests are always HVM. */
-static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
-{
- BUG();
-}
-
-/* TODO: this shouldn't be here but it is because the frontend drivers
- * are using it (its rolled in headers) even though we won't hit the code path.
- * So for right now just punt with this.
- */
-static inline pte_t *lookup_address(unsigned long address, unsigned int *level)
-{
- BUG();
- return NULL;
-}
-
-extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
- struct gnttab_map_grant_ref *kmap_ops,
- struct page **pages, unsigned int count);
-
-extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
- struct gnttab_unmap_grant_ref *kunmap_ops,
- struct page **pages, unsigned int count);
-
-bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
-bool __set_phys_to_machine_multi(unsigned long pfn, unsigned long mfn,
- unsigned long nr_pages);
-
-static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
-{
- return __set_phys_to_machine(pfn, mfn);
-}
-
-#define xen_remap(cookie, size) ioremap_cache((cookie), (size))
-#define xen_unmap(cookie) iounmap((cookie))
-
-bool xen_arch_need_swiotlb(struct device *dev,
- phys_addr_t phys,
- dma_addr_t dev_addr);
-unsigned long xen_get_swiotlb_free_pages(unsigned int order);
-
-#endif /* _ASM_ARM_XEN_PAGE_H */
+#include <xen/arm/page.h>
diff --git a/arch/arm64/include/asm/xen/hypercall.h b/arch/arm64/include/asm/xen/hypercall.h
index 74b0c42..3522cba 100644
--- a/arch/arm64/include/asm/xen/hypercall.h
+++ b/arch/arm64/include/asm/xen/hypercall.h
@@ -1 +1 @@
-#include <../../arm/include/asm/xen/hypercall.h>
+#include <xen/arm/hypercall.h>
diff --git a/arch/arm64/include/asm/xen/hypervisor.h b/arch/arm64/include/asm/xen/hypervisor.h
index f263da8..d6e7709 100644
--- a/arch/arm64/include/asm/xen/hypervisor.h
+++ b/arch/arm64/include/asm/xen/hypervisor.h
@@ -1 +1 @@
-#include <../../arm/include/asm/xen/hypervisor.h>
+#include <xen/arm/hypervisor.h>
diff --git a/arch/arm64/include/asm/xen/interface.h b/arch/arm64/include/asm/xen/interface.h
index 44457ae..88c0d75 100644
--- a/arch/arm64/include/asm/xen/interface.h
+++ b/arch/arm64/include/asm/xen/interface.h
@@ -1 +1 @@
-#include <../../arm/include/asm/xen/interface.h>
+#include <xen/arm/interface.h>
diff --git a/arch/arm64/include/asm/xen/page-coherent.h b/arch/arm64/include/asm/xen/page-coherent.h
index 2052102..b3ef061 100644
--- a/arch/arm64/include/asm/xen/page-coherent.h
+++ b/arch/arm64/include/asm/xen/page-coherent.h
@@ -1 +1 @@
-#include <../../arm/include/asm/xen/page-coherent.h>
+#include <xen/arm/page-coherent.h>
diff --git a/arch/arm64/include/asm/xen/page.h b/arch/arm64/include/asm/xen/page.h
index bed87ec..31bbc80 100644
--- a/arch/arm64/include/asm/xen/page.h
+++ b/arch/arm64/include/asm/xen/page.h
@@ -1 +1 @@
-#include <../../arm/include/asm/xen/page.h>
+#include <xen/arm/page.h>
diff --git a/arch/arm/include/asm/xen/hypercall.h b/include/xen/arm/hypercall.h
similarity index 100%
copy from arch/arm/include/asm/xen/hypercall.h
copy to include/xen/arm/hypercall.h
diff --git a/arch/arm/include/asm/xen/hypervisor.h b/include/xen/arm/hypervisor.h
similarity index 100%
copy from arch/arm/include/asm/xen/hypervisor.h
copy to include/xen/arm/hypervisor.h
diff --git a/arch/arm/include/asm/xen/interface.h b/include/xen/arm/interface.h
similarity index 100%
copy from arch/arm/include/asm/xen/interface.h
copy to include/xen/arm/interface.h
diff --git a/arch/arm/include/asm/xen/page-coherent.h b/include/xen/arm/page-coherent.h
similarity index 100%
copy from arch/arm/include/asm/xen/page-coherent.h
copy to include/xen/arm/page-coherent.h
diff --git a/arch/arm/include/asm/xen/page.h b/include/xen/arm/page.h
similarity index 100%
copy from arch/arm/include/asm/xen/page.h
copy to include/xen/arm/page.h
--
2.1.4
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Icenowy Zheng @ 2016-12-02 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201093619.gs6lmoxtlptp2jr6@lukather>
01.12.2016, 17:36, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Mon, Nov 28, 2016 at 12:29:07AM +0000, Andr? Przywara wrote:
>> ?> Something more interesting happened.
>> ?>
>> ?> Xunlong made a add-on board for Orange Pi Zero, which exposes the
>> ?> two USB Controllers exported at expansion bus as USB Type-A
>> ?> connectors.
>> ?>
>> ?> Also it exposes a analog A/V jack and a microphone.
>> ?>
>> ?> Should I enable {e,o}hci{2.3} in the device tree?
>>
>> ?Actually we should do this regardless of this extension board. The USB
>> ?pins are not multiplexed and are exposed on user accessible pins (just
>> ?not soldered, but that's a detail), so I think they qualify for DT
>> ?enablement. And even if a user can't use them, it doesn't hurt to have
>> ?them (since they are not multiplexed).
>
> My main concern about this is that we'll leave regulators enabled by
> default, for a minority of users. And that minority will prevent to do
> a proper power management when the times come since we'll have to keep
> that behaviour forever.
I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH v3 3/7] PWM: add pwm-stm32 DT bindings
From: Lee Jones @ 2016-12-02 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480673842-20804-4-git-send-email-benjamin.gaignard@st.com>
On Fri, 02 Dec 2016, Benjamin Gaignard wrote:
> Define bindings for pwm-stm32
>
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/pwm/pwm-stm32.txt | 38 ++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> new file mode 100644
> index 0000000..575b9fb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> @@ -0,0 +1,38 @@
> +STMicroelectronics PWM driver bindings for STM32
> +
> +Must be a sub-node of STM32 general purpose timer driver
> +Parent node properties are describe in ../mfd/stm32-general-purpose-timer.txt
> +
> +Required parameters:
> +- compatible: Must be "st,stm32-pwm"
> +- pinctrl-names: Set to "default".
> +- pinctrl-0: List of phandles pointing to pin configuration nodes
> + for PWM module.
> + For Pinctrl properties, please refer to [1].
> +
> +Optional parameters:
> +- st,breakinput: Set if the hardware have break input capabilities
> +- st,breakinput-polarity: Set break input polarity. Default is 0
> + The value define the active polarity:
> + - 0 (active LOW)
> + - 1 (active HIGH)
> +- st,breakinput-polarity-high
Then assume the default if the property is not present.
> +- st,pwm-num-chan: Number of available PWM channels. Default is 0.
What's the point in having a PWM device with no channels?
Best to make this a compulsory property.
> +- st,32bits-counter: Set if the hardware have a 32 bits counter
> +- st,complementary: Set if the hardware have complementary output channels
> +
> +[1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
Use relative path.
../pinctrl/pinctrl-bindings.txt
> +Example:
> + gptimer1: gptimer1 at 40010000 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm1 at 0 {
Don't number the node name.
pwm at xx
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,breakinput;
> + st,complementary;
> + };
> + };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v3 5/7] IIO: add bindings for stm32 timer trigger driver
From: Benjamin Gaignard @ 2016-12-02 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202135904.GN2683@dell>
2016-12-02 14:59 GMT+01:00 Lee Jones <lee.jones@linaro.org>:
> On Fri, 02 Dec 2016, Benjamin Gaignard wrote:
>
>> Define bindings for stm32 timer trigger
>>
>> version 3:
>> - change file name
>> - add cross reference with mfd bindings
>>
>> version 2:
>> - only keep one compatible
>> - add DT parameters to set lists of the triggers:
>> one list describe the triggers created by the device
>> another one give the triggers accepted by the device
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>> .../bindings/iio/timer/stm32-timer-trigger.txt | 39 ++++++++++++++++++++++
>> 1 file changed, 39 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt b/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
>> new file mode 100644
>> index 0000000..858816d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
>> @@ -0,0 +1,39 @@
>> +timer trigger bindings for STM32
>> +
>> +Must be a sub-node of STM32 general purpose timer driver
>> +Parent node properties are describe in ../mfd/stm32-general-purpose-timer.txt
>> +
>> +Required parameters:
>> +- compatible: must be "st,stm32-iio-timer"
>> +- interrupts: Interrupt for this device
>> + See ../interrupt-controller/st,stm32-exti.txt
>> +
>> +Optional parameters:
>> +- st,input-triggers-names: List of the possible input triggers for
>> + the device
>> +- st,output-triggers-names: List of the possible output triggers for
>> + the device
>> +
>> +Possible triggers are defined in include/dt-bindings/iio/timer/st,stm32-timer-trigger.h
>> +
>> +Example:
>> + gptimer1: gptimer1 at 40010000 {
>> + compatible = "st,stm32-gptimer";
>> + reg = <0x40010000 0x400>;
>> + clocks = <&rcc 0 160>;
>> + clock-names = "clk_int";
>> +
>> + timer1 at 0 {
>> + compatible = "st,stm32-timer-trigger";
>> + interrupts = <27>;
>> + st,input-triggers-names = TIM5_TRGO,
>> + TIM2_TRGO,
>> + TIM4_TRGO,
>> + TIM3_TRGO;
>> + st,output-triggers-names = TIM1_TRGO,
>> + TIM1_CH1,
>> + TIM1_CH2,
>> + TIM1_CH3,
>> + TIM1_CH4;
>
> I see why you've done it like this now ... because it makes things
> easier for you in the driver, since the IIO subsystem matches on names
> such as these.
>
> BUT, this is a Linux-implementation-ism. Just use pairs of integers
> and create the Linux-ism strings in the driver.
The goal is not to make things easier in driver but to be able to share
the triggers names with other drivers like DAC or ADC.
If each driver have to create it own triggers names it will more difficult
to keep them coherent than it they share the same definitions
>
>> + };
>> + };
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v3 2/7] MFD: add stm32 general purpose timer driver
From: Lee Jones @ 2016-12-02 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480673842-20804-3-git-send-email-benjamin.gaignard@st.com>
On Fri, 02 Dec 2016, Benjamin Gaignard wrote:
> This hardware block could at used at same time for PWM generation
> and IIO timer for other IPs like DAC, ADC or other timers.
> PWM and IIO timer configuration are mixed in the same registers
> so we need a multi fonction driver to be able to share those registers.
>
> version 2:
> - rename driver "stm32-gptimer" to be align with SoC documentation
> - only keep one compatible
> - use of_platform_populate() instead of devm_mfd_add_devices()
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> drivers/mfd/Kconfig | 10 ++++++
> drivers/mfd/Makefile | 2 ++
> drivers/mfd/stm32-gptimer.c | 73 +++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/stm32-gptimer.h | 62 +++++++++++++++++++++++++++++++++
> 4 files changed, 147 insertions(+)
> create mode 100644 drivers/mfd/stm32-gptimer.c
> create mode 100644 include/linux/mfd/stm32-gptimer.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index c6df644..e75abcb 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1607,6 +1607,15 @@ config MFD_STW481X
> in various ST Microelectronics and ST-Ericsson embedded
> Nomadik series.
>
> +config MFD_STM32_GP_TIMER
> + tristate "Support for STM32 General Purpose Timer"
> + select MFD_CORE
> + select REGMAP
> + depends on ARCH_STM32
> + depends on OF
"|| COMPILE_TEST"?
> + help
> + Select this option to enable stm32 general purpose timer
I can see that. Tell us more about the device and what it does.
s/stm32/STM32/
> menu "Multimedia Capabilities Port drivers"
> depends on ARCH_SA1100
>
> @@ -1644,4 +1653,5 @@ config MFD_VEXPRESS_SYSREG
> on the ARM Ltd. Versatile Express board.
>
> endmenu
> +
Please remove this change. It has nothing to do with the set.
> endif
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9834e66..86353b9 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -211,3 +211,5 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> +
> +obj-$(CONFIG_MFD_STM32_GP_TIMER) += stm32-gptimer.o
> diff --git a/drivers/mfd/stm32-gptimer.c b/drivers/mfd/stm32-gptimer.c
> new file mode 100644
> index 0000000..54fb95c
> --- /dev/null
> +++ b/drivers/mfd/stm32-gptimer.c
> @@ -0,0 +1,73 @@
> +/*
> + * stm32-gptimer.c
Swap this out for a description.
> + * Copyright (C) STMicroelectronics 2016
'\n'
> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
> + * License terms: GNU General Public License (GPL), version 2
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/reset.h>
> +
> +#include <linux/mfd/stm32-gptimer.h>
> +
> +static const struct regmap_config stm32_gptimer_regmap_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = sizeof(u32),
> + .max_register = 0x400,
> + .fast_io = true,
> +};
> +
> +static int stm32_gptimer_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct stm32_gptimer_dev *mfd;
s/mfd/ddata/
> + struct resource *res;
> + void __iomem *mmio;
> +
> + mfd = devm_kzalloc(dev, sizeof(*mfd), GFP_KERNEL);
> + if (!mfd)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -ENOMEM;
> +
Remove this 3 lines.
devm_ioremap_resource() does the checking and error printing for you.
> + mmio = devm_ioremap_resource(dev, res);
> + if (IS_ERR(mmio))
> + return PTR_ERR(mmio);
> +
> + mfd->regmap = devm_regmap_init_mmio_clk(dev, "clk_int", mmio,
> + &stm32_gptimer_regmap_cfg);
> + if (IS_ERR(mfd->regmap))
> + return PTR_ERR(mfd->regmap);
> +
> + mfd->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(mfd->clk))
> + return PTR_ERR(mfd->clk);
> +
> + platform_set_drvdata(pdev, mfd);
> +
> + return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> +}
> +
> +static const struct of_device_id stm32_gptimer_of_match[] = {
> + {
> + .compatible = "st,stm32-gptimer",
> + },
One line:
{ .compatible = "st,stm32-gptimer" },
> +};
> +MODULE_DEVICE_TABLE(of, stm32_gptimer_of_match);
> +
> +static struct platform_driver stm32_gptimer_driver = {
> + .probe = stm32_gptimer_probe,
> + .driver = {
> + .name = "stm32-gptimer",
> + .of_match_table = stm32_gptimer_of_match,
> + },
Remove tabs before the '='s.
> +module_platform_driver(stm32_gptimer_driver);
> +
> +MODULE_DESCRIPTION("STMicroelectronics STM32 general purpose timer");
"General Purpose Timer"
> +MODULE_LICENSE("GPL");
"GPL v2"
> diff --git a/include/linux/mfd/stm32-gptimer.h b/include/linux/mfd/stm32-gptimer.h
> new file mode 100644
> index 0000000..f8c92de
> --- /dev/null
> +++ b/include/linux/mfd/stm32-gptimer.h
> @@ -0,0 +1,62 @@
> +/*
> + * stm32-gptimer.h
> + *
> + * Copyright (C) STMicroelectronics 2016
> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
> + * License terms: GNU General Public License (GPL), version 2
> + */
Same comments as before.
> +#ifndef _LINUX_STM32_GPTIMER_H_
> +#define _LINUX_STM32_GPTIMER_H_
> +
> +#include <linux/clk.h>
> +#include <linux/regmap.h>
> +
> +#define TIM_CR1 0x00 /* Control Register 1 */
> +#define TIM_CR2 0x04 /* Control Register 2 */
> +#define TIM_SMCR 0x08 /* Slave mode control reg */
> +#define TIM_DIER 0x0C /* DMA/interrupt register */
> +#define TIM_SR 0x10 /* Status register */
> +#define TIM_EGR 0x14 /* Event Generation Reg */
> +#define TIM_CCMR1 0x18 /* Capt/Comp 1 Mode Reg */
> +#define TIM_CCMR2 0x1C /* Capt/Comp 2 Mode Reg */
> +#define TIM_CCER 0x20 /* Capt/Comp Enable Reg */
> +#define TIM_PSC 0x28 /* Prescaler */
> +#define TIM_ARR 0x2c /* Auto-Reload Register */
> +#define TIM_CCR1 0x34 /* Capt/Comp Register 1 */
> +#define TIM_CCR2 0x38 /* Capt/Comp Register 2 */
> +#define TIM_CCR3 0x3C /* Capt/Comp Register 3 */
> +#define TIM_CCR4 0x40 /* Capt/Comp Register 4 */
> +#define TIM_BDTR 0x44 /* Break and Dead-Time Reg */
> +
> +#define TIM_CR1_CEN BIT(0) /* Counter Enable */
> +#define TIM_CR1_ARPE BIT(7) /* Auto-reload Preload Ena */
> +#define TIM_CR2_MMS (BIT(4) | BIT(5) | BIT(6)) /* Master mode selection */
> +#define TIM_SMCR_SMS (BIT(0) | BIT(1) | BIT(2)) /* Slave mode selection */
> +#define TIM_SMCR_TS (BIT(4) | BIT(5) | BIT(6)) /* Trigger selection */
> +#define TIM_DIER_UIE BIT(0) /* Update interrupt */
> +#define TIM_SR_UIF BIT(0) /* Update interrupt flag */
> +#define TIM_EGR_UG BIT(0) /* Update Generation */
> +#define TIM_CCMR_PE BIT(3) /* Channel Preload Enable */
> +#define TIM_CCMR_M1 (BIT(6) | BIT(5)) /* Channel PWM Mode 1 */
> +#define TIM_CCER_CC1E BIT(0) /* Capt/Comp 1 out Ena */
> +#define TIM_CCER_CC1P BIT(1) /* Capt/Comp 1 Polarity */
> +#define TIM_CCER_CC1NE BIT(2) /* Capt/Comp 1N out Ena */
> +#define TIM_CCER_CC1NP BIT(3) /* Capt/Comp 1N Polarity */
> +#define TIM_CCER_CCXE (BIT(0) | BIT(4) | BIT(8) | BIT(12))
> +#define TIM_BDTR_BKE BIT(12) /* Break input enable */
> +#define TIM_BDTR_BKP BIT(13) /* Break input polarity */
> +#define TIM_BDTR_AOE BIT(14) /* Automatic Output Enable */
> +#define TIM_BDTR_MOE BIT(15) /* Main Output Enable */
> +
> +#define MAX_TIM_PSC 0xFFFF
> +
> +struct stm32_gptimer_dev {
Drop the "_dev" or replace with ddata.
> + /* Device data */
No need for this.
> + struct clk *clk;
> +
> + /* Registers mapping */
No need for this.
> + struct regmap *regmap;
> +};
> +
> +#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Hans de Goede @ 2016-12-02 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11498641480688550@web2g.yandex.ru>
Hi,
On 02-12-16 15:22, Icenowy Zheng wrote:
>
>
> 01.12.2016, 17:36, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> On Mon, Nov 28, 2016 at 12:29:07AM +0000, Andr? Przywara wrote:
>>> > Something more interesting happened.
>>> >
>>> > Xunlong made a add-on board for Orange Pi Zero, which exposes the
>>> > two USB Controllers exported at expansion bus as USB Type-A
>>> > connectors.
>>> >
>>> > Also it exposes a analog A/V jack and a microphone.
>>> >
>>> > Should I enable {e,o}hci{2.3} in the device tree?
>>>
>>> Actually we should do this regardless of this extension board. The USB
>>> pins are not multiplexed and are exposed on user accessible pins (just
>>> not soldered, but that's a detail), so I think they qualify for DT
>>> enablement. And even if a user can't use them, it doesn't hurt to have
>>> them (since they are not multiplexed).
>>
>> My main concern about this is that we'll leave regulators enabled by
>> default, for a minority of users. And that minority will prevent to do
>> a proper power management when the times come since we'll have to keep
>> that behaviour forever.
>
> I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .
I don't think that will be necessary I'm pretty sure these extra usb
ports do not have a regulator for the Vbus, they just hook directly
to the 5V rail, can someone with a schematic check ?
Regards,
Hans
^ permalink raw reply
* [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Icenowy Zheng @ 2016-12-02 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <efb30303-b9bb-7a7c-4478-af485991dd86@redhat.com>
02.12.2016, 22:30, "Hans de Goede" <hdegoede@redhat.com>:
> Hi,
>
> On 02-12-16 15:22, Icenowy Zheng wrote:
>> ?01.12.2016, 17:36, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>>> ?On Mon, Nov 28, 2016 at 12:29:07AM +0000, Andr? Przywara wrote:
>>>> ??> Something more interesting happened.
>>>> ??>
>>>> ??> Xunlong made a add-on board for Orange Pi Zero, which exposes the
>>>> ??> two USB Controllers exported at expansion bus as USB Type-A
>>>> ??> connectors.
>>>> ??>
>>>> ??> Also it exposes a analog A/V jack and a microphone.
>>>> ??>
>>>> ??> Should I enable {e,o}hci{2.3} in the device tree?
>>>>
>>>> ??Actually we should do this regardless of this extension board. The USB
>>>> ??pins are not multiplexed and are exposed on user accessible pins (just
>>>> ??not soldered, but that's a detail), so I think they qualify for DT
>>>> ??enablement. And even if a user can't use them, it doesn't hurt to have
>>>> ??them (since they are not multiplexed).
>>>
>>> ?My main concern about this is that we'll leave regulators enabled by
>>> ?default, for a minority of users. And that minority will prevent to do
>>> ?a proper power management when the times come since we'll have to keep
>>> ?that behaviour forever.
>>
>> ?I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .
>
> I don't think that will be necessary I'm pretty sure these extra usb
> ports do not have a regulator for the Vbus, they just hook directly
> to the 5V rail, can someone with a schematic check ?
We seems to have still no schematics for the add-on board.
But something is sure is that there's no any regulator-related pins
on the add-on pinout. There's only USB DM and DP pins.
So the Vbus must be directly connected to +5V.
>
> Regards,
>
> Hans
^ permalink raw reply
* [PATCH] ARM: dts: imx6q-utilite-pro: enable 2nd display pipeline
From: christopher.spinrath at rwth-aachen.de @ 2016-12-02 14:37 UTC (permalink / raw)
To: linux-arm-kernel
From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
Apart from the already enabled Designware HDMI port, the Utilite Pro
has a second display pipeline which has the following shape:
IPU1 DI0 --> Parallel display --> tfp410 rgb24 to DVI encoder
--> HDMI connector.
Enable support for it.
In addition, since this pipeline is hardwired to IPU1, sever the link
between IPU1 and the SoC-internal Designware HDMI encoder forcing the
latter to be connected to IPU2 instead of IPU1. Otherwise, it is not
possible to drive both displays at high resolution due to the bandwidth
limitations of a single IPU.
Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
---
Hi all,
the removal of the link between IPU1 and the Designware HDMI encoder is the
result of a discussion I had with Philipp Zabel:
https://lists.freedesktop.org/archives/dri-devel/2016-November/125399.html .
Altough it is not possible to connect anything else to IPU1 on the Utilite, this
approach has at least one disadvantage: if the resolution is low enough such
that a single IPU can handle both displays then muxing both displays to IPU1
would reduce the power consumption.
However, IMHO omitting the link IPU1 <--> DW HDMI is still the preferrable
solution since I'm not aware of any OS/driver that is capable of switching IPUs
or can handle the bandwidth limitation in a sane way. In particular, Linux is
unusable when both displays are supposed to be driven at high resolution and
both muxing options for the DW HDMI are available (this is not a userspace
issue; the system becomes almost unresponsive as soon as the kernel sets the
initial resolution).
Cheers,
Christopher
P.S.: this patch depends on the tfp410 bridge driver which has recently been
merged into drm-next.
arch/arm/boot/dts/imx6q-utilite-pro.dts | 115 ++++++++++++++++++++++++++++++++
1 file changed, 115 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
index 2200994..69bdd82 100644
--- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
+++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
@@ -59,6 +59,33 @@
rtc1 = &snvs_rtc;
};
+ encoder {
+ compatible = "ti,tfp410";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ tfp410_in: endpoint {
+ remote-endpoint = <¶llel_display_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ tfp410_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
pinctrl-names = "default";
@@ -72,6 +99,19 @@
};
};
+ hdmi-connector {
+ compatible = "hdmi-connector";
+
+ type = "a";
+ ddc-i2c-bus = <&i2c_dvi_ddc>;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+ };
+
i2cmux {
compatible = "i2c-mux-gpio";
pinctrl-names = "default";
@@ -105,8 +145,46 @@
#size-cells = <0>;
};
};
+
+ parallel-display {
+ compatible = "fsl,imx-parallel-display";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1>;
+
+ interface-pix-fmt = "rgb24";
+
+ port at 0 {
+ reg = <0>;
+
+ parallel_display_in: endpoint {
+ remote-endpoint = <&ipu1_di0_disp0>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ parallel_display_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ };
+ };
+ };
};
+/*
+ * A single IPU is not able to drive both display interfaces available on the
+ * Utilite Pro at high resolution due to its bandwidth limitation. Since the
+ * tfp410 encoder is wired up to IPU1, sever the link between IPU1 and the
+ * SoC-internal Designware HDMI encoder forcing the latter to be connected to
+ * IPU2 instead of IPU1.
+ */
+/delete-node/&ipu1_di0_hdmi;
+/delete-node/&hdmi_mux_0;
+/delete-node/&ipu1_di1_hdmi;
+/delete-node/&hdmi_mux_1;
+
&hdmi {
ddc-i2c-bus = <&i2c2>;
status = "okay";
@@ -151,6 +229,39 @@
>;
};
+ pinctrl_ipu1: ipu1grp {
+ fsl,pins = <
+ MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x38
+ MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x38
+ MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x38
+ MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x38
+ MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0x38
+ MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x38
+ MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x38
+ MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x38
+ MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x38
+ MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x38
+ MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x38
+ MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x38
+ MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x38
+ MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x38
+ MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x38
+ MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x38
+ MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x38
+ MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x38
+ MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x38
+ MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x38
+ MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x38
+ MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x38
+ MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0x38
+ MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0x38
+ MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0x38
+ MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0x38
+ MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0x38
+ MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0x38
+ >;
+ };
+
pinctrl_uart2: uart2grp {
fsl,pins = <
MX6QDL_PAD_GPIO_7__UART2_TX_DATA 0x1b0b1
@@ -194,6 +305,10 @@
};
};
+&ipu1_di0_disp0 {
+ remote-endpoint = <¶llel_display_in>;
+};
+
&pcie {
pcie at 0,0 {
reg = <0x000000 0 0 0 0>;
--
2.10.2
^ permalink raw reply related
* [PATCH 1/3] nvmem: imx-ocotp: Add support for i.MX6UL
From: Daniel Schultz @ 2016-12-02 14:45 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds OCOTP support for the i.MX6UL SoC.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
---
Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 5 +++--
drivers/nvmem/imx-ocotp.c | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
index 383d588..fcb1a48 100644
--- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
+++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
@@ -1,13 +1,14 @@
Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings
This binding represents the on-chip eFuse OTP controller found on
-i.MX6Q/D, i.MX6DL/S, i.MX6SL, and i.MX6SX SoCs.
+i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX and i.MX6UL SoCs.
Required properties:
- compatible: should be one of
"fsl,imx6q-ocotp" (i.MX6Q/D/DL/S),
"fsl,imx6sl-ocotp" (i.MX6SL), or
- "fsl,imx6sx-ocotp" (i.MX6SX), followed by "syscon".
+ "fsl,imx6sx-ocotp" (i.MX6SX), or
+ "fsl,imx6ul-ocotp" (i.MX6UL), followed by "syscon".
- reg: Should contain the register base and length.
- clocks: Should contain a phandle pointing to the gated peripheral clock.
diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index ac27b9b..d2f78d3 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -71,6 +71,7 @@ static int imx_ocotp_read(void *context, unsigned int offset,
static const struct of_device_id imx_ocotp_dt_ids[] = {
{ .compatible = "fsl,imx6q-ocotp", (void *)128 },
+ { .compatible = "fsl,imx6ul-ocotp", (void *)128 },
{ .compatible = "fsl,imx6sl-ocotp", (void *)32 },
{ .compatible = "fsl,imx6sx-ocotp", (void *)128 },
{ },
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: imx6ul: Add OCOTP node
From: Daniel Schultz @ 2016-12-02 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480689949-17957-1-git-send-email-d.schultz@phytec.de>
This device node adds OCOTP for the i.MX6UL SoC.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
---
arch/arm/boot/dts/imx6ul.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index c5c05fd..ee53795 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -849,6 +849,12 @@
reg = <0x021b0000 0x4000>;
};
+ ocotp: ocotp at 021bc000 {
+ compatible = "fsl,imx6ul-ocotp";
+ reg = <0x021bc000 0x4000>;
+ clocks = <&clks IMX6UL_CLK_OCOTP>;
+ };
+
lcdif: lcdif at 021c8000 {
compatible = "fsl,imx6ul-lcdif", "fsl,imx28-lcdif";
reg = <0x021c8000 0x4000>;
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] nvmem: imx-ocotp: Fix wrong register size
From: Daniel Schultz @ 2016-12-02 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480689949-17957-1-git-send-email-d.schultz@phytec.de>
All i.MX6 SoCs have an OCOTP Controller with 4kbit fuses. The i.MX6SL is
an exception and has only 2kbit fuses.
In the TRM for the i.MX6DQ (IMX6QDRM - Rev 2, 06/2014) the fuses size is
described in chapter 46.1.1 with:
"32-bit word restricted program and read to 4Kbits of eFuse OTP(512x8)."
In the TRM for the i.MX6SL (IMX6SLRM - Rev 2, 06/2015) the fuses size is
described in chapter 34.1.1 with:
"32-bit word restricted program and read to 2 kbit of eFuse OTP(128x8)."
Since the Freescale Linux kernel OCOTP driver works with a fuses size of
2 kbit for the i.MX6SL, it looks like the TRM is wrong and the formula
to calculate the correct fuses size has to be 256x8.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
---
drivers/nvmem/imx-ocotp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index d2f78d3..8482c53 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -72,7 +72,7 @@ static int imx_ocotp_read(void *context, unsigned int offset,
static const struct of_device_id imx_ocotp_dt_ids[] = {
{ .compatible = "fsl,imx6q-ocotp", (void *)128 },
{ .compatible = "fsl,imx6ul-ocotp", (void *)128 },
- { .compatible = "fsl,imx6sl-ocotp", (void *)32 },
+ { .compatible = "fsl,imx6sl-ocotp", (void *)64 },
{ .compatible = "fsl,imx6sx-ocotp", (void *)128 },
{ },
};
--
1.9.1
^ permalink raw reply related
* [PATCH v2] arm64: mm: Fix memmap to be initialized for the entire section
From: James Morse @ 2016-12-02 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202071157.GQ2213@rric.localdomain>
Hi Robert,
On 02/12/16 07:11, Robert Richter wrote:
> On 01.12.16 17:26:55, James Morse wrote:
>> On 01/12/16 16:45, Will Deacon wrote:
>>> Thanks for sending out the new patch. Whilst I'm still a bit worried about
>>> changing pfn_valid like this, I guess we'll just have to fix up any callers
>>> which suffer from this change.
>>
>> Hibernate's core code falls foul of this. This patch causes a panic when copying
>> memory to build the 'image'[0].
>> saveable_page() in kernel/power/snapshot.c broadly assumes that pfn_valid()
>> pages can be accessed.
>>
>> Fortunately the core code exposes pfn_is_nosave() which we can extend to catch
>> 'nomap' pages, but only if they are also marked as PageReserved().
>>
>> Are there any side-effects of marking all the nomap regions with
>> mark_page_reserved()? (it doesn't appear to be the case today).
>
> Reserving the page adds it to the memory management which is what we
> would like to avoid for NOMAP pages. I don't believe we should do
> this. Since NOMAP is to some degree now core functionality I would
> rather implement pfn_is_nomap() that defaults to pfn_is_valid() but
> calls memblock_is_nomap() for arm64 or does something equivalent.
I thought the adjust_managed_page_count() code was just fiddling with some
counters. I will change it to call SetPageReserved() directly which will just
set the bit in struct page's flags. I will post these shortly as the 'fixes' way
of solving the hibernate fallout.
I guess any arch that uses memblock nomap needs core code to take account of it,
but at the moment that is just arm/arm64. If we are adding new pfn_is_ calls, we
could try and clean up pfn_valid() users to use pfn_is_memory(), pfn_is_mapped()
or pfn_has_memmap(). Part of the problem is 'valid' means different things to
different people.
> The question arises what to do with that mem at all. There could be
> mappings by the kernel, e.g. of acpi tables. We can't assume the mem
> regions still come out the same from the BIOS during resume.
Unfortunately we have to assume this. If the firmware reserved regions move
around in memory we can't resume from hibernate. Other OS also require this not
to happen. ([0] 'firmware memory requirements')
Hibernate core code checks the number of pages of kernel memory is the same
before trying to resume. If you just move the allocations around this will panic
during resume as the resume kernel will have surprising holes in its linear map.
x86 recently grew an MD5sum check of the e820 memory map, I intend to do the
same for memblock.
The theory is this would only happen if you change the hardware in some way, and
that otherwise the firmware is entirely deterministic...
> Do we
> need to save the mem? I can't answer that as I don't know much about
> hibernation yet.
Hibernate only save/restores the linear map and CPU state. We expect firmware to
put equivalent data in the same places for its nomap regions. If the region
belongs to a device, its up to the device driver to tidy up. (It has
freeze/thaw/resume callbacks to do this).
Thanks,
James
[0]
https://msdn.microsoft.com/en-gb/windows/hardware/commercialize/manufacture/desktop/uefi-requirements-boot-time-runtime-hibernation-state--s4
^ permalink raw reply
* [PATCH 0/2] Hibernate fixes for 'Fix memmap to be initialized for the entire section'
From: James Morse @ 2016-12-02 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480530091-1092-1-git-send-email-rrichter@cavium.com>
Patch "arm64: mm: Fix memmap to be initialized for the entire section"
changes pfn_valid() in a way that breaks hibernate. These patches fix
hibernate, and provided struct page's are allocated for nomap pages,
can be applied before [0].
Hibernate core code belives 'valid' to mean "I can access this". It
uses pfn_valid() to test the page if the page is 'valid'.
pfn_valid() needs to be changed so that all struct pages in a numa
node have the same node-id. Currently 'nomap' pages are skipped, and
retain their pre-numa node-ids, which leads to a later BUG_ON().
These patches make hibernate's savable_page() take its escape route
via 'if (PageReserved(page) && pfn_is_nosave(pfn))'.
[0] https://lkml.org/lkml/2016/11/30/566
James Morse (2):
arm64: mm: Mark nomap regions with the PG_reserved flag
arm64: hibernate: report nomap regions as being pfn_nosave
arch/arm64/kernel/hibernate.c | 6 +++++-
arch/arm64/mm/init.c | 14 ++++++++++++++
2 files changed, 19 insertions(+), 1 deletion(-)
--
2.10.1
^ permalink raw reply
* [PATCH 1/2] arm64: mm: Mark nomap regions with the PG_reserved flag
From: James Morse @ 2016-12-02 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202144909.18405-1-james.morse@arm.com>
linux/page-flags.h has a flag for describing special pages:
> PG_reserved is set for special pages, which can never be swapped out.
> Some of them might not even exist (eg empty_bad_page)...
memblock nomap pages fall in the 'might not even exist' category,
set this bit on all the struct pages in the nomap regions.
This gives pfn walkers the necessary hint that the page might not
be accessible, allowing pfn_valid()s meaning to change slightly.
Signed-off-by: James Morse <james.morse@arm.com>
---
arch/arm64/mm/init.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 166911f4a2e6..5da9ff7d20f5 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -31,6 +31,7 @@
#include <linux/memblock.h>
#include <linux/sort.h>
#include <linux/of_fdt.h>
+#include <linux/page-flags.h>
#include <linux/dma-mapping.h>
#include <linux/dma-contiguous.h>
#include <linux/efi.h>
@@ -401,6 +402,8 @@ static void __init free_unused_memmap(void)
*/
void __init mem_init(void)
{
+ struct memblock_region *region;
+
if (swiotlb_force || max_pfn > (arm64_dma_phys_limit >> PAGE_SHIFT))
swiotlb_init(1);
@@ -479,6 +482,17 @@ void __init mem_init(void)
*/
sysctl_overcommit_memory = OVERCOMMIT_ALWAYS;
}
+
+ /* Mark struct pages for the memblock:nomap regions as reserved */
+ for_each_memblock(memory, region) {
+ u64 pfn;
+ u64 start_pfn = memblock_region_memory_base_pfn(region);
+ u64 end_pfn = memblock_region_memory_end_pfn(region);
+
+ if (memblock_is_nomap(region))
+ for (pfn = start_pfn; pfn < end_pfn; pfn++)
+ SetPageReserved(pfn_to_page(pfn));
+ }
}
void free_initmem(void)
--
2.10.1
^ permalink raw reply related
* [PATCH 2/2] arm64: hibernate: report nomap regions as being pfn_nosave
From: James Morse @ 2016-12-02 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202144909.18405-1-james.morse@arm.com>
pfn_valid() needs to be changed so that all struct pages in a numa
node have the same node-id. Currently 'nomap' pages are skipped, and
retain their pre-numa node-ids, which leads to a later BUG_ON().
Once this change happens, hibernate's code code will try and
save/restore the nomap pages.
Add the memblock nomap regions to the ranges reported as being
'pfn_nosave' to the hibernate core code. This only works if all
pages in the nomap region are also marked with PG_reserved.
Signed-off-by: James Morse <james.morse@arm.com>
---
arch/arm64/kernel/hibernate.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index d55a7b09959b..9e901658a123 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -17,6 +17,7 @@
#define pr_fmt(x) "hibernate: " x
#include <linux/cpu.h>
#include <linux/kvm_host.h>
+#include <linux/memblock.h>
#include <linux/mm.h>
#include <linux/pm.h>
#include <linux/sched.h>
@@ -105,7 +106,10 @@ int pfn_is_nosave(unsigned long pfn)
unsigned long nosave_begin_pfn = virt_to_pfn(&__nosave_begin);
unsigned long nosave_end_pfn = virt_to_pfn(&__nosave_end - 1);
- return (pfn >= nosave_begin_pfn) && (pfn <= nosave_end_pfn);
+ if ((pfn >= nosave_begin_pfn) && (pfn <= nosave_end_pfn))
+ return 1;
+
+ return !memblock_is_map_memory(pfn << PAGE_SHIFT);
}
void notrace save_processor_state(void)
--
2.10.1
^ permalink raw reply related
* [PATCH v4] ARM: davinci: da8xx: Fix sleeping function called from invalid context
From: Alexandre Bailon @ 2016-12-02 14:53 UTC (permalink / raw)
To: linux-arm-kernel
Everytime the usb20 phy is enabled, there is a
"sleeping function called from invalid context" BUG.
clk_enable() from arch/arm/mach-davinci/clock.c uses spin_lock_irqsave()
before to invoke the callback usb20_phy_clk_enable().
usb20_phy_clk_enable() uses clk_get() and clk_enable_prepapre()
which may sleep.
Move clk_get() to da8xx_register_usb20_phy_clk() and
replace clk_prepare_enable() by clk_enable().
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
arch/arm/mach-davinci/usb-da8xx.c | 28 +++++++++++++++-------------
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-davinci/usb-da8xx.c b/arch/arm/mach-davinci/usb-da8xx.c
index b010e5f..704f506 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -22,6 +22,8 @@
#define DA8XX_USB0_BASE 0x01e00000
#define DA8XX_USB1_BASE 0x01e25000
+static struct clk *usb20_clk;
+
static struct platform_device da8xx_usb_phy = {
.name = "da8xx-usb-phy",
.id = -1,
@@ -158,21 +160,14 @@ int __init da8xx_register_usb_refclkin(int rate)
static void usb20_phy_clk_enable(struct clk *clk)
{
- struct clk *usb20_clk;
int err;
u32 val;
u32 timeout = 500000; /* 500 msec */
val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
- usb20_clk = clk_get(&da8xx_usb20_dev.dev, "usb20");
- if (IS_ERR(usb20_clk)) {
- pr_err("could not get usb20 clk: %ld\n", PTR_ERR(usb20_clk));
- return;
- }
-
/* The USB 2.O PLL requires that the USB 2.O PSC is enabled as well. */
- err = clk_prepare_enable(usb20_clk);
+ err = clk_enable(usb20_clk);
if (err) {
pr_err("failed to enable usb20 clk: %d\n", err);
clk_put(usb20_clk);
@@ -197,8 +192,7 @@ static void usb20_phy_clk_enable(struct clk *clk)
pr_err("Timeout waiting for USB 2.0 PHY clock good\n");
done:
- clk_disable_unprepare(usb20_clk);
- clk_put(usb20_clk);
+ clk_disable(usb20_clk);
}
static void usb20_phy_clk_disable(struct clk *clk)
@@ -285,11 +279,19 @@ static struct clk_lookup usb20_phy_clk_lookup =
int __init da8xx_register_usb20_phy_clk(bool use_usb_refclkin)
{
struct clk *parent;
- int ret = 0;
+ int ret;
+
+ usb20_clk = clk_get(&da8xx_usb20_dev.dev, "usb20");
+ ret = PTR_ERR_OR_ZERO(usb20_clk);
+ if (ret)
+ return ret;
parent = clk_get(NULL, use_usb_refclkin ? "usb_refclkin" : "pll0_aux");
- if (IS_ERR(parent))
- return PTR_ERR(parent);
+ ret = PTR_ERR_OR_ZERO(parent);
+ if (ret) {
+ clk_put(usb20_clk);
+ return ret;
+ }
usb20_phy_clk.parent = parent;
ret = clk_register(&usb20_phy_clk);
--
2.7.3
^ permalink raw reply related
* [RESEND PATCH V6 0/6] Add support for privileged mappings
From: Sricharan R @ 2016-12-02 14:55 UTC (permalink / raw)
To: linux-arm-kernel
This series is a resend of the V5 that Mitch sent sometime back [2]
All the patches are the same and i have just rebased. Not sure why this
finally did not make it last time. The last patch in the previous
series does not apply now [3], so just redid that. Also Copied the tags
that he had from last time as well.
The following patch to the ARM SMMU driver:
commit d346180e70b91b3d5a1ae7e5603e65593d4622bc
Author: Robin Murphy <robin.murphy@arm.com>
Date: Tue Jan 26 18:06:34 2016 +0000
iommu/arm-smmu: Treat all device transactions as unprivileged
started forcing all SMMU transactions to come through as "unprivileged".
The rationale given was that:
(1) There is no way in the IOMMU API to even request privileged
mappings.
(2) It's difficult to implement a DMA mapper that correctly models the
ARM VMSAv8 behavior of unprivileged-writeable =>
privileged-execute-never.
This series rectifies (1) by introducing an IOMMU API for privileged
mappings and implements it in io-pgtable-arm.
This series rectifies (2) by introducing a new dma attribute
(DMA_ATTR_PRIVILEGED) for users of the DMA API that need privileged
mappings which are inaccessible to lesser-privileged execution levels, and
implements it in the arm64 IOMMU DMA mapper. The one known user (pl330.c)
is converted over to the new attribute.
Jordan and Jeremy can provide more info on the use case if needed, but the
high level is that it's a security feature to prevent attacks such as [1].
[1] https://github.com/robclark/kilroy
[2] https://lkml.org/lkml/2016/7/27/590
[3] https://patchwork.kernel.org/patch/9250493/
Changelog:
v5..v6
- Rebased all the patches and redid 6/6 as it does not apply in
this code base.
v4..v5
- Simplified patch 4/6 (suggested by Robin Murphy).
v3..v4
- Rebased and reworked on linux next due to the dma attrs rework going
on over there. Patches changed: 3/6, 4/6, and 5/6.
v2..v3
- Incorporated feedback from Robin:
* Various comments and re-wordings.
* Use existing bit definitions for IOMMU_PRIV implementation
in io-pgtable-arm.
* Renamed and redocumented dma_direction_to_prot.
* Don't worry about executability in new DMA attr.
v1..v2
- Added a new DMA attribute to make executable privileged mappings
work, and use that in the pl330 driver (suggested by Will).
Jeremy Gebben (1):
iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag
Mitchel Humpherys (4):
iommu: add IOMMU_PRIV attribute
common: DMA-mapping: add DMA_ATTR_PRIVILEGED attribute
arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED
dmaengine: pl330: Make sure microcode is privileged
Sricharan R (1):
iommu/arm-smmu: Set privileged attribute to 'default' instead of
'unprivileged'
Documentation/DMA-attributes.txt | 10 ++++++++++
arch/arm64/mm/dma-mapping.c | 6 +++---
drivers/dma/pl330.c | 6 ++++--
drivers/iommu/arm-smmu.c | 2 +-
drivers/iommu/dma-iommu.c | 10 ++++++++--
drivers/iommu/io-pgtable-arm.c | 5 ++++-
include/linux/dma-iommu.h | 3 ++-
include/linux/dma-mapping.h | 7 +++++++
include/linux/iommu.h | 1 +
9 files changed, 40 insertions(+), 10 deletions(-)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [RESEND PATCH V6 1/6] iommu: add IOMMU_PRIV attribute
From: Sricharan R @ 2016-12-02 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480690509-13490-1-git-send-email-sricharan@codeaurora.org>
From: Mitchel Humpherys <mitchelh@codeaurora.org>
Add the IOMMU_PRIV attribute, which is used to indicate privileged
mappings.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
---
[V6] No change
include/linux/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index f2960e4..bf22131 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -31,6 +31,7 @@
#define IOMMU_CACHE (1 << 2) /* DMA cache coherency */
#define IOMMU_NOEXEC (1 << 3)
#define IOMMU_MMIO (1 << 4) /* e.g. things like MSI doorbells */
+#define IOMMU_PRIV (1 << 5) /* privileged */
struct iommu_ops;
struct iommu_group;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [RESEND PATCH V6 2/6] iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag
From: Sricharan R @ 2016-12-02 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480690509-13490-1-git-send-email-sricharan@codeaurora.org>
From: Jeremy Gebben <jgebben@codeaurora.org>
Allow the creation of privileged mode mappings, for stage 1 only.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
---
[V6] No change
drivers/iommu/io-pgtable-arm.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index f5c90e1..69ba83a 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -350,11 +350,14 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
if (data->iop.fmt == ARM_64_LPAE_S1 ||
data->iop.fmt == ARM_32_LPAE_S1) {
- pte = ARM_LPAE_PTE_AP_UNPRIV | ARM_LPAE_PTE_nG;
+ pte = ARM_LPAE_PTE_nG;
if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
pte |= ARM_LPAE_PTE_AP_RDONLY;
+ if (!(prot & IOMMU_PRIV))
+ pte |= ARM_LPAE_PTE_AP_UNPRIV;
+
if (prot & IOMMU_MMIO)
pte |= (ARM_LPAE_MAIR_ATTR_IDX_DEV
<< ARM_LPAE_PTE_ATTRINDX_SHIFT);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [RESEND PATCH V6 3/6] common: DMA-mapping: add DMA_ATTR_PRIVILEGED attribute
From: Sricharan R @ 2016-12-02 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480690509-13490-1-git-send-email-sricharan@codeaurora.org>
From: Mitchel Humpherys <mitchelh@codeaurora.org>
This patch adds the DMA_ATTR_PRIVILEGED attribute to the DMA-mapping
subsystem.
Some advanced peripherals such as remote processors and GPUs perform
accesses to DMA buffers in both privileged "supervisor" and unprivileged
"user" modes. This attribute is used to indicate to the DMA-mapping
subsystem that the buffer is fully accessible at the elevated privilege
level (and ideally inaccessible or at least read-only at the
lesser-privileged levels).
Cc: linux-doc at vger.kernel.org
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
---
[V6] No change
Documentation/DMA-attributes.txt | 10 ++++++++++
include/linux/dma-mapping.h | 7 +++++++
2 files changed, 17 insertions(+)
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index 98bf7ac..44c6bc4 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -143,3 +143,13 @@ So, this provides a way for drivers to avoid those error messages on calls
where allocation failures are not a problem, and shouldn't bother the logs.
NOTE: At the moment DMA_ATTR_NO_WARN is only implemented on PowerPC.
+
+DMA_ATTR_PRIVILEGED
+------------------------------
+
+Some advanced peripherals such as remote processors and GPUs perform
+accesses to DMA buffers in both privileged "supervisor" and unprivileged
+"user" modes. This attribute is used to indicate to the DMA-mapping
+subsystem that the buffer is fully accessible at the elevated privilege
+level (and ideally inaccessible or at least read-only at the
+lesser-privileged levels).
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 6f3e6ca..ee31ea1 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -63,6 +63,13 @@
#define DMA_ATTR_NO_WARN (1UL << 8)
/*
+ * DMA_ATTR_PRIVILEGED: used to indicate that the buffer is fully
+ * accessible at an elevated privilege level (and ideally inaccessible or
+ * at least read-only@lesser-privileged levels).
+ */
+#define DMA_ATTR_PRIVILEGED (1UL << 8)
+
+/*
* A dma_addr_t can hold any valid DMA or bus address for the platform.
* It can be given to a device to use as a DMA source or target. A CPU cannot
* reference a dma_addr_t directly because there may be translation between
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [RESEND PATCH V6 4/6] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED
From: Sricharan R @ 2016-12-02 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480690509-13490-1-git-send-email-sricharan@codeaurora.org>
From: Mitchel Humpherys <mitchelh@codeaurora.org>
The newly added DMA_ATTR_PRIVILEGED is useful for creating mappings that
are only accessible to privileged DMA engines. Implement it in
dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
---
[V6] No change
arch/arm64/mm/dma-mapping.c | 6 +++---
drivers/iommu/dma-iommu.c | 10 ++++++++--
include/linux/dma-iommu.h | 3 ++-
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 401f79a..ae76ead 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -557,7 +557,7 @@ static void *__iommu_alloc_attrs(struct device *dev, size_t size,
unsigned long attrs)
{
bool coherent = is_device_dma_coherent(dev);
- int ioprot = dma_direction_to_prot(DMA_BIDIRECTIONAL, coherent);
+ int ioprot = dma_info_to_prot(DMA_BIDIRECTIONAL, coherent, attrs);
size_t iosize = size;
void *addr;
@@ -711,7 +711,7 @@ static dma_addr_t __iommu_map_page(struct device *dev, struct page *page,
unsigned long attrs)
{
bool coherent = is_device_dma_coherent(dev);
- int prot = dma_direction_to_prot(dir, coherent);
+ int prot = dma_info_to_prot(dir, coherent, attrs);
dma_addr_t dev_addr = iommu_dma_map_page(dev, page, offset, size, prot);
if (!iommu_dma_mapping_error(dev, dev_addr) &&
@@ -769,7 +769,7 @@ static int __iommu_map_sg_attrs(struct device *dev, struct scatterlist *sgl,
__iommu_sync_sg_for_device(dev, sgl, nelems, dir);
return iommu_dma_map_sg(dev, sgl, nelems,
- dma_direction_to_prot(dir, coherent));
+ dma_info_to_prot(dir, coherent, attrs));
}
static void __iommu_unmap_sg_attrs(struct device *dev,
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index d2a7a46..756d5e0 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -182,16 +182,22 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
EXPORT_SYMBOL(iommu_dma_init_domain);
/**
- * dma_direction_to_prot - Translate DMA API directions to IOMMU API page flags
+ * dma_info_to_prot - Translate DMA API directions and attributes to IOMMU API
+ * page flags.
* @dir: Direction of DMA transfer
* @coherent: Is the DMA master cache-coherent?
+ * @attrs: DMA attributes for the mapping
*
* Return: corresponding IOMMU API page protection flags
*/
-int dma_direction_to_prot(enum dma_data_direction dir, bool coherent)
+int dma_info_to_prot(enum dma_data_direction dir, bool coherent,
+ unsigned long attrs)
{
int prot = coherent ? IOMMU_CACHE : 0;
+ if (attrs & DMA_ATTR_PRIVILEGED)
+ prot |= IOMMU_PRIV;
+
switch (dir) {
case DMA_BIDIRECTIONAL:
return prot | IOMMU_READ | IOMMU_WRITE;
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 32c5890..a203181 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -34,7 +34,8 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
u64 size, struct device *dev);
/* General helpers for DMA-API <-> IOMMU-API interaction */
-int dma_direction_to_prot(enum dma_data_direction dir, bool coherent);
+int dma_info_to_prot(enum dma_data_direction dir, bool coherent,
+ unsigned long attrs);
/*
* These implement the bulk of the relevant DMA mapping callbacks, but require
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [RESEND PATCH V6 5/6] dmaengine: pl330: Make sure microcode is privileged
From: Sricharan R @ 2016-12-02 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480690509-13490-1-git-send-email-sricharan@codeaurora.org>
From: Mitchel Humpherys <mitchelh@codeaurora.org>
The PL330 performs privileged instruction fetches. This can result in
SMMU permission faults on SMMUs that implement the ARMv8 VMSA, which
specifies that mappings that are writeable at one execution level shall
not be executable at any higher-privileged level. Fix this by using the
DMA_ATTR_PRIVILEGED attribute, which will ensure that the microcode
IOMMU mapping is only accessible to the privileged level.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
---
[V6] No change
drivers/dma/pl330.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 030fe05..1a8bac2 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1854,14 +1854,16 @@ static int dmac_alloc_resources(struct pl330_dmac *pl330)
{
int chans = pl330->pcfg.num_chan;
int ret;
+ unsigned long dma_attrs = DMA_ATTR_PRIVILEGED;
/*
* Alloc MicroCode buffer for 'chans' Channel threads.
* A channel's buffer offset is (Channel_Id * MCODE_BUFF_PERCHAN)
*/
- pl330->mcode_cpu = dma_alloc_coherent(pl330->ddma.dev,
+ pl330->mcode_cpu = dma_alloc_attrs(pl330->ddma.dev,
chans * pl330->mcbufsz,
- &pl330->mcode_bus, GFP_KERNEL);
+ &pl330->mcode_bus, GFP_KERNEL,
+ dma_attrs);
if (!pl330->mcode_cpu) {
dev_err(pl330->ddma.dev, "%s:%d Can't allocate memory!\n",
__func__, __LINE__);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox