Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks

On Fri, Jul 17, 2020 at 01:16:42PM +0200, Arnaud Ferraris wrote: > Hi Nic, > > Le 02/07/2020 à 20:42, Nicolin Chen a écrit : > > Hi Arnaud, > > > > On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote: > >> The current ASRC driver hardcodes the input and output clocks used for > >>

Re: [v3 12/15] powerpc/perf: Add support for outputting extended regs in perf intr_regs

On 7/21/20 11:32 AM, kajoljain wrote: > > > On 7/17/20 8:08 PM, Athira Rajeev wrote: >> From: Anju T Sudhakar >> >> Add support for perf extended register capability in powerpc. >> The capability flag PERF_PMU_CAP_EXTENDED_REGS, is used to indicate the >> PMU which support extended

RE: [PATCH devicetree 3/4] powerpc: dts: t1040rdb: put SGMII PHY under label

> -Original Message- > From: Vladimir Oltean > Sent: Wednesday, July 22, 2020 8:24 PM > To: robh...@kernel.org; shawn...@kernel.org; m...@ellerman.id.au; > devicet...@vger.kernel.org > Cc: b...@kernel.crashing.org; pau...@samba.org; linuxppc- > d...@lists.ozlabs.org;

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

Le 7/21/20 à 7:36 PM, Palmer Dabbelt a écrit : On Tue, 21 Jul 2020 16:11:02 PDT (-0700), b...@kernel.crashing.org wrote: On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote: > > I guess I don't understand why this is necessary at all. > > Specifically: why > > can't we just relocate the

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

Hi Palmer, Le 7/21/20 à 3:05 PM, Palmer Dabbelt a écrit : On Tue, 21 Jul 2020 11:36:10 PDT (-0700), a...@ghiti.fr wrote: Let's try to make progress here: I add linux-mm in CC to get feedback on this patch as it blocks sv48 support too. Sorry for being slow here.  I haven't replied because I

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

Hi Benjamin, Le 7/21/20 à 7:11 PM, Benjamin Herrenschmidt a écrit : On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote: I guess I don't understand why this is necessary at all. Specifically: why can't we just relocate the kernel within the linear map? That would let the bootloader put the

Re: [v4 2/5] KVM: PPC: Book3S HV: track the state GFNs associated with secure VMs

On Fri, Jul 17, 2020 at 01:00:24AM -0700, Ram Pai wrote: > During the life of SVM, its GFNs transition through normal, secure and > shared states. Since the kernel does not track GFNs that are shared, it > is not possible to disambiguate a shared GFN from a GFN whose PFN has > not yet been

Re: [PATCH v2 2/2] KVM: PPC: Book3S HV: rework secure mem slot dropping

On Tue, Jul 21, 2020 at 12:42:02PM +0200, Laurent Dufour wrote: > When a secure memslot is dropped, all the pages backed in the secure device > (aka really backed by secure memory by the Ultravisor) should be paged out > to a normal page. Previously, this was achieved by triggering the page >

Re: [PATCHv3 2/2] powerpc/pseries: update device tree before ejecting hotplug uevents

On Wed, Jul 22, 2020 at 12:57 PM Michael Ellerman wrote: > > Pingfan Liu writes: > > A bug is observed on pseries by taking the following steps on rhel: > ^ > RHEL > >

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

On Thu, Jul 16, 2020 at 06:49:09PM +0200, Christophe Leroy wrote: > Jarkko Sakkinen a écrit : > > > Rename module_alloc() to text_alloc() and module_memfree() to > > text_memfree(), and move them to kernel/text.c, which is unconditionally > > compiled to the kernel proper. This allows kprobes,

Re: [v3 11/15] powerpc/perf: BHRB control to disable BHRB logic when not used

On Thu, Jul 23, 2020 at 11:26 AM Jordan Niethe wrote: > > On Sat, Jul 18, 2020 at 1:26 AM Athira Rajeev > wrote: > > > > PowerISA v3.1 has few updates for the Branch History Rolling Buffer(BHRB). > > > > BHRB disable is controlled via Monitor Mode Control Register A (MMCRA) > > bit, namely "BHRB

Re: [v3 11/15] powerpc/perf: BHRB control to disable BHRB logic when not used

On Sat, Jul 18, 2020 at 1:26 AM Athira Rajeev wrote: > > PowerISA v3.1 has few updates for the Branch History Rolling Buffer(BHRB). > > BHRB disable is controlled via Monitor Mode Control Register A (MMCRA) > bit, namely "BHRB Recording Disable (BHRBRD)". This field controls > whether BHRB

Re: [PATCH v4 5/7] powerpc/iommu: Move iommu_table cleaning routine to iommu_table_clean

On Tue, 2020-07-21 at 19:52 -0500, Brian King wrote: > > > > As of today, there seems to be nothing like that happening in the > > driver I am testing. > > I spoke to Brian King on slack, and he mentioned that at the point DDW > > is created there should be no allocations in place. > > I think

Re: [PATCH v4 5/7] powerpc/iommu: Move iommu_table cleaning routine to iommu_table_clean

On Wed, 2020-07-22 at 11:28 +1000, Alexey Kardashevskiy wrote: > > On 22/07/2020 08:13, Leonardo Bras wrote: > > On Tue, 2020-07-21 at 14:59 +1000, Alexey Kardashevskiy wrote: > > > On 16/07/2020 17:16, Leonardo Bras wrote: > > > > Move the part of iommu_table_free() that does struct iommu_table

Re: [PATCH v2 1/2] powerpc/drmem: accelerate memory_add_physaddr_to_nid() with LMB xarray

Hi Scott, I'm hitting this issue and Rick just pointed my at your patch. Any chance we could get it upstream? Thanks, Anton > On PowerPC, memory_add_physaddr_to_nid() uses a linear search to find > an LMB matching the given address. This scales very poorly when there > are many LMBs. The poor

Re: OF: Can't handle multiple dma-ranges with different offsets

On 22/07/20 4:19 pm, Chris Packham wrote: > Hi, > > I've just fired up linux kernel v5.7 on a p2040 based system and I'm > getting the following new warning > > OF: Can't handle multiple dma-ranges with different offsets on > node(/pcie@ffe202000) > OF: Can't handle multiple dma-ranges with

[PATCH devicetree 4/4] powerpc: dts: t1040rdb: add ports for Seville Ethernet switch

Define the network interface names for the switch ports and hook them up to the 2 QSGMII PHYs that are onboard. A conscious decision was taken to go along with the numbers that are written on the front panel of the board and not with the hardware numbers of the switch chip ports. The 2 are

[PATCH devicetree 2/4] powerpc: dts: t1040: label the 2 MDIO controllers

In preparation of referencing the MDIO nodes from board DTS files (so that we can add PHY nodes easier), add labels to mdio0 and mdio1. Signed-off-by: Vladimir Oltean --- arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH devicetree 3/4] powerpc: dts: t1040rdb: put SGMII PHY under label

We're going to add 8 more PHYs in a future patch. It is easier to follow the hardware description if we don't need to fish for the path of the MDIO controllers inside the SoC and just use the labels. Signed-off-by: Vladimir Oltean --- arch/powerpc/boot/dts/fsl/t1040rdb.dts | 12 ++-- 1

[PATCH devicetree 0/4] Add Seville Ethernet switch to T1040RDB

Seville is a DSA switch that is embedded inside the T1040 SoC, and supported by the mscc_seville DSA driver. The driver has been accepted this release cycle and is currently available in net-next (and therefore, in linux-next). This series adds this switch to the SoC's dtsi files and to the

[PATCH devicetree 1/4] powerpc: dts: t1040: add bindings for Seville Ethernet switch

Add the description of the embedded L2 switch inside the SoC dtsi file for NXP T1040. Signed-off-by: Vladimir Oltean --- arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 75 + 1 file changed, 75 insertions(+) diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

On Wed, Jul 22, 2020 at 1:23 PM Arnd Bergmann wrote: > > On Wed, Jul 22, 2020 at 9:52 PM Palmer Dabbelt wrote: > > On Wed, 22 Jul 2020 02:43:50 PDT (-0700), Arnd Bergmann wrote: > > > On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt wrote: > > > The eventual goal is to have a split of 3840MB for

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

On Wed, Jul 22, 2020 at 9:52 PM Palmer Dabbelt wrote: > On Wed, 22 Jul 2020 02:43:50 PDT (-0700), Arnd Bergmann wrote: > > On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt wrote: > > The eventual goal is to have a split of 3840MB for either user or linear map > > plus and 256MB for vmalloc,

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

On Wed, 22 Jul 2020 02:43:50 PDT (-0700), Arnd Bergmann wrote: On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt wrote: On Tue, 21 Jul 2020 11:36:10 PDT (-0700), a...@ghiti.fr wrote: > Let's try to make progress here: I add linux-mm in CC to get feedback on > this patch as it blocks sv48 support

Re: [PATCH v4 07/12] ppc64/kexec_file: add support to relocate purgatory

On 22/07/20 9:55 am, Michael Ellerman wrote: > Hari Bathini writes: >> Right now purgatory implementation is only minimal. But if purgatory >> code is to be enhanced to copy memory to the backup region and verify >> sha256 digest, relocations may have to be applied to the purgatory. >> So, add

Re: [PATCH v3 0/2] Selftest for cpuidle latency measurement

Hello Daniel, On 21/07/20 8:27 pm, Daniel Lezcano wrote: On 21/07/2020 14:42, Pratik Rajesh Sampat wrote: v2: https://lkml.org/lkml/2020/7/17/369 Changelog v2-->v3 Based on comments from Gautham R. Shenoy adding the following in the selftest, 1. Grepping modules to determine if already loaded

Re: [PATCH] spi: ppc4xx: Convert to use GPIO descriptors

On Tue, 14 Jul 2020 09:22:26 +0200, Linus Walleij wrote: > This converts the PPC4xx SPI driver to use GPIO descriptors. > > The driver is already just picking some GPIOs from the device > tree so the conversion is pretty straight forward. However > this driver is looking form a pure "gpios"

RE: [RFC PATCH] powerpc/pseries/svm: capture instruction faulting on MMIO access, in sprg0 register

Ram Pai writes: > On Wed, Jul 22, 2020 at 12:06:06PM +1000, Michael Ellerman wrote: >> Ram Pai writes: >> > An instruction accessing a mmio address, generates a HDSI fault. This >> > fault is >> > appropriately handled by the Hypervisor. However in the case of >> > secureVMs, the >> > fault

Re: [v3 07/15] powerpc/perf: Add power10_feat to dt_cpu_ftrs

> On 22-Jul-2020, at 4:19 PM, Jordan Niethe wrote: > > On Wed, Jul 22, 2020 at 5:55 PM Athira Rajeev > mailto:atraj...@linux.vnet.ibm.com>> wrote: >> >> >> >> On 22-Jul-2020, at 10:11 AM, Jordan Niethe wrote: >> >> On Sat, Jul 18, 2020 at 1:13 AM Athira Rajeev >> wrote: >> >> >> From:

Re: [PATCH v3] powerpc/pseries: Avoid using addr_to_pfn in realmode

On 7/21/20 3:38 PM, Nicholas Piggin wrote: Excerpts from Ganesh Goudar's message of July 20, 2020 6:03 pm: When an UE or memory error exception is encountered the MCE handler tries to find the pfn using addr_to_pfn() which takes effective address as an argument, later pfn is used to poison

Re: [v3 04/15] powerpc/perf: Add support for ISA3.1 PMU SPRs

> On 22-Jul-2020, at 9:48 AM, Jordan Niethe wrote: > > On Sat, Jul 18, 2020 at 1:02 AM Athira Rajeev > mailto:atraj...@linux.vnet.ibm.com>> wrote: >> >> From: Madhavan Srinivasan >> >> PowerISA v3.1 includes new performance monitoring unit(PMU) >> special purpose registers (SPRs). They are

Re: [v3 07/15] powerpc/perf: Add power10_feat to dt_cpu_ftrs

> On 22-Jul-2020, at 10:11 AM, Jordan Niethe wrote: > > On Sat, Jul 18, 2020 at 1:13 AM Athira Rajeev > mailto:atraj...@linux.vnet.ibm.com>> wrote: >> >> From: Madhavan Srinivasan >> >> Add power10 feature function to dt_cpu_ftrs.c along >> with a power10 specific init() to initialize pmu

Re: [v3 04/15] powerpc/perf: Add support for ISA3.1 PMU SPRs

Jordan Niethe writes: > On Sat, Jul 18, 2020 at 1:02 AM Athira Rajeev > wrote: >> From: Madhavan Srinivasan >> >> PowerISA v3.1 includes new performance monitoring unit(PMU) >> special purpose registers (SPRs). They are ... >> >> diff --git a/arch/powerpc/include/asm/perf_event_server.h >>

Re: [v3 04/15] powerpc/perf: Add support for ISA3.1 PMU SPRs

On Wed, Jul 22, 2020 at 6:07 PM Athira Rajeev wrote: > > > > On 22-Jul-2020, at 9:48 AM, Jordan Niethe wrote: > > On Sat, Jul 18, 2020 at 1:02 AM Athira Rajeev > wrote: > > > From: Madhavan Srinivasan > > PowerISA v3.1 includes new performance monitoring unit(PMU) > special purpose registers

Re: [v3 07/15] powerpc/perf: Add power10_feat to dt_cpu_ftrs

On Wed, Jul 22, 2020 at 5:55 PM Athira Rajeev wrote: > > > > On 22-Jul-2020, at 10:11 AM, Jordan Niethe wrote: > > On Sat, Jul 18, 2020 at 1:13 AM Athira Rajeev > wrote: > > > From: Madhavan Srinivasan > > Add power10 feature function to dt_cpu_ftrs.c along > with a power10 specific init() to

Re: [PATCH] powerpc/64s: Fix irq tracing corruption in interrupt/syscall return caused by perf interrupts

On 22/07/2020 17:34, Nicholas Piggin wrote: > Alexey reports lockdep_assert_irqs_enabled() warnings when stress testing > perf, e.g., > > WARNING: CPU: 0 PID: 1556 at kernel/softirq.c:169 > __local_bh_enable_ip+0x258/0x270 > CPU: 0 PID: 1556 Comm: syz-executor > NIP: c01ec888 LR:

Re: [PATCH 09/20] Documentation: i2c: eliminate duplicated word

On Tue, Jul 07, 2020 at 11:04:03AM -0700, Randy Dunlap wrote: > Drop doubled word "new". > > Signed-off-by: Randy Dunlap For the record: Acked-by: Wolfram Sang signature.asc Description: PGP signature

Re: [v3 07/15] powerpc/perf: Add power10_feat to dt_cpu_ftrs

Athira Rajeev writes: >> On 22-Jul-2020, at 10:11 AM, Jordan Niethe wrote: >> >> On Sat, Jul 18, 2020 at 1:13 AM Athira Rajeev >> mailto:atraj...@linux.vnet.ibm.com>> wrote: >>> >>> From: Madhavan Srinivasan >>> >>> Add power10 feature function to dt_cpu_ftrs.c along >>> with a power10

Re: [PATCH 15/15] powerpc/powernv/sriov: Make single PE mode a per-BAR setting

On 22/07/2020 15:39, Oliver O'Halloran wrote: > On Wed, Jul 15, 2020 at 6:00 PM Alexey Kardashevskiy wrote: >> >* > - * Generally, one M64 BAR maps one IOV BAR. To avoid > conflict > - * with other devices, IOV BAR size is expanded to

Re: [v4 5/5] KVM: PPC: Book3S HV: migrate hot plugged memory

On Fri, Jul 17, 2020 at 01:00:27AM -0700, Ram Pai wrote: > From: Laurent Dufour > > When a memory slot is hot plugged to a SVM, PFNs associated with the > GFNs in that slot must be migrated to secure-PFNs, aka device-PFNs. > > Call kvmppc_uv_migrate_mem_slot() to accomplish this. > Disable

Re: [PATCH 05/15] powerpc/powernv/sriov: Move SR-IOV into a seperate file

On 22/07/2020 15:01, Oliver O'Halloran wrote: > On Tue, Jul 14, 2020 at 7:16 PM Alexey Kardashevskiy wrote: >> >> On 10/07/2020 15:23, Oliver O'Halloran wrote: >>> + align = pci_iov_resource_size(pdev, resno); >>> + >>> + /* >>> + * iov can be null if we have an SR-IOV device with

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt wrote: > > On Tue, 21 Jul 2020 11:36:10 PDT (-0700), a...@ghiti.fr wrote: > > Let's try to make progress here: I add linux-mm in CC to get feedback on > > this patch as it blocks sv48 support too. > > Sorry for being slow here. I haven't replied

Re: [PATCH v2 06/10] powerpc/smp: Generalize 2nd sched domain

On Wed, Jul 22, 2020 at 10:48:54AM +0200, Peter Zijlstra wrote: > But reading your explanation, it looks like the Linux topology setup > could actually unravel the fused-faux-SMT8 into two independent SMT4 > parts, negating that firmware option. Ah, it looks like that's exactly what you're doing.

Re: [v4 1/5] KVM: PPC: Book3S HV: Disable page merging in H_SVM_INIT_START

On Fri, Jul 17, 2020 at 01:00:23AM -0700, Ram Pai wrote: > Page-merging of pages in memory-slots associated with a Secure VM, > is disabled in H_SVM_PAGE_IN handler. > > This operation should have been done much earlier; the moment the VM > is initiated for secure-transition. Delaying this

Re: [PATCH v2 06/10] powerpc/smp: Generalize 2nd sched domain

On Wed, Jul 22, 2020 at 01:48:22PM +0530, Srikar Dronamraju wrote: > * pet...@infradead.org [2020-07-22 09:46:24]: > > > On Tue, Jul 21, 2020 at 05:08:10PM +0530, Srikar Dronamraju wrote: > > > Currently "CACHE" domain happens to be the 2nd sched domain as per > > > powerpc_topology. This domain

Re: [PATCH v3 0/4] powerpc/mm/radix: Memory unplug fixes

On Wed, Jul 22, 2020 at 11:35:06AM +0530, Bharata B Rao wrote: > On Tue, Jul 21, 2020 at 10:25:58PM +1000, Michael Ellerman wrote: > > Bharata B Rao writes: > > > On Tue, Jul 21, 2020 at 11:45:20AM +1000, Michael Ellerman wrote: > > >> Nathan Lynch writes: > > >> > "Aneesh Kumar K.V" writes: >

Re: [PATCH v2 06/10] powerpc/smp: Generalize 2nd sched domain

* pet...@infradead.org [2020-07-22 09:46:24]: > On Tue, Jul 21, 2020 at 05:08:10PM +0530, Srikar Dronamraju wrote: > > Currently "CACHE" domain happens to be the 2nd sched domain as per > > powerpc_topology. This domain will collapse if cpumask of l2-cache is > > same as SMT domain. However we

Re: [PATCH v2 01/10] powerpc/smp: Cache node for reuse

* Michael Ellerman [2020-07-22 17:41:41]: > Srikar Dronamraju writes: > > While cpu_to_node is inline function with access to per_cpu variable. > > However when using repeatedly, it may be cleaner to cache it in a local > > variable. > > It's not clear what "cleaner" is supposed to mean. Are

RE: [RFC PATCH] powerpc/pseries/svm: capture instruction faulting on MMIO access, in sprg0 register

On Wed, Jul 22, 2020 at 12:06:06PM +1000, Michael Ellerman wrote: > Ram Pai writes: > > An instruction accessing a mmio address, generates a HDSI fault. This > > fault is > > appropriately handled by the Hypervisor. However in the case of secureVMs, > > the > > fault is delivered to the

Re: [PATCH v2 06/10] powerpc/smp: Generalize 2nd sched domain

On Tue, Jul 21, 2020 at 05:08:10PM +0530, Srikar Dronamraju wrote: > Currently "CACHE" domain happens to be the 2nd sched domain as per > powerpc_topology. This domain will collapse if cpumask of l2-cache is > same as SMT domain. However we could generalize this domain such that it > could mean

RE: [RFC PATCH] powerpc/pseries/svm: capture instruction faulting on MMIO access, in sprg0 register

On Wed, Jul 22, 2020 at 12:42:05AM -0700, Ram Pai wrote: > On Wed, Jul 22, 2020 at 03:02:32PM +1000, Paul Mackerras wrote: > > On Thu, Jul 16, 2020 at 01:32:13AM -0700, Ram Pai wrote: > > > An instruction accessing a mmio address, generates a HDSI fault. This > > > fault is > > > appropriately

Re: Re: [RFC PATCH] powerpc/pseries/svm: capture instruction faulting on MMIO access, in sprg0 register

On Wed, Jul 22, 2020 at 03:02:32PM +1000, Paul Mackerras wrote: > On Thu, Jul 16, 2020 at 01:32:13AM -0700, Ram Pai wrote: > > An instruction accessing a mmio address, generates a HDSI fault. This > > fault is > > appropriately handled by the Hypervisor. However in the case of secureVMs, > >

Re: [PATCH v2 01/10] powerpc/smp: Cache node for reuse

Srikar Dronamraju writes: > While cpu_to_node is inline function with access to per_cpu variable. > However when using repeatedly, it may be cleaner to cache it in a local > variable. It's not clear what "cleaner" is supposed to mean. Are you saying it makes the source clearer, or the generated

Re: [PATCH v2 06/10] powerpc/smp: Generalize 2nd sched domain

* Gautham R Shenoy [2020-07-22 12:26:40]: > Hello Srikar, > > On Tue, Jul 21, 2020 at 05:08:10PM +0530, Srikar Dronamraju wrote: > > Currently "CACHE" domain happens to be the 2nd sched domain as per > > powerpc_topology. This domain will collapse if cpumask of l2-cache is > > same as SMT

[PATCH] powerpc/64s: Fix irq tracing corruption in interrupt/syscall return caused by perf interrupts

Alexey reports lockdep_assert_irqs_enabled() warnings when stress testing perf, e.g., WARNING: CPU: 0 PID: 1556 at kernel/softirq.c:169 __local_bh_enable_ip+0x258/0x270 CPU: 0 PID: 1556 Comm: syz-executor NIP: c01ec888 LR: c01ec884 CTR: c0ef0610 REGS: c00022d4f8a0

Re: [PATCH v2 09/10] Powerpc/smp: Create coregroup domain

> > @@ -1386,6 +1421,9 @@ int setup_profiling_timer(unsigned int multiplier) > > > > static void fixup_topology(void) > > { > > + if (!has_coregroup_support()) > > + powerpc_topology[mc_idx].mask = cpu_bigcore_mask; > > + > > Shouldn't we move this condition after doing the fixup

Re: [PATCH v2 2/2] KVM: PPC: Book3S HV: rework secure mem slot dropping

Le 21/07/2020 à 23:37, Ram Pai a écrit : On Tue, Jul 21, 2020 at 12:42:02PM +0200, Laurent Dufour wrote: When a secure memslot is dropped, all the pages backed in the secure device (aka really backed by secure memory by the Ultravisor) should be paged out to a normal page. Previously, this was

Re: [PATCH v2 10/10] powerpc/smp: Implement cpu_to_coregroup_id

On Tue, Jul 21, 2020 at 05:08:14PM +0530, Srikar Dronamraju wrote: > Lookup the coregroup id from the associativity array. > > If unable to detect the coregroup id, fallback on the core id. > This way, ensure sched_domain degenerates and an extra sched domain is > not created. > > Ideally this

Re: [PATCH v2 09/10] Powerpc/smp: Create coregroup domain

Hi Srikar, On Tue, Jul 21, 2020 at 05:08:13PM +0530, Srikar Dronamraju wrote: > Add percpu coregroup maps and masks to create coregroup domain. > If a coregroup doesn't exist, the coregroup domain will be degenerated > in favour of SMT/CACHE domain. > > Cc: linuxppc-dev > Cc: LKML > Cc:

Re: [PATCH v2 04/10] powerpc/smp: Enable small core scheduling sooner

* Gautham R Shenoy [2020-07-22 11:29:25]: > Hello Srikar, > > On Tue, Jul 21, 2020 at 05:08:08PM +0530, Srikar Dronamraju wrote: > > Enable small core scheduling as soon as we detect that we are in a > > system that supports thread group. Doing so would avoid a redundant > > check. > > The

Re: [PATCH v2 05/10] powerpc/smp: Dont assume l2-cache to be superset of sibling

* Gautham R Shenoy [2020-07-22 11:51:14]: > Hi Srikar, > > > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c > > index 72f16dc0cb26..57468877499a 100644 > > --- a/arch/powerpc/kernel/smp.c > > +++ b/arch/powerpc/kernel/smp.c > > @@ -1196,6 +1196,7 @@ static bool

[PATCH v2 16/16] powerpc/powernv/sriov: Remove vfs_expanded

Previously iov->vfs_expanded was used for two purposes. 1) To work out how much we need to multiple the per-VF BAR size to figure out the total space required for the IOV BAR. 2) To indicate that IOV is not usable with this device (vfs_expanded == 0). We don't really need the field for

[PATCH v2 15/16] powerpc/powernv/sriov: Make single PE mode a per-BAR setting

Using single PE BARs to map an SR-IOV BAR is really a choice about what strategy to use when mapping a BAR. It doesn't make much sense for this to be a global setting since a device might have one large BAR which needs to be mapped with single PE windows and another smaller BAR that can be mapped

[PATCH v2 14/16] powerpc/powernv/sriov: Refactor M64 BAR setup

Split up the logic so that we have one branch that handles setting up a segmented window and another that handles setting up single PE windows for each VF. Signed-off-by: Oliver O'Halloran Reviewed-by: Alexey Kardashevskiy --- v2: no changes --- arch/powerpc/platforms/powernv/pci-sriov.c | 57

[PATCH v2 13/16] powerpc/powernv/sriov: Move M64 BAR allocation into a helper

I want to refactor the loop this code is currently inside of. Hoist it on out. Signed-off-by: Oliver O'Halloran Reviewed-by: Alexey Kardashevskiy --- v2: no change --- arch/powerpc/platforms/powernv/pci-sriov.c | 31 ++ 1 file changed, 20 insertions(+), 11 deletions(-)

[PATCH v2 12/16] powerpc/powernv/sriov: De-indent setup and teardown

Remove the IODA2 PHB checks. We already assume IODA2 in several places so there's not much point in wrapping most of the setup and teardown process in an if block. Signed-off-by: Oliver O'Halloran --- v2: Added a note that iov->vf_pe_arr is a pointer into the PHB's PE array rather than

[PATCH v2 11/16] powerpc/powernv/sriov: Drop iov->pe_num_map[]

Currently the iov->pe_num_map[] does one of two things depending on whether single PE mode is being used or not. When it is, this contains an array which maps a vf_index to the corresponding PE number. When single PE mode is not being used this contains a scalar which is the base PE for the set of

[PATCH v2 10/16] powerpc/powernv/pci: Refactor pnv_ioda_alloc_pe()

Rework the PE allocation logic to allow allocating blocks of PEs rather than individually. We'll use this to allocate contigious blocks of PEs for the SR-IOVs. This patch also adds code to pnv_ioda_alloc_pe() and pnv_ioda_reserve_pe() to use the existing, but unused, phb->pe_alloc_mutex.

[PATCH v2 09/16] powerpc/powernv/sriov: Factor out M64 BAR setup

The sequence required to use the single PE BAR mode is kinda janky and requires a little explanation. The API was designed with P7-IOC style windows where the setup process is something like: 1. Configure the window start / end address 2. Enable the window 3. Map the segments of each window to

[PATCH v2 08/16] powerpc/powernv/sriov: Simplify used window tracking

No need for the multi-dimensional arrays, just use a bitmap. Signed-off-by: Oliver O'Halloran Reviewed-by: Alexey Kardashevskiy --- v2: Fixed license to GPL-2.0-or-later Added MAX_M64_BARS for the size of the M64 allocation bitmap rather than open coding 64. ---

[PATCH v2 07/16] powerpc/powernv/sriov: Rename truncate_iov

This prevents SR-IOV being used by making the SR-IOV BAR resources unallocatable. Rename it to reflect what it actually does. Signed-off-by: Oliver O'Halloran Reviewed-by: Alexey Kardashevskiy --- v2: no changes --- arch/powerpc/platforms/powernv/pci-sriov.c | 11 ++- 1 file changed, 6

[PATCH v2 06/16] powerpc/powernv/sriov: Explain how SR-IOV works on PowerNV

SR-IOV support on PowerNV is a byzantine maze of hooks. I have no idea how anyone is supposed to know how it works except through a lot of stuffering. Write up some docs about the overall story to help out the next sucker^Wperson who needs to tinker with it. Signed-off-by: Oliver O'Halloran

[PATCH v2 05/16] powerpc/powernv/sriov: Move SR-IOV into a separate file

pci-ioda.c is getting a bit unwieldly due to the amount of stuff jammed in there. The SR-IOV support can be extracted easily enough and is mostly standalone, so move it into a separate file. This patch also moves the PowerNV SR-IOV specific fields from pci_dn and moves them into a platform

[PATCH v2 04/16] powerpc/powernv/pci: Initialise M64 for IODA1 as a 1-1 window

We pre-configure the m64 window for IODA1 as a 1-1 segment-PE mapping, similar to PHB3. Currently the actual mapping of segments occurs in pnv_ioda_pick_m64_pe(), but we can move it into pnv_ioda1_init_m64() and drop the IODA1 specific code paths in the PE setup / teardown. Signed-off-by: Oliver

[PATCH v2 03/16] powerpc/powernv/pci: Add explicit tracking of the DMA setup state

There's an optimisation in the PE setup which skips performing DMA setup for a PE if we only have bridges in a PE. The assumption being that only "real" devices will DMA to system memory, which is probably fair. However, if we start off with only bridge devices in a PE then add a non-bridge device

[PATCH v2 02/16] powerpc/powernv/pci: Always tear down DMA windows on PE release

Currently we have these two functions: pnv_pci_ioda2_release_dma_pe(), and pnv_pci_ioda2_release_pe_dma() The first is used when tearing down VF PEs and the other is used for normal devices. There's very little difference between the two though. The latter (non-VF) will skip a

[PATCH v2 01/16] powernv/pci: Add pci_bus_to_pnvhb() helper

Add a helper to go from a pci_bus structure to the pnv_phb that hosts that bus. There's a lot of instances of the following pattern: struct pci_controller *hose = pci_bus_to_host(pdev->bus); struct pnv_phb *phb = hose->private_data; Without any other uses of the pci_controller

Re: [PATCH v2 06/10] powerpc/smp: Generalize 2nd sched domain

Hello Srikar, On Tue, Jul 21, 2020 at 05:08:10PM +0530, Srikar Dronamraju wrote: > Currently "CACHE" domain happens to be the 2nd sched domain as per > powerpc_topology. This domain will collapse if cpumask of l2-cache is > same as SMT domain. However we could generalize this domain such that it

Re: [PATCH v2 05/10] powerpc/smp: Dont assume l2-cache to be superset of sibling

Hi Srikar, On Tue, Jul 21, 2020 at 05:08:09PM +0530, Srikar Dronamraju wrote: > Current code assumes that cpumask of cpus sharing a l2-cache mask will > always be a superset of cpu_sibling_mask. > > Lets stop that assumption. cpu_l2_cache_mask is a superset of > cpu_sibling_mask if and only if

Re: [PATCH v3 0/4] powerpc/mm/radix: Memory unplug fixes

On Tue, Jul 21, 2020 at 10:25:58PM +1000, Michael Ellerman wrote: > Bharata B Rao writes: > > On Tue, Jul 21, 2020 at 11:45:20AM +1000, Michael Ellerman wrote: > >> Nathan Lynch writes: > >> > "Aneesh Kumar K.V" writes: > >> >> This is the next version of the fixes for memory unplug on radix. >

Re: [v3 02/15] KVM: PPC: Book3S HV: Cleanup updates for kvm vcpu MMCR

On 7/22/20 10:24 AM, Paul Mackerras wrote: On Wed, Jul 22, 2020 at 07:39:26AM +0530, Athira Rajeev wrote: On 21-Jul-2020, at 9:24 AM, Paul Mackerras wrote: On Fri, Jul 17, 2020 at 10:38:14AM -0400, Athira Rajeev wrote: Currently `kvm_vcpu_arch` stores all Monitor Mode Control registers

Re: [v3 02/15] KVM: PPC: Book3S HV: Cleanup updates for kvm vcpu MMCR

> On 22-Jul-2020, at 10:07 AM, Michael Ellerman wrote: > > Athira Rajeev > writes: >>> On 21-Jul-2020, at 9:24 AM, Paul Mackerras wrote: >>> On Fri, Jul 17, 2020 at 10:38:14AM -0400, Athira Rajeev wrote: Currently `kvm_vcpu_arch` stores all Monitor