[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