* [PATCH 03/14] ARM: bugs: hook processor bug checking into SMP and suspend paths
From: Russell King @ 2018-05-16 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516105949.GJ16141@n2100.armlinux.org.uk>
Check for CPU bugs when secondary processors are being brought online,
and also when CPUs are resuming from a low power mode. This gives an
opportunity to check that processor specific bug workarounds are
correctly enabled for all paths that a CPU re-enters the kernel.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/include/asm/bugs.h | 2 ++
arch/arm/kernel/bugs.c | 5 +++++
arch/arm/kernel/smp.c | 4 ++++
arch/arm/kernel/suspend.c | 2 ++
4 files changed, 13 insertions(+)
diff --git a/arch/arm/include/asm/bugs.h b/arch/arm/include/asm/bugs.h
index ed122d294f3f..73a99c72a930 100644
--- a/arch/arm/include/asm/bugs.h
+++ b/arch/arm/include/asm/bugs.h
@@ -14,8 +14,10 @@ extern void check_writebuffer_bugs(void);
#ifdef CONFIG_MMU
extern void check_bugs(void);
+extern void check_other_bugs(void);
#else
#define check_bugs() do { } while (0)
+#define check_other_bugs() do { } while (0)
#endif
#endif
diff --git a/arch/arm/kernel/bugs.c b/arch/arm/kernel/bugs.c
index 88024028bb70..16e7ba2a9cc4 100644
--- a/arch/arm/kernel/bugs.c
+++ b/arch/arm/kernel/bugs.c
@@ -3,7 +3,12 @@
#include <asm/bugs.h>
#include <asm/proc-fns.h>
+void check_other_bugs(void)
+{
+}
+
void __init check_bugs(void)
{
check_writebuffer_bugs();
+ check_other_bugs();
}
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 2da087926ebe..5ad0b67b9e33 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -31,6 +31,7 @@
#include <linux/irq_work.h>
#include <linux/atomic.h>
+#include <asm/bugs.h>
#include <asm/smp.h>
#include <asm/cacheflush.h>
#include <asm/cpu.h>
@@ -405,6 +406,9 @@ asmlinkage void secondary_start_kernel(void)
* before we continue - which happens after __cpu_up returns.
*/
set_cpu_online(cpu, true);
+
+ check_other_bugs();
+
complete(&cpu_running);
local_irq_enable();
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index a40ebb7c0896..d08099269e35 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -3,6 +3,7 @@
#include <linux/slab.h>
#include <linux/mm_types.h>
+#include <asm/bugs.h>
#include <asm/cacheflush.h>
#include <asm/idmap.h>
#include <asm/pgalloc.h>
@@ -36,6 +37,7 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
cpu_switch_mm(mm->pgd, mm);
local_flush_bp_all();
local_flush_tlb_all();
+ check_other_bugs();
}
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH 02/14] ARM: bugs: prepare processor bug infrastructure
From: Russell King @ 2018-05-16 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516105949.GJ16141@n2100.armlinux.org.uk>
Prepare the processor bug infrastructure so that it can be expanded to
check for per-processor bugs.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/include/asm/bugs.h | 4 ++--
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/bugs.c | 9 +++++++++
3 files changed, 12 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/kernel/bugs.c
diff --git a/arch/arm/include/asm/bugs.h b/arch/arm/include/asm/bugs.h
index a97f1ea708d1..ed122d294f3f 100644
--- a/arch/arm/include/asm/bugs.h
+++ b/arch/arm/include/asm/bugs.h
@@ -10,10 +10,10 @@
#ifndef __ASM_BUGS_H
#define __ASM_BUGS_H
-#ifdef CONFIG_MMU
extern void check_writebuffer_bugs(void);
-#define check_bugs() check_writebuffer_bugs()
+#ifdef CONFIG_MMU
+extern void check_bugs(void);
#else
#define check_bugs() do { } while (0)
#endif
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index b59ac4bf82b8..8cad59465af3 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -31,6 +31,7 @@ else
obj-y += entry-armv.o
endif
+obj-$(CONFIG_MMU) += bugs.o
obj-$(CONFIG_CPU_IDLE) += cpuidle.o
obj-$(CONFIG_ISA_DMA_API) += dma.o
obj-$(CONFIG_FIQ) += fiq.o fiqasm.o
diff --git a/arch/arm/kernel/bugs.c b/arch/arm/kernel/bugs.c
new file mode 100644
index 000000000000..88024028bb70
--- /dev/null
+++ b/arch/arm/kernel/bugs.c
@@ -0,0 +1,9 @@
+// SPDX-Identifier: GPL-2.0
+#include <linux/init.h>
+#include <asm/bugs.h>
+#include <asm/proc-fns.h>
+
+void __init check_bugs(void)
+{
+ check_writebuffer_bugs();
+}
--
2.7.4
^ permalink raw reply related
* [PATCH 01/14] ARM: add CPU part numbers for Cortex A73, A75 and Brahma B15
From: Russell King @ 2018-05-16 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516105949.GJ16141@n2100.armlinux.org.uk>
Add CPU part numbers for the above mentioned CPUs
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/include/asm/cputype.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index cb546425da8a..adc4a3eef815 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -77,8 +77,13 @@
#define ARM_CPU_PART_CORTEX_A12 0x4100c0d0
#define ARM_CPU_PART_CORTEX_A17 0x4100c0e0
#define ARM_CPU_PART_CORTEX_A15 0x4100c0f0
+#define ARM_CPU_PART_CORTEX_A73 0x4100d090
+#define ARM_CPU_PART_CORTEX_A75 0x4100d0a0
#define ARM_CPU_PART_MASK 0xff00fff0
+/* Broadcom cores */
+#define ARM_CPU_PART_BRAHMA_B15 0x420000f0
+
/* DEC implemented cores */
#define ARM_CPU_PART_SA1100 0x4400a110
--
2.7.4
^ permalink raw reply related
* [PATCH 0/14] ARM Spectre variant 2 fixes
From: Russell King - ARM Linux @ 2018-05-16 10:59 UTC (permalink / raw)
To: linux-arm-kernel
This series addresses the Spectre variant 2 issues on ARM Cortex and
Broadcom Brahma B15 CPUs. Due to the complexity of the bug, it is not
possible to verify that this series fixes any of the bugs, since it
has not been able to reproduce these exact scenarios using test
programs.
I believe that this covers the entire extent of the Spectre variant 2
issues, with the exception of Cortex A53 and Cortex A72 processors as
these require a substantially more complex solution (except where the
workaround is implemented in PSCI firmware.)
Spectre variant 1 is not covered by this series.
The patch series is based partly on Marc Zyngier's work from February -
two of the KVM patches are from Marc's work.
The main differences are:
- Inclusion of more processors as per current ARM Ltd security update
documentation.
- Extension of "bugs" infrastructure to detect Cortex A8 and Cortex A15
CPUs missing out on the IBE bit being set on (re-)entry to the kernel
through all paths.
- Handle all suspect userspace-touching-kernelspace aborts irrespective
of mapping type.
The first patch will trivially conflict with the Broadcom Brahma
updates already in arm-soc - it has been necessary to independently
add the ID definitions for the B15 CPU.
Having worked through this series, I'm of the opinion that the
define_processor_functions macro in proc-v7 are probably more hassle
than they're worth - here, we don't need the global equivalent symbols,
because we never refer to them from the kernel code for any V7
processor (MULTI_CPU is always defined.)
This series is currently in my "spectre" branch (along with some
Spectre variant 1 patches.)
Please carefully review.
arch/arm/include/asm/bugs.h | 6 +-
arch/arm/include/asm/cp15.h | 3 +
arch/arm/include/asm/cputype.h | 5 ++
arch/arm/include/asm/kvm_asm.h | 2 -
arch/arm/include/asm/kvm_host.h | 14 +++-
arch/arm/include/asm/kvm_mmu.h | 23 +++++-
arch/arm/include/asm/proc-fns.h | 4 +
arch/arm/include/asm/system_misc.h | 8 ++
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/bugs.c | 18 +++++
arch/arm/kernel/smp.c | 4 +
arch/arm/kernel/suspend.c | 2 +
arch/arm/kvm/hyp/hyp-entry.S | 108 ++++++++++++++++++++++++-
arch/arm/mm/Kconfig | 23 ++++++
arch/arm/mm/Makefile | 2 +-
arch/arm/mm/fault.c | 3 +
arch/arm/mm/proc-macros.S | 3 +-
arch/arm/mm/proc-v7-2level.S | 6 --
arch/arm/mm/proc-v7-bugs.c | 130 ++++++++++++++++++++++++++++++
arch/arm/mm/proc-v7.S | 158 +++++++++++++++++++++++++++++--------
20 files changed, 471 insertions(+), 52 deletions(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] media: helene: fix tuning frequency of satellite
From: Abylay Ospan @ 2018-05-16 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516084111.28618-1-suzuki.katsuhiro@socionext.com>
True.
I'm curious but how did it worked before ...
Which hardware (dvb adapter) are you using ?
2018-05-16 4:41 GMT-04:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
> This patch fixes tuning frequency of satellite to kHz. That as same
> as terrestrial one.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> ---
> drivers/media/dvb-frontends/helene.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-frontends/helene.c b/drivers/media/dvb-frontends/helene.c
> index 04033f0c278b..0a4f312c4368 100644
> --- a/drivers/media/dvb-frontends/helene.c
> +++ b/drivers/media/dvb-frontends/helene.c
> @@ -523,7 +523,7 @@ static int helene_set_params_s(struct dvb_frontend *fe)
> enum helene_tv_system_t tv_system;
> struct dtv_frontend_properties *p = &fe->dtv_property_cache;
> struct helene_priv *priv = fe->tuner_priv;
> - int frequencykHz = p->frequency;
> + int frequencykHz = p->frequency / 1000;
> uint32_t frequency4kHz = 0;
> u32 symbol_rate = p->symbol_rate/1000;
>
> --
> 2.17.0
>
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
^ permalink raw reply
* [PATCH v2] media: helene: add I2C device probe function
From: Abylay Ospan @ 2018-05-16 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516083753.15510-1-suzuki.katsuhiro@socionext.com>
Hi Katsuhiro,
Thanks for patch.
What is the purpose to rework helene_set_params(_t|_s) ?
other part of this patch looks ok for me, but not tested due to lack
of spare time ;(
2018-05-16 4:37 GMT-04:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
> This patch adds I2C probe function to use dvb_module_probe()
> with this driver.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
>
> ---
>
> Changes since v1:
> - Add documents for dvb_frontend member of helene_config
> ---
> drivers/media/dvb-frontends/helene.c | 88 ++++++++++++++++++++++++++--
> drivers/media/dvb-frontends/helene.h | 3 +
> 2 files changed, 87 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/helene.c b/drivers/media/dvb-frontends/helene.c
> index a0d0b53c91d7..04033f0c278b 100644
> --- a/drivers/media/dvb-frontends/helene.c
> +++ b/drivers/media/dvb-frontends/helene.c
> @@ -666,7 +666,7 @@ static int helene_set_params_s(struct dvb_frontend *fe)
> return 0;
> }
>
> -static int helene_set_params(struct dvb_frontend *fe)
> +static int helene_set_params_t(struct dvb_frontend *fe)
> {
> u8 data[MAX_WRITE_REGSIZE];
> u32 frequency;
> @@ -835,6 +835,19 @@ static int helene_set_params(struct dvb_frontend *fe)
> return 0;
> }
>
> +static int helene_set_params(struct dvb_frontend *fe)
> +{
> + struct dtv_frontend_properties *p = &fe->dtv_property_cache;
> +
> + if (p->delivery_system == SYS_DVBT ||
> + p->delivery_system == SYS_DVBT2 ||
> + p->delivery_system == SYS_ISDBT ||
> + p->delivery_system == SYS_DVBC_ANNEX_A)
> + return helene_set_params_t(fe);
> +
> + return helene_set_params_s(fe);
> +}
> +
> static int helene_get_frequency(struct dvb_frontend *fe, u32 *frequency)
> {
> struct helene_priv *priv = fe->tuner_priv;
> @@ -843,7 +856,7 @@ static int helene_get_frequency(struct dvb_frontend *fe, u32 *frequency)
> return 0;
> }
>
> -static const struct dvb_tuner_ops helene_tuner_ops = {
> +static const struct dvb_tuner_ops helene_tuner_ops_t = {
> .info = {
> .name = "Sony HELENE Ter tuner",
> .frequency_min = 1000000,
> @@ -853,7 +866,7 @@ static const struct dvb_tuner_ops helene_tuner_ops = {
> .init = helene_init,
> .release = helene_release,
> .sleep = helene_sleep,
> - .set_params = helene_set_params,
> + .set_params = helene_set_params_t,
> .get_frequency = helene_get_frequency,
> };
>
> @@ -871,6 +884,20 @@ static const struct dvb_tuner_ops helene_tuner_ops_s = {
> .get_frequency = helene_get_frequency,
> };
>
> +static const struct dvb_tuner_ops helene_tuner_ops = {
> + .info = {
> + .name = "Sony HELENE Sat/Ter tuner",
> + .frequency_min = 500000,
> + .frequency_max = 1200000000,
> + .frequency_step = 1000,
> + },
> + .init = helene_init,
> + .release = helene_release,
> + .sleep = helene_sleep,
> + .set_params = helene_set_params,
> + .get_frequency = helene_get_frequency,
> +};
> +
> /* power-on tuner
> * call once after reset
> */
> @@ -1032,7 +1059,7 @@ struct dvb_frontend *helene_attach(struct dvb_frontend *fe,
> if (fe->ops.i2c_gate_ctrl)
> fe->ops.i2c_gate_ctrl(fe, 0);
>
> - memcpy(&fe->ops.tuner_ops, &helene_tuner_ops,
> + memcpy(&fe->ops.tuner_ops, &helene_tuner_ops_t,
> sizeof(struct dvb_tuner_ops));
> fe->tuner_priv = priv;
> dev_info(&priv->i2c->dev,
> @@ -1042,6 +1069,59 @@ struct dvb_frontend *helene_attach(struct dvb_frontend *fe,
> }
> EXPORT_SYMBOL(helene_attach);
>
> +static int helene_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct helene_config *config = client->dev.platform_data;
> + struct dvb_frontend *fe = config->fe;
> + struct device *dev = &client->dev;
> + struct helene_priv *priv;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->i2c_address = client->addr;
> + priv->i2c = client->adapter;
> + priv->set_tuner_data = config->set_tuner_priv;
> + priv->set_tuner = config->set_tuner_callback;
> + priv->xtal = config->xtal;
> +
> + if (fe->ops.i2c_gate_ctrl)
> + fe->ops.i2c_gate_ctrl(fe, 1);
> +
> + if (helene_x_pon(priv) != 0)
> + return -EINVAL;
> +
> + if (fe->ops.i2c_gate_ctrl)
> + fe->ops.i2c_gate_ctrl(fe, 0);
> +
> + memcpy(&fe->ops.tuner_ops, &helene_tuner_ops,
> + sizeof(struct dvb_tuner_ops));
> + fe->tuner_priv = priv;
> + i2c_set_clientdata(client, priv);
> +
> + dev_info(dev, "Sony HELENE attached on addr=%x at I2C adapter %p\n",
> + priv->i2c_address, priv->i2c);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id helene_id[] = {
> + { "helene", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, helene_id);
> +
> +static struct i2c_driver helene_driver = {
> + .driver = {
> + .name = "helene",
> + },
> + .probe = helene_probe,
> + .id_table = helene_id,
> +};
> +module_i2c_driver(helene_driver);
> +
> MODULE_DESCRIPTION("Sony HELENE Sat/Ter tuner driver");
> MODULE_AUTHOR("Abylay Ospan <aospan@netup.ru>");
> MODULE_LICENSE("GPL");
> diff --git a/drivers/media/dvb-frontends/helene.h b/drivers/media/dvb-frontends/helene.h
> index c9fc81c7e4e7..8562d01bc93e 100644
> --- a/drivers/media/dvb-frontends/helene.h
> +++ b/drivers/media/dvb-frontends/helene.h
> @@ -39,6 +39,7 @@ enum helene_xtal {
> * @set_tuner_callback: Callback function that notifies the parent driver
> * which tuner is active now
> * @xtal: Cristal frequency as described by &enum helene_xtal
> + * @fe: Frontend for which connects this tuner
> */
> struct helene_config {
> u8 i2c_address;
> @@ -46,6 +47,8 @@ struct helene_config {
> void *set_tuner_priv;
> int (*set_tuner_callback)(void *, int);
> enum helene_xtal xtal;
> +
> + struct dvb_frontend *fe;
> };
>
> #if IS_REACHABLE(CONFIG_DVB_HELENE)
> --
> 2.17.0
>
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
^ permalink raw reply
* [PATCH] media: helene: fix xtal frequency setting at power on
From: Abylay Ospan @ 2018-05-16 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516084120.28674-1-suzuki.katsuhiro@socionext.com>
Acked-by: Abylay Ospan <aospan@netup.ru>
2018-05-16 4:41 GMT-04:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
> This patch fixes crystal frequency setting when power on this device.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> ---
> drivers/media/dvb-frontends/helene.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-frontends/helene.c b/drivers/media/dvb-frontends/helene.c
> index 0a4f312c4368..8fcf7a00782a 100644
> --- a/drivers/media/dvb-frontends/helene.c
> +++ b/drivers/media/dvb-frontends/helene.c
> @@ -924,7 +924,10 @@ static int helene_x_pon(struct helene_priv *priv)
> helene_write_regs(priv, 0x99, cdata, sizeof(cdata));
>
> /* 0x81 - 0x94 */
> - data[0] = 0x18; /* xtal 24 MHz */
> + if (priv->xtal == SONY_HELENE_XTAL_16000)
> + data[0] = 0x10; /* xtal 16 MHz */
> + else
> + data[0] = 0x18; /* xtal 24 MHz */
> data[1] = (uint8_t)(0x80 | (0x04 & 0x1F)); /* 4 x 25 = 100uA */
> data[2] = (uint8_t)(0x80 | (0x26 & 0x7F)); /* 38 x 0.25 = 9.5pF */
> data[3] = 0x80; /* REFOUT signal output 500mVpp */
> --
> 2.17.0
>
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
^ permalink raw reply
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
From: Sudeep Holla @ 2018-05-16 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VciOAMX1HWifZ+K9GiVicZRFrwHaGteJFVe1uFrh+qu0w@mail.gmail.com>
Hi Andy,
On 15/05/18 20:32, Andy Shevchenko wrote:
> On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>
>>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>>> + cache_size = of_get_property(np, propname, NULL);
>>> if (cache_size)
>>> this_leaf->size = of_read_number(cache_size, 1);
>
> Can't you switch to of_read_property_uXX() variant here?
>
This patch is just changing the first argument to the calls. So if we
need to change, it has to be separate patch.
Now, we can use of_property_read_u64() but is there any particular
reason you mention that ? One reason I can see is that we can avoid
making explicit of_get_property call. Just wanted to the motive before I
can write the patch.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] arm64: Select ARCH_HAS_FAST_MULTIPLIER
From: Catalin Marinas @ 2018-05-16 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <877b532d8d240c1d9e9db923c84b924443a218ed.1524583390.git.robin.murphy@arm.com>
On Tue, Apr 24, 2018 at 04:25:47PM +0100, Robin Murphy wrote:
> It is probably safe to assume that all Armv8-A implementations have a
> multiplier whose efficiency is comparable or better than a sequence of
> three or so register-dependent arithmetic instructions. Select
> ARCH_HAS_FAST_MULTIPLIER to get ever-so-slightly nicer codegen in the
> few dusty old corners which care.
>
> In a contrived benchmark calling hweight64() in a loop, this does indeed
> turn out to be a small win overall, with no measurable impact on
> Cortex-A57 but about 5% performance improvement on Cortex-A53.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Queued for 4.18. Thanks.
--
Catalin
^ permalink raw reply
* [PULL v8] KVM: arm64: Optimise FPSIMD context switching
From: Dave Martin @ 2018-05-16 10:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi Marc,
This is a trivial update to the previously posted v7 [1]. The only
changes are a couple of minor cosmetic changes requested by reviewers,
on-list and the addition of Acked-by/Reviewed-by tags received since the
series was posted.
Let me know if you need anything else on this.
Cheers
---Dave
[1] [PATCH v7 00/16] KVM: arm64: Optimise FPSIMD context switching
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/576595.html
The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:
Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)
are available in the git repository at:
git://linux-arm.org/linux-dm.git
for you to fetch changes up to 90255dd95fe71a9bd1c4ce728abad4b0eec240d9:
KVM: arm64: Invoke FPSIMD context switch trap from C (2018-05-16 10:44:00 +0100)
----------------------------------------------------------------
Christoffer Dall (1):
KVM: arm/arm64: Introduce kvm_arch_vcpu_run_pid_change
Dave Martin (15):
thread_info: Add update_thread_flag() helpers
arm64: Use update{,_tsk}_thread_flag()
KVM: arm64: Convert lazy FPSIMD context switch trap to C
arm64: fpsimd: Generalise context saving for non-task contexts
arm64/sve: Refactor user SVE trap maintenance for external use
KVM: arm64: Repurpose vcpu_arch.debug_flags for general-purpose flags
KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing
arm64/sve: Move read_zcr_features() out of cpufeature.h
arm64/sve: Switch sve_pffr() argument from task to thread
arm64/sve: Move sve_pffr() to fpsimd.h and make inline
KVM: arm64: Save host SVE context as appropriate
KVM: arm64: Remove eager host SVE state saving
KVM: arm64: Remove redundant *exit_code changes in fpsimd_guest_exit()
KVM: arm64: Fold redundant exit code checks out of fixup_guest_exit()
KVM: arm64: Invoke FPSIMD context switch trap from C
arch/arm/include/asm/kvm_host.h | 9 ++-
arch/arm64/Kconfig | 7 ++
arch/arm64/include/asm/cpufeature.h | 29 -------
arch/arm64/include/asm/fpsimd.h | 21 ++++++
arch/arm64/include/asm/kvm_asm.h | 3 -
arch/arm64/include/asm/kvm_host.h | 32 +++++---
arch/arm64/include/asm/processor.h | 2 +
arch/arm64/kernel/fpsimd.c | 147 +++++++++++++++++++-----------------
arch/arm64/kernel/ptrace.c | 1 +
arch/arm64/kvm/Kconfig | 1 +
arch/arm64/kvm/Makefile | 2 +-
arch/arm64/kvm/debug.c | 8 +-
arch/arm64/kvm/fpsimd.c | 111 +++++++++++++++++++++++++++
arch/arm64/kvm/hyp/debug-sr.c | 6 +-
arch/arm64/kvm/hyp/entry.S | 43 -----------
arch/arm64/kvm/hyp/hyp-entry.S | 19 -----
arch/arm64/kvm/hyp/switch.c | 124 ++++++++++++++++++++----------
arch/arm64/kvm/hyp/sysreg-sr.c | 4 +-
arch/arm64/kvm/sys_regs.c | 9 +--
include/linux/kvm_host.h | 9 +++
include/linux/sched.h | 6 ++
include/linux/thread_info.h | 11 +++
virt/kvm/Kconfig | 3 +
virt/kvm/arm/arm.c | 25 +++++-
virt/kvm/kvm_main.c | 7 +-
25 files changed, 406 insertions(+), 233 deletions(-)
create mode 100644 arch/arm64/kvm/fpsimd.c
^ permalink raw reply
* [PATCH v2] arm64: Remove duplicate include
From: Catalin Marinas @ 2018-05-16 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1523630675-30687-1-git-send-email-vincenzo.frascino@arm.com>
On Fri, Apr 13, 2018 at 03:44:35PM +0100, Vincenzo Frascino wrote:
> "make includecheck" detected few duplicated includes in arch/arm64.
>
> This patch removes the double inclusions.
>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> ---
> arch/arm64/include/asm/kvm_mmu.h | 1 -
> arch/arm64/kernel/armv8_deprecated.c | 3 +--
> arch/arm64/kernel/fpsimd.c | 1 -
> arch/arm64/kernel/ptrace.c | 2 --
> 4 files changed, 1 insertion(+), 6 deletions(-)
Queued for 4.18. Thanks.
--
Catalin
^ permalink raw reply
* [PATCH] arm64: remove no-op macro VMLINUX_SYMBOL()
From: Catalin Marinas @ 2018-05-16 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525851986-28631-1-git-send-email-yamada.masahiro@socionext.com>
On Wed, May 09, 2018 at 04:46:26PM +0900, Masahiro Yamada wrote:
> VMLINUX_SYMBOL() is no-op unless CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX
> is defined. It has ever been selected only by BLACKFIN and METAG.
> VMLINUX_SYMBOL() is unneeded for ARM64-specific code.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Queued for 4.18. Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH v10 00/27] ARM: davinci: convert to common clock framework
From: Sekhar Nori @ 2018-05-16 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJUKGS_wm1O+HJBt2yY=BQ4169ka1p0264O-PJFdGj5Fdg@mail.gmail.com>
On Wednesday 16 May 2018 01:17 PM, Bartosz Golaszewski wrote:
> 2018-05-16 0:44 GMT+02:00 Adam Ford <aford173@gmail.com>:
>> On Tue, May 15, 2018 at 4:25 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>> 2018-05-14 2:40 GMT+02:00 Adam Ford <aford173@gmail.com>:
>>>> On Wed, May 9, 2018 at 12:25 PM, David Lechner <david@lechnology.com> wrote:
>>>>> This series converts mach-davinci to use the common clock framework.
>>>>>
>>>>> The series works like this, the first 3 patches fix some issues with the clock
>>>>> drivers that have already been accepted into the mainline kernel.
>>>>>
>>>>> Then, starting with "ARM: davinci: pass clock as parameter to
>>>>> davinci_timer_init()", we get the mach code ready for the switch by adding the
>>>>> code needed for the new clock drivers and adding #ifndef CONFIG_COMMON_CLK
>>>>> around the legacy clocks so that we can switch easily between the old and the
>>>>> new.
>>>>>
>>>>> "ARM: davinci: switch to common clock framework" actually flips the switch
>>>>> to start using the new clock drivers. Then the next 8 patches remove all
>>>>> of the old clock code.
>>>>>
>>>>> The final four patches add device tree clock support to the one SoC that
>>>>> supports it.
>>>>>
>>>>> This series has been tested on TI OMAP-L138 LCDK (both device tree and legacy
>>>>> board file).
>>>>>
>>>>
>>>> I am not sure if I did something wrong, but I attempted to build and I
>>>> wasn't able to boot the da850-evm.dtb your repo common-clk-v11,
>>>> however the legacy board file boot was OK.
>>>>
>>>> make davinci_all_defconfig ARCH=arm
>>>> make zImage modules da850-evm.dtb ARCH=arm CROSS_COMPILE=arm-linux- -j8
>>>>
>>>> 3140416 bytes read in 1464 ms (2 MiB/s)
>>>> 20353 bytes read in 15 ms (1.3 MiB/s)
>>>> ## Flattened Device Tree blob at c0600000
>>>> Booting using the fdt blob at 0xc0600000
>>>> Loading Device Tree to c7e57000, end c7e5ef80 ... OK
>>>>
>>>> Starting kernel ...
>>>>
>>>> Uncompressing Linux... done, booting the kernel.
>>>>
>>>> (and hang)
>>>>
>>>> If you have some suggestions, I am try them as I get time.
>>>>
>>>> adam
>>>>
>>>
>>> Runs fine on da850-lcdk and dm365-evm. I'll test the da850-evm
>>> tomorrow when I'll have access to it.
>>
>> I set the bootargs to: bootargs=console=ttyS2,115200n8
>> clk_ignore_unused root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
>>
>> I enabled DEBUG_LL and EARLY_PRINTK, yet when it loads, I only get:
With DEBUG_LL, you dont get any prints "automatically". You need add
printascii() calls where you need. I use the attached patch which
patches printk() calls with printascii()[1]
>>
>> ## Flattened Device Tree blob at c0600000
>> Booting using the fdt blob at 0xc0600000
>> Loading Device Tree to c7e57000, end c7e5ef35 ... OK
>>
>> Starting kernel ...
>>
>> Uncompressing Linux... done, booting the kernel.
>>
>>
>> I am doing this at my home, so I don't have a debugger for the
>> DA850-EVM. I am using a SOM that is an AM1808, but I vaguely remember
>> something about enabling a DSP clock somewhere, but I cannot seem to
>> find the e-mail. I know its counter intuitive that we'd need to
>> enable a clock that runs the DSP since it doesn't exist on the AM1808,
>> but I would have thought the clk_ignore_unused would have worked
>> around that issue.
>>
>> If someone else has a DA850-EVM or suggestions, I'm willing to try
>> them as I have time.
>>
>> adam
>
> Hi Adam,
>
> everything works fine for me both when booting the DTB and in legacy
> mode on da850-evm.
>
> I'm using the following bootargs:
> ip=dhcp console=ttyS2,115200n8 root=/dev/nfs rw nfsroot=<snip!>,v3
> nfsrootdebug
>
> Regular davinci_all_defconfig on David's common-clk-v11 branch.
Adam, if you still cannot get it to work, one problem could be that the
DT size has increased and its being overwritten. You could look at where
you are loading various binaries. Or append the .dtb to zImage and
switch on APPENDED_DTB config in kernel.
Thanks,
Sekhar
[1]
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 5b5a708..c3419c0 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1488,6 +1488,7 @@ static size_t cont_print_text(char *text, size_t size)
return textlen;
}
+void printascii(char *);
asmlinkage int vprintk_emit(int facility, int level,
const char *dict, size_t dictlen,
const char *fmt, va_list args)
@@ -1552,6 +1553,7 @@ asmlinkage int vprintk_emit(int facility, int level,
text_len--;
lflags |= LOG_NEWLINE;
}
+ printascii(text);
/* strip kernel syslog prefix and extract log level or control flags */
if (facility == 0) {
^ permalink raw reply related
* issue with kexec/kdump on imx6ull
From: Russell King - ARM Linux @ 2018-05-16 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516103120.GA17813@arthur-bzh>
On Wed, May 16, 2018 at 12:31:20PM +0200, Arthur LAMBERT wrote:
> Le Monday 09 Apr 2018 ? 15:31:23 (+0100), Russell King - ARM Linux a ?crit :
> >
> > > kernel command line: "console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw earlyprintk maxcpus=1 reset_devices elfcorehdr=0x9b100000 mem=50176K"
> >
> > This is the command line which the target kernel should boot with, but...
> >
> > > [ 0.000000] Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw crashkernel=50M
> >
> > it appears that it hasn't, so something is still wrong. Without the
> > right command line, you won't get the vmcore.
>
> Sorry for my very late answer Russell.
>
> We can see that kexec is able to build the correct command line but instead of booting with this kernel
> command line. Kexec boot the target kernel with default kernel command line.
>
> I am currently forcing kernel command line on my target kernel :
>
> CONFIG_CMDLINE="console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw earlyprintk crashkernel=50M"
> # CONFIG_CMDLINE_FROM_BOOTLOADER is not set
> # CONFIG_CMDLINE_EXTEND is not set
> CONFIG_CMDLINE_FORCE=y
I guess it's taken quite a while to track this down.
I wonder if we should encode that into the zImage, and have kexec print
a friendly error or warning message suggesting the kernel be more
appropriately configured.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] arm64: dts: juno: fix graph node unit addresses for coresight components
From: Sudeep Holla @ 2018-05-16 10:34 UTC (permalink / raw)
To: linux-arm-kernel
Currently the coresight components graph node unit addresses are
continuous for both input and output ports while the "reg" properties
are restarted for input and output ports separately. This results is
the following DTC warnings:
(graph_port): /etf at 20010000/ports/port at 1: graph node unit address error, expected "0"
(graph_port): /etf at 20140000/ports/port at 1: graph node unit address error, expected "0"
(graph_port): /funnel at 20040000/ports/port at 1: graph node unit address error, expected "0"
(graph_port): /funnel at 20040000/ports/port at 2: graph node unit address error, expected "1"
(graph_port): /funnel at 20040000/ports/port at 3: graph node unit address error, expected "2"
(graph_port): /funnel at 20130000/ports/port at 1: graph node unit address error, expected "0"
(graph_port): /funnel at 20150000/ports/port at 1: graph node unit address error, expected "0"
(graph_port): /funnel at 20150000/ports/port at 2: graph node unit address error, expected "1"
(graph_port): /funnel at 220c0000/ports/port at 1: graph node unit address error, expected "0"
(graph_port): /funnel at 220c0000/ports/port at 2: graph node unit address error, expected "1"
(graph_port): /funnel at 230c0000/ports/port at 1: graph node unit address error, expected "0"
(graph_port): /funnel at 230c0000/ports/port at 2: graph node unit address error, expected "1"
(graph_port): /funnel at 230c0000/ports/port at 3: graph node unit address error, expected "2"
(graph_port): /funnel at 230c0000/ports/port at 4: graph node unit address error, expected "3"
(graph_port): /replicator at 20120000/ports/port at 2: graph node unit address error, expected "0"
This patch makes even the reg property to follow the continuous
numbering as in the graph node unit address.
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 20 ++++++++++----------
arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 8 ++++----
arch/arm64/boot/dts/arm/juno.dts | 2 +-
3 files changed, 15 insertions(+), 15 deletions(-)
Hi Suzuki/Mathieu,
I did a quick scan @ drivers/hwtracing/coresight/of_coresight.c to check
if reg field is being used or not and whether this change causes any
regression. I don't think so, but I may be wrong, let me know.
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 708a15887af4..dbeca292a57c 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -131,7 +131,7 @@
/* output port */
port at 1 {
- reg = <0>;
+ reg = <1>;
etf0_out_port: endpoint {
};
};
@@ -175,7 +175,7 @@
/* input ports */
port at 1 {
- reg = <0>;
+ reg = <1>;
main_funnel_in_port0: endpoint {
slave-mode;
remote-endpoint = <&cluster0_funnel_out_port>;
@@ -183,7 +183,7 @@
};
port at 2 {
- reg = <1>;
+ reg = <2>;
main_funnel_in_port1: endpoint {
slave-mode;
remote-endpoint = <&cluster1_funnel_out_port>;
@@ -265,7 +265,7 @@
};
port at 1 {
- reg = <0>;
+ reg = <1>;
cluster0_funnel_in_port0: endpoint {
slave-mode;
remote-endpoint = <&cluster0_etm0_out_port>;
@@ -273,7 +273,7 @@
};
port at 2 {
- reg = <1>;
+ reg = <2>;
cluster0_funnel_in_port1: endpoint {
slave-mode;
remote-endpoint = <&cluster0_etm1_out_port>;
@@ -347,7 +347,7 @@
};
port at 1 {
- reg = <0>;
+ reg = <1>;
cluster1_funnel_in_port0: endpoint {
slave-mode;
remote-endpoint = <&cluster1_etm0_out_port>;
@@ -355,21 +355,21 @@
};
port at 2 {
- reg = <1>;
+ reg = <2>;
cluster1_funnel_in_port1: endpoint {
slave-mode;
remote-endpoint = <&cluster1_etm1_out_port>;
};
};
port at 3 {
- reg = <2>;
+ reg = <3>;
cluster1_funnel_in_port2: endpoint {
slave-mode;
remote-endpoint = <&cluster1_etm2_out_port>;
};
};
port at 4 {
- reg = <3>;
+ reg = <4>;
cluster1_funnel_in_port3: endpoint {
slave-mode;
remote-endpoint = <&cluster1_etm3_out_port>;
@@ -476,7 +476,7 @@
/* replicator input port */
port at 2 {
- reg = <0>;
+ reg = <2>;
replicator_in_port0: endpoint {
slave-mode;
};
diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
index 21287f2d75d3..a99f311c8dcb 100644
--- a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
@@ -21,7 +21,7 @@
/* input port */
port at 1 {
- reg = <0>;
+ reg = <1>;
csys1_funnel_in_port0: endpoint {
slave-mode;
};
@@ -52,7 +52,7 @@
/* output port */
port at 1 {
- reg = <0>;
+ reg = <1>;
etf1_out_port: endpoint {
remote-endpoint = <&csys2_funnel_in_port1>;
};
@@ -81,7 +81,7 @@
/* input ports */
port at 1 {
- reg = <0>;
+ reg = <1>;
csys2_funnel_in_port0: endpoint {
slave-mode;
remote-endpoint = <&etf0_out_port>;
@@ -89,7 +89,7 @@
};
port at 2 {
- reg = <1>;
+ reg = <2>;
csys2_funnel_in_port1: endpoint {
slave-mode;
remote-endpoint = <&etf1_out_port>;
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index aa3b341a7547..34e940e7465b 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -260,7 +260,7 @@
&main_funnel {
ports {
port at 3 {
- reg = <2>;
+ reg = <3>;
main_funnel_in_port2: endpoint {
slave-mode;
remote-endpoint = <&stm_out_port>;
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: KVM: reduce guest fpsimd trap
From: Dave Martin @ 2018-05-16 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4a812440-b5c6-8a11-a89d-0bad0e7d5150@arm.com>
On Wed, May 16, 2018 at 10:25:40AM +0100, Marc Zyngier wrote:
> [+Dave]
>
> Hi Nianyao,
>
> On 16/05/18 10:08, Tangnianyao (ICT) wrote:
> > Add last_fpsimd_trap to notify if guest last exit reason is handling fpsimd. If guest is using fpsimd frequently, save host's fpsimd state and restore guest's fpsimd state and deactive fpsimd trap before returning to guest. It can avoid guest fpsimd trap soon to improve performance.
So, the purpose of this patch is to context switch the FPSIMD state on
initial entry to the guest, instead of enabling the trap and context
switching the FPSIMD state lazily?
And you decide whether to do this or not, based on whether the guest
triggered a lazy FPSIMD switch previously?
> >
> > Signed-off-by: Nianyao Tang <tangnianyao@huawei.com>
> > ---
> > arch/arm64/kernel/asm-offsets.c | 1 +
> > arch/arm64/kvm/hyp/entry.S | 5 +++++
> > arch/arm64/kvm/hyp/switch.c | 38 ++++++++++++++++++++++++++++++++++++--
> > include/linux/kvm_host.h | 1 +
> > 4 files changed, 43 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c index 5bdda65..35a9c5c 100644
> > --- a/arch/arm64/kernel/asm-offsets.c
> > +++ b/arch/arm64/kernel/asm-offsets.c
> > @@ -136,6 +136,7 @@ int main(void)
> > #ifdef CONFIG_KVM_ARM_HOST
> > DEFINE(VCPU_CONTEXT, offsetof(struct kvm_vcpu, arch.ctxt));
> > DEFINE(VCPU_FAULT_DISR, offsetof(struct kvm_vcpu, arch.fault.disr_el1));
> > + DEFINE(VCPU_LAST_FPSIMD_TRAP, offsetof(struct kvm_vcpu,
> > + last_fpsimd_trap));
> > DEFINE(CPU_GP_REGS, offsetof(struct kvm_cpu_context, gp_regs));
> > DEFINE(CPU_USER_PT_REGS, offsetof(struct kvm_regs, regs));
> > DEFINE(CPU_FP_REGS, offsetof(struct kvm_regs, fp_regs));
> > diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S index e41a161..956e042 100644
> > --- a/arch/arm64/kvm/hyp/entry.S
> > +++ b/arch/arm64/kvm/hyp/entry.S
> > @@ -197,6 +197,11 @@ alternative_endif
> > add x0, x2, #CPU_GP_REG_OFFSET(CPU_FP_REGS)
> > bl __fpsimd_restore_state
> >
> > + // Mark guest using fpsimd now
> > + ldr x0, [x3, #VCPU_LAST_FPSIMD_TRAP]
> > + add x0, x0, #1
Can this overflow?
> > + str x0, [x3, #VCPU_LAST_FPSIMD_TRAP]
> > +
> > // Skip restoring fpexc32 for AArch64 guests
> > mrs x1, hcr_el2
> > tbnz x1, #HCR_RW_SHIFT, 1f
> > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c index d964523..86eea1b 100644
> > --- a/arch/arm64/kvm/hyp/switch.c
> > +++ b/arch/arm64/kvm/hyp/switch.c
> > @@ -92,7 +92,13 @@ static void activate_traps_vhe(struct kvm_vcpu *vcpu)
> >
> > val = read_sysreg(cpacr_el1);
> > val |= CPACR_EL1_TTA;
> > - val &= ~(CPACR_EL1_FPEN | CPACR_EL1_ZEN);
> > + val &= ~CPACR_EL1_ZEN;
> > +
> > + if (vcpu->last_fpsimd_trap)
> > + val |= CPACR_EL1_FPEN;
> > + else
> > + val &= ~CPACR_EL1_FPEN;
> > +
> > write_sysreg(val, cpacr_el1);
> >
> > write_sysreg(kvm_get_hyp_vector(), vbar_el1); @@ -105,7 +111,13 @@ static void __hyp_text __activate_traps_nvhe(struct kvm_vcpu *vcpu)
> > __activate_traps_common(vcpu);
> >
> > val = CPTR_EL2_DEFAULT;
> > - val |= CPTR_EL2_TTA | CPTR_EL2_TFP | CPTR_EL2_TZ;
> > + val |= CPTR_EL2_TTA | CPTR_EL2_TZ;
> > +
> > + if (vcpu->last_fpsimd_trap)
> > + val &= ~CPTR_EL2_TFP;
> > + else
> > + val |= CPTR_EL2_TFP;
> > +
> > write_sysreg(val, cptr_el2);
> > }
> >
> > @@ -406,6 +418,17 @@ int kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
> > __activate_traps(vcpu);
> > __activate_vm(vcpu->kvm);
> >
> > + /*
> > + * If guest last trap to host for handling fpsimd, last_fpsimd_trap
> > + * is set. Restore guest's fpsimd state and deactivate fpsimd trap
> > + * to avoid guest traping soon.
> > + */
> > + if (vcpu->last_fpsimd_trap) {
> > + __fpsimd_save_state(&host_ctxt->gp_regs.fp_regs);
> > + __fpsimd_restore_state(&guest_ctxt->gp_regs.fp_regs);
> > + vcpu->last_fpsimd_trap = 0;
> > + }
> > +
> > sysreg_restore_guest_state_vhe(guest_ctxt);
> > __debug_switch_to_guest(vcpu);
> >
> > @@ -454,6 +477,17 @@ int __hyp_text __kvm_vcpu_run_nvhe(struct kvm_vcpu *vcpu)
> > __activate_traps(vcpu);
> > __activate_vm(kern_hyp_va(vcpu->kvm));
> >
> > + /*
> > + * If guest last trap to host for handling fpsimd, last_fpsimd_trap
> > + * is set. Restore guest's fpsimd state and deactivate fpsimd trap
> > + * to avoid guest traping soon.
> > + */
> > + if (vcpu->last_fpsimd_trap) {
> > + __fpsimd_save_state(&host_ctxt->gp_regs.fp_regs);
> > + __fpsimd_restore_state(&guest_ctxt->gp_regs.fp_regs);
> > + vcpu->last_fpsimd_trap = 0;
> > + }
> > +
> > __hyp_vgic_restore_state(vcpu);
> > __timer_enable_traps(vcpu);
> >
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 6930c63..46bdf0d 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -274,6 +274,7 @@ struct kvm_vcpu {
> > bool preempted;
> > struct kvm_vcpu_arch arch;
> > struct dentry *debugfs_dentry;
> > + unsigned int last_fpsimd_trap;
> > };
> >
> > static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
> > --
> > 2.7.4
> >
>
> This doesn't seem to be the 100% correct. I can't see how this works
> when being preempted, for example... I suggest you look at Dave Martin's
> series[1], which does this correctly.
If I've understood correctly, this chooses between eager and lazy
switching, which is addressing a different issue from [1].
In effect, this code is attempting to predict whether the guest will
use FPSIMD before the next exit. If the prediction is correct and the
guest does use FPSIMD, then the overhead of the lazy FPSIMD trap
disappears. This is probably a good thing, though it may increase
interrupt latency a little. However, if the prediction is wrong and
the guest doesn't use FPSIMD before the next exit, then the overhead of
guest entry increases for no benefit, because FPSIMD was switched
unnecessarily.
Do you have any benchmarks or metrics on the accuracy of the
prediction and the overall impact on performance?
The changes in [1] should reduce the number of FPSIMD context switches
overall, so may reduce the benefit of this patch.
Cheers
---Dave
^ permalink raw reply
* issue with kexec/kdump on imx6ull
From: Arthur LAMBERT @ 2018-05-16 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180409143123.GA4251@n2100.armlinux.org.uk>
Le Monday 09 Apr 2018 ? 15:31:23 (+0100), Russell King - ARM Linux a ?crit :
>
> > kernel command line: "console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw earlyprintk maxcpus=1 reset_devices elfcorehdr=0x9b100000 mem=50176K"
>
> This is the command line which the target kernel should boot with, but...
>
> > [ 0.000000] Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw crashkernel=50M
>
> it appears that it hasn't, so something is still wrong. Without the
> right command line, you won't get the vmcore.
Sorry for my very late answer Russell.
We can see that kexec is able to build the correct command line but instead of booting with this kernel
command line. Kexec boot the target kernel with default kernel command line.
I am currently forcing kernel command line on my target kernel :
CONFIG_CMDLINE="console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw earlyprintk crashkernel=50M"
# CONFIG_CMDLINE_FROM_BOOTLOADER is not set
# CONFIG_CMDLINE_EXTEND is not set
CONFIG_CMDLINE_FORCE=y
By just using extend bootlader command line, it seems to be better :
CONFIG_CMDLINE="bazinga"
# CONFIG_CMDLINE_FROM_BOOTLOADER is not set
CONFIG_CMDLINE_EXTEND=y
# CONFIG_CMDLINE_FORCE is not set
New result :
[ 117.998829] Loading crashdump kernel...
[ 118.002830] Bye!
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.16.0-rc7KEXEC (arthur at arthur-bzh) (gcc version 5.4.0 (Buildroot 2017.05-git-38202-gb94bcd1-dirty)) #9 SMP Tue May 15 15:50:55 CEST 2018
[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Freescale i.MX6 UlltraLite 14x14 EVK Board
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x98000000
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Failed to reserve 64 MiB
[ 0.000000] random: fast init done
[ 0.000000] percpu: Embedded 16 pages/cpu @(ptrval) s36136 r8192 d21208 u65536
[ 0.000000] Built 1 zonelists, mobility grouping off. Total pages: 12446
[ 0.000000] Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw earlyprintk elfcorehdr=0x9b100000 mem=50176K bazinga
(...)
# cat /proc/cmdline
console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw earlyprintk elfcorehdr=0x9b100000 mem=50176K bazinga
# ls -l /proc/vmcore
-r-------- 1 root root 484450304 Jan 1 00:07 /proc/vmcore
Now I just need to compare behavior between kernel mainline and nxp bsp to understand and fix the kernel freeze
issue with the bsp. At least now I have a working setup. I will try to find some time to work on that
next week.
Do you have a reliable method to analyze vmcore from ARM architecture ?
On your first message you wrote :
>> There's also a ti-keystone2 branch which contains an additional
>> (hacky and untested) patch which allows reading the coredump
>> generated by kexec on a crash.
Thanks for your help !
^ permalink raw reply
* [PATCH v3 20/26] drm/mediatek: hdmi: provide an owner .odev device for the bridge
From: Philipp Zabel @ 2018-05-16 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-21-peda@axentia.se>
On Wed, 2018-05-16 at 12:15 +0200, Peter Rosin wrote:
> The .of_node member is going away.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 59a11026dceb..d8c7d93d0a87 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1694,8 +1694,8 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev)
>
> mtk_hdmi_register_audio_driver(dev);
>
> + hdmi->bridge.odev = &pdev->dev;
> hdmi->bridge.funcs = &mtk_hdmi_bridge_funcs;
> - hdmi->bridge.of_node = pdev->dev.of_node;
> drm_bridge_add(&hdmi->bridge);
>
> ret = mtk_hdmi_clk_enable_audio(hdmi);
^ permalink raw reply
* [GIT PULL ++] Immutable branch between MFD and PWM due for the v4.18 merge window (v2)
From: Lee Jones @ 2018-05-16 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516081910.GF5130@dell>
Subsequent pull-request containing additional bindings patch.
Enjoy!
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-pwm-v4.18-1
for you to fetch changes up to acc8e22f5d41558c90519aadc011b6d2839aedfe:
dt-bindings: mfd: stm32-timers: Add support for dmas (2018-05-16 11:13:13 +0100)
----------------------------------------------------------------
Immutable branch between MFD and PWM due for the v4.18 merge window (v2)
----------------------------------------------------------------
Fabrice Gasnier (5):
mfd: stm32-timers: Add support for DMAs
pwm: stm32: Add capture support
pwm: stm32: Improve capture by tuning counter prescaler
pwm: stm32: Use input prescaler to improve period capture
dt-bindings: mfd: stm32-timers: Add support for dmas
Documentation/devicetree/bindings/mfd/stm32-timers.txt | 20 ++++
drivers/mfd/stm32-timers.c | 201 +++++++++++++++++++++++++++++++-
drivers/pwm/pwm-stm32.c | 257 +++++++++++++++++++++++++++++++++++++++++
include/linux/mfd/stm32-timers.h | 58 ++++++++++
4 files changed, 534 insertions(+), 2 deletions(-)
--
Lee Jones [???]
Linaro Services Technical Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v3 26/26] drm/bridge: establish a link between the bridge supplier and consumer
From: Peter Rosin @ 2018-05-16 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-1-peda@axentia.se>
If the bridge supplier is unbound, this will bring the bridge consumer
down along with the bridge. Thus, there will no longer linger any
dangling pointers from the bridge consumer (the drm_device) to some
non-existent bridge supplier.
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
include/drm/drm_bridge.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 78d186b6831b..0259f0a3ff27 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -26,6 +26,7 @@
#include <linux/mutex.h>
#include <drm/drm_bridge.h>
+#include <drm/drm_device.h>
#include <drm/drm_encoder.h>
#include "drm_crtc_internal.h"
@@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
if (bridge->dev)
return -EBUSY;
+ if (encoder->dev->dev != bridge->odev) {
+ bridge->link = device_link_add(encoder->dev->dev,
+ bridge->odev, 0);
+ if (!bridge->link) {
+ dev_err(bridge->odev, "failed to link bridge to %s\n",
+ dev_name(encoder->dev->dev));
+ return -EINVAL;
+ }
+ }
+
bridge->dev = encoder->dev;
bridge->encoder = encoder;
if (bridge->funcs->attach) {
ret = bridge->funcs->attach(bridge);
if (ret < 0) {
+ if (bridge->link)
+ device_link_del(bridge->link);
+ bridge->link = NULL;
bridge->dev = NULL;
bridge->encoder = NULL;
return ret;
@@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
if (bridge->funcs->detach)
bridge->funcs->detach(bridge);
+ if (bridge->link)
+ device_link_del(bridge->link);
+ bridge->link = NULL;
+
bridge->dev = NULL;
}
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index b656e505d11e..bd1265c5a0bc 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -261,6 +261,7 @@ struct drm_bridge_timings {
* @list: to keep track of all added bridges
* @timings: the timing specification for the bridge, if any (may
* be NULL)
+ * @link: device link between the drm consumer and the bridge supplier
* @funcs: control functions
* @driver_private: pointer to the bridge driver's internal context
*/
@@ -271,6 +272,7 @@ struct drm_bridge {
struct drm_bridge *next;
struct list_head list;
const struct drm_bridge_timings *timings;
+ struct device_link *link;
const struct drm_bridge_funcs *funcs;
void *driver_private;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 25/26] drm/bridge: require the owner .odev to be filled in on drm_bridge_add/attach
From: Peter Rosin @ 2018-05-16 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-1-peda@axentia.se>
The .odev owner device will be handy to have around.
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/drm_bridge.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index df084db33494..78d186b6831b 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -70,6 +70,9 @@ static LIST_HEAD(bridge_list);
*/
void drm_bridge_add(struct drm_bridge *bridge)
{
+ if (WARN_ON(!bridge->odev))
+ return;
+
mutex_lock(&bridge_lock);
list_add_tail(&bridge->list, &bridge_list);
mutex_unlock(&bridge_lock);
@@ -115,6 +118,9 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
if (!encoder || !bridge)
return -EINVAL;
+ if (WARN_ON(!bridge->odev))
+ return -EINVAL;
+
if (previous && (!previous->dev || previous->encoder != encoder))
return -EINVAL;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 24/26] drm/bridge: remove the .of_node member
From: Peter Rosin @ 2018-05-16 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-1-peda@axentia.se>
It is unused.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/drm_bridge.c | 3 +--
drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 --
include/drm/drm_bridge.h | 4 ----
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 3872f5379998..df084db33494 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -365,8 +365,7 @@ struct drm_bridge *of_drm_find_bridge(struct device_node *np)
mutex_lock(&bridge_lock);
list_for_each_entry(bridge, &bridge_list, list) {
- if ((bridge->odev && bridge->odev->of_node == np) ||
- bridge->of_node == np) {
+ if (bridge->odev->of_node == np) {
mutex_unlock(&bridge_lock);
return bridge;
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 557e0079c98d..e77d4c909582 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -377,8 +377,6 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
}
if (lvds->panel)
remote = lvds->panel->dev->of_node;
- else if (lvds->bridge->of_node)
- remote = lvds->bridge->of_node;
else
remote = lvds->bridge->odev->of_node;
if (of_property_read_string(dev->of_node, "rockchip,output", &name))
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 7c17977c3537..b656e505d11e 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -258,7 +258,6 @@ struct drm_bridge_timings {
* @dev: DRM device this bridge belongs to
* @encoder: encoder to which this bridge is connected
* @next: the next bridge in the encoder chain
- * @of_node: device node pointer to the bridge
* @list: to keep track of all added bridges
* @timings: the timing specification for the bridge, if any (may
* be NULL)
@@ -270,9 +269,6 @@ struct drm_bridge {
struct drm_device *dev;
struct drm_encoder *encoder;
struct drm_bridge *next;
-#ifdef CONFIG_OF
- struct device_node *of_node;
-#endif
struct list_head list;
const struct drm_bridge_timings *timings;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 20/26] drm/mediatek: hdmi: provide an owner .odev device for the bridge
From: Peter Rosin @ 2018-05-16 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-1-peda@axentia.se>
The .of_node member is going away.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 59a11026dceb..d8c7d93d0a87 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1694,8 +1694,8 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev)
mtk_hdmi_register_audio_driver(dev);
+ hdmi->bridge.odev = &pdev->dev;
hdmi->bridge.funcs = &mtk_hdmi_bridge_funcs;
- hdmi->bridge.of_node = pdev->dev.of_node;
drm_bridge_add(&hdmi->bridge);
ret = mtk_hdmi_clk_enable_audio(hdmi);
--
2.11.0
^ permalink raw reply related
* [PATCH v3 19/26] drm/exynos: mic: provide an owner .odev device for the bridge
From: Peter Rosin @ 2018-05-16 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-1-peda@axentia.se>
The .of_node member is going away.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 2174814273e2..f9ff8d3ec937 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -417,8 +417,8 @@ static int exynos_mic_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mic);
+ mic->bridge.odev = dev;
mic->bridge.funcs = &mic_bridge_funcs;
- mic->bridge.of_node = dev->of_node;
drm_bridge_add(&mic->bridge);
--
2.11.0
^ permalink raw reply related
* [PATCH v3 01/26] drm/bridge: allow optionally specifying an owner .odev device
From: Peter Rosin @ 2018-05-16 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-1-peda@axentia.se>
Bridge drivers can now (temporarily, in a transition phase) select if
they want to provide a full owner device or keep just providing an
of_node.
By providing a full owner device, the bridge drivers no longer need
to provide an of_node since that node is available via the owner
device.
When all bridge drivers provide an owner device, that will become
mandatory and the .of_node member will be removed.
There is an interaction with the rockchip lvds driver, since that
driver peeks into somewhat private parts of the bridge struct in
order to find out things about the remote bridge. When there are
now two ways to get to the remote bridge, the rockchip lvds driver
has to adapt. That said, the correct thing to do for the rockchip
lvds driver is to use some other way than DT to find things out
about the remote bridge, but that is orthogonal to this patch.
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/drm_bridge.c | 3 ++-
drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
include/drm/drm_bridge.h | 2 ++
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 1638bfe9627c..3872f5379998 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -365,7 +365,8 @@ struct drm_bridge *of_drm_find_bridge(struct device_node *np)
mutex_lock(&bridge_lock);
list_for_each_entry(bridge, &bridge_list, list) {
- if (bridge->of_node == np) {
+ if ((bridge->odev && bridge->odev->of_node == np) ||
+ bridge->of_node == np) {
mutex_unlock(&bridge_lock);
return bridge;
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 4bd94b167d2c..557e0079c98d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -377,8 +377,10 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
}
if (lvds->panel)
remote = lvds->panel->dev->of_node;
- else
+ else if (lvds->bridge->of_node)
remote = lvds->bridge->of_node;
+ else
+ remote = lvds->bridge->odev->of_node;
if (of_property_read_string(dev->of_node, "rockchip,output", &name))
/* default set it as output rgb */
lvds->output = DISPLAY_OUTPUT_RGB;
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 3270fec46979..7c17977c3537 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -254,6 +254,7 @@ struct drm_bridge_timings {
/**
* struct drm_bridge - central DRM bridge control structure
+ * @odev: device that owns the bridge
* @dev: DRM device this bridge belongs to
* @encoder: encoder to which this bridge is connected
* @next: the next bridge in the encoder chain
@@ -265,6 +266,7 @@ struct drm_bridge_timings {
* @driver_private: pointer to the bridge driver's internal context
*/
struct drm_bridge {
+ struct device *odev;
struct drm_device *dev;
struct drm_encoder *encoder;
struct drm_bridge *next;
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox