* [PATCH v2 2/2] arm64: process: dump memory around registers when displaying regs
From: Enric Balletbo i Serra @ 2017-04-25 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425134430.5545-1-enric.balletbo@collabora.com>
From: Greg Hackmann <ghackmann@google.com>
Dump a block of kernel memory from around the registers in the kernel oops
dump. This is behind a config option (DEBUG_AROUND_REGS), since it adds
a bunch of noise to the kernel logs (which someone can find valuable but
not everyone else will).
This is extremely useful in diagnosing remote crashes, and is based heavily
on original work by Michael Davidson <md@google.com> and San Mehat
<san@google.com>.
Signed-off-by: Greg Hackmann <ghackmann@google.com>
[rework to use dump_mem]
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
Same as 1/2 but for arm64 architecture.
Changes since v1:
- Did not exists.
---
arch/arm64/include/asm/traps.h | 3 +++
arch/arm64/kernel/process.c | 26 ++++++++++++++++++++++++++
arch/arm64/kernel/traps.c | 4 ++--
3 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
index 02e9035..140f642 100644
--- a/arch/arm64/include/asm/traps.h
+++ b/arch/arm64/include/asm/traps.h
@@ -60,4 +60,7 @@ static inline int in_exception_text(unsigned long ptr)
return in ? : __in_irqentry_text(ptr);
}
+void dump_mem(const char *lvl, const char *str, unsigned long bottom,
+ unsigned long top);
+
#endif
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index ae2a835..5ee2f48 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -58,6 +58,7 @@
#include <asm/mmu_context.h>
#include <asm/processor.h>
#include <asm/stacktrace.h>
+#include <asm/traps.h>
#ifdef CONFIG_CC_STACKPROTECTOR
#include <linux/stackprotector.h>
@@ -170,6 +171,28 @@ void machine_restart(char *cmd)
while (1);
}
+/*
+ * Dump a block of kernel memory from around the given address
+ */
+static void __show_regs_extra_data(struct pt_regs *regs, int nbytes)
+{
+#ifdef CONFIG_DEBUG_AROUND_REGS
+ int i;
+
+ dump_mem("", "PC ", regs->pc - nbytes, regs->pc + nbytes);
+ dump_mem("", "LR ", regs->regs[30] - nbytes, regs->regs[30] + nbytes);
+ dump_mem("", "SP ", regs->sp - nbytes, regs->sp + nbytes);
+
+ for (i = 0; i < 30; i++) {
+ char name[4];
+
+ snprintf(name, sizeof(name), "X%u", i);
+ dump_mem("", name, regs->regs[i] - nbytes,
+ regs->regs[i] + nbytes);
+ }
+#endif
+}
+
void __show_regs(struct pt_regs *regs)
{
int i, top_reg;
@@ -205,6 +228,9 @@ void __show_regs(struct pt_regs *regs)
pr_cont("\n");
}
+
+ if (!user_mode(regs))
+ __show_regs_extra_data(regs, 128);
}
void show_regs(struct pt_regs * regs)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 1de444e..6d07675 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -59,8 +59,8 @@ int show_unhandled_signals = 1;
/*
* Dump out the contents of some kernel memory nicely...
*/
-static void dump_mem(const char *lvl, const char *str, unsigned long bottom,
- unsigned long top)
+void dump_mem(const char *lvl, const char *str, unsigned long bottom,
+ unsigned long top)
{
unsigned long first;
mm_segment_t fs;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/2] arm: process: dump memory around registers when displaying regs
From: Enric Balletbo i Serra @ 2017-04-25 13:44 UTC (permalink / raw)
To: linux-arm-kernel
Dump a block of kernel memory from around the registers in the kernel oops
dump. This is behind a config option (DEBUG_AROUND_REGS), since it adds
a bunch of noise to the kernel logs (which someone can find valuable but
not everyone else will).
This is extremely useful in diagnosing remote crashes, and is based heavily
on original work by Michael Davidson <md@google.com> and San Mehat
<san@google.com>.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
This is a second version of a patch that was initially sent by John Stultz
in 2010[1], current version is a rework trying to address the feedback
received in the first version. We're still carrying this patch on recent
chromeos kernels and find it useful. This is a second attempt to try
to get this acceptable, so waiting for your feedback, and I hope I'll be
able to do the modifications needed.
Changes since v1:
- Use dump_mem() to dump memory.
- Put the code behind a config option.
[1] http://www.spinics.net/lists/arm-kernel/msg107477.html
---
arch/arm/include/asm/traps.h | 1 +
arch/arm/kernel/process.c | 34 ++++++++++++++++++++++++++++++++++
arch/arm/kernel/traps.c | 6 ++----
lib/Kconfig.debug | 11 +++++++++++
4 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/traps.h b/arch/arm/include/asm/traps.h
index f555bb3..24e65c2 100644
--- a/arch/arm/include/asm/traps.h
+++ b/arch/arm/include/asm/traps.h
@@ -47,6 +47,7 @@ static inline int in_exception_text(unsigned long ptr)
}
extern void __init early_trap_init(void *);
+extern void dump_mem(const char *lvl, const char *str, unsigned long bottom, unsigned long top);
extern void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long frame);
extern void ptrace_break(struct task_struct *tsk, struct pt_regs *regs);
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 939e8b5..3894cf2 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -34,6 +34,7 @@
#include <asm/processor.h>
#include <asm/thread_notify.h>
+#include <asm/traps.h>
#include <asm/stacktrace.h>
#include <asm/system_misc.h>
#include <asm/mach/time.h>
@@ -94,6 +95,37 @@ void arch_cpu_idle_exit(void)
ledtrig_cpu(CPU_LED_IDLE_END);
}
+/*
+ * Dump a block of kernel memory from around the given address
+ */
+static void __show_regs_extra_data(struct pt_regs *regs, int nbytes)
+{
+#ifdef CONFIG_DEBUG_AROUND_REGS
+ struct map_regs {
+ unsigned long reg;
+ const char *name;
+ };
+ struct map_regs map_dump[] = {
+ { regs->ARM_pc, "PC " }, { regs->ARM_lr, "LR " },
+ { regs->ARM_sp, "SP " }, { regs->ARM_ip, "IP " },
+ { regs->ARM_fp, "FP " }, { regs->ARM_r0, "R0 " },
+ { regs->ARM_r1, "R1 " }, { regs->ARM_r2, "R2 " },
+ { regs->ARM_r3, "R3 " }, { regs->ARM_r4, "R4 " },
+ { regs->ARM_r5, "R5 " }, { regs->ARM_r6, "R6 " },
+ { regs->ARM_r7, "R7 " }, { regs->ARM_r8, "R8 " },
+ { regs->ARM_r9, "R9 " }, { regs->ARM_r10, "R10 " },
+ { -1, NULL },
+ };
+ struct map_regs *map = map_dump;
+
+ while (map->name) {
+ dump_mem("", map->name, map->reg - nbytes,
+ map->reg + nbytes);
+ map++;
+ }
+#endif
+}
+
void __show_regs(struct pt_regs *regs)
{
unsigned long flags;
@@ -185,6 +217,8 @@ void __show_regs(struct pt_regs *regs)
printk("Control: %08x%s\n", ctrl, buf);
}
#endif
+
+ __show_regs_extra_data(regs, 128);
}
void show_regs(struct pt_regs * regs)
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 948c648..f4ee05b 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -62,8 +62,6 @@ static int __init user_debug_setup(char *str)
__setup("user_debug=", user_debug_setup);
#endif
-static void dump_mem(const char *, const char *, unsigned long, unsigned long);
-
void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long frame)
{
#ifdef CONFIG_KALLSYMS
@@ -115,8 +113,8 @@ static int verify_stack(unsigned long sp)
/*
* Dump out the contents of some memory nicely...
*/
-static void dump_mem(const char *lvl, const char *str, unsigned long bottom,
- unsigned long top)
+void dump_mem(const char *lvl, const char *str, unsigned long bottom,
+ unsigned long top)
{
unsigned long first;
mm_segment_t fs;
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 77fadfa..b72d4ce6 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -726,6 +726,17 @@ config DEBUG_STACKOVERFLOW
If in doubt, say "N".
+config DEBUG_AROUND_REGS
+ bool "Dump a block of kernel memory from around registers"
+ depends on DEBUG_KERNEL
+ help
+ Say Y here to dump a block of kernel memory around the registers
+ in the kernel oops dump. This is useful in diagnosing remote
+ crashes.
+
+ Note that selecting this option will increase significally the
+ information in the oops dump. Most people should say N here.
+
source "lib/Kconfig.kmemcheck"
source "lib/Kconfig.kasan"
--
2.9.3
^ permalink raw reply related
* Touchscreen failure with CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
From: Fabio Estevam @ 2017-04-25 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xJVicKuAc0dDbzBg4h2d1UUP66iKkSsWN_f=rPd4mOZSw@mail.gmail.com>
Hi Adam,
On Tue, Apr 25, 2017 at 9:41 AM, Adam Ford <aford173@gmail.com> wrote:
> I don't have that board, so I can't test, but I have seen other issues on my
> imx6 board where operating at 'performance' instead of on-demand worked
> better for me as well in different areas. I was assuming it was something
What are the issues you observed with 'on-demand' on your mx6 board?
> regarding the voltage levels of various regulators for my board, and I am
> going to run tests on my board by playing with regulators on my device tree
> to make sure they are properly regulating to the right voltages. Since
> 'performance' runs the processor at both a higher speed and higher voltage,
> it's conceivable to me that something is just below some limit/level and
> needs some minor adjustment. At least that is my theory with my board
> issues. Have you looked considered that possibility?
One test I have already tried was to run all other cpufreq operating
points with the same ARM and SOC-PU voltages as the 996MHz.
Still in this case I do see touchscreen failure.
^ permalink raw reply
* [PATCH 1/3] arm64: extend ioremap for cacheable non-shareable memory
From: Mark Rutland @ 2017-04-25 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7C745CC3-3E91-4A8A-8DAB-0FA4E50DF08B@nxp.com>
On Fri, Apr 21, 2017 at 02:30:32PM +0000, Roy Pledge wrote:
> These transactions are done in HW via an ACP port which if I remember
> correctly only supports non coherent transactions. I will need to go
> back and check through email conversations I had with Catalin last
> year when debugging an issue using this mechanism
> (cacheable/nonshareable mapping) but it was deemed to be valid ARM
> setup architecturally for this type of device.
>
> Just for some background the page the QBMan device presented to a core
> is only accessed by a single core (i.e. SW portals are core affine).
> In this model each page is always mapped as non shareable and another
> core will never access it.
You cannot guarantee this given the page tables are used by multiple
CPUs.
The problem is not explicit memory accesses performed by code. As you
suggest, you can enforce that instructions accessing memory are only
architecturally executed on certain CPUs.
The problem is that even without any explicit access, a CPU can
implicitly access any region of Normal memory, at any time, for any
reason the microarchitecture sees fit to do so.
For example, the core may speculate some arbitrary instruction sequence,
which (perhaps by chance) generates an address falling in the
Non-shareable region, and attempts to load from it. The results might be
thrown away (i.e. the sequence wasn't architecturally executed), but the
speculated accesses will affect the memory system, and can result in
problems such as what I described previously.
Further, a cache maintenance op on a VA is only guaranteed to affect
caches scoped to the shareability domain of that VA. So no amount of
cache maintenance can provide the guarantees you require.
Practically speaking, because of such issues, it does not make sense for
Linux to use Non-shareable mappings.
> The important factor is that it is not DDR memory being mapped non
> sharable, but a non-coherent master on the bus in our SoC. I agree
> regular RAM shouldn?t be mapped this way but we cannot map this device
> as cacheable/shareable (coherent) on CCN-504 devices without getting
> exceptions from the CCN-504.
The problem is that multiple CPUs have a Non-shareable mapping for the
same physical address. What in particular is being mapped is immaterial.
> Treating it as non cacheable is functionally OK but performance
> suffers in that case.
Given that mapping these regions as Non-shareable is not functionally
OK, and given that you are unable to use coherent transactions, the only
option is to use a Non-cacheable mapping.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v5 2/2] PCI: quirks: Fix ThunderX2 dma alias handling
From: Bjorn Helgaas @ 2017-04-25 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425130346.GA30542@localhost>
On Tue, Apr 25, 2017 at 8:03 AM, Jayachandran C
<jnair@caviumnetworks.com> wrote:
> On Fri, Apr 21, 2017 at 12:57:05PM -0500, Bjorn Helgaas wrote:
>> I did notice that all the Root Port devices claim to *not* be connected to
>> slots, which doesn't seem right. For example,
>>
>> 12:00.0 PCI bridge: Broadcom Corporation Device 9084
>> Bus: primary=12, secondary=13, subordinate=14, sec-latency=0
>> Capabilities: [ac] Express (v2) Root Port (Slot-), MSI 00
>>
>> 13:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection
>>
>> It seems strange because the 12:00.0 Root Port looks like it probably
>> *does* lead to a slot where the NIC is plugged in. Or is that NIC really
>> soldered down?
>>
>> But I assume there are *some* PCIe slots, so at some of those Root Ports
>> should advertise "Slot+" (which by itself does not imply hotplug support,
>> if that's the concern).
>
> The Root Ports are connected to a slot, so I am not sure why the slot implemented
> bit is not set. There seems to be nothing useful in the slot capabilites, so this
> may be ok for now. I have reported this to the hardware team.
Thanks. The "Slot Implemented" bit and the slot registers aren't
essential if you don't want to support hotplug on those slots. But
even without hotplug, they do contain things like a slot number, which
may be useful in the user interface.
^ permalink raw reply
* [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
From: Marc Zyngier @ 2017-04-25 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425125103.GC16888@mai>
On 25/04/17 13:51, Daniel Lezcano wrote:
> On Tue, Apr 25, 2017 at 11:21:21AM +0100, Marc Zyngier wrote:
>> On 25/04/17 10:49, Daniel Lezcano wrote:
>>> On Tue, Apr 25, 2017 at 10:10:12AM +0100, Marc Zyngier wrote:
>>
>> [...]
>>
>>>>> +static inline void setup_timings(struct irq_desc *desc, struct irqaction *act)
>>>>> +{
>>>>> + /*
>>>>> + * We don't need the measurement because the idle code already
>>>>> + * knows the next expiry event.
>>>>> + */
>>>>> + if (act->flags & __IRQF_TIMER)
>>>>> + return;
>>>>
>>>> And that's where this is really wrong for the KVM guest timer. As I
>>>> said, this timer is under complete control of the guest, and the rest of
>>>> the system doesn't know about it. KVM itself will only find out when the
>>>> vcpu does a VM exit for a reason or another, and will just save/restore
>>>> the state in order to be able to give the timer to another guest.
>>>>
>>>> The idle code is very much *not* aware of anything concerning that guest
>>>> timer.
>>>
>>> Just for my own curiosity, if there are two VM (VM1 and VM2). VM1 sets a timer1
>>> at <time> and exits, VM2 runs and sets a timer2 at <time+delta>.
>>>
>>> The timer1 for VM1 is supposed to expire while VM2 is running. IIUC the virtual
>>> timer is under control of VM2 and will expire at <time+delta>.
>>>
>>> Is the host wake up with the SW timer and switch in VM1 which in turn restores
>>> the timer and jump in the virtual timer irq handler?
>>
>> Indeed. The SW timer causes VM1 to wake-up, either on the same CPU
>> (preempting VM2) or on another. The timer is then restored with the
>> pending virtual interrupt injected, and the guest does what it has to
>> with it.
>
> Thanks for clarification.
>
> So there is a virtual timer with real registers / interruption (waking up the
> host) for the running VMs and SW timers for non-running VMs.
>
> What is the benefit of having such mechanism instead of real timers injecting
> interrupts in the VM without the virtual timer + save/restore? Efficiency in
> the running VMs when setting up timers (saving privileges change overhead)?
You can't dedicate HW resources to virtual CPUs. It just doesn't scale.
Also, injecting HW interrupts in a guest is pretty hard work, and for
multiple reasons:
- the host needs to be in control of interrupt delivery (don't hog the
CPU with guest interrupts)
- you want to be able to remap interrupts (id X on the host becomes id
Y on the guest),
- you want to deal with migrating vcpus,
- you want deliver an interrupt to a vcpu that is *not* running.
It *is* doable, but it is not cheap at all from a HW point of view.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v4 5/5] ARM: dts: rockchip: enable ARM Mali GPU on rk3288-veyron
From: Guillaume Tucker @ 2017-04-25 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1493125299.git.guillaume.tucker@collabora.com>
From: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Add reference to the Mali GPU device tree node on rk3288-veyron.
Tested on Minnie and Jerry boards.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---
arch/arm/boot/dts/rk3288-veyron.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 5d1eb0a25827..9847d5c6db3b 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -447,6 +447,11 @@
status = "okay";
};
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
&wdt {
status = "okay";
};
--
2.11.0
^ permalink raw reply related
* [PATCH v4 4/5] ARM: dts: rockchip: enable ARM Mali GPU on rk3288-firefly
From: Guillaume Tucker @ 2017-04-25 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1493125299.git.guillaume.tucker@collabora.com>
Add reference to the Mali GPU device tree node on rk3288-firefly.
Tested on Firefly board.
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---
arch/arm/boot/dts/rk3288-firefly.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 10793ac18599..f520589493b4 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -594,3 +594,8 @@
&wdt {
status = "okay";
};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH v4 3/5] ARM: dts: rockchip: enable ARM Mali GPU on rk3288-rock2-som
From: Guillaume Tucker @ 2017-04-25 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1493125299.git.guillaume.tucker@collabora.com>
Add reference to the Mali GPU device tree node on the
rk3288-rock2-som platform. Tested on a Radxa Rock2 Square board.
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---
arch/arm/boot/dts/rk3288-rock2-som.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-rock2-som.dtsi b/arch/arm/boot/dts/rk3288-rock2-som.dtsi
index 1c0bbc9b928b..f694867fa46a 100644
--- a/arch/arm/boot/dts/rk3288-rock2-som.dtsi
+++ b/arch/arm/boot/dts/rk3288-rock2-som.dtsi
@@ -301,3 +301,8 @@
&wdt {
status = "okay";
};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH v4 2/5] ARM: dts: rockchip: add ARM Mali GPU node for rk3288
From: Guillaume Tucker @ 2017-04-25 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1493125299.git.guillaume.tucker@collabora.com>
Add Mali GPU device tree node for the rk3288 SoC, with devfreq
opp table.
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---
arch/arm/boot/dts/rk3288.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index df8a0dbe9d91..35969041eae2 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -43,6 +43,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/pinctrl/rockchip.h>
#include <dt-bindings/clock/rk3288-cru.h>
+#include <dt-bindings/power/rk3288-power.h>
#include <dt-bindings/thermal/thermal.h>
#include <dt-bindings/power/rk3288-power.h>
#include <dt-bindings/soc/rockchip,boot-mode.h>
@@ -1117,6 +1118,48 @@
};
};
+ gpu: mali at ffa30000 {
+ compatible = "rockchip,rk3288-mali", "arm,mali-t760", "arm,mali-midgard";
+ reg = <0xffa30000 0x10000>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "job", "mmu", "gpu";
+ clocks = <&cru ACLK_GPU>;
+ operating-points-v2 = <&gpu_opp_table>;
+ power-domains = <&power RK3288_PD_GPU>;
+ status = "disabled";
+ };
+
+ gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ opp at 100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ opp-microvolt = <950000>;
+ };
+ opp at 200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ opp-microvolt = <950000>;
+ };
+ opp at 300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <1000000>;
+ };
+ opp at 400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <1100000>;
+ };
+ opp at 500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <1200000>;
+ };
+ opp at 600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1250000>;
+ };
+ };
+
qos_gpu_r: qos at ffaa0000 {
compatible = "syscon";
reg = <0xffaa0000 0x20>;
--
2.11.0
^ permalink raw reply related
* [PATCH v4 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Guillaume Tucker @ 2017-04-25 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1493125299.git.guillaume.tucker@collabora.com>
The ARM Mali Midgard GPU family is present in a number of SoCs
from many different vendors such as Samsung Exynos and Rockchip.
Import the device tree bindings documentation from the r16p0
release of the Mali Midgard GPU kernel driver:
https://developer.arm.com/-/media/Files/downloads/mali-drivers/kernel/mali-midgard-gpu/TX011-SW-99002-r16p0-00rel0.tgz
Remove the copyright and GPL licence header as deemed not necessary.
Redesign the "compatible" property strings to list all the Mali
Midgard GPU types and include optional vendor ones.
Drop the "clock-names" property as only one clock is used by the Mali
Midgard driver (which now needs to call clk_get with NULL).
Convert the "interrupt-names" property values to lower-case: "job",
"mmu" and "gpu".
Replace the deprecated "operating-points" optional property with
"operating-points-v2".
Omit the following optional properties in this initial version as they
are only used in very specific cases:
* snoop_enable_smc
* snoop_disable_smc
* jm_config
* power_model
* system-coherency
* ipa-model
Update the example accordingly to reflect all these changes.
CC: John Reitan <john.reitan@arm.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---
.../devicetree/bindings/gpu/arm,mali-midgard.txt | 82 ++++++++++++++++++++++
1 file changed, 82 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
new file mode 100644
index 000000000000..547ddeceb498
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -0,0 +1,82 @@
+ARM Mali Midgard GPU
+====================
+
+Required properties:
+
+- compatible :
+ * Must be one of the following:
+ + "arm,mali-t60x"
+ + "arm,mali-t62x"
+ + "arm,mali-t720"
+ + "arm,mali-t760"
+ + "arm,mali-t820"
+ + "arm,mali-t830"
+ + "arm,mali-t860"
+ + "arm,mali-t880"
+ * And, optionally, one of the vendor specific compatible:
+ + "amlogic,meson-gxm-mali"
+ + "rockchip,rk3288-mali"
+
+- reg : Physical base address of the device and length of the register area.
+
+- interrupts : Contains the three IRQ lines required by Mali Midgard devices.
+
+- interrupt-names : Contains the names of IRQ resources in the order they were
+ provided in the interrupts property. Must contain: "job", "mmu", "gpu".
+
+
+Optional properties:
+
+- clocks : Phandle to clock for the Mali Midgard device.
+
+- mali-supply : Phandle to regulator for the Mali device. Refer to
+ Documentation/devicetree/bindings/regulator/regulator.txt for details.
+
+- operating-points-v2 : Refer to Documentation/devicetree/bindings/power/opp.txt
+ for details.
+
+
+Example for a Mali-T602:
+
+gpu at fc010000 {
+ compatible = "arm,mali-t60x", "arm,mali-midgard";
+ reg = <0xfc010000 0x4000>;
+ interrupts = <0 36 4>, <0 37 4>, <0 38 4>;
+ interrupt-names = "job", "mmu", "gpu";
+ clocks = <&pclk_mali>;
+ mali-supply = <&vdd_mali>;
+ operating-points-v2 = <&gpu_opp_table>;
+};
+
+gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ opp at 533000000 {
+ opp-hz = /bits/ 64 <533000000>;
+ opp-microvolt = <1250000>;
+ };
+ opp at 450000000 {
+ opp-hz = /bits/ 64 <450000000>;
+ opp-microvolt = <1150000>;
+ };
+ opp at 400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <1125000>;
+ };
+ opp at 350000000 {
+ opp-hz = /bits/ 64 <350000000>;
+ opp-microvolt = <1075000>;
+ };
+ opp at 266000000 {
+ opp-hz = /bits/ 64 <266000000>;
+ opp-microvolt = <1025000>;
+ };
+ opp at 160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ opp-microvolt = <925000>;
+ };
+ opp at 100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ opp-microvolt = <912500>;
+ };
+};
--
2.11.0
^ permalink raw reply related
* [PATCH v4 0/5] Add ARM Mali Midgard device tree bindings and gpu node for rk3288
From: Guillaume Tucker @ 2017-04-25 13:16 UTC (permalink / raw)
To: linux-arm-kernel
The ARM Mali Midgard GPU kernel driver is only available
out-of-tree and is not going to be merged in its current form.
However, it would be useful to have its device tree bindings
merged. In particular, this would enable distributions to create
working driver packages (dkms...) without having to patch the
kernel.
The bindings for the earlier Mali Utgard GPU family have already
been merged, so this is essentially the same scenario but for
newer GPUs (Mali-T604 ~ Mali-T880).
This series of patches first imports the bindings from the latest
driver release with some clean-up then adds a gpu node for the
rk3288 SoC. This was successfully tested on Radxa Rock2 Square,
Firefly, Veyron Minnie and Jerry boards using Mali kernel driver
r16p0 and r12p0 user-space binary.
Changes since v1:
- enabled gpu on rk3288-veyron boards
Changes since v2:
- removed "clk-names" property and "clk_mali" name
- converted values of "interrupt-names" property to
lower-case: "job", "mmu" and "gpu"
- replaced dt compatible strings with list of all Midgard GPU variants and
optional vendors
- cleaned up gpu node example
Changes since v3:
- add "rockchip,rk3288-mali" vendor compatible string
- move gpu node at the right location in rk3288.dtsi
- use operating-points-v2 in documentation and rk3288.dtsi
Enric Balletbo i Serra (1):
ARM: dts: rockchip: enable ARM Mali GPU on rk3288-veyron
Guillaume Tucker (4):
dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
ARM: dts: rockchip: add ARM Mali GPU node for rk3288
ARM: dts: rockchip: enable ARM Mali GPU on rk3288-rock2-som
ARM: dts: rockchip: enable ARM Mali GPU on rk3288-firefly
.../devicetree/bindings/gpu/arm,mali-midgard.txt | 82 ++++++++++++++++++++++
arch/arm/boot/dts/rk3288-firefly.dtsi | 5 ++
arch/arm/boot/dts/rk3288-rock2-som.dtsi | 5 ++
arch/arm/boot/dts/rk3288-veyron.dtsi | 5 ++
arch/arm/boot/dts/rk3288.dtsi | 43 ++++++++++++
5 files changed, 140 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
--
2.11.0
^ permalink raw reply
* [PATCH v5 2/2] PCI: quirks: Fix ThunderX2 dma alias handling
From: Jayachandran C @ 2017-04-25 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421175705.GB17916@bhelgaas-glaptop.roam.corp.google.com>
On Fri, Apr 21, 2017 at 12:57:05PM -0500, Bjorn Helgaas wrote:
> On Fri, Apr 21, 2017 at 05:05:41PM +0000, Jayachandran C wrote:
> > On Fri, Apr 21, 2017 at 10:48:15AM -0500, Bjorn Helgaas wrote:
> > > On Mon, Apr 17, 2017 at 12:47 PM, Jayachandran C
> > > <jnair@caviumnetworks.com> wrote:
> > > > On Fri, Apr 14, 2017 at 09:00:06PM -0500, Bjorn Helgaas wrote:
>
> > > >> Could you collect "lspci -vv" output from this system? I'd like to
> > > >> archive that as background for this IOMMU issue and the ASPM tweaks I
> > > >> suspect we'll have to do. I *wish* we had more information about that
> > > >> VIA thing, because I suspect we could get rid of it if we had more
> > > >> details.
> > > >
> > > > The full logs are slightly large, so I have kept them at:
> > > > https://github.com/jchandra-cavm/thunderx2/blob/master/logs/
> > > > The lspci -vv output is lspci-vv.txt and lspci -tvn output is lspci-tvn.txt
> > > >
> > > > The output is from 2 socket system, the cards are not on the first slot
> > > > like the example above, so the bus and device numbers are different.
> > >
> > > Can somebody with this system collect the "lspci -xxxx" output as well?
> > >
> > > I'm making some lspci changes to handle the PCI-to-PCIe bridge
> > > correctly, and I can use the "lspci -xxxx" output to create an lspci
> > > test case.
> >
> > [Sorry was AFK for a few days]
> >
> > I have updated the above directory with the log. Also tested your next branch
> > and it works fine on ThunderX2.
>
> Thanks!
>
> With regard to my lspci changes, they add "Slot-" here:
>
> 01:0a.0 PCI bridge: Broadcom Corporation Device 9039
> ...
> - Capabilities: [40] Express (v2) PCI/PCI-X to PCI-Express Bridge, MSI 00
> + Capabilities: [40] Express (v2) PCI/PCI-X to PCI-Express Bridge (Slot-), MSI 00
>
> for all your PCI-to-PCIe bridges. I assume the "Slot-" is correct, i.e.,
> the link is not connected to a slot, right? This comes from the "Slot
> Implemented" bit in the PCIe Capabilities Register.
Yes, Slot- should be correct.
> I did notice that all the Root Port devices claim to *not* be connected to
> slots, which doesn't seem right. For example,
>
> 12:00.0 PCI bridge: Broadcom Corporation Device 9084
> Bus: primary=12, secondary=13, subordinate=14, sec-latency=0
> Capabilities: [ac] Express (v2) Root Port (Slot-), MSI 00
>
> 13:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection
>
> It seems strange because the 12:00.0 Root Port looks like it probably
> *does* lead to a slot where the NIC is plugged in. Or is that NIC really
> soldered down?
>
> But I assume there are *some* PCIe slots, so at some of those Root Ports
> should advertise "Slot+" (which by itself does not imply hotplug support,
> if that's the concern).
The Root Ports are connected to a slot, so I am not sure why the slot implemented
bit is not set. There seems to be nothing useful in the slot capabilites, so this
may be ok for now. I have reported this to the hardware team.
Thanks for the review and the comments,
JC.
^ permalink raw reply
* [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
From: Daniel Lezcano @ 2017-04-25 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425102230.GJ4104@cbox>
On Tue, Apr 25, 2017 at 12:22:30PM +0200, Christoffer Dall wrote:
> On Tue, Apr 25, 2017 at 11:49:27AM +0200, Daniel Lezcano wrote:
>
> [...]
>
> > >
> > > The idle code is very much *not* aware of anything concerning that guest
> > > timer.
> >
> > Just for my own curiosity, if there are two VM (VM1 and VM2). VM1 sets a timer1
> > at <time> and exits, VM2 runs and sets a timer2 at <time+delta>.
> >
> > The timer1 for VM1 is supposed to expire while VM2 is running. IIUC the virtual
> > timer is under control of VM2 and will expire at <time+delta>.
> >
> > Is the host wake up with the SW timer and switch in VM1 which in turn restores
> > the timer and jump in the virtual timer irq handler?
> >
> The thing that may be missing here is that a VCPU thread (more of which
> in a collection is a VM) is just a thread from the point of view of
> Linux, and whether or not a guest schedules a timer, should not effect
> the scheduler's decision to run a given thread, if the thread is
> runnable.
>
> Whenever we run a VCPU thread, we look at its timer state (in software)
> and calculate if the guest should see a timer interrupt and inject such
> a one (the hardware arch timer is not involved in this process at all).
>
> We use timers in exactly two scenarios:
>
> 1. The hardware arch timers are used to force an exit to the host when
> the guest programmed the timer, so we can do the calculation in
> software I mentioned above and inject a virtual software-generated
> interrupt when the guest expects to see one.
>
> 2. The guest goes to sleep (WFI) but has programmed a timer to be woken
> up at some point. KVM handles a WFI by blocking the VCPU thread,
> which basically means making the thread interruptible and putting it
> on a waitqueue. In this case we schedule a software timer to make
> the thread runnable again when the software timer fires (and the
> scheduler runs that thread when it wants to after that).
>
> If you have a VCPU thread from VM1 blocked, and you run a VCPU thread
> from VM2, then the VCPU thread from VM2 will program the hardware arch
> timer with the context of the VM2 VCPU thread while running, and this
> has nothing to do with the VCPU thread from VM1 at this point, because
> it relies on the host Linux time keeping infrastructure to become
> runnable some time in the future, and running a guest naturally doesn't
> mess with the host's time keeping.
>
> Hope this helps,
Yes, definitively. Thanks for the detailed description.
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* support autofocus / autogain in libv4l2
From: Pali Rohár @ 2017-04-25 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425122820.GD7926@amd>
On Tuesday 25 April 2017 14:28:20 Pavel Machek wrote:
> On Tue 2017-04-25 13:30:09, Pali Roh?r wrote:
> > On Tuesday 25 April 2017 13:23:30 Pavel Machek wrote:
> > > Hi!
> > > On Tue 2017-04-25 10:08:15, Pali Roh?r wrote:
> > > > On Tuesday 25 April 2017 10:05:38 Pavel Machek wrote:
> > > > > > > It would be nice if more than one application could be accessing the
> > > > > > > camera at the same time... (I.e. something graphical running preview
> > > > > > > then using command line tool to grab a picture.) This one is
> > > > > > > definitely not solveable inside a library...
> > > > > >
> > > > > > Someone once suggested to have something like pulseaudio for V4L.
> > > > > > For such usage, a server would be interesting. Yet, I would code it
> > > > > > in a way that applications using libv4l will talk with such daemon
> > > > > > in a transparent way.
> > > > >
> > > > > Yes, we need something like pulseaudio for V4L. And yes, we should
> > > > > make it transparent for applications using libv4l.
> > > >
> > > > IIRC there is already some effort in writing such "video" server which
> > > > would support accessing more application into webcam video, like
> > > > pulseaudio server for accessing more applications to microphone input.
> > >
> > > Do you have project name / url / something?
> >
> > Pinos (renamed from PulseVideo)
> >
> > https://blogs.gnome.org/uraeus/2015/06/30/introducing-pulse-video/
> > https://cgit.freedesktop.org/~wtay/pinos/
> >
> > But from git history it looks like it is probably dead now...
>
> Actually, last commit is an hour ago on "work" branch. Seems alive to
> me ;-).
Great! I just (blindly) looked at master branch and it is old...
> Thanks for pointer...
> Pavel
--
Pali Roh?r
pali.rohar at gmail.com
^ permalink raw reply
* [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."
From: Julien Grall @ 2017-04-25 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1704241214100.16723@sstabellini-ThinkPad-X260>
Hi Stefano,
On 24/04/17 20:16, Stefano Stabellini wrote:
> Given the outstanding regression we need to fix as soon as possible,
> I'll queue these patches on the xentip tree for 4.12.
It looks like there is another rc for 4.11. I am wondering whether you
could try to send a pull request to Linus so it can be fixed in 4.11?
Cheers,
--
Julien Grall
^ permalink raw reply
* [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
From: Daniel Lezcano @ 2017-04-25 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c98a5ff3-c2ea-5f94-d136-391bd7c224f3@arm.com>
On Tue, Apr 25, 2017 at 11:21:21AM +0100, Marc Zyngier wrote:
> On 25/04/17 10:49, Daniel Lezcano wrote:
> > On Tue, Apr 25, 2017 at 10:10:12AM +0100, Marc Zyngier wrote:
>
> [...]
>
> >>> +static inline void setup_timings(struct irq_desc *desc, struct irqaction *act)
> >>> +{
> >>> + /*
> >>> + * We don't need the measurement because the idle code already
> >>> + * knows the next expiry event.
> >>> + */
> >>> + if (act->flags & __IRQF_TIMER)
> >>> + return;
> >>
> >> And that's where this is really wrong for the KVM guest timer. As I
> >> said, this timer is under complete control of the guest, and the rest of
> >> the system doesn't know about it. KVM itself will only find out when the
> >> vcpu does a VM exit for a reason or another, and will just save/restore
> >> the state in order to be able to give the timer to another guest.
> >>
> >> The idle code is very much *not* aware of anything concerning that guest
> >> timer.
> >
> > Just for my own curiosity, if there are two VM (VM1 and VM2). VM1 sets a timer1
> > at <time> and exits, VM2 runs and sets a timer2 at <time+delta>.
> >
> > The timer1 for VM1 is supposed to expire while VM2 is running. IIUC the virtual
> > timer is under control of VM2 and will expire at <time+delta>.
> >
> > Is the host wake up with the SW timer and switch in VM1 which in turn restores
> > the timer and jump in the virtual timer irq handler?
>
> Indeed. The SW timer causes VM1 to wake-up, either on the same CPU
> (preempting VM2) or on another. The timer is then restored with the
> pending virtual interrupt injected, and the guest does what it has to
> with it.
Thanks for clarification.
So there is a virtual timer with real registers / interruption (waking up the
host) for the running VMs and SW timers for non-running VMs.
What is the benefit of having such mechanism instead of real timers injecting
interrupts in the VM without the virtual timer + save/restore? Efficiency in
the running VMs when setting up timers (saving privileges change overhead)?
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH 2/2] arm64: pmu: Wire-up L2 cache events for ARMv8 PMUv3
From: Will Deacon @ 2017-04-25 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420190546.7453-4-f.fainelli@gmail.com>
Hi Florian,
On Thu, Apr 20, 2017 at 12:05:46PM -0700, Florian Fainelli wrote:
> The ARMv8 PMUv3 cache map did not include the L2 cache events, add
> them.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm64/kernel/perf_event.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 4f011cdd756d..a664c575f3fd 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -264,6 +264,11 @@ static const unsigned armv8_pmuv3_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
> [C(L1I)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE,
> [C(L1I)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL,
>
> + [C(LL)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
> + [C(LL)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
> + [C(LL)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
> + [C(LL)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
I don't think this is correct in general. 'LL' stands for "last-level",
which may be L3 or even a system cache in the interconnect. Tying that to L2
is the wrong thing to do from perf's generic event perspective.
I'm ok with what you're proposing for A53 (where the PMU can only count
events out to the L2), but I'm reluctant to make this change for the generic
PMUv3 events.
Will
^ permalink raw reply
* [PATCH 1/2] PCI: mediatek: Add Mediatek PCIe host controller support
From: Arnd Bergmann @ 2017-04-25 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492935543-18190-2-git-send-email-ryder.lee@mediatek.com>
On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> +static inline bool mtk_pcie_link_is_up(struct mtk_pcie_port *port)
> +{
> + return !!(readl_relaxed(port->base + PCIE_LINK_STATUS) &
> + PCIE_PORT_LINKUP);
> +}
If this is not performance critical, please use the regular readl() instead
of readl_relaxed().
> +static bool mtk_pcie_valid_device(struct mtk_pcie *pcie,
> + struct pci_bus *bus, int devfn)
> +{
> + struct mtk_pcie_port *port;
> + struct pci_dev *dev;
> + struct pci_bus *pbus;
> +
> + /* if there is no link, then there is no device */
> + list_for_each_entry(port, &pcie->ports, list) {
> + if (bus->number == 0 && port->index == PCI_SLOT(devfn) &&
> + mtk_pcie_link_is_up(port)) {
> + return true;
> + } else if (bus->number != 0) {
> + pbus = bus;
> + do {
> + dev = pbus->self;
> + if (port->index == PCI_SLOT(dev->devfn) &&
> + mtk_pcie_link_is_up(port)) {
> + return true;
> + }
> + pbus = dev->bus;
> + } while (dev->bus->number != 0);
> + }
> + }
> +
> + return false;
> +}
> +static int mtk_pcie_hw_rd_cfg(struct mtk_pcie *pcie, u32 bus, u32 devfn,
> + int where, int size, u32 *val)
> +{
> + writel(PCIE_CONF_ADDR(where, PCI_FUNC(devfn), PCI_SLOT(devfn), bus),
> + pcie->base + PCIE_CFG_ADDR);
> +
> + *val = 0;
> +
> + switch (size) {
> + case 1:
> + *val = readb(pcie->base + PCIE_CFG_DATA + (where & 3));
> + break;
> + case 2:
> + *val = readw(pcie->base + PCIE_CFG_DATA + (where & 2));
> + break;
> + case 4:
> + *val = readl(pcie->base + PCIE_CFG_DATA);
> + break;
> + }
> +
> + return PCIBIOS_SUCCESSFUL;
> +}
This is a fairly standard set of read/write operations. Can you change
the pci_ops
to use pci_generic_config_read/pci_generic_config_write and an appropriate
map function instead?
> +static int mtk_pcie_enable_ports(struct mtk_pcie *pcie)
> +{
> + struct device *dev = pcie->dev;
> + struct mtk_pcie_port *port, *tmp;
> + int err, linkup = 0;
> +
> + list_for_each_entry_safe(port, tmp, &pcie->ports, list) {
> + err = clk_prepare_enable(port->sys_ck);
> + if (err) {
> + dev_err(dev, "failed to enable port%d clock\n",
> + port->index);
> + continue;
> + }
> +
> + /* assert RC */
> + reset_control_assert(port->reset);
> + /* de-assert RC */
> + reset_control_deassert(port->reset);
> +
> + /* power on PHY */
> + err = phy_power_on(port->phy);
> + if (err) {
> + dev_err(dev, "failed to power on port%d phy\n",
> + port->index);
> + goto err_phy_on;
> + }
> +
> + mtk_pcie_assert_ports(port);
> +
Similar to the comment I had for the binding, I wonder if it would be
better to keep all the information about the ports in one place and
then just deal with it at the root level.
Alternatively, we could decide to standardize on the properties
you have added to the pcie port node, but then I would handle
them in the pcieport driver rather than in the host bridge driver.
> +/*
> + * This IP lacks interrupt status register to check or map INTx from
> + * different devices at the same time.
> + */
> +static int __init mtk_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
> +{
> + struct mtk_pcie *pcie = dev->bus->sysdata;
> + struct mtk_pcie_port *port;
> +
> + list_for_each_entry(port, &pcie->ports, list)
> + if (port->index == slot)
> + return port->irq;
> +
> + return -1;
> +}
This looks odd, what is it needed for specifically? It looks like
it's broken for devices behind bridges, and the interrupt mapping
should normally come from the interrupt-map property, without
the need for a driver specific map_irq override.
> +static int mtk_pcie_register_ports(struct mtk_pcie *pcie)
> +{
> + struct pci_bus *bus, *child;
> +
> + bus = pci_scan_root_bus(pcie->dev, 0, &mtk_pcie_ops, pcie,
> + &pcie->resources);
Can you use the new pci_register_host_bridge() method instead of
pci_scan_root_bus() here?
ARnd
^ permalink raw reply
* support autofocus / autogain in libv4l2
From: Pavel Machek @ 2017-04-25 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425113009.GH30553@pali>
On Tue 2017-04-25 13:30:09, Pali Roh?r wrote:
> On Tuesday 25 April 2017 13:23:30 Pavel Machek wrote:
> > Hi!
> > On Tue 2017-04-25 10:08:15, Pali Roh?r wrote:
> > > On Tuesday 25 April 2017 10:05:38 Pavel Machek wrote:
> > > > > > It would be nice if more than one application could be accessing the
> > > > > > camera at the same time... (I.e. something graphical running preview
> > > > > > then using command line tool to grab a picture.) This one is
> > > > > > definitely not solveable inside a library...
> > > > >
> > > > > Someone once suggested to have something like pulseaudio for V4L.
> > > > > For such usage, a server would be interesting. Yet, I would code it
> > > > > in a way that applications using libv4l will talk with such daemon
> > > > > in a transparent way.
> > > >
> > > > Yes, we need something like pulseaudio for V4L. And yes, we should
> > > > make it transparent for applications using libv4l.
> > >
> > > IIRC there is already some effort in writing such "video" server which
> > > would support accessing more application into webcam video, like
> > > pulseaudio server for accessing more applications to microphone input.
> >
> > Do you have project name / url / something?
>
> Pinos (renamed from PulseVideo)
>
> https://blogs.gnome.org/uraeus/2015/06/30/introducing-pulse-video/
> https://cgit.freedesktop.org/~wtay/pinos/
>
> But from git history it looks like it is probably dead now...
Actually, last commit is an hour ago on "work" branch. Seems alive to
me ;-).
Thanks for pointer...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170425/cdcc4df0/attachment.sig>
^ permalink raw reply
* [PATCH] iommu: arm-smmu: correct sid to mask
From: Joerg Roedel @ 2017-04-25 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424155453.GP12323@arm.com>
On Mon, Apr 24, 2017 at 04:54:54PM +0100, Will Deacon wrote:
> On Fri, Apr 21, 2017 at 05:03:36PM +0800, Peng Fan wrote:
> > - sid, smmu->smr_mask_mask);
> > + mask, smmu->smr_mask_mask);
> > goto out_free;
>
> Looks like a copy-paste error to me:
>
> Acked-by: Will Deacon <will.deacon@arm.com>
>
> Joerg: do you mind picking this one up, please?
Applied, thanks.
^ permalink raw reply
* [PATCH 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe
From: Arnd Bergmann @ 2017-04-25 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492935543-18190-3-git-send-email-ryder.lee@mediatek.com>
On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> Add documentation for PCIe host driver available in MT7623
> series SoCs.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> .../bindings/pci/mediatek,mt7623-pcie.txt | 153 +++++++++++++++++++++
> 1 file changed, 153 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> new file mode 100644
> index 0000000..ee93ba2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> @@ -0,0 +1,153 @@
> +Mediatek MT7623 PCIe controller
> +
> +Required properties:
> +- compatible: Should contain "mediatek,mt7623-pcie".
Did mediatek license the IP block from someone else or was it
developed in-house? Is there a name and/or version identifier
for the block itself other than identifying it as the one in mt7623?
> +- device_type: Must be "pci"
> +- reg: Base addresses and lengths of the pcie controller.
> +- interrupts: A list of interrupt outputs of the controller.
Please be more specific about what each interrupt is for, and how
many there are.
> +Required properties:
> +- device_type: Must be "pci"
> +- assigned-addresses: Address and size of the port configuration registers
> +- reg: Only the first four bytes are used to refer to the correct bus number
> + and device number.
> +- #address-cells: Must be 3
> +- #size-cells: Must be 2
> +- ranges: Sub-ranges distributed from the PCIe controller node. An empty
> + property is sufficient.
> +- clocks: Must contain an entry for each entry in clock-names.
> + See ../clocks/clock-bindings.txt for details.
> +- clock-names: Must include the following entries:
> + - sys_ck
> +- resets: Must contain an entry for each entry in reset-names.
> + See ../reset/reset.txt for details.
This seems odd: you have a device that is simply identified as "pci"
without any more specific ID, but you require additional properties
(clocks, reset, ...) that are not part of the standard PCI binding.
Can you clarify how the port devices related to the root device in
this hardware design?
Have you considered moving the nonstandard properties into the host
bridge node and having that device deal with setting up the links
to the other drivers? That way we could use the regular pcie
port driver for the children.
> +- reset-names: Must include the following entries:
> + - pcie-reset
> +- num-lanes: Number of lanes to use for this port.
> +- phys: Must contain an entry for each entry in phy-names.
> +- phy-names: Must include an entry for each sub node. Entries are of the form
> + "pcie-phyN": where N ranges from 0 to the value specified for port number.
> + See ../phy/phy-mt7623-pcie.txt for details.
I think the name should not include the number of the port but rather
be always the same here.
Arnd
^ permalink raw reply
* Tegra baseline test results for v4.11-rc6
From: Jon Hunter @ 2017-04-25 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7ef3c6bd-0f47-4277-eff5-940af68c858f@nvidia.com>
On 25/04/17 13:03, Jon Hunter wrote:
> Here are some basic Tegra test results for Linux v4.11-rc6.
> Logs and other details at:
>
> https://nvtb.github.io//linux/test_v4.11-rc6/20170411053103/
>
>
> Test summary
> ------------
>
> Build: zImage:
> Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
>
> Build: Image:
> Pass: ( 1/ 1): defconfig
>
> Boot to userspace: defconfig:
> Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
> tegra210-p2371-0000, tegra210-smaug
>
> Boot to userspace: multi_v7_defconfig:
> Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
> tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
>
> Boot to userspace: tegra_defconfig:
> Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
> tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
>
> PM: System suspend: multi_v7_defconfig:
> Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
> tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
>
> PM: System suspend: tegra_defconfig:
> FAIL: ( 1/ 5): tegra124-nyan-big
> Pass: ( 4/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
> tegra20-trimslice, tegra30-beaver
The above suspend failure for nyan-big bisected to commit ce612879ddc7
("mm: move pcp and lru-pcp draining into single wq"). There have been
other reports of this breaking suspend [0] and has since been fixed [1]
for v4.11-rc7.
Interestingly this only was causing problems for tegra with XHCI enabled
(in tegra_defconfig). I am seeing some random usb resets during resume
with XHCI and so if anyone sees any such problems let me know.
Cheers
Jon
[0] http://marc.info/?l=linux-kernel&m=149254544031358&w=2
[1] http://marc.info/?l=linux-kernel&m=149258864408467&w=2
--
nvpublic
^ permalink raw reply
* [PATCH] arm64: Add ASM modifier for xN register operands
From: Will Deacon @ 2017-04-25 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424191345.GM128305@google.com>
On Mon, Apr 24, 2017 at 12:13:45PM -0700, Matthias Kaehlcke wrote:
> El Mon, Apr 24, 2017 at 06:34:14PM +0100 Will Deacon ha dit:
> > On Mon, Apr 24, 2017 at 06:22:51PM +0100, Ard Biesheuvel wrote:
> > > AIUI, Clang now always complains for missing register width modifiers,
> > > not just for placeholders that resolve to a 32-bit (or smaller)
> > > quantity.
> >
> > Ok, in which case this patch is incomplete as there's a bunch of asm that
> > isn't updated (e.g. spinlock.h).
>
> Sorry, my grep pattern was a bit naive and didn't take multiline
> inline assembly into account.
Ah, right, so you were trying to fix everything but just missed stuff. Maybe
it's best to grep for 'asm.*(' and filter out the false positives.
> If you are ok with adding modifiers everywhere I'll add the missing
> bits, otherwise I'll rework the patch to only change the instances
> where clang emits the warning.
Fixing the issue everywhere is probably best. You might also need to look
under drivers/.
Will
^ permalink raw reply
* Tegra baseline test results for v4.11-rc8
From: Jon Hunter @ 2017-04-25 12:06 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.11-rc8.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.11-rc8/20170423173102/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.11-rc7 (4f7d029b9bf009fbee76bb10c0c4351a1870d2f3)):
text data bss total kernel
-268 +264 0 -4 defconfig
+896 +64 0 +960 multi_v7_defconfig
+428 0 0 +428 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.11-rc7 (4f7d029b9bf009fbee76bb10c0c4351a1870d2f3))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
--
nvpublic
^ permalink raw reply
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