book3s_64_vio currently accounts for pinned pages with
account_locked_vm() which charges the pages to mm->locked_vm. To make
this consistent with other drivers switch to using
vm_account_pinned().
Signed-off-by: Alistair Popple
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Mike Kravetz writes:
> On 12/19/22 13:06, Michal Hocko wrote:
>> On Fri 16-12-22 11:20:12, Mike Kravetz wrote:
>> > zap_page_range was originally designed to unmap pages within an address
>> > range that could span multiple vmas. While working on [1], it was
>> > discovered that all callers of
Thanks, looks reasonable.
Reviewed-by: Alistair Popple
On Saturday, 18 September 2021 7:22:32 PM AEST Christophe Leroy wrote:
> arch/powerpc/platforms/44x/ppc476.c:236:17: warning: cast removes
> address space '__iomem' of expression
> arch/powerpc/platforms/
retry adds complexity. So clean this up by removing the retry
and MIGRATE_PFN_LOCKED flag.
Destination pages are also meant to have the MIGRATE_PFN_LOCKED flag
set, but nothing actually checks that.
Signed-off-by: Alistair Popple
---
Documentation/vm/hmm.rst | 2 +-
arch/p
On Tuesday, 26 October 2021 11:57:06 AM AEDT Ralph Campbell wrote:
>
> On 10/24/21 21:16, Alistair Popple wrote:
> > MIGRATE_PFN_LOCKED is used to indicate to migrate_vma_prepare() that a
> > source page was already locked during migrate_vma_collect(). If it
> > wasn
On Wednesday, 27 October 2021 3:09:57 AM AEDT Felix Kuehling wrote:
> Am 2021-10-25 um 12:16 a.m. schrieb Alistair Popple:
> > MIGRATE_PFN_LOCKED is used to indicate to migrate_vma_prepare() that a
> > source page was already locked during migrate_vma_collect(). If it
> > was
On Friday, 29 October 2021 2:33:31 AM AEDT Felix Kuehling wrote:
> Am 2021-10-27 um 9:42 p.m. schrieb Alistair Popple:
> > On Wednesday, 27 October 2021 3:09:57 AM AEDT Felix Kuehling wrote:
> >> Am 2021-10-25 um 12:16 a.m. schrieb Alistair Popple:
> >>> MIGRATE_PFN
.
UV_PAGE_IN_in both copies and maps the data page, therefore it should
only be called after checking the results of migrate_vma_pages().
Signed-off-by: Alistair Popple
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm
On Friday, 4 December 2020 9:18:41 PM AEDT Bharata B Rao wrote:
>
> Reviewed-by: Bharata B Rao
>
> Did you actually hit this scenario with secure VMs where a UV-paged-in
> page was later found to be not migratable?
No, this was found by inspection. I have no way of testing this but we had a
si
On Saturday, 5 December 2020 3:52:44 AM AEDT Ram Pai wrote:
> On Fri, Dec 04, 2020 at 03:48:41PM +0530, Bharata B Rao wrote:
> > On Thu, Dec 03, 2020 at 04:08:12PM +1100, Alistair Popple wrote:
> This patch certainly looks like the problem, that has been hurting
> us for a while.
On Thursday, 14 May 2020 4:11:43 PM AEST Christophe Leroy wrote:
> @@ -249,7 +249,7 @@ int arch_prepare_optimized_kprobe(struct
> optimized_kprobe *op, struct kprobe *p)
> > * Fixup the template with instructions to:
> > * 1. load the address of the actual probepoint
> > */
> > - patch_imm64_
nother and it seems logical to me at least
that you would introduce prefix support to the datatype prior to using them.
- Alistair
> Christophe
>
> > Reviewed-by: Alistair Popple
> > Signed-off-by: Jordan Niethe
> > ---
> > v2: - Move __get_user_instr() an
On Thursday, 14 May 2020 4:15:06 PM AEST Christophe Leroy wrote:
> Shouldn't this patch go before patch 23 ?
Perhaps I am missing something, but it seems reasonable enough to me that you
would introduce the machinery for dealing with prefix instructions prior to
defining them. What would be the
v1:
- Two bug-fixes to enable prefix and MMA on pseries
- Minor updates to commit message wording
- Fixes a build error when CONFIG_KVM_BOOK3S_64_HV is enabled
Alistair Popple (7):
powerpc: Add new HWCAP bits
powerpc: Add support for ISA v3.1
powerpc/dt_cpu_ftrs: Advertise support for
POWER10 introduces two new architectural features - ISAv3.1 and matrix
multiply accumulate (MMA) instructions. Userspace detects the presence
of these features via two HWCAP bits introduced in this patch. These
bits have been agreed to by the compiler and binutils team.
Signed-off-by: Alistair
supported by the hardware.
Signed-off-by: Alistair Popple
---
arch/powerpc/include/asm/cputable.h | 1 +
arch/powerpc/include/asm/reg.h | 3 ++-
arch/powerpc/kvm/book3s_hv.c| 3 ---
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch
On powernv hardware support for ISAv3.1 is advertised via a cpu feature
bit in the device tree. This patch enables the associated HWCAP bit if
the device tree indicates ISAv3.1 is available.
Signed-off-by: Alistair Popple
---
arch/powerpc/kernel/dt_cpu_ftrs.c | 6 ++
1 file changed, 6
anges made to the FSCR during cpu feature detection. This
patch ensures the current thread state is updated to match once feature
detection is complete.
Signed-off-by: Alistair Popple
---
arch/powerpc/kernel/dt_cpu_ftrs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/k
Prefix instructions have their own FSCR bit which needs to be enabled
via a CPU feature. The kernel will save the FSCR for problem state but
it needs to be enabled initially.
Signed-off-by: Alistair Popple
---
arch/powerpc/kernel/dt_cpu_ftrs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
Matrix multiple accumulate (MMA) is a new feature added to ISAv3.1 and
POWER10. Support on powernv can be selected via a firmware CPU device
tree feature which enables it via a PCR bit.
Signed-off-by: Alistair Popple
---
arch/powerpc/include/asm/reg.h| 3 ++-
arch/powerpc/kernel
PVR value of 0x0F06 means we are arch v3.1 compliant (i.e. POWER10).
This is used by phyp and kvm when booting as a pseries guest to detect
the presence of new P10 features and to enable the appropriate hwcap and
facility bits.
Signed-off-by: Alistair Popple
Signed-off-by: Cédric Le Goater
On Tuesday, 19 May 2020 2:04:51 PM AEST Jordan Niethe wrote:
> On Tue, May 19, 2020 at 10:39 AM Alistair Popple
wrote:
> > Newer ISA versions are enabled by clearing all bits in the PCR
> > associated with previous versions of the ISA. Enable ISA v3.1 support
> > by upd
at 10:31:56AM +1000, Alistair Popple wrote:
> > Matrix multiple accumulate (MMA) is a new feature added to ISAv3.1 and
>
> Conclusion is that this should be "Matrix-Multiply Assist", but then there
> are a couple more below...
>
> > POWER10. Support on powernv
On Wednesday, 20 May 2020 12:42:09 PM AEST Michael Ellerman wrote:
> Alistair Popple writes:
> > POWER10 introduces two new architectural features - ISAv3.1 and matrix
> > multiply accumulate (MMA) instructions. Userspace detects the presence
> > of these features via two HWC
v2:
- s/accumulate/assist/
- Updated commit messages
Changes from v1:
- Two bug-fixes to enable prefix and MMA on pseries
- Minor updates to commit message wording
- Fixes a build error when CONFIG_KVM_BOOK3S_64_HV is enabled
Alistair Popple (7):
powerpc: Add new HWCAP bits
powerpc
optional feature and software that makes
use of it should first check for availability via this HWCAP bit and use
alternate code paths if unavailable.
Signed-off-by: Alistair Popple
Tested-by: Michael Neuling
---
arch/powerpc/include/uapi/asm/cputable.h | 2 ++
1 file changed, 2 insertions
supported by the hardware.
Signed-off-by: Alistair Popple
---
arch/powerpc/include/asm/cputable.h | 1 +
arch/powerpc/include/asm/reg.h | 3 ++-
arch/powerpc/kvm/book3s_hv.c| 3 ---
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch
On powernv hardware support for ISAv3.1 is advertised via a cpu feature
bit in the device tree. This patch enables the associated HWCAP bit if
the device tree indicates ISAv3.1 is available.
Signed-off-by: Alistair Popple
---
arch/powerpc/kernel/dt_cpu_ftrs.c | 6 ++
1 file changed, 6
anges made to the FSCR during cpu feature detection. This
patch ensures the current thread state is updated to match once feature
detection is complete.
Signed-off-by: Alistair Popple
---
arch/powerpc/kernel/dt_cpu_ftrs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/k
Prefix instructions have their own FSCR bit which needs to be enabled
via a CPU feature. The kernel will save the FSCR for problem state but
it needs to be enabled initially.
Signed-off-by: Alistair Popple
---
arch/powerpc/kernel/dt_cpu_ftrs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
Matrix multiple assist (MMA) is a new feature added to ISAv3.1 and
POWER10. Support on powernv can be selected via a firmware CPU device
tree feature which enables it via a PCR bit.
Signed-off-by: Alistair Popple
---
arch/powerpc/include/asm/reg.h| 3 ++-
arch/powerpc/kernel/dt_cpu_ftrs.c
PVR value of 0x0F06 means we are arch v3.1 compliant (i.e. POWER10).
This is used by phyp and kvm when booting as a pseries guest to detect
the presence of new P10 features and to enable the appropriate hwcap and
facility bits.
Signed-off-by: Alistair Popple
Signed-off-by: Cédric Le Goater
For what it's worth I tested this series on Mambo PowerNV and it seems to
correctly enable/disable the prefix FSCR bit based on the cpu feature so feel
free to add:
Tested-by: Alistair Popple
Mikey is going to test out pseries.
- Alistair
On Thursday, 28 May 2020 12:58:40 AM AEST Mi
Adds support for emulating ISAv3.1 guests by adding the appropriate PCR
and FSCR bits.
Signed-off-by: Alistair Popple
---
arch/powerpc/include/asm/reg.h | 1 +
arch/powerpc/kvm/book3s_hv.c | 11 ---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include
I've tested these on Mambo and they pass so:
Tested-by: Alistair Popple
On Wednesday, 20 May 2020 12:11:02 PM AEST Jordan Niethe wrote:
> The alignment handler selftest needs cache-inhibited memory and
> currently /dev/fb0 is relied on to provided this. This prevents running
&g
Tested-by: Alistair Popple
On Wednesday, 20 May 2020 12:11:03 PM AEST Jordan Niethe wrote:
> Extend the alignment handler selftest to exercise prefixed load store
> instructions. Add tests for prefixed VSX, floating point and integer
> instructions.
>
> Skip prefix tests if ISA v
On Wednesday, 20 May 2020 12:11:03 PM AEST Jordan Niethe wrote:
> +/* POWER10 feature */
> +#ifndef PPC_FEATURE2_ARCH_3_10
> +#define PPC_FEATURE2_ARCH_3_10 0x0004
> +#endif
One minor nit pick, this needs to be updated to PPC_FEATURE2_ARCH_3_1 to
reflect the changes made in response to feedba
Adds a simple test of some basic matrix multiply assist (MMA)
instructions.
Signed-off-by: Alistair Popple
---
.../testing/selftests/powerpc/include/utils.h | 5 ++
tools/testing/selftests/powerpc/math/Makefile | 6 ++-
tools/testing/selftests/powerpc/math/mma.S| 33 +
tools
Alexey,
> >>> +void pnv_try_isolate_nvidia_v100(struct pci_dev *bridge)
> >>> +{
> >>> + u32 mask, val;
> >>> + void __iomem *bar0_0, *bar0_12, *bar0_a0;
> >>> + struct pci_dev *pdev;
> >>> + u16 cmd = 0, cmdmask = PCI_COMMAND_MEMORY;
> >>> +
> >>> + if (!bridge->subordinate)
> >>> +
Hi Alexey,
Do we need a seperate patch to allow this to be used? Last time I tried
calling dma_set_mask(52) on powernv it returned an error and there doesn't
seem to be anything obvious to me in this series to change that behaviour, but
perhaps I missed something.
- Alistair
On Wednesday, 1 M
I have been hitting EEH address errors testing this with some network
cards which map/unmap DMA addresses more frequently. For example:
PHB4 PHB#5 Diag-data (Version: 1)
On Thursday, 6 June 2019 10:07:54 PM AEST Oliver wrote:
> On Thu, Jun 6, 2019 at 5:17 PM Alistair Popple
wrote:
> > I have been hitting EEH address errors testing this with some network
> > cards which map/unmap DMA addresses more frequently. For example:
> >
> > PH
There is of_property_read_u32_index but no u64 variant. This patch
adds one similar to the u32 version for u64.
Signed-off-by: Alistair Popple
---
drivers/of/base.c | 31 +++
include/linux/of.h | 3 +++
2 files changed, 34 insertions(+)
diff --git a/drivers/of
.
Signed-off-by: Alistair Popple
---
arch/powerpc/platforms/powernv/npu-dma.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
index 1c383f3..050bd5d 100644
--- a/arch/powerpc/platforms/powernv/npu
when a device should stop issuing address translation
requests (ATRs). It also adds a fault handler to allow device drivers
to demand fault pages in.
Signed-off-by: Alistair Popple
---
arch/powerpc/include/asm/book3s/64/mmu.h | 6 +
arch/powerpc/include/asm/opal-api.h| 5
There is of_property_read_u32_index but no u64 variant. This patch
adds one similar to the u32 version for u64.
Signed-off-by: Alistair Popple
Acked-by: Rob Herring
---
drivers/of/base.c | 31 +++
include/linux/of.h | 3 +++
2 files changed, 34 insertions(+)
diff
-off-by: Alistair Popple
---
arch/powerpc/platforms/powernv/npu-dma.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
index 1c383f3..050bd5d 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
when a device should stop issuing address translation
requests (ATRs). It also adds a fault handler to allow device drivers
to demand fault pages in.
Signed-off-by: Alistair Popple
---
Changes since v1:
- Moved exported function call prototypes to an externally accessable
header.
- Fixed
27;t specifically looking at timing, hence the vagueness of the
remarks).
Otherwise the patch worked and would be useful - I have already had to
setup tlbie counting/tracing several times in the last 12 months.
Tested-by: Alistair Popple
- Alistair
> Thanks for the review
> Balbir Singh
The patch to introduce address translation services for Nvlink2 uses
MMU notifiers. However usage of MMU notifiers requires a Kconfig
option which is not selected by default on powerpc so add it to the
powernv Kconfig.
Signed-off-by: Alistair Popple
---
arch/powerpc/platforms/powernv/Kconfig
This patch adds an equivalent IODA2 version of the function which uses
the correct invalidation method depending on PHB model and changes all
external callers to use it instead.
Fixes: 616badd2fb49 ("powerpc/powernv: Use OPAL call for TCE kill on NVLink2")
Signed-off-by: Alis
Hi Frederic,
On Wed, 3 May 2017 04:29:04 PM Frederic Barrat wrote:
> capi2 and opencapi require the TLB invalidations being sent for
> addresses used on the cxl adapter or opencapi device to be global, as
> there's a translation cache in the PSL (for capi2) or NPU (for
> opencapi). The CAPP (for P
opal_npu_destroy_context() should be called with the NPU PHB, not the
PCIe PHB.
Signed-off-by: Alistair Popple
---
arch/powerpc/platforms/powernv/npu-dma.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms
t once for
every PCIe device in the system. This results in spurious WARN_ON()'s so
remove it.
The same situation should not exist for pnv_pci_get_gpu_dev() as any NPU
based PCIe device requires a device-tree node.
Signed-off-by: Alistair Popple
Reported-by: Alexey Kardashevskiy
---
arch/po
only used for init_mm which will never be a user mm on the GPU. To
enforce this we add a check in pnv_npu2_init_context() just in case someone
tries to use PID 0 on the GPU.
Signed-off-by: Alistair Popple
---
Michael,
It turns out my assumptions about MMU_NO_CONTEXT were wrong so we have
reverted
You may need some kind of temporary unused annotation to shut the
compiler/kbuild robot up but the patch itself looks fine.
Reviewed-by: Alistair Popple
On Wed, 21 Jun 2017 05:18:03 PM Russell Currey wrote:
> Add a helper that determines if all the devices contained in a given PE
> are al
On Thursday, 2 November 2017 4:07:06 PM AEDT Ivan Mikhaylov wrote:
> * add irq error handlers for cmu, plb, opb, mcue, conf
> with debug information output in case of problem.
>
> Signed-off-by: Ivan Mikhaylov
> ---
> arch/powerpc/platforms/44x/fsp2.c | 204
>
Again, I'm not familiar with this specific hardware so can only provide general
comments.
On Thursday, 2 November 2017 4:07:05 PM AEDT Ivan Mikhaylov wrote:
> * tvsense(temperature and voltage sensors) may provide
> erratic sense values which may result in parity errors
> on CMU.
It would be
I'm not familiar with the hardware setup going on here so I can't comment on
it's correctness but the code looks ok. A commit message describing why this
particular setup is needed would be nice though.
Reviewed-by: Alistair Popple
On Thursday, 2 November 2017 4:07:04 PM AEDT
Hi Ivan,
Does it make sense to have these in a seperate include file? From what I could
see these defines were only used in fsp2.c so you could just put them directly
in there.
- Alistair
On Thursday, 2 November 2017 4:07:03 PM AEDT Ivan Mikhaylov wrote:
> * add cmu, plbX, l2 register definition
On Friday, 8 December 2017 6:41:02 PM AEDT Ivan Mikhaylov wrote:
> add irq error handlers for cmu, plb, opb, mcue, conf
> with debug information output in case of problems.
>
> Signed-off-by: Ivan Mikhaylov
Acked-by: Alistair Popple
> ---
> arch/powerpc/platforms
address of the partition table
(ie. the PTCR) which needs to be programmed into the NMMU.
This patch adds a call to OPAL to set the PTCR for the nest mmu in
opal_init().
Signed-off-by: Alistair Popple
---
arch/powerpc/include/asm/opal-api.h| 3 ++-
arch/powerpc/include/asm/opal.h
On Fri, 2 Dec 2016 08:24:09 PM Michael Ellerman wrote:
> Alistair Popple writes:
>
> > diff --git a/arch/powerpc/platforms/powernv/powernv.h
> > b/arch/powerpc/platforms/powernv/powernv.h
> > index da7c843..6fa9551 100644
> > --- a/arch/powerpc/platforms/powernv/po
Hi,
On Sat, 3 Dec 2016 10:40:58 PM Michael Ellerman wrote:
> Michael Ellerman writes:
>
> > Balbir Singh writes:
> >
> >>
> >>
> >>> static void __init radix_init_partition_table(void)
> >>> {
> >>> - unsigned long rts_field;
> >>> + unsigned long rts_field, ptcr;
> >>
> >> I thi
address of the partition table
(ie. the PTCR) which needs to be programmed into the NMMU.
This patch adds a call to OPAL to set the PTCR for the nest mmu in
opal_init().
Signed-off-by: Alistair Popple
---
Differences from v2:
* Rename powernv_set_ptcr() to powernv_set_nmmu_ptcr() as suggested
> Michael the skiboot fix to stop this breaking in mambo has been posted
> (see http://patchwork.ozlabs.org/patch/702564/). Will let you know
> when it has gone upstream.
Upstream in skiboot master as of 9418533911728f6d8bb7aa647033c317772ddb97.
Thanks!
>
> arch/powerpc/include/asm/opal-api.h
NPU2 PHB model.
Signed-off-by: Alistair Popple
---
arch/powerpc/platforms/powernv/pci-ioda.c | 9 -
arch/powerpc/platforms/powernv/pci.c | 7 +++
arch/powerpc/platforms/powernv/pci.h | 1 +
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms
On Fri, 3 Feb 2017 03:20:48 PM Nicholas Piggin wrote:
> On Fri, 3 Feb 2017 00:25:11 +1000
> Nicholas Piggin wrote:
>
> > This goes with the previous NMI IPI series, and a new version of
> > Alistair's opal API I posted to the skiboot list.
>
> And here is the incremental bit that is required for
Thanks Balbir, one question below. I have no way of testing this at present but
it looks ok to me. Thanks!
On Thursday, 14 December 2017 12:10:08 PM AEDT Balbir Singh wrote:
> While reviewing the code I found that the flush assumes all
> pages are of mmu_linear_psize, which is not correct. The pat
On Tuesday, 16 January 2018 3:15:05 PM AEDT Alistair Popple wrote:
> Thanks Balbir, one question below. I have no way of testing this at present
> but
> it looks ok to me. Thanks!
The below are more future optimisations once we can test. So in the meantime:
Acked-by: Alistair Popp
are either
acquired or released together and in order.
Fixes: bbd5ff50afff ("powerpc/powernv/npu-dma: Add explicit flush when sending
an ATSD")
Signed-off-by: Alistair Popple
---
Michael,
This should probalby go to stable as well, although it's bigger than the 100
line limit m
Thanks Mark, this will also fix the lack of cleanup OPAL call in the unlikely
case the kzalloc() fails.
Acked-By: Alistair Popple
On Friday, 9 February 2018 7:20:06 PM AEDT Mark Hairgrove wrote:
> pnv_npu2_init_context wasn't checking the return code from
> __mmu_notifier_r
> > +struct mmio_atsd_reg {
> > + struct npu *npu;
> > + int reg;
> > +};
> > +
>
> Is it just easier to move reg to inside of struct npu?
I don't think so, struct npu is global to all npu contexts where as this is
specific to the given invalidation. We don't have enough registers to assign
e
> > Shouldn't that be enforced with READ_ONCE() then?
Yep, I can add that.
> Good point, although I think the acquire_* function itself may be called
> from a higher layer with the mmap_sem always held. I wonder if we need
> barriers around get and put mmio_atsd_reg.
test_and_set_bit() should im
> @aneesh can you please look at this? @mpe can we pick this up if there
> are no objections?
@mpe any objections to picking this up for this release? Or do you want to wait
for the next one? (there are likely more bugfixes coming for ATS support).
- Alistair
> Balbir Singh
>
are either
acquired or released together and in order.
Fixes: bbd5ff50afff ("powerpc/powernv/npu-dma: Add explicit flush when sending
an ATSD")
Signed-off-by: Alistair Popple
---
v2: Added memory barriers around ->npdev[] and ATSD register aquisition/release
arch/powerpc/platform
> > diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
> > b/arch/powerpc/platforms/powernv/npu-dma.c
> > index 0a253b64ac5f..2fed4b116e19 100644
> > --- a/arch/powerpc/platforms/powernv/npu-dma.c
> > +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> > @@ -726,7 +749,7 @@ struct npu_context *pnv
are either
acquired or released together and in order.
Fixes: bbd5ff50afff ("powerpc/powernv/npu-dma: Add explicit flush when sending
an ATSD")
Signed-off-by: Alistair Popple
---
v2:
- Added memory barriers around ATSD register aquisition/release
- Added compiler barriers ar
Michael,
This won't apply cleanly on top of Balbir's MMIO ATSD Flushing patch
(https://patchwork.ozlabs.org/patch/848343/). I will resend a v4 which applies
cleanly on top of that as the rebase/merge is non-trivial.
- Alistair
On Friday, 2 March 2018 4:18:45 PM AEDT Alistair Po
On Thursday, 8 March 2018 7:22:52 PM AEDT Michael Ellerman wrote:
> Alistair Popple writes:
>
> > Michael,
> >
> > This won't apply cleanly on top of Balbir's MMIO ATSD Flushing patch
> > (https://patchwork.ozlabs.org/patch/848343/). I will resend a v4
I must admit I haven't really looked at the iommu_table_group code in depth so
don't fully understand it, but I was wondering why we don't hit this for NVLink1
as well?
The error that Skiboot is printing is because the requested page size doesn't
match expected so I guess there is a possibility th
concurrent initialisation and destruction for different GPUs. As
npu context creation/destruction is not a performance critical path and the
critical section is not large a single spinlock is used for simplicity.
Signed-off-by: Alistair Popple
---
arch/powerpc/platforms/powernv/npu-dma.c | 51
There is a single npu context per set of callback parameters. Callers
should be prevented from overwriting existing callback values so instead
return an error if different parameters are passed.
Signed-off-by: Alistair Popple
---
arch/powerpc/include/asm/powernv.h | 2 +-
arch/powerpc
given
PID on each GPU.
Signed-off-by: Alistair Popple
---
arch/powerpc/platforms/powernv/npu-dma.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
index 94801d8e7894
and refinement of the value.
Signed-off-by: Alistair Popple
---
arch/powerpc/platforms/powernv/npu-dma.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
index dc34662e9df9
Sorry, forgot to include:
Fixes: 1ab66d1fbada ("powerpc/powernv: Introduce address translation services
for Nvlink2")
Thanks
On Wednesday, 11 April 2018 4:38:54 PM AEST Alistair Popple wrote:
> The pnv_npu2_init_context() and pnv_npu2_destroy_context() functions are
> used
Sorry, forgot to include:
Fixes: 1ab66d1fbada ("powerpc/powernv: Introduce address translation services
for Nvlink2")
Thanks
On Wednesday, 11 April 2018 4:38:55 PM AEST Alistair Popple wrote:
> There is a single npu context per set of callback parameters. Callers
> should b
Sorry, forgot to include:
Fixes: 1ab66d1fbada ("powerpc/powernv: Introduce address translation services
for Nvlink2")
Thanks
On Tuesday, 17 April 2018 7:11:28 PM AEST Alistair Popple wrote:
> The NPU has a limited number of address translation shootdown (ATSD)
> registers
Hi Reza,
On Thu, 6 Oct 2016 01:36:32 PM Reza Arbab wrote:
> Respect the standard dt "status" property when scanning memory nodes in
> early_init_dt_scan_memory(), so that if the node is unavailable, no
> memory will be added.
What happens if a kernel without this patch is booted on a system with
On Wed, 9 Nov 2016 01:01:24 AM Nicholas Piggin wrote:
> Allow platforms to provide an NMI IPI, and wire that to the NMI
> system.
> ---
> arch/powerpc/include/asm/smp.h| 5 +
> arch/powerpc/kernel/smp.c | 21 -
> arch/powerpc/platforms/85xx/smp.
There's one call to pr_warn() in pnv_npu_disable_bypass() that could arguably
be converted to pe_warn(), but we can clean that up later as the patch looks
fine and I'm assuming subsequent patches make use of these.
Reviewed-By: Alistair Popple
On Fri, 29 Apr 2016 18:55:21 Alexey Kar
On Tue, 3 May 2016 15:46:33 Alistair Popple wrote:
> There's one call to pr_warn() in pnv_npu_disable_bypass() that could
arguably
> be converted to pe_warn(), but we can clean that up later as the patch looks
> fine and I'm assuming subsequent patches make use of these.
pu_pe->tce32_table as we always use
> @@ -248,6 +289,10 @@ static int pnv_npu_dma_set_bypass(struct pnv_ioda_pe
*npe)
> if (phb->type != PNV_PHB_NPU || !npe->pdev)
> return -EINVAL;
>
> + rc = pnv_npu_unset_window(npe);
As noted in the commit mess
needed anymore.
Happy to see it go. I'm not too familiar with iommu groups but based on the
code and what you have described to me both here and offline everything looks
good to me. One pretty minor style comment below.
Reviewed-By: Alistair Popple
> While we are here, add TCE cach
>private_data;
> + if (phb->type != PNV_PHB_NPU)
> + return 0;
> +
> + *ptmppe = &phb->ioda.pe_array[pdn->pe_number];
> +
> + return 1;
> +}
> +
> +/*
> + * This returns PE of associated NPU.
> +
against future weak PCI subsystem
functions that may get these names? In other words none of these functions
currently exist as weak PCI subsystem functions and hence aren't called from
the PCI subsystem?
If so this just looks like a simple rename.
Reviewed-By: Alistair Popple
_SEGSIZE representing one DMA32
> segment size. the TCE table size can be calcualted when the page
> has fixed 4KB size. So all the related calculation depends on one
> macro (PNV_IODA1_DMA32_SEGSIZE). No logical changes introduced.
Looks ok to me.
Reviewed-By: Alistair Popple
ments to helper pnv_ioda_setup_pe_res().
> The data type for @rc is changed to "int64_t". Also, argument @hose is
> removed from pnv_ioda_setup_pe() as it can be got from @pe. No functional
> changes introduced.
>
> Signed-off-by: Gavin Shan
Reviewed-By: Alistair Popple
>
On Tue, 3 May 2016 15:41:26 Gavin Shan wrote:
> There are two arrays for IO and M32 segment maps on every PHB.
> The index of the arrays are segment number and the value stored
> in the corresponding element is PE number, indicating the segment
> is assigned to the PE. Initially, all elements in th
I had a quick look at the surrounding code and couldn't see anything obvious
that would result in a behaviour change.
Reviewed-By: Alistair Popple
On Tue, 3 May 2016 15:41:25 Gavin Shan wrote:
> This changes the data type of PE number from "int" to "unsigned int"
301 - 400 of 740 matches
Mail list logo
