* Re: [PATCH 3/6] KVM: PPC: Book3S HV: Allow HPT and radix on the same core for POWER9 v2.2
From: Paul Mackerras @ 2018-01-18 1:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: kvm, linuxppc-dev, kvm-ppc
In-Reply-To: <1516187685.31850.190.camel@au1.ibm.com>
On Wed, Jan 17, 2018 at 10:14:45PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2018-01-17 at 20:51 +1100, Paul Mackerras wrote:
> > +
> > + /*
> > + * POWER9 chips before version 2.02 can't have some threads in
> > + * HPT mode and some in radix mode on the same core.
> > + */
> > + if (cpu_has_feature(CPU_FTR_ARCH_300)) {
> > + unsigned int pvr = mfspr(SPRN_PVR);
> > + if ((pvr >> 16) == PVR_POWER9 && (pvr & 0xfff) < 0x202)
> > + no_mixing_hpt_and_radix = true;
> > + }
> > +
> > return r;
> > }
>
> You need to check that it's a Nimbus using the top nimble of the bottom
> 16 bits of PVR. For Cumulus, the fixes are either in 1.0 or 1.1 (to
> check).
OK, how about this for the check:
if (cpu_has_feature(CPU_FTR_ARCH_300)) {
unsigned int pvr = mfspr(SPRN_PVR);
if ((pvr >> 16) == PVR_POWER9 &&
(((pvr & 0xe000) == 0 && (pvr & 0xfff) < 0x202) ||
((pvr & 0xe000) == 0x2000 && (pvr & 0xfff) < 0x101)))
no_mixing_hpt_and_radix = true;
}
Paul.
^ permalink raw reply
* Re: [PATCH 0/3] PCI: move DT PCI functions to PCI core
From: Bjorn Helgaas @ 2018-01-17 23:55 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Helgaas, devicetree, linux-kernel, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Frank Rowand, linuxppc-dev,
linux-pci
In-Reply-To: <20180104211215.11344-1-robh@kernel.org>
On Thu, Jan 04, 2018 at 03:12:12PM -0600, Rob Herring wrote:
> Most subsystem specific functions have been moved into the respective
> subsystems. Only PCI and networking remain. This series moves most of the
> PCI related code to drivers/pci/of.c. Some bus address functions for PCI
> remain in of/address.c because we don't have infrastructure to split up
> the per bus helper functions.
>
> I expect Bjorn to take this series, so PPC maintainers please ack.
>
> Rob
>
> Rob Herring (3):
> PCI: move OF related PCI functions into PCI core
> powerpc/pci: use of_irq_parse_and_map_pci helper
> PCI: make of_irq_parse_pci static
>
> arch/arm/mach-mvebu/Kconfig | 1 -
> arch/powerpc/kernel/pci-common.c | 8 +-
> drivers/of/Kconfig | 16 --
> drivers/of/Makefile | 2 -
> drivers/of/address.c | 8 +-
> drivers/of/of_pci.c | 384 -----------------------------
> drivers/of/of_pci_irq.c | 131 ----------
> drivers/pci/of.c | 505 +++++++++++++++++++++++++++++++++++++++
> include/linux/of_pci.h | 8 +-
> 9 files changed, 510 insertions(+), 553 deletions(-)
> delete mode 100644 drivers/of/of_pci.c
> delete mode 100644 drivers/of/of_pci_irq.c
Applied to pci/dt-resources for v4.16, thanks!
I'll update this if necessary if PPC maintainers comment.
^ permalink raw reply
* Re: [PATCH 0/3] PCI: move DT PCI functions to PCI core
From: Bjorn Helgaas @ 2018-01-17 23:33 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Helgaas, devicetree, linux-kernel, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Frank Rowand, linuxppc-dev,
linux-pci
In-Reply-To: <20180104211215.11344-1-robh@kernel.org>
On Thu, Jan 04, 2018 at 03:12:12PM -0600, Rob Herring wrote:
> Most subsystem specific functions have been moved into the respective
> subsystems. Only PCI and networking remain. This series moves most of the
> PCI related code to drivers/pci/of.c. Some bus address functions for PCI
> remain in of/address.c because we don't have infrastructure to split up
> the per bus helper functions.
>
> I expect Bjorn to take this series, so PPC maintainers please ack.
I plan to merge this for v4.16, so PPC maintainers, this is your
chance to speak up :)
> Rob Herring (3):
> PCI: move OF related PCI functions into PCI core
> powerpc/pci: use of_irq_parse_and_map_pci helper
> PCI: make of_irq_parse_pci static
>
> arch/arm/mach-mvebu/Kconfig | 1 -
> arch/powerpc/kernel/pci-common.c | 8 +-
> drivers/of/Kconfig | 16 --
> drivers/of/Makefile | 2 -
> drivers/of/address.c | 8 +-
> drivers/of/of_pci.c | 384 -----------------------------
> drivers/of/of_pci_irq.c | 131 ----------
> drivers/pci/of.c | 505 +++++++++++++++++++++++++++++++++++++++
> include/linux/of_pci.h | 8 +-
> 9 files changed, 510 insertions(+), 553 deletions(-)
> delete mode 100644 drivers/of/of_pci.c
> delete mode 100644 drivers/of/of_pci_irq.c
>
> --
> 2.14.1
^ permalink raw reply
* linux-next: manual merge of the powerpc tree with the powerpc-fixes tree
From: Stephen Rothwell @ 2018-01-17 22:21 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, PowerPC
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
Hi all,
Today's linux-next merge of the powerpc tree got a conflict in:
arch/powerpc/kernel/setup-common.c
between commit:
349524bc0da6 ("powerpc: Don't preempt_disable() in show_cpuinfo()")
from the powerpc-fixes tree and commit:
f5f563012a70 ("powerpc: Make newline in cpuinfo unconditional")
from the powerpc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/powerpc/kernel/setup-common.c
index 3f33869c6486,24da91768133..000000000000
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@@ -346,10 -354,10 +346,7 @@@ static int show_cpuinfo(struct seq_fil
loops_per_jiffy / (500000/HZ),
(loops_per_jiffy / (5000/HZ)) % 100);
#endif
-
- #ifdef CONFIG_SMP
seq_printf(m, "\n");
- #endif
-
- preempt_enable();
-
/* If this is the last cpu, print the summary */
if (cpumask_next(cpu_id, cpu_online_mask) >= nr_cpu_ids)
show_cpuinfo_summary(m);
^ permalink raw reply
* Re: [PATCH] net: fs_enet: do not call phy_stop() in interrupts
From: David Miller @ 2018-01-17 20:44 UTC (permalink / raw)
To: christophe.leroy
Cc: pantelis.antoniou, vbordug, linux-kernel, linuxppc-dev, netdev
In-Reply-To: <20180116093305.A04A26EEC5@localhost.localdomain>
From: Christophe Leroy <christophe.leroy@c-s.fr>
Date: Tue, 16 Jan 2018 10:33:05 +0100 (CET)
> In case of TX timeout, fs_timeout() calls phy_stop(), which
> triggers the following BUG_ON() as we are in interrupt.
...
> This patch moves fs_timeout() actions into an async worker.
>
> Fixes: commit 48257c4f168e5 ("Add fs_enet ethernet network driver, for several embedded platforms")
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v5 00/17] ASoC: fsl_ssi: Clean up - program flow level
From: Maciej S. Szmigiero @ 2018-01-17 20:27 UTC (permalink / raw)
To: Nicolin Chen
Cc: timur, broonie, linux-kernel, linuxppc-dev, alsa-devel, lgirdwood,
fabio.estevam, caleb, arnaud.mouiche, lukma, kernel
In-Reply-To: <20180117200210.GA9523@Asurada-Nvidia>
On 17.01.2018 21:02, Nicolin Chen wrote:
> On Wed, Jan 17, 2018 at 08:38:48PM +0100, Maciej S. Szmigiero wrote:
>
>> However, I have a small nitpick regarding a comment newly added in
>> this version of patch 16:
>> + /*
>> + * Do not set SSI dev as the parent of AC97 CODEC device since
>> + * it does not have a DT node. Otherwise ASoC core will assume
>> + * CODEC has the same DT node as the SSI, so it may return a
>> + * NULL pointer of CODEC when asked for SSI via the DT node
>>
>> The second part of the last sentence isn't really true, the ASoC core
>> will return a (valid, non-NULL) CODEC object pointer when asked for
>> the SSI one if we set the SSI as the parent device of a AC'97 CODEC
>> platform device.
>>
>> The NULL pointer dereference when starting a playback that I wrote
>> about in my previous message happens because in this situation the SSI
>> DAI probe callback won't ever get called and so won't setup DMA data
>> pointers (they will remain NULL).
>
> Well, somehow the DMA data pointer of CODEC could be described
> as "a NULL pointer of CODEC" reluctantly...it confuses people
> though.
>
>> And this in turn will cause the ASoC DMA code to dereference these
>> NULL pointers when starting a playback (the same will probably happen
>> also when starting a capture).
>>
>> Sorry if I wasn't 100% clear about these details in my previous
>> message describing this issue.
>
> I would prefer to send an incremental patch later to update it,
> if there are no new comments against this version; Otherwise, I
> will update it in a next version once there is a need to send a
> v6 anyway.
IMHO it is such a tiny thing that it isn't worth respinning 17
patch series just for it, it can be easily improved later via
a separate patch.
> Thanks
>
Thanks,
Maciej
^ permalink raw reply
* Re: [PATCH v5 00/17] ASoC: fsl_ssi: Clean up - program flow level
From: Nicolin Chen @ 2018-01-17 20:02 UTC (permalink / raw)
To: Maciej S. Szmigiero
Cc: timur, broonie, linux-kernel, linuxppc-dev, alsa-devel, lgirdwood,
fabio.estevam, caleb, arnaud.mouiche, lukma, kernel
In-Reply-To: <a6621849-2621-79ee-c8a4-09e23beea2c5@maciej.szmigiero.name>
On Wed, Jan 17, 2018 at 08:38:48PM +0100, Maciej S. Szmigiero wrote:
> However, I have a small nitpick regarding a comment newly added in
> this version of patch 16:
> + /*
> + * Do not set SSI dev as the parent of AC97 CODEC device since
> + * it does not have a DT node. Otherwise ASoC core will assume
> + * CODEC has the same DT node as the SSI, so it may return a
> + * NULL pointer of CODEC when asked for SSI via the DT node
>
> The second part of the last sentence isn't really true, the ASoC core
> will return a (valid, non-NULL) CODEC object pointer when asked for
> the SSI one if we set the SSI as the parent device of a AC'97 CODEC
> platform device.
>
> The NULL pointer dereference when starting a playback that I wrote
> about in my previous message happens because in this situation the SSI
> DAI probe callback won't ever get called and so won't setup DMA data
> pointers (they will remain NULL).
Well, somehow the DMA data pointer of CODEC could be described
as "a NULL pointer of CODEC" reluctantly...it confuses people
though.
> And this in turn will cause the ASoC DMA code to dereference these
> NULL pointers when starting a playback (the same will probably happen
> also when starting a capture).
>
> Sorry if I wasn't 100% clear about these details in my previous
> message describing this issue.
I would prefer to send an incremental patch later to update it,
if there are no new comments against this version; Otherwise, I
will update it in a next version once there is a need to send a
v6 anyway.
Thanks
^ permalink raw reply
* Re: [PATCH v5 00/17] ASoC: fsl_ssi: Clean up - program flow level
From: Maciej S. Szmigiero @ 2018-01-17 19:38 UTC (permalink / raw)
To: Nicolin Chen
Cc: timur, broonie, linux-kernel, linuxppc-dev, alsa-devel, lgirdwood,
fabio.estevam, caleb, arnaud.mouiche, lukma, kernel
In-Reply-To: <1516171902-32669-1-git-send-email-nicoleotsuka@gmail.com>
On 17.01.2018 07:51, Nicolin Chen wrote:
> [ Maciej, could you please send your Tested-by/Reviewed-by for AC97
> once you confirm this series?
>
> And Caleb, this version does not need a test for non-AC97 cases.
>
> Thanks both! ]
>
> ==Change log==
> v5
> * Reworked the series by taking suggestions from Maciej for AC97
> + Fixed SSI lockup issue by changing cleanup sequence in PATCH-13
> + Moved fsl_ssi_hw_clean() after unregistering the CODEC device
> in PATCH-13
> + Set NULL as the parent of CODEC platform device to fix a NULL
> pointer dereference bug in PATCH-16
> * Updated comments of three variables/pointers in struct fsl_ssi
> to describe them more accurately in PATCH-16
> v4
> * Reworked the series by taking suggestions from Maciej
> + Added TXBIT0 bit back to play safe in PATCH-14
> + Made bool synchronous exclusive with AC97 mode in PATCH-16
> v3
> * Reworked the series by taking suggestions from Maciej
> + Added PATCH-01 to make RX and TX more clearly defined
> + Replaced "bool dir" with "int dir" in PATCH-04
> + Replaced "!dir" with "int adir" in PATCH-05
> + Put CBM_CFS behind the baudclk check to keep the same
> program flow in PATCH-14
> + Removed all cpu_dai_drv changes in PATCH-15
> v2
> * Reworked the series by taking suggestions from Maciej
> + Added PATCH-01 to keep all ssi->i2s_net updated
> + Replaced bool tx with bool dir in PATCH-03 and PATCH-06
> + Moved all initial register configurations from dai probe() to
> platform probe() so as to let AC97 CODEC successfully probe.
> * Added Tested-by from Caleb for TDM test cases.
>
> ==Background==
> The fsl_ssi driver was designed for PPC originally and then it has
> been updated to support different modes for i.MX Series, including
> SDMA, I2S Master mode, AC97 and older i.MXs with FIQ, by different
> contributors for different use cases in different coding styles.
>
> Additionally, in order to fix/work-around hardware bugs and design
> flaws, the driver made a lot of compromise so now its program flow
> looks very complicated and it's getting hard to maintain or update.
>
> So I am going to clean up the driver on both coding style level and
> program flow level.
>
> ==Introduction==
> This series of patches is the second set to clean up fsl_ssi driver
> in the program flow level. Any patch here may impact a fundamental
> test case like playback or record.
>
> ==Verification==
> This series of patches require fully tested. I have done such tests
> on i.MX6SoloX with WM8962 using imx_v6_v7_defconfig as:
> - Playback via I2S Master and Slave mode
> - Record via I2S Master and Slave mode
> - Simultaneous playback and record via I2S Master and Slave mode
> - Background playback with foreground record (starting at different
> time) via I2S Master and Slave mode
> - Background record with foreground playback (starting at different
> time) via I2S Master and Slave mode
> * All tests above by hacking offline_config to true in imx51.
>
> Caleb has tested v1-v4 with TDM lookback tests on i.MX6.
>
> Example of uncovered tests: AC97, PowerPC and FIQ.
For the whole series:
Tested-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Reviewed-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
However, I have a small nitpick regarding a comment newly added in
this version of patch 16:
+ /*
+ * Do not set SSI dev as the parent of AC97 CODEC device since
+ * it does not have a DT node. Otherwise ASoC core will assume
+ * CODEC has the same DT node as the SSI, so it may return a
+ * NULL pointer of CODEC when asked for SSI via the DT node
The second part of the last sentence isn't really true, the ASoC core
will return a (valid, non-NULL) CODEC object pointer when asked for
the SSI one if we set the SSI as the parent device of a AC'97 CODEC
platform device.
The NULL pointer dereference when starting a playback that I wrote
about in my previous message happens because in this situation the SSI
DAI probe callback won't ever get called and so won't setup DMA data
pointers (they will remain NULL).
And this in turn will cause the ASoC DMA code to dereference these
NULL pointers when starting a playback (the same will probably happen
also when starting a capture).
Sorry if I wasn't 100% clear about these details in my previous
message describing this issue.
Maciej
^ permalink raw reply
* [PATCH] powerpc/kernel: Fix L1D_SIZE to a non-zero value on missing cache nodes
From: Madhavan Srinivasan @ 2018-01-17 19:03 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, Madhavan Srinivasan
parse_cache_info() parse device tree to detect various [i/d] cache properties.
But if no cache nodes found in device tree, these properties are set to zero
as default in init_cache_info().
Having a zero value could cause a infinite loop in rfi_flush_callback() since
l1d_size is used to determine the lid_flush_set parameter which is used as
the upper bounce in L1D cache flush loop. So default the l1d_size to 64K if
it is zero.
Fixes: aa8a5e0062ac9 ('powerpc/64s: Add support for RFI flush of L1-D cache')
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/setup.h | 2 ++
arch/powerpc/kernel/setup_64.c | 16 ++++++++++++++++
2 files changed, 18 insertions(+)
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 469b7fdc9be4..12954bf2d3fe 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -41,6 +41,8 @@ static inline void pseries_little_endian_exceptions(void) {}
void rfi_flush_enable(bool enable);
+#define DEFAULT_L1D_SIZE (1024 * 64)
+
/* These are bit flags */
enum l1d_flush_type {
L1D_FLUSH_NONE = 0x1,
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 491be4179ddd..7a3077a2cd5c 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -856,6 +856,22 @@ static void init_fallback_flush(void)
int cpu;
l1d_size = ppc64_caches.l1d.size;
+
+ /*
+ * If there is no cache node in cpus/ device tree,
+ * l1d_size could be zero. This in turn make l1d_flush_sets as
+ * zero, which will be an issue in RFI_FLUSH_CALLBACK.
+ *
+ * RFI_FLUSH_CALLBACK use the l1d_flush_sets value as upper bounce
+ * (loaded in CTR) and loop with a `bdnz` instruction. If the CTR
+ * happen to zero, instruction (as per definition) will decrement
+ * CTR first and then compare. So we end up in a really big
+ * loop (becos of negative value in CTR). Avoid this by defaulting
+ * to a sane value (64kb).
+ */
+ if (!l1d_size)
+ l1d_size = DEFAULT_L1D_SIZE;
+
limit = min(safe_stack_limit(), ppc64_rma_size);
/*
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 3/5] powerpc/ftw: Implement a simple FTW driver
From: Randy Dunlap @ 2018-01-17 18:30 UTC (permalink / raw)
To: Sukadev Bhattiprolu, Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
In-Reply-To: <1516157443-17716-4-git-send-email-sukadev@linux.vnet.ibm.com>
On 01/16/18 18:50, Sukadev Bhattiprolu wrote:
> The Fast Thread Wake-up (FTW) driver provides user space applications an
> interface to the low latency Core-to-Core wakeup functionality in POWER9.
>
> This mechanism allows a thread on one core to efficiently send a message
> to a "waiting thread" on another core on the same chip, using the Virtual
> Accelrator Switchboard (VAS) subsystem.
>
> This initial FTW driver implements the ioctl and mmap operations on an
> FTW device node. Using these operations, a pair of application threads
> can establish a "communication channel" and use the COPY, PASTE and WAIT
> instructions to wait/wake up.
>
> PATCH 5/5 documents the API and includes an example of the usage.
>
> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> ---
> Changelog[v2]
> - [Michael Neuling] Rename from drop "nx" from name "nx-ftw".
> - [Michael Neuling] Use a single VAS_FTW_SETUP ioctl to simplify
> interface.
> - [Michael Ellerman] To work with paste emulation patch, mark
> PTE dirty in ->mmap() to ensure there is no fault on paste
> (the emulation patch must disable pagefaults when updating
> thread reconfig registers).
> - Check return value from set_thread_tidr().
> - Move driver drivers/misc/ftw.
>
> ---
> drivers/misc/Kconfig | 1 +
> drivers/misc/Makefile | 1 +
> drivers/misc/ftw/Kconfig | 16 +++
> drivers/misc/ftw/Makefile | 4 +
> drivers/misc/ftw/ftw.c | 346 ++++++++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 368 insertions(+)
> create mode 100644 drivers/misc/ftw/Kconfig
> create mode 100644 drivers/misc/ftw/Makefile
> create mode 100644 drivers/misc/ftw/ftw.c
> +static long ftw_ioctl(struct file *fp, unsigned int cmd, unsigned long arg)
> +{
> + switch (cmd) {
> +
> + case FTW_SETUP:
> + return ftw_ioc_ftw_setup(fp, arg);
> +
> + default:
> + return -EINVAL;
> + }
> +}
Nit: some versions of gcc (or maybe clang) complain about a typed function
not always having a return value in code like above, so it is often done as:
> +static long ftw_ioctl(struct file *fp, unsigned int cmd, unsigned long arg)
> +{
> + switch (cmd) {
> +
> + case FTW_SETUP:
> + return ftw_ioc_ftw_setup(fp, arg);
> +
> + default:
> + break;
> + }
return -EINVAL;
> +}
Do you expect to implement more ioctls? If not, just change the switch to
an if ().
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/5] powerpc/ftw: Define FTW_SETUP ioctl API
From: Randy Dunlap @ 2018-01-17 18:23 UTC (permalink / raw)
To: Sukadev Bhattiprolu, Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
In-Reply-To: <1516157443-17716-3-git-send-email-sukadev@linux.vnet.ibm.com>
On 01/16/18 18:50, Sukadev Bhattiprolu wrote:
> Define the FTW_SETUP ioctl interface for fast thread wakeup (FTW). A
> follow-on patch will implement the FTW driver and ioctl.
>
> Thanks to input from Ben Herrenschmidt, Michael Neuling, Michael Ellerman.
>
> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> ---
> Changelog[v2]
> - [Michael Neuling] Use a single VAS_FTW_SETUP ioctl and simplify
> the interface.
> ---
> include/uapi/misc/ftw.h | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 include/uapi/misc/ftw.h
>
> diff --git a/include/uapi/misc/ftw.h b/include/uapi/misc/ftw.h
> new file mode 100644
> index 0000000..f233f51
> --- /dev/null
> +++ b/include/uapi/misc/ftw.h
> @@ -0,0 +1,31 @@
> +/*
> + * Copyright 2018 IBM Corp.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#ifndef _UAPI_MISC_FTW_H
> +#define _UAPI_MISC_FTW_H
> +
> +#include <linux/types.h>
> +#include <linux/ioctl.h>
> +
> +#define FTW_FLAGS_PIN_WINDOW 0x1
> +
> +#define FTW_SETUP _IOW('v', 1, struct ftw_setup_attr)
ioctls should be documented in Documentation/ioctl/ioctl-number.txt.
Please update that file.
> +
> +struct ftw_setup_attr {
> + __s16 version;
> + __s16 vas_id; /* specific instance of vas or -1 for default */
> + __u32 reserved;
> +
> + __u64 reserved1;
> +
> + __u64 flags;
> + __u64 reserved2;
> +};
> +
> +#endif /* _UAPI_MISC_FTW_H */
>
--
~Randy
^ permalink raw reply
* Re: [PATCH v4 0/7] SR-IOV Enablement on PowerVM
From: Bryant G. Ly @ 2018-01-17 17:29 UTC (permalink / raw)
To: benh, paulus, mpe
Cc: seroyer, jjalvare, alex.williamson, helgaas, aik, ruscur,
linux-pci, linuxppc-dev, bodong, eli, saeedm
In-Reply-To: <20180105164552.36371-1-bryantly@linux.vnet.ibm.com>
Mike Ellerman/Ben,
Do you know if we can make 4.16 with this?
-Bryant
On 1/5/18 10:45 AM, Bryant G. Ly wrote:
> This patch series will enable SR-IOV on PowerVM. A specific set of
> lids for PFW/PHYP is required. They are planned to release with
> 920 at the moment.
>
> For IBM internal testers let me know of a system you want to test on
> and we can put on the lids required or we can provide a system to run
> the tests.
>
> This patch depends on the three patches:
> 988fc3ba5653278a8c14d6ccf687371775930d2b
> dae7253f9f78a731755ca20c66b2d2c40b86baea
> 608c0d8804ef3ca4cda8ec6ad914e47deb283d7b
>
> v1 - Initial Patch
> v2 - Addressed Alexey and Russell's comments
> v3 - Unify the call of .error_detected()
> v4 - Fixed subject and change log per Bjorn's comments and
> fixed Alexey's comments
>
> Bryant G. Ly (7):
> platform/pseries: Update VF config space after EEH
> linux/pci: Add uevents in AER and EEH error/resume
> platforms/pseries: Set eeh_pe of EEH_PE_VF type
> powerpc/kernel Add EEH operations to notify resume
> powerpc/kernel: Add EEH notify resume sysfs
> pseries/pci: Associate PEs to VFs in configure SR-IOV
> pseries/setup: Add Initialization of VF Bars
>
> arch/powerpc/include/asm/eeh.h | 2 +
> arch/powerpc/include/asm/pci-bridge.h | 5 +-
> arch/powerpc/include/asm/pci.h | 2 +
> arch/powerpc/kernel/eeh.c | 59 ++++++++++
> arch/powerpc/kernel/eeh_driver.c | 6 +
> arch/powerpc/kernel/eeh_sysfs.c | 45 ++++++++
> arch/powerpc/kernel/pci_of_scan.c | 2 +-
> arch/powerpc/platforms/powernv/eeh-powernv.c | 68 +----------
> arch/powerpc/platforms/pseries/eeh_pseries.c | 137 +++++++++++++++++++++-
> arch/powerpc/platforms/pseries/pci.c | 150 +++++++++++++++++++++++-
> arch/powerpc/platforms/pseries/setup.c | 164 +++++++++++++++++++++++++++
> drivers/pci/pcie/aer/aerdrv_core.c | 3 +
> include/linux/pci.h | 36 ++++++
> 13 files changed, 611 insertions(+), 68 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: export thread-tidr interfaces
From: Sukadev Bhattiprolu @ 2018-01-17 17:07 UTC (permalink / raw)
To: Frederic Barrat
Cc: Michael Ellerman, linuxppc-dev, Christophe Lombard, linux-kernel,
Philippe Bergheaud
In-Reply-To: <eff03efa-0637-c63a-a7ee-320c490cff9d@linux.vnet.ibm.com>
Frederic Barrat [fbarrat@linux.vnet.ibm.com] wrote:
> Hi,
>
>
> > diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> > index 2010e4c..f20c1ad 100644
> > --- a/arch/powerpc/kernel/process.c
> > +++ b/arch/powerpc/kernel/process.c
> > @@ -1560,6 +1560,7 @@ void clear_thread_tidr(struct task_struct *t)
> > free_thread_tidr(t->thread.tidr);
> > t->thread.tidr = 0;
> > }
> > +EXPORT_SYMBOL_GPL(clear_thread_tidr);
>
> Isn't it dangerous to export clear_thread_tidr()? Other modules may also
> have assigned the TIDR by calling set_thread_tidr(), so clearing it could
> potentially break those other modules. My understanding is that once the
> TIDR is assigned, there's no safe way to reclaim it other than the thread
> exiting. Or we would need some kind of reference counter.
Yes the FTW driver avoids calling clear_thread_tidr() for the same reasons.
I don't have a strong case for exporting clear_thread_tidr(). Here is the
updated patch, exporting just the set_thread_tidr().
Thanks,
Sukadev
---
>From 204ee3c918f8dad46c1e40d2d3730b07c10a87a3 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Date: Mon, 15 Jan 2018 13:43:18 -0600
Subject: [PATCH 1/2] powerpc: export set_thread_tidr()
Export set_thread_tidr() so it can be used by external modules.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
Changelog [Frederic Barrat] Don't export clear_thread_tidr()
---
arch/powerpc/kernel/process.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 2010e4c..20df2cb2 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1592,6 +1592,7 @@ int set_thread_tidr(struct task_struct *t)
return 0;
}
+EXPORT_SYMBOL_GPL(set_thread_tidr);
#endif /* CONFIG_PPC64 */
--
1.8.3.1
^ permalink raw reply related
* [PATCH for 4.16 02/11] powerpc: membarrier: Skip memory barrier in switch_mm() (v7)
From: Mathieu Desnoyers @ 2018-01-17 16:54 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra, Thomas Gleixner
Cc: linux-kernel, linux-api, Andy Lutomirski, Paul E . McKenney,
Boqun Feng, Andrew Hunter, Maged Michael, Avi Kivity,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Dave Watson, H . Peter Anvin, Andrea Parri, Russell King,
Greg Hackmann, Will Deacon, David Sehr, Linus Torvalds, x86,
Mathieu Desnoyers, Alan Stern, Alexander Viro, Nicholas Piggin,
linuxppc-dev, linux-arch
In-Reply-To: <20180117165458.13330-1-mathieu.desnoyers@efficios.com>
Allow PowerPC to skip the full memory barrier in switch_mm(), and
only issue the barrier when scheduling into a task belonging to a
process that has registered to use expedited private.
Threads targeting the same VM but which belong to different thread
groups is a tricky case. It has a few consequences:
It turns out that we cannot rely on get_nr_threads(p) to count the
number of threads using a VM. We can use
(atomic_read(&mm->mm_users) == 1 && get_nr_threads(p) == 1)
instead to skip the synchronize_sched() for cases where the VM only has
a single user, and that user only has a single thread.
It also turns out that we cannot use for_each_thread() to set
thread flags in all threads using a VM, as it only iterates on the
thread group.
Therefore, test the membarrier state variable directly rather than
relying on thread flags. This means
membarrier_register_private_expedited() needs to set the
MEMBARRIER_STATE_PRIVATE_EXPEDITED flag, issue synchronize_sched(), and
only then set MEMBARRIER_STATE_PRIVATE_EXPEDITED_READY which allows
private expedited membarrier commands to succeed.
membarrier_arch_switch_mm() now tests for the
MEMBARRIER_STATE_PRIVATE_EXPEDITED flag.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC: Peter Zijlstra <peterz@infradead.org>
CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
CC: Boqun Feng <boqun.feng@gmail.com>
CC: Andrew Hunter <ahh@google.com>
CC: Maged Michael <maged.michael@gmail.com>
CC: Avi Kivity <avi@scylladb.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: Michael Ellerman <mpe@ellerman.id.au>
CC: Dave Watson <davejwatson@fb.com>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: Will Deacon <will.deacon@arm.com>
CC: Andy Lutomirski <luto@kernel.org>
CC: Ingo Molnar <mingo@redhat.com>
CC: Alexander Viro <viro@zeniv.linux.org.uk>
CC: Nicholas Piggin <npiggin@gmail.com>
CC: linuxppc-dev@lists.ozlabs.org
CC: linux-arch@vger.kernel.org
---
Changes since v1:
- Use test_ti_thread_flag(next, ...) instead of test_thread_flag() in
powerpc membarrier_arch_sched_in(), given that we want to specifically
check the next thread state.
- Add missing ARCH_HAS_MEMBARRIER_HOOKS in Kconfig.
- Use task_thread_info() to pass thread_info from task to
*_ti_thread_flag().
Changes since v2:
- Move membarrier_arch_sched_in() call to finish_task_switch().
- Check for NULL t->mm in membarrier_arch_fork().
- Use membarrier_sched_in() in generic code, which invokes the
arch-specific membarrier_arch_sched_in(). This fixes allnoconfig
build on PowerPC.
- Move asm/membarrier.h include under CONFIG_MEMBARRIER, fixing
allnoconfig build on PowerPC.
- Build and runtime tested on PowerPC.
Changes since v3:
- Simply rely on copy_mm() to copy the membarrier_private_expedited mm
field on fork.
- powerpc: test thread flag instead of reading
membarrier_private_expedited in membarrier_arch_fork().
- powerpc: skip memory barrier in membarrier_arch_sched_in() if coming
from kernel thread, since mmdrop() implies a full barrier.
- Set membarrier_private_expedited to 1 only after arch registration
code, thus eliminating a race where concurrent commands could succeed
when they should fail if issued concurrently with process
registration.
- Use READ_ONCE() for membarrier_private_expedited field access in
membarrier_private_expedited. Matches WRITE_ONCE() performed in
process registration.
Changes since v4:
- Move powerpc hook from sched_in() to switch_mm(), based on feedback
from Nicholas Piggin.
Changes since v5:
- Rebase on v4.14-rc6.
- Fold "Fix: membarrier: Handle CLONE_VM + !CLONE_THREAD correctly on
powerpc (v2)"
Changes since v6:
- Rename MEMBARRIER_STATE_SWITCH_MM to MEMBARRIER_STATE_PRIVATE_EXPEDITED.
---
MAINTAINERS | 1 +
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/membarrier.h | 26 ++++++++++++++++++++++++++
arch/powerpc/mm/mmu_context.c | 7 +++++++
include/linux/sched/mm.h | 13 ++++++++++++-
init/Kconfig | 3 +++
kernel/sched/core.c | 10 ----------
kernel/sched/membarrier.c | 8 ++++++++
8 files changed, 58 insertions(+), 11 deletions(-)
create mode 100644 arch/powerpc/include/asm/membarrier.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 18994806e441..c2f0d9a48a10 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8931,6 +8931,7 @@ L: linux-kernel@vger.kernel.org
S: Supported
F: kernel/sched/membarrier.c
F: include/uapi/linux/membarrier.h
+F: arch/powerpc/include/asm/membarrier.h
MEMORY MANAGEMENT
L: linux-mm@kvack.org
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c51e6ce42e7a..a63adb082c0a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -140,6 +140,7 @@ config PPC
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_PMEM_API if PPC64
+ select ARCH_HAS_MEMBARRIER_HOOKS
select ARCH_HAS_SCALED_CPUTIME if VIRT_CPU_ACCOUNTING_NATIVE
select ARCH_HAS_SG_CHAIN
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
diff --git a/arch/powerpc/include/asm/membarrier.h b/arch/powerpc/include/asm/membarrier.h
new file mode 100644
index 000000000000..98ff4f1fcf2b
--- /dev/null
+++ b/arch/powerpc/include/asm/membarrier.h
@@ -0,0 +1,26 @@
+#ifndef _ASM_POWERPC_MEMBARRIER_H
+#define _ASM_POWERPC_MEMBARRIER_H
+
+static inline void membarrier_arch_switch_mm(struct mm_struct *prev,
+ struct mm_struct *next,
+ struct task_struct *tsk)
+{
+ /*
+ * Only need the full barrier when switching between processes.
+ * Barrier when switching from kernel to userspace is not
+ * required here, given that it is implied by mmdrop(). Barrier
+ * when switching from userspace to kernel is not needed after
+ * store to rq->curr.
+ */
+ if (likely(!(atomic_read(&next->membarrier_state) &
+ MEMBARRIER_STATE_PRIVATE_EXPEDITED) || !prev))
+ return;
+
+ /*
+ * The membarrier system call requires a full memory barrier
+ * after storing to rq->curr, before going back to user-space.
+ */
+ smp_mb();
+}
+
+#endif /* _ASM_POWERPC_MEMBARRIER_H */
diff --git a/arch/powerpc/mm/mmu_context.c b/arch/powerpc/mm/mmu_context.c
index d60a62bf4fc7..0ab297c4cfad 100644
--- a/arch/powerpc/mm/mmu_context.c
+++ b/arch/powerpc/mm/mmu_context.c
@@ -12,6 +12,7 @@
#include <linux/mm.h>
#include <linux/cpu.h>
+#include <linux/sched/mm.h>
#include <asm/mmu_context.h>
@@ -58,6 +59,10 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
*
* On the read side the barrier is in pte_xchg(), which orders
* the store to the PTE vs the load of mm_cpumask.
+ *
+ * This full barrier is needed by membarrier when switching
+ * between processes after store to rq->curr, before user-space
+ * memory accesses.
*/
smp_mb();
@@ -80,6 +85,8 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
if (new_on_cpu)
radix_kvm_prefetch_workaround(next);
+ else
+ membarrier_arch_switch_mm(prev, next, tsk);
/*
* The actual HW switching method differs between the various
diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
index 3d49b91b674d..1754396795f6 100644
--- a/include/linux/sched/mm.h
+++ b/include/linux/sched/mm.h
@@ -215,14 +215,25 @@ static inline void memalloc_noreclaim_restore(unsigned int flags)
#ifdef CONFIG_MEMBARRIER
enum {
MEMBARRIER_STATE_PRIVATE_EXPEDITED_READY = (1U << 0),
- MEMBARRIER_STATE_SWITCH_MM = (1U << 1),
+ MEMBARRIER_STATE_PRIVATE_EXPEDITED = (1U << 1),
};
+#ifdef CONFIG_ARCH_HAS_MEMBARRIER_HOOKS
+#include <asm/membarrier.h>
+#endif
+
static inline void membarrier_execve(struct task_struct *t)
{
atomic_set(&t->mm->membarrier_state, 0);
}
#else
+#ifdef CONFIG_ARCH_HAS_MEMBARRIER_HOOKS
+static inline void membarrier_arch_switch_mm(struct mm_struct *prev,
+ struct mm_struct *next,
+ struct task_struct *tsk)
+{
+}
+#endif
static inline void membarrier_execve(struct task_struct *t)
{
}
diff --git a/init/Kconfig b/init/Kconfig
index a9a2e2c86671..2d118b6adee2 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1412,6 +1412,9 @@ config USERFAULTFD
Enable the userfaultfd() system call that allows to intercept and
handle page faults in userland.
+config ARCH_HAS_MEMBARRIER_HOOKS
+ bool
+
config EMBEDDED
bool "Embedded system"
option allnoconfig_y
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 644fa2e3d993..524b705892db 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2653,16 +2653,6 @@ static struct rq *finish_task_switch(struct task_struct *prev)
prev_state = prev->state;
vtime_task_switch(prev);
perf_event_task_sched_in(prev, current);
- /*
- * The membarrier system call requires a full memory barrier
- * after storing to rq->curr, before going back to user-space.
- *
- * TODO: This smp_mb__after_unlock_lock can go away if PPC end
- * up adding a full barrier to switch_mm(), or we should figure
- * out if a smp_mb__after_unlock_lock is really the proper API
- * to use.
- */
- smp_mb__after_unlock_lock();
finish_lock_switch(rq, prev);
finish_arch_post_lock_switch();
diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
index 9bcbacba82a8..678577267a9a 100644
--- a/kernel/sched/membarrier.c
+++ b/kernel/sched/membarrier.c
@@ -118,6 +118,14 @@ static void membarrier_register_private_expedited(void)
if (atomic_read(&mm->membarrier_state)
& MEMBARRIER_STATE_PRIVATE_EXPEDITED_READY)
return;
+ atomic_or(MEMBARRIER_STATE_PRIVATE_EXPEDITED, &mm->membarrier_state);
+ if (!(atomic_read(&mm->mm_users) == 1 && get_nr_threads(p) == 1)) {
+ /*
+ * Ensure all future scheduler executions will observe the
+ * new thread flag state for this process.
+ */
+ synchronize_sched();
+ }
atomic_or(MEMBARRIER_STATE_PRIVATE_EXPEDITED_READY,
&mm->membarrier_state);
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] powerpc/kprobes: Fix call trace due to incorrect preempt count
From: Ananth N Mavinakayanahalli @ 2018-01-17 16:48 UTC (permalink / raw)
To: Naveen N. Rao; +Cc: Michael Ellerman, linuxppc-dev
In-Reply-To: <20180117122224.19860-1-naveen.n.rao@linux.vnet.ibm.com>
On Wed, Jan 17, 2018 at 05:52:24PM +0530, Naveen N. Rao wrote:
> Michael Ellerman reported the following call trace when running
> ftracetest:
>
> BUG: using __this_cpu_write() in preemptible [00000000] code: ftracetest/6178
> caller is opt_pre_handler+0xc4/0x110
> CPU: 1 PID: 6178 Comm: ftracetest Not tainted 4.15.0-rc7-gcc6x-gb2cd1df #1
> Call Trace:
> [c0000000f9ec39c0] [c000000000ac4304] dump_stack+0xb4/0x100 (unreliable)
> [c0000000f9ec3a00] [c00000000061159c] check_preemption_disabled+0x15c/0x170
> [c0000000f9ec3a90] [c000000000217e84] opt_pre_handler+0xc4/0x110
> [c0000000f9ec3af0] [c00000000004cf68] optimized_callback+0x148/0x170
> [c0000000f9ec3b40] [c00000000004d954] optinsn_slot+0xec/0x10000
> [c0000000f9ec3e30] [c00000000004bae0] kretprobe_trampoline+0x0/0x10
>
> This is showing up since OPTPROBES is now enabled with CONFIG_PREEMPT.
>
> trampoline_probe_handler() considers itself to be a special kprobe
> handler for kretprobes. In doing so, it expects to be called from
> kprobe_handler() on a trap, and re-enables preemption before returning a
> non-zero return value so as to suppress any subsequent processing of the
> trap by the kprobe_handler().
>
> However, with optprobes, we don't deal with special handlers (we ignore
> the return code) and just try to re-enable preemption causing the above
> trace.
>
> To address this, modify trampoline_probe_handler() to not be special.
> The only additional processing done in kprobe_handler() is to emulate
> the instruction (in this case, a 'nop'). We adjust the value of
> regs->nip for the purpose and delegate the job of re-enabling
> preemption and resetting current kprobe to the probe handlers
> (kprobe_handler() or optimized_callback()).
>
> Reported-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH -next] ipmi/powernv: Fix error return code in ipmi_powernv_probe()
From: Corey Minyard @ 2018-01-17 15:52 UTC (permalink / raw)
To: Wei Yongjun
Cc: openipmi-developer, linuxppc-dev, linux-kernel, Jeremy Kerr,
Michael, Ellerman, Alistair Popple
In-Reply-To: <1516188311-144227-1-git-send-email-weiyongjun1@huawei.com>
On 01/17/2018 05:25 AM, Wei Yongjun wrote:
> Fix to return a negative error code from the request_irq() error
> handling case instead of 0, as done elsewhere in this function.
I think you are right here. However, you had a bunch of people on the email
that probably didn't need to be there, and didn't have a few that should.
I've adjusted in this response.
This was introduced in change dce143c3381c355ef73be3dd97cf3ca1b15359b8,
you should add a "Fixes:" in the commit text.
I'll let the people that did this code comment, just to be sure, and
wait for
a v2 patch from you after that.
Thanks,
-corey
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/char/ipmi/ipmi_powernv.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_powernv.c b/drivers/char/ipmi/ipmi_powernv.c
> index c687c8d..bcf493d 100644
> --- a/drivers/char/ipmi/ipmi_powernv.c
> +++ b/drivers/char/ipmi/ipmi_powernv.c
> @@ -250,8 +250,9 @@ static int ipmi_powernv_probe(struct platform_device *pdev)
> ipmi->irq = opal_event_request(prop);
> }
>
> - if (request_irq(ipmi->irq, ipmi_opal_event, IRQ_TYPE_LEVEL_HIGH,
> - "opal-ipmi", ipmi)) {
> + rc = request_irq(ipmi->irq, ipmi_opal_event, IRQ_TYPE_LEVEL_HIGH,
> + "opal-ipmi", ipmi);
> + if (rc) {
> dev_warn(dev, "Unable to request irq\n");
> goto err_dispose;
> }
>
^ permalink raw reply
* Re: [PATCH v5 00/17] ASoC: fsl_ssi: Clean up - program flow level
From: Caleb Crome @ 2018-01-17 15:19 UTC (permalink / raw)
To: Nicolin Chen
Cc: Timur Tabi, Mark Brown, mail, linux-kernel, linuxppc-dev,
alsa-devel, Liam Girdwood, Fabio Estevam, Arnaud Mouiche, lukma,
Sascha Hauer
In-Reply-To: <1516171902-32669-1-git-send-email-nicoleotsuka@gmail.com>
On Tue, Jan 16, 2018 at 10:51 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> [ Maciej, could you please send your Tested-by/Reviewed-by for AC97
> once you confirm this series?
>
> And Caleb, this version does not need a test for non-AC97 cases.
>
> Thanks both! ]
>
> ==Change log==
> v5
> * Reworked the series by taking suggestions from Maciej for AC97
> + Fixed SSI lockup issue by changing cleanup sequence in PATCH-13
> + Moved fsl_ssi_hw_clean() after unregistering the CODEC device
> in PATCH-13
> + Set NULL as the parent of CODEC platform device to fix a NULL
> pointer dereference bug in PATCH-16
> * Updated comments of three variables/pointers in struct fsl_ssi
> to describe them more accurately in PATCH-16
> v4
> * Reworked the series by taking suggestions from Maciej
> + Added TXBIT0 bit back to play safe in PATCH-14
> + Made bool synchronous exclusive with AC97 mode in PATCH-16
> v3
> * Reworked the series by taking suggestions from Maciej
> + Added PATCH-01 to make RX and TX more clearly defined
> + Replaced "bool dir" with "int dir" in PATCH-04
> + Replaced "!dir" with "int adir" in PATCH-05
> + Put CBM_CFS behind the baudclk check to keep the same
> program flow in PATCH-14
> + Removed all cpu_dai_drv changes in PATCH-15
> v2
> * Reworked the series by taking suggestions from Maciej
> + Added PATCH-01 to keep all ssi->i2s_net updated
> + Replaced bool tx with bool dir in PATCH-03 and PATCH-06
> + Moved all initial register configurations from dai probe() to
> platform probe() so as to let AC97 CODEC successfully probe.
> * Added Tested-by from Caleb for TDM test cases.
>
> ==Background==
> The fsl_ssi driver was designed for PPC originally and then it has
> been updated to support different modes for i.MX Series, including
> SDMA, I2S Master mode, AC97 and older i.MXs with FIQ, by different
> contributors for different use cases in different coding styles.
>
> Additionally, in order to fix/work-around hardware bugs and design
> flaws, the driver made a lot of compromise so now its program flow
> looks very complicated and it's getting hard to maintain or update.
>
> So I am going to clean up the driver on both coding style level and
> program flow level.
>
> ==Introduction==
> This series of patches is the second set to clean up fsl_ssi driver
> in the program flow level. Any patch here may impact a fundamental
> test case like playback or record.
>
> ==Verification==
> This series of patches require fully tested. I have done such tests
> on i.MX6SoloX with WM8962 using imx_v6_v7_defconfig as:
> - Playback via I2S Master and Slave mode
> - Record via I2S Master and Slave mode
> - Simultaneous playback and record via I2S Master and Slave mode
> - Background playback with foreground record (starting at different
> time) via I2S Master and Slave mode
> - Background record with foreground playback (starting at different
> time) via I2S Master and Slave mode
> * All tests above by hacking offline_config to true in imx51.
>
> Caleb has tested v1-v4 with TDM lookback tests on i.MX6.
>
> Example of uncovered tests: AC97, PowerPC and FIQ.
>
> Nicolin Chen (17):
> ASoC: fsl_ssi: Redefine RX and TX macros
> ASoC: fsl_ssi: Keep ssi->i2s_net updated
> ASoC: fsl_ssi: Clean up set_dai_tdm_slot()
> ASoC: fsl_ssi: Maintain a mask of active streams
> ASoC: fsl_ssi: Rename fsl_ssi_disable_val macro
> ASoC: fsl_ssi: Clear FIFO directly in fsl_ssi_config()
> ASoC: fsl_ssi: Clean up helper functions of trigger()
> ASoC: fsl_ssi: Add DAIFMT define for AC97
> ASoC: fsl_ssi: Clean up fsl_ssi_setup_regvals()
> ASoC: fsl_ssi: Set xFEN0 and xFEN1 together
> ASoC: fsl_ssi: Use snd_soc_init_dma_data instead
> ASoC: fsl_ssi: Move one-time configurations to probe()
> ASoC: fsl_ssi: Setup AC97 in fsl_ssi_hw_init()
> ASoC: fsl_ssi: Clean up _fsl_ssi_set_dai_fmt()
> ASoC: fsl_ssi: Add bool synchronous to mark synchronous mode
> ASoC: fsl_ssi: Move DT related code to a separate probe()
> ASoC: fsl_ssi: Use ssi->streams instead of reading register
>
> sound/soc/fsl/fsl_ssi.c | 756 +++++++++++++++++++++++++-----------------------
> sound/soc/fsl/fsl_ssi.h | 3 -
> 2 files changed, 395 insertions(+), 364 deletions(-)
>
> --
> 2.7.4
>
tested v5.
No problems,
-Caleb
^ permalink raw reply
* Re: [PATCH v6 00/24] Speculative page faults
From: Laurent Dufour @ 2018-01-17 15:15 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: paulmck, peterz, akpm, ak, mhocko, dave, jack, Matthew Wilcox,
benh, mpe, paulus, Thomas Gleixner, Ingo Molnar, hpa, Will Deacon,
Sergey Senozhatsky, Andrea Arcangeli, Alexei Starovoitov,
kemi.wang, sergey.senozhatsky.work, linux-kernel, linux-mm, haren,
khandual, npiggin, bsingharora, Tim Chen, linuxppc-dev, x86
In-Reply-To: <20180116151145.74odvlj6mjuwq3rr@node.shutemov.name>
Hi Kirill,
Thanks for reviewing this series.
On 16/01/2018 16:11, Kirill A. Shutemov wrote:
> On Fri, Jan 12, 2018 at 06:25:44PM +0100, Laurent Dufour wrote:
>> ------------------
>> Benchmarks results
>>
>> Base kernel is 4.15-rc6-mmotm-2018-01-04-16-19
>> SPF is BASE + this series
>
> Do you have THP=always here? Lack of THP support worries me.
Yes my kernel is built with THP=always.
For the record, I wrote all the code to support THP, but when I was about
to plug it into the speculative page fault handler, I was wondering about
the pmd_none() check and this raises the issue with khugepaged and the way
it is invalidating the pmd before collapsing the underlying pages.
Currently, there is no easy way to detect when such a collapsing operation
is occurring.
> What is performance in the worst case scenario? Like when we go far enough into
> speculative code path on every page fault and then fallback to normal page
> fault?
I did further tests focusing on the THP with a patched ebizzy (to use
posix_memalign() and MADV_HUGEPAGE) to force the use of the transparent
huge pages. I double checked that use through /proc/#/smaps.
Here is the result I got on a 16 CPUs x86 VM (higher the best):
BASE SPF
mean 276.83 276.93 record/s
max 280 280 record/s
The run was done 100 times using a large enough size records (128 MB).
Here is also the event I recorded when running ebizzy during 60s:
275 records/s
Performance counter stats for './ebizzy -HT -s 134217728':
182,470 faults
5,085 spf
176,634 pagefault:spf_vma_notsup
10.518504612 seconds time elapsed
Most of the speculative page fault events were aborted because the VMA was
not supported, which is matching the huge pages (pagefault:spf_vma_notsup).
Only 5,000 were managed fully without holding the mmap_sem, I guess for
other part of the memory's process.
Running the same command on the Base kernel gave:
293 records/s
Performance counter stats for './ebizzy -HT -s 134217728':
183,170 faults
10.660787623 seconds time elapsed
So I'd say that aborting the speculative page fault handler when a THP is
detected, has no visible impact.
Cheers,
Laurent.
^ permalink raw reply
* Re: DPAA Ethernet traffice troubles with Linux kernel
From: Joakim Tjernlund @ 2018-01-17 15:00 UTC (permalink / raw)
To: madalin.bucur@nxp.com, andrew@lunn.ch
Cc: linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org,
madskateman@gmail.com
In-Reply-To: <DB3PR0402MB38492999533EB4400DED45BFECE90@DB3PR0402MB3849.eurprd04.prod.outlook.com>
T24gVGh1LCAxOTcwLTAxLTAxIGF0IDAwOjAwICswMDAwLCBNYWRhbGluLWNyaXN0aWFuIEJ1Y3Vy
IHdyb3RlOg0KPiBDQVVUSU9OOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9m
IHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRz
IHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMg
c2FmZS4NCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTog
Sm9ha2ltIFRqZXJubHVuZCBbbWFpbHRvOkpvYWtpbS5UamVybmx1bmRAaW5maW5lcmEuY29tXQ0K
PiA+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTYsIDIwMTggNzo1OCBQTQ0KPiA+IFRvOiBhbmRy
ZXdAbHVubi5jaA0KPiA+IFN1YmplY3Q6IFJlOiBEUEFBIEV0aGVybmV0IHRyYWZmaWNlIHRyb3Vi
bGVzIHdpdGggTGludXgga2VybmVsDQo+ID4gDQo+ID4gT24gVGh1LCAxOTcwLTAxLTAxIGF0IDAw
OjAwICswMDAwLCBBbmRyZXcgTHVubiB3cm90ZToNCj4gPiA+IA0KPiA+ID4gSGkgSm9ha2ltDQo+
ID4gPiANCj4gPiA+IFlvdSBhcHBlYXIgdG8gYmUgdXNpbmcgYW4gb2xkIGtlcm5lbC4gVGFrZSBh
IGxvb2sgYXQ6DQo+ID4gDQo+ID4gTm90IHJlYWxseSwgSSBhbSB1c2luZyA0LjE0LnggYW5kIEkg
ZG9uJ3QgdGhpbmsgdGhhdCBpcyBvbGQuIFNlZW1zIGxpa2UNCj4gPiB0aGlzDQo+ID4gcGF0Y2gg
aGFzbid0IGJlZW4gc2VudCB0byA0LjE0LnguDQo+ID4gDQo+ID4gSSB3b25kZXIgaWYgSSBtaWdo
dCBiZSBtaXNzaW5nIHNvbWV0aGluZyBlbHNlLCB3ZSBqdXN0IG1vdmVkIHRvIDQuMTQgYW5kDQo+
ID4gbm90aWMgdGhhdCBhbGwNCj4gPiBvdXIgZml4ZWQgUEhZcyBhcmUgbm9uIGZ1bmN0aW9uaW5n
Og0KPiA+IGZzbF9tYWMgZmZlNGUyMDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQo+ID4gZnNsX21h
YyBmZmU0ZTIwMDAuZXRoZXJuZXQ6IEZNYW4gTUFDIGFkZHJlc3M6IDAwOjA2OjljOjBiOjA2OjIw
DQo+ID4gZnNsX21hYyBkcGFhLWV0aGVybmV0LjA6IF9fZGV2bV9yZXF1ZXN0X21lbV9yZWdpb24o
bWFjKSBmYWlsZWQNCj4gPiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVybmV0LjAgZmFpbGVk
IHdpdGggZXJyb3IgLTE2DQo+ID4gZnNsX21hYyBmZmU0ZTQwMDAuZXRoZXJuZXQ6IEZNYW4gTUVN
QUMNCj4gPiBmc2xfbWFjIGZmZTRlNDAwMC5ldGhlcm5ldDogRk1hbiBNQUMgYWRkcmVzczogMDA6
MDY6OWM6MGI6MDY6MjENCj4gPiBmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMTogX19kZXZtX3JlcXVl
c3RfbWVtX3JlZ2lvbihtYWMpIGZhaWxlZA0KPiA+IGZzbF9tYWM6IHByb2JlIG9mIGRwYWEtZXRo
ZXJuZXQuMSBmYWlsZWQgd2l0aCBlcnJvciAtMTYNCj4gPiBmc2xfbWFjIGZmZTRlNjAwMC5ldGhl
cm5ldDogRk1hbiBNRU1BQw0KPiA+IGZzbF9tYWMgZmZlNGU2MDAwLmV0aGVybmV0OiBGTWFuIE1B
QyBhZGRyZXNzOiAwMDowNjo5YzowYjowNjoyMg0KPiA+IGZzbF9tYWMgZHBhYS1ldGhlcm5ldC4y
OiBfX2Rldm1fcmVxdWVzdF9tZW1fcmVnaW9uKG1hYykgZmFpbGVkDQo+ID4gZnNsX21hYzogcHJv
YmUgb2YgZHBhYS1ldGhlcm5ldC4yIGZhaWxlZCB3aXRoIGVycm9yIC0xNg0KPiA+IGZzbF9tYWMg
ZmZlNGU4MDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQo+ID4gZnNsX21hYyBmZmU0ZTgwMDAuZXRo
ZXJuZXQ6IEZNYW4gTUFDIGFkZHJlc3M6IDAwOjA2OjljOjBiOjA2OjIzDQo+ID4gZnNsX21hYyBk
cGFhLWV0aGVybmV0LjM6IF9fZGV2bV9yZXF1ZXN0X21lbV9yZWdpb24obWFjKSBmYWlsZWQNCj4g
PiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVybmV0LjMgZmFpbGVkIHdpdGggZXJyb3IgLTE2
DQo+ID4gDQo+ID4gRmVlbHMgbGlrZSBGTUFOIHN0aWxsIHRoaW5rIHRoZXJlIGFyZSByZWFsIFBI
WXMgdGhlcmUgPw0KPiANCj4gSGkgSm9ha2ltLA0KPiANCj4gVGhlc2UgZXJyb3JzIGFyZSBpc3N1
ZWQgd2hlbiB0cnlpbmcgdG8gcHJvYmUgdGhlIHNlY29uZCB0aW1lIHRoZSBzYW1lDQo+IE1BQyBu
b2RlLiBUaGUgaXNzdWUgd2FzIGludHJvZHVjZWQgYnkgdGhpcyBjb21taXQ6DQo+IA0KPiBjb21t
aXQgNGQ4ZWUxOTM1YmNkNjY2MzYwMzExZGZkYWRlZWUyMzVkNjgyZDY5YQ0KPiBBdXRob3I6IEZs
b3JpYW4gRmFpbmVsbGkgPGYuZmFpbmVsbGlAZ21haWwuY29tPg0KPiBEYXRlOiBUdWUgQXVnIDIy
IDE1OjI0OjQ3IDIwMTcgLTA3MDANCj4gZnNsL21hbjogSW5oZXJpdCBwYXJlbnQgZGV2aWNlIGFu
ZCBvZl9ub2RlDQo+IA0KPiBhbmQgd2FzIGxhdGVyIGFkZHJlc3NlZCBieSB0aGlzIHBhdGNoIHNl
dDoNCj4gDQo+IGh0dHA6Ly9wYXRjaHdvcmsub3psYWJzLm9yZy9wcm9qZWN0L25ldGRldi9saXN0
Lz9zZXJpZXM9ODQ2MiZzdGF0ZT0qDQo+IA0KPiBFdmVuIHdpdGggdGhlc2UgZXJyb3JzIHByaW50
ZWQsIGFsbCBpcyB3b3JraW5nIGZpbmUsIGl0J3MganVzdCB0aGUNCj4gc2Vjb25kIHByb2Jpbmcg
dGhhdCBmYWlscy4gQWRkaW5nIHRoZSBsYXR0ZXIgcGF0Y2hlcyBvciByZXZlcnRpbmcNCj4gdGhl
IG9uZSBhYm92ZSBtYWtlcyB0aGUgZXJyb3JzIHByaW50cyBkaXNzYXBlYXIuDQo+IA0KPiBNYWRh
bGluDQoNCkFoaCwgbm93IGl0IHN0YXJ0cyB0byBsb29rIGJldHRlciwgcmV2ZXJ0aW5nICJmc2wv
bWFuOiBJbmhlcml0IHBhcmVudCBkZXZpY2UgYW5kIG9mX25vZGUiIG9uIDQuMTQgZ2l2ZXM6DQps
aWJwaHk6IEZpeGVkIE1ESU8gQnVzOiBwcm9iZWQNCnR1bjogVW5pdmVyc2FsIFRVTi9UQVAgZGV2
aWNlIGRyaXZlciwgMS42DQpsaWJwaHk6IEZyZWVzY2FsZSBYR01BQyBNRElPIEJ1czogcHJvYmVk
DQppb21tdTogQWRkaW5nIGRldmljZSBmZmU0ODgwMDAucG9ydCB0byBncm91cCAxMA0KbGlicGh5
OiBGcmVlc2NhbGUgWEdNQUMgTURJTyBCdXM6IHByb2JlZA0KbWRpb19idXMgZmZlNGUxMDAwOiBF
cnJvciB3aGlsZSByZWFkaW5nIFBIWTAgcmVnIGF0IDMuMw0KaW9tbXU6IEFkZGluZyBkZXZpY2Ug
ZmZlNDg5MDAwLnBvcnQgdG8gZ3JvdXAgMjINCmxpYnBoeTogRnJlZXNjYWxlIFhHTUFDIE1ESU8g
QnVzOiBwcm9iZWQNCm1kaW9fYnVzIGZmZTRlMzAwMDogRXJyb3Igd2hpbGUgcmVhZGluZyBQSFkw
IHJlZyBhdCAzLjMNCmlvbW11OiBBZGRpbmcgZGV2aWNlIGZmZTQ4YTAwMC5wb3J0IHRvIGdyb3Vw
IDIzDQpsaWJwaHk6IEZyZWVzY2FsZSBYR01BQyBNRElPIEJ1czogcHJvYmVkDQptZGlvX2J1cyBm
ZmU0ZTUwMDA6IEVycm9yIHdoaWxlIHJlYWRpbmcgUEhZMCByZWcgYXQgMy4zDQppb21tdTogQWRk
aW5nIGRldmljZSBmZmU0OGIwMDAucG9ydCB0byBncm91cCAyNA0KbGlicGh5OiBGcmVlc2NhbGUg
WEdNQUMgTURJTyBCdXM6IHByb2JlZA0KbWRpb19idXMgZmZlNGU3MDAwOiBFcnJvciB3aGlsZSBy
ZWFkaW5nIFBIWTAgcmVnIGF0IDMuMw0KaW9tbXU6IEFkZGluZyBkZXZpY2UgZmZlNDhjMDAwLnBv
cnQgdG8gZ3JvdXAgMjUNCmxpYnBoeTogRnJlZXNjYWxlIFhHTUFDIE1ESU8gQnVzOiBwcm9iZWQN
Cm1kaW9fYnVzIGZmZTRlOTAwMDogRXJyb3Igd2hpbGUgcmVhZGluZyBQSFkwIHJlZyBhdCAzLjMN
CmZzbF9tYWMgZmZlNGUyMDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQpmc2xfbWFjIGZmZTRlMjAw
MC5ldGhlcm5ldDogRk1hbiBNQUMgYWRkcmVzczogMDA6MDY6OWM6MGI6MDY6MjANCmZzbF9tYWMg
ZmZlNGU0MDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQpmc2xfbWFjIGZmZTRlNDAwMC5ldGhlcm5l
dDogRk1hbiBNQUMgYWRkcmVzczogMDA6MDY6OWM6MGI6MDY6MjENCmZzbF9tYWMgZmZlNGU2MDAw
LmV0aGVybmV0OiBGTWFuIE1FTUFDDQpmc2xfbWFjIGZmZTRlNjAwMC5ldGhlcm5ldDogRk1hbiBN
QUMgYWRkcmVzczogMDA6MDY6OWM6MGI6MDY6MjINCmZzbF9tYWMgZmZlNGU4MDAwLmV0aGVybmV0
OiBGTWFuIE1FTUFDDQpmc2xfbWFjIGZmZTRlODAwMC5ldGhlcm5ldDogRk1hbiBNQUMgYWRkcmVz
czogMDA6MDY6OWM6MGI6MDY6MjMNCmZzbF9tYWMgZmZlNGUwMDAwLmV0aGVybmV0OiBGTWFuIE1F
TUFDDQpmc2xfbWFjIGZmZTRlMDAwMC5ldGhlcm5ldDogRk1hbiBNQUMgYWRkcmVzczogMDA6MDY6
OWM6MGI6MDY6MWYNCmZzbF9kcGEgZHBhYS1ldGhlcm5ldC4wIGV0aDA6IFByb2JlZCBpbnRlcmZh
Y2UgZXRoMA0KZnNsX2RwYSBkcGFhLWV0aGVybmV0LjEgZXRoMTogUHJvYmVkIGludGVyZmFjZSBl
dGgxDQpmc2xfZHBhIGRwYWEtZXRoZXJuZXQuMiBldGgyOiBQcm9iZWQgaW50ZXJmYWNlIGV0aDIN
CmZzbF9kcGEgZHBhYS1ldGhlcm5ldC4zIGV0aDM6IFByb2JlZCBpbnRlcmZhY2UgZXRoMw0KZnNs
X2RwYSBkcGFhLWV0aGVybmV0LjQgZXRoNDogUHJvYmVkIGludGVyZmFjZSBldGg0DQoNClN0aWxs
IHNvbWUgbWlub3IgZXJyb3JzOiBtZGlvX2J1cyBmZmU0ZTcwMDA6IEVycm9yIHdoaWxlIHJlYWRp
bmcgUEhZMCByZWcgYXQgMy4zDQpidXQgdGhpcyBpcyBnb2luZyB0aGUgcmlnaHQgd2F5KEkgaGF2
ZSBub3QgaGFkIGEgY2hhbmNlIHRvIHRyeSBpZiB0aGV5IHdvcmsgZHVlDQp0byBleHRlcm5hbCBt
b2R1bGVzIG5vdCBwb3J0ZWQvcmVhZHkgeWV0KQ0KDQpUaGUgb3RoZXIgcGF0Y2ggc2VyaWVzIGlz
IHN0aWxsIHRvIGJlIHRlc3RlZCB0aG91Z2ggYnV0IEkgYWxyZWFkeSBub3cgd2FudGVkIA0KdG8g
c3RyZXNzIHRoZSBpbXBvcnRhbmNlIG9mIGdldHRpbmcgYWxsIHVwc3RyZWFtIGZpeGVzIGludG8g
c3RhYmxlLCBBU0FQLg0KWW91IG5vdyB3aGF0IHRoZXkgYXJlLCBJIGhhdmUgbm8gaWRlYS4NCg0K
VGhhbmtzIA0KICAgICAgIEpvY2tl
^ permalink raw reply
* RE: DPAA Ethernet traffice troubles with Linux kernel
From: Madalin-cristian Bucur @ 2018-01-17 14:43 UTC (permalink / raw)
To: David S . Miller
Cc: linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org,
madskateman@gmail.com, Madalin-cristian Bucur, Andrew Lunn,
Joakim Tjernlund
In-Reply-To: <DB3PR0402MB3849865056493075A4F4317CECE90@DB3PR0402MB3849.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Madalin-cristian Bucur
> Sent: Wednesday, January 17, 2018 4:25 PM
> To: David S . Miller <davem@davemloft.net>
> Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> madskateman@gmail.com; 'Madalin-cristian Bucur' <madalin.bucur@nxp.com>;
> Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> <Joakim.Tjernlund@infinera.com>
> Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
>=20
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org=
]
> > On Behalf Of Madalin-cristian Bucur
> > Sent: Wednesday, January 17, 2018 4:16 PM
> > To: Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> > <Joakim.Tjernlund@infinera.com>
> > Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> > madskateman@gmail.com; David S . Miller <davem@davemloft.net>
> > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> >
> > > -----Original Message-----
> > > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > > Sent: Wednesday, January 17, 2018 3:44 PM
> > > To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > >
> > > > That doesn't work really, having users to hit the bug, debug it, fi=
x
> > it
> > > and then
> > > > find it fixed already in upstream, then specifically request it to
> be
> > > backported to stable.
> > > > I don't need this fix to be backported, already got it. Someone els=
e
> > > might though.
> > >
> > > The "someone else might though" is a big point of asking for it to
> > > added to stable. The other reason is it means one less patch you need
> > > to maintain in your build.
> >
> > I've sent that patch [1] for net but I guess the timing was wrong and
> > it was merged to net-next.
> >
> > > > I would be interested in bug fixes upstream which fixes:
> > >
> > > Did you try upstream? Does it give the same errors?
> > >
> > > Andrew
> >
> > [1] https://patchwork.kernel.org/patch/10146119/
> >
> > Madalin
>=20
> Hi Dave,
>=20
> Can you please add the fix [1] to stable?
>=20
> Thank you,
> Madalin
Sorry,
I've provided the wrong link towards the patch (v1 instead of v3),
here's the correct one:
https://patchwork.kernel.org/patch/10151969/
Madalin
^ permalink raw reply
* RE: DPAA Ethernet traffice troubles with Linux kernel
From: Madalin-cristian Bucur @ 2018-01-17 14:24 UTC (permalink / raw)
To: David S . Miller
Cc: linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org,
madskateman@gmail.com, Madalin-cristian Bucur, Andrew Lunn,
Joakim Tjernlund
In-Reply-To: <DB3PR0402MB3849850266808EC52F88A783ECE90@DB3PR0402MB3849.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Madalin-cristian Bucur
> Sent: Wednesday, January 17, 2018 4:16 PM
> To: Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> <Joakim.Tjernlund@infinera.com>
> Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> madskateman@gmail.com; David S . Miller <davem@davemloft.net>
> Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
>=20
> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > Sent: Wednesday, January 17, 2018 3:44 PM
> > To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> >
> > > That doesn't work really, having users to hit the bug, debug it, fix
> it
> > and then
> > > find it fixed already in upstream, then specifically request it to be
> > backported to stable.
> > > I don't need this fix to be backported, already got it. Someone else
> > might though.
> >
> > The "someone else might though" is a big point of asking for it to
> > added to stable. The other reason is it means one less patch you need
> > to maintain in your build.
>=20
> I've sent that patch [1] for net but I guess the timing was wrong and
> it was merged to net-next.
>=20
> > > I would be interested in bug fixes upstream which fixes:
> >
> > Did you try upstream? Does it give the same errors?
> >
> > Andrew
>=20
> [1] https://patchwork.kernel.org/patch/10146119/
>=20
> Madalin
Hi Dave,
Can you please add the fix [1] to stable?
Thank you,
Madalin
^ permalink raw reply
* RE: DPAA Ethernet traffice troubles with Linux kernel
From: Madalin-cristian Bucur @ 2018-01-17 14:15 UTC (permalink / raw)
To: Andrew Lunn, Joakim Tjernlund
Cc: linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org,
madskateman@gmail.com, David S . Miller
In-Reply-To: <20180117134339.GC32299@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Wednesday, January 17, 2018 3:44 PM
> To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
>=20
> > That doesn't work really, having users to hit the bug, debug it, fix it
> and then
> > find it fixed already in upstream, then specifically request it to be
> backported to stable.
> > I don't need this fix to be backported, already got it. Someone else
> might though.
>=20
> The "someone else might though" is a big point of asking for it to
> added to stable. The other reason is it means one less patch you need
> to maintain in your build.
I've sent that patch [1] for net but I guess the timing was wrong and
it was merged to net-next.
> > I would be interested in bug fixes upstream which fixes:
>=20
> Did you try upstream? Does it give the same errors?
>=20
> Andrew
[1] https://patchwork.kernel.org/patch/10146119/
Madalin
^ permalink raw reply
* RE: DPAA Ethernet traffice troubles with Linux kernel
From: Madalin-cristian Bucur @ 2018-01-17 14:11 UTC (permalink / raw)
To: Joakim Tjernlund, andrew@lunn.ch
Cc: linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org,
madskateman@gmail.com
In-Reply-To: <1516125454.18795.87.camel@infinera.com>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2FraW0gVGplcm5sdW5kIFtt
YWlsdG86Sm9ha2ltLlRqZXJubHVuZEBpbmZpbmVyYS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEph
bnVhcnkgMTYsIDIwMTggNzo1OCBQTQ0KPiBUbzogYW5kcmV3QGx1bm4uY2gNCj4gU3ViamVjdDog
UmU6IERQQUEgRXRoZXJuZXQgdHJhZmZpY2UgdHJvdWJsZXMgd2l0aCBMaW51eCBrZXJuZWwNCj4g
DQo+IE9uIFRodSwgMTk3MC0wMS0wMSBhdCAwMDowMCArMDAwMCwgQW5kcmV3IEx1bm4gd3JvdGU6
DQo+ID4NCj4gPiBIaSBKb2FraW0NCj4gPg0KPiA+IFlvdSBhcHBlYXIgdG8gYmUgdXNpbmcgYW4g
b2xkIGtlcm5lbC4gVGFrZSBhIGxvb2sgYXQ6DQo+IA0KPiBOb3QgcmVhbGx5LCBJIGFtIHVzaW5n
IDQuMTQueCBhbmQgSSBkb24ndCB0aGluayB0aGF0IGlzIG9sZC4gU2VlbXMgbGlrZQ0KPiB0aGlz
DQo+IHBhdGNoIGhhc24ndCBiZWVuIHNlbnQgdG8gNC4xNC54Lg0KPiANCj4gSSB3b25kZXIgaWYg
SSBtaWdodCBiZSBtaXNzaW5nIHNvbWV0aGluZyBlbHNlLCB3ZSBqdXN0IG1vdmVkIHRvIDQuMTQg
YW5kDQo+IG5vdGljIHRoYXQgYWxsDQo+IG91ciBmaXhlZCBQSFlzIGFyZSBub24gZnVuY3Rpb25p
bmc6DQo+IGZzbF9tYWMgZmZlNGUyMDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQo+IGZzbF9tYWMg
ZmZlNGUyMDAwLmV0aGVybmV0OiBGTWFuIE1BQyBhZGRyZXNzOiAwMDowNjo5YzowYjowNjoyMA0K
PiBmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMDogX19kZXZtX3JlcXVlc3RfbWVtX3JlZ2lvbihtYWMp
IGZhaWxlZA0KPiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVybmV0LjAgZmFpbGVkIHdpdGgg
ZXJyb3IgLTE2DQo+IGZzbF9tYWMgZmZlNGU0MDAwLmV0aGVybmV0OiBGTWFuIE1FTUFDDQo+IGZz
bF9tYWMgZmZlNGU0MDAwLmV0aGVybmV0OiBGTWFuIE1BQyBhZGRyZXNzOiAwMDowNjo5YzowYjow
NjoyMQ0KPiBmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMTogX19kZXZtX3JlcXVlc3RfbWVtX3JlZ2lv
bihtYWMpIGZhaWxlZA0KPiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVybmV0LjEgZmFpbGVk
IHdpdGggZXJyb3IgLTE2DQo+IGZzbF9tYWMgZmZlNGU2MDAwLmV0aGVybmV0OiBGTWFuIE1FTUFD
DQo+IGZzbF9tYWMgZmZlNGU2MDAwLmV0aGVybmV0OiBGTWFuIE1BQyBhZGRyZXNzOiAwMDowNjo5
YzowYjowNjoyMg0KPiBmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMjogX19kZXZtX3JlcXVlc3RfbWVt
X3JlZ2lvbihtYWMpIGZhaWxlZA0KPiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVybmV0LjIg
ZmFpbGVkIHdpdGggZXJyb3IgLTE2DQo+IGZzbF9tYWMgZmZlNGU4MDAwLmV0aGVybmV0OiBGTWFu
IE1FTUFDDQo+IGZzbF9tYWMgZmZlNGU4MDAwLmV0aGVybmV0OiBGTWFuIE1BQyBhZGRyZXNzOiAw
MDowNjo5YzowYjowNjoyMw0KPiBmc2xfbWFjIGRwYWEtZXRoZXJuZXQuMzogX19kZXZtX3JlcXVl
c3RfbWVtX3JlZ2lvbihtYWMpIGZhaWxlZA0KPiBmc2xfbWFjOiBwcm9iZSBvZiBkcGFhLWV0aGVy
bmV0LjMgZmFpbGVkIHdpdGggZXJyb3IgLTE2DQo+IA0KPiBGZWVscyBsaWtlIEZNQU4gc3RpbGwg
dGhpbmsgdGhlcmUgYXJlIHJlYWwgUEhZcyB0aGVyZSA/DQoNCkhpIEpvYWtpbSwNCg0KVGhlc2Ug
ZXJyb3JzIGFyZSBpc3N1ZWQgd2hlbiB0cnlpbmcgdG8gcHJvYmUgdGhlIHNlY29uZCB0aW1lIHRo
ZSBzYW1lDQpNQUMgbm9kZS4gVGhlIGlzc3VlIHdhcyBpbnRyb2R1Y2VkIGJ5IHRoaXMgY29tbWl0
Og0KDQpjb21taXQgNGQ4ZWUxOTM1YmNkNjY2MzYwMzExZGZkYWRlZWUyMzVkNjgyZDY5YQ0KQXV0
aG9yOiBGbG9yaWFuIEZhaW5lbGxpIDxmLmZhaW5lbGxpQGdtYWlsLmNvbT4NCkRhdGU6IFR1ZSBB
dWcgMjIgMTU6MjQ6NDcgMjAxNyAtMDcwMA0KZnNsL21hbjogSW5oZXJpdCBwYXJlbnQgZGV2aWNl
IGFuZCBvZl9ub2RlDQoNCmFuZCB3YXMgbGF0ZXIgYWRkcmVzc2VkIGJ5IHRoaXMgcGF0Y2ggc2V0
Og0KDQpodHRwOi8vcGF0Y2h3b3JrLm96bGFicy5vcmcvcHJvamVjdC9uZXRkZXYvbGlzdC8/c2Vy
aWVzPTg0NjImc3RhdGU9Kg0KDQpFdmVuIHdpdGggdGhlc2UgZXJyb3JzIHByaW50ZWQsIGFsbCBp
cyB3b3JraW5nIGZpbmUsIGl0J3MganVzdCB0aGUNCnNlY29uZCBwcm9iaW5nIHRoYXQgZmFpbHMu
IEFkZGluZyB0aGUgbGF0dGVyIHBhdGNoZXMgb3IgcmV2ZXJ0aW5nDQp0aGUgb25lIGFib3ZlIG1h
a2VzIHRoZSBlcnJvcnMgcHJpbnRzIGRpc3NhcGVhci4NCg0KTWFkYWxpbg0K
^ permalink raw reply
* [PATCH] powerpc/64s: Improve RFI L1-D cache flush fallback
From: Nicholas Piggin @ 2018-01-17 13:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
The fallback RFI flush is used when firmware does not provide a way
to flush the cache. It's a "displacement flush" that evicts useful
data by displacing it with an uninteresting buffer.
The flush has to take care to work with implementation specific cache
replacment policies, so the recipe has been in flux. The initial
slow but conservative approach is to touch all lines of a congruence
class, with dependencies between each load. It has since been
determined that a linear pattern of loads without dependencies is
sufficient, and is significantly faster.
Measuring the speed of a null syscall with RFI fallback flush enabled
gives the relative improvement:
P8 - 1.83x
P9 - 1.75x
The flush also becomes simpler and more adaptable to different cache
geometries.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/paca.h | 3 +-
arch/powerpc/kernel/asm-offsets.c | 3 +-
arch/powerpc/kernel/exceptions-64s.S | 76 +++++++++++++++++-------------------
arch/powerpc/kernel/setup_64.c | 13 +-----
4 files changed, 39 insertions(+), 56 deletions(-)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 23ac7fc0af23..0ec7b1e383ef 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -239,8 +239,7 @@ struct paca_struct {
*/
u64 exrfi[EX_SIZE] __aligned(0x80);
void *rfi_flush_fallback_area;
- u64 l1d_flush_congruence;
- u64 l1d_flush_sets;
+ u64 l1d_flush_size;
#endif
};
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index f390d57cf2e1..fd99a9c6ea63 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -239,8 +239,7 @@ int main(void)
OFFSET(PACA_IN_NMI, paca_struct, in_nmi);
OFFSET(PACA_RFI_FLUSH_FALLBACK_AREA, paca_struct, rfi_flush_fallback_area);
OFFSET(PACA_EXRFI, paca_struct, exrfi);
- OFFSET(PACA_L1D_FLUSH_CONGRUENCE, paca_struct, l1d_flush_congruence);
- OFFSET(PACA_L1D_FLUSH_SETS, paca_struct, l1d_flush_sets);
+ OFFSET(PACA_L1D_FLUSH_SIZE, paca_struct, l1d_flush_size);
#endif
OFFSET(PACAHWCPUID, paca_struct, hw_cpu_id);
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 2dc10bf646b8..939445b16d58 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1455,39 +1455,37 @@ TRAMP_REAL_BEGIN(rfi_flush_fallback)
std r9,PACA_EXRFI+EX_R9(r13)
std r10,PACA_EXRFI+EX_R10(r13)
std r11,PACA_EXRFI+EX_R11(r13)
- std r12,PACA_EXRFI+EX_R12(r13)
- std r8,PACA_EXRFI+EX_R13(r13)
mfctr r9
ld r10,PACA_RFI_FLUSH_FALLBACK_AREA(r13)
- ld r11,PACA_L1D_FLUSH_SETS(r13)
- ld r12,PACA_L1D_FLUSH_CONGRUENCE(r13)
- /*
- * The load adresses are at staggered offsets within cachelines,
- * which suits some pipelines better (on others it should not
- * hurt).
- */
- addi r12,r12,8
+ ld r11,PACA_L1D_FLUSH_SIZE(r13)
+ srdi r11,r11,(7 + 3) /* 128 byte lines, unrolled 8x */
mtctr r11
DCBT_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */
/* order ld/st prior to dcbt stop all streams with flushing */
sync
-1: li r8,0
- .rept 8 /* 8-way set associative */
- ldx r11,r10,r8
- add r8,r8,r12
- xor r11,r11,r11 // Ensure r11 is 0 even if fallback area is not
- add r8,r8,r11 // Add 0, this creates a dependency on the ldx
- .endr
- addi r10,r10,128 /* 128 byte cache line */
+
+ /*
+ * The load adresses are at staggered offsets within cachelines,
+ * which suits some pipelines better (on others it should not
+ * hurt).
+ */
+1:
+ ld r11,(0x80 + 8)*0(r10)
+ ld r11,(0x80 + 8)*1(r10)
+ ld r11,(0x80 + 8)*2(r10)
+ ld r11,(0x80 + 8)*3(r10)
+ ld r11,(0x80 + 8)*4(r10)
+ ld r11,(0x80 + 8)*5(r10)
+ ld r11,(0x80 + 8)*6(r10)
+ ld r11,(0x80 + 8)*7(r10)
+ addi r10,r10,0x80*8
bdnz 1b
mtctr r9
ld r9,PACA_EXRFI+EX_R9(r13)
ld r10,PACA_EXRFI+EX_R10(r13)
ld r11,PACA_EXRFI+EX_R11(r13)
- ld r12,PACA_EXRFI+EX_R12(r13)
- ld r8,PACA_EXRFI+EX_R13(r13)
GET_SCRATCH0(r13);
rfid
@@ -1497,39 +1495,37 @@ TRAMP_REAL_BEGIN(hrfi_flush_fallback)
std r9,PACA_EXRFI+EX_R9(r13)
std r10,PACA_EXRFI+EX_R10(r13)
std r11,PACA_EXRFI+EX_R11(r13)
- std r12,PACA_EXRFI+EX_R12(r13)
- std r8,PACA_EXRFI+EX_R13(r13)
mfctr r9
ld r10,PACA_RFI_FLUSH_FALLBACK_AREA(r13)
- ld r11,PACA_L1D_FLUSH_SETS(r13)
- ld r12,PACA_L1D_FLUSH_CONGRUENCE(r13)
- /*
- * The load adresses are at staggered offsets within cachelines,
- * which suits some pipelines better (on others it should not
- * hurt).
- */
- addi r12,r12,8
+ ld r11,PACA_L1D_FLUSH_SIZE(r13)
+ srdi r11,r11,(7 + 3) /* 128 byte lines, unrolled 8x */
mtctr r11
DCBT_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */
/* order ld/st prior to dcbt stop all streams with flushing */
sync
-1: li r8,0
- .rept 8 /* 8-way set associative */
- ldx r11,r10,r8
- add r8,r8,r12
- xor r11,r11,r11 // Ensure r11 is 0 even if fallback area is not
- add r8,r8,r11 // Add 0, this creates a dependency on the ldx
- .endr
- addi r10,r10,128 /* 128 byte cache line */
+
+ /*
+ * The load adresses are at staggered offsets within cachelines,
+ * which suits some pipelines better (on others it should not
+ * hurt).
+ */
+1:
+ ld r11,(0x80 + 8)*0(r10)
+ ld r11,(0x80 + 8)*1(r10)
+ ld r11,(0x80 + 8)*2(r10)
+ ld r11,(0x80 + 8)*3(r10)
+ ld r11,(0x80 + 8)*4(r10)
+ ld r11,(0x80 + 8)*5(r10)
+ ld r11,(0x80 + 8)*6(r10)
+ ld r11,(0x80 + 8)*7(r10)
+ addi r10,r10,0x80*8
bdnz 1b
mtctr r9
ld r9,PACA_EXRFI+EX_R9(r13)
ld r10,PACA_EXRFI+EX_R10(r13)
ld r11,PACA_EXRFI+EX_R11(r13)
- ld r12,PACA_EXRFI+EX_R12(r13)
- ld r8,PACA_EXRFI+EX_R13(r13)
GET_SCRATCH0(r13);
hrfid
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 491be4179ddd..cc7ab8bf462c 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -867,19 +867,8 @@ static void init_fallback_flush(void)
memset(l1d_flush_fallback_area, 0, l1d_size * 2);
for_each_possible_cpu(cpu) {
- /*
- * The fallback flush is currently coded for 8-way
- * associativity. Different associativity is possible, but it
- * will be treated as 8-way and may not evict the lines as
- * effectively.
- *
- * 128 byte lines are mandatory.
- */
- u64 c = l1d_size / 8;
-
paca[cpu].rfi_flush_fallback_area = l1d_flush_fallback_area;
- paca[cpu].l1d_flush_congruence = c;
- paca[cpu].l1d_flush_sets = c / 128;
+ paca[cpu].l1d_flush_size = l1d_size;
}
}
--
2.15.1
^ permalink raw reply related
* Re: DPAA Ethernet traffice troubles with Linux kernel
From: Andrew Lunn @ 2018-01-17 13:43 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org,
madalin.bucur@nxp.com, madskateman@gmail.com
In-Reply-To: <1516189651.18795.99.camel@infinera.com>
> That doesn't work really, having users to hit the bug, debug it, fix it and then
> find it fixed already in upstream, then specifically request it to be backported to stable.
> I don't need this fix to be backported, already got it. Someone else might though.
The "someone else might though" is a big point of asking for it to
added to stable. The other reason is it means one less patch you need
to maintain in your build.
> I would be interested in bug fixes upstream which fixes:
Did you try upstream? Does it give the same errors?
Andrew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox