* [PATCH v3 1/9] clk: sunxi-ng: Rename the internal structures
From: Maxime Ripard @ 2016-10-03 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161003080913.24197-1-maxime.ripard@free-electrons.com>
Rename the structures meant to be embedded in other structures to make it
consistent with the mux structure name
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/clk/sunxi-ng/ccu_div.h | 6 +++---
drivers/clk/sunxi-ng/ccu_frac.c | 12 ++++++------
drivers/clk/sunxi-ng/ccu_frac.h | 14 +++++++-------
drivers/clk/sunxi-ng/ccu_mp.h | 4 ++--
drivers/clk/sunxi-ng/ccu_mult.h | 4 ++--
drivers/clk/sunxi-ng/ccu_nk.h | 4 ++--
drivers/clk/sunxi-ng/ccu_nkm.h | 6 +++---
drivers/clk/sunxi-ng/ccu_nkmp.h | 8 ++++----
drivers/clk/sunxi-ng/ccu_nm.h | 6 +++---
9 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu_div.h b/drivers/clk/sunxi-ng/ccu_div.h
index 34c338832c0d..06540f7cf41c 100644
--- a/drivers/clk/sunxi-ng/ccu_div.h
+++ b/drivers/clk/sunxi-ng/ccu_div.h
@@ -20,7 +20,7 @@
#include "ccu_mux.h"
/**
- * struct _ccu_div - Internal divider description
+ * struct ccu_div_internal - Internal divider description
* @shift: Bit offset of the divider in its register
* @width: Width of the divider field in its register
* @max: Maximum value allowed for that divider. This is the
@@ -36,7 +36,7 @@
* It is basically a wrapper around the clk_divider functions
* arguments.
*/
-struct _ccu_div {
+struct ccu_div_internal {
u8 shift;
u8 width;
@@ -78,7 +78,7 @@ struct _ccu_div {
struct ccu_div {
u32 enable;
- struct _ccu_div div;
+ struct ccu_div_internal div;
struct ccu_mux_internal mux;
struct ccu_common common;
};
diff --git a/drivers/clk/sunxi-ng/ccu_frac.c b/drivers/clk/sunxi-ng/ccu_frac.c
index 5c4b10cd15b5..8b5eb7756bf7 100644
--- a/drivers/clk/sunxi-ng/ccu_frac.c
+++ b/drivers/clk/sunxi-ng/ccu_frac.c
@@ -14,7 +14,7 @@
#include "ccu_frac.h"
bool ccu_frac_helper_is_enabled(struct ccu_common *common,
- struct _ccu_frac *cf)
+ struct ccu_frac_internal *cf)
{
if (!(common->features & CCU_FEATURE_FRACTIONAL))
return false;
@@ -23,7 +23,7 @@ bool ccu_frac_helper_is_enabled(struct ccu_common *common,
}
void ccu_frac_helper_enable(struct ccu_common *common,
- struct _ccu_frac *cf)
+ struct ccu_frac_internal *cf)
{
unsigned long flags;
u32 reg;
@@ -38,7 +38,7 @@ void ccu_frac_helper_enable(struct ccu_common *common,
}
void ccu_frac_helper_disable(struct ccu_common *common,
- struct _ccu_frac *cf)
+ struct ccu_frac_internal *cf)
{
unsigned long flags;
u32 reg;
@@ -53,7 +53,7 @@ void ccu_frac_helper_disable(struct ccu_common *common,
}
bool ccu_frac_helper_has_rate(struct ccu_common *common,
- struct _ccu_frac *cf,
+ struct ccu_frac_internal *cf,
unsigned long rate)
{
if (!(common->features & CCU_FEATURE_FRACTIONAL))
@@ -63,7 +63,7 @@ bool ccu_frac_helper_has_rate(struct ccu_common *common,
}
unsigned long ccu_frac_helper_read_rate(struct ccu_common *common,
- struct _ccu_frac *cf)
+ struct ccu_frac_internal *cf)
{
u32 reg;
@@ -84,7 +84,7 @@ unsigned long ccu_frac_helper_read_rate(struct ccu_common *common,
}
int ccu_frac_helper_set_rate(struct ccu_common *common,
- struct _ccu_frac *cf,
+ struct ccu_frac_internal *cf,
unsigned long rate)
{
unsigned long flags;
diff --git a/drivers/clk/sunxi-ng/ccu_frac.h b/drivers/clk/sunxi-ng/ccu_frac.h
index e4c670b1cdfe..7b1ee380156f 100644
--- a/drivers/clk/sunxi-ng/ccu_frac.h
+++ b/drivers/clk/sunxi-ng/ccu_frac.h
@@ -18,7 +18,7 @@
#include "ccu_common.h"
-struct _ccu_frac {
+struct ccu_frac_internal {
u32 enable;
u32 select;
@@ -33,21 +33,21 @@ struct _ccu_frac {
}
bool ccu_frac_helper_is_enabled(struct ccu_common *common,
- struct _ccu_frac *cf);
+ struct ccu_frac_internal *cf);
void ccu_frac_helper_enable(struct ccu_common *common,
- struct _ccu_frac *cf);
+ struct ccu_frac_internal *cf);
void ccu_frac_helper_disable(struct ccu_common *common,
- struct _ccu_frac *cf);
+ struct ccu_frac_internal *cf);
bool ccu_frac_helper_has_rate(struct ccu_common *common,
- struct _ccu_frac *cf,
+ struct ccu_frac_internal *cf,
unsigned long rate);
unsigned long ccu_frac_helper_read_rate(struct ccu_common *common,
- struct _ccu_frac *cf);
+ struct ccu_frac_internal *cf);
int ccu_frac_helper_set_rate(struct ccu_common *common,
- struct _ccu_frac *cf,
+ struct ccu_frac_internal *cf,
unsigned long rate);
#endif /* _CCU_FRAC_H_ */
diff --git a/drivers/clk/sunxi-ng/ccu_mp.h b/drivers/clk/sunxi-ng/ccu_mp.h
index edf9215ea8cc..915625e97d98 100644
--- a/drivers/clk/sunxi-ng/ccu_mp.h
+++ b/drivers/clk/sunxi-ng/ccu_mp.h
@@ -29,8 +29,8 @@
struct ccu_mp {
u32 enable;
- struct _ccu_div m;
- struct _ccu_div p;
+ struct ccu_div_internal m;
+ struct ccu_div_internal p;
struct ccu_mux_internal mux;
struct ccu_common common;
};
diff --git a/drivers/clk/sunxi-ng/ccu_mult.h b/drivers/clk/sunxi-ng/ccu_mult.h
index 5d2c8dc14073..113780b7558e 100644
--- a/drivers/clk/sunxi-ng/ccu_mult.h
+++ b/drivers/clk/sunxi-ng/ccu_mult.h
@@ -4,7 +4,7 @@
#include "ccu_common.h"
#include "ccu_mux.h"
-struct _ccu_mult {
+struct ccu_mult_internal {
u8 shift;
u8 width;
};
@@ -18,7 +18,7 @@ struct _ccu_mult {
struct ccu_mult {
u32 enable;
- struct _ccu_mult mult;
+ struct ccu_mult_internal mult;
struct ccu_mux_internal mux;
struct ccu_common common;
};
diff --git a/drivers/clk/sunxi-ng/ccu_nk.h b/drivers/clk/sunxi-ng/ccu_nk.h
index 4b52da0c29fe..437836b80696 100644
--- a/drivers/clk/sunxi-ng/ccu_nk.h
+++ b/drivers/clk/sunxi-ng/ccu_nk.h
@@ -30,8 +30,8 @@ struct ccu_nk {
u32 enable;
u32 lock;
- struct _ccu_mult n;
- struct _ccu_mult k;
+ struct ccu_mult_internal n;
+ struct ccu_mult_internal k;
unsigned int fixed_post_div;
diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
index 35493fddd8ab..34580894f4d1 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.h
+++ b/drivers/clk/sunxi-ng/ccu_nkm.h
@@ -29,9 +29,9 @@ struct ccu_nkm {
u32 enable;
u32 lock;
- struct _ccu_mult n;
- struct _ccu_mult k;
- struct _ccu_div m;
+ struct ccu_mult_internal n;
+ struct ccu_mult_internal k;
+ struct ccu_div_internal m;
struct ccu_mux_internal mux;
struct ccu_common common;
diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.h b/drivers/clk/sunxi-ng/ccu_nkmp.h
index 5adb0c92a614..a82facbc6144 100644
--- a/drivers/clk/sunxi-ng/ccu_nkmp.h
+++ b/drivers/clk/sunxi-ng/ccu_nkmp.h
@@ -29,10 +29,10 @@ struct ccu_nkmp {
u32 enable;
u32 lock;
- struct _ccu_mult n;
- struct _ccu_mult k;
- struct _ccu_div m;
- struct _ccu_div p;
+ struct ccu_mult_internal n;
+ struct ccu_mult_internal k;
+ struct ccu_div_internal m;
+ struct ccu_div_internal p;
struct ccu_common common;
};
diff --git a/drivers/clk/sunxi-ng/ccu_nm.h b/drivers/clk/sunxi-ng/ccu_nm.h
index 0b7bcd33a2df..e87fd186da78 100644
--- a/drivers/clk/sunxi-ng/ccu_nm.h
+++ b/drivers/clk/sunxi-ng/ccu_nm.h
@@ -30,9 +30,9 @@ struct ccu_nm {
u32 enable;
u32 lock;
- struct _ccu_mult n;
- struct _ccu_div m;
- struct _ccu_frac frac;
+ struct ccu_mult_internal n;
+ struct ccu_div_internal m;
+ struct ccu_frac_internal frac;
struct ccu_common common;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v3 0/9] arm64: Allwinner A64 support based on sunxi-ng
From: Maxime Ripard @ 2016-10-03 8:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
As it was in the first iteration, this is the A64 support based on the
new sunxi-ng clock framework.
The support for it is quite minimal at the moment, but it should be
fairly easy to add new devices, as most of the design is shared with
older SoCs.
Let me know what you think,
Maxime
Changes from v2:
- Added pull-ups on the Pine64 i2c bus
- Removed the PMU since it doesn't work
- Refactored the sunxi-ng framework to deal with the specifities of
the A64 CCU, especially in terms of minimum factors.
- Fixed a few things in the CCU driver: added CLK_SET_RATE PARENT
flags, fixed some mux width, etc.
- Converted the CCU driver to a platform driver
- Added the DRAM reset line
- Added IDs for the USB muxes (even though we're not using them yet)
Changes from v1:
- Split the A64 CCU support out of the H3 driver
- Added the PMU support
- Removed the clocks node
- Rebased on top of current sunxi/clk-for-4.9 branch
Andre Przywara (3):
arm64: dts: add Allwinner A64 SoC .dtsi
Documentation: devicetree: add vendor prefix for Pine64
arm64: dts: add Pine64 support
Maxime Ripard (6):
clk: sunxi-ng: Rename the internal structures
clk: sunxi-ng: Remove the use of rational computations
clk: sunxi-ng: Finish to convert to structures for arguments
clk: sunxi-ng: Add minimums for all the relevant structures and clocks
clk: sunxi-ng: Implement minimum for multipliers
clk: sunxi-ng: Add A64 clocks
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
.../devicetree/bindings/clock/sunxi-ccu.txt | 1 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
MAINTAINERS | 1 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/allwinner/Makefile | 5 +
.../boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 50 ++
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 74 ++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 263 ++++++
drivers/clk/sunxi-ng/Kconfig | 14 +-
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 918 +++++++++++++++++++++
drivers/clk/sunxi-ng/ccu-sun50i-a64.h | 72 ++
drivers/clk/sunxi-ng/ccu_div.h | 6 +-
drivers/clk/sunxi-ng/ccu_frac.c | 12 +-
drivers/clk/sunxi-ng/ccu_frac.h | 14 +-
drivers/clk/sunxi-ng/ccu_mp.h | 4 +-
drivers/clk/sunxi-ng/ccu_mult.c | 33 +-
drivers/clk/sunxi-ng/ccu_mult.h | 17 +-
drivers/clk/sunxi-ng/ccu_nk.c | 43 +-
drivers/clk/sunxi-ng/ccu_nk.h | 4 +-
drivers/clk/sunxi-ng/ccu_nkm.c | 45 +-
drivers/clk/sunxi-ng/ccu_nkm.h | 6 +-
drivers/clk/sunxi-ng/ccu_nkmp.c | 55 +-
drivers/clk/sunxi-ng/ccu_nkmp.h | 8 +-
drivers/clk/sunxi-ng/ccu_nm.c | 58 +-
drivers/clk/sunxi-ng/ccu_nm.h | 6 +-
include/dt-bindings/clock/sun50i-a64-ccu.h | 134 +++
include/dt-bindings/reset/sun50i-a64-ccu.h | 98 +++
29 files changed, 1824 insertions(+), 121 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a64.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a64.h
create mode 100644 include/dt-bindings/clock/sun50i-a64-ccu.h
create mode 100644 include/dt-bindings/reset/sun50i-a64-ccu.h
--
2.9.3
^ permalink raw reply
* [1/3] Revert "ACPI,PCI,IRQ: reduce static IRQ array size to 16"
From: Jonathan Liu @ 2016-10-03 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bf16b077-603f-bc7e-cd7b-bf006242f781@codeaurora.org>
On 3 October 2016 at 12:07, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 10/2/2016 7:40 AM, Jonathan Liu wrote:
>> This series fixes one or more network adapters in VirtualBox not
>> working with Linux 32-bit x86 guest if I have 4 network adapters
>> enabled. The following message no longer appears in the kernel log:
>> ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
>>
>> Tested-by: Jonathan Liu <net147@gmail.com>
>
> Thanks for the test. I didn't realize that VirtualBox was broken too.
I am running VirtualBox on Windows 7 64-bit host with Linux guest. The
problem occurs in the Linux guest.
>
> So far I got some random test results in the mail list that something
> is broken. I hope to hear more that we close the issue for some time
> now.
>
> The IRQ stuff got broken three times already. Hopefully, this will be
> the seal.
^ permalink raw reply
* [PATCH v26 0/7] arm64: add kdump support
From: Manish Jaggi @ 2016-10-03 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160907042908.6232-1-takahiro.akashi@linaro.org>
Hi Akashi,
On 09/07/2016 09:59 AM, AKASHI Takahiro wrote:
> v26-specific note: After a comment from Rob[0], an idea of adding
> "linux,usable-memory-range" was dropped. Instead, an existing
> "reserved-memory" node will be used to limit usable memory ranges
> on crash dump kernel.
> This works not only on UEFI/ACPI systems but also on DT-only systems,
> but if he really insists on using DT-specific "usable-memory" property,
> I will post additional patches for kexec-tools. Those would be
> redundant, though.
> Even in that case, the kernel will not have to be changed.
>
> This patch series adds kdump support on arm64.
> There are some prerequisite patches [1],[2].
>
> To load a crash-dump kernel to the systems, a series of patches to
> kexec-tools, which have not yet been merged upstream, are needed.
> Please always use my latest kdump patches, v3 [3].
>
> To examine vmcore (/proc/vmcore) on a crash-dump kernel, you can use
> - crash utility (coming v7.1.6 or later) [4]
> (Necessary patches have already been queued in the master.)
>
>
> [0] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/452582.html
> [1] "arm64: mark reserved memblock regions explicitly in iomem"
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/450433.html
> [2] "efi: arm64: treat regions with WT/WC set but WB cleared as memory"
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/451491.html
> [3] T.B.D.
> [4] https://github.com/crash-utility/crash.git
>
With the v26 kdump and v3 kexec-tools and top of tree crash.git, below are the tests done
Attached is a patch in crash.git (symbols.c) to make crash utility work on my setup.
Can you please have a look and provide your comments.
To generate a panic, i have a kernel module which on init calls panic.
Observations:
1.1. Dump capture kernel shows different memory map.
---------------------------------------------------
In dump capture kernel /proc/meminfo and /proc/iomem differ
root at arm64:/home/ubuntu/CODE/crash#
MemTotal: 65882432 kB
MemFree: 65507136 kB
MemAvailable: 60373632 kB
Buffers: 29248 kB
Cached: 46720 kB
SwapCached: 0 kB
Active: 63872 kB
Inactive: 19776 kB
Active(anon): 8256 kB
Inactive(anon): 7616 kB
First kernel is booted with mem=2G crashkernel=1G command line option.
While the system has 64G memory.
root at arm64:/home/ubuntu/CODE/crash# cat /proc/iomem
41400000-fffeffff : System RAM
41480000-420cffff : Kernel code
42490000-4278ffff : Kernel data
ffff0000-ffffffff : reserved
100000000-ffaa7ffff : System RAM
ffaa80000-ffaabffff : reserved
ffaac0000-fffa6ffff : System RAM
fffa70000-fffacffff : reserved
fffad0000-fffffffff : System RAM
1.2 Live crash dump fails with error
--------------------------------------
$crash vmlinux
crash 7.1.5++
Copyright (C) 2002-2016 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "aarch64-unknown-linux-gnu"...
crash: read error: kernel virtual address: ffff800ffffffcc0 type: "pglist node_id"
Observation 2
------------
If saved vmcore file is used
$crash vmlinux vmcore_saved
Got the below error.
please wait... (gathering module symbol data)crash: malloc.c:2846: mremap_chunk: Assertion `((size + offset) & (_rtld_global_ro._dl_pagesize - 1)) == 0' failed.
Aborted
Experiment 3
------------
If crash.git is modified with a hack patch in symbols.c. Crash utility works fine log, bt commands work.
-------------------
Patch: symbols.c
git diff symbols.c
diff --git a/symbols.c b/symbols.c
index 13282f4..f7c6cac 100644
--- a/symbols.c
+++ b/symbols.c
@@ -2160,6 +2160,7 @@ store_module_kallsyms_v2(struct load_module *lm, int start
FREEBUF(module_buf);
return 0;
}
+ lm->mod_init_size = 0;
if (lm->mod_init_size > 0) {
module_buf_init = GETBUF(lm->mod_init_size);
------------------
$ crash vmlinux vmcore_saved
KERNEL: /home/ubuntu/CODE/linux/vmlinux
DUMPFILE: vm
CPUS: 48 [OFFLINE: 46]
DATE: Mon Oct 3 00:11:47 2016
UPTIME: 00:02:41
LOAD AVERAGE: 0.36, 0.14, 0.05
TASKS: 171
NODENAME: arm64
RELEASE: 4.8.0-rc3-00044-g070a615-dirty
VERSION: #63 SMP Sat Oct 1 01:39:45 PDT 2016
MACHINE: aarch64 (unknown Mhz)
MEMORY: 2 GB
PANIC: "Kernel panic - not syncing: crash module starting"
PID: 958
COMMAND: "insmod"
TASK: ffff800007859300 [THREAD_INFO: ffff80000c940000]
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash> bt
PID: 958 TASK: ffff800007859300 CPU: 0 COMMAND: "insmod"
#0 [ffff80000c943980] __crash_kexec at ffff000008144fe8
#1 [ffff80000c943ae0] panic at ffff0000081ae704
#2 [ffff80000c943ba0] init_module at ffff000000900014 [crash]
#3 [ffff80000c943bb0] do_one_initcall at ffff000008083bb4
#4 [ffff80000c943c40] do_init_module at ffff0000081af6f0
#5 [ffff80000c943c70] load_module at ffff000008140b7c
#6 [ffff80000c943e10] sys_finit_module at ffff000008141634
#7 [ffff80000c943ed0] el0_svc_naked at ffff0000080833ec
PC: 00000003 LR: ffffaca050a0 SP: ffffaca865a0 PSTATE: 00000111
X12: ffffac941a5c X11: 00000080 X10: 00000004 X9: 00000030
X8: ffffffff X7: fefefefefefeff40 X6: 00000111 X5: 00000001
X4: 00000001 X3: 0002ed61 X2: 00000000 X1: 00000003
X0: 00000000
crash>
---
Thanks,
manish
^ permalink raw reply related
* [GIT PULL 1/3] ARM: soc: exynos: Drivers for v4.9
From: Krzysztof Kozlowski @ 2016-10-03 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgSu=bfVwWYkEG0+eDKBxh_zqSM0uxFAq3Y3X-O0vLGKQ@mail.gmail.com>
On Sun, Oct 02, 2016 at 05:25:07PM -0700, Olof Johansson wrote:
> On Mon, Sep 19, 2016 at 8:53 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Mon, Sep 19, 2016 at 05:02:40PM +0200, Arnd Bergmann wrote:
> >> On Sunday, September 18, 2016 6:39:46 PM CEST Krzysztof Kozlowski wrote:
> >> > Samsung drivers/soc update for v4.9:
> >> > 1. Allow compile testing of exynos-mct clocksource driver on ARM64.
> >> > 2. Document Exynos5433 PMU compatible (already used by clkout driver and more
> >> > will be coming soon).
> >>
> >> Pulled into next/drivers, thanks
> >>
> >> Just for my understanding: why do we need the exynos-mct driver on ARM64
> >> but not the delay-timer portion of it?
> >
> > I think we want all of it but Doug's optimization 3252a646aa2c
> > ("clocksource: exynos_mct: Only use 32-bits where possible") is not
> > ARM64 friendly. One way of dealing with it would be to prepare two
> > versions of exynos4_read_current_timer(). One reading only lower 32-bit
> > value for ARMv7 and second (slow) reading lower and upper for ARMv8.
> >
> >>
> >> Is there an advantage in using MCT over the architected timer on these
> >> chips? If so, should we also have a way to use it as the delay timer?
> >
> > No, there is no real advantage... except that the SoC has some
> > interesting "characteristics"... The timers are tightly coupled. Very
> > tightly. I spent a lot of time and failed to boot my ARMv8 board without
> > some MCT magic.
>
> What kind of magic is that?
Most notably: the arch timer starts when MCT forward running counter
starts. Without kicking MCT, the arch timer seems to be frozen.
> I can understand that needing the MCT for
> some system-level timer functionality might be true (wakeups, etc),
> but for system timesource avoiding the MMIO timer and using the arch
> ones is a substantial performance improvement for gettimeofday() and
> friends.
>
> There was extensive discussion last year over using arch timers on
> 5420/5422, and it fizzled out with vague comments about something not
> working right between A15/A7 on b.L. hardware. I'm presuming whatever
> implementation details of that SoC has since been fixed on later chips
> (including v8). Any chance you can confirm? It'd be very nice to leave
> MCT behind on v8 as a system time source.
Unfortunately, I cannot confirm this, at least on Exynos5433 (ARMv8). I
played with arch and MCT timers on it and failed to get the
arch-timer-only setup working. I did not have access to newer Exynos
designs (Exynos 7) so I do not know how it works there.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 6/6] ARM: da850: adjust memory settings for tilcdc
From: Peter Ujfalusi @ 2016-10-03 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <948c3f9e-f11b-092c-e002-e2ef4436197f@ti.com>
On 10/01/16 12:24, Sekhar Nori wrote:
>> That's good to hear, but I think the priorities should be set:
>> LCDC and EDMA30TC1 to highest priority
>> EDMA30TC0 to priority 2
>>
>> The 0TC0 is used by MMC and if you want to play a video you might need the
>> servicing TC to be higher priority then other masters.
>>
>> If audio playback would trigger sync losts in lcdc then we might need to move
>> 0TC1 to priority 1.
>>
>> I agree that LCDC priority needs to be higher, but I do wonder why the default
>> (5) is not working and if it is not working why it is 5...
>>
>> My guess is that the change in the PBBPR register is the one actually helping
>> here.
>
> Good point, Peter. If you are booting off NFS and not playing any audio,
> then there is pretty much no EDMA generated traffic on the interconnect.
Yes, this is my understanding as well.
> I would guess too that its the PBBPR setting that is making a
> difference. The EDMA vs LCDC priority adjustment might be needed in
> particular situations too, but specific experiments should be done to
> narrow down on that being the cause.
True, we can use some conservative values for the priority, but the PBBPR
register for sure needs to be updated.
> In any case, to configure the PBBR, you will have to introduce a driver
> for it in drivers/memory. Then you can set it up per board using a DT
> parameter.
and we can reuse the introduced bindings for am335x and OMAP1/2 as well. On
OMAP the legacy DMA API provided a call to raise the priority of the sDMA in
EMIF :o That needs to be removed and replaced.
--
P?ter
^ permalink raw reply
* [PATCH v3 2/2] ARM64: dts: bcm: Use a symlink to R-Pi dtsi files from arch=arm
From: Olof Johansson @ 2016-10-03 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1471516926-11466-2-git-send-email-ijc@hellion.org.uk>
On Thu, Aug 18, 2016 at 11:42:06AM +0100, Ian Campbell wrote:
> The ../../../arm... style cross-references added by commit 9d56c22a7861
> ("ARM: bcm2835: Add devicetree for the Raspberry Pi 3.") do not work in the
> context of the split device-tree repository[0] (where the directory
> structure differs). As with commit 8ee57b8182c4 ("ARM64: dts: vexpress: Use
> a symlink to vexpress-v2m-rs1.dtsi from arch=arm") use symlinks instead.
>
> [0] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
>
> Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Lee Jones <lee@kernel.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-rpi-kernel at lists.infradead.org
> Cc: arm at kernel.org
> ---
> v2: No more need for skeleton.dtsi since this was cleaned up in the previous
> patch
> v3: Collected tags
Hi,
I still think this is fundamentally the wrong approach. We shouldn't have
created these file links in the first place.
I'd rather have something like this in our tree:
arch/arm64/boot/dts/include/arm -> ../../../../arm/boot/dts
arch/arm64/boot/dts/include/arm64 -> ../..
arch/arm/boot/dts/include/arm64 -> ../../../../arm64/boot/dts
arch/arm/boot/dts/include/arm -> ../..
That way you can include by using <arm/bcm2835-rpi.dtsi> instead.
You'll populate another (or the same) directory with links as appropriate
in your out-of-tree version of the DT contents.
No more symlinked files, and still a clear way of showing that you're
referencing contents out of the other architecture.
Considerably cleaner, isn't it?
-Olof
^ permalink raw reply
* [PATCH V3 2/2] PCI: handle CRS returned by device after FLR
From: Sinan Kaya @ 2016-10-03 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475473021-14251-1-git-send-email-okaya@codeaurora.org>
An endpoint is allowed to issue CRS following an FLR request to indicate
that it is not ready to accept new requests. Changing the polling mechanism
in FLR wait function to go read the vendor ID instead of the command/status
register. A CRS indication will only be given if the address to be read is
vendor ID.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index c8749b9..7580b00 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3725,7 +3725,8 @@ static void pci_flr_wait(struct pci_dev *dev)
do {
msleep(100);
- pci_read_config_dword(dev, PCI_COMMAND, &id);
+ pci_bus_read_dev_vendor_id(dev->bus, dev->devfn, &id,
+ 60 * 1000);
} while (i++ < 10 && id == ~0);
if (id == ~0)
--
1.9.1
^ permalink raw reply related
* [PATCH V3 1/2] PCI: add CRS support to error handling path
From: Sinan Kaya @ 2016-10-03 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475473021-14251-1-git-send-email-okaya@codeaurora.org>
The PCIE spec allows an endpoint device to extend the initialization time
beyond 1 second by issuing Configuration Request Retry Status (CRS) for a
vendor ID read request.
This basically means "I'm busy now, please call me back later".
There are two moving parts to CRS support from the SW perspective. One part
is to determine if CRS is supported or not. The second part is to set the
CRS visibility register.
As part of the probe, the Linux kernel sets the above two conditions in
pci_enable_crs function. The kernel is also honoring the returned CRS in
pci_bus_read_dev_vendor_id function if supported. The function will poll up
to specified amount of time while endpoint is returning CRS response.
The PCIe spec also allows CRS to be issued during cold, warm, hot and FLR
resets.
The hot reset is initiated by starting a secondary bus reset. A bus/device
restore follows the reset. This patch is adding vendor ID read into dev
restore function to validate that the device is accessible before writing
the register contents. If the device issues CRS, the code might poll up
to 60 seconds.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/pci.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index aab9d51..c8749b9 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4020,6 +4020,12 @@ static void pci_dev_save_and_disable(struct pci_dev *dev)
static void pci_dev_restore(struct pci_dev *dev)
{
+ u32 l;
+
+ /* see if the device is accessible first */
+ if (!pci_bus_read_dev_vendor_id(dev->bus, dev->devfn, &l, 60 * 1000))
+ return;
+
pci_restore_state(dev);
pci_reset_notify(dev, false);
}
--
1.9.1
^ permalink raw reply related
* [PATCH V3 0/2] PCI: add CRS support after hot reset and FLR
From: Sinan Kaya @ 2016-10-03 5:36 UTC (permalink / raw)
To: linux-arm-kernel
The PCIE spec allows an endpoint device to extend the initialization time
beyond 1 second by issuing Configuration Request Retry Status (CRS) for a
vendor ID read request.
This basically means "I'm busy now, please call me back later".
There are two moving parts to CRS support from the SW perspective. One part
is to determine if CRS is supported or not. The second part is to set the
CRS visibility register.
As part of the probe, the Linux kernel sets the above two conditions in
pci_enable_crs function. The kernel is also honoring the returned CRS in
pci_bus_read_dev_vendor_id function if supported. The function will poll up
to specified amount of time while endpoint is returning CRS response.
The PCIe spec also allows CRS to be issued during cold, warm, hot and FLR
resets.
The hot reset is initiated by starting a secondary bus reset. A bus/device
restore follows the reset. This patch is adding vendor ID read into dev
restore function to validate that the device is accessible before writing
the register contents. If the device issues CRS, the code might poll up
to 60 seconds.
An endpoint is allowed to issue CRS following an FLR request to indicate
that it is not ready to accept new requests. Changing the polling mechanism
in FLR wait function to go read the vendor ID instead of the command/status
register. A CRS indication will only be given if the address to be read is
vendor ID.
v3:
* dropped parent_bus_reset change and IB/hfi1 changes as both of them work
only when there is a single device on the bus and reset is for the device
in the bus.
* dropper AER changes as AER driver broadcasts error to the endpoint device
driver which eventually cause endpoint driver to be reprobed after fatal
error.
* moved vendor id read into the pci_dev_restore function as this is the
* first
attempt to contact the endpoint after a reset.
v2:
http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1233472.html
* IB/hfi1 via pci_reset_bridge_secondary_bus
* PCI/AER via pci_reset_bridge_secondary_bus
* PCI: dev_reset via parent bus reset
* use walk_bus for vendor id reads since the lock is no longer held.
v1:
http://www.spinics.net/lists/linux-pci/msg53596.html
* initial implementation
Sinan Kaya (2):
PCI: add CRS support to error handling path
PCI: handle CRS returned by device after FLR
drivers/pci/pci.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--
1.9.1
^ permalink raw reply
* [GIT PULL 1/4] Broadcom devicetree changes for 4.9 (part 2)
From: Olof Johansson @ 2016-10-03 5:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475263395-27653-1-git-send-email-f.fainelli@gmail.com>
On Fri, Sep 30, 2016 at 12:23:12PM -0700, Florian Fainelli wrote:
> The following changes since commit 7260ecd22baa3c62ef6efaf59e7de53f4c8df800:
>
> Merge tag 'bcm2835-dt-next-2016-08-29' into devicetree/next (2016-08-30 20:02:04 -0700)
>
> are available in the git repository at:
>
> http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.9/devicetree-part2
>
> for you to fetch changes up to ef3bc318adeb15b38688df6a583bafea2befce43:
>
> ARM: BCM5301X: Add DT for Luxul XWR-3100 (2016-09-30 11:58:31 -0700)
>
> ----------------------------------------------------------------
> This pull request contains Broadcom ARM-based SoCs Device Tree changes for 4.9,
> please pull the following:
>
> - Rafal adds support for the Netgear R8500 routers, adds basic support
> for the Tenda AC9 router which uses the new BCM53573 SoC (single core Cortex
> A7). He also enables the UART on the Netgear R8000 and restructures the
> include files a bit for the BCM47094 SoC, finally he adds USB 3.0 PHY nodes
> which enables USB 3.0 on BCM5301X devices that support it
>
> - Kamal adds support for the QSPI controller on the Northstar Plus SoCs and updates
> the bcm958625k reference board to have it enabled
>
> - Dan adds support for the Luxul XAP-1510 and XWR-3100 devices
Hi Florian,
Given the timing of these pull requests, we'll have to hold them off
for 4.10. The defconfig changes can be considered for -rc2, but the
DT contents should wait.
Please send a fresh pull request once 4.9-rc1 is out.
Thanks,
-Olof
^ permalink raw reply
* [PATCH] bus: qcom-ebi2: depend on HAS_IOMEM
From: Olof Johansson @ 2016-10-03 5:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475445239-25006-1-git-send-email-linus.walleij@linaro.org>
On Sun, Oct 02, 2016 at 11:53:59PM +0200, Linus Walleij wrote:
> After being asked to not depend on ARCH_QCOM* or similar,
> unsurprisingly compilation fails on UM as it has no I/O
> memory:
>
> drivers/built-in.o: In function `qcom_ebi2_probe':
> >> drivers/bus/qcom-ebi2.c:333: undefined reference to
> `devm_ioremap_resource'
>
> Fix this by letting the Kconfig atleast depend on HAS_IOMEM.
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Andy Gross <andy.gross@linaro.org>
> Cc: linux-arm-msm at vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ARM SoC maintainers: please apply this directly on the offending
> branch, or line it up for v4.9 fixes.
Applied to next/drivers. A Fixes: tag could have been nice, but it was
easy to find where the offender was.
-Olof
^ permalink raw reply
* [PATCH] net: ethernet: mediatek: mark symbols static where possible
From: David Miller @ 2016-10-03 5:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475221730-18773-1-git-send-email-baoyou.xie@linaro.org>
From: Baoyou Xie <baoyou.xie@linaro.org>
Date: Fri, 30 Sep 2016 15:48:50 +0800
> We get 2 warnings when building kernel with W=1:
> drivers/net/ethernet/mediatek/mtk_eth_soc.c:2041:5: warning: no previous prototype for 'mtk_get_link_ksettings' [-Wmissing-prototypes]
> drivers/net/ethernet/mediatek/mtk_eth_soc.c:2052:5: warning: no previous prototype for 'mtk_set_link_ksettings' [-Wmissing-prototypes]
>
> In fact, these functions are only used in the file in which they are
> declared and don't need a declaration, but can be made static.
> So this patch marks these functions with 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Applied, thanks.
^ permalink raw reply
* [PATCH] arm64: Enable HIBERNATION in defconfig
From: Olof Johansson @ 2016-10-03 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915100231.GG2492@e104818-lin.cambridge.arm.com>
Hi,
On Thu, Sep 15, 2016 at 11:02:31AM +0100, Catalin Marinas wrote:
> On Thu, Sep 15, 2016 at 10:42:14AM +0100, Catalin Marinas wrote:
> > This patch adds CONFIG_HIBERNATION to the arm64 defconfig.
> >
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > ---
> > arch/arm64/configs/defconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > index eadf4855ad2d..91a7592029e3 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -80,6 +80,7 @@ CONFIG_KEXEC=y
> > # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
> > CONFIG_COMPAT=y
> > CONFIG_CPU_IDLE=y
> > +CONFIG_HIBERNATION=y
> > CONFIG_ARM_CPUIDLE=y
> > CONFIG_CPU_FREQ=y
> > CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
>
> Or maybe it could go through arm-soc as it seems Arnd has picked up a
> few other defconfig patches.
When we just get a cc of a reply to a patch, it's usually pretty error prone
whether we end up applying it. Which happened here, I just came across this
when making a final sweep.
Yes, in general we tend to have more changes to the defconfig, so it's
appreciated to get these sent our way.
Given timing, resend after -rc1? We should be OK with applying it for 4.9
still around that time.
-Olof
^ permalink raw reply
* [PATCH] ARM: dts: lpc32xx: add device node for IRAM on-chip memory
From: Olof Johansson @ 2016-10-03 5:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1467931601-25067-1-git-send-email-vz@mleia.com>
On Fri, Jul 08, 2016 at 01:46:41AM +0300, Vladimir Zapolskiy wrote:
> The change adds a new device node with description of generic SRAM
> on-chip memory found on NXP LPC32xx SoC series and connected to AHB
> matrix slave port 3.
>
> Note that NXP LPC3220 SoC has 128KiB of SRAM memory, the other
> LPC3230, LPC3240 and LPC3250 SoCs all have 256KiB SRAM space,
> in the shared DTSI file this change specifies 128KiB SRAM size.
>
> Also it's worth to mention that the SRAM area contains of 64KiB banks,
> 2 banks on LPC3220 and 4 banks on the other SoCs from the series, and
> all SRAM banks but the first one have independent power controls,
> the description of this feature will be added with the introduction of
> power domains for the SoC series.
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> Cc: Sylvain Lemieux <slemieux.tyco@gmail.com>
> ---
>
> Hi Arnd, Olof, Kevin,
>
> please consider to include this NXP LPC32xx DT change directly to
> ARM tree for v4.8.
>
> The SRAM device node will be utilized to store PM resume code
> and to store MAC buffers.
Hi,
When sweeping my inbox looking for patches we had missed, this still showed
up from back in July. I've now applied it, it'll make it into 4.9 (in
next/late). Sorry for missing it earlier.
-Olof
^ permalink raw reply
* [PATCH V4 05/10] dmaengine: qcom_hidma: make pending_tre_count atomic
From: Vinod Koul @ 2016-10-03 3:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e5782331-0dc6-9e0e-777c-372dc88f38e3@codeaurora.org>
On Sat, Oct 01, 2016 at 11:19:43AM -0400, Sinan Kaya wrote:
> On 10/1/2016 2:19 AM, Vinod Koul wrote:
> >> Making it atomic so that it can be updated from multiple contexts.
> > How is it multiple contexts? It's either existing context of MSI, not both!
> >
>
> I was trying to mean multiple processor contexts here. The driver allocates 11
> MSI interrupts. Each MSI interrupt can be assigned to a different CPU. Then,
> we have a race condition for common variables as they share the same interrupt
> handler with a different cause bit.
>
> I will put the above description into the commit text.
Sounds better :)
--
~Vinod
^ permalink raw reply
* [PATCH V4 04/10] dmaengine: qcom_hidma: configure DMA and MSI for OF
From: Vinod Koul @ 2016-10-03 3:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <da6536a3-353e-1364-7074-9d3dcbcc4171@codeaurora.org>
On Sat, Oct 01, 2016 at 11:15:00AM -0400, Sinan Kaya wrote:
> On 10/1/2016 2:17 AM, Vinod Koul wrote:
> > On Wed, Sep 28, 2016 at 10:12:41PM -0400, Sinan Kaya wrote:
> >> Configure the DMA bindings for the device tree based firmware.
> >>
> >> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> >> ---
> >> drivers/dma/qcom/hidma_mgmt.c | 5 ++++-
> >> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
> >> index 82f36e4..e8f6b84 100644
> >> --- a/drivers/dma/qcom/hidma_mgmt.c
> >> +++ b/drivers/dma/qcom/hidma_mgmt.c
> >> @@ -375,8 +375,11 @@ static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
> >> ret = PTR_ERR(new_pdev);
> >> goto out;
> >> }
> >> + of_node_get(child);
> >> + new_pdev->dev.of_node = child;
> >> of_dma_configure(&new_pdev->dev, child);
> >> -
> >> + of_msi_configure(&new_pdev->dev, child);
> >> + of_node_put(child);
> >
> > should this be done unconditionally? Dont we needto call this only for
> > platforms with msi?
>
> I followed the pattern in of_platform_device_create_pdata function. of_msi_configure does
> nothing if MSI is not enabled as irq_find_matching_host returns NULL. It didn't have any
> side effects on my testing either.
yeah later on I did look up the of_msi_configure() and I suspected this. I
think it would be worthwhile to document this assumption here.
Thanks
--
~Vinod
^ permalink raw reply
* [PATCH V2 3/5] PCI: save and restore bus on parent bus reset
From: Sinan Kaya @ 2016-10-03 3:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8dbad89c-2646-773a-e114-42d21ce14cc7@codeaurora.org>
On 9/29/2016 7:50 PM, Sinan Kaya wrote:
> Hi Bjorn,
>
> On 9/29/2016 5:49 PM, Bjorn Helgaas wrote:
>>> + }
>> This pattern of "unlock, do something, relock" needs some
>> justification. In general it's unsafe because the lock is protecting
>> *something*, and you have to assume that something can change as soon
>> as you unlock. Maybe you know it's safe in this situation, and if so,
>> the explanation of why it's safe is what I'm looking for.
>
> Agreed.
>
> The problem is that save and restore routines obtain the lock again and
> they fails as the lock is already held.
>
> The alternative is to change the dev_locks in save and restore to try_lock
> so that it will work if locks were previously obtained or not.
>
>>
>> Also, you're now calling pci_reset_bridge_secondary_bus() with the dev
>> unlocked, where we called it with the dev locked before. Some (but
>> worryingly, not all) of the other pci_reset_bridge_secondary_bus()
>> callers also have the dev locked. I didn't look long enough to figure
>> out if there is a strategy there or if these inconsistencies are
>> latent bugs.
>>
>
> The goal of this routine is to reset the device not the bridge and the code
> will use FLR or others if available. Therefore, it makes perfect sense to
> obtain the device lock while doing this.
>
> The code tries to reset the bus if none of the other resets work. This is
> where the problem is. It destroys the context for other devices.
>
> I can fix get rid of this unlock, do something and then lock again business
> by rewriting the locks in save and restore.
>
> Sinan
>
I looked at the code a little bit more. I missed the fact pci_parent_bus_reset
will only work if there is only PCI device on the bus and that device is the
reset requesting device.
I'll drop this patch as well as the infiniband version for the same reason.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [1/3] Revert "ACPI,PCI,IRQ: reduce static IRQ array size to 16"
From: Sinan Kaya @ 2016-10-03 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANwerB2bhMbkQrGG55Bq-yrFk_DC3Pz2tF0CRrt4ccmrzTmrzQ@mail.gmail.com>
On 10/2/2016 7:40 AM, Jonathan Liu wrote:
> This series fixes one or more network adapters in VirtualBox not
> working with Linux 32-bit x86 guest if I have 4 network adapters
> enabled. The following message no longer appears in the kernel log:
> ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
>
> Tested-by: Jonathan Liu <net147@gmail.com>
Thanks for the test. I didn't realize that VirtualBox was broken too.
So far I got some random test results in the mail list that something
is broken. I hope to hear more that we close the issue for some time
now.
The IRQ stuff got broken three times already. Hopefully, this will be
the seal.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 1/2] remoteproc: Split driver and consumer dereferencing
From: Bjorn Andersson @ 2016-10-03 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In order to be able to lock a rproc driver implementations only when
used by a client, we must differ between the dereference operation of a
client and the implementation itself.
This patch brings no functional change.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Documentation/remoteproc.txt | 6 +++---
drivers/remoteproc/da8xx_remoteproc.c | 4 ++--
drivers/remoteproc/omap_remoteproc.c | 4 ++--
drivers/remoteproc/qcom_q6v5_pil.c | 4 ++--
drivers/remoteproc/qcom_wcnss.c | 4 ++--
drivers/remoteproc/remoteproc_core.c | 21 ++++++++++++++++++---
drivers/remoteproc/st_remoteproc.c | 4 ++--
drivers/remoteproc/ste_modem_rproc.c | 4 ++--
drivers/remoteproc/wkup_m3_rproc.c | 4 ++--
include/linux/remoteproc.h | 1 +
10 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index ef0219fa4bb4..f07597482351 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -101,9 +101,9 @@ int dummy_rproc_example(struct rproc *my_rproc)
On success, the new rproc is returned, and on failure, NULL.
Note: _never_ directly deallocate @rproc, even if it was not registered
- yet. Instead, when you need to unroll rproc_alloc(), use rproc_put().
+ yet. Instead, when you need to unroll rproc_alloc(), use rproc_free().
- void rproc_put(struct rproc *rproc)
+ void rproc_free(struct rproc *rproc)
- Free an rproc handle that was allocated by rproc_alloc.
This function essentially unrolls rproc_alloc(), by decrementing the
rproc's refcount. It doesn't directly free rproc; that would happen
@@ -131,7 +131,7 @@ int dummy_rproc_example(struct rproc *my_rproc)
has completed successfully.
After rproc_del() returns, @rproc is still valid, and its
- last refcount should be decremented by calling rproc_put().
+ last refcount should be decremented by calling rproc_free().
Returns 0 on success and -EINVAL if @rproc isn't valid.
diff --git a/drivers/remoteproc/da8xx_remoteproc.c b/drivers/remoteproc/da8xx_remoteproc.c
index 12823d078e1e..1afac8f31be0 100644
--- a/drivers/remoteproc/da8xx_remoteproc.c
+++ b/drivers/remoteproc/da8xx_remoteproc.c
@@ -261,7 +261,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
return 0;
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -290,7 +290,7 @@ static int da8xx_rproc_remove(struct platform_device *pdev)
disable_irq(drproc->irq);
rproc_del(rproc);
- rproc_put(rproc);
+ rproc_free(rproc);
return 0;
}
diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
index 01e234cb9157..fa63bf2eb885 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -215,7 +215,7 @@ static int omap_rproc_probe(struct platform_device *pdev)
return 0;
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -224,7 +224,7 @@ static int omap_rproc_remove(struct platform_device *pdev)
struct rproc *rproc = platform_get_drvdata(pdev);
rproc_del(rproc);
- rproc_put(rproc);
+ rproc_free(rproc);
return 0;
}
diff --git a/drivers/remoteproc/qcom_q6v5_pil.c b/drivers/remoteproc/qcom_q6v5_pil.c
index 05b04573e87d..2e0caaaa766a 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -875,7 +875,7 @@ static int q6v5_probe(struct platform_device *pdev)
return 0;
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -885,7 +885,7 @@ static int q6v5_remove(struct platform_device *pdev)
struct q6v5 *qproc = platform_get_drvdata(pdev);
rproc_del(qproc->rproc);
- rproc_put(qproc->rproc);
+ rproc_free(qproc->rproc);
return 0;
}
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index 1917de7db91c..f5cedeaafba1 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -585,7 +585,7 @@ static int wcnss_probe(struct platform_device *pdev)
return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -598,7 +598,7 @@ static int wcnss_remove(struct platform_device *pdev)
qcom_smem_state_put(wcnss->state);
rproc_del(wcnss->rproc);
- rproc_put(wcnss->rproc);
+ rproc_free(wcnss->rproc);
return 0;
}
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index 3da566b0d437..ede3af14b9d0 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1307,7 +1307,7 @@ static struct device_type rproc_type = {
* On success the new rproc is returned, and on failure, NULL.
*
* Note: _never_ directly deallocate @rproc, even if it was not registered
- * yet. Instead, when you need to unroll rproc_alloc(), use rproc_put().
+ * yet. Instead, when you need to unroll rproc_alloc(), use rproc_free().
*/
struct rproc *rproc_alloc(struct device *dev, const char *name,
const struct rproc_ops *ops,
@@ -1386,7 +1386,22 @@ struct rproc *rproc_alloc(struct device *dev, const char *name,
EXPORT_SYMBOL(rproc_alloc);
/**
- * rproc_put() - unroll rproc_alloc()
+ * rproc_free() - unroll rproc_alloc()
+ * @rproc: the remote processor handle
+ *
+ * This function decrements the rproc dev refcount.
+ *
+ * If no one holds any reference to rproc anymore, then its refcount would
+ * now drop to zero, and it would be freed.
+ */
+void rproc_free(struct rproc *rproc)
+{
+ put_device(&rproc->dev);
+}
+EXPORT_SYMBOL(rproc_free);
+
+/**
+ * rproc_put() - release rproc reference
* @rproc: the remote processor handle
*
* This function decrements the rproc dev refcount.
@@ -1411,7 +1426,7 @@ EXPORT_SYMBOL(rproc_put);
*
* After rproc_del() returns, @rproc isn't freed yet, because
* of the outstanding reference created by rproc_alloc. To decrement that
- * one last refcount, one still needs to call rproc_put().
+ * one last refcount, one still needs to call rproc_free().
*
* Returns 0 on success and -EINVAL if @rproc isn't valid.
*/
diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
index 6f056caa8a56..ae8963fcc8c8 100644
--- a/drivers/remoteproc/st_remoteproc.c
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -262,7 +262,7 @@ static int st_rproc_probe(struct platform_device *pdev)
return 0;
free_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
return ret;
}
@@ -277,7 +277,7 @@ static int st_rproc_remove(struct platform_device *pdev)
of_reserved_mem_device_release(&pdev->dev);
- rproc_put(rproc);
+ rproc_free(rproc);
return 0;
}
diff --git a/drivers/remoteproc/ste_modem_rproc.c b/drivers/remoteproc/ste_modem_rproc.c
index 53dc17bdd54e..03d69a9a3c5b 100644
--- a/drivers/remoteproc/ste_modem_rproc.c
+++ b/drivers/remoteproc/ste_modem_rproc.c
@@ -257,7 +257,7 @@ static int sproc_drv_remove(struct platform_device *pdev)
rproc_del(sproc->rproc);
dma_free_coherent(sproc->rproc->dev.parent, SPROC_FW_SIZE,
sproc->fw_addr, sproc->fw_dma_addr);
- rproc_put(sproc->rproc);
+ rproc_free(sproc->rproc);
mdev->drv_data = NULL;
@@ -325,7 +325,7 @@ static int sproc_probe(struct platform_device *pdev)
free_rproc:
/* Reset device data upon error */
mdev->drv_data = NULL;
- rproc_put(rproc);
+ rproc_free(rproc);
return err;
}
diff --git a/drivers/remoteproc/wkup_m3_rproc.c b/drivers/remoteproc/wkup_m3_rproc.c
index 3811cb522af3..18175d0331fd 100644
--- a/drivers/remoteproc/wkup_m3_rproc.c
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -208,7 +208,7 @@ static int wkup_m3_rproc_probe(struct platform_device *pdev)
return 0;
err_put_rproc:
- rproc_put(rproc);
+ rproc_free(rproc);
err:
pm_runtime_put_noidle(dev);
pm_runtime_disable(dev);
@@ -220,7 +220,7 @@ static int wkup_m3_rproc_remove(struct platform_device *pdev)
struct rproc *rproc = platform_get_drvdata(pdev);
rproc_del(rproc);
- rproc_put(rproc);
+ rproc_free(rproc);
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index c321eab5054e..930023b7c825 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -493,6 +493,7 @@ struct rproc *rproc_alloc(struct device *dev, const char *name,
void rproc_put(struct rproc *rproc);
int rproc_add(struct rproc *rproc);
int rproc_del(struct rproc *rproc);
+void rproc_free(struct rproc *rproc);
int rproc_boot(struct rproc *rproc);
void rproc_shutdown(struct rproc *rproc);
--
2.5.0
^ permalink raw reply related
* [GIT PULL 1/3] ARM: soc: exynos: Drivers for v4.9
From: Olof Johansson @ 2016-10-03 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919155302.GA4447@kozik-book>
On Mon, Sep 19, 2016 at 8:53 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Mon, Sep 19, 2016 at 05:02:40PM +0200, Arnd Bergmann wrote:
>> On Sunday, September 18, 2016 6:39:46 PM CEST Krzysztof Kozlowski wrote:
>> > Samsung drivers/soc update for v4.9:
>> > 1. Allow compile testing of exynos-mct clocksource driver on ARM64.
>> > 2. Document Exynos5433 PMU compatible (already used by clkout driver and more
>> > will be coming soon).
>>
>> Pulled into next/drivers, thanks
>>
>> Just for my understanding: why do we need the exynos-mct driver on ARM64
>> but not the delay-timer portion of it?
>
> I think we want all of it but Doug's optimization 3252a646aa2c
> ("clocksource: exynos_mct: Only use 32-bits where possible") is not
> ARM64 friendly. One way of dealing with it would be to prepare two
> versions of exynos4_read_current_timer(). One reading only lower 32-bit
> value for ARMv7 and second (slow) reading lower and upper for ARMv8.
>
>>
>> Is there an advantage in using MCT over the architected timer on these
>> chips? If so, should we also have a way to use it as the delay timer?
>
> No, there is no real advantage... except that the SoC has some
> interesting "characteristics"... The timers are tightly coupled. Very
> tightly. I spent a lot of time and failed to boot my ARMv8 board without
> some MCT magic.
What kind of magic is that? I can understand that needing the MCT for
some system-level timer functionality might be true (wakeups, etc),
but for system timesource avoiding the MMIO timer and using the arch
ones is a substantial performance improvement for gettimeofday() and
friends.
There was extensive discussion last year over using arch timers on
5420/5422, and it fizzled out with vague comments about something not
working right between A15/A7 on b.L. hardware. I'm presuming whatever
implementation details of that SoC has since been fixed on later chips
(including v8). Any chance you can confirm? It'd be very nice to leave
MCT behind on v8 as a system time source.
-Olof
^ permalink raw reply
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: Jon Masters @ 2016-10-02 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5869118.UilSPY9Sai@wuerfel>
On 09/14/2016 02:32 PM, Arnd Bergmann wrote:
> On Wednesday, September 14, 2016 10:50:44 PM CEST zhichang.yuan wrote:
>> And there are probably multiple child devices under LPC, the global arm64_extio_ops only can cover one PIO range. It is fortunate only ipmi driver can not support I/O
>> operation registering, serial driver has serial_in/serial_out to
>> be registered. So, only the PIO range for ipmi device is stored
>> in arm64_extio_ops and the indirect-IO
>> works well for ipmi device.
>
> You should not do that in the serial driver, please just use the
> normal 8250 driver that works fine once you handle the entire
> port range.
Just for the record, Arnd has the right idea. There is only one type of
UART permitted by SBSA (PL011). We carved out an exception for a design
that was already in flight and allowed it to be 16550. That other design
was then corrected in future generations to be PL011 as we required it
to be. Then there's the Hip06. I've given feedback elsewhere about the
need for there to be (at most) two types of UART in the wild. This "LPC"
stuff needs cleaning up (feedback given elsewhere already on that), but
we won't be adding a third serial driver into the mix in order to make
it work. There will be standard ARM servers. There will not be the
kinda-sorta-standard. Thanks.
Jon.
^ permalink raw reply
* [PATCH] bus: qcom-ebi2: depend on HAS_IOMEM
From: Linus Walleij @ 2016-10-02 21:53 UTC (permalink / raw)
To: linux-arm-kernel
After being asked to not depend on ARCH_QCOM* or similar,
unsurprisingly compilation fails on UM as it has no I/O
memory:
drivers/built-in.o: In function `qcom_ebi2_probe':
>> drivers/bus/qcom-ebi2.c:333: undefined reference to
`devm_ioremap_resource'
Fix this by letting the Kconfig atleast depend on HAS_IOMEM.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Gross <andy.gross@linaro.org>
Cc: linux-arm-msm at vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ARM SoC maintainers: please apply this directly on the offending
branch, or line it up for v4.9 fixes.
---
drivers/bus/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 5a2d47c71525..7010dcac9328 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -110,6 +110,7 @@ config OMAP_OCP2SCP
config QCOM_EBI2
bool "Qualcomm External Bus Interface 2 (EBI2)"
+ depends on HAS_IOMEM
help
Say y here to enable support for the Qualcomm External Bus
Interface 2, which can be used to connect things like NAND Flash,
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: imx6sx: Fix LCDIF interrupt type
From: Marek Vasut @ 2016-10-02 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5DwZYawBOiXWn0FMy9SgO4+-C=y-CFCQBPSO_mDYk-a6g@mail.gmail.com>
On 10/02/2016 07:43 PM, Fabio Estevam wrote:
> Hi Marek,
Hi!
> On Sun, Oct 2, 2016 at 1:44 PM, Marek Vasut <marex@denx.de> wrote:
>> The LCDIF interrupt should be triggered by the rising edge of the
>> IRQ line because we only want the interrupt to trigger once per each
>> frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted
>> by software, so the previous behavior before this patch, where the
>> interrupt was triggered by level-high status of the IRQ line, caused
>> the interrupt to fire again immediatelly after it was handled, which
>> caused the system to lock up due to the high rate of interrupts.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Lucas Stach <l.stach@pengutronix.de>
>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
>> Cc: Shawn Guo <shawnguo@kernel.org>
>> ---
>> arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
>> index 1a473e8..9526c38 100644
>> --- a/arch/arm/boot/dts/imx6sx.dtsi
>> +++ b/arch/arm/boot/dts/imx6sx.dtsi
>> @@ -1143,7 +1143,7 @@
>> lcdif1: lcdif at 02220000 {
>> compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
>> reg = <0x02220000 0x4000>;
>> - interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
>
> What about mx6ul and mx6sl.dtsi? Shouldn't they be also updated?
Probably, but I don't have the hardware to test MXSFB DRM/KMS driver on
those. I can mail you the necessary patches if you want to try it out,
the latest version is not in the ML yet as there is some DRM
infrastructure work going on.
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx: Fix LCDIF interrupt type
From: Fabio Estevam @ 2016-10-02 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161002164435.5812-1-marex@denx.de>
Hi Marek,
On Sun, Oct 2, 2016 at 1:44 PM, Marek Vasut <marex@denx.de> wrote:
> The LCDIF interrupt should be triggered by the rising edge of the
> IRQ line because we only want the interrupt to trigger once per each
> frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted
> by software, so the previous behavior before this patch, where the
> interrupt was triggered by level-high status of the IRQ line, caused
> the interrupt to fire again immediatelly after it was handled, which
> caused the system to lock up due to the high rate of interrupts.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> ---
> arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
> index 1a473e8..9526c38 100644
> --- a/arch/arm/boot/dts/imx6sx.dtsi
> +++ b/arch/arm/boot/dts/imx6sx.dtsi
> @@ -1143,7 +1143,7 @@
> lcdif1: lcdif at 02220000 {
> compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
> reg = <0x02220000 0x4000>;
> - interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> + interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
What about mx6ul and mx6sl.dtsi? Shouldn't they be also updated?
^ 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