Chen, Hongzhan <[email protected]> writes:
>>-----Original Message----- >>From: Philippe Gerum <[email protected]> >>Sent: Monday, February 1, 2021 5:31 PM >>To: Chen, Hongzhan <[email protected]> >>Cc: [email protected] >>Subject: Re: several questions about porting latmus >> >> >>Hi Hongzhan, >> >>Chen, Hongzhan <[email protected]> writes: >> >>> Hi Philippe >>> >>> When I was trying to port latmus from evl to xenomai 3.2, I met several >>> issues that block porting >>> and need your suggestions. >>> >>> 1. When I tried to replace function evl_run_kthread_on_cpu of latmus.c >>> driver , I found that only rtdm_task_init >>> can meet our requirements mostly but we still cannot pass cpu affinity >>> through it to pin task to required >>> cpu. Do we need to implement new API so that we can pass cpu affinity >>> to pin task to required cpu but >>> finish all functions of rtdm_task_init? >>> >> >>We should probably introduce rtdm_task_init_on_cpu() in 3.2, since this >>is a desirable feature which should be part of the CXP. Other ways to >>pin the new kthread are fairly ugly ATM, ranging from pinning the parent >>to the destination CPU before creating the child thread, or open coding >>the spawning sequence based on the internal interface (xnthread_init, >>xnthread_start). Please submit a patch for review of that change >>specifically, prior to submitting any latmus-related bits. >> > > OK. I have finished latmus driver porting so far and built it successfully > with linux. > In the following , I would start to port latmus application. After latmus > application is done, > I would validate all of them and then will try to submit patches to review > after validation > is successful. > With respect to the timer responder test, the latmus application is based on EVL's built-in timerfd [1] feature, which is very close to the Cobalt/POSIX equivalent, so the port should be straightforward. Things may be a little trickier with the GPIO responder test, as Cobalt needs a specific RTDM driver to operate the GPIO lines (EVL reuses the common GPIOLIB for this [2], so do not look for any specific driver here). It depends on the GPIO controller you will test on. You will certainly need to add support for it to kernel/drivers/gpio. Which hardware do you plan to use? [1] https://evlproject.org/core/user-api/timer/ [2] http://evlproject.org/core/oob-drivers/gpio/ -- Philippe.
