* [PATCH v6 3/5] ARM: davinci: da8xx: Add USB PHY platform declaration
From: David Lechner @ 2016-10-26 3:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477451211-31979-1-git-send-email-david@lechnology.com>
There is now a proper phy driver for the DA8xx SoC USB PHY. This adds the
platform device declarations needed to use it.
Signed-off-by: David Lechner <david@lechnology.com>
---
da8xx-usb-phy device id is changed to -1 since there is only one da8xx-usb-phy
device.
arch/arm/mach-davinci/board-da830-evm.c | 28 +++++-----------------------
arch/arm/mach-davinci/board-omapl138-hawk.c | 5 +++++
arch/arm/mach-davinci/include/mach/da8xx.h | 1 +
arch/arm/mach-davinci/usb-da8xx.c | 11 +++++++++++
4 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 3051cb6..c62766e 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -26,7 +26,6 @@
#include <linux/platform_data/mtd-davinci.h>
#include <linux/platform_data/mtd-davinci-aemif.h>
#include <linux/platform_data/spi-davinci.h>
-#include <linux/platform_data/usb-davinci.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -106,30 +105,8 @@ static irqreturn_t da830_evm_usb_ocic_irq(int irq, void *dev_id)
static __init void da830_evm_usb_init(void)
{
- u32 cfgchip2;
int ret;
- /*
- * Set up USB clock/mode in the CFGCHIP2 register.
- * FYI: CFGCHIP2 is 0x0000ef00 initially.
- */
- cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
-
- /*
- * We have to override VBUS/ID signals when MUSB is configured into the
- * host-only mode -- ID pin will float if no cable is connected, so the
- * controller won't be able to drive VBUS thinking that it's a B-device.
- * Otherwise, we want to use the OTG mode and enable VBUS comparators.
- */
- cfgchip2 &= ~CFGCHIP2_OTGMODE;
-#ifdef CONFIG_USB_MUSB_HOST
- cfgchip2 |= CFGCHIP2_FORCE_HOST;
-#else
- cfgchip2 |= CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
-#endif
-
- __raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
-
/* USB_REFCLKIN is not used. */
ret = da8xx_register_usb20_phy_clk(false);
if (ret)
@@ -141,6 +118,11 @@ static __init void da830_evm_usb_init(void)
pr_warn("%s: USB 1.1 PHY CLK registration failed: %d\n",
__func__, ret);
+ ret = da8xx_register_usb_phy();
+ if (ret)
+ pr_warn("%s: USB PHY registration failed: %d\n",
+ __func__, ret);
+
ret = davinci_cfg_reg(DA830_USB0_DRVVBUS);
if (ret)
pr_warn("%s: USB 2.0 PinMux setup failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 8691a25..c5cb8d9 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -260,6 +260,11 @@ static __init void omapl138_hawk_usb_init(void)
pr_warn("%s: USB 1.1 PHY CLK registration failed: %d\n",
__func__, ret);
+ ret = da8xx_register_usb_phy();
+ if (ret)
+ pr_warn("%s: USB PHY registration failed: %d\n",
+ __func__, ret);
+
ret = gpio_request_one(DA850_USB1_VBUS_PIN,
GPIOF_DIR_OUT, "USB1 VBUS");
if (ret < 0) {
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index c32444b..38d932e 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -92,6 +92,7 @@ int da8xx_register_watchdog(void);
int da8xx_register_usb_refclkin(int rate);
int da8xx_register_usb20_phy_clk(bool use_usb_refclkin);
int da8xx_register_usb11_phy_clk(bool use_usb_refclkin);
+int da8xx_register_usb_phy(void);
int da8xx_register_usb20(unsigned mA, unsigned potpgt);
int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
int da8xx_register_emac(void);
diff --git a/arch/arm/mach-davinci/usb-da8xx.c b/arch/arm/mach-davinci/usb-da8xx.c
index 71a6d85..9c30bff 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -7,6 +7,7 @@
#include <linux/platform_data/usb-davinci.h>
#include <linux/platform_device.h>
#include <linux/mfd/da8xx-cfgchip.h>
+#include <linux/phy/phy.h>
#include <linux/usb/musb.h>
#include <mach/clock.h>
@@ -243,6 +244,16 @@ int __init da8xx_register_usb11_phy_clk(bool use_usb_refclkin)
return ret;
}
+static struct platform_device da8xx_usb_phy = {
+ .name = "da8xx-usb-phy",
+ .id = -1,
+};
+
+int __init da8xx_register_usb_phy(void)
+{
+ return platform_device_register(&da8xx_usb_phy);
+}
+
#if IS_ENABLED(CONFIG_USB_MUSB_HDRC)
static struct musb_hdrc_config musb_config = {
--
2.7.4
^ permalink raw reply related
* [PATCH v6 4/5] ARM: DTS: da850: Add cfgchip syscon node
From: David Lechner @ 2016-10-26 3:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477451211-31979-1-git-send-email-david@lechnology.com>
Add a syscon node for the SoC CFGCHIPn registers. This is needed for
the new usb phy driver.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/da850.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b9..6bbf20d 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -188,6 +188,10 @@
};
};
+ cfgchip: cfgchip at 1417c {
+ compatible = "ti,da830-cfgchip", "syscon";
+ reg = <0x1417c 0x14>;
+ };
edma0: edma at 0 {
compatible = "ti,edma3-tpcc";
/* eDMA3 CC0: 0x01c0 0000 - 0x01c0 7fff */
--
2.7.4
^ permalink raw reply related
* [PATCH v6 5/5] ARM: DTS: da850: Add usb phy node
From: David Lechner @ 2016-10-26 3:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477451211-31979-1-git-send-email-david@lechnology.com>
Add a node for the new usb phy driver.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/da850.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 6bbf20d..33fcdce 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -376,6 +376,11 @@
>;
status = "disabled";
};
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <1>;
+ status = "disabled";
+ };
gpio: gpio at 226000 {
compatible = "ti,dm6441-gpio";
gpio-controller;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc
From: Leizhen (ThunderTown) @ 2016-10-26 3:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025132338.GA31239@dhcp22.suse.cz>
On 2016/10/25 21:23, Michal Hocko wrote:
> On Tue 25-10-16 10:59:17, Zhen Lei wrote:
>> If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
>> actually exist. The percpu variable areas and numa control blocks of that
>> memoryless numa nodes need to be allocated from the nearest available
>> node to improve performance.
>>
>> Although memblock_alloc_try_nid and memblock_virt_alloc_try_nid try the
>> specified nid at the first time, but if that allocation failed it will
>> directly drop to use NUMA_NO_NODE. This mean any nodes maybe possible at
>> the second time.
>>
>> To compatible the above old scene, I use a marco node_distance_ready to
>> control it. By default, the marco node_distance_ready is not defined in
>> any platforms, the above mentioned functions will work as normal as
>> before. Otherwise, they will try the nearest node first.
>
> I am sorry but it is absolutely unclear to me _what_ is the motivation
> of the patch. Is this a performance optimization, correctness issue or
> something else? Could you please restate what is the problem, why do you
> think it has to be fixed at memblock layer and describe what the actual
> fix is please?
This is a performance optimization. The problem is if some memoryless numa nodes are
actually exist, for example: there are total 4 nodes, 0,1,2,3, node 1 has no memory,
and the node distances is as below:
---------board-------
| |
| |
socket0 socket1
/ \ / \
/ \ / \
node0 node1 node2 node3
distance[1][0] is nearer than distance[1][2] and distance[1][3]. CPUs on node1 access
the memory of node0 is faster than node2 or node3.
Linux defines a lot of percpu variables, each cpu has a copy of it and most of the time
only to access their own percpu area. In this example, we hope the percpu area of CPUs
on node1 allocated from node0. But without these patches, it's not sure that.
If each node has their own memory, we can directly use below functions to allocate memory
from its local node:
1. memblock_alloc_nid
2. memblock_alloc_try_nid
3. memblock_virt_alloc_try_nid_nopanic
4. memblock_virt_alloc_try_nid
So, these patches is only used for numa memoryless scenario.
Another use case is the control block "extern pg_data_t *node_data[]",
Here is an example of x86 numa in arch/x86/mm/numa.c:
static void __init alloc_node_data(int nid)
{
... ...
/*
* Allocate node data. Try node-local memory and then any node. //==>But the nearest node is the best
* Never allocate in DMA zone.
*/
nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
if (!nd_pa) {
nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
MEMBLOCK_ALLOC_ACCESSIBLE);
if (!nd_pa) {
pr_err("Cannot find %zu bytes in node %d\n",
nd_size, nid);
return;
}
}
nd = __va(nd_pa);
... ...
node_data[nid] = nd;
>
>>From a quick glance you are trying to bend over the memblock API for
> something that should be handled on a different layer.
>
>>
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>> ---
>> mm/memblock.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++---------
>> 1 file changed, 65 insertions(+), 11 deletions(-)
>>
>> diff --git a/mm/memblock.c b/mm/memblock.c
>> index 7608bc3..556bbd2 100644
>> --- a/mm/memblock.c
>> +++ b/mm/memblock.c
>> @@ -1213,9 +1213,71 @@ phys_addr_t __init memblock_alloc(phys_addr_t size, phys_addr_t align)
>> return memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ACCESSIBLE);
>> }
>>
>> +#ifndef node_distance_ready
>> +#define node_distance_ready() 0
>> +#endif
>> +
>> +static phys_addr_t __init memblock_alloc_near_nid(phys_addr_t size,
>> + phys_addr_t align, phys_addr_t start,
>> + phys_addr_t end, int nid, ulong flags,
>> + int alloc_func_type)
>> +{
>> + int nnid, round = 0;
>> + u64 pa;
>> + DECLARE_BITMAP(nodes_map, MAX_NUMNODES);
>> +
>> + bitmap_zero(nodes_map, MAX_NUMNODES);
>> +
>> +again:
>> + /*
>> + * There are total 4 cases:
>> + * <nid == NUMA_NO_NODE>
>> + * 1)2) node_distance_ready || !node_distance_ready
>> + * Round 1, nnid = nid = NUMA_NO_NODE;
>> + * <nid != NUMA_NO_NODE>
>> + * 3) !node_distance_ready
>> + * Round 1, nnid = nid;
>> + * ::Round 2, currently only applicable for alloc_func_type = <0>
>> + * Round 2, nnid = NUMA_NO_NODE;
>> + * 4) node_distance_ready
>> + * Round 1, LOCAL_DISTANCE, nnid = nid;
>> + * Round ?, nnid = nearest nid;
>> + */
>> + if (!node_distance_ready() || (nid == NUMA_NO_NODE)) {
>> + nnid = (++round == 1) ? nid : NUMA_NO_NODE;
>> + } else {
>> + int i, distance = INT_MAX;
>> +
>> + for_each_clear_bit(i, nodes_map, MAX_NUMNODES)
>> + if (node_distance(nid, i) < distance) {
>> + nnid = i;
>> + distance = node_distance(nid, i);
>> + }
>> + }
>> +
>> + switch (alloc_func_type) {
>> + case 0:
>> + pa = memblock_find_in_range_node(size, align, start, end, nnid, flags);
>> + break;
>> +
>> + case 1:
>> + default:
>> + pa = memblock_alloc_nid(size, align, nnid);
>> + if (!node_distance_ready())
>> + return pa;
>> + }
>> +
>> + if (!pa && (nnid != NUMA_NO_NODE)) {
>> + bitmap_set(nodes_map, nnid, 1);
>> + goto again;
>> + }
>> +
>> + return pa;
>> +}
>> +
>> phys_addr_t __init memblock_alloc_try_nid(phys_addr_t size, phys_addr_t align, int nid)
>> {
>> - phys_addr_t res = memblock_alloc_nid(size, align, nid);
>> + phys_addr_t res = memblock_alloc_near_nid(size, align, 0, 0, nid, 0, 1);
>>
>> if (res)
>> return res;
>> @@ -1276,19 +1338,11 @@ static void * __init memblock_virt_alloc_internal(
>> max_addr = memblock.current_limit;
>>
>> again:
>> - alloc = memblock_find_in_range_node(size, align, min_addr, max_addr,
>> - nid, flags);
>> + alloc = memblock_alloc_near_nid(size, align, min_addr, max_addr,
>> + nid, flags, 0);
>> if (alloc)
>> goto done;
>>
>> - if (nid != NUMA_NO_NODE) {
>> - alloc = memblock_find_in_range_node(size, align, min_addr,
>> - max_addr, NUMA_NO_NODE,
>> - flags);
>> - if (alloc)
>> - goto done;
>> - }
>> -
>> if (min_addr) {
>> min_addr = 0;
>> goto again;
>> --
>> 2.5.0
>>
>
^ permalink raw reply
* [PATCH V2 0/6] ARM64: Uprobe support added
From: Pratyush Anand @ 2016-10-26 3:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1474960629.git.panand@redhat.com>
Hi Catalin,
Please let me know if everything else other than is_trap_insn() looks
fine to you. May be I can work well in time. It would be great if we
can make it into v4.9.
~Pratyush
On Tue, Sep 27, 2016 at 1:17 PM, Pratyush Anand <panand@redhat.com> wrote:
> Changes since v1:
> * Exposed sync_icache_aliases() and used that in stead of flush_uprobe_xol_access()
> * Assigned 0x0005 to BRK64_ESR_UPROBES in stead of 0x0008
> * moved uprobe_opcode_t from probes.h to uprobes.h
> * Assigned 4 to TIF_UPROBE instead of 5
> * Assigned AARCH64_INSN_SIZE to UPROBE_SWBP_INSN_SIZE instead of hard code 4.
> * Removed saved_fault_code from struct arch_uprobe_task
> * Removed preempt_dis(en)able() from arch_uprobe_copy_ixol()
> * Removed case INSN_GOOD from arch_uprobe_analyze_insn()
> * Now we do check that probe point is not for a 32 bit task.
> * Return a false positive from is_tarp_insn()
> * Changes for rebase conflict resolution
>
> V1 was here: https://lkml.org/lkml/2016/8/2/29
> Patches have been rebased on next-20160927, so that there would be no
> conflicts with other arm64/for-next/core patches.
>
> Patches have been tested for following:
> 1. Step-able instructions, like sub, ldr, add etc.
> 2. Simulation-able like ret, cbnz, cbz etc.
> 3. uretprobe
> 4. Reject-able instructions like sev, wfe etc.
> 5. trapped and abort xol path
> 6. probe at unaligned user address.
> 7. longjump test cases
>
> aarch32 task probing is not yet supported.
>
> Pratyush Anand (6):
> arm64: kprobe: protect/rename few definitions to be reused by uprobe
> arm64: kgdb_step_brk_fn: ignore other's exception
> arm64: Handle TRAP_TRACE for user mode as well
> arm64: Handle TRAP_BRKPT for user mode as well
> arm64: introduce mm context flag to keep 32 bit task information
> arm64: Add uprobe support
>
> arch/arm64/Kconfig | 3 +
> arch/arm64/include/asm/cacheflush.h | 1 +
> arch/arm64/include/asm/debug-monitors.h | 3 +
> arch/arm64/include/asm/elf.h | 12 +-
> arch/arm64/include/asm/mmu.h | 1 +
> arch/arm64/include/asm/probes.h | 19 +--
> arch/arm64/include/asm/ptrace.h | 8 ++
> arch/arm64/include/asm/thread_info.h | 5 +-
> arch/arm64/include/asm/uprobes.h | 36 ++++++
> arch/arm64/kernel/debug-monitors.c | 40 +++---
> arch/arm64/kernel/kgdb.c | 3 +
> arch/arm64/kernel/probes/Makefile | 2 +
> arch/arm64/kernel/probes/decode-insn.c | 32 ++---
> arch/arm64/kernel/probes/decode-insn.h | 8 +-
> arch/arm64/kernel/probes/kprobes.c | 36 +++---
> arch/arm64/kernel/probes/uprobes.c | 221 ++++++++++++++++++++++++++++++++
> arch/arm64/kernel/signal.c | 3 +
> arch/arm64/mm/flush.c | 2 +-
> 18 files changed, 371 insertions(+), 64 deletions(-)
> create mode 100644 arch/arm64/include/asm/uprobes.h
> create mode 100644 arch/arm64/kernel/probes/uprobes.c
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 4/4] iommu/arm-smmu: Add the device_link between masters and smmu
From: Sricharan @ 2016-10-26 4:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d0489bcc-573f-de7a-fb6e-59fee521dac8@samsung.com>
Hi Marek,
>
>On 2016-10-21 19:14, Sricharan R wrote:
>> The device link between master and its smmu is added so that
>> the smmu gets runtime enabled/disabled when the master needs it.
>> This is done from add_device callback which gets called once
>> when the master is added to the smmu group.
>>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> drivers/iommu/arm-smmu.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 578cdc2..71ce4b6 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -1470,6 +1470,15 @@ static int arm_smmu_add_device(struct device *dev)
>> goto out_free;
>> pm_runtime_put_sync(smmu->dev);
>>
>> + /*
>> + * Establish the link between smmu and master, so that the
>> + * smmu gets runtime enabled/disabled as per the master's
>> + * needs.
>> + */
>> +
>> + device_link_add(dev, smmu->dev, DEVICE_LINK_AVAILABLE,
>> + DEVICE_LINK_PM_RUNTIME);
>
>Please update to the latest version of Rafael's patches. In V5 the
>initial link
>state is not needed anymore and there was an important fix for creating
>links
>during master's driver probing, what happens after applying your IOMMU
>deferred
>probe patchset.
Sure i will update to V5. I see that i am on V4.
Regards,
Sricharan
^ permalink raw reply
* [PATCH v2] arm64: Add support for additional relocations in the kexec purgatory code
From: Pratyush Anand @ 2016-10-26 4:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476960211-25594-1-git-send-email-catalin.marinas@arm.com>
On Thursday 20 October 2016 04:13 PM, Catalin Marinas wrote:
> When compiling the kexec-tools with gcc6, the following additional
> reolcations are generated in the purgatory.ro file:
>
> R_AARCH64_ADR_PREL_PG_HI21
> R_AARCH64_ADD_ABS_LO12_NC
> R_AARCH64_LDST64_ABS_LO12_NC
>
> This patch modifies the arm64 machine_apply_elf_rel() function to handle
> these relocations.
Noticed that, gcc version of fedora koji(6.2.1-2.fc25) inserts another
relocation and kexec-tools generates following error.
machine_apply_elf_rel: ERROR Unknown type: 261
I have a fixup here:
https://github.com/pratyushanand/kexec-tools/commit/0eb8a908f617e0f957df7fb3ef293596f47e6832
May be I will send them separately.
~Pratyush
>
> Cc: Geoff Levand <geoff@infradead.org>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
>
> Changes for v2:
> - Fixed the type string to drop the "R_AARCH64_" prefix
>
> kexec/arch/arm64/kexec-arm64.c | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> index 2e8839a..e067a23 100644
> --- a/kexec/arch/arm64/kexec-arm64.c
> +++ b/kexec/arch/arm64/kexec-arm64.c
> @@ -550,6 +550,14 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
> # define R_AARCH64_ADR_PREL_LO21 274
> #endif
>
> +#if !defined(R_AARCH64_ADR_PREL_PG_HI21)
> +# define R_AARCH64_ADR_PREL_PG_HI21 275
> +#endif
> +
> +#if !defined(R_AARCH64_ADD_ABS_LO12_NC)
> +# define R_AARCH64_ADD_ABS_LO12_NC 277
> +#endif
> +
> #if !defined(R_AARCH64_JUMP26)
> # define R_AARCH64_JUMP26 282
> #endif
> @@ -558,10 +566,15 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
> # define R_AARCH64_CALL26 283
> #endif
>
> +#if !defined(R_AARCH64_LDST64_ABS_LO12_NC)
> +# define R_AARCH64_LDST64_ABS_LO12_NC 286
> +#endif
> +
> uint64_t *loc64;
> uint32_t *loc32;
> uint64_t *location = (uint64_t *)ptr;
> uint64_t data = *location;
> + uint64_t imm;
> const char *type = NULL;
>
> switch(r_type) {
> @@ -585,6 +598,19 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
> *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
> + (((value - address) << 3) & 0xffffe0));
> break;
> + case R_AARCH64_ADR_PREL_PG_HI21:
> + type = "ADR_PREL_PG_HI21";
> + imm = ((value & ~0xfff) - (address & ~0xfff)) >> 12;
> + loc32 = ptr;
> + *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
> + + ((imm & 3) << 29) + ((imm & 0x1ffffc) << (5 - 2)));
> + break;
> + case R_AARCH64_ADD_ABS_LO12_NC:
> + type = "ADD_ABS_LO12_NC";
> + loc32 = ptr;
> + *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
> + + ((value & 0xfff) << 10));
> + break;
> case R_AARCH64_JUMP26:
> type = "JUMP26";
> loc32 = ptr;
> @@ -597,6 +623,15 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
> *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
> + (((value - address) >> 2) & 0x3ffffff));
> break;
> + case R_AARCH64_LDST64_ABS_LO12_NC:
> + if (value & 7)
> + die("%s: ERROR Unaligned value: %lx\n", __func__,
> + value);
> + type = "LDST64_ABS_LO12_NC";
> + loc32 = ptr;
> + *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
> + + ((value & 0xff8) << (10 - 3)));
> + break;
> default:
> die("%s: ERROR Unknown type: %lu\n", __func__, r_type);
> break;
>
^ permalink raw reply
* [PATCH] arm64: Add support of R_AARCH64_PREL32 relocation in purgatory
From: Pratyush Anand @ 2016-10-26 4:40 UTC (permalink / raw)
To: linux-arm-kernel
gcc version in fedora koji is 6.2.1-2.fc25. kexec-tools compiled with this
gcc produced another relocation error:
machine_apply_elf_rel: ERROR Unknown type: 261
This patch fixes the above error.
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
kexec/arch/arm64/kexec-arm64.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 218f0bc832cd..b12de4772412 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -720,6 +720,10 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
# define R_AARCH64_ABS64 257
#endif
+#if !defined(R_AARCH64_PREL32)
+# define R_AARCH64_PREL32 261
+#endif
+
#if !defined(R_AARCH64_LD_PREL_LO19)
# define R_AARCH64_LD_PREL_LO19 273
#endif
@@ -761,6 +765,11 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
loc64 = ptr;
*loc64 = cpu_to_elf64(ehdr, elf64_to_cpu(ehdr, *loc64) + value);
break;
+ case R_AARCH64_PREL32:
+ type = "PREL32";
+ loc32 = ptr;
+ *loc32 = cpu_to_elf32(ehdr, elf32_to_cpu(ehdr, *loc32) + value - address);
+ break;
case R_AARCH64_LD_PREL_LO19:
type = "LD_PREL_LO19";
loc32 = ptr;
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP modules
From: Magnus Damm @ 2016-10-26 5:24 UTC (permalink / raw)
To: linux-arm-kernel
From: Magnus Damm <damm+renesas@opensource.se>
Extend the ARM64 defconfig to enable the DU DRM device as module
together with required dependencies of V4L2 FCP and VSP modules.
This enables VGA output on the r8a7795 Salvator-X board.
Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---
Written against next-20161026
arch/arm64/configs/defconfig | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- 0001/arch/arm64/configs/defconfig
+++ work/arch/arm64/configs/defconfig 2016-10-26 14:10:58.220607110 +0900
@@ -293,8 +293,22 @@ CONFIG_REGULATOR_PWM=y
CONFIG_REGULATOR_QCOM_SMD_RPM=y
CONFIG_REGULATOR_QCOM_SPMI=y
CONFIG_REGULATOR_S2MPS11=y
+CONFIG_MEDIA_SUPPORT=m
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
+CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
+CONFIG_MEDIA_CONTROLLER=y
+CONFIG_VIDEO_V4L2_SUBDEV_API=y
+# CONFIG_DVB_NET is not set
+CONFIG_V4L_MEM2MEM_DRIVERS=y
+CONFIG_VIDEO_RENESAS_FCP=m
+CONFIG_VIDEO_RENESAS_VSP1=m
CONFIG_DRM=m
CONFIG_DRM_NOUVEAU=m
+CONFIG_DRM_RCAR_DU=m
+CONFIG_DRM_RCAR_HDMI=y
+CONFIG_DRM_RCAR_LVDS=y
+CONFIG_DRM_RCAR_VSP=y
CONFIG_DRM_TEGRA=m
CONFIG_DRM_PANEL_SIMPLE=m
CONFIG_DRM_I2C_ADV7511=m
^ permalink raw reply
* [PATCH v5 3/9] drm/hisilicon/hibmc: Add support for frame buffer
From: Daniel Vetter @ 2016-10-26 5:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477449426-69018-4-git-send-email-zourongrong@gmail.com>
On Wed, Oct 26, 2016 at 10:37:00AM +0800, Rongrong Zou wrote:
> Add support for fbdev and kms fb management.
>
> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
Small drive-by comment below.
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> index db8d80e..d41138a 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> @@ -20,9 +20,23 @@
> #define HIBMC_DRM_DRV_H
>
> #include <drm/drmP.h>
> +#include <drm/drm_fb_helper.h>
> #include <drm/ttm/ttm_bo_driver.h>
> #include <drm/drm_gem.h>
>
> +struct hibmc_framebuffer {
> + struct drm_framebuffer fb;
> + struct drm_gem_object *obj;
> + bool is_fbdev_fb;
> +};
> +
> +struct hibmc_fbdev {
> + struct drm_fb_helper helper;
> + struct hibmc_framebuffer fb;
I wouldn't embed the single framebuffer here, but instead have a pointer
and just refcount it. This here is a pattern that predates framebuffer
refcounting, and it leads to plenty of surprises.
Maybe we should update the documentation of
drm_framebuffer_unregister_private() to mention that it is deprecated? The
overview doc in drm_framebuffer.c already explains that, but I guess
that's not obvious enough.
Can you pls do that patch? And pls make sure it all looks pretty when
building the docs with
$ make htmldocs
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v2] drm/mediatek: fixed the calc method of data rate per lane
From: CK Hu @ 2016-10-26 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477374045-2837-1-git-send-email-jitao.shi@mediatek.com>
Hi, Jitao:
On Tue, 2016-10-25 at 13:40 +0800, Jitao Shi wrote:
> Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
> Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
> signal will cause h-time larger than normal and reduce FPS.
> Need to multiply a coefficient to offset the extra signal's effect.
> coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
> Ths_exit)/(htotal*bpp/lane_number))
>
> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
> ---
> Change since v1:
> - phy_timing2 and phy_timing3 refer clock cycle time.
> - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 103 +++++++++++++++++++++++-------------
> 1 file changed, 67 insertions(+), 36 deletions(-)
>
[snip...]
>
> -static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> +static void dsi_phy_timconfig(struct mtk_dsi *dsi, u32 phy_timing0,
> + u32 phy_timing1, u32 phy_timing2,
> + u32 phy_timing3)
> {
> - u32 timcon0, timcon1, timcon2, timcon3;
> - unsigned int ui, cycle_time;
> - unsigned int lpx;
> -
> - ui = 1000 / dsi->data_rate + 0x01;
> - cycle_time = 8000 / dsi->data_rate + 0x01;
> - lpx = 5;
> -
> - timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
> - timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
> - (4 * lpx);
> - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> - (NS_TO_CYCLE(0x150, cycle_time) << 16);
> - timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> - NS_TO_CYCLE(0x40, cycle_time);
> -
> - writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
> - writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> - writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
> - writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
Why do you move these calculation to mtk_dsi_poweron()? You can keep
calculation here and just do some modification.
Regards,
CK
> + writel(phy_timing0, dsi->regs + DSI_PHY_TIMECON0);
> + writel(phy_timing1, dsi->regs + DSI_PHY_TIMECON1);
> + writel(phy_timing2, dsi->regs + DSI_PHY_TIMECON2);
> + writel(phy_timing3, dsi->regs + DSI_PHY_TIMECON3);
> }
>
> static void mtk_dsi_enable(struct mtk_dsi *dsi)
> @@ -202,19 +188,51 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> {
> struct device *dev = dsi->dev;
> int ret;
> + u64 bit_clock, total_bits;
> + u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
> + u32 phy_timing0, phy_timing1, phy_timing2, phy_timing3;
> + u32 ui, cycle_time;
>
> if (++dsi->refcount != 1)
> return 0;
>
> + switch (dsi->format) {
> + case MIPI_DSI_FMT_RGB565:
> + bit_per_pixel = 16;
> + break;
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + bit_per_pixel = 18;
> + break;
> + case MIPI_DSI_FMT_RGB666:
> + case MIPI_DSI_FMT_RGB888:
> + default:
> + bit_per_pixel = 24;
> + break;
> + }
> + /**
> + * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
> + * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
> + * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
> + * + Thstrail + Ths_exit + Ths_zero) /
> + * (htotal * byte_per_pixel /lane_number)
> + */
> + bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
> + htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
> + dsi->vm.hsync_len;
> + htotal_bits = htotal * bit_per_pixel;
> +
> /**
> - * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
> - * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
> - * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> - * we set mipi_ratio is 1.05.
> + * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
> */
> - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> + overhead_cycles = LPX + (HS_PRPR >> 8) + (HS_ZERO >> 16) +
> + (HS_TRAIL >> 24) + (DA_HS_EXIT >> 24);
> + overhead_bits = overhead_cycles * dsi->lanes * 8;
> + total_bits = htotal_bits + overhead_bits;
>
> - ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
> + dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
> + htotal_bits * dsi->lanes);
> +
> + ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
> if (ret < 0) {
> dev_err(dev, "Failed to set data rate: %d\n", ret);
> goto err_refcount;
> @@ -236,7 +254,20 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>
> mtk_dsi_enable(dsi);
> mtk_dsi_reset(dsi);
> - dsi_phy_timconfig(dsi);
> +
> + ui = 1000 / dsi->data_rate + 0x01;
> + cycle_time = 8000 / dsi->data_rate + 0x01;
> +
> + phy_timing0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
> + phy_timing1 = TA_GO | TA_SURE | TA_GET | DA_HS_EXIT;
> + phy_timing2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> + (NS_TO_CYCLE(0x150, cycle_time) << 16);
> + phy_timing3 = (2 * LPX) << 16 |
> + NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> + NS_TO_CYCLE(0x40, cycle_time);
> +
> + dsi_phy_timconfig(dsi, phy_timing0, phy_timing1, phy_timing2,
> + phy_timing3);
>
> return 0;
>
^ permalink raw reply
* [PATCH v2] staging: vc04_services: Replace dmac_map_area with dmac_map_sg
From: Greg KH @ 2016-10-26 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026022327.19055-1-mzoran@crowfest.net>
On Tue, Oct 25, 2016 at 07:23:27PM -0700, Michael Zoran wrote:
> The original arm implementation uses dmac_map_area which is not
> portable. Replace it with an architecture neutral version
> which uses dma_map_sg.
>
> As you can see that for larger page sizes, the dma_map_sg
> implementation is faster then the original unportable dma_map_area
> implementation.
>
> Test dmac_map_area dma_map_page dma_map_sg
> vchiq_test -b 4 10000 51us/iter 76us/iter 76us
> vchiq_test -b 8 10000 70us/iter 82us/iter 91us
> vchiq_test -b 16 10000 94us/iter 118us/iter 121us
> vchiq_test -b 32 10000 146us/iter 173us/iter 187us
> vchiq_test -b 64 10000 263us/iter 328us/iter 299us
> vchiq_test -b 128 10000 529us/iter 631us/iter 595us
> vchiq_test -b 256 10000 2285us/iter 2275us/iter 2001us
> vchiq_test -b 512 10000 4372us/iter 4616us/iter 4123us
>
> For message sizes >= 64KB, dma_map_sg is faster then dma_map_page.
>
> For message size >= 256KB, the dma_map_sg is the fastest
> implementation.
>
> "Normal" messages sizes should be about 1MB which is beyond
> the length that this change shows a speed increase.
>
> This is v2 of the patch which includes extra WARN_ONs and
> incorporates feedback from Eric Anholt <eric@anholt.net>.
>
> Signed-off-by: Michael Zoran <mzoran@crowfest.net>
> ---
> .../interface/vchiq_arm/vchiq_2835_arm.c | 152 +++++++++++++--------
> 1 file changed, 93 insertions(+), 59 deletions(-)
Nice work!
I'd like to get an ack from Eric before applying it...
thanks,
greg k-h
^ permalink raw reply
* [PATCH] tty/serial: at91: fix hardware handshake on Atmel platforms
From: Richard Genoud @ 2016-10-26 6:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025162247.phhevbtd6dsmknbr@piout.net>
On 25/10/2016 18:22, Alexandre Belloni wrote:
> Hi,
>
> On 25/10/2016 at 18:11:35 +0200, Richard Genoud wrote :
>> commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when
>> hardware handshake is enabled"), despite its title, broke hardware
>> handshake on *every* Atmel platforms.
>>
>> The only one partially working is the SAMA5D2.
>>
>
> [...]
>
>> Changes since v4:
>> - the mctrl_gpio_use_rtscts() is gone since it was atmel_serial
>> specific. (so patch 1 is gone)
>> - patches 2 and 3 have been merged together since it didn't make
>> a lot of sense to correct the GPIO case in one separate patch.
>> - ATMEL_US_USMODE_HWHS is now unset for platform with PDC
>>
>> Changes since v3:
>> - remove superfluous #include <linux/err.h> (thanks to Uwe)
>> - rebase on next-20160930
>>
>> Changes since v2:
>> - remove IS_ERR_OR_NULL() test in patch 1/3 as Uwe suggested.
>> - fix typos in patch 2/3
>> - rebase on next-20160927
>> - simplify the logic in patch 3/3.
>>
>> Changes since v1:
>> - Correct patch 1 with the error found by kbuild.
>> - Add Alexandre's Acked-by on patch 2
>> - Rewrite patch 3 logic in the light of the on-going discussion
>> with Cyrille and Alexandre.
>>
>
> The changelog has to go after the --- marker.
You're right.
thanks !
>> * the list may not be exhaustive
>>
>> Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
>
> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>
>> ---
>> drivers/tty/serial/atmel_serial.c | 25 +++++++++++++++++++++----
>> 1 file changed, 21 insertions(+), 4 deletions(-)
>>
>> I think this should go in the stable tree since it fixes the flow
>> control broken since v4.0.
>> But It won't compile on versions before 4.9rc1 because:
>> function atmel_use_fifo was introduced in 4.4.12 / 4.7
>> variable atmel_port was introduced in 4.9rc1
>>
>> That's why I didn't add the Cc stable in the email body.
>>
>>
>> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>> index fd8aa1f4ba78..2c7c45904ba7 100644
>> --- a/drivers/tty/serial/atmel_serial.c
>> +++ b/drivers/tty/serial/atmel_serial.c
>> @@ -2132,11 +2132,28 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
>> mode |= ATMEL_US_USMODE_RS485;
>> } else if (termios->c_cflag & CRTSCTS) {
>> /* RS232 with hardware handshake (RTS/CTS) */
>> - if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
>> - dev_info(port->dev, "not enabling hardware flow control because DMA is used");
>> - termios->c_cflag &= ~CRTSCTS;
>> - } else {
>> + if (atmel_use_fifo(port) &&
>> + !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
>> + /*
>> + * with ATMEL_US_USMODE_HWHS set, the controller will
>> + * be able to drive the RTS pin high/low when the RX
>> + * FIFO is above RXFTHRES/below RXFTHRES2.
>> + * It will also disable the transmitter when the CTS
>> + * pin is high.
>> + * This mode is not activated if CTS pin is a GPIO
>> + * because in this case, the transmitter is always
>> + * disabled.
>> + * If the RTS pin is a GPIO, the controller won't be
>> + * able to drive it according to the FIFO thresholds,
>> + * but it will be handled by the driver.
>> + */
>> mode |= ATMEL_US_USMODE_HWHS;
>> + } else {
>> + /*
>> + * For platforms without FIFO, the flow control is
>> + * handled by the driver.
>> + */
>> + mode |= ATMEL_US_USMODE_NORMAL;
>> }
>> } else {
>> /* RS232 without hadware handshake */
>
^ permalink raw reply
* [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG MSI
From: M.H. Lian @ 2016-10-26 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0416d929-dfef-da09-8d9a-d1db8575afef@arm.com>
Hi Robin,
Please see my comments inline.
Thanks,
Minghuan
> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Tuesday, October 25, 2016 9:01 PM
> To: M.H. Lian <minghuan.lian@nxp.com>; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org
> Cc: Marc Zyngier <marc.zyngier@arm.com>; Stuart Yoder
> <stuart.yoder@nxp.com>; Leo Li <leoyang.li@nxp.com>; Scott Wood
> <scott.wood@nxp.com>; Shawn Guo <shawnguo@kernel.org>; Mingkai Hu
> <mingkai.hu@nxp.com>
> Subject: Re: [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG
> MSI
>
> On 25/10/16 13:35, Minghuan Lian wrote:
> > 1. The different version of a SoC may have different MSI
> > implementation. But compatible "fsl,<soc-name>-msi" can not describe
> > the SoC version.
>
> Can't it?
>
> compatible = "fsl-ls1043a-rev11-msi";
>
> Oh, I guess it can!
>
> Joking aside, if there are multiple versions of a piece of hardware which
> require *different* treatment by drivers, then it is obviously wrong to use
> the same compatible string because *they are not compatible*.
>
[Minghuan Lian] Yes, but Rev1.0 and Rev1.1 SoC will use the same dts files.
We cannot create different dts files for each revision of the same kind of SoC.
It means that there are different variants in the different versions of the same SoC that will use the same compatible string.
So I have to use SoC match interface to get the versions.
I'm too radical. I do not want to first check SoC family via compatible string and then check revision via SoC match or SVR.
I selected the "SoC match" like the following to get the related information at only one place.
static struct soc_device_attribute soc_msi_matches[] = {
{ .family = "QorIQ LS1021A",
.data = &ls1021_msi_cfg },
{ .family = "QorIQ LS1012A",
.data = &ls1021_msi_cfg },
{ .family = "QorIQ LS1043A", .revision = "1.0",
.data = &ls1021_msi_cfg },
{ .family = "QorIQ LS1043A", .revision = "1.1",
.data = &ls1043_rev11_msi_cfg },
{ .family = "QorIQ LS1046A",
.data = &ls1046_msi_cfg },
{ },
};
I will remain the SoC related compatible and try to describe the difference via some kind of the property.
> > The MSI driver will use SoC match interface to get SoC type and
> > version instead of compatible string. So all MSI node can use the
> > common compatible "fsl,ls-scfg-msi" and the original compatible is
> > unnecessary.
>
> If there is some common level of functionality that *all* variants support
> without the driver having to know which one is which, then there might be
> some sense in having an additional common compatible to represent that
> level of functionality, e.g.
>
> compatible = "fsl-ls1043a-rev11-msi", "fsl,ls-scfg-msi";
>
> But if, say, new variants turn out to have less functionality, rather than more,
> then there's probably not much point, and we should stick to specific,
> accurate, compatible strings.
>
> DT is not specific to a kernel version, nor even to Linux. A string which triggers
> some board-specific magic in a specific version of a Linux driver does not
> describe the hardware.
>
> Robin.
>
> > 2. Layerscape SoCs may have one or several MSI controllers.
> > In order to increase MSI interrupt number of a PCIe, the patch moves
> > all MSI node into the parent node "msi-controller". So a PCIe can
> > request MSI from all the MSI controllers.
> >
> > Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
> > ---
> > .../interrupt-controller/fsl,ls-scfg-msi.txt | 57 +++++++++++++++++++--
> -
> > 1 file changed, 49 insertions(+), 8 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > index 9e38949..29f95fd 100644
> > ---
> > a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-sc
> > +++ fg-msi.txt
> > @@ -1,18 +1,28 @@
> > * Freescale Layerscape SCFG PCIe MSI controller
> >
> > +Layerscape SoCs may have one or multiple MSI controllers.
> > +Each MSI controller must be showed as a child node.
> > +
> > Required properties:
> >
> > -- compatible: should be "fsl,<soc-name>-msi" to identify
> > - Layerscape PCIe MSI controller block such as:
> > - "fsl,1s1021a-msi"
> > - "fsl,1s1043a-msi"
> > +- compatible: should be "fsl,ls-scfg-msi"
> > +- #address-cells: must be 2
> > +- #size-cells: must be 2
> > +- ranges: allows valid 1:1 translation between child's address space and
> > + parent's address space
> > - msi-controller: indicates that this is a PCIe MSI controller node
> > +
> > +Required child node:
> > +A child node must exist to represent the MSI controller.
> > +The following are properties specific to those nodes:
> > +
> > - reg: physical base address of the controller and length of memory
> mapped.
> > - interrupts: an interrupt to the parent interrupt controller.
> >
> > Optional properties:
> > - interrupt-parent: the phandle to the parent interrupt controller.
> >
> > +Notes:
> > This interrupt controller hardware is a second level interrupt
> > controller that is hooked to a parent interrupt controller: e.g: ARM
> > GIC for ARM-based platforms. If interrupt-parent is not provided, the
> > default parent interrupt @@ -22,9 +32,40 @@ MSI controller node
> >
> > Examples:
> >
> > - msi1: msi-controller at 1571000 {
> > - compatible = "fsl,1s1043a-msi";
> > - reg = <0x0 0x1571000 0x0 0x8>,
> > + msi: msi-controller {
> > + compatible = "fsl,ls-scfg-msi";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > msi-controller;
> > - interrupts = <0 116 0x4>;
> > +
> > + msi0 at 1580000 {
> > + reg = <0x0 0x1580000 0x0 0x10000>;
> > + interrupts = <0 116 0x4>,
> > + <0 111 0x4>,
> > + <0 112 0x4>,
> > + <0 113 0x4>;
> > + };
> > +
> > + msi1 at 1590000 {
> > + reg = <0x0 0x1590000 0x0 0x10000>;
> > + interrupts = <0 126 0x4>,
> > + <0 121 0x4>,
> > + <0 122 0x4>,
> > + <0 123 0x4>;
> > + };
> > +
> > + msi2 at 15a0000 {
> > + reg = <0x0 0x15a0000 0x0 0x10000>;
> > + interrupts = <0 160 0x4>,
> > + <0 155 0x4>,
> > + <0 156 0x4>,
> > + <0 157 0x4>;
> > + };
> > + };
> > +
> > + pcie at 3400000 {
> > + ...
> > + msi-parent = <&msi>;
> > + ...
> > };
> >
^ permalink raw reply
* [PATCH v7] spi: sun4i: Allow transfers larger than FIFO size
From: Alexandru Gagniuc @ 2016-10-26 7:00 UTC (permalink / raw)
To: linux-arm-kernel
This is the seventh attempt to get this patch in. I was prompted to look
into this again as someone recently remarked:
" cool, to bad spi does not work properly on allwinner..."
Two and a half years ago, we were told this will all be handled with DMA.
A year or so ago, we were told this will all be handled with DMA.
A week or so ago, we were told this will all be handled with DMA.
See the pattern?
When DMA finally takes over, this fallback path is not mutually exclusive.
Changes since V6:
Rebased to make sure it applies on top of 4.9-rc.
Also tested on actual hardware.
Alexandru Gagniuc (1):
spi: sun4i: Allow transfers larger than FIFO size
drivers/spi/spi-sun4i.c | 75 +++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 67 insertions(+), 8 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH] spi: sun4i: Allow transfers larger than FIFO size
From: Alexandru Gagniuc @ 2016-10-26 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477465231-17704-1-git-send-email-mr.nuke.me@gmail.com>
SPI transfers were limited to one FIFO depth, which is 64 bytes.
This was an artificial limitation, however, as the hardware can handle
much larger bursts. To accommodate this, we enable the interrupt when
the Rx FIFO is 3/4 full, and drain the FIFO within the interrupt
handler. The 3/4 ratio was chosen arbitrarily, with the intention to
reduce the potential number of interrupts.
Since the SUN4I_CTL_TP bit is set, the hardware will pause
transmission whenever the FIFO is full, so there is no risk of losing
data if we can't service the interrupt in time.
For the Tx side, enable and use the Tx FIFO 3/4 empty interrupt to
replenish the FIFO on large SPI bursts. This requires more care in
when the interrupt is left enabled, as this interrupt will continually
trigger when the FIFO is less than 1/4 full, even though we
acknowledge it.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Olliver Schinagl <o.schinagl@ultimaker.com>
---
drivers/spi/spi-sun4i.c | 75 +++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 67 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index 4969dc1..c5cd635 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -46,6 +46,8 @@
#define SUN4I_CTL_TP BIT(18)
#define SUN4I_INT_CTL_REG 0x0c
+#define SUN4I_INT_CTL_RF_F34 BIT(4)
+#define SUN4I_INT_CTL_TF_E34 BIT(12)
#define SUN4I_INT_CTL_TC BIT(16)
#define SUN4I_INT_STA_REG 0x10
@@ -61,11 +63,14 @@
#define SUN4I_CLK_CTL_CDR1(div) (((div) & SUN4I_CLK_CTL_CDR1_MASK) << 8)
#define SUN4I_CLK_CTL_DRS BIT(12)
+#define SUN4I_MAX_XFER_SIZE 0xffffff
+
#define SUN4I_BURST_CNT_REG 0x20
-#define SUN4I_BURST_CNT(cnt) ((cnt) & 0xffffff)
+#define SUN4I_BURST_CNT(cnt) ((cnt) & SUN4I_MAX_XFER_SIZE)
#define SUN4I_XMIT_CNT_REG 0x24
-#define SUN4I_XMIT_CNT(cnt) ((cnt) & 0xffffff)
+#define SUN4I_XMIT_CNT(cnt) ((cnt) & SUN4I_MAX_XFER_SIZE)
+
#define SUN4I_FIFO_STA_REG 0x28
#define SUN4I_FIFO_STA_RF_CNT_MASK 0x7f
@@ -96,6 +101,31 @@ static inline void sun4i_spi_write(struct sun4i_spi *sspi, u32 reg, u32 value)
writel(value, sspi->base_addr + reg);
}
+static inline u32 sun4i_spi_get_tx_fifo_count(struct sun4i_spi *sspi)
+{
+ u32 reg = sun4i_spi_read(sspi, SUN4I_FIFO_STA_REG);
+
+ reg >>= SUN4I_FIFO_STA_TF_CNT_BITS;
+
+ return reg & SUN4I_FIFO_STA_TF_CNT_MASK;
+}
+
+static inline void sun4i_spi_enable_interrupt(struct sun4i_spi *sspi, u32 mask)
+{
+ u32 reg = sun4i_spi_read(sspi, SUN4I_INT_CTL_REG);
+
+ reg |= mask;
+ sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, reg);
+}
+
+static inline void sun4i_spi_disable_interrupt(struct sun4i_spi *sspi, u32 mask)
+{
+ u32 reg = sun4i_spi_read(sspi, SUN4I_INT_CTL_REG);
+
+ reg &= ~mask;
+ sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, reg);
+}
+
static inline void sun4i_spi_drain_fifo(struct sun4i_spi *sspi, int len)
{
u32 reg, cnt;
@@ -118,10 +148,13 @@ static inline void sun4i_spi_drain_fifo(struct sun4i_spi *sspi, int len)
static inline void sun4i_spi_fill_fifo(struct sun4i_spi *sspi, int len)
{
+ u32 cnt;
u8 byte;
- if (len > sspi->len)
- len = sspi->len;
+ /* See how much data we can fit */
+ cnt = SUN4I_FIFO_DEPTH - sun4i_spi_get_tx_fifo_count(sspi);
+
+ len = min3(len, (int)cnt, sspi->len);
while (len--) {
byte = sspi->tx_buf ? *sspi->tx_buf++ : 0;
@@ -184,10 +217,10 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
u32 reg;
/* We don't support transfer larger than the FIFO */
- if (tfr->len > SUN4I_FIFO_DEPTH)
+ if (tfr->len > SUN4I_MAX_XFER_SIZE)
return -EMSGSIZE;
- if (tfr->tx_buf && tfr->len >= SUN4I_FIFO_DEPTH)
+ if (tfr->tx_buf && tfr->len >= SUN4I_MAX_XFER_SIZE)
return -EMSGSIZE;
reinit_completion(&sspi->done);
@@ -286,7 +319,11 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH - 1);
/* Enable the interrupts */
- sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, SUN4I_INT_CTL_TC);
+ sun4i_spi_enable_interrupt(sspi, SUN4I_INT_CTL_TC |
+ SUN4I_INT_CTL_RF_F34);
+ /* Only enable Tx FIFO interrupt if we really need it */
+ if (tx_len > SUN4I_FIFO_DEPTH)
+ sun4i_spi_enable_interrupt(sspi, SUN4I_INT_CTL_TF_E34);
/* Start the transfer */
reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
@@ -306,7 +343,6 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
goto out;
}
- sun4i_spi_drain_fifo(sspi, SUN4I_FIFO_DEPTH);
out:
sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, 0);
@@ -322,10 +358,33 @@ static irqreturn_t sun4i_spi_handler(int irq, void *dev_id)
/* Transfer complete */
if (status & SUN4I_INT_CTL_TC) {
sun4i_spi_write(sspi, SUN4I_INT_STA_REG, SUN4I_INT_CTL_TC);
+ sun4i_spi_drain_fifo(sspi, SUN4I_FIFO_DEPTH);
complete(&sspi->done);
return IRQ_HANDLED;
}
+ /* Receive FIFO 3/4 full */
+ if (status & SUN4I_INT_CTL_RF_F34) {
+ sun4i_spi_drain_fifo(sspi, SUN4I_FIFO_DEPTH);
+ /* Only clear the interrupt _after_ draining the FIFO */
+ sun4i_spi_write(sspi, SUN4I_INT_STA_REG, SUN4I_INT_CTL_RF_F34);
+ return IRQ_HANDLED;
+ }
+
+ /* Transmit FIFO 3/4 empty */
+ if (status & SUN4I_INT_CTL_TF_E34) {
+ sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH);
+
+ if (!sspi->len)
+ /* nothing left to transmit */
+ sun4i_spi_disable_interrupt(sspi, SUN4I_INT_CTL_TF_E34);
+
+ /* Only clear the interrupt _after_ re-seeding the FIFO */
+ sun4i_spi_write(sspi, SUN4I_INT_STA_REG, SUN4I_INT_CTL_TF_E34);
+
+ return IRQ_HANDLED;
+ }
+
return IRQ_NONE;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: convert to generated system call tables
From: Michael Cree @ 2016-10-26 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4146248.jXuviLlvH5@wuerfel>
On Tue, Oct 25, 2016 at 12:28:16PM +0200, Arnd Bergmann wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > > I see your point, but I think there are serious issues with the current
> > > approach as well:
> > >
> > > - a lot of the less common architectures just don't get updated
> > > in time, out of 22 architectures that don't use asm-generic/unistd.h,
> > > only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > >
> > > - some architectures that add all syscalls sometimes make a mistake
> > > and forget one, e.g. alpha apparently never added __NR_bpf, but it
> > > did add the later __NR_execveat.
> >
> > __NR_bpf was not forgotten on Alpha. It was not wired up because
> > extra architecture support is needed which has not been implemented.
> >
> > But maybe we should just wire it up to sys_ni_syscall in the meantime
> > so a syscall number is reserved for it, and user space can call it to
> > get -ENOSYS returned.
>
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.
Oh. When someone posted wiring up of syscalls on Alpha some time
back I raised a query about seccomp then someone else (I can't be
bothered looking up the old emails, it doesn't really matter)
said bpf was in the same basket, so the patch was re-submitted with
neither of those syscalls.
> sys_seccomp is another one that falls into a similar category, but
> it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> architectures have assigned a syscall number but not set this symbol.
> This one will actually allow you to set strict seccomp mode even
> without the Kconfig symbol, just not allow to set a filter.
We have got way behind on syscalls on Alpha and I was just in the
process of wiring them up and testing them, so I will include both
seccomp and bpf in that.
Cheers
Michael.
^ permalink raw reply
* [PATCH 3/3] ARM: dts: socfpga: Enable QSPI on the Cyclone5 sockit
From: Steffen Trumtrar @ 2016-10-26 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5e0adad1-8ef2-029f-cfcd-4a07c962fda2@opensource.altera.com>
Hi!
On Tue, Oct 25, 2016 at 10:38:10AM -0500, Graham Moore wrote:
> On 10/20/2016 09:12 AM, Dinh Nguyen wrote:
> >
> >
> > On 10/20/2016 02:19 AM, Steffen Trumtrar wrote:
> >
> > > > + cdns,tslch-ns = <4>;
> > > > +
> > > > + partition at qspi-boot {
> > > > + /* 8MB for raw data. */
> > > > + label = "Flash 0 Raw Data";
> > > > + reg = <0x0 0x800000>;
> > > > + };
> > > > +
> > > > + partition at qspi-rootfs {
> > > > + /* 120MB for jffs2 data. */
> > > > + label = "Flash 0 jffs2 Filesystem";
> > > > + reg = <0x800000 0x7800000>;
> > > > + };
> > > > + };
> > > > +};
> > > > +
> > >
> > > What is the current preferred way of handling the partitions?
> > > This doesn't fit my Sockit configuration for example. So I would always
> > > have to patch the devicetree.
> >
> > I'm not 100% sure on this. Graham, do you have any insight?
> > >
>
> Well, strictly speaking, these partitions are only for the socdk, the Altera
> dev kit. Our sample designs and file systems expect this layout.
The thing is, that I don't think these partitions belong in a mainline
dts at all. But I'm not sure what the current policy is.
>
> Therefore, these partitions are not required for any other dev kits, and can
> probably be left out.
>
> Or, Steffen, if you have a standard layout you'd like to see, then put that
> in there.
>
Well in my case, it actually doesn't really matter. All the boards
I use do not have u-boot as bootloader but barebox. And barebox uses
devicetree fixups for adding the partition layout that fits the
particular use case. All other partitions are thrown out.
I don't know if u-boot does something like this.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v2] clocksource/arm_arch_timer: Map frame with of_io_request_and_map()
From: Stephen Boyd @ 2016-10-26 7:35 UTC (permalink / raw)
To: linux-arm-kernel
Let's use the of_io_request_and_map() API so that the frame
region is protected and shows up in /proc/iomem.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
Changes from v1:
* Check for IS_ERR instead
drivers/clocksource/arm_arch_timer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 73c487da6d2a..723cc924d8d1 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -964,8 +964,9 @@ static int __init arch_timer_mem_init(struct device_node *np)
}
ret= -ENXIO;
- base = arch_counter_base = of_iomap(best_frame, 0);
- if (!base) {
+ base = arch_counter_base = of_io_request_and_map(best_frame, 0,
+ "arch_mem_timer");
+ if (IS_ERR(base)) {
pr_err("arch_timer: Can't map frame's registers\n");
goto out;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* arm/boot/dts/at91sam9260.dtsi USB clock divisors and AT91SAM9G20
From: Alexandre Belloni @ 2016-10-26 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAkeqgVrCEAtX+Tujjqe4admkhnn1746kL4_d8Z1NjCwVwUGcA@mail.gmail.com>
On 25/10/2016 at 10:49:01 -0700, Andrey Yurovsky wrote :
> I'm working at an AT91SAM9G20 on which the USB clock divisor was wrong
> and traced the issue down to arm/boot/dts/at91sam9260.dtsi which is
> included like this:
>
> at91sam9g20ek_common.dtsi
> at91sam9g20.dtsi
> at91sam9260.dtsi
>
> This has a node:
>
> usb: usbck {
> compatible = "atmel,at91rm9200-clk-usb";
> #clock-cells = <0>;
> atmel,clk-divisors = <1 2 4 0>;
> clocks = <&pllb>;
> };
>
> However the G20 parts seem to need a different divisor, for me this works:
>
> usb: usbck {
> compatible = "atmel,at91rm9200-clk-usb";
> #clock-cells = <0>;
> atmel,clk-divisors = <4 2 0 0>;
> clocks = <&pllb>;
> };
>
> Should the USB clock node be moved to a separate .dtsi file to account
> for this difference?
I think the easiest way of doing it is to override atmel,clk-divisors in
at91sam9g20.dtsi.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v6 1/5] ARM: davinci: da8xx: add usb phy clocks
From: Sekhar Nori @ 2016-10-26 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477451211-31979-2-git-send-email-david@lechnology.com>
On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:
> Up to this point, the USB phy clock configuration was handled manually in
> the board files and in the usb drivers. This adds proper clocks so that
> the usb drivers can use clk_get and clk_enable and not have to worry about
> the details. Also, the related code is removed from the board files and
> replaced with the new clock registration functions.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
>
> I have added "ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable"
> from Axel Haslam to this patch.
>
> In the review of Axel's patch, Sekhar said:
>
>> We should not be using a NULL device pointer here. Can you pass the musb
>> device pointer available in the same file? Also, da850_clks[] in da850.c
>> needs to be fixed to add the matching device name.
>
> However, the musb device may not be registered. The usb20_clk can be used to
> supply a 48MHz clock to USB 1.1 (ohci) without using the musb device. So, I am
> inclined to leave this as NULL.
But clock look-up has nothing to do with device being registered AFAICT.
It is used to identify the clock consumer. Passing NULL there means the
clock is not associated with any device. Which is not correct as we are
specifically looking at MUSB module clock.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2] dmaengine: mv_xor: Add support for scatter-gather DMA mode
From: Stefan Roese @ 2016-10-26 8:10 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds memory to memory scatter-gather support to the Marvell
mv_or DMA driver.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>
---
v2:
- Change none, but now compiles clean for x86_64 since the following patch
has been applied in the mean-time:
434cec62a6d73b8c8080cd992bc97a564fdd5a5a
bus: mvebu-mbus: Provide stub function for mvebu_mbus_get_io_win_info()
drivers/dma/mv_xor.c | 183 +++++++++++++++++++++++++++++++++++++++++++++++++--
drivers/dma/mv_xor.h | 1 +
2 files changed, 180 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index 23f7528..b0d09d9 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -68,6 +68,36 @@ static void mv_desc_init(struct mv_xor_desc_slot *desc,
hw_desc->byte_count = byte_count;
}
+/* Populate the descriptor */
+static void mv_xor_config_sg_ll_desc(struct mv_xor_desc_slot *desc,
+ dma_addr_t dma_src, dma_addr_t dma_dst,
+ u32 len, struct mv_xor_desc_slot *prev)
+{
+ struct mv_xor_desc *hw_desc = desc->hw_desc;
+
+ hw_desc->status = XOR_DESC_DMA_OWNED;
+ hw_desc->phy_next_desc = 0;
+ /* Configure for XOR with only one src address -> MEMCPY */
+ hw_desc->desc_command = XOR_DESC_OPERATION_XOR | (0x1 << 0);
+ hw_desc->phy_dest_addr = dma_dst;
+ hw_desc->phy_src_addr[0] = dma_src;
+ hw_desc->byte_count = len;
+
+ if (prev) {
+ struct mv_xor_desc *hw_prev = prev->hw_desc;
+
+ hw_prev->phy_next_desc = desc->async_tx.phys;
+ }
+}
+
+static void mv_xor_desc_config_eod(struct mv_xor_desc_slot *desc)
+{
+ struct mv_xor_desc *hw_desc = desc->hw_desc;
+
+ /* Enable end-of-descriptor interrupt */
+ hw_desc->desc_command |= XOR_DESC_EOD_INT_EN;
+}
+
static void mv_desc_set_mode(struct mv_xor_desc_slot *desc)
{
struct mv_xor_desc *hw_desc = desc->hw_desc;
@@ -228,8 +258,13 @@ mv_chan_clean_completed_slots(struct mv_xor_chan *mv_chan)
list_for_each_entry_safe(iter, _iter, &mv_chan->completed_slots,
node) {
- if (async_tx_test_ack(&iter->async_tx))
+ if (async_tx_test_ack(&iter->async_tx)) {
list_move_tail(&iter->node, &mv_chan->free_slots);
+ if (!list_empty(&iter->sg_tx_list)) {
+ list_splice_tail_init(&iter->sg_tx_list,
+ &mv_chan->free_slots);
+ }
+ }
}
return 0;
}
@@ -244,11 +279,20 @@ mv_desc_clean_slot(struct mv_xor_desc_slot *desc,
/* the client is allowed to attach dependent operations
* until 'ack' is set
*/
- if (!async_tx_test_ack(&desc->async_tx))
+ if (!async_tx_test_ack(&desc->async_tx)) {
/* move this slot to the completed_slots */
list_move_tail(&desc->node, &mv_chan->completed_slots);
- else
+ if (!list_empty(&desc->sg_tx_list)) {
+ list_splice_tail_init(&desc->sg_tx_list,
+ &mv_chan->completed_slots);
+ }
+ } else {
list_move_tail(&desc->node, &mv_chan->free_slots);
+ if (!list_empty(&desc->sg_tx_list)) {
+ list_splice_tail_init(&desc->sg_tx_list,
+ &mv_chan->free_slots);
+ }
+ }
return 0;
}
@@ -450,6 +494,7 @@ static int mv_xor_alloc_chan_resources(struct dma_chan *chan)
dma_async_tx_descriptor_init(&slot->async_tx, chan);
slot->async_tx.tx_submit = mv_xor_tx_submit;
INIT_LIST_HEAD(&slot->node);
+ INIT_LIST_HEAD(&slot->sg_tx_list);
dma_desc = mv_chan->dma_desc_pool;
slot->async_tx.phys = dma_desc + idx * MV_XOR_SLOT_SIZE;
slot->idx = idx++;
@@ -617,6 +662,132 @@ mv_xor_prep_dma_interrupt(struct dma_chan *chan, unsigned long flags)
return mv_xor_prep_dma_xor(chan, dest, &src, 1, len, flags);
}
+/**
+ * mv_xor_prep_dma_sg - prepare descriptors for a memory sg transaction
+ * @chan: DMA channel
+ * @dst_sg: Destination scatter list
+ * @dst_sg_len: Number of entries in destination scatter list
+ * @src_sg: Source scatter list
+ * @src_sg_len: Number of entries in source scatter list
+ * @flags: transfer ack flags
+ *
+ * Return: Async transaction descriptor on success and NULL on failure
+ */
+static struct dma_async_tx_descriptor *
+mv_xor_prep_dma_sg(struct dma_chan *chan, struct scatterlist *dst_sg,
+ unsigned int dst_sg_len, struct scatterlist *src_sg,
+ unsigned int src_sg_len, unsigned long flags)
+{
+ struct mv_xor_chan *mv_chan = to_mv_xor_chan(chan);
+ struct mv_xor_desc_slot *new;
+ struct mv_xor_desc_slot *first = NULL;
+ struct mv_xor_desc_slot *prev = NULL;
+ size_t len, dst_avail, src_avail;
+ dma_addr_t dma_dst, dma_src;
+ int desc_cnt = 0;
+ int ret;
+
+ dev_dbg(mv_chan_to_devp(mv_chan),
+ "%s dst_sg_len: %d src_sg_len: %d flags: %ld\n",
+ __func__, dst_sg_len, src_sg_len, flags);
+
+ dst_avail = sg_dma_len(dst_sg);
+ src_avail = sg_dma_len(src_sg);
+
+ /* Run until we are out of scatterlist entries */
+ while (true) {
+ /* Allocate and populate the descriptor */
+ desc_cnt++;
+ new = mv_chan_alloc_slot(mv_chan);
+ if (!new) {
+ dev_err(mv_chan_to_devp(mv_chan),
+ "Out of descriptors (desc_cnt=%d)!\n",
+ desc_cnt);
+ goto err;
+ }
+
+ len = min_t(size_t, src_avail, dst_avail);
+ len = min_t(size_t, len, MV_XOR_MAX_BYTE_COUNT);
+ if (len == 0)
+ goto fetch;
+
+ if (len < MV_XOR_MIN_BYTE_COUNT) {
+ dev_err(mv_chan_to_devp(mv_chan),
+ "Transfer size of %zu too small!\n", len);
+ goto err;
+ }
+
+ dma_dst = sg_dma_address(dst_sg) + sg_dma_len(dst_sg) -
+ dst_avail;
+ dma_src = sg_dma_address(src_sg) + sg_dma_len(src_sg) -
+ src_avail;
+
+ /* Check if a new window needs to get added for 'dst' */
+ ret = mv_xor_add_io_win(mv_chan, dma_dst);
+ if (ret)
+ goto err;
+
+ /* Check if a new window needs to get added for 'src' */
+ ret = mv_xor_add_io_win(mv_chan, dma_src);
+ if (ret)
+ goto err;
+
+ /* Populate the descriptor */
+ mv_xor_config_sg_ll_desc(new, dma_src, dma_dst, len, prev);
+ prev = new;
+ dst_avail -= len;
+ src_avail -= len;
+
+ if (!first)
+ first = new;
+ else
+ list_move_tail(&new->node, &first->sg_tx_list);
+
+fetch:
+ /* Fetch the next dst scatterlist entry */
+ if (dst_avail == 0) {
+ if (dst_sg_len == 0)
+ break;
+
+ /* Fetch the next entry: if there are no more: done */
+ dst_sg = sg_next(dst_sg);
+ if (dst_sg == NULL)
+ break;
+
+ dst_sg_len--;
+ dst_avail = sg_dma_len(dst_sg);
+ }
+
+ /* Fetch the next src scatterlist entry */
+ if (src_avail == 0) {
+ if (src_sg_len == 0)
+ break;
+
+ /* Fetch the next entry: if there are no more: done */
+ src_sg = sg_next(src_sg);
+ if (src_sg == NULL)
+ break;
+
+ src_sg_len--;
+ src_avail = sg_dma_len(src_sg);
+ }
+ }
+
+ /* Set the EOD flag in the last descriptor */
+ mv_xor_desc_config_eod(new);
+ first->async_tx.flags = flags;
+
+ return &first->async_tx;
+
+err:
+ /* Cleanup: Move all descriptors back into the free list */
+ spin_lock_bh(&mv_chan->lock);
+ mv_desc_clean_slot(first, mv_chan);
+ spin_unlock_bh(&mv_chan->lock);
+
+ return NULL;
+}
+
static void mv_xor_free_chan_resources(struct dma_chan *chan)
{
struct mv_xor_chan *mv_chan = to_mv_xor_chan(chan);
@@ -1083,6 +1254,8 @@ mv_xor_channel_add(struct mv_xor_device *xordev,
dma_dev->device_prep_dma_interrupt = mv_xor_prep_dma_interrupt;
if (dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask))
dma_dev->device_prep_dma_memcpy = mv_xor_prep_dma_memcpy;
+ if (dma_has_cap(DMA_SG, dma_dev->cap_mask))
+ dma_dev->device_prep_dma_sg = mv_xor_prep_dma_sg;
if (dma_has_cap(DMA_XOR, dma_dev->cap_mask)) {
dma_dev->max_xor = 8;
dma_dev->device_prep_dma_xor = mv_xor_prep_dma_xor;
@@ -1132,10 +1305,11 @@ mv_xor_channel_add(struct mv_xor_device *xordev,
goto err_free_irq;
}
- dev_info(&pdev->dev, "Marvell XOR (%s): ( %s%s%s)\n",
+ dev_info(&pdev->dev, "Marvell XOR (%s): ( %s%s%s%s)\n",
mv_chan->op_in_desc ? "Descriptor Mode" : "Registers Mode",
dma_has_cap(DMA_XOR, dma_dev->cap_mask) ? "xor " : "",
dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask) ? "cpy " : "",
+ dma_has_cap(DMA_SG, dma_dev->cap_mask) ? "sg " : "",
dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask) ? "intr " : "");
dma_async_device_register(dma_dev);
@@ -1378,6 +1552,7 @@ static int mv_xor_probe(struct platform_device *pdev)
dma_cap_zero(cap_mask);
dma_cap_set(DMA_MEMCPY, cap_mask);
+ dma_cap_set(DMA_SG, cap_mask);
dma_cap_set(DMA_XOR, cap_mask);
dma_cap_set(DMA_INTERRUPT, cap_mask);
diff --git a/drivers/dma/mv_xor.h b/drivers/dma/mv_xor.h
index 88eeab2..cf921dd 100644
--- a/drivers/dma/mv_xor.h
+++ b/drivers/dma/mv_xor.h
@@ -148,6 +148,7 @@ struct mv_xor_chan {
*/
struct mv_xor_desc_slot {
struct list_head node;
+ struct list_head sg_tx_list;
enum dma_transaction_type type;
void *hw_desc;
u16 idx;
--
2.10.1
^ permalink raw reply related
* [PATCH v14 0/9] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
From: Fu Wei @ 2016-10-26 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020151655.GA27598@leverpostej>
Hi Mark
On 20 October 2016 at 23:17, Mark Rutland <mark.rutland@arm.com> wrote:
> On Thu, Oct 20, 2016 at 03:57:52PM +0100, Lorenzo Pieralisi wrote:
>> On Thu, Oct 20, 2016 at 03:31:01PM +0100, Mark Rutland wrote:
>> > Hi,
>> >
>> > On Thu, Sep 29, 2016 at 02:17:08AM +0800, fu.wei at linaro.org wrote:
>> > > From: Fu Wei <fu.wei@linaro.org>
>> >
>> > > This patchset depends on the following patchset:
>> > > [UPDATE PATCH V11 1/8] ACPI: I/O Remapping Table (IORT) initial support
>> > > https://lkml.org/lkml/2016/9/12/949
>> >
>> > Is there a branch with these anywhere? I wasn't Cc'd on those and it's
>> > rather difficult to get at the series from an LKML link.
>>
>> For the records, the dependency above has now been merged and it was
>> just a directory creation dependency (drivers/acpi/arm64, where some of
>> the code in this series will live).
>
> Ah, I see. That saves us all some trouble, then. :)
Sorry, I forgot to delete this in v14 cover letter.
The IORT patchset has been merged in to the mainline,
we don't need to mention this anymore. :-)
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v14 2/9] clocksource/drivers/arm_arch_timer: Add a new enum for spi type
From: Fu Wei @ 2016-10-26 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020150933.GK10234@leverpostej>
Hi Mark,
On 20 October 2016 at 23:09, Mark Rutland <mark.rutland@arm.com> wrote:
> On Thu, Sep 29, 2016 at 02:17:10AM +0800, fu.wei at linaro.org wrote:
>> diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
>> index 6f06481..16dcd10 100644
>> --- a/include/clocksource/arm_arch_timer.h
>> +++ b/include/clocksource/arm_arch_timer.h
>> @@ -45,6 +45,12 @@ enum ppi_nr {
>> MAX_TIMER_PPI
>> };
>>
>> +enum spi_nr {
>> + PHYS_SPI,
>> + VIRT_SPI,
>> + MAX_TIMER_SPI
>> +};
>
> Please rename this to arch_timer_spi_nr (as with patch 1 for
> s/ppi_nr/arch_timer_ppi_nr/). With that:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
OK, NP, done :-)
Great thanks!
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v14 3/9] clocksource/drivers/arm_arch_timer: Improve printk relevant code
From: Fu Wei @ 2016-10-26 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020153244.GB27598@leverpostej>
Hi Mark,
On 20 October 2016 at 23:32, Mark Rutland <mark.rutland@arm.com> wrote:
> On Thu, Sep 29, 2016 at 02:17:11AM +0800, fu.wei at linaro.org wrote:
>> static void arch_timer_banner(unsigned type)
>> {
>> - pr_info("Architected %s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",
>> - type & ARCH_CP15_TIMER ? "cp15" : "",
>> - type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? " and " : "",
>> - type & ARCH_MEM_TIMER ? "mmio" : "",
>> - (unsigned long)arch_timer_rate / 1000000,
>> - (unsigned long)(arch_timer_rate / 10000) % 100,
>> - type & ARCH_CP15_TIMER ?
>> - (arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :
>> - "",
>> - type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? "/" : "",
>> - type & ARCH_MEM_TIMER ?
>> - arch_timer_mem_use_virtual ? "virt" : "phys" :
>> - "");
>> + pr_info("%s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",
>> + type & ARCH_CP15_TIMER ? "cp15" : "",
>> + type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? " and " : "",
>> + type & ARCH_MEM_TIMER ? "mmio" : "",
>> + (unsigned long)arch_timer_rate / 1000000,
>> + (unsigned long)(arch_timer_rate / 10000) % 100,
>> + type & ARCH_CP15_TIMER ?
>> + (arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :
>> + "",
> Please restore the additional indent on this line...
>
>> + type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? "/" : "",
>> + type & ARCH_MEM_TIMER ?
>> + arch_timer_mem_use_virtual ? "virt" : "phys" :
>> + "");
>
> ... and these two.
>
> No matter what checkpatch says, I prefer the code that way so as to keep
> the ternary clear.
yes, NP, I have fixed it :-)
>
> [...]
>
>> @@ -768,7 +769,7 @@ static int __init arch_timer_init(void)
>> return ret;
>>
>> arch_timer_kvm_info.virtual_irq = arch_timer_ppi[VIRT_PPI];
>> -
>> +
>
> Please mention the whitespace fixup in the commit message. It's
> surprising otherwise.
OK, added this message.
>
> With all that:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
Great thanks :-)
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ 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