On Monday 18 September 2017 08:21 PM, Ferruh Yigit wrote:
On 9/9/2017 12:20 PM, Shreyansh Jain wrote:
Userspace applications interact with DPAA blocks using this IOCTL driver.
Signed-off-by: Geoff Thorpe <geoff.tho...@nxp.com>
Signed-off-by: Hemant Agrawal <hemant.agra...@nxp.com>
Signed-off-by: Shreyansh Jain <shreyansh.j...@nxp.com>
<...>
+static int fd = -1;
+static pthread_mutex_t fd_init_lock = PTHREAD_MUTEX_INITIALIZER;
+
+static int check_fd(void)
+{
+ int ret;
+
+ if (fd >= 0)
+ return 0;
+ ret = pthread_mutex_lock(&fd_init_lock);
Do you need to link against pthred library for this":
LDLIBS += -lpthread
We are already doing that in driver/bus/dpaa/Makefile.
Only issue is that I have introduced that two patches from this.
I will fix this.
<...>
+/* The process device underlies process-wide user/kernel interactions, such as
+ * mapping dma_mem memory and providing accompanying ioctl()s. (This isn't used
+ * for portals, which use one UIO device each.).
+ */
+#define PROCESS_PATH "/dev/fsl-usdpaa"
Who is creating this file, who is responsible to responding ioctl()
calls, there must a kernel module, right?
This is provided by Userspace DPAA (usdpaa) drivers in the QorIQ kernel.
This is currently part of the NXP SDK
(https://lsdk.github.io/components.html) for DPAA boards.
(https://github.com/qoriq-open-source/linux). We are still in process of
pushing it to upstream.
So, assumption is that DPAA DPDK driver will only work with this SDK
until the Linux Kernel upstreaming completes. I guess I had documented
this in dpaa.rst but if not, I will explicitly add this.
<...>
