[dpdk-dev] [PATCH v4 07/41] bus/dpaa: enable DPAA IOCTL portal driver
Shreyansh Jain
shreyansh.jain at nxp.com
Tue Sep 19 16:17:18 CEST 2017
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.thorpe at nxp.com>
>> Signed-off-by: Hemant Agrawal <hemant.agrawal at nxp.com>
>> Signed-off-by: Shreyansh Jain <shreyansh.jain at 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.
>
> <...>
>
More information about the dev
mailing list