* Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
From: Sudeep Holla @ 2019-06-20 11:15 UTC (permalink / raw)
To: Peng Fan
Cc: robh+dt@kernel.org, mark.rutland@arm.com,
jassisinghbrar@gmail.com, f.fainelli@gmail.com,
kernel@pengutronix.de, dl-linux-imx, shawnguo@kernel.org,
festevam@gmail.com, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, andre.przywara@arm.com,
van.freenix@gmail.com, Sudeep Holla
In-Reply-To: <AM0PR04MB4481203DE76D290F311E3BFA88E40@AM0PR04MB4481.eurprd04.prod.outlook.com>
On Thu, Jun 20, 2019 at 10:21:09AM +0000, Peng Fan wrote:
> Hi Sudeep,
>
> > Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
> >
> > On Mon, Jun 03, 2019 at 04:30:05PM +0800, peng.fan@nxp.com wrote:
> > > From: Peng Fan <peng.fan@nxp.com>
> > >
> > > This mailbox driver implements a mailbox which signals transmitted
> > > data via an ARM smc (secure monitor call) instruction. The mailbox
> > > receiver is implemented in firmware and can synchronously return data
> > > when it returns execution to the non-secure world again.
> > > An asynchronous receive path is not implemented.
> > > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > > which either don't have a separate management processor or on which
> > > such a core is not available. A user of this mailbox could be the SCP
> > > interface.
> > >
> > > Modified from Andre Przywara's v2 patch
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7
> > Cpeng.fa
> > >
> > n%40nxp.com%7C6b37f78032e446be750e08d6f560e707%7C686ea1d3bc2b4
> > c6fa92cd
> > >
> > 99c5c301635%7C0%7C0%7C636966193913988679&sdata=UNM4MTPs
> > brqoMqWStEy
> > > YzzwMEWTmX7hHO3TeNEz%2BOAw%3D&reserved=0
> > >
> > > Cc: Andre Przywara <andre.przywara@arm.com>
> > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > ---
> > >
> > > V2:
> > > Add interrupts notification support.
> > >
> > > drivers/mailbox/Kconfig | 7 ++
> > > drivers/mailbox/Makefile | 2 +
> > > drivers/mailbox/arm-smc-mailbox.c | 190
> > ++++++++++++++++++++++++++++++++
> > > include/linux/mailbox/arm-smc-mailbox.h | 10 ++
> > > 4 files changed, 209 insertions(+)
> > > create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode
> > > 100644 include/linux/mailbox/arm-smc-mailbox.h
> > >
> > > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > > 595542bfae85..c3bd0f1ddcd8 100644
> > > --- a/drivers/mailbox/Kconfig
> > > +++ b/drivers/mailbox/Kconfig
> > > @@ -15,6 +15,13 @@ config ARM_MHU
> > > The controller has 3 mailbox channels, the last of which can be
> > > used in Secure mode only.
> > >
> > > +config ARM_SMC_MBOX
> > > + tristate "Generic ARM smc mailbox"
> > > + depends on OF && HAVE_ARM_SMCCC
> > > + help
> > > + Generic mailbox driver which uses ARM smc calls to call into
> > > + firmware for triggering mailboxes.
> > > +
> > > config IMX_MBOX
> > > tristate "i.MX Mailbox"
> > > depends on ARCH_MXC || COMPILE_TEST
> > > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > > c22fad6f696b..93918a84c91b 100644
> > > --- a/drivers/mailbox/Makefile
> > > +++ b/drivers/mailbox/Makefile
> > > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> > >
> > > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> > >
> > > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > > +
> > > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> > >
> > > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX) +=
> > armada-37xx-rwtm-mailbox.o
> > > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > > b/drivers/mailbox/arm-smc-mailbox.c
> > > new file mode 100644
> > > index 000000000000..fef6e38d8b98
> > > --- /dev/null
> > > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > > @@ -0,0 +1,190 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Copyright (C) 2016,2017 ARM Ltd.
> > > + * Copyright 2019 NXP
> > > + */
> > > +
> > > +#include <linux/arm-smccc.h>
> > > +#include <linux/device.h>
> > > +#include <linux/kernel.h>
> > > +#include <linux/interrupt.h>
> > > +#include <linux/mailbox_controller.h> #include
> > > +<linux/mailbox/arm-smc-mailbox.h>
> > > +#include <linux/module.h>
> > > +#include <linux/platform_device.h>
> > > +
> > > +#define ARM_SMC_MBOX_USE_HVC BIT(0)
> > > +#define ARM_SMC_MBOX_USB_IRQ BIT(1)
> > > +
> > > +struct arm_smc_chan_data {
> > > + u32 function_id;
> > > + u32 flags;
> > > + int irq;
> > > +};
> > > +
> > > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > > + struct arm_smc_chan_data *chan_data = link->con_priv;
> > > + struct arm_smccc_mbox_cmd *cmd = data;
> > > + struct arm_smccc_res res;
> > > + u32 function_id;
> > > +
> > > + if (chan_data->function_id != UINT_MAX)
> > > + function_id = chan_data->function_id;
> > > + else
> > > + function_id = cmd->a0;
> > > +
> > > + if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
> > > + arm_smccc_hvc(function_id, cmd->a1, cmd->a2, cmd->a3,
> > cmd->a4,
> > > + cmd->a5, cmd->a6, cmd->a7, &res);
> > > + else
> > > + arm_smccc_smc(function_id, cmd->a1, cmd->a2, cmd->a3,
> > cmd->a4,
> > > + cmd->a5, cmd->a6, cmd->a7, &res);
> > > +
> >
> > So how will the SMC/HVC handler in EL3/2 find which mailbox is being
> > referred with this command ? I prefer 2nd argument to be the mailbox
> > number.
> You mean channel number as following?
>
> @@ -37,10 +38,10 @@ static int arm_smc_send_data(struct mbox_chan *link, void *data)
> function_id = cmd->a0;
>
> if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
> - arm_smccc_hvc(function_id, cmd->a1, cmd->a2, cmd->a3, cmd->a4,
> + arm_smccc_hvc(function_id, chan_data->chan_id, cmd->a2, cmd->a3, cmd->a4,
> cmd->a5, cmd->a6, cmd->a7, &res);
> else
> - arm_smccc_smc(function_id, cmd->a1, cmd->a2, cmd->a3, cmd->a4,
> + arm_smccc_smc(function_id, chan_data->chan_id, cmd->a2, cmd->a3, cmd->a4,
> cmd->a5, cmd->a6, cmd->a7, &res);
>
Yes something like above. There's a brief description of the same in
latest SCMI specification though it's not related to SCMI, it more
general note for SMC based mailbox.
"In case the doorbell is SMC/HVC based, it should follow the SMC Calling
Convention [SMCCC] and needs to provide the identifier of the Shared Memory
area that contains the payload. On return from the call, the Shared Memory
area which contained the payload is now updated with the SCMI return response.
The identifier of the Shared Memory area should be 32-bits and each identifier
should denote a distinct Shared Memory area."
> Or should that be passed from firmware driver?
>
No, we can't assume the id's in DT are 1-1 translation to mailbox ID used
though it may be the same most of the time.
> If not from firmware driver, just as above, I do not have a good idea which
> should be passed to smc, from cmd->a1 to a5 or from cmd->a2 to a6.
>
Also I found copying those registers may not be always needed and can
be sub-optimal. May be a way to indicate that this in DT whether
register based transfers are used or using memory. Just a thought.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH V6 00/27] Enable Tegra PCIe root port features
From: Thierry Reding @ 2019-06-20 11:14 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Bjorn Helgaas, Manikanta Maddireddy, robh+dt, mark.rutland,
jonathanh, vidyas, linux-tegra, linux-pci, devicetree
In-Reply-To: <20190620105301.GA23729@e121166-lin.cambridge.arm.com>
[-- Attachment #1: Type: text/plain, Size: 4230 bytes --]
On Thu, Jun 20, 2019 at 11:53:01AM +0100, Lorenzo Pieralisi wrote:
> On Thu, Jun 20, 2019 at 12:25:52PM +0200, Thierry Reding wrote:
> > On Tue, Jun 18, 2019 at 11:31:39PM +0530, Manikanta Maddireddy wrote:
> > > This series of patches adds,
> > > - Tegra root port features like Gen2, AER, etc
> > > - Power and perf optimizations
> > > - Fixes like "power up sequence", "dev_err prints", etc
> > >
> > > This series of patches are tested on Tegra186 based Jetson-TX2, Tegra210
> > > based Jetson-TX1, T124 based Jetson-TK1, Tegra20 and Tegra30 platforms.
> > >
> > > Changes from V5 to V6:
> > > - Patch [V4, 20/27]: Replaced pcie_pme_disable_msi() with no_msi quirk
> > >
> > > Changes from V4 to V5:
> > > - Patch [V4, 4/28]: Added blank line before block style comment
> > > - Patch [V4, 22/28]: "Access endpoint config only if PCIe link is up"
> > > patch is dropped
> > > - Patch [V4, 27/28]:
> > > * Updated reset gpio toggle logic to reflect active low usage
> > > * Replaced kasprintf() with devm_kasprintf()
> > > * Updated commit message with more information.
> > >
> > > Changes from V3 to V4:
> > > - Patch [V3,27/29] is dropped
> > > - Patch [V3,28/29]: devm_gpiod_get_from_of_node() is directly used in
> > > pci-tegra driver instead of of_get_pci* wrapper function defined in
> > > Patch [V3,27/29].
> > >
> > > Manikanta Maddireddy (27):
> > > soc/tegra: pmc: Export tegra_powergate_power_on()
> > > PCI: tegra: Handle failure cases in tegra_pcie_power_on()
> > > PCI: tegra: Rearrange Tegra PCIe driver functions
> > > PCI: tegra: Mask AFI_INTR in runtime suspend
> > > PCI: tegra: Fix PCIe host power up sequence
> > > PCI: tegra: Add PCIe Gen2 link speed support
> > > PCI: tegra: Advertise PCIe Advanced Error Reporting (AER) capability
> > > PCI: tegra: Program UPHY electrical settings for Tegra210
> > > PCI: tegra: Enable opportunistic UpdateFC and ACK
> > > PCI: tegra: Disable AFI dynamic clock gating
> > > PCI: tegra: Process pending DLL transactions before entering L1 or L2
> > > PCI: tegra: Enable PCIe xclk clock clamping
> > > PCI: tegra: Increase the deskew retry time
> > > PCI: tegra: Add SW fixup for RAW violations
> > > PCI: tegra: Update flow control timer frequency in Tegra210
> > > PCI: tegra: Set target speed as Gen1 before starting LTSSM
> > > PCI: tegra: Fix PLLE power down issue due to CLKREQ# signal
> > > PCI: tegra: Program AFI_CACHE* registers only for Tegra20
> > > PCI: tegra: Change PRSNT_SENSE IRQ log to debug
> > > PCI: tegra: Disable MSI for Tegra PCIe root port
> > > PCI: tegra: Add AFI_PEX2_CTRL reg offset as part of soc struct
> > > dt-bindings: pci: tegra: Document PCIe DPD pinctrl optional prop
> > > arm64: tegra: Add PEX DPD states as pinctrl properties
> > > PCI: tegra: Put PEX CLK & BIAS pads in DPD mode
> > > PCI: Add DT binding for "reset-gpios" property
> > > PCI: tegra: Add support for GPIO based PERST#
> > > PCI: tegra: Change link retry log level to debug
> >
> > Hi Lorenzo, Bjorn,
> >
> > There's a build-time dependency from the PCI patches on patch 1 of this
> > series. I've already Acked that, so I think you should take it through
> > the PCI tree along with the rest of the series.
> >
> > The only patch that I picked up is the DT change in patch 23, which is
> > decoupled from the others via DT, though the data that it adds to DT
> > will be used in patch 24.
> >
> > Does that sound good to you?
>
> Yes, I will drop patch 20 too as requested. Is there a merge ordering
> dependency between patch 23 and 24 ? If yes we should let Bjorn know
> or you drop patch 23 and I will merge it via PCI, let us know.
Nope, I don't think there are any issues with ordering. Patch 23
basically just adds the DT content that will be used by patch 24 to
dynamically change the pinmux options. Without patch 24, the default
state will be applied, which is what the state will be on boot anyway.
Patch 24 without patch 23 would mean that the PCI driver will try to
select a pinctrl state which does not exist, but this is already handled
gracefully in pinctrl_pm_select_state().
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2 3/3] recipes-bsp/u-boot: update to the latest version
From: ayaka @ 2019-06-20 11:14 UTC (permalink / raw)
To: yocto; +Cc: Randy Li, romain.perier
In-Reply-To: <20190620111410.4573-1-ayaka@soulik.info>
From: Randy Li <ayaka@soulik.info>
Signed-off-by: Randy Li <ayaka@soulik.info>
---
recipes-bsp/u-boot/u-boot-rockchip_git.bb | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 recipes-bsp/u-boot/u-boot-rockchip_git.bb
diff --git a/recipes-bsp/u-boot/u-boot-rockchip_git.bb b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
new file mode 100644
index 0000000..5b04b62
--- /dev/null
+++ b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
@@ -0,0 +1,19 @@
+# Copyright (C) 2019 SUMOMO Computer Assocation
+# Released under the MIT license (see COPYING.MIT for the terms)
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+include u-boot-rockchip.inc
+
+DESCRIPTION = "Rockchip U-Boot"
+
+LIC_FILES_CHKSUM = "file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
+
+SRC_URI = " \
+ git://github.com/rockchip-linux/u-boot.git;branch=release; \
+ file://gcc7_fixup.patch \
+ file://gcc9-no-Werror.patch \
+"
+SRCREV = "${AUTOREV}"
+
+S = "${WORKDIR}/git"
+PV = "v2019.01"
--
2.21.0
^ permalink raw reply related
* [PATCH v2 2/3] recipes-bsp/u-boot: update build rules
From: ayaka @ 2019-06-20 11:14 UTC (permalink / raw)
To: yocto; +Cc: Randy 'ayaka' Li, romain.perier
In-Reply-To: <20190620111410.4573-1-ayaka@soulik.info>
From: Randy 'ayaka' Li <ayaka@soulik.info>
Adding the missing recipes header file.
Fixing the compiler error after oe-core update.
Disabled the -Werror flag which would break the build due to
update of toolchain.
Signed-off-by: Randy 'ayaka' Li <ayaka@soulik.info>
---
recipes-bsp/u-boot/u-boot-rockchip.inc | 12 ++++++++++++
.../u-boot/u-boot-rockchip/gcc9-no-Werror.patch | 13 +++++++++++++
recipes-bsp/u-boot/u-boot-rockchip_20171218.bb | 4 ++++
3 files changed, 29 insertions(+)
create mode 100644 recipes-bsp/u-boot/u-boot-rockchip/gcc9-no-Werror.patch
diff --git a/recipes-bsp/u-boot/u-boot-rockchip.inc b/recipes-bsp/u-boot/u-boot-rockchip.inc
index 5d89cd6..8815ac8 100644
--- a/recipes-bsp/u-boot/u-boot-rockchip.inc
+++ b/recipes-bsp/u-boot/u-boot-rockchip.inc
@@ -2,6 +2,7 @@
# Copyright (C) 2017 Trevor Woerner <twoerner@gmail.com>
# Released under the MIT license (see COPYING.MIT for the terms)
+require recipes-bsp/u-boot/u-boot-common.inc
require recipes-bsp/u-boot/u-boot.inc
DESCRIPTION = "Rockchip next-dev U-Boot"
@@ -14,6 +15,17 @@ DEPENDS = "dtc-native bc-native swig-native"
# u-boot will build native python module
inherit pythonnative
+do_configure () {
+ if [ -z "${UBOOT_CONFIG}" ]; then
+ if [ -n "${UBOOT_MACHINE}" ]; then
+ oe_runmake -C ${S} O=${B} ${UBOOT_MACHINE}
+ else
+ oe_runmake -C ${S} O=${B} oldconfig
+ fi
+ cml1_do_configure
+ fi
+}
+
do_compile_prepend () {
export STAGING_INCDIR=${STAGING_INCDIR_NATIVE};
export STAGING_LIBDIR=${STAGING_LIBDIR_NATIVE};
diff --git a/recipes-bsp/u-boot/u-boot-rockchip/gcc9-no-Werror.patch b/recipes-bsp/u-boot/u-boot-rockchip/gcc9-no-Werror.patch
new file mode 100644
index 0000000..198d846
--- /dev/null
+++ b/recipes-bsp/u-boot/u-boot-rockchip/gcc9-no-Werror.patch
@@ -0,0 +1,13 @@
+diff --git a/Makefile b/Makefile
+index a2e1a09674..3697ece6fc 100644
+--- a/Makefile
++++ b/Makefile
+@@ -360,7 +360,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__ -D__UBOOT__
+ KBUILD_CFLAGS := -Wall -Wstrict-prototypes \
+ -Wno-format-security \
+ -fno-builtin -ffreestanding
+-KBUILD_CFLAGS += -fshort-wchar -Werror
++KBUILD_CFLAGS += -fshort-wchar
+ KBUILD_AFLAGS := -D__ASSEMBLY__
+
+ # Read UBOOTRELEASE from include/config/uboot.release (if it exists)
diff --git a/recipes-bsp/u-boot/u-boot-rockchip_20171218.bb b/recipes-bsp/u-boot/u-boot-rockchip_20171218.bb
index 4545f13..f4ecbae 100644
--- a/recipes-bsp/u-boot/u-boot-rockchip_20171218.bb
+++ b/recipes-bsp/u-boot/u-boot-rockchip_20171218.bb
@@ -9,5 +9,9 @@ TAG = "release-${PV}"
SRC_URI = " \
git://github.com/rockchip-linux/u-boot.git;tag=${TAG};nobranch=1; \
file://binutils-2.28-ld-fix.patch \
+ file://gcc7_fixup.patch \
+ file://gcc9-no-Werror.patch \
"
S = "${WORKDIR}/git"
+
+SRCREV = "release-20171218"
--
2.21.0
^ permalink raw reply related
* [PATCH v2 1/3] recipes-bsp/u-boot: fixup build for gcc7
From: ayaka @ 2019-06-20 11:14 UTC (permalink / raw)
To: yocto; +Cc: Randy Li, Randy 'ayaka' Li, romain.perier
In-Reply-To: <20190620111410.4573-1-ayaka@soulik.info>
From: Randy 'ayaka' Li <ayaka@soulik.info>
Signed-off-by: Randy Li <randy.li@rock-chips.com>
Signed-off-by: Randy 'ayaka' Li <ayaka@soulik.info>
---
.../u-boot/u-boot-rockchip/gcc7_fixup.patch | 38 +++++++++++++++++++
1 file changed, 38 insertions(+)
create mode 100644 recipes-bsp/u-boot/u-boot-rockchip/gcc7_fixup.patch
diff --git a/recipes-bsp/u-boot/u-boot-rockchip/gcc7_fixup.patch b/recipes-bsp/u-boot/u-boot-rockchip/gcc7_fixup.patch
new file mode 100644
index 0000000..ccb709a
--- /dev/null
+++ b/recipes-bsp/u-boot/u-boot-rockchip/gcc7_fixup.patch
@@ -0,0 +1,38 @@
+diff --git a/include/linux/log2.h b/include/linux/log2.h
+index aa1de63090..5526af036d 100644
+--- a/include/linux/log2.h
++++ b/include/linux/log2.h
+@@ -12,12 +12,6 @@
+ #include <linux/types.h>
+ #include <linux/bitops.h>
+
+-/*
+- * deal with unrepresentable constant logarithms
+- */
+-extern __attribute__((const, noreturn))
+-int ____ilog2_NaN(void);
+-
+ /*
+ * non-constant log of base 2 calculators
+ * - the arch may override these in asm/bitops.h if they can be implemented
+@@ -82,7 +76,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
+ #define ilog2(n) \
+ ( \
+ __builtin_constant_p(n) ? ( \
+- (n) < 1 ? ____ilog2_NaN() : \
++ (n) < 2 ? 0 : \
+ (n) & (1ULL << 63) ? 63 : \
+ (n) & (1ULL << 62) ? 62 : \
+ (n) & (1ULL << 61) ? 61 : \
+@@ -145,10 +139,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
+ (n) & (1ULL << 4) ? 4 : \
+ (n) & (1ULL << 3) ? 3 : \
+ (n) & (1ULL << 2) ? 2 : \
+- (n) & (1ULL << 1) ? 1 : \
+- (n) & (1ULL << 0) ? 0 : \
+- ____ilog2_NaN() \
+- ) : \
++ 1 ) : \
+ (sizeof(n) <= 4) ? \
+ __ilog2_u32(n) : \
+ __ilog2_u64(n) \
--
2.21.0
^ permalink raw reply related
* [meta-rockchip] [PATCH v2 0/3] fixup u-boot compiling error
From: ayaka @ 2019-06-20 11:14 UTC (permalink / raw)
To: yocto; +Cc: Randy 'ayaka' Li, romain.perier
From: Randy 'ayaka' Li <ayaka@soulik.info>
Changelog
v2:
Fixed unset SRCREV stopped building in the previous time
Fixed compiler warning in GCC 9 of new oe
Randy 'ayaka' Li (2):
recipes-bsp/u-boot: fixup build for gcc7
recipes-bsp/u-boot: update build rules
Randy Li (1):
recipes-bsp/u-boot: update to the latest version
recipes-bsp/u-boot/u-boot-rockchip.inc | 12 ++++++
.../u-boot/u-boot-rockchip/gcc7_fixup.patch | 38 +++++++++++++++++++
.../u-boot-rockchip/gcc9-no-Werror.patch | 13 +++++++
.../u-boot/u-boot-rockchip_20171218.bb | 4 ++
recipes-bsp/u-boot/u-boot-rockchip_git.bb | 19 ++++++++++
5 files changed, 86 insertions(+)
create mode 100644 recipes-bsp/u-boot/u-boot-rockchip/gcc7_fixup.patch
create mode 100644 recipes-bsp/u-boot/u-boot-rockchip/gcc9-no-Werror.patch
create mode 100644 recipes-bsp/u-boot/u-boot-rockchip_git.bb
--
2.21.0
^ permalink raw reply
* [Qemu-devel] [PATCH RFC] x86: BFloat16 feature enabling on Cooper Lake
From: Jing Liu @ 2019-06-20 11:00 UTC (permalink / raw)
To: qemu-devel, pbonzini; +Cc: jing2.liu, jing2.liu
Intel CooperLake cpu adds AVX512_BF16 instruction, defining as
CPUID.(EAX=7,EXC=1):EAX[bit 05].
The release spec link as follows,
https://software.intel.com/sites/default/files/managed/c5/15/\
architecture-instruction-set-extensions-programming-reference.pdf
Signed-off-by: Jing Liu <jing2.liu@linux.intel.com>
---
target/i386/cpu.c | 46 +++++++++++++++++++++++++++++++++++++++-------
target/i386/cpu.h | 3 +++
target/i386/kvm.c | 3 ++-
3 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index c1ab86d..249f7f9 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -664,6 +664,9 @@ static CPUCacheInfo legacy_l3_cache = {
#define L2_ITLB_4K_ASSOC 4
#define L2_ITLB_4K_ENTRIES 512
+/* CPUID Leaf 0x07 constants: */
+#define INTEL_LEAF_7_MAX_SUBLEAF 0x1
+
/* CPUID Leaf 0x14 constants: */
#define INTEL_PT_MAX_SUBLEAF 0x1
/*
@@ -767,6 +770,7 @@ static void x86_cpu_vendor_words2str(char *dst, uint32_t vendor1,
/* CPUID_7_0_ECX_OSPKE is dynamic */ \
CPUID_7_0_ECX_LA57)
#define TCG_7_0_EDX_FEATURES 0
+#define TCG_7_1_EAX_FEATURES 0
#define TCG_APM_FEATURES 0
#define TCG_6_EAX_FEATURES CPUID_6_EAX_ARAT
#define TCG_XSAVE_FEATURES (CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XGETBV1)
@@ -1092,6 +1096,25 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
},
.tcg_features = TCG_7_0_EDX_FEATURES,
},
+ [FEAT_7_1_EAX] = {
+ .type = CPUID_FEATURE_WORD,
+ .feat_names = {
+ NULL, NULL, NULL, NULL,
+ NULL, "avx512-bf16", NULL, NULL,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL,
+ },
+ .cpuid = {
+ .eax = 7,
+ .needs_ecx = true, .ecx = 1,
+ .reg = R_EAX,
+ },
+ .tcg_features = TCG_7_1_EAX_FEATURES,
+ },
[FEAT_8000_0007_EDX] = {
.type = CPUID_FEATURE_WORD,
.feat_names = {
@@ -4343,19 +4366,28 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
break;
case 7:
/* Structured Extended Feature Flags Enumeration Leaf */
- if (count == 0) {
- *eax = 0; /* Maximum ECX value for sub-leaves */
+ *eax = 0;
+ *ebx = 0;
+ *ecx = 0;
+ *edx = 0;
+
+ switch (count) {
+ case 0:
+ if (env->features[FEAT_7_1_EAX] & CPUID_7_1_EAX_AVX512_BF16) {
+ *eax = INTEL_LEAF_7_MAX_SUBLEAF; /* Maximum ECX value for sub-leaves */
+ }
*ebx = env->features[FEAT_7_0_EBX]; /* Feature flags */
*ecx = env->features[FEAT_7_0_ECX]; /* Feature flags */
if ((*ecx & CPUID_7_0_ECX_PKU) && env->cr[4] & CR4_PKE_MASK) {
*ecx |= CPUID_7_0_ECX_OSPKE;
}
*edx = env->features[FEAT_7_0_EDX]; /* Feature flags */
- } else {
- *eax = 0;
- *ebx = 0;
- *ecx = 0;
- *edx = 0;
+ break;
+ case 1:
+ *eax = env->features[FEAT_7_1_EAX];
+ break;
+ default:
+ break;
}
break;
case 9:
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index bd06523..40594a1 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -488,6 +488,7 @@ typedef enum FeatureWord {
FEAT_7_0_EBX, /* CPUID[EAX=7,ECX=0].EBX */
FEAT_7_0_ECX, /* CPUID[EAX=7,ECX=0].ECX */
FEAT_7_0_EDX, /* CPUID[EAX=7,ECX=0].EDX */
+ FEAT_7_1_EAX, /* CPUID[EAX=7,ECX=1].EAX */
FEAT_8000_0001_EDX, /* CPUID[8000_0001].EDX */
FEAT_8000_0001_ECX, /* CPUID[8000_0001].ECX */
FEAT_8000_0007_EDX, /* CPUID[8000_0007].EDX */
@@ -699,6 +700,8 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
#define CPUID_7_0_EDX_ARCH_CAPABILITIES (1U << 29) /*Arch Capabilities*/
#define CPUID_7_0_EDX_SPEC_CTRL_SSBD (1U << 31) /* Speculative Store Bypass Disable */
+#define CPUID_7_1_EAX_AVX512_BF16 (1U << 5) /* AVX512 BFloat16 Instruction */
+
#define CPUID_8000_0008_EBX_WBNOINVD (1U << 9) /* Write back and
do not invalidate cache */
#define CPUID_8000_0008_EBX_IBPB (1U << 12) /* Indirect Branch Prediction Barrier */
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 3b29ce5..977aaa5 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -1110,6 +1110,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
c = &cpuid_data.entries[cpuid_i++];
}
break;
+ case 0x7:
case 0x14: {
uint32_t times;
@@ -1122,7 +1123,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
for (j = 1; j <= times; ++j) {
if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
fprintf(stderr, "cpuid_data is full, no space for "
- "cpuid(eax:0x14,ecx:0x%x)\n", j);
+ "cpuid(eax:0x%x,ecx:0x%x)\n", i, j);
abort();
}
c = &cpuid_data.entries[cpuid_i++];
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] drm/imx: correct order of crtc disable
From: Robert Beckett @ 2019-06-20 11:12 UTC (permalink / raw)
To: Daniel Vetter, Philipp Zabel; +Cc: dri-devel
In-Reply-To: <CAKMK7uF=h_gQwTJG4gCv6fT27q0Cctf=AKS=ZgyV=tOFr7ktLg@mail.gmail.com>
On Thu, 2019-06-20 at 10:50 +0200, Daniel Vetter wrote:
> On Wed, Jun 19, 2019 at 11:40 AM Philipp Zabel <
> p.zabel@pengutronix.de> wrote:
> >
> > Hi Robert,
> >
> > thank you for the patch.
> >
> > On Tue, 2019-06-18 at 16:50 +0100, Robert Beckett wrote:
> > > Notify drm core before sending pending events during crtc
> > > disable.
> > > This fixes the first event after disable having an old stale
> > > timestamp
> > > by having drm_crtc_vblank_off update the timestamp to now.
> > >
> > > This was seen while debugging weston log message:
> > > Warning: computed repaint delay is insane: -8212 msec
> > >
> >
> > Would you say this
> > Fixes: a474478642d5 ("drm/imx: fix crtc vblank state regression")
> > ?
> >
> > > Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
> > > ---
> > > drivers/gpu/drm/imx/ipuv3-crtc.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > index 9cc1d678674f..c436a28d50e4 100644
> > > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > @@ -91,14 +91,14 @@ static void ipu_crtc_atomic_disable(struct
> > > drm_crtc *crtc,
> > > ipu_dc_disable(ipu);
> > > ipu_prg_disable(ipu);
> > >
> > > + drm_crtc_vblank_off(crtc);
> > > +
> >
> > This is explained in the commit message and aligns with the
> > drm_crtc_state @event documentation.
>
> This part here looks fishy. The drm_vblank.c code is supposed to do
> the right thing, no matter where or when you ask it to generate an
> event. It definitely shouldn't generate a timestamp that's a few
> seconds too early. Bunch of options:
> - there's a bug in drm_vblank.c and it's mixing up something and
> generating a totally bogus value.
> - there's a lie in your imx vblank code, which trips the drm_vblank.c
> counter interpolation and results in a totally bogus value.
>
> drm_vblank.c assumes that if you do claim to have a hw counter and
> generate timestamps, that those are perfectly accurate. It only falls
> back to guestimating using the system timer if that's not present.
>
> Either way, this very much smells like papering over a bug if this
> change indeed fixes your wrong vblank timestamps.
>
A quick explaination of where the dodgy timestamp came from:
1. driver starts up
2. fbcon comes along and restores fbdev, enabling vblank
3. vblank_disable_fn fires via timer disabling vblank, keeping vblank
seq number and time set at current value
(some time later)
4. weston starts and does a modeset
5. atomic commit disables crtc while it does the modeset
6. ipu_crtc_atomic_disable sends vblank with old seq number and time
It turns out the actual fix for the old vblank is the next change,
which stops it being sent at all during the crtc disable as it is is
still active, it would then go through drm_crtc_vblank_off, reseting
the timestamp, and get delivered during the vblank enable as part of
the atomic commit.
So, in theory, we could just have the following change to fix the
specific issue of a stale timestamp.
However, given the documentation for the event in
include/drm/drm_crtc.h:
* - The event is for a CRTC which is being disabled through
this
* atomic commit. In that case the event can be send out any
time
* after the hardware has stopped scanning out the current
* framebuffers. It should contain the timestamp and counter
for the
* last vblank before the display pipeline was shut off. The
simplest
* way to achieve that is calling
drm_crtc_send_vblank_event()
* somewhen after drm_crtc_vblank_off() has been called.
This still seems like a sensible change for when the crtc is being
disabled.
> > > spin_lock_irq(&crtc->dev->event_lock);
> > > - if (crtc->state->event)
> > > {
> > > + if (crtc->state->event && !crtc->state->active) {
> >
> > This is not mentioned though.
> >
> > If the pending event is not sent here, I assume it will be picked
> > up by
> > .atomic_flush and will then be sent after the first EOF interrupt
> > after
> > the modeset is complete. Can you explain this in the commit
> > message?
>
> Yeah looks correct (you only want to generate the event here when the
> crtc stays off), if it gets re-enabled the event should only be
> generated later on once that's all finished. But separate bugfix.
> -Daniel
>
It looks like this is actually the fix needed to avoid the bogus
timestamp.
I can split this patch up in to 2 commits if desired?
> >
> > With that,
> > Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
> >
> > > drm_crtc_send_vblank_event(crtc, crtc->state-
> > > >event);
> > > crtc->state->event = NULL;
> > > }
> > > spin_unlock_irq(&crtc->dev->event_lock);
> > > -
> > > - drm_crtc_vblank_off(crtc);
> > > }
> > >
> > > static void imx_drm_crtc_reset(struct drm_crtc *crtc)
> >
> > regards
> > Philipp
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t 5/5] docs: Embed subtest descriptions in the documentation
From: Petri Latvala @ 2019-06-20 11:11 UTC (permalink / raw)
To: Arkadiusz Hiler; +Cc: igt-dev, Daniel Vetter
In-Reply-To: <20190620105225.72w3opn6qccyqn2e@ahiler-desk1.fi.intel.com>
On Thu, Jun 20, 2019 at 01:52:25PM +0300, Arkadiusz Hiler wrote:
> On Thu, Jun 20, 2019 at 11:20:18AM +0300, Petri Latvala wrote:
> > On Mon, Jun 17, 2019 at 01:54:43PM +0300, Arkadiusz Hiler wrote:
> > > This rewrites generate_description_xml in Python, so that we generate
> > > properly escaped XML. The switch also makes the code more manageable.
> > >
> > > Changes in the generated docbook:
> > >
> > > 1. subtests are not simply listed anymore, they are now another (sub)section
> > >
> > > 2. subtests are now linkable,
> > > e.g. docs/igt-kms-tests.html#kms_hdmi_inject@inject-4k
> > >
> > > 3. subtest's section now includes output of --describe
> > >
> > > Python is required already by gtk-doc and we are not using anything
> > > other than the standard library.
> >
> > Python yes, but what about python3? My Debian installation is ancient
> > even on Debian standards and gtk-doc-tools depends on python2. I'm too
> > lazy to check if the version used by gitlab-CI depends on python3, so
> > asking instead: Do you have a fork in gitlab for this? :P
>
> It works on Fedora:
>
> % head -n 1 $(which gtkdoc-mkhtml)
> #!/usr/bin/python3
>
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/.gitlab-ci.yml#L174
>
>
> But for explicitness I can squash in:
>
> diff --git a/docs/reference/igt-gpu-tools/meson.build b/docs/reference/igt-gpu-tools/meson.build
> index e2bdc495..b3a4c0bd 100644
> --- a/docs/reference/igt-gpu-tools/meson.build
> +++ b/docs/reference/igt-gpu-tools/meson.build
> @@ -45,6 +45,7 @@ test_groups = [
> 'vgem',
> ]
>
> +find_program('python3') # required by doc generators
> gen_description = find_program('generate_description_xml.py')
> gen_programs = find_program('generate_programs_xml.sh')
For explicitness I'd prefer something the doc building can depend on
to automatically not build them if you don't have python3.
--
Petri Latvala
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH] samples: make pidfd-metadata fail gracefully on older kernels
From: Christian Brauner @ 2019-06-20 11:10 UTC (permalink / raw)
To: Dmitry V. Levin
Cc: Jann Horn, Oleg Nesterov, Arnd Bergmann, linux-api, linux-kernel
In-Reply-To: <20190620110037.GA4998@altlinux.org>
On Thu, Jun 20, 2019 at 02:00:37PM +0300, Dmitry V. Levin wrote:
> Cc'ed more people as the issue is not just with the example but
> with the interface itself.
>
> On Thu, Jun 20, 2019 at 12:31:06PM +0200, Christian Brauner wrote:
> > On Thu, Jun 20, 2019 at 06:11:44AM +0300, Dmitry V. Levin wrote:
> > > Initialize pidfd to an invalid descriptor, to fail gracefully on
> > > those kernels that do not implement CLONE_PIDFD and leave pidfd
> > > unchanged.
> > >
> > > Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
> > > ---
> > > samples/pidfd/pidfd-metadata.c | 8 ++++++--
> > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/samples/pidfd/pidfd-metadata.c b/samples/pidfd/pidfd-metadata.c
> > > index 14b454448429..ff109fdac3a5 100644
> > > --- a/samples/pidfd/pidfd-metadata.c
> > > +++ b/samples/pidfd/pidfd-metadata.c
> > > @@ -83,7 +83,7 @@ static int pidfd_metadata_fd(pid_t pid, int pidfd)
> > >
> > > int main(int argc, char *argv[])
> > > {
> > > - int pidfd = 0, ret = EXIT_FAILURE;
> > > + int pidfd = -1, ret = EXIT_FAILURE;
> >
> > Hm, that currently won't work since we added a check in fork.c for
> > pidfd == 0. If it isn't you'll get EINVAL.
>
> Sorry, I must've missed that check. But this makes things even worse.
>
> > This was done to ensure that
> > we can potentially extend CLONE_PIDFD by passing in flags through the
> > return argument.
> > However, I find this increasingly unlikely. Especially since the
> > interface would be horrendous and an absolute last resort.
> > If clone3() gets merged for 5.3 (currently in linux-next) we also have
> > no real need anymore to extend legacy clone() this way. So either wait
> > until (if) we merge clone3() where the check I mentioned is gone anyway,
> > or remove the pidfd == 0 check from fork.c in a preliminary patch.
> > Thoughts?
>
> Userspace needs a reliable way to tell whether CLONE_PIDFD is supported
> by the kernel or not.
Right, that's the general problem with legacy clone(): it ignores
unknown flags... clone3() will EINVAL you if you pass any flag it
doesn't know about.
For legacy clone you can pass
(CLONE_PIDFD | CLONE_DETACHED)
on all relevant kernels >= 2.6.2. CLONE_DETACHED will be silently
ignored by the kernel if specified in flags. But if you specify both
CLONE_PIDFD and CLONE_DETACHED on a kernel that does support CLONE_PIDFD
you'll get EINVALed. (We did this because we wanted to have the ability
to make CLONE_DETACHED reuseable with CLONE_PIDFD.)
Does that help?
>
> If CLONE_PIDFD is not supported, then pidfd remains unchanged.
>
> If CLONE_PIDFD is supported and fd 0 is closed, then mandatory pidfd == 0
> also remains unchanged, which effectively means that userspace must ensure
> that fd 0 is not closed when invoking CLONE_PIDFD. This is ugly.
>
> If we can assume that clone(CLONE_PIDFD) is not going to be extended,
> then I'm for removing the pidfd == 0 check along with recommending
> userspace to initialize pidfd with -1.
Right, I'm ok with that too.
Thanks!
Christian
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v1 14/17] tests/vm: fedora autoinstall, using serial console
From: Philippe Mathieu-Daudé @ 2019-06-20 10:36 UTC (permalink / raw)
To: Alex Bennée, qemu-devel; +Cc: Fam Zheng, Thomas Huth, Gerd Hoffmann
In-Reply-To: <20190619194021.8240-15-alex.bennee@linaro.org>
On 6/19/19 9:40 PM, Alex Bennée wrote:
> From: Gerd Hoffmann <kraxel@redhat.com>
>
> Download the install iso and prepare the image locally. Install to
> disk, using the serial console. Create qemu user, configure ssh login.
> Install packages needed for qemu builds.
>
> Yes, we have docker images for fedora. But for trouble-shooting it
> might be helpful to have a vm too. When vm builds fail you can use
> it to figure whenever the vm setup or the guest os is the problem.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> Tested-by: Thomas Huth <thuth@redhat.com>
> Message-Id: <20190617043858.8290-11-kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
> tests/vm/Makefile.include | 3 +-
> tests/vm/basevm.py | 9 +-
> tests/vm/fedora | 189 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 199 insertions(+), 2 deletions(-)
> create mode 100755 tests/vm/fedora
>
> diff --git a/tests/vm/Makefile.include b/tests/vm/Makefile.include
> index a61c236b8e..809b80e2e5 100644
> --- a/tests/vm/Makefile.include
> +++ b/tests/vm/Makefile.include
> @@ -2,7 +2,7 @@
>
> .PHONY: vm-build-all vm-clean-all
>
> -IMAGES := ubuntu.i386 freebsd netbsd openbsd centos
> +IMAGES := ubuntu.i386 freebsd netbsd openbsd centos fedora
> IMAGES_DIR := $(HOME)/.cache/qemu-vm/images
> IMAGE_FILES := $(patsubst %, $(IMAGES_DIR)/%.img, $(IMAGES))
>
> @@ -16,6 +16,7 @@ vm-test:
> @echo " vm-build-netbsd - Build QEMU in NetBSD VM"
> @echo " vm-build-openbsd - Build QEMU in OpenBSD VM"
> @echo " vm-build-centos - Build QEMU in CentOS VM, with Docker"
> + @echo " vm-build-fedora - Build QEMU in Fedora VM"
> @echo ""
> @echo " vm-build-all - Build QEMU in all VMs"
> @echo " vm-clean-all - Clean up VM images"
> diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py
> index 592a344773..3d717da498 100755
> --- a/tests/vm/basevm.py
> +++ b/tests/vm/basevm.py
> @@ -206,7 +206,7 @@ class BaseVM(object):
> # log console line
> sys.stderr.write("con recv: %s\n" % line)
>
> - def console_wait(self, expect):
> + def console_wait(self, expect, expectalt = None):
> vm = self._guest
> output = ""
> while True:
> @@ -215,6 +215,8 @@ class BaseVM(object):
> except socket.timeout:
> sys.stderr.write("console: *** read timeout ***\n")
> sys.stderr.write("console: waiting for: '%s'\n" % expect)
> + if not expectalt is None:
> + sys.stderr.write("console: waiting for: '%s' (alt)\n" % expectalt)
> sys.stderr.write("console: line buffer:\n")
> sys.stderr.write("\n")
> self.console_log(output.rstrip())
> @@ -223,6 +225,8 @@ class BaseVM(object):
> output += chars.decode("latin1")
> if expect in output:
> break
> + if not expectalt is None and expectalt in output:
> + break
> if "\r" in output or "\n" in output:
> lines = re.split("[\r\n]", output)
> output = lines.pop()
> @@ -230,6 +234,9 @@ class BaseVM(object):
> self.console_log("\n".join(lines))
> if self.debug:
> self.console_log(output)
> + if not expectalt is None and expectalt in output:
> + return False
> + return True
>
> def console_send(self, command):
> vm = self._guest
> diff --git a/tests/vm/fedora b/tests/vm/fedora
> new file mode 100755
> index 0000000000..e8fa5bf0d2
> --- /dev/null
> +++ b/tests/vm/fedora
> @@ -0,0 +1,189 @@
> +#!/usr/bin/env python
> +#
> +# Fedora VM image
> +#
> +# Copyright 2019 Red Hat Inc.
> +#
> +# Authors:
> +# Gerd Hoffmann <kraxel@redhat.com>
> +#
> +# This code is licensed under the GPL version 2 or later. See
> +# the COPYING file in the top-level directory.
> +#
> +
> +import os
> +import re
> +import sys
> +import time
> +import socket
> +import subprocess
> +import basevm
> +
> +class FedoraVM(basevm.BaseVM):
> + name = "fedora"
> + arch = "x86_64"
> +
> + base = "http://dl.fedoraproject.org/pub/fedora/linux/releases/30/"
> + link = base + "Server/x86_64/iso/Fedora-Server-netinst-x86_64-30-1.2.iso"
> + repo = base + "Server/x86_64/os/"
> + full = base + "Everything/x86_64/os/"
> + csum = "5e4eac4566d8c572bfb3bcf54b7d6c82006ec3c6c882a2c9235c6d3494d7b100"
> + size = "20G"
> + pkgs = [
> + # tools
> + 'git-core',
> + 'flex', 'bison',
> + 'gcc', 'binutils', 'make',
> +
> + # perl
> + 'perl-Test-Harness',
> +
> + # libs: usb
> + '"pkgconfig(libusb-1.0)"',
> + '"pkgconfig(libusbredirparser-0.5)"',
> +
> + # libs: crypto
> + '"pkgconfig(gnutls)"',
> +
> + # libs: ui
> + '"pkgconfig(sdl2)"',
> + '"pkgconfig(gtk+-3.0)"',
> + '"pkgconfig(ncursesw)"',
> +
> + # libs: audio
> + '"pkgconfig(libpulse)"',
> + '"pkgconfig(alsa)"',
> + ]
> +
> + BUILD_SCRIPT = """
> + set -e;
> + rm -rf /home/qemu/qemu-test.*
> + cd $(mktemp -d /home/qemu/qemu-test.XXXXXX);
> + mkdir src build; cd src;
> + tar -xf /dev/vdb;
> + cd ../build
> + ../src/configure --python=python3 {configure_opts};
> + gmake --output-sync -j{jobs} {target} {verbose};
> + """
> +
> + def build_image(self, img):
> + self.print_step("Downloading install iso")
> + cimg = self._download_with_cache(self.link, sha256sum=self.csum)
> + img_tmp = img + ".tmp"
> + iso = img + ".install.iso"
> +
> + self.print_step("Preparing iso and disk image")
> + subprocess.check_call(["cp", "-f", cimg, iso])
> + subprocess.check_call(["qemu-img", "create", "-f", "qcow2",
> + img_tmp, self.size])
> +
> + self.print_step("Booting installer")
> + self.boot(img_tmp, extra_args = [
> + "-bios", "pc-bios/bios-256k.bin",
> + "-machine", "graphics=off",
> + "-cdrom", iso
> + ])
> + self.console_init(300)
> + self.console_wait("installation process.")
> + time.sleep(0.3)
> + self.console_send("\t")
> + time.sleep(0.3)
> + self.console_send(" console=ttyS0")
> + proxy = os.environ.get("http_proxy")
> + if not proxy is None:
> + self.console_send(" proxy=%s" % proxy)
> + self.console_send(" inst.proxy=%s" % proxy)
> + self.console_send(" inst.repo=%s" % self.repo)
> + self.console_send("\n")
> +
> + self.console_wait_send("2) Use text mode", "2\n")
> +
> + self.console_wait_send("5) [!] Installation Dest", "5\n")
> + self.console_wait_send("1) [x]", "c\n")
> + self.console_wait_send("2) [ ] Use All Space", "2\n")
> + self.console_wait_send("2) [x] Use All Space", "c\n")
> + self.console_wait_send("1) [ ] Standard Part", "1\n")
> + self.console_wait_send("1) [x] Standard Part", "c\n")
> +
> + self.console_wait_send("7) [!] Root password", "7\n")
> + self.console_wait("Password:")
> + self.console_send("%s\n" % self.ROOT_PASS)
> + self.console_wait("Password (confirm):")
> + self.console_send("%s\n" % self.ROOT_PASS)
> +
> + self.console_wait_send("8) [ ] User creation", "8\n")
> + self.console_wait_send("1) [ ] Create user", "1\n")
> + self.console_wait_send("3) User name", "3\n")
> + self.console_wait_send("ENTER:", "%s\n" % self.GUEST_USER)
> + self.console_wait_send("4) [ ] Use password", "4\n")
> + self.console_wait_send("5) Password", "5\n")
> + self.console_wait("Password:")
> + self.console_send("%s\n" % self.GUEST_PASS)
> + self.console_wait("Password (confirm):")
> + self.console_send("%s\n" % self.GUEST_PASS)
> + self.console_wait_send("7) Groups", "c\n")
> +
> + while True:
> + good = self.console_wait("3) [x] Installation",
> + "3) [!] Installation")
> + self.console_send("r\n")
> + if good:
> + break
> + time.sleep(10)
> +
> + while True:
> + good = self.console_wait("4) [x] Software",
> + "4) [!] Software")
> + self.console_send("r\n")
> + if good:
> + break
> + time.sleep(10)
> + self.console_send("r\n" % self.GUEST_PASS)
> +
> + self.console_wait_send("'b' to begin install", "b\n")
> +
> + self.print_step("Installation started now, this will take a while")
> +
> + self.console_wait_send("Installation complete", "\n")
> + self.print_step("Installation finished, rebooting")
> +
> + # setup qemu user
> + prompt = " ~]$"
> + self.console_ssh_init(prompt, self.GUEST_USER, self.GUEST_PASS)
> + self.console_wait_send(prompt, "exit\n")
> +
> + # setup root user
> + prompt = " ~]#"
> + self.console_ssh_init(prompt, "root", self.ROOT_PASS)
> + self.console_sshd_config(prompt)
> +
> + # setup virtio-blk #1 (tarfile)
> + self.console_wait(prompt)
> + self.console_send("echo 'KERNEL==\"vdb\" MODE=\"666\"' >> %s\n" %
> + "/etc/udev/rules.d/99-qemu.rules")
> +
> + self.print_step("Configuration finished, rebooting")
> + self.console_wait_send(prompt, "reboot\n")
> + self.console_wait("login:")
> + self.wait_ssh()
> +
> + self.print_step("Installing packages")
> + self.ssh_root_check("rm -vf /etc/yum.repos.d/fedora*.repo\n")
> + self.ssh_root_check("echo '[fedora]' >> /etc/yum.repos.d/qemu.repo\n")
> + self.ssh_root_check("echo 'baseurl=%s' >> /etc/yum.repos.d/qemu.repo\n" % self.full)
> + self.ssh_root_check("echo 'gpgcheck=0' >> /etc/yum.repos.d/qemu.repo\n")
> + self.ssh_root_check("dnf install -y %s\n" % " ".join(self.pkgs))
> +
> + # shutdown
> + self.ssh_root(self.poweroff)
> + self.console_wait("sleep state S5")
> + self.wait()
> +
> + if os.path.exists(img):
> + os.remove(img)
> + os.rename(img_tmp, img)
> + os.remove(iso)
> + self.print_step("All done")
> +
> +if __name__ == "__main__":
> + sys.exit(basevm.main(FedoraVM))
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v1 16/17] .travis.yml: default the --disable-system build to --static
From: Philippe Mathieu-Daudé @ 2019-06-20 10:37 UTC (permalink / raw)
To: Alex Bennée, qemu-devel; +Cc: Fam Zheng
In-Reply-To: <20190619194021.8240-17-alex.bennee@linaro.org>
On 6/19/19 9:40 PM, Alex Bennée wrote:
> It's fairly common to build qemu-user binaries with --static linking
> so the binary can be copied around without libraries. Enable --static
> in the default qemu-user build to cover this.
>
> There are other qemu-user builds that use dynamic linking so they
> should catch any problems there.
>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
> .travis.yml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index aeb9b211cd..9750dc905c 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -80,7 +80,7 @@ script:
> matrix:
> include:
> - env:
> - - CONFIG="--disable-system"
> + - CONFIG="--disable-system --static"
>
>
> # we split the system builds as it takes a while to build them all
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v1 17/17] .travis.yml: force a brew update for MacOS builds
From: Philippe Mathieu-Daudé @ 2019-06-20 10:37 UTC (permalink / raw)
To: Alex Bennée, qemu-devel; +Cc: Fam Zheng
In-Reply-To: <20190619194021.8240-18-alex.bennee@linaro.org>
On 6/19/19 9:40 PM, Alex Bennée wrote:
> It looks like the Travis image package databases are out of date
> causing the build to error with:
>
> Error: Your Homebrew is outdated. Please run `brew update`.
> Error: Kernel.exit
>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
> .travis.yml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.travis.yml b/.travis.yml
> index 9750dc905c..a891ce2485 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -43,6 +43,7 @@ addons:
> - glib
> - pixman
> - gnu-sed
> + update: true
>
>
> # The channel name "irc.oftc.net#qemu" is encrypted against qemu/qemu
>
^ permalink raw reply
* linux-next: Fixes tag needs some work in the pinctrl tree
From: Stephen Rothwell @ 2019-06-20 11:08 UTC (permalink / raw)
To: Linus Walleij
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Phil Reid
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
Hi all,
In commit
905dade66268 ("pinctrl: mcp23s08: Fix add_data and irqchip_add_nested call order")
Fixes tag
Fixes: 02e389e63 ("pinctrl: mcp23s08: fix irq setup order")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: pull request: iwlwifi firmware updates 2019-06-20
From: Josh Boyer @ 2019-06-20 11:07 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-firmware@kernel.org, linux-wireless@vger.kernel.org,
linuxwifi, kyle@infradead.org, ben@decadent.org.uk
In-Reply-To: <86eada55d771732ac0477a008d3c5f0a61570952.camel@coelho.fi>
On Thu, Jun 20, 2019 at 4:16 AM Luca Coelho <luca@coelho.fi> wrote:
>
> Hi,
>
> This contains some updated firmwares for the 9000 and 22000 series of
> devices, and new firmwares for new integrated 22000 series devices.
>
> Please pull or let me know if there are any issues.
>
> --
> Cheers,
> Luca.
>
>
> The following changes since commit acb56f2fae3235195bc99ecb7d09742fb4b65e63:
>
> cavium: Add firmware for CNN55XX crypto driver. (2019-06-18 09:12:52 -0400)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2019-06-20
Pulled and pushed out.
josh
^ permalink raw reply
* Re: [PATCH v1 5/5] coresight: etm4x: save/restore state across CPU low power states
From: Andrew Murray @ 2019-06-20 11:07 UTC (permalink / raw)
To: Mathieu Poirier; +Cc: Alexander Shishkin, linux-arm-kernel, Suzuki K Poulose
In-Reply-To: <20190618225549.GB24894@xps15>
On Tue, Jun 18, 2019 at 04:55:49PM -0600, Mathieu Poirier wrote:
> On Tue, Jun 18, 2019 at 01:54:33PM +0100, Andrew Murray wrote:
> > Some hardware will ignore bit TRCPDCR.PU which is used to signal
> > to hardware that power should not be removed from the trace unit.
> > Let's mitigate against this by saving and restoring the trace
> > unit state when the CPU enters low power states.
> >
> > To provide the benefit to both self-hosted and external debuggers
> > we save/restore the entire state which includes etmv4_config data
> > and dynamic data such as inflight counter values, sequencer
> > states, etc.
> >
> > To reduce CPU suspend/resume latency the state is only saved or
> > restored if coresight is in use as determined by the claimset
> > registers.
> >
> > To aid debug of CPU suspend/resume a disable_pm_save parameter
> > is provided to disable this feature.
> >
> > Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> > ---
> > drivers/hwtracing/coresight/coresight-etm4x.c | 245 ++++++++++++++++++
> > drivers/hwtracing/coresight/coresight-etm4x.h | 66 ++++-
> > drivers/hwtracing/coresight/coresight.c | 2 +-
> > include/linux/coresight.h | 7 +
> > 4 files changed, 318 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> > index bda90d4cd62b..d27c5e0d9aec 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> > @@ -18,6 +18,7 @@
> > #include <linux/stat.h>
> > #include <linux/clk.h>
> > #include <linux/cpu.h>
> > +#include <linux/cpu_pm.h>
> > #include <linux/coresight.h>
> > #include <linux/coresight-pmu.h>
> > #include <linux/pm_wakeup.h>
> > @@ -36,6 +37,9 @@
> > static int boot_enable;
> > module_param_named(boot_enable, boot_enable, int, 0444);
> >
> > +static int disable_pm_save;
> > +module_param_named(disable_pm_save, disable_pm_save, int, 0444);
> > +
> > /* The number of ETMv4 currently registered */
> > static int etm4_count;
> > static struct etmv4_drvdata *etmdrvdata[NR_CPUS];
> > @@ -53,6 +57,14 @@ static void etm4_os_unlock(struct etmv4_drvdata *drvdata)
> > isb();
> > }
> >
> > +static void etm4_os_lock(struct etmv4_drvdata *drvdata)
> > +{
> > + /* Writing 0x1 to TRCOSLAR unlocks the trace registers */
> > + writel_relaxed(0x1, drvdata->base + TRCOSLAR);
> > + drvdata->os_unlock = false;
> > + isb();
> > +}
> > +
> > static bool etm4_arch_supported(u8 arch)
> > {
> > /* Mask out the minor version number */
> > @@ -1076,6 +1088,235 @@ static void etm4_init_trace_id(struct etmv4_drvdata *drvdata)
> > drvdata->trcid = coresight_get_trace_id(drvdata->cpu);
> > }
> >
> > +#ifdef CONFIG_CPU_PM
> > +static void etm4_cpu_save(struct etmv4_drvdata *drvdata)
> > +{
> > + int i;
> > + u32 control;
> > + struct etmv4_save_state *state;
>
> Before going any further I would make sure the CPU this is running on it equal
> to drvdata->cpu. Otherwise something very wrong happened.
>
Sure I'll add that.
> > +
> > + /* As recommended by 3.4.1 of ARM IHI 0064D */
> > + dsb(sy);
> > + isb();
> > +
> > + CS_UNLOCK(drvdata->base);
> > + etm4_os_lock(drvdata);
>
> Please add a comment to explain that you are using the OS lock to disable
> external debugger access to the trace registers while the unit is powered down.
> Otherwise people will get confused and will submit patches that changes
> etm4_os_lock() to etm4_os_unlock().
Yes sure, it deserves a comment.
>
> > +
> > + /* wait for TRCSTATR.PMSTABLE to go up */
> > + if (coresight_timeout(drvdata->base, TRCSTATR,
> > + TRCSTATR_PMSTABLE_BIT, 1))
> > + dev_err(drvdata->dev,
> > + "timeout while waiting for Idle Trace Status\n");
>
> The above comment is not accurate since we are waiting for the PMSTABLE bit.
I'll change that.
>
> > +
> > + state = &drvdata->save_state;
> > +
> > + state->trcprgctlr = readl(drvdata->base + TRCPRGCTLR);
> > + state->trcprocselr = readl(drvdata->base + TRCPROCSELR);
> > + state->trcconfigr = readl(drvdata->base + TRCCONFIGR);
> > + state->trcauxctlr = readl(drvdata->base + TRCAUXCTLR);
> > + state->trceventctl0r = readl(drvdata->base + TRCEVENTCTL0R);
> > + state->trceventctl1r = readl(drvdata->base + TRCEVENTCTL1R);
> > + state->trcstallctlr = readl(drvdata->base + TRCSTALLCTLR);
> > + state->trctsctlr = readl(drvdata->base + TRCTSCTLR);
> > + state->trcsyncpr = readl(drvdata->base + TRCSYNCPR);
> > + state->trcccctlr = readl(drvdata->base + TRCCCCTLR);
> > + state->trcbbctlr = readl(drvdata->base + TRCBBCTLR);
> > + state->trctraceidr = readl(drvdata->base + TRCTRACEIDR);
> > + state->trcqctlr = readl(drvdata->base + TRCQCTLR);
> > +
> > + state->trcvictlr = readl(drvdata->base + TRCVICTLR);
> > + state->trcviiectlr = readl(drvdata->base + TRCVIIECTLR);
> > + state->trcvissctlr = readl(drvdata->base + TRCVISSCTLR);
> > + state->trcvipcssctlr = readl(drvdata->base + TRCVIPCSSCTLR);
> > + state->trcvdctlr = readl(drvdata->base + TRCVDCTLR);
> > + state->trcvdsacctlr = readl(drvdata->base + TRCVDSACCTLR);
> > + state->trcvdarcctlr = readl(drvdata->base + TRCVDARCCTLR);
> > +
> > + for (i = 0; i < drvdata->nrseqstate; i++)
> > + state->trcseqevr[i] = readl(drvdata->base + TRCSEQEVRn(i));
> > +
> > + state->trcseqrstevr = readl(drvdata->base + TRCSEQRSTEVR);
> > + state->trcseqstr = readl(drvdata->base + TRCSEQSTR);
> > + state->trcextinselr = readl(drvdata->base + TRCEXTINSELR);
> > +
> > + for (i = 0; i < drvdata->nr_cntr; i++) {
> > + state->trccntrldvr[i] = readl(drvdata->base + TRCCNTRLDVRn(i));
> > + state->trccntctlr[i] = readl(drvdata->base + TRCCNTCTLRn(i));
> > + state->trccntvr[i] = readl(drvdata->base + TRCCNTVRn(i));
> > + }
> > +
> > + for (i = 0; i < drvdata->nr_resource * 2; i++)
> > + state->trcrsctlr[i] = readl(drvdata->base + TRCRSCTLRn(i));
> > +
> > + for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> > + state->trcssccr[i] = readl(drvdata->base + TRCSSCCRn(i));
> > + state->trcsscsr[i] = readl(drvdata->base + TRCSSCSRn(i));
> > + state->trcsspcicr[i] = readl(drvdata->base + TRCSSPCICRn(i));
> > + }
> > +
> > + for (i = 0; i < drvdata->nr_addr_cmp * 2; i++) {
> > + state->trcacvr[i] = readl(drvdata->base + TRCACVRn(i));
> > + state->trcacatr[i] = readl(drvdata->base + TRCACATRn(i));
> > + }
> > +
> > + for (i = 0; i < drvdata->numcidc; i++)
> > + state->trccidcvr[i] = readl(drvdata->base + TRCCIDCVRn(i));
> > +
> > + for (i = 0; i < drvdata->numvmidc; i++)
> > + state->trcvmidcvr[i] = readl(drvdata->base + TRCVMIDCVRn(i));
> > +
> > + state->trccidcctlr0 = readl(drvdata->base + TRCCIDCCTLR0);
> > + state->trccidcctlr1 = readl(drvdata->base + TRCCIDCCTLR1);
> > +
> > + state->trcvmidcctlr0 = readl(drvdata->base + TRCVMIDCCTLR0);
> > + state->trcvmidcctlr0 = readl(drvdata->base + TRCVMIDCCTLR1);
> > +
> > + state->trcclaimset = readl(drvdata->base + TRCCLAIMCLR);
> > +
> > + /* wait for TRCSTATR.IDLE to go up */
> > + if (coresight_timeout(drvdata->base, TRCSTATR, TRCSTATR_IDLE_BIT, 1))
> > + dev_err(drvdata->dev,
> > + "timeout while waiting for Idle Trace Status\n");
> > +
> > + /* power can be removed from the trace unit now */
> > + control = readl_relaxed(drvdata->base + TRCPDCR);
> > + control &= ~TRCPDCR_PU;
> > + writel_relaxed(control, drvdata->base + TRCPDCR);
> > +
> > + CS_LOCK(drvdata->base);
> > +}
> > +
> > +static void etm4_cpu_restore(struct etmv4_drvdata *drvdata)
> > +{
> > + int i;
> > + struct etmv4_save_state *state;
> > +
> > + state = &drvdata->save_state;
>
> Same comment as above about the running CPU.
>
> > +
> > + CS_UNLOCK(drvdata->base);
> > +
> > + writel_relaxed(state->trcclaimset, drvdata->base + TRCCLAIMSET);
> > +
> > + writel_relaxed(state->trcprgctlr, drvdata->base + TRCPRGCTLR);
> > + writel_relaxed(state->trcprocselr, drvdata->base + TRCPROCSELR);
> > + writel_relaxed(state->trcconfigr, drvdata->base + TRCCONFIGR);
> > + writel_relaxed(state->trcauxctlr, drvdata->base + TRCAUXCTLR);
> > + writel_relaxed(state->trceventctl0r, drvdata->base + TRCEVENTCTL0R);
> > + writel_relaxed(state->trceventctl1r, drvdata->base + TRCEVENTCTL1R);
> > + writel_relaxed(state->trcstallctlr, drvdata->base + TRCSTALLCTLR);
> > + writel_relaxed(state->trctsctlr, drvdata->base + TRCTSCTLR);
> > + writel_relaxed(state->trcsyncpr, drvdata->base + TRCSYNCPR);
> > + writel_relaxed(state->trcccctlr, drvdata->base + TRCCCCTLR);
> > + writel_relaxed(state->trcbbctlr, drvdata->base + TRCBBCTLR);
> > + writel_relaxed(state->trctraceidr, drvdata->base + TRCTRACEIDR);
> > + writel_relaxed(state->trcqctlr, drvdata->base + TRCQCTLR);
> > +
> > + writel_relaxed(state->trcvictlr, drvdata->base + TRCVICTLR);
> > + writel_relaxed(state->trcviiectlr, drvdata->base + TRCVIIECTLR);
> > + writel_relaxed(state->trcvissctlr, drvdata->base + TRCVISSCTLR);
> > + writel_relaxed(state->trcvipcssctlr, drvdata->base + TRCVIPCSSCTLR);
> > + writel_relaxed(state->trcvdctlr, drvdata->base + TRCVDCTLR);
> > + writel_relaxed(state->trcvdsacctlr, drvdata->base + TRCVDSACCTLR);
> > + writel_relaxed(state->trcvdarcctlr, drvdata->base + TRCVDARCCTLR);
> > +
> > + for (i = 0; i < drvdata->nrseqstate; i++)
> > + writel_relaxed(state->trcseqevr[i],
> > + drvdata->base + TRCSEQEVRn(i));
> > +
> > + writel_relaxed(state->trcseqrstevr, drvdata->base + TRCSEQRSTEVR);
> > + writel_relaxed(state->trcseqstr, drvdata->base + TRCSEQSTR);
> > + writel_relaxed(state->trcextinselr, drvdata->base + TRCEXTINSELR);
> > +
> > + for (i = 0; i < drvdata->nr_cntr; i++) {
> > + writel_relaxed(state->trccntrldvr[i],
> > + drvdata->base + TRCCNTRLDVRn(i));
> > + writel_relaxed(state->trccntctlr[i],
> > + drvdata->base + TRCCNTCTLRn(i));
> > + writel_relaxed(state->trccntvr[i],
> > + drvdata->base + TRCCNTVRn(i));
> > + }
> > +
> > + for (i = 0; i < drvdata->nr_resource * 2; i++)
> > + writel_relaxed(state->trcrsctlr[i],
> > + drvdata->base + TRCRSCTLRn(i));
> > +
> > + for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> > + writel_relaxed(state->trcssccr[i],
> > + drvdata->base + TRCSSCCRn(i));
> > + writel_relaxed(state->trcsscsr[i],
> > + drvdata->base + TRCSSCSRn(i));
> > + writel_relaxed(state->trcsspcicr[i],
> > + drvdata->base + TRCSSPCICRn(i));
> > + }
> > +
> > + for (i = 0; i < drvdata->nr_addr_cmp * 2; i++) {
> > + writel_relaxed(state->trcacvr[i],
> > + drvdata->base + TRCACVRn(i));
> > + writel_relaxed(state->trcacatr[i],
> > + drvdata->base + TRCACATRn(i));
> > + }
> > +
> > + for (i = 0; i < drvdata->numcidc; i++)
> > + writel_relaxed(state->trccidcvr[i],
> > + drvdata->base + TRCCIDCVRn(i));
> > +
> > + for (i = 0; i < drvdata->numvmidc; i++)
> > + writel_relaxed(state->trcvmidcvr[i],
> > + drvdata->base + TRCVMIDCVRn(i));
> > +
> > + writel_relaxed(state->trccidcctlr0, drvdata->base + TRCCIDCCTLR0);
> > + writel_relaxed(state->trccidcctlr1, drvdata->base + TRCCIDCCTLR1);
> > +
> > + writel_relaxed(state->trcvmidcctlr0, drvdata->base + TRCVMIDCCTLR0);
> > + writel_relaxed(state->trcvmidcctlr0, drvdata->base + TRCVMIDCCTLR1);
> > +
> > + writel_relaxed(state->trcclaimset, drvdata->base + TRCCLAIMSET);
> > +
> > + /* As recommended by 4.3.7 of ARM IHI 0064D */
> > + dsb(sy);
> > + isb();
> > +
> > + etm4_os_unlock(drvdata);
>
> Same comment as above.
>
> > + CS_LOCK(drvdata->base);
> > +}
> > +
> > +static int etm4_cpu_pm_notify(struct notifier_block *nb, unsigned long cmd,
> > + void *v)
> > +{
> > + struct etmv4_drvdata *drvdata = container_of(nb,
> > + struct etmv4_drvdata, nb);
> > +
> > + if (disable_pm_save)
> > + return NOTIFY_OK;
> > +
> > + switch (cmd) {
> > + case CPU_PM_ENTER:
> > + /* save the state if coresight is in use */
> > + if (coresight_is_claimed_any(drvdata->base))
>
> claimed_any()? At this point if coresight_is_claimed_self_hosted() == false an
> external agent is competing with the framework and we should abdicate.
If we only support save/restore for self-hosted, then we don't actually need
to store as much state as much of it is in the etmv4_config structure.
My thinking here was that if an external agent is being used and we power down
then we'd also potentially suffer the same issue where state is lost. So
saving/restoring may be helpful for external agents as well (or at least
wouldn't do harm)...
However I don't know if this is a real issue.
>
> > + etm4_cpu_save(drvdata);
> > + break;
> > + case CPU_PM_EXIT:
> > + case CPU_PM_ENTER_FAILED:
> > + /* trcclaimset is set when there is state to restore */
> > + if (drvdata->save_state.trcclaimset)
> > + etm4_cpu_restore(drvdata);
> > + break;
> > + default:
> > + return NOTIFY_DONE;
> > + }
> > +
> > + return NOTIFY_OK;
> > +}
> > +
> > +static int etm4_cpu_pm_register(struct etmv4_drvdata *drvdata)
> > +{
> > + drvdata->nb.notifier_call = etm4_cpu_pm_notify;
> > + return cpu_pm_register_notifier(&drvdata->nb);
> > +}
> > +#else
> > +static int etm4_cpu_pm_register(struct etmv4_drvdata *drvdata) { return 0; }
> > +#endif
> > +
> > static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
> > {
> > int ret;
> > @@ -1141,6 +1382,10 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
> > etm4_init_trace_id(drvdata);
> > etm4_set_default(&drvdata->config);
> >
> > + ret = etm4_cpu_pm_register(drvdata);
> > + if (ret)
> > + goto err_arch_supported;
> > +
> > desc.type = CORESIGHT_DEV_TYPE_SOURCE;
> > desc.subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_PROC;
> > desc.ops = &etm4_cs_ops;
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
> > index 52786e9d8926..f4cff447c8a1 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> > @@ -174,7 +174,8 @@
> > ETM_MODE_EXCL_KERN | \
> > ETM_MODE_EXCL_USER)
> >
> > -#define TRCSTATR_IDLE_BIT 0
> > +#define TRCSTATR_IDLE_BIT BIT(0)
> > +#define TRCSTATR_PMSTABLE_BIT BIT(1)
> > #define ETM_DEFAULT_ADDR_COMP 0
> >
> > /* PowerDown Control Register bits */
> > @@ -281,6 +282,65 @@ struct etmv4_config {
> > u32 ext_inp;
> > };
> >
> > +/**
> > + * struct etm4_save_state - state to be preserved when ETM is without power
> > + */
> > +struct etmv4_save_state {
> > + u32 trcprgctlr;
> > + u32 trcprocselr;
> > + u32 trcconfigr;
> > + u32 trcauxctlr;
> > + u32 trceventctl0r;
> > + u32 trceventctl1r;
> > + u32 trcstallctlr;
> > + u32 trctsctlr;
> > + u32 trcsyncpr;
> > + u32 trcccctlr;
> > + u32 trcbbctlr;
> > + u32 trctraceidr;
> > + u32 trcqctlr;
> > +
> > + u32 trcvictlr;
> > + u32 trcviiectlr;
> > + u32 trcvissctlr;
> > + u32 trcvipcssctlr;
> > + u32 trcvdctlr;
> > + u32 trcvdsacctlr;
> > + u32 trcvdarcctlr;
> > +
> > + u32 trcseqevr[ETM_MAX_SEQ_STATES];
> > + u32 trcseqrstevr;
> > + u32 trcseqstr;
> > + u32 trcextinselr;
> > + u32 trccntrldvr[ETMv4_MAX_CNTR];
> > + u32 trccntctlr[ETMv4_MAX_CNTR];
> > + u32 trccntvr[ETMv4_MAX_CNTR];
> > +
> > + u32 trcrsctlr[ETM_MAX_RES_SEL * 2];
> > +
> > + u32 trcssccr[ETM_MAX_SS_CMP];
> > + u32 trcsscsr[ETM_MAX_SS_CMP];
> > + u32 trcsspcicr[ETM_MAX_SS_CMP];
> > +
> > + u64 trcacvr[ETM_MAX_SINGLE_ADDR_CMP];
> > + u64 trcacatr[ETM_MAX_SINGLE_ADDR_CMP];
> > + u64 trcdvcvr[ETM_MAX_DATA_VAL_CMP];
> > + u64 trcdvcmr[ETM_MAX_DATA_VAL_CMP];
> > + u64 trccidcvr[ETMv4_MAX_CTXID_CMP];
> > + u32 trcvmidcvr[ETM_MAX_VMID_CMP];
> > + u32 trccidcctlr0;
> > + u32 trccidcctlr1;
> > + u32 trcvmidcctlr0;
> > + u32 trcvmidcctlr1;
> > +
> > + u32 trcclaimset;
> > +
> > + u32 cntr_val[ETMv4_MAX_CNTR];
> > + u32 seq_state;
> > + u32 vinst_ctrl;
> > + u32 ss_status[ETM_MAX_SS_CMP];
> > +};
> > +
> > /**
> > * struct etm4_drvdata - specifics associated to an ETM component
> > * @base: Memory mapped base address for this component.
> > @@ -337,6 +397,8 @@ struct etmv4_config {
> > * @atbtrig: If the implementation can support ATB triggers
> > * @lpoverride: If the implementation can support low-power state over.
> > * @config: structure holding configuration parameters.
> > + * @save_state: State to be preserved across power loss
> > + * @nb: CPU PM notifier
> > */
> > struct etmv4_drvdata {
> > void __iomem *base;
> > @@ -383,6 +445,8 @@ struct etmv4_drvdata {
> > bool atbtrig;
> > bool lpoverride;
> > struct etmv4_config config;
> > + struct etmv4_save_state save_state;
> > + struct notifier_block nb;
> > };
> >
> > /* Address comparator access types */
> > diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
> > index 4b130281236a..e85d09e597a0 100644
> > --- a/drivers/hwtracing/coresight/coresight.c
> > +++ b/drivers/hwtracing/coresight/coresight.c
> > @@ -140,7 +140,7 @@ static inline bool coresight_is_claimed_self_hosted(void __iomem *base)
> > return coresight_read_claim_tags(base) == CORESIGHT_CLAIM_SELF_HOSTED;
> > }
> >
> > -static inline bool coresight_is_claimed_any(void __iomem *base)
> > +bool coresight_is_claimed_any(void __iomem *base)
> > {
> > return coresight_read_claim_tags(base) != 0;
> > }
> > diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> > index 62a520df8add..4f7ba923ffc4 100644
> > --- a/include/linux/coresight.h
> > +++ b/include/linux/coresight.h
> > @@ -268,6 +268,8 @@ extern int coresight_claim_device_unlocked(void __iomem *base);
> > extern void coresight_disclaim_device(void __iomem *base);
> > extern void coresight_disclaim_device_unlocked(void __iomem *base);
> >
> > +extern bool coresight_is_claimed_any(void __iomem *base);
> > +
> > #else
> > static inline struct coresight_device *
> > coresight_register(struct coresight_desc *desc) { return NULL; }
> > @@ -290,6 +292,11 @@ static inline int coresight_claim_device(void __iomem *base)
> > static inline void coresight_disclaim_device(void __iomem *base) {}
> > static inline void coresight_disclaim_device_unlocked(void __iomem *base) {}
> >
> > +static inline bool coresight_is_claimed_any(void __iomem *base)
> > +{
> > + return false;
> > +}
> > +
>
> I wanted to test your code but it doesn't apply on the CS next branch:
>
> https://git.linaro.org/kernel/coresight.git/log/?h=next
Oh sorry about that, this was ontop of v5.2-rc5, I'll rebase to the CS branch
on the next iteration.
Thanks for the responsive feedback.
Andrew Murray
>
> Thanks,
> Mathieu
>
> > #endif
> >
> > #ifdef CONFIG_OF
> > --
> > 2.21.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 2/2] DaVinci DT update for v5.3
From: Sekhar Nori @ 2019-06-20 11:07 UTC (permalink / raw)
To: ARM-SoC Maintainers
Cc: Bartosz Golaszewski, Sekhar Nori, Linux ARM Mailing List
In-Reply-To: <20190620110703.18616-1-nsekhar@ti.com>
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v5.3/dt
for you to fetch changes up to 3a4b44d5c032f03cee71a8f2ad5c10ce18b3519b:
ARM: davinci_all_defconfig: Enable CPUFREQ_DT (2019-06-14 18:22:37 +0530)
----------------------------------------------------------------
This pull request adds CPUFreq support for DA850 boards in device-tree
boot using the generic CPUFREQ_DT driver.
----------------------------------------------------------------
Bartosz Golaszewski (1):
ARM: dts: da850-evm: enable cpufreq
David Lechner (4):
ARM: dts: da850: add cpu node and operating points to DT
ARM: dts: da850-lego-ev3: enable cpufreq
ARM: dts: da850-lcdk: enable cpufreq
ARM: davinci_all_defconfig: Enable CPUFREQ_DT
arch/arm/boot/dts/da850-evm.dts | 13 +++++++++
arch/arm/boot/dts/da850-lcdk.dts | 36 ++++++++++++++++++++++++
arch/arm/boot/dts/da850-lego-ev3.dts | 30 ++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 50 ++++++++++++++++++++++++++++++++++
arch/arm/configs/davinci_all_defconfig | 1 +
5 files changed, 130 insertions(+)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 1/2] DaVinci Soc updates for v5.3
From: Sekhar Nori @ 2019-06-20 11:07 UTC (permalink / raw)
To: ARM-SoC Maintainers
Cc: Bartosz Golaszewski, Sekhar Nori, Linux ARM Mailing List
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v5.3/soc
for you to fetch changes up to 1f8e44b622dc9d47af1815ac59169b1adaa1195d:
ARM: davinci: Use GPIO lookup table for DA850 LEDs (2019-06-20 14:36:15 +0530)
----------------------------------------------------------------
This pull request has a patch to switch DA850 EVM GPIO LED support to use
GPIO lookup table
----------------------------------------------------------------
Linus Walleij (1):
ARM: davinci: Use GPIO lookup table for DA850 LEDs
arch/arm/mach-davinci/board-da850-evm.c | 43 +++++++++++++++++----------------
1 file changed, 22 insertions(+), 21 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [cip-dev] [ANNOUNCE] Release 4.19.52-cip4 and 4.4.182-cip34
From: nobuhiro1.iwamatsu at toshiba.co.jp @ 2019-06-20 11:07 UTC (permalink / raw)
To: cip-dev
Hi all,
CIP kernel team has released Linux kernel 4.19.52-cip4 and 4.4.182-cip34 for SACK Panic[0].
You can get this release via the git tree at:
4.19.52-cip4:
repository: https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch: linux-4.19.y-cip
commit: 097491b463d99691d7857aa8ff26f04cdb30c55b
4.4.182-cip34:
repository: https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch: linux-4.4.y-cip
commit: f70ae212791f2a559cc32ea0fc6f92f60b1c8fbb
Best regards,
Nobuhiro
[0]: https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
^ permalink raw reply
* [U-Boot] [PATCH 2/2] efi_loader: consistent error handling in efidebug.c
From: Heinrich Schuchardt @ 2019-06-20 11:06 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20190620110636.8370-1-xypron.glpk@gmx.de>
If a variable cannot be set, always show an information message.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
cmd/efidebug.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index 479e37714c..cb152b3339 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -506,7 +506,7 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
void *data = NULL;
efi_uintn_t size;
efi_status_t ret;
- int r;
+ int r = CMD_RET_SUCCESS;
if (argc < 6 || argc > 7)
return CMD_RET_USAGE;
@@ -563,7 +563,10 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS,
size, data));
- r = (ret == EFI_SUCCESS ? CMD_RET_SUCCESS : CMD_RET_FAILURE);
+ if (ret != EFI_SUCCESS) {
+ printf("Cannot set %ls\n", var_name16);
+ r = CMD_RET_FAILURE;
+ }
out:
free(data);
efi_free_pool(device_path);
@@ -610,7 +613,7 @@ static int do_efi_boot_rm(cmd_tbl_t *cmdtp, int flag,
ret = EFI_CALL(RT->set_variable(var_name16, &guid, 0, 0, NULL));
if (ret) {
- printf("cannot remove Boot%04X", id);
+ printf("Cannot remove Boot%04X", id);
return CMD_RET_FAILURE;
}
}
@@ -897,7 +900,7 @@ static int do_efi_boot_next(cmd_tbl_t *cmdtp, int flag,
char *endp;
efi_guid_t guid;
efi_status_t ret;
- int r;
+ int r = CMD_RET_SUCCESS;
if (argc != 2)
return CMD_RET_USAGE;
@@ -916,7 +919,10 @@ static int do_efi_boot_next(cmd_tbl_t *cmdtp, int flag,
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS,
size, &bootnext));
- r = (ret == EFI_SUCCESS ? CMD_RET_SUCCESS : CMD_RET_FAILURE);
+ if (ret != EFI_SUCCESS) {
+ printf("Cannot set BootNext\n");
+ r = CMD_RET_FAILURE;
+ }
out:
return r;
}
@@ -943,7 +949,7 @@ static int do_efi_boot_order(cmd_tbl_t *cmdtp, int flag,
char *endp;
efi_guid_t guid;
efi_status_t ret;
- int r;
+ int r = CMD_RET_SUCCESS;
if (argc == 1)
return show_efi_boot_order();
@@ -973,7 +979,10 @@ static int do_efi_boot_order(cmd_tbl_t *cmdtp, int flag,
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS,
size, bootorder));
- r = (ret == EFI_SUCCESS ? CMD_RET_SUCCESS : CMD_RET_FAILURE);
+ if (ret != EFI_SUCCESS) {
+ printf("Cannot set BootOrder\n");
+ r = CMD_RET_FAILURE;
+ }
out:
free(bootorder);
--
2.20.1
^ permalink raw reply related
* [U-Boot] [PATCH 1/2] efi_loader: consistent types in efidebug.c
From: Heinrich Schuchardt @ 2019-06-20 11:06 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20190620110636.8370-1-xypron.glpk@gmx.de>
efi_status_t and int are of different size. Use separate variables for
return codes of different type.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
cmd/efidebug.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index e657226254..479e37714c 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -505,7 +505,8 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
struct efi_load_option lo;
void *data = NULL;
efi_uintn_t size;
- int ret;
+ efi_status_t ret;
+ int r;
if (argc < 6 || argc > 7)
return CMD_RET_USAGE;
@@ -538,7 +539,7 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
if (ret != EFI_SUCCESS) {
printf("Cannot create device path for \"%s %s\"\n",
argv[3], argv[4]);
- ret = CMD_RET_FAILURE;
+ r = CMD_RET_FAILURE;
goto out;
}
lo.file_path = file_path;
@@ -553,7 +554,7 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
size = efi_serialize_load_option(&lo, (u8 **)&data);
if (!size) {
- ret = CMD_RET_FAILURE;
+ r = CMD_RET_FAILURE;
goto out;
}
@@ -562,14 +563,14 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS,
size, data));
- ret = (ret == EFI_SUCCESS ? CMD_RET_SUCCESS : CMD_RET_FAILURE);
+ r = (ret == EFI_SUCCESS ? CMD_RET_SUCCESS : CMD_RET_FAILURE);
out:
free(data);
efi_free_pool(device_path);
efi_free_pool(file_path);
free(lo.label);
- return ret;
+ return r;
}
/**
@@ -896,6 +897,7 @@ static int do_efi_boot_next(cmd_tbl_t *cmdtp, int flag,
char *endp;
efi_guid_t guid;
efi_status_t ret;
+ int r;
if (argc != 2)
return CMD_RET_USAGE;
@@ -903,7 +905,7 @@ static int do_efi_boot_next(cmd_tbl_t *cmdtp, int flag,
bootnext = (u16)simple_strtoul(argv[1], &endp, 16);
if (*endp != '\0' || bootnext > 0xffff) {
printf("invalid value: %s\n", argv[1]);
- ret = CMD_RET_FAILURE;
+ r = CMD_RET_FAILURE;
goto out;
}
@@ -914,9 +916,9 @@ static int do_efi_boot_next(cmd_tbl_t *cmdtp, int flag,
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS,
size, &bootnext));
- ret = (ret == EFI_SUCCESS ? CMD_RET_SUCCESS : CMD_RET_FAILURE);
+ r = (ret == EFI_SUCCESS ? CMD_RET_SUCCESS : CMD_RET_FAILURE);
out:
- return ret;
+ return r;
}
/**
@@ -941,6 +943,7 @@ static int do_efi_boot_order(cmd_tbl_t *cmdtp, int flag,
char *endp;
efi_guid_t guid;
efi_status_t ret;
+ int r;
if (argc == 1)
return show_efi_boot_order();
@@ -957,7 +960,7 @@ static int do_efi_boot_order(cmd_tbl_t *cmdtp, int flag,
id = (int)simple_strtoul(argv[i], &endp, 16);
if (*endp != '\0' || id > 0xffff) {
printf("invalid value: %s\n", argv[i]);
- ret = CMD_RET_FAILURE;
+ r = CMD_RET_FAILURE;
goto out;
}
@@ -970,11 +973,11 @@ static int do_efi_boot_order(cmd_tbl_t *cmdtp, int flag,
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS,
size, bootorder));
- ret = (ret == EFI_SUCCESS ? CMD_RET_SUCCESS : CMD_RET_FAILURE);
+ r = (ret == EFI_SUCCESS ? CMD_RET_SUCCESS : CMD_RET_FAILURE);
out:
free(bootorder);
- return ret;
+ return r;
}
static cmd_tbl_t cmd_efidebug_boot_sub[] = {
--
2.20.1
^ permalink raw reply related
* [U-Boot] [PATCH 0/2] efi_loader: consistent error handling in efidebug.c
From: Heinrich Schuchardt @ 2019-06-20 11:06 UTC (permalink / raw)
To: u-boot
If a variable cannot be set, always show an information message.
Do not reuse a variable for a value of a different type.
Heinrich Schuchardt (2):
efi_loader: consistent types in efidebug.c
efi_loader: consistent error handling in efidebug.c
cmd/efidebug.c | 36 ++++++++++++++++++++++++------------
1 file changed, 24 insertions(+), 12 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [RFC PATCH 6/7] sched/cpufreq: Improve sugov_cpu_is_busy accuracy
From: Patrick Bellasi @ 2019-06-20 11:05 UTC (permalink / raw)
To: Douglas Raillard
Cc: linux-kernel, linux-pm, mingo, peterz, quentin.perret,
dietmar.eggemann
In-Reply-To: <e908b2ab-5c86-5be1-d3f0-36f2b26973c5@arm.com>
On 19-Jun 17:19, Douglas Raillard wrote:
> Hi Patrick,
Hi!
> On 5/16/19 1:55 PM, Patrick Bellasi wrote:
> > On 08-May 18:43, douglas.raillard@arm.com wrote:
> > > From: Douglas RAILLARD <douglas.raillard@arm.com>
> > >
> > > Avoid assuming a CPU is busy when it has begun being idle before
> > > get_next_freq() is called. This is achieved by making sure the CPU will
> > > not be detected as busy by other CPUs whenever its utilization is
> > > decreasing.
> >
> > If I understand it correctly, what you are after here is a "metric"
> > which tells you (in a shared performance domain) if a CPU has been
> > busy for a certain amount of time.
> > You do that by reworking the way idle_calls are accounted for the
> > sugov_update_single() case.
> >
> > That approach could work but it looks a bit convoluted in the way it's
> > coded and it's also difficult to exclude there could be corner cases
> > with wired behaviors.
> > Isn't that why you "fix" the saved_idle_calls counter after all?
> >
> > What about a different approach where we:
> >
> > 1. we annotate the timestamp a CPU wakes up from IDLE (last_wakeup_time)
> >
> > 2. we use that annotated last_wake_time and the rq->nr_running to
> > define the "cpu is busy" heuristic.
> >
> > Looking at a sibling CPU, I think we can end up with two main cases:
> >
> > 1. CPU's nr_running is == 0
> > then we don't consider busy that CPU
> >
> > 2. CPU's nr_running is > 0
> > then the CPU is busy iff
> > (current_time - last_wakeup_tim) >= busy_threshold
> >
> > Notice that, when a CPU is active, its rq clock is periodically
> > updated, at least once per tick. Thus, provided a tick time is not too
> > long to declare busy a CPU, then the above logic should work.
> >
> > Perhaps the busy_threshold can also be defined considering the PELT
> > dynamics and starting from an expected utilization increase converted
> > in time.
>
> After experimenting with quite a few combinations, I managed to get a heuristic
> based on util_avg and util_est_enqueued that seems to work better in my case.
> Key differences are:
> * this new heuristic only really takes into account CFS signals
> (current one based on idle calls takes into account everything that executes
> on a given CPU.)
Right, that should not be an issue. You are after boosting for CFS
tasks at the end, while for RT and DL we don't need boosting since
they have their own mechanisms.
> * it will mark a CPU as busy less often, since it should only trigger when
> there is a change in the utilization of a currently enqueued tasks.
That sounds right too.
> Util changes due to enqueue/dequeue will not trigger it, which IMHO
> is desirable, since we only want to bias frequency selection
> when we know that we don't have precise utilization values for the
> enqueued tasks (because the task has changed its behavior).
Agree.
Best,
Patrick
--
#include <best/regards.h>
Patrick Bellasi
^ permalink raw reply
* Re: [Xen-devel] [PATCH] xen/arm: fix build after 2e35cdf
From: Volodymyr Babchuk @ 2019-06-20 11:05 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org, Julien Grall, Volodymyr Babchuk,
andrew.cooper3@citrix.com
In-Reply-To: <alpine.DEB.2.21.1906191446280.2072@sstabellini-ThinkPad-T480s>
Hi Stefano, Julien,
Stefano Stabellini writes:
> On Wed, 19 Jun 2019, Julien Grall wrote:
>> Hi Stefano,
>>
>> Title: You should at least mention this is for op-tee.
>>
>> Also, mostly likely the sha1 is too small and likely to match multiple commit
>> in the future. So you want to specify the title of the commit.
>>
>> On 6/19/19 10:24 PM, Stefano Stabellini wrote:
>> > Optee breaks the build with:
>> >
>> > optee.c: In function ‘translate_noncontig.isra.4’:
>> > optee.c:743:38: error: ‘xen_data’ may be used uninitialized in this function
>> > [-Werror=maybe-uninitialized]
>> > xen_data->next_page_data = page_to_maddr(xen_pgs + 1);
>> > ^
>> > optee.c:732:71: error: ‘guest_data’ may be used uninitialized in this
>> > function [-Werror=maybe-uninitialized]
>> > page =
>> > get_domain_ram_page(gaddr_to_gfn(guest_data->pages_list[idx]));
>> > ^
>> > optee.c:750:21: error: ‘guest_pg’ may be used uninitialized in this function
>> > [-Werror=maybe-uninitialized]
>> > put_page(guest_pg);
>> > ^
>> > cc1: all warnings being treated as errors
>> >
>> > Fix it by initializing xen_data, guest_data, guest_pg to NULL. Also set
>> > xen_pgs to NULL for consistency.
>>
>> Without more explanation I think this is an unwise choice. If GCC thinks it is
>> going to be used unitialized, then mostly likely you silent an error that
>> could end up to dereference NULL.
There is no way to use this variables without initialization. They are
always initialized on the first iteration of the loop, when idx equals
to 0. Newer version of GCC can infer this, but look like this causes
problem for older versions.
>> Also, setting xen_pgs for consistency will only defeat the compiler. Leading
>> to dereferencing NULL and crash Xen...
>>
>> For xen_pgs, this should definitely not be NULL. For the two others, you need
>> to explain why this is fine (if this is just because the compiler can't find
>> the reason, then you should add a comment in the code to explain it).
>
> I was only trying to unblock the build. I'll withdraw the patch and let
> Volodmir fix it properly.
Actually, your patch is fine, taking into account Julien's comment about
xen_pgs and justification in the comments.
So, you can send fixed version or I can do this, if you don't want to.
>
> Volodmir, FYI I reproduced the issue using Ubuntu Trusty gcc
> 4.8.4-2ubuntu1~14.04.3.
Oh, I see. This is the quite old version of GCC. I'm using
aarch64-poky-linux-gcc (Linaro GCC 5.2-2015.11-2) 5.2.1 20151005
which is also old, but at least it tracks variables initialization
better.
--
Best regards,Volodymyr Babchuk
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t 5/5] docs: Embed subtest descriptions in the documentation
From: Ser, Simon @ 2019-06-20 11:05 UTC (permalink / raw)
To: Hiler, Arkadiusz, igt-dev@lists.freedesktop.org, daniel@ffwll.ch
In-Reply-To: <20190620105225.72w3opn6qccyqn2e@ahiler-desk1.fi.intel.com>
On Thu, 2019-06-20 at 13:52 +0300, Arkadiusz Hiler wrote:
> On Thu, Jun 20, 2019 at 11:20:18AM +0300, Petri Latvala wrote:
> > On Mon, Jun 17, 2019 at 01:54:43PM +0300, Arkadiusz Hiler wrote:
> > > This rewrites generate_description_xml in Python, so that we generate
> > > properly escaped XML. The switch also makes the code more manageable.
> > >
> > > Changes in the generated docbook:
> > >
> > > 1. subtests are not simply listed anymore, they are now another (sub)section
> > >
> > > 2. subtests are now linkable,
> > > e.g. docs/igt-kms-tests.html#kms_hdmi_inject@inject-4k
> > >
> > > 3. subtest's section now includes output of --describe
> > >
> > > Python is required already by gtk-doc and we are not using anything
> > > other than the standard library.
> >
> > Python yes, but what about python3? My Debian installation is ancient
> > even on Debian standards and gtk-doc-tools depends on python2. I'm too
> > lazy to check if the version used by gitlab-CI depends on python3, so
> > asking instead: Do you have a fork in gitlab for this? :P
>
> It works on Fedora:
>
> % head -n 1 $(which gtkdoc-mkhtml)
> #!/usr/bin/python3
I believe `#!/usr/bin/env python3` is more correct.
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/.gitlab-ci.yml#L174
>
>
> But for explicitness I can squash in:
>
> diff --git a/docs/reference/igt-gpu-tools/meson.build b/docs/reference/igt-gpu-tools/meson.build
> index e2bdc495..b3a4c0bd 100644
> --- a/docs/reference/igt-gpu-tools/meson.build
> +++ b/docs/reference/igt-gpu-tools/meson.build
> @@ -45,6 +45,7 @@ test_groups = [
> 'vgem',
> ]
>
> +find_program('python3') # required by doc generators
> gen_description = find_program('generate_description_xml.py')
> gen_programs = find_program('generate_programs_xml.sh')
>
> _______________________________________________
> igt-dev mailing list
> igt-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.