* Re: [PATCH v2] powerpc/mm: Fix growth direction for hugepages mmaps with slice
From: Aneesh Kumar K.V @ 2018-01-17 3:19 UTC (permalink / raw)
To: Christophe LEROY, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Scott Wood
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <d5f6060f-3061-dc3c-66f7-3cec05d50169@c-s.fr>
On 01/16/2018 10:18 PM, Christophe LEROY wrote:
>
>
> Le 16/01/2018 à 17:03, Aneesh Kumar K.V a écrit :
>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>
>>> An application running with libhugetlbfs fails to allocate
>>> additional pages to HEAP due to the hugemap being done
>>> inconditionally as topdown mapping:
>>>
>>> mmap(0x10080000, 1572864, PROT_READ|PROT_WRITE,
>>> MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0) = 0x73e80000
>>> [...]
>>> mmap(0x74000000, 1048576, PROT_READ|PROT_WRITE,
>>> MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0x180000) = 0x73d80000
>>> munmap(0x73d80000, 1048576) = 0
>>> [...]
>>> mmap(0x74000000, 1572864, PROT_READ|PROT_WRITE,
>>> MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0x180000) = 0x73d00000
>>> munmap(0x73d00000, 1572864) = 0
>>> [...]
>>> mmap(0x74000000, 1572864, PROT_READ|PROT_WRITE,
>>> MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0x180000) = 0x73d00000
>>> munmap(0x73d00000, 1572864) = 0
>>> [...]
>>>
>>
>> Can you explain the failure details above. I am not sure I understand
>> what to read from the above output.
>
> libhugetlbfs first requests an area of size 1.5Mbytes, at address
> 0x10080000
> mmap() returns an area at address 0x73e80000
>
> Then libhugetlbfs requests an additional area on top of that, ie at
> address 0x74000000, to expand the heap.
> But mmap() returns an area at address 0x73d80000, ie under the previous
> area.
>
Can you share the test details?. Why does it not fail on book3s64? We
use topdown search with book3s64.
> This is not the behaviour when using the generic (ie without mm_slices)
> hugepages code, and this is not what libhugetlbfs expects for expending
> the heap.
>
>
-aneesh
^ permalink raw reply
* Re: [PATCH v6 03/24] mm: Dont assume page-table invariance during faults
From: Andi Kleen @ 2018-01-17 3:04 UTC (permalink / raw)
To: Laurent Dufour
Cc: paulmck, peterz, akpm, kirill, 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: <1515777968-867-4-git-send-email-ldufour@linux.vnet.ibm.com>
Laurent Dufour <ldufour@linux.vnet.ibm.com> writes:
> From: Peter Zijlstra <peterz@infradead.org>
>
> One of the side effects of speculating on faults (without holding
> mmap_sem) is that we can race with free_pgtables() and therefore we
> cannot assume the page-tables will stick around.
>
> Remove the reliance on the pte pointer.
This needs a lot more explanation. So why is this code not needed with
SPF only?
-Andi
^ permalink raw reply
* [PATCH 5/5] powerpc/ftw: Document FTW API/usage
From: Sukadev Bhattiprolu @ 2018-01-17 2:50 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
In-Reply-To: <1516157443-17716-1-git-send-email-sukadev@linux.vnet.ibm.com>
Document the usage of the VAS Fast thread-wakeup API and add an entry in
MAINTAINERS file.
Thanks for input/comments from Benjamin Herrenschmidt, Michael Neuling,
Michael Ellerman, Robert Blackmore, Ian Munsie, Haren Myneni and Paul
Mackerras.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
Changelog[v2]
- [Michael Neuling] Update API to use a single, VAS_FTW_SEUTP ioctl
rather than two ioctls.
- [Michael Neuling] Drop "nx" from name "nx-ftw".
---
Documentation/powerpc/ftw-api.txt | 283 ++++++++++++++++++++++++++++++++++++++
MAINTAINERS | 8 ++
2 files changed, 291 insertions(+)
create mode 100644 Documentation/powerpc/ftw-api.txt
diff --git a/Documentation/powerpc/ftw-api.txt b/Documentation/powerpc/ftw-api.txt
new file mode 100644
index 0000000..a107628
--- /dev/null
+++ b/Documentation/powerpc/ftw-api.txt
@@ -0,0 +1,283 @@
+Virtual Accelerator Switchboard and Fast Thread-Wakeup API
+
+ Power9 processor supports a hardware subystem known as the Virtual
+ Accelerator Switchboard (VAS) which allows two entities in the Power9
+ system to efficiently exchange messages. Messages must be formatted as
+ Coprocessor Request Blocks (CRB) and be submitted using the COPY/PASTE
+ instructions (new in Power9).
+
+ Usage of VAS depends on the entities exchanging the messages and
+ currently two usages have been identified.
+
+ First usage of VAS, referred to as VAS/NX involves a software thread
+ submitting data compression requests to a co-processor (hardware/nest
+ accelerator) aka NX engine. This usage is not yet available to user
+ applications.
+
+ Alternatively, VAS can be used by two software threads to efficiently
+ exchange messages. Initially, this mechanism is intended to wake up a
+ waiting thread quickly - i.e "fast thread wake-up (FTW)". This document
+ describes the user API for this VAS/FTW mechanism.
+
+ Application access to the FTW mechanism is provided through the FTW
+ device node (/dev/ftw) implemented by the FTW device driver.
+
+ A multi-threaded software processes that intends to use the FTW
+ mechanism must first setup a channel (consisting of a pair of VAS
+ windows) for the waiting and waking threads to communicate. The
+ channel is set up by opening the FTW device and issuing the FTW_SETUP
+ ioctl. Upon successful return from the ioctl, the waiting side of
+ channel is complete and a thread can issue the "Wait" instruction
+ to wait for an event.
+
+ After the successful return from the FTW_SETUP ioctl, the waking
+ thread must use mmap() system call on the same file descriptor and
+ obtain a virtual address known as the "paste address".
+
+ Once the mmap() call succeeds the setup of "waking" side of the channel
+ is complete. To wake up a waiting thread, the waking thread should use
+ the "COPY" and "PASTE" instructions to write a zero-filled CRB to the
+ paste-address.
+
+ The wait and wake up operations can be repeated as long as the paste
+ address and the FTW file descriptor are valid (i.e until munmap() of
+ the paste address or a close() of the FTW fd).
+
+1. FTW Device Node
+
+ There is one /dev/ftw node in the system and it provides access to the
+ VAS/FTW functionality.
+
+ The only valid operations (system calls) on the FTW node are:
+
+ - open() the device for read and write.
+
+ - issue the FTW_SETUP ioctl to set up a channel.
+
+ - mmap() the file descriptor
+
+ - close the device node.
+
+ Other file operations on the FTW node are undefined.
+
+ Note that the COPY and PASTE operations go directly to the hardware
+ and do not involve system calls or go through the FTW device.
+
+ Although a system may have several instances of the VAS in the system
+ (typically, one per P9 chip) there is just one FTW device node in
+ the system.
+
+ When the FTW device node is opened, the kernel assigns a suitable
+ instance of VAS to the process. Kernel will make a best-effort attempt
+ to assign an optimal instance of VAS for the process - based on the CPU/
+ chip that the process is running on. In the initial release, the kernel
+ does not support migrating the VAS instance if the process migrates from
+ a CPU on one chip to a CPU on another chip.
+
+ Applications may chose a specific instance of the VAS using the 'vas_id'
+ field in the FTW_SETUP ioctl as detailed below.
+
+2. Open FTW node
+
+ The device should be opened for read and write. No special privileges
+ are needed to open the device. The device may be opened multiple times.
+
+ Each open() of the FTW device is associated with one channel of
+ communication. There is a system-wide limit (currently 64K windows per
+ chip and since some are reserved for hardware, there are about 32K
+ channels per chip). If no more channels are available, the open() system
+ call will fail.
+
+ See open(2) system call man pages for other details such as return
+ values, error codes and restrictions.
+
+3. Setup a communication channel (FTW_SETUP ioctl)
+
+ A process that intends to use the Fast Thread-wakeup mechanism must
+ first setup a channel by issuing the FTW_SETUP ioctl.
+
+ #include <misc/ftw.h>
+
+ struct ftw_setup_attr ftwattr;
+
+ rc = ioctl(fd, FTW_SETUP, &ftwattr);
+
+ The attributes of ftwattr are as follows:
+
+ struct ftw_setup_attr {
+ int16_t version;
+ int16_t vas_id;
+ uint32_t reserved;
+
+ int64_t reserved1;
+ int64_t flags;
+ int64_t reserved2;
+ };
+
+ The version field identifies the version of the API and must currently
+ be set to 1.
+
+ The vas_id field identifies a specific instance of the VAS that the
+ application wishes to access. See section on VAS ID below.
+
+ The reserved fields must all be set to zeroes.
+
+ The flags field specifies additional attributes to the channel. The
+ only valid bit in the flags for Fast thread-wakeup usage are:
+
+ FTW_FLAGS_PIN_WINDOW if set, indicates that the channel should be
+ pinned in cache. This flag is restricted
+ to privileged users. See Pinning windows
+ below.
+
+ All the other bits in the flags field must be set to 0.
+
+ Return value:
+
+ The FTW_SETUP ioctl returns 0 on success. On error, it returns -1
+ and sets the errno variable to indicate the error.
+
+ Error codes:
+
+ EINVAL version is invalid
+
+ EINVAL vas_id is invalid
+
+ EINVAL fd does not refer to a valid VAS device.
+
+ ENOSPC System has too many active channels (windows) open,
+
+ EPERM FTW_FLAGS_PIN_WINDOW is set in 'flags' field and process
+ is not privileged.
+
+ EINVAL reserved fields are not set to 0.
+
+ See the ioctl(2) man page for more details, error codes and restrictions.
+
+4. mmap() FTW device fd
+
+ The mmap() system call for a FTW device fd returns a "paste address"
+ that the application can use to COPY/PASTE a CRB to the waiting thread.
+
+ paste_addr = mmap(NULL, size, prot, flags, fd, offset);
+
+ Only restrictions on mmap for a FTW device fd are:
+
+ - size parameter should be one page size
+
+ - offset parameter should be 0ULL.
+
+ Refer to mmap(2) man page for additional details/restrictions.
+
+ In addition to the error conditions listed on the mmap(2) man page,
+ mmap() can also fail with one of following error codes:
+
+ EINVAL fd is not associated with an open channel (window)
+ (i.e mmap() does not follow a successful call to the
+ FTW_SETUP ioctl).
+
+ EINVAL offset field is not 0ULL.
+
+
+5. VAS ID
+
+ A system may have several instances of VAS in the hardware, typically
+ one per POWER 9 chip. The choice of a specific instance of VAS can have
+ significant impact on the performance, specially if the application
+ migrates from one CPU to another. Applications can specify a vas_id
+ using the FTW_SETUP ioctl and should be prudent in choosing an
+ instance of VAS.
+
+ The vas_id for each instance of VAS is listed as the device tree
+ property 'ibm,vas-id'. Determining the specific vas_id to use for
+ a specific application thread is beyond the scope of this API.
+
+ If the application has no preference, the vas_id field may be set to
+ -1 and the kernel will choose a suitable instance of the VAS engine.
+
+6. COPY/PASTE operations:
+
+ Applications should use the COPY and PASTE instructions defined in
+ the RFC to copy/paste the CRB. For VAS/FTW usage, the contents of
+ CRB, are ignored and can be zero, but CRB should point to a valid buffer
+
+7. Interrupt completion and signal handling
+
+ No VAS-specific signals will be generated to the application threads
+ with the VAS/FTW usage.
+
+8. Example/Proposed usage of the VAS/FTW API
+
+ In the following example we use two threads that use the VAS/FTW API.
+ Thread T1 sets up the channel and uses the WAIT instruction to wait for
+ an event. Thread T2 uses copy/paste instructions to wake up T1.
+ Note that the pthread_cond_wait() calls must be in a loop for spurious
+ wake ups, but are simplified here.
+
+ Common interfaces:
+
+ static bool paste_done;
+
+ #define WAIT .long (0x7C00003C)
+
+ static inline int do_wait(void)
+ {
+ __asm__ __volatile(stringify_in_c(WAIT)";");
+ }
+
+ /*
+ * Check if paste_done is true
+ */
+ static bool is_paste_done(void)
+ {
+ return __sync_bool_compare_and_swap(&paste_done, 1, 0);
+
+ }
+
+ /*
+ * Set paste_done to true
+ */
+ static inline void set_paste_done(void)
+ {
+ __sync_bool_compare_and_swap(&paste_done, 0, 1);
+ }
+
+
+ int fd = -1; // global, visible to both T1 and T2
+
+ Thread T1:
+
+ struct ftw_setup_attr ftwattr;
+
+ fd = open("/dev/ftw", O_RDWR);
+
+ memset(&rxattr, 0, sizeof(rxattr));
+ ftwattr.version = 1;
+ ftwattr.vas_id = -1;
+
+ rc = ioctl(fd, FTW_SETUP, &ftwattr);
+
+ /* Tell T2 that waiter side of channel is ready */
+ pthread_cond_signal(&rx_win_ready);
+
+ /* Rx set up done */
+
+ /* later, wait for an event to occur */
+
+ while(!is_paste_done())
+ do_wait();
+
+ Thread T2:
+
+ /* Wait for waiter side of channel to be set up first */
+ pthread_cond_wait(&rx_win_ready);
+
+ prot = PROT_READ|PROT_WRITE;
+ paste_addr = mmap(NULL, 4096, prot, MAP_SHARED, fd, 0ULL);
+
+ /* Tx setup done */
+
+ /* later ... */
+
+ set_paste_done(); /* ... event occurred */
+ write_empty_crb(paste_addr); /* wake up T1 */
diff --git a/MAINTAINERS b/MAINTAINERS
index 1899480..cb4b0f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4244,6 +4244,14 @@ L: linux-i2c@vger.kernel.org
S: Maintained
F: drivers/i2c/busses/i2c-diolan-u2c.c
+FAST THREAD-WAKEUP DRIVER
+M: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
+L: linuxppc-dev@lists.ozlabs.org
+S: Maintained
+F: drivers/misc/ftw/
+F: include/uapi/misc/ftw.h
+F: Documentation/powerpc/ftw-api.txt
+
FILESYSTEM DIRECT ACCESS (DAX)
M: Matthew Wilcox <mawilcox@microsoft.com>
M: Ross Zwisler <ross.zwisler@linux.intel.com>
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] powerpc/ftw: Add a couple of trace points
From: Sukadev Bhattiprolu @ 2018-01-17 2:50 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
In-Reply-To: <1516157443-17716-1-git-send-email-sukadev@linux.vnet.ibm.com>
Add a couple of trace points in the FTW driver
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
drivers/misc/ftw/ftw-trace.h | 75 ++++++++++++++++++++++++++++++++++++++++++++
drivers/misc/ftw/ftw.c | 6 ++++
2 files changed, 81 insertions(+)
create mode 100644 drivers/misc/ftw/ftw-trace.h
diff --git a/drivers/misc/ftw/ftw-trace.h b/drivers/misc/ftw/ftw-trace.h
new file mode 100644
index 0000000..0d96046
--- /dev/null
+++ b/drivers/misc/ftw/ftw-trace.h
@@ -0,0 +1,75 @@
+/*
+ * 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.
+ */
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM ftw
+
+#if !defined(_FTW_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
+
+#define _FTW_TRACE_H
+#include <linux/tracepoint.h>
+#include <linux/sched.h>
+
+TRACE_EVENT( ftw_open_event,
+
+ TP_PROTO(struct task_struct *tsk,
+ int instid),
+
+ TP_ARGS(tsk, instid),
+
+ TP_STRUCT__entry(
+ __field(struct task_struct *, tsk)
+ __field(int, instid)
+ __field(int, pid)
+ ),
+
+ TP_fast_assign(
+ __entry->pid = tsk->pid;
+ __entry->instid = instid;
+ ),
+
+ TP_printk("pid=%d, inst=%d", __entry->pid, __entry->instid)
+);
+
+TRACE_EVENT( ftw_mmap_event,
+
+ TP_PROTO(struct task_struct *tsk,
+ int instid,
+ unsigned long paste_addr,
+ unsigned long vma_start),
+
+ TP_ARGS(tsk, instid, paste_addr, vma_start),
+
+ TP_STRUCT__entry(
+ __field(struct task_struct *, tsk)
+ __field(int, pid)
+ __field(int, instid)
+ __field(unsigned long, paste_addr)
+ __field(unsigned long, vma_start)
+ ),
+
+ TP_fast_assign(
+ __entry->pid = tsk->pid;
+ __entry->instid = instid;
+ __entry->paste_addr = paste_addr;
+ __entry->vma_start = vma_start;
+ ),
+
+ TP_printk(
+ "pid=%d, inst=%d, pasteaddr=0x%16lx, vma_start=0x%16lx",
+ __entry->pid, __entry->instid, __entry->paste_addr,
+ __entry->vma_start)
+);
+
+#endif /* _FTW_TRACE_H */
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_FILE ftw-trace
+#include <trace/define_trace.h>
diff --git a/drivers/misc/ftw/ftw.c b/drivers/misc/ftw/ftw.c
index 6fcb4e2..a01c9e6 100644
--- a/drivers/misc/ftw/ftw.c
+++ b/drivers/misc/ftw/ftw.c
@@ -21,6 +21,9 @@
#include <asm/vas.h>
#include <uapi/misc/ftw.h>
+#define CREATE_TRACE_POINTS
+#include "ftw-trace.h"
+
/*
* FTW is a device driver used to provide user space access to the
* Core-to-Core aka Fast Thread Wakeup (FTW) functionality provided by
@@ -81,6 +84,8 @@ static int ftw_open(struct inode *inode, struct file *fp)
fp->private_data = instance;
+ trace_ftw_open_event(current, instance->id);
+
return 0;
}
@@ -234,6 +239,7 @@ static int ftw_mmap(struct file *fp, struct vm_area_struct *vma)
pr_devel("paste addr %llx at %lx, rc %d\n", paste_addr, vma->vm_start,
rc);
+ trace_ftw_mmap_event(current, instance->id, paste_addr, vma->vm_start);
set_thread_uses_vas();
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] powerpc/ftw: Implement a simple FTW driver
From: Sukadev Bhattiprolu @ 2018-01-17 2:50 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
In-Reply-To: <1516157443-17716-1-git-send-email-sukadev@linux.vnet.ibm.com>
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
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index f1a5c23..a9b161f 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -508,4 +508,5 @@ source "drivers/misc/mic/Kconfig"
source "drivers/misc/genwqe/Kconfig"
source "drivers/misc/echo/Kconfig"
source "drivers/misc/cxl/Kconfig"
+source "drivers/misc/ftw/Kconfig"
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 5ca5f64..338668c 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
+obj-$(CONFIG_PPC_FTW) += ftw/
obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
obj-$(CONFIG_PCI_ENDPOINT_TEST) += pci_endpoint_test.o
diff --git a/drivers/misc/ftw/Kconfig b/drivers/misc/ftw/Kconfig
new file mode 100644
index 0000000..5454d40
--- /dev/null
+++ b/drivers/misc/ftw/Kconfig
@@ -0,0 +1,16 @@
+
+config PPC_FTW
+ tristate "IBM Fast Thread-Wakeup (FTW)"
+ depends on PPC_VAS
+ default n
+ help
+ This enables support for IBM Fast Thread-Wakeup driver.
+
+ The FTW driver allows applications to utilize a low overhead
+ core-to-core wake up mechansim in the IBM Virtual Accelerator
+ Switchboard (VAS) to improve performance.
+
+ VAS adapters are found in POWER9 based systems and are required
+ for the FTW driver to be operational.
+
+ If unsure, say N.
diff --git a/drivers/misc/ftw/Makefile b/drivers/misc/ftw/Makefile
new file mode 100644
index 0000000..2cfe566
--- /dev/null
+++ b/drivers/misc/ftw/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+ccflags-y := $(call cc-disable-warning, unused-const-variable)
+ccflags-$(CONFIG_PPC_WERROR) += -Werror
+obj-$(CONFIG_PPC_FTW) += ftw.o
diff --git a/drivers/misc/ftw/ftw.c b/drivers/misc/ftw/ftw.c
new file mode 100644
index 0000000..6fcb4e2
--- /dev/null
+++ b/drivers/misc/ftw/ftw.c
@@ -0,0 +1,346 @@
+/*
+ * 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.
+ */
+#define pr_fmt(fmt) "ftw: " fmt
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/cdev.h>
+#include <linux/fs.h>
+#include <linux/mm.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/pfn_t.h>
+#include <asm/switch_to.h>
+#include <asm/vas.h>
+#include <uapi/misc/ftw.h>
+
+/*
+ * FTW is a device driver used to provide user space access to the
+ * Core-to-Core aka Fast Thread Wakeup (FTW) functionality provided by
+ * the Virtual Accelerator Subsystem (VAS) in POWER9 systems. See also
+ * arch/powerpc/platforms/powernv/vas*.
+ *
+ * The driver creates the device /dev/ftw that can be used as follows:
+ *
+ * fd = open("/dev/ftw", O_RDWR);
+ * rc = ioctl(fd, FTW_SETUP, &attr);
+ * paste_addr = mmap(NULL, PAGE_SIZE, prot, MAP_SHARED, fd, 0ULL).
+ * vas_copy(&crb, 0, 1);
+ * vas_paste(paste_addr, 0, 1);
+ *
+ * where "vas_copy" and "vas_paste" are defined in copy-paste.h.
+ */
+
+static char *ftw_dev_name = "ftw";
+static atomic_t ftw_instid = ATOMIC_INIT(0);
+
+/*
+ * Wrapper object for the ftw device - there is just one instance of
+ * this node in the system.
+ */
+struct ftw_dev {
+ struct cdev cdev;
+ struct device *device;
+ char *name;
+ dev_t devt;
+ struct class *class;
+} ftw_device;
+
+/*
+ * One instance per open of a ftw device. Each ftw_instance is
+ * associated with a VAS window after the caller issues FTW_SETUP
+ * ioctl.
+ */
+struct ftw_instance {
+ int id;
+ struct vas_window *rxwin;
+ struct vas_window *txwin;
+};
+
+static char *ftw_devnode(struct device *dev, umode_t *mode)
+{
+ return kasprintf(GFP_KERNEL, "%s", dev_name(dev));
+}
+
+static int ftw_open(struct inode *inode, struct file *fp)
+{
+ struct ftw_instance *instance;
+
+ instance = kzalloc(sizeof(*instance), GFP_KERNEL);
+ if (!instance)
+ return -ENOMEM;
+
+ instance->id = atomic_inc_return(&ftw_instid);
+
+ fp->private_data = instance;
+
+ return 0;
+}
+
+static int validate_ftw_setup_attr(struct ftw_setup_attr *uattr)
+{
+ if (uattr->version != 1 || uattr->reserved || uattr->reserved1 ||
+ uattr->reserved2)
+ return -EINVAL;
+
+ if (uattr->flags & ~FTW_FLAGS_PIN_WINDOW)
+ return -EINVAL;
+
+ if (uattr->flags & FTW_FLAGS_PIN_WINDOW && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ return 0;
+}
+
+static int ftw_ioc_ftw_setup(struct file *fp, unsigned long arg)
+{
+ int rc, vasid, cop;
+ struct vas_rx_win_attr rxattr;
+ struct vas_tx_win_attr txattr;
+ struct ftw_setup_attr uattr;
+ void __user *uptr = (void *)arg;
+ struct vas_window *rxwin, *txwin;
+ struct ftw_instance *instance = fp->private_data;
+
+ rc = copy_from_user(&uattr, uptr, sizeof(uattr));
+ if (rc) {
+ pr_debug("copy_from_user() returns %d\n", rc);
+ return -EFAULT;
+ }
+
+ rc = validate_ftw_setup_attr(&uattr);
+ if (rc)
+ return rc;
+
+ cop = VAS_COP_TYPE_FTW;
+ rc = set_thread_tidr(current);
+ if (rc)
+ return rc;
+
+ vasid = uattr.vas_id;
+
+ vas_init_rx_win_attr(&rxattr, cop);
+ rxattr.lnotify_lpid = mfspr(SPRN_LPID);
+
+ /*
+ * Only caller can own the window for now. Not sure if there is need
+ * for process P1 to make P2 the owner of a window. If so, we need to
+ * find P2, make sure we have permissions, get a reference etc.
+ */
+ rxattr.lnotify_pid = mfspr(SPRN_PID);
+ rxattr.lnotify_tid = mfspr(SPRN_TIDR);
+
+ rxwin = vas_rx_win_open(vasid, cop, &rxattr);
+ if (IS_ERR(rxwin)) {
+ pr_debug("vas_rx_win_open() failed, %ld\n", PTR_ERR(rxwin));
+ return PTR_ERR(rxwin);
+ }
+
+ vas_init_tx_win_attr(&txattr, cop);
+
+ txattr.lpid = mfspr(SPRN_LPID);
+ txattr.pidr = mfspr(SPRN_PID);
+ txattr.pid = task_pid_nr(current);
+ txattr.pswid = vas_win_id(rxwin);
+
+ txwin = vas_tx_win_open(vasid, cop, &txattr);
+ if (IS_ERR(txwin)) {
+ pr_debug("vas_tx_win_open() failed, %ld\n", PTR_ERR(txwin));
+ rc = PTR_ERR(txwin);
+ goto close_rxwin;
+ }
+
+ instance->rxwin = rxwin;
+ instance->txwin = txwin;
+
+ return 0;
+
+close_rxwin:
+ vas_win_close(rxwin);
+ return rc;
+}
+
+static int ftw_release(struct inode *inode, struct file *fp)
+{
+ struct ftw_instance *instance;
+
+ instance = fp->private_data;
+
+ if (instance->txwin)
+ vas_win_close(instance->txwin);
+ if (instance->rxwin)
+ vas_win_close(instance->rxwin);
+ /*
+ * TODO We don't know here if user has other receive windows
+ * open, and can't really call clear_thread_tidr(). So,
+ * once the process calls set_thread_tidr(), the TIDR value
+ * sticks around until process exits, potentially resulting
+ * in an unnecessary copy in restore_sprs() when even the
+ * process has closed its last window.
+ */
+
+ instance->rxwin = instance->txwin = NULL;
+
+ kfree(instance);
+ fp->private_data = NULL;
+ atomic_dec(&ftw_instid);
+
+ return 0;
+}
+
+static int ftw_mmap(struct file *fp, struct vm_area_struct *vma)
+{
+ int rc;
+ pgprot_t prot;
+ u64 paste_addr;
+ unsigned long pfn;
+ struct ftw_instance *instance = fp->private_data;
+
+ if ((vma->vm_end - vma->vm_start) > PAGE_SIZE) {
+ pr_debug("size 0x%zx, PAGE_SIZE 0x%zx\n",
+ (vma->vm_end - vma->vm_start), PAGE_SIZE);
+ return -EINVAL;
+ }
+
+ /* Ensure instance has an open send window */
+ if (!instance->txwin) {
+ pr_debug("No send window open?\n");
+ return -EINVAL;
+ }
+
+ paste_addr = vas_win_paste_addr(instance->txwin);
+ pfn = paste_addr >> PAGE_SHIFT;
+
+ /* flags, page_prot from cxl_mmap(), except we want cachable */
+ vma->vm_flags |= VM_IO | VM_PFNMAP;
+ vma->vm_page_prot = pgprot_cached(vma->vm_page_prot);
+
+ /*
+ * We must disable page faults when emulating the paste
+ * instruction. To ensure that the page associated with
+ * the paste address is in memory, mark it dirty.
+ */
+ prot = __pgprot(pgprot_val(vma->vm_page_prot) | _PAGE_DIRTY);
+
+ rc = remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
+ vma->vm_end - vma->vm_start, prot);
+
+ pr_devel("paste addr %llx at %lx, rc %d\n", paste_addr, vma->vm_start,
+ rc);
+
+ set_thread_uses_vas();
+
+ return rc;
+}
+
+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;
+ }
+}
+
+const struct file_operations ftw_fops = {
+ .owner = THIS_MODULE,
+ .open = ftw_open,
+ .release = ftw_release,
+ .mmap = ftw_mmap,
+ .unlocked_ioctl = ftw_ioctl,
+};
+
+
+int ftw_file_init(void)
+{
+ int rc;
+ dev_t devno;
+
+ rc = alloc_chrdev_region(&ftw_device.devt, 1, 1, "ftw");
+ if (rc) {
+ pr_debug("Unable to allocate ftw major number: %i\n", rc);
+ return rc;
+ }
+
+ pr_devel("device allocated, dev [%i,%i]\n",
+ MAJOR(ftw_device.devt), MINOR(ftw_device.devt));
+
+ ftw_device.class = class_create(THIS_MODULE, "ftw");
+ if (IS_ERR(ftw_device.class)) {
+ pr_debug("Unable to create FTW class\n");
+ rc = PTR_ERR(ftw_device.class);
+ goto err;
+ }
+ ftw_device.class->devnode = ftw_devnode;
+
+ cdev_init(&ftw_device.cdev, &ftw_fops);
+
+ devno = MKDEV(MAJOR(ftw_device.devt), 0);
+ if (cdev_add(&ftw_device.cdev, devno, 1)) {
+ pr_debug("cdev_add() failed\n");
+ goto err;
+ }
+
+ ftw_device.device = device_create(ftw_device.class, NULL,
+ devno, NULL, ftw_dev_name, MINOR(devno));
+ if (IS_ERR(ftw_device.device)) {
+ pr_debug("Unable to create ftw-%d\n", MINOR(devno));
+ goto err;
+ }
+
+ pr_devel("Added dev [%d,%d]\n", MAJOR(devno), MINOR(devno));
+
+ return 0;
+
+err:
+ unregister_chrdev_region(ftw_device.devt, 1);
+ return rc;
+}
+
+void ftw_file_exit(void)
+{
+ dev_t devno;
+
+ cdev_del(&ftw_device.cdev);
+ devno = MKDEV(MAJOR(ftw_device.devt), MINOR(ftw_device.devt));
+ device_destroy(ftw_device.class, devno);
+
+ class_destroy(ftw_device.class);
+ unregister_chrdev_region(ftw_device.devt, 1);
+}
+
+int __init ftw_init(void)
+{
+ int rc;
+
+ rc = ftw_file_init();
+ if (rc)
+ return rc;
+
+ pr_info("Device initialized\n");
+
+ return 0;
+}
+
+void __init ftw_exit(void)
+{
+ pr_devel("Device exiting\n");
+ ftw_file_exit();
+}
+
+module_init(ftw_init);
+module_exit(ftw_exit);
+
+MODULE_DESCRIPTION("IBM NX Fast Thread Wakeup Device");
+MODULE_AUTHOR("Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>");
+MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] powerpc/ftw: Define FTW_SETUP ioctl API
From: Sukadev Bhattiprolu @ 2018-01-17 2:50 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
In-Reply-To: <1516157443-17716-1-git-send-email-sukadev@linux.vnet.ibm.com>
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)
+
+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 */
--
2.7.4
^ permalink raw reply related
* [PATCH 1/5] powerpc/vas: Remove a stray line in Makefile
From: Sukadev Bhattiprolu @ 2018-01-17 2:50 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
In-Reply-To: <1516157443-17716-1-git-send-email-sukadev@linux.vnet.ibm.com>
Remove a bogus line from arch/powerpc/platforms/powernv/Makefile that
was added by commit ece4e51 ("powerpc/vas: Export HVWC to debugfs").
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
index 3732118..ca94488 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -16,4 +16,3 @@ obj-$(CONFIG_OPAL_PRD) += opal-prd.o
obj-$(CONFIG_PERF_EVENTS) += opal-imc.o
obj-$(CONFIG_PPC_MEMTRACE) += memtrace.o
obj-$(CONFIG_PPC_VAS) += vas.o vas-window.o vas-debug.o
-obj-$(CONFIG_PPC_FTW) += nx-ftw.o
--
2.7.4
^ permalink raw reply related
* [PATCH 0/5] Implement FTW driver
From: Sukadev Bhattiprolu @ 2018-01-17 2:50 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
The Virtual Accelerator Switchboard (VAS) subsystem in the POWER9 processor
provides a low latency Core-to-core wakeup" mechanism which allows a thread
on one core the processor to efficiently send a message to a thread waiting
on another core.
This Fast thread-wakeup (FTW) driver provides user space applications an
interface to the Core-to-core wakeup mechanism. The FTW driver uses the
"external" interfaces provided by the VAS driver to interact with the VAS
hardware.
PATCH 5/5 documents the API.
The ftw-next branch on my github has some initial test cases for the
driver:
https://github.com/sukadev/linux/tree/ftw-next
Thanks to input from Ben Herrenschmidt, Michael Ellerman, Michael
Neuling and Robert Blackmore.
Sukadev Bhattiprolu (5):
powerpc/vas: Remove a stray line in Makefile
powerpc/ftw: Define FTW_SETUP ioctl API
powerpc/ftw: Implement a simple FTW driver
powerpc/ftw: Add a couple of trace points
powerpc/ftw: Document FTW API/usage
Documentation/powerpc/ftw-api.txt | 283 +++++++++++++++++++++++++
MAINTAINERS | 8 +
arch/powerpc/platforms/powernv/Makefile | 1 -
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile | 1 +
drivers/misc/ftw/Kconfig | 16 ++
drivers/misc/ftw/Makefile | 4 +
drivers/misc/ftw/ftw-trace.h | 75 +++++++
drivers/misc/ftw/ftw.c | 352 ++++++++++++++++++++++++++++++++
include/uapi/misc/ftw.h | 31 +++
10 files changed, 771 insertions(+), 1 deletion(-)
create mode 100644 Documentation/powerpc/ftw-api.txt
create mode 100644 drivers/misc/ftw/Kconfig
create mode 100644 drivers/misc/ftw/Makefile
create mode 100644 drivers/misc/ftw/ftw-trace.h
create mode 100644 drivers/misc/ftw/ftw.c
create mode 100644 include/uapi/misc/ftw.h
--
2.7.4
^ permalink raw reply
* [PATCH 1/1] powerpc/vas: Add a couple of trace points
From: Sukadev Bhattiprolu @ 2018-01-17 1:59 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
Add a couple of trace points in the VAS driver.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/vas-trace.h | 112 ++++++++++++++++++++++++++++
arch/powerpc/platforms/powernv/vas-window.c | 9 +++
2 files changed, 121 insertions(+)
create mode 100644 arch/powerpc/platforms/powernv/vas-trace.h
diff --git a/arch/powerpc/platforms/powernv/vas-trace.h b/arch/powerpc/platforms/powernv/vas-trace.h
new file mode 100644
index 0000000..c937191
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/vas-trace.h
@@ -0,0 +1,112 @@
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM vas
+
+#if !defined(_VAS_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
+
+#define _VAS_TRACE_H
+#include <linux/tracepoint.h>
+#include <linux/sched.h>
+#include <asm/vas.h>
+
+TRACE_EVENT( vas_rx_win_open,
+
+ TP_PROTO(struct task_struct *tsk,
+ int vasid,
+ int cop,
+ struct vas_rx_win_attr *rxattr),
+
+ TP_ARGS(tsk, vasid, cop, rxattr),
+
+ TP_STRUCT__entry(
+ __field(struct task_struct *, tsk)
+ __field(int, pid)
+ __field(int, cop)
+ __field(int, vasid)
+ __field(struct vas_rx_win_attr *, rxattr)
+ __field(int, lnotify_lpid)
+ __field(int, lnotify_pid)
+ __field(int, lnotify_tid)
+ ),
+
+ TP_fast_assign(
+ __entry->pid = tsk->pid;
+ __entry->vasid = vasid;
+ __entry->cop = cop;
+ __entry->lnotify_lpid = rxattr->lnotify_lpid;
+ __entry->lnotify_pid = rxattr->lnotify_pid;
+ __entry->lnotify_tid = rxattr->lnotify_tid;
+ ),
+
+ TP_printk("pid=%d, vasid=%d, cop=%d, lpid=%d, pid=%d, tid=%d",
+ __entry->pid, __entry->vasid, __entry->cop,
+ __entry->lnotify_lpid, __entry->lnotify_pid,
+ __entry->lnotify_tid)
+);
+
+TRACE_EVENT( vas_tx_win_open,
+
+ TP_PROTO(struct task_struct *tsk,
+ int vasid,
+ int cop,
+ struct vas_tx_win_attr *txattr),
+
+ TP_ARGS(tsk, vasid, cop, txattr),
+
+ TP_STRUCT__entry(
+ __field(struct task_struct *, tsk)
+ __field(int, pid)
+ __field(int, cop)
+ __field(int, vasid)
+ __field(struct vas_tx_win_attr *, txattr)
+ __field(int, lpid)
+ __field(int, pidr)
+ ),
+
+ TP_fast_assign(
+ __entry->pid = tsk->pid;
+ __entry->vasid = vasid;
+ __entry->cop = cop;
+ __entry->lpid = txattr->lpid;
+ __entry->pidr = txattr->pidr;
+ ),
+
+ TP_printk("pid=%d, vasid=%d, cop=%d, lpid=%d, pidr=%d",
+ __entry->pid, __entry->vasid, __entry->cop,
+ __entry->lpid, __entry->pidr)
+);
+
+TRACE_EVENT( vas_paste_crb,
+
+ TP_PROTO(struct task_struct *tsk,
+ struct vas_window *win),
+
+ TP_ARGS(tsk, win),
+
+ TP_STRUCT__entry(
+ __field(struct task_struct *, tsk)
+ __field(struct vas_window *, win)
+ __field(int, pid)
+ __field(int, vasid)
+ __field(int, winid)
+ __field(unsigned long, paste_kaddr)
+ ),
+
+ TP_fast_assign(
+ __entry->pid = tsk->pid;
+ __entry->vasid = win->vinst->vas_id;
+ __entry->winid = win->winid;
+ __entry->paste_kaddr = (unsigned long)win->paste_kaddr
+ ),
+
+ TP_printk("pid=%d, vasid=%d, winid=%d, paste_kaddr=0x%016lx\n",
+ __entry->pid, __entry->vasid, __entry->winid,
+ __entry->paste_kaddr)
+);
+
+#endif /* _VAS_TRACE_H */
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_FILE vas-trace
+#include <trace/define_trace.h>
diff --git a/arch/powerpc/platforms/powernv/vas-window.c b/arch/powerpc/platforms/powernv/vas-window.c
index 2b3eb01..6b2de9e 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -21,6 +21,9 @@
#include "vas.h"
#include "copy-paste.h"
+#define CREATE_TRACE_POINTS
+#include "vas-trace.h"
+
/*
* Compute the paste address region for the window @window using the
* ->paste_base_addr and ->paste_win_id_shift we got from device tree.
@@ -880,6 +883,8 @@ struct vas_window *vas_rx_win_open(int vasid, enum vas_cop_type cop,
struct vas_winctx winctx;
struct vas_instance *vinst;
+ trace_vas_rx_win_open(current, vasid, cop, rxattr);
+
if (!rx_win_args_valid(cop, rxattr))
return ERR_PTR(-EINVAL);
@@ -1008,6 +1013,8 @@ struct vas_window *vas_tx_win_open(int vasid, enum vas_cop_type cop,
struct vas_winctx winctx;
struct vas_instance *vinst;
+ trace_vas_tx_win_open(current, vasid, cop, attr);
+
if (!tx_win_args_valid(cop, attr))
return ERR_PTR(-EINVAL);
@@ -1100,6 +1107,8 @@ int vas_paste_crb(struct vas_window *txwin, int offset, bool re)
void *addr;
uint64_t val;
+ trace_vas_paste_crb(current, txwin);
+
/*
* Only NX windows are supported for now and hardware assumes
* report-enable flag is set for NX windows. Ensure software
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] powerpc: export set_thread_uses_vas()
From: Sukadev Bhattiprolu @ 2018-01-17 1:50 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
In-Reply-To: <1516153832-9282-1-git-send-email-sukadev@linux.vnet.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
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 f20c1ad..d22055b 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1475,6 +1475,7 @@ int set_thread_uses_vas(void)
#endif /* CONFIG_PPC_BOOK3S_64 */
return 0;
}
+EXPORT_SYMBOL_GPL(set_thread_uses_vas);
#ifdef CONFIG_PPC64
static DEFINE_SPINLOCK(vas_thread_id_lock);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] powerpc: export thread-tidr interfaces
From: Sukadev Bhattiprolu @ 2018-01-17 1:50 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
Export set_thread_tidr() and clear_thread_tidr() interfaces so they
can be used by external modules.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
arch/powerpc/kernel/process.c | 2 ++
1 file changed, 2 insertions(+)
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);
void arch_release_task_struct(struct task_struct *t)
{
@@ -1592,6 +1593,7 @@ int set_thread_tidr(struct task_struct *t)
return 0;
}
+EXPORT_SYMBOL_GPL(set_thread_tidr);
#endif /* CONFIG_PPC64 */
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4 00/17] ASoC: fsl_ssi: Clean up - program flow level
From: Maciej S. Szmigiero @ 2018-01-17 0:11 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: <20180116235258.GA6849@Asurada-Nvidia>
On 17.01.2018 00:52, Nicolin Chen wrote:
> On Wed, Jan 17, 2018 at 12:38:09AM +0100, Maciej S. Szmigiero wrote:
>
>>> Example of uncovered tests: AC97, PowerPC and FIQ.
>>
>> I've tested the whole series in the AC'97 mode on an i.MX6 UDOO board
>> and everything seems to work fine as long as few small changes are made
>> to patches 13 and 16.
>
> Thanks for the review and testing. Really appreciate that. I'll
> take care of those issues in the next version.
Thanks for these cleanups Nicolin!
> And I believe those issues are confined to AC97. So Caleb should
> be able to skip his test if only these two places get updated.
> (Thanks for keeping testing on each version.)
Yes, these required changes only affect the AC'97 mode, there
shouldn't be any functionality change in the I2S mode.
Maciej
^ permalink raw reply
* Re: [PATCH v4 00/17] ASoC: fsl_ssi: Clean up - program flow level
From: Nicolin Chen @ 2018-01-16 23:52 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: <56fb5b43-383f-c0f2-360c-eef0e4d0844f@maciej.szmigiero.name>
On Wed, Jan 17, 2018 at 12:38:09AM +0100, Maciej S. Szmigiero wrote:
> > Example of uncovered tests: AC97, PowerPC and FIQ.
>
> I've tested the whole series in the AC'97 mode on an i.MX6 UDOO board
> and everything seems to work fine as long as few small changes are made
> to patches 13 and 16.
Thanks for the review and testing. Really appreciate that. I'll
take care of those issues in the next version.
And I believe those issues are confined to AC97. So Caleb should
be able to skip his test if only these two places get updated.
(Thanks for keeping testing on each version.)
^ permalink raw reply
* Re: [PATCH v4 16/17] ASoC: fsl_ssi: Move DT related code to a separate probe()
From: Maciej S. Szmigiero @ 2018-01-16 23:39 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: <1516058192-65519-17-git-send-email-nicoleotsuka@gmail.com>
On 16.01.2018 00:16, Nicolin Chen wrote:
> This patch cleans up probe() function by moving all Device Tree
> related code into a separate function. It allows the probe() to
> be Device Tree independent. This will be very useful for future
> integration of imx-ssi driver which has similar functionalities
> while exists only because it supports non-DT cases.
>
> This patch also moves symmetric_channels of AC97 from the probe
> to the structure snd_soc_dai_driver for simplification.
>
> Additionally, since PowerPC and AC97 use the same pdev pointer
> to register a platform device, this patch also unifies related
> code.
>
> Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
> Tested-by: Caleb Crome <caleb@crome.org>
> ---
> Changelog
> v4
> * Made bool synchronous exclusive with AC97 mode in PATCH-16
>
> sound/soc/fsl/fsl_ssi.c | 209 ++++++++++++++++++++++++++----------------------
> 1 file changed, 114 insertions(+), 95 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index dfeca43..07ec47d 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -1529,50 +1581,17 @@ static int fsl_ssi_probe(struct platform_device *pdev)
> if (ret)
> goto error_asoc_register;
>
> - /* Bypass it if using newer DT bindings of ASoC machine drivers */
> - if (!of_get_property(np, "codec-handle", NULL))
> - goto done;
> -
> - /*
> - * Backward compatible for older bindings by manually triggering the
> - * machine driver's probe(). Use /compatible property, including the
> - * address of CPU DAI driver structure, as the name of machine driver.
> - */
> - sprop = of_get_property(of_find_node_by_path("/"), "compatible", NULL);
> - /* Sometimes the compatible name has a "fsl," prefix, so we strip it. */
> - p = strrchr(sprop, ',');
> - if (p)
> - sprop = p + 1;
> - snprintf(name, sizeof(name), "snd-soc-%s", sprop);
> - make_lowercase(name);
> -
> - ssi->pdev = platform_device_register_data(dev, name, 0, NULL, 0);
> - if (IS_ERR(ssi->pdev)) {
> - ret = PTR_ERR(ssi->pdev);
> - dev_err(dev, "failed to register platform: %d\n", ret);
> - goto error_sound_card;
> - }
> -
> -done:
> /* Initially configures SSI registers */
> fsl_ssi_hw_init(ssi);
>
> - if (fsl_ssi_is_ac97(ssi)) {
> - u32 ssi_idx;
> -
> - ret = of_property_read_u32(np, "cell-index", &ssi_idx);
> - if (ret) {
> - dev_err(dev, "failed to get SSI index property\n");
> - goto error_sound_card;
> - }
> -
> - ssi->pdev = platform_device_register_data(NULL, "ac97-codec",
> - ssi_idx, NULL, 0);
> - if (IS_ERR(ssi->pdev)) {
> - ret = PTR_ERR(ssi->pdev);
> - dev_err(dev,
> - "failed to register AC97 codec platform: %d\n",
> - ret);
> + /* Register a platform device for older bindings or AC97 */
> + if (ssi->card_name[0]) {
> + ssi->card_pdev = platform_device_register_data(dev,
^
Here we need to pass NULL as the parent in the AC'97 mode as the original
code did, because otherwise snd_soc_find_dai() will assume that the AC'97
CODEC platform device has the same DT node as the SSI (the CODEC isn't
present in the DT on its own) and so when asked for SSI by its DT node
will return the CODEC instead.
The end result is a NULL pointer dereference when starting a playback.
Maciej
^ permalink raw reply
* Re: [PATCH v4 13/17] ASoC: fsl_ssi: Setup AC97 in fsl_ssi_hw_init()
From: Maciej S. Szmigiero @ 2018-01-16 23:39 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: <1516058192-65519-14-git-send-email-nicoleotsuka@gmail.com>
On 16.01.2018 00:16, Nicolin Chen wrote:
> AC97 configures most of registers earlier to start a communication
> with CODECs in order to successfully initialize CODEC. Currently,
> _fsl_ssi_set_dai_fmt() and fsl_ssi_setup_ac97() are called to get
> all SSI registers properly set.
>
> Since now the driver has a fsl_ssi_hw_init() to handle all register
> initial settings, this patch moves those register settings of AC97
> to the fsl_ssi_hw_init() as well.
>
> Meanwhile it applies _fsl_ssi_set_dai_fmt() call to AC97 only since
> other formats would be configured via normal set_dai_fmt() directly.
>
> This patch also adds fsl_ssi_hw_clean() to cleanup control bits for
> AC97 in the platform remote() function.
>
> Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
> Tested-by: Caleb Crome <caleb@crome.org>
> ---
> Changelog
> v2
> * Moved all to fsl_ssi_hw_init() in platform probe()
> * Added fsl_ssi_hw_clean() instead of dai remove()
>
> sound/soc/fsl/fsl_ssi.c | 26 ++++++++++++++++++++------
> 1 file changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index 50648f5..ebb3eb9 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -1255,10 +1252,28 @@ static int fsl_ssi_hw_init(struct fsl_ssi *ssi)
> regmap_update_bits(ssi->regs, REG_SSI_SCR,
> SSI_SCR_TCH_EN, SSI_SCR_TCH_EN);
>
> + /* AC97 should start earlier to communicate with CODECs */
> + if (fsl_ssi_is_ac97(ssi)) {
> + _fsl_ssi_set_dai_fmt(ssi->dev, ssi, ssi->dai_fmt);
> + fsl_ssi_setup_ac97(ssi);
> + }
> +
> return 0;
> }
>
> /**
> + * Clear SSI registers
> + */
> +static void fsl_ssi_hw_clean(struct fsl_ssi *ssi)
> +{
> + /* Disable registers for AC97 */
> + if (fsl_ssi_is_ac97(ssi)) {
> + regmap_write(ssi->regs, REG_SSI_SCR, 0);
> + regmap_write(ssi->regs, REG_SSI_SACNT, 0);
> + regmap_write(ssi->regs, REG_SSI_SOR, 0);
These writes cause a hard SoC lockup when unloading the driver.
The following replacement order seems to be tolerated by the SSI:
regmap_update_bits(ssi->regs, REG_SSI_SCR, SSI_SCR_TE | SSI_SCR_RE, 0);
regmap_write(ssi->regs, REG_SSI_SACNT, 0);
regmap_write(ssi->regs, REG_SSI_SOR, 0);
regmap_update_bits(ssi->regs, REG_SSI_SCR, SSI_SCR_SSIEN, 0);
BTW: I've also tried disabling SSIEN before writing to SACNT and SOR
(both together with (TR | RE) and also as a separate step) but this
still caused a lockup.
> @@ -1587,6 +1599,8 @@ static int fsl_ssi_remove(struct platform_device *pdev)
> {
> struct fsl_ssi *ssi = dev_get_drvdata(&pdev->dev);
>
> + fsl_ssi_hw_clean(ssi);
> +
We need to move this call...
> fsl_ssi_debugfs_remove(&ssi->dbg_stats);
>
> if (ssi->pdev)
> platform_device_unregister(ssi->card_pdev);
...here, after the AC'97 CODEC platform device is unregistered, since the
CODEC shutdown may need a working AC'97 register communication.
Maciej
^ permalink raw reply
* Re: [PATCH v4 00/17] ASoC: fsl_ssi: Clean up - program flow level
From: Maciej S. Szmigiero @ 2018-01-16 23: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: <1516058192-65519-1-git-send-email-nicoleotsuka@gmail.com>
On 16.01.2018 00:16, Nicolin Chen wrote:
> ==Change log==
> 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 with TDM lookback tests on i.MX6.
>
> Example of uncovered tests: AC97, PowerPC and FIQ.
I've tested the whole series in the AC'97 mode on an i.MX6 UDOO board
and everything seems to work fine as long as few small changes are made
to patches 13 and 16.
Maciej
^ permalink raw reply
* Re: [PATCH 3/6] gpio: Add GPIO driver for Nintendo Wii
From: Jonathan Neuschäfer @ 2018-01-16 21:58 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Neuschäfer, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org list, linux-gpio,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Albert Herranz, Segher Boessenkool
In-Reply-To: <CACRpkdb11jn4HFdoKLuNVmXeTBntpTAjkVctvH1=R-p6989eTg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3201 bytes --]
On Tue, Jan 16, 2018 at 10:42:54AM +0100, Linus Walleij wrote:
> On Mon, Jan 15, 2018 at 4:13 AM, Jonathan Neuschäfer
> <j.neuschaefer@gmx.net> wrote:
>
> > This patch is based on code developed by Albert Herranz and the GameCube
> > Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
> > available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
> > has grown quite dissimilar.
>
> I'm impressed by this effort. As with all reverse engineering.
>
> > This driver currently uses __raw_readl and __raw_writel to access the
> > GPIO controller's MMIO registers. I wonder if readl/writel plus explicit
> > byte-swapping would be more correct, because it could be independent of
> > the CPU's endianness. That said, this hardware only exists in two
> > big-endian machines (Wii and Wii U).
>
> I don't know about PPC but I think you're supposed to use
> ioread32be() and iowrite32be() to do explicit BE access.
Ah, that's the name! I didn't find ioread32*/iowrite32* in the
documentation or source code.
> But when I look at it, I think you can just use the gpio-mmio library
> for this driver and cut down code cosiderably.
I'll look into it. So far it looks good (drivers/gpio/gpio-iop.c has
just 60 lines).
> > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> Can't you just save a pointer to struct device *dev in the
> state container and use dev_info(state->dev, ...) etc instead
> of this?
Makes sense. I'll try this out.
> > +#include <linux/of_gpio.h>
>
> This include should not be needed.
Okay.
> > +/*
> > + * Update the bit with the given bit offset in the given register to a given
> > + * value
> > + */
> > +static void hlwd_gpio_update_bit(struct gpio_chip *gc, unsigned int reg,
> > + int offset, int value)
> > +{
> > + struct hlwd_gpio *hlwd = gpiochip_get_data(gc);
> > + unsigned long flags;
> > + u32 bit = 1UL << offset;
>
> #include <linux/bitops.h>
>
> u32 bit = BIT(offset);
>
> > + u32 tmp;
> > +
> > + spin_lock_irqsave(&hlwd->lock, flags);
> > + tmp = __raw_readl(hlwd->regs + reg);
> > + if (value)
> > + __raw_writel(tmp | bit, hlwd->regs + reg);
> > + else
> > + __raw_writel(tmp & ~bit, hlwd->regs + reg);
> > + spin_unlock_irqrestore(&hlwd->lock, flags);
> > +}
>
> This looks very much like it is reimplementing the stuff we already
> have in drivers/gpio/gpio-mmio.h.
>
> There is even a big endian access flag for the library.
> And you get so much for free with gpio-mmio.
>
> select GPIO_GENERIC
> in Kconfig
>
> the helpers come in from <linux/gpio/driver.h>
>
> Look at other drivers for inspiration:
> git grep bgpio_init
>
> If you need IRQ support you should probably have your own file
> for this driver, but it will be just a few lines of wrapper using
> bgpio_init() and BGPIOF_BIG_ENDIAN and/or possibly
> BGPIOF_BIG_ENDIAN_BYTE_ORDER.
Yes, I plan to add IRQ support in a later patch.
>
> See the other drivers.
Yep, gpio-mmio looks like a good option, thanks for the pointer!
Thanks,
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v4 00/17] ASoC: fsl_ssi: Clean up - program flow level
From: Caleb Crome @ 2018-01-16 21:26 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: <1516058192-65519-1-git-send-email-nicoleotsuka@gmail.com>
On Mon, Jan 15, 2018 at 3:16 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> ==Change log==
> 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 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 | 741 +++++++++++++++++++++++++-----------------------
> sound/soc/fsl/fsl_ssi.h | 3 -
> 2 files changed, 379 insertions(+), 365 deletions(-)
>
> --
> 2.7.4
>
Tested v4 with 8 channel TDM at 48kHz. No problems found.
Tested-by: Caleb Crome <caleb@crome.org>
^ permalink raw reply
* Re: DPAA Ethernet traffice troubles with Linux kernel
From: mad skateman @ 2018-01-16 21:15 UTC (permalink / raw)
To: Andrew Lunn, Joakim Tjernlund, linuxppc-dev@lists.ozlabs.org,
madalin.bucur@nxp.com, Christian Zigotzky
In-Reply-To: <20180116210048.GB29888@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
This makes me really start to wonder if the mainboard producer Varisys/AEON
has Purchased MAC`s for these boards at IEEE
Uboot system info gives for both MAC adresses the value NULL ... and i have
checked the mainboard for any stickers regarding the MAC adresses but there
is none..
I also tried to just create a ethaddr, eth1addr and eth2addr as mention on
the Wiki..but no luck
http://wiki.amiga.org/index.php?title=AmigaONE_X5000
On Tue, Jan 16, 2018 at 10:00 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > *Given this if we disable that bit, we get the matching "Universally
> > Administered Address" 00000100 (Binary), 04 (Hex) -> "04:00:00", hence my
> > question:"*
> >
> > This has something to do with the MAC adresses being locally administered
> > .. and since whe can use Uboot and choose any Mac addr we want, this
> could
> > make sense..
>
> You cannot just flip this bit. Universally administered addresses are
> allocated by the IEEE. You need to purchase them from the IEEE.
> Locally administered MAC addresses you can use, and any sane DHCP
> server should work with them.
>
> This also does not fit with mii-tool -R observation.
>
> Andrew
>
[-- Attachment #2: Type: text/html, Size: 1788 bytes --]
^ permalink raw reply
* Re: DPAA Ethernet traffice troubles with Linux kernel
From: Andrew Lunn @ 2018-01-16 21:00 UTC (permalink / raw)
To: mad skateman
Cc: Joakim Tjernlund, linuxppc-dev@lists.ozlabs.org,
madalin.bucur@nxp.com
In-Reply-To: <CAHkrCmE5GzvkKTm5=Yy5QxKOL_OJn+9xrWLjhH=Zayg_nsQt7A@mail.gmail.com>
> *Given this if we disable that bit, we get the matching "Universally
> Administered Address" 00000100 (Binary), 04 (Hex) -> "04:00:00", hence my
> question:"*
>
> This has something to do with the MAC adresses being locally administered
> .. and since whe can use Uboot and choose any Mac addr we want, this could
> make sense..
You cannot just flip this bit. Universally administered addresses are
allocated by the IEEE. You need to purchase them from the IEEE.
Locally administered MAC addresses you can use, and any sane DHCP
server should work with them.
This also does not fit with mii-tool -R observation.
Andrew
^ permalink raw reply
* Re: DPAA Ethernet traffice troubles with Linux kernel
From: Andrew Lunn @ 2018-01-16 20:53 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: <1516125454.18795.87.camel@infinera.com>
> > You appear to be using an old kernel. Take a look at:
>
> Not really, I am using 4.14.x and I don't think that is old.
Development for 4.14 stopped somewhere around the beginning of
September. So there has been over 4 months of work since then. We are
clearly interested in fixing bugs in that kernel, since it is the
current stable version. But when reporting bugs, please let is know if
the latest version of the network kernel,
it://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git has
the issue.
> Seems like this patch hasn't been sent to 4.14.x.
If it fixes a bug for you, please request the fix is added to stable.
Andrew
^ permalink raw reply
* Re: DPAA Ethernet problems with mainstream Linux kernels
From: Christian Zigotzky @ 2018-01-16 20:42 UTC (permalink / raw)
To: Madalin-cristian Bucur, Darren Stevens, Jamie Krueger,
linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org
In-Reply-To: <DB3PR0402MB38496B4FB62904321A97186AECEA0@DB3PR0402MB3849.eurprd04.prod.outlook.com>
Hi All,
I compiled the RC8 of kernel 4.15 for the X5000 without PAMU support today.
Download: http://www.xenosoft.de/uImage_without_pamu.tar.gz
Please test it on your AmigaOne X5000.
Thanks,
Christian
On 16 January 2018 at 6:33PM, Madalin-cristian Bucur wrote:
>> The PAMU related errors may be relevant to the issue, if you have incorrect
>> settings you may have no traffic passing through. The PAMU configuration
>> should be made by the bootloader. Can you try to disable CONFIG_FSL_PAMU?
>>
>> Madalin
>>
>>
^ permalink raw reply
* [PATCH 2/2] macintosh/rack-meter: Improve a size determination in rackmeter_probe()
From: SF Markus Elfring @ 2018-01-16 20:40 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt; +Cc: LKML, kernel-janitors
In-Reply-To: <c11e0a90-a7b2-dddd-7751-7dac3e62215b@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 16 Jan 2018 21:26:52 +0100
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/macintosh/rack-meter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/rack-meter.c b/drivers/macintosh/rack-meter.c
index 0796b74174d4..800fc6822ad8 100644
--- a/drivers/macintosh/rack-meter.c
+++ b/drivers/macintosh/rack-meter.c
@@ -397,7 +397,7 @@ static int rackmeter_probe(struct macio_dev* mdev,
}
/* Create and initialize our instance data */
- rm = kzalloc(sizeof(struct rackmeter), GFP_KERNEL);
+ rm = kzalloc(sizeof(*rm), GFP_KERNEL);
if (rm == NULL) {
rc = -ENOMEM;
goto bail_release;
--
2.15.1
^ permalink raw reply related
* [PATCH 1/2] macintosh/rack-meter: Delete an error message for a failed memory allocation in rackmeter_probe()
From: SF Markus Elfring @ 2018-01-16 20:39 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt; +Cc: LKML, kernel-janitors
In-Reply-To: <c11e0a90-a7b2-dddd-7751-7dac3e62215b@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 16 Jan 2018 21:23:36 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/macintosh/rack-meter.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/macintosh/rack-meter.c b/drivers/macintosh/rack-meter.c
index 910b5b6f96b1..0796b74174d4 100644
--- a/drivers/macintosh/rack-meter.c
+++ b/drivers/macintosh/rack-meter.c
@@ -399,7 +399,6 @@ static int rackmeter_probe(struct macio_dev* mdev,
/* Create and initialize our instance data */
rm = kzalloc(sizeof(struct rackmeter), GFP_KERNEL);
if (rm == NULL) {
- printk(KERN_ERR "rackmeter: failed to allocate memory !\n");
rc = -ENOMEM;
goto bail_release;
}
--
2.15.1
^ permalink raw reply related
* [PATCH 0/2] macintosh/rack-meter: Adjustments for rackmeter_probe()
From: SF Markus Elfring @ 2018-01-16 20:38 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt; +Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 16 Jan 2018 21:36:56 +0100
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an error message for a failed memory allocation
Improve a size determination
drivers/macintosh/rack-meter.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--
2.15.1
^ 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