[Xenomai] analogy: sensory 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Xenomai] analogy: sensory 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Jorge Ramirez Ortiz]

---------------------------------------------------------------------- Message: 1 
Date: Mon, 07 Jul 2014 12:38:42 +0200 From: Wojciech Domski <> To: Gilles 
Chanteperdrix <gilles.chanteperdrix@xenomai.org> Cc: xenomai@xenomai.org Subject: Re: 
[Xenomai] Sensoray 626 analogy driver Message-ID: <53BA78B2.2010802@gmail.com> 
Content-Type: text/plain; charset="utf-8"; Format="flowed" W dniu 11.04.2014 00:01, 
Gilles Chanteperdrix pisze:
>> On 04/10/2014 02:25 PM, Wojciech Domski wrote:
>>> 2014-03-25 13:33 GMT+01:00 Gilles Chanteperdrix <
>>> gilles.chanteperdrix@xenomai.org>:
>>>
>>>> On 03/25/2014 01:14 PM, Wojciech Domski wrote:
>>>>> W dniu 25.03.2014 12:58, Gilles Chanteperdrix pisze:
>>>>>> On 03/25/2014 12:54 PM, Wojciech Domski wrote:
>>>>>>> W dniu 25.03.2014 12:36, Gilles Chanteperdrix pisze:
>>>>>>>> On 03/25/2014 12:28 PM, Wojciech Domski wrote:
>>>>>>>>> W dniu 25.03.2014 12:16, Gilles Chanteperdrix pisze:
>>>>>>>>>> On 03/25/2014 11:26 AM, Wojciech Domski wrote:
>>>>>>>>>>> W dniu 24.03.2014 13:19, Gilles Chanteperdrix pisze:
>>>>>>>>>>>> The solution which would be acceptable is not to have busy waits,
>>>> except
>>>>>>>>>>>> for very short durations. But for instance transferring a byte on
>>>> I2C
>>>>>>>>>>>> takes around 20us at 400 kHz, a 20us masking section is
>>>> unacceptable.
>>>>>>>>>>>> rtdm_task_busy_sleep, as the name suggests is a busy wait loop,
>>>> so, no,
>>>>>>>>>>>> it is not acceptable either.
>>>>>>>>>>>>
>>>>>>>>>>>> Use a thread or a timer to reschedule while you wait for the end
>>>> of the
>>>>>>>>>>>> transfer, instead of busy waiting.
>>>>>>>>>>> Dear Gilles,
>>>>>>>>>>>
>>>>>>>>>>> As you mentioned before the driver has few places like this:
>>>>>>>>>>>
>>>>>>>>>>> while(!FLAG1);
>>>>>>>>>>> while(!FLAG2);
>>>>>>>>>>>
>>>>>>>>>>> Would a solution of creating a separate task for this purpose be
>>>> ok?
>>>>>>>>>>> task()
>>>>>>>>>>> {
>>>>>>>>>>>           while(!FLAG1);
>>>>>>>>>>>           while(!FLAG2);
>>>>>>>>>>> }
>>>>>>>>>> I was rather thinking about rtdm_task_sleep() instead.
>>>>>>>>>>
>>>>>>>>>>> In the place of those loops a piece of code responsible for
>>>> creating and
>>>>>>>>>>> joining task would be put instead:
>>>>>>>>>>>
>>>>>>>>>>> rtdm_task_init();
>>>>>>>>>>> rtdm_task_join_nrt();
>>>>>>>>>> This will not work for code currently running in interrupt
>>>> handlers. An
>>>>>>>>>> interrupt handler can not call rtdm_task_join_nrt(). You will rather
>>>>>>>>>> have to wake up the thread, not reenabling the interrupt at the end
>>>> of
>>>>>>>>>> the handler, and reenable the interrupt in the thread when the job
>>>> is
>>>>>>>>>> done. Or alternatively, fire a timer instead of waking up a thread.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Dear Gilles,
>>>>>>>>>
>>>>>>>>> If what I have understood correctly, basically what you mean is
>>>> changing:
>>>>>>>>> while(!FLAG) ;
>>>>>>>>>
>>>>>>>>> into
>>>>>>>>>
>>>>>>>>> while(!FLAG)
>>>>>>>>>          rtdm_task_sleep();
>>>>>>>>>
>>>>>>>>> Xenomai's documentation that rtdm_task_sleep() can be always
>>>>>>>>> rescheduled. In my opinion
>>>>>>>>> this solution is sufficient and meets Xenomai requirements.
>>>>>>>> This solution will not work if the busy loop was in an irq handler.
>>>> You
>>>>>>>> can not call rtdm_task_sleep from the context of an irq handler.
>>>>>>>>
>>>>>>>>
>>>>>>> Ok, now I get your point.
>>>>>>>
>>>>>>> However, what do you mean exactly by rescheduling while waiting? Do you
>>>>>>> mean something like
>>>>>>> putting all irq services into another thread and only in irq handler
>>>>>>> notify the separate thread
>>>>>>> to do the job accordingly?
>>>>>> Well, I do not know exactly, I have not looked at the details of the
>>>>>> driver, you are supposed to do that. But you may be able to split the
>>>>>> interrupt code in two parts: a first part that will run in interrupt
>>>>>> mode, and a second part that will run as a thread. The irq handler would
>>>>>> wake the thread up at the end of the first part, and return without
>>>>>> reenabling the interrupt at interrupt controller level. The thread would
>>>>>> execute, sleep during the I2C transfers as needed, and reenable the
>>>>>> interrupt before going back to sleep.
>>>>>>
>>>>>>
>>>>> So would it be a good practise to create a new task for irq service with
>>>>>
>>>>> rtdm_task_init();
>>>>>
>>>>> inside attach function and join it with
>>>>>
>>>>> rtdm_task_join_nrt();
>>>>>
>>>>> inside detach function?
>>>> I do not know the details about analogy drivers, so, again, it is left
>>>> to you to read other analogy drivers and see where is the best place to
>>>> do what you want to do.
>>>>
>>>>
>>>> --
>>>>                                                                   Gilles.
>>>>
>>> Dear Gilles,
>>>
>>> I have altered the driver according to your advices.
>>> If I had omitted something please let me know.
>>>
>>> Please find a patch enclosed in the attachment.
>>>
>>> Best regards,
>>> Wojciech Domski
>>>
>>> Domski.pl
>>>
>>> Wojciech.Domski.pl
>>> -------------- next part --------------
>>> A non-text attachment was scrubbed...
>>> Name: s626_patch.patch
>>> Type: text/x-patch
>>> Size: 141659 bytes
>>> Desc: not available
>>> URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140410/e7191247/attachment.bin>
>> scripts/checkpatch.pl attchment.bin:
>>
>> total: 325 errors, 392 warnings, 3991 lines checked
>>
>> Please fix these errors.
>>
>>
> Dear Gilles,
>
> In the attachment you will find patch for xenomai including support for
> analogy Sensoray 626.
>
> May I ask you to include this patch to main xenomai tree?
>
> Best regards,
>
> Wojciech Domski
>
> Domski.pl
>
> Wojciech.Domski.pl
>


Hi Wojciech

I did some changes to the patch that you sent and pushed it to my Xenomai 3 tree 
(branch sensoray) as work in progress; however we have no means to test or validate 
any of the changes.
http://git.xenomai.org/xenomai-jro.git/log/?h=sensoray

is this something that you can do? ie, do you have access to the sensoray device?

In any case after reviewing the Comedi implementation in 3.12 staging I think it 
would make sense to base off that newer release instead.

jro



-- 
jro

Re: [Xenomai] analogy: sensory 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Wojciech Domski]

W dniu 2014-07-14 16:18, Jorge Ramirez Ortiz pisze:
> ---------------------------------------------------------------------- 
> Message: 1 Date: Mon, 07 Jul 2014 12:38:42 +0200 From: Wojciech Domski 
> <> To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> Cc: 
> xenomai@xenomai.org Subject: Re: [Xenomai] Sensoray 626 analogy driver 
> Message-ID: <53BA78B2.2010802@gmail.com> Content-Type: text/plain; 
> charset="utf-8"; Format="flowed" W dniu 11.04.2014 00:01, Gilles 
> Chanteperdrix pisze:
>>> On 04/10/2014 02:25 PM, Wojciech Domski wrote:
>>>> 2014-03-25 13:33 GMT+01:00 Gilles Chanteperdrix <
>>>> gilles.chanteperdrix@xenomai.org>:
>>>>
>>>>> On 03/25/2014 01:14 PM, Wojciech Domski wrote:
>>>>>> W dniu 25.03.2014 12:58, Gilles Chanteperdrix pisze:
>>>>>>> On 03/25/2014 12:54 PM, Wojciech Domski wrote:
>>>>>>>> W dniu 25.03.2014 12:36, Gilles Chanteperdrix pisze:
>>>>>>>>> On 03/25/2014 12:28 PM, Wojciech Domski wrote:
>>>>>>>>>> W dniu 25.03.2014 12:16, Gilles Chanteperdrix pisze:
>>>>>>>>>>> On 03/25/2014 11:26 AM, Wojciech Domski wrote:
>>>>>>>>>>>> W dniu 24.03.2014 13:19, Gilles Chanteperdrix pisze:
>>>>>>>>>>>>> The solution which would be acceptable is not to have busy 
>>>>>>>>>>>>> waits,
>>>>> except
>>>>>>>>>>>>> for very short durations. But for instance transferring a 
>>>>>>>>>>>>> byte on
>>>>> I2C
>>>>>>>>>>>>> takes around 20us at 400 kHz, a 20us masking section is
>>>>> unacceptable.
>>>>>>>>>>>>> rtdm_task_busy_sleep, as the name suggests is a busy wait 
>>>>>>>>>>>>> loop,
>>>>> so, no,
>>>>>>>>>>>>> it is not acceptable either.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Use a thread or a timer to reschedule while you wait for 
>>>>>>>>>>>>> the end
>>>>> of the
>>>>>>>>>>>>> transfer, instead of busy waiting.
>>>>>>>>>>>> Dear Gilles,
>>>>>>>>>>>>
>>>>>>>>>>>> As you mentioned before the driver has few places like this:
>>>>>>>>>>>>
>>>>>>>>>>>> while(!FLAG1);
>>>>>>>>>>>> while(!FLAG2);
>>>>>>>>>>>>
>>>>>>>>>>>> Would a solution of creating a separate task for this 
>>>>>>>>>>>> purpose be
>>>>> ok?
>>>>>>>>>>>> task()
>>>>>>>>>>>> {
>>>>>>>>>>>>           while(!FLAG1);
>>>>>>>>>>>>           while(!FLAG2);
>>>>>>>>>>>> }
>>>>>>>>>>> I was rather thinking about rtdm_task_sleep() instead.
>>>>>>>>>>>
>>>>>>>>>>>> In the place of those loops a piece of code responsible for
>>>>> creating and
>>>>>>>>>>>> joining task would be put instead:
>>>>>>>>>>>>
>>>>>>>>>>>> rtdm_task_init();
>>>>>>>>>>>> rtdm_task_join_nrt();
>>>>>>>>>>> This will not work for code currently running in interrupt
>>>>> handlers. An
>>>>>>>>>>> interrupt handler can not call rtdm_task_join_nrt(). You 
>>>>>>>>>>> will rather
>>>>>>>>>>> have to wake up the thread, not reenabling the interrupt at 
>>>>>>>>>>> the end
>>>>> of
>>>>>>>>>>> the handler, and reenable the interrupt in the thread when 
>>>>>>>>>>> the job
>>>>> is
>>>>>>>>>>> done. Or alternatively, fire a timer instead of waking up a 
>>>>>>>>>>> thread.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Dear Gilles,
>>>>>>>>>>
>>>>>>>>>> If what I have understood correctly, basically what you mean is
>>>>> changing:
>>>>>>>>>> while(!FLAG) ;
>>>>>>>>>>
>>>>>>>>>> into
>>>>>>>>>>
>>>>>>>>>> while(!FLAG)
>>>>>>>>>>          rtdm_task_sleep();
>>>>>>>>>>
>>>>>>>>>> Xenomai's documentation that rtdm_task_sleep() can be always
>>>>>>>>>> rescheduled. In my opinion
>>>>>>>>>> this solution is sufficient and meets Xenomai requirements.
>>>>>>>>> This solution will not work if the busy loop was in an irq 
>>>>>>>>> handler.
>>>>> You
>>>>>>>>> can not call rtdm_task_sleep from the context of an irq handler.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Ok, now I get your point.
>>>>>>>>
>>>>>>>> However, what do you mean exactly by rescheduling while 
>>>>>>>> waiting? Do you
>>>>>>>> mean something like
>>>>>>>> putting all irq services into another thread and only in irq 
>>>>>>>> handler
>>>>>>>> notify the separate thread
>>>>>>>> to do the job accordingly?
>>>>>>> Well, I do not know exactly, I have not looked at the details of 
>>>>>>> the
>>>>>>> driver, you are supposed to do that. But you may be able to 
>>>>>>> split the
>>>>>>> interrupt code in two parts: a first part that will run in 
>>>>>>> interrupt
>>>>>>> mode, and a second part that will run as a thread. The irq 
>>>>>>> handler would
>>>>>>> wake the thread up at the end of the first part, and return without
>>>>>>> reenabling the interrupt at interrupt controller level. The 
>>>>>>> thread would
>>>>>>> execute, sleep during the I2C transfers as needed, and reenable the
>>>>>>> interrupt before going back to sleep.
>>>>>>>
>>>>>>>
>>>>>> So would it be a good practise to create a new task for irq 
>>>>>> service with
>>>>>>
>>>>>> rtdm_task_init();
>>>>>>
>>>>>> inside attach function and join it with
>>>>>>
>>>>>> rtdm_task_join_nrt();
>>>>>>
>>>>>> inside detach function?
>>>>> I do not know the details about analogy drivers, so, again, it is 
>>>>> left
>>>>> to you to read other analogy drivers and see where is the best 
>>>>> place to
>>>>> do what you want to do.
>>>>>
>>>>>
>>>>> -- 
>>>>> Gilles.
>>>>>
>>>> Dear Gilles,
>>>>
>>>> I have altered the driver according to your advices.
>>>> If I had omitted something please let me know.
>>>>
>>>> Please find a patch enclosed in the attachment.
>>>>
>>>> Best regards,
>>>> Wojciech Domski
>>>>
>>>> Domski.pl
>>>>
>>>> Wojciech.Domski.pl
>>>> -------------- next part --------------
>>>> A non-text attachment was scrubbed...
>>>> Name: s626_patch.patch
>>>> Type: text/x-patch
>>>> Size: 141659 bytes
>>>> Desc: not available
>>>> URL: 
>>>> <http://www.xenomai.org/pipermail/xenomai/attachments/20140410/e7191247/attachment.bin>
>>> scripts/checkpatch.pl attchment.bin:
>>>
>>> total: 325 errors, 392 warnings, 3991 lines checked
>>>
>>> Please fix these errors.
>>>
>>>
>> Dear Gilles,
>>
>> In the attachment you will find patch for xenomai including support for
>> analogy Sensoray 626.
>>
>> May I ask you to include this patch to main xenomai tree?
>>
>> Best regards,
>>
>> Wojciech Domski
>>
>> Domski.pl
>>
>> Wojciech.Domski.pl
>>
>
>
> Hi Wojciech
>
> I did some changes to the patch that you sent and pushed it to my 
> Xenomai 3 tree (branch sensoray) as work in progress; however we have 
> no means to test or validate any of the changes.
> http://git.xenomai.org/xenomai-jro.git/log/?h=sensoray
>
> is this something that you can do? ie, do you have access to the 
> sensoray device?
>
> In any case after reviewing the Comedi implementation in 3.12 staging 
> I think it would make sense to base off that newer release instead.
>
> jro
>
>
>
Thank you for committing the driver.
I have access to the Sensoray 626 board and I will test the remarks you 
have proposed. It will take me sometime, however. First of all I would 
like to test my driver with two Sensoray boards. For now, I see that it 
won't work with more than one card. It requires some changes to the 
attach and probe function. After I implement this functionality I will 
take a look into the interrupt handling service.

Seizing the opportunity, I would like to ask you a question about 
handling PCI device. When I'm calling pci_register_driver() and I have 
two exactly the same PCI devices will this function call appropriate 
probe() function two times? If yes, then is the probe() function an 
appropriate place to make list of available devices?

Wojciech Domski

Domski.pl

Wojciech.Domski.pl

Re: [Xenomai] analogy: sensory 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Jorge Ramirez Ortiz]

On 07/14/2014 03:09 PM, Wojciech Domski wrote:
> W dniu 2014-07-14 16:18, Jorge Ramirez Ortiz pisze:
>> ---------------------------------------------------------------------- Message: 1 
>> Date: Mon, 07 Jul 2014 12:38:42 +0200 From: Wojciech Domski <> To: Gilles 
>> Chanteperdrix <gilles.chanteperdrix@xenomai.org> Cc: xenomai@xenomai.org Subject: 
>> Re: [Xenomai] Sensoray 626 analogy driver Message-ID: <53BA78B2.2010802@gmail.com> 
>> Content-Type: text/plain; charset="utf-8"; Format="flowed" W dniu 11.04.2014 
>> 00:01, Gilles Chanteperdrix pisze:
>>>>
>>>> On 04/10/2014 02:25 PM, Wojciech Domski wrote:
>>>>> 2014-03-25 13:33 GMT+01:00 Gilles Chanteperdrix <
>>>>> gilles.chanteperdrix@xenomai.org>:
>>>>>
>>>>>>
>>>>>> On 03/25/2014 01:14 PM, Wojciech Domski wrote:
>>>>>>> W dniu 25.03.2014 12:58, Gilles Chanteperdrix pisze:
>>>>>>>>
>>>>>>>> On 03/25/2014 12:54 PM, Wojciech Domski wrote:
>>>>>>>>> W dniu 25.03.2014 12:36, Gilles Chanteperdrix pisze:
>>>>>>>>>>
>>>>>>>>>> On 03/25/2014 12:28 PM, Wojciech Domski wrote:
>>>>>>>>>>> W dniu 25.03.2014 12:16, Gilles Chanteperdrix pisze:
>>>>>>>>>>>>
>>>>>>>>>>>> On 03/25/2014 11:26 AM, Wojciech Domski wrote:
>>>>>>>>>>>>> W dniu 24.03.2014 13:19, Gilles Chanteperdrix pisze:
>>>>>>>>>>>>>> The solution which would be acceptable is not to have busy waits,
>>>>>> except
>>>>>>>>>>>>>> for very short durations. But for instance transferring a byte on
>>>>>> I2C
>>>>>>>>>>>>>> takes around 20us at 400 kHz, a 20us masking section is
>>>>>> unacceptable.
>>>>>>>>>>>>>> rtdm_task_busy_sleep, as the name suggests is a busy wait loop,
>>>>>> so, no,
>>>>>>>>>>>>>> it is not acceptable either.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Use a thread or a timer to reschedule while you wait for the end
>>>>>> of the
>>>>>>>>>>>>>> transfer, instead of busy waiting.
>>>>>>>>>>>>> Dear Gilles,
>>>>>>>>>>>>>
>>>>>>>>>>>>> As you mentioned before the driver has few places like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>> while(!FLAG1);
>>>>>>>>>>>>> while(!FLAG2);
>>>>>>>>>>>>>
>>>>>>>>>>>>> Would a solution of creating a separate task for this purpose be
>>>>>> ok?
>>>>>>>>>>>>> task()
>>>>>>>>>>>>> {
>>>>>>>>>>>>>           while(!FLAG1);
>>>>>>>>>>>>>           while(!FLAG2);
>>>>>>>>>>>>> }
>>>>>>>>>>>> I was rather thinking about rtdm_task_sleep() instead.
>>>>>>>>>>>>
>>>>>>>>>>>>> In the place of those loops a piece of code responsible for
>>>>>> creating and
>>>>>>>>>>>>> joining task would be put instead:
>>>>>>>>>>>>>
>>>>>>>>>>>>> rtdm_task_init();
>>>>>>>>>>>>> rtdm_task_join_nrt();
>>>>>>>>>>>> This will not work for code currently running in interrupt
>>>>>> handlers. An
>>>>>>>>>>>> interrupt handler can not call rtdm_task_join_nrt(). You will rather
>>>>>>>>>>>> have to wake up the thread, not reenabling the interrupt at the end
>>>>>> of
>>>>>>>>>>>> the handler, and reenable the interrupt in the thread when the job
>>>>>> is
>>>>>>>>>>>> done. Or alternatively, fire a timer instead of waking up a thread.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Dear Gilles,
>>>>>>>>>>>
>>>>>>>>>>> If what I have understood correctly, basically what you mean is
>>>>>> changing:
>>>>>>>>>>> while(!FLAG) ;
>>>>>>>>>>>
>>>>>>>>>>> into
>>>>>>>>>>>
>>>>>>>>>>> while(!FLAG)
>>>>>>>>>>>          rtdm_task_sleep();
>>>>>>>>>>>
>>>>>>>>>>> Xenomai's documentation that rtdm_task_sleep() can be always
>>>>>>>>>>> rescheduled. In my opinion
>>>>>>>>>>> this solution is sufficient and meets Xenomai requirements.
>>>>>>>>>> This solution will not work if the busy loop was in an irq handler.
>>>>>> You
>>>>>>>>>> can not call rtdm_task_sleep from the context of an irq handler.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Ok, now I get your point.
>>>>>>>>>
>>>>>>>>> However, what do you mean exactly by rescheduling while waiting? Do you
>>>>>>>>> mean something like
>>>>>>>>> putting all irq services into another thread and only in irq handler
>>>>>>>>> notify the separate thread
>>>>>>>>> to do the job accordingly?
>>>>>>>> Well, I do not know exactly, I have not looked at the details of the
>>>>>>>> driver, you are supposed to do that. But you may be able to split the
>>>>>>>> interrupt code in two parts: a first part that will run in interrupt
>>>>>>>> mode, and a second part that will run as a thread. The irq handler would
>>>>>>>> wake the thread up at the end of the first part, and return without
>>>>>>>> reenabling the interrupt at interrupt controller level. The thread would
>>>>>>>> execute, sleep during the I2C transfers as needed, and reenable the
>>>>>>>> interrupt before going back to sleep.
>>>>>>>>
>>>>>>>>
>>>>>>> So would it be a good practise to create a new task for irq service with
>>>>>>>
>>>>>>> rtdm_task_init();
>>>>>>>
>>>>>>> inside attach function and join it with
>>>>>>>
>>>>>>> rtdm_task_join_nrt();
>>>>>>>
>>>>>>> inside detach function?
>>>>>> I do not know the details about analogy drivers, so, again, it is left
>>>>>> to you to read other analogy drivers and see where is the best place to
>>>>>> do what you want to do.
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Gilles.
>>>>>>
>>>>> Dear Gilles,
>>>>>
>>>>> I have altered the driver according to your advices.
>>>>> If I had omitted something please let me know.
>>>>>
>>>>> Please find a patch enclosed in the attachment.
>>>>>
>>>>> Best regards,
>>>>> Wojciech Domski
>>>>>
>>>>> Domski.pl
>>>>>
>>>>> Wojciech.Domski.pl
>>>>> -------------- next part --------------
>>>>> A non-text attachment was scrubbed...
>>>>> Name: s626_patch.patch
>>>>> Type: text/x-patch
>>>>> Size: 141659 bytes
>>>>> Desc: not available
>>>>> URL: 
>>>>> <http://www.xenomai.org/pipermail/xenomai/attachments/20140410/e7191247/attachment.bin>
>>>> scripts/checkpatch.pl attchment.bin:
>>>>
>>>> total: 325 errors, 392 warnings, 3991 lines checked
>>>>
>>>> Please fix these errors.
>>>>
>>>>
>>> Dear Gilles,
>>>
>>> In the attachment you will find patch for xenomai including support for
>>> analogy Sensoray 626.
>>>
>>> May I ask you to include this patch to main xenomai tree?
>>>
>>> Best regards,
>>>
>>> Wojciech Domski
>>>
>>> Domski.pl
>>>
>>> Wojciech.Domski.pl
>>>
>>
>>
>> Hi Wojciech
>>
>> I did some changes to the patch that you sent and pushed it to my Xenomai 3 tree 
>> (branch sensoray) as work in progress; however we have no means to test or 
>> validate any of the changes.
>> http://git.xenomai.org/xenomai-jro.git/log/?h=sensoray
>>
>> is this something that you can do? ie, do you have access to the sensoray device?
>>
>> In any case after reviewing the Comedi implementation in 3.12 staging I think it 
>> would make sense to base off that newer release instead.
>>
>> jro
>>
>>
>>
> Thank you for committing the driver.
> I have access to the Sensoray 626 board and I will test the remarks you have 
> proposed. It will take me sometime, however. First of all I would like to test my 
> driver with two Sensoray boards. For now, I see that it won't work with more than 
> one card. It requires some changes to the attach and probe function. After I 
> implement this functionality I will take a look into the interrupt handling service.
>
> Seizing the opportunity, I would like to ask you a question about handling PCI 
> device. When I'm calling pci_register_driver() and I have two exactly the same PCI 
> devices will this function call appropriate probe() function two times? If yes, 
> then is the probe() function an appropriate place to make list of available devices?
>
> Wojciech Domski
>
> Domski.pl
>
> Wojciech.Domski.pl
>
>
invoking pci_register_driver in dev_s626_attach causes the probe interface in the pci 
driver to be executed for all the devices of the kind described in the pci id table; 
this is probably the reason why you can only register one.

It might be easier to follow the approach in analogy/national_instruments/mite.c

mite_init registers the driver which ends up calling mite_probe which will create a 
mite_struct and add it to the list of mite_devices.
Incidentally if you were wondering, this is the reason why if the pci_register_driver 
call succeeded the driver can display all the devices in the system.

the same would need to be done for the s626

on a different note, we are adding a new interface to rtdm to support the busy loops.
rtdm_busywait_safe(__condition, __busy_delay, __busy_wait)

this should allow you to do things like this

-       while (!MC_TEST(P_MC2, MC2_UPLD_DEBI))
-               rtdm_task_sleep(2000);
+       ret = rtdm_busywait_safe(!MC_TEST(P_MC2, MC2_UPLD_DEBI), BUSY_DELAY, BUSY_SLEEP);
+       if (ret)
+               __a4l_err( "error waiting");






-- 
jro

Re: [Xenomai] analogy: sensory 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Jorge Ramirez Ortiz]

On 07/14/2014 05:07 PM, Jorge Ramirez Ortiz wrote:
>
>
> On 07/14/2014 03:09 PM, Wojciech Domski wrote:
>>  W dniu 2014-07-14 16:18, Jorge Ramirez Ortiz pisze:
>>>  ---------------------------------------------------------------------- Message: 1
>>>  Date: Mon, 07 Jul 2014 12:38:42 +0200 From: Wojciech Domski < To: Gilles
>>>  Chanteperdrix <gilles.chanteperdrix@xenomai.org Cc: xenomai@xenomai.org Subject:
>>>  Re: [Xenomai] Sensoray 626 analogy driver Message-ID:
>>>  <53BA78B2.2010802@gmail.com Content-Type: text/plain; charset="utf-8";
>>>  Format="flowed" W dniu 11.04.2014 00:01, Gilles Chanteperdrix pisze:
>>>>>
>>>>>
>>>>>
>>>>> On 04/10/2014 02:25 PM, Wojciech Domski wrote:
>>>>>>  2014-03-25 13:33 GMT+01:00 Gilles Chanteperdrix <
>>>>>>  gilles.chanteperdrix@xenomai.org:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 03/25/2014 01:14 PM, Wojciech Domski wrote:
>>>>>>>>  W dniu 25.03.2014 12:58, Gilles Chanteperdrix pisze:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 03/25/2014 12:54 PM, Wojciech Domski wrote:
>>>>>>>>>>  W dniu 25.03.2014 12:36, Gilles Chanteperdrix pisze:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 03/25/2014 12:28 PM, Wojciech Domski wrote:
>>>>>>>>>>>>  W dniu 25.03.2014 12:16, Gilles Chanteperdrix pisze:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 03/25/2014 11:26 AM, Wojciech Domski wrote:
>>>>>>>>>>>>>>  W dniu 24.03.2014 13:19, Gilles Chanteperdrix pisze:
>>>>>>>>>>>>>>>  The solution which would be acceptable is not to have busy waits,
>>>>>>>
>>>>>>>  except
>>>>>>>>>>>>>>>  for very short durations. But for instance transferring a byte on
>>>>>>>
>>>>>>>  I2C
>>>>>>>>>>>>>>>  takes around 20us at 400 kHz, a 20us masking section is
>>>>>>>
>>>>>>>  unacceptable.
>>>>>>>>>>>>>>>  rtdm_task_busy_sleep, as the name suggests is a busy wait loop,
>>>>>>>
>>>>>>>  so, no,
>>>>>>>>>>>>>>>  it is not acceptable either.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  Use a thread or a timer to reschedule while you wait for the end
>>>>>>>
>>>>>>>  of the
>>>>>>>>>>>>>>>  transfer, instead of busy waiting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  Dear Gilles,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  As you mentioned before the driver has few places like this:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  while(!FLAG1);
>>>>>>>>>>>>>>  while(!FLAG2);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  Would a solution of creating a separate task for this purpose be
>>>>>>>
>>>>>>>  ok?
>>>>>>>>>>>>>>  task()
>>>>>>>>>>>>>>  {
>>>>>>>>>>>>>>            while(!FLAG1);
>>>>>>>>>>>>>>            while(!FLAG2);
>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>
>>>>>>>>>>>>>  I was rather thinking about rtdm_task_sleep() instead.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>  In the place of those loops a piece of code responsible for
>>>>>>>
>>>>>>>  creating and
>>>>>>>>>>>>>>  joining task would be put instead:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  rtdm_task_init();
>>>>>>>>>>>>>>  rtdm_task_join_nrt();
>>>>>>>>>>>>>
>>>>>>>>>>>>>  This will not work for code currently running in interrupt
>>>>>>>
>>>>>>>  handlers. An
>>>>>>>>>>>>>  interrupt handler can not call rtdm_task_join_nrt(). You will rather
>>>>>>>>>>>>>  have to wake up the thread, not reenabling the interrupt at the end
>>>>>>>
>>>>>>>  of
>>>>>>>>>>>>>  the handler, and reenable the interrupt in the thread when the job
>>>>>>>
>>>>>>>  is
>>>>>>>>>>>>>  done. Or alternatively, fire a timer instead of waking up a thread.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  Dear Gilles,
>>>>>>>>>>>>
>>>>>>>>>>>>  If what I have understood correctly, basically what you mean is
>>>>>>>
>>>>>>>  changing:
>>>>>>>>>>>>  while(!FLAG) ;
>>>>>>>>>>>>
>>>>>>>>>>>>  into
>>>>>>>>>>>>
>>>>>>>>>>>>  while(!FLAG)
>>>>>>>>>>>>           rtdm_task_sleep();
>>>>>>>>>>>>
>>>>>>>>>>>>  Xenomai's documentation that rtdm_task_sleep() can be always
>>>>>>>>>>>>  rescheduled. In my opinion
>>>>>>>>>>>>  this solution is sufficient and meets Xenomai requirements.
>>>>>>>>>>>
>>>>>>>>>>>  This solution will not work if the busy loop was in an irq handler.
>>>>>>>
>>>>>>>  You
>>>>>>>>>>>  can not call rtdm_task_sleep from the context of an irq handler.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  Ok, now I get your point.
>>>>>>>>>>
>>>>>>>>>>  However, what do you mean exactly by rescheduling while waiting? Do you
>>>>>>>>>>  mean something like
>>>>>>>>>>  putting all irq services into another thread and only in irq handler
>>>>>>>>>>  notify the separate thread
>>>>>>>>>>  to do the job accordingly?
>>>>>>>>>
>>>>>>>>>  Well, I do not know exactly, I have not looked at the details of the
>>>>>>>>>  driver, you are supposed to do that. But you may be able to split the
>>>>>>>>>  interrupt code in two parts: a first part that will run in interrupt
>>>>>>>>>  mode, and a second part that will run as a thread. The irq handler would
>>>>>>>>>  wake the thread up at the end of the first part, and return without
>>>>>>>>>  reenabling the interrupt at interrupt controller level. The thread would
>>>>>>>>>  execute, sleep during the I2C transfers as needed, and reenable the
>>>>>>>>>  interrupt before going back to sleep.
>>>>>>>>>
>>>>>>>>
>>>>>>>>  So would it be a good practise to create a new task for irq service with
>>>>>>>>
>>>>>>>>  rtdm_task_init();
>>>>>>>>
>>>>>>>>  inside attach function and join it with
>>>>>>>>
>>>>>>>>  rtdm_task_join_nrt();
>>>>>>>>
>>>>>>>>  inside detach function?
>>>>>>>
>>>>>>>  I do not know the details about analogy drivers, so, again, it is left
>>>>>>>  to you to read other analogy drivers and see where is the best place to
>>>>>>>  do what you want to do.
>>>>>>>
>>>>>>>
>>>>>>>  --
>>>>>>>  Gilles.
>>>>>>
>>>>>>  Dear Gilles,
>>>>>>
>>>>>>  I have altered the driver according to your advices.
>>>>>>  If I had omitted something please let me know.
>>>>>>
>>>>>>  Please find a patch enclosed in the attachment.
>>>>>>
>>>>>>  Best regards,
>>>>>>  Wojciech Domski
>>>>>>
>>>>>>  Domski.pl
>>>>>>
>>>>>>  Wojciech.Domski.pl
>>>>>>  -------------- next part --------------
>>>>>>  A non-text attachment was scrubbed...
>>>>>>  Name: s626_patch.patch
>>>>>>  Type: text/x-patch
>>>>>>  Size: 141659 bytes
>>>>>>  Desc: not available
>>>>>>  URL:
>>>>>>  <http://www.xenomai.org/pipermail/xenomai/attachments/20140410/e7191247/attachment.bin 
>>>>>
>>>>>  scripts/checkpatch.pl attchment.bin:
>>>>>
>>>>>  total: 325 errors, 392 warnings, 3991 lines checked
>>>>>
>>>>>  Please fix these errors.
>>>>>
>>>>
>>>>  Dear Gilles,
>>>>
>>>>  In the attachment you will find patch for xenomai including support for
>>>>  analogy Sensoray 626.
>>>>
>>>>  May I ask you to include this patch to main xenomai tree?
>>>>
>>>>  Best regards,
>>>>
>>>>  Wojciech Domski
>>>>
>>>>  Domski.pl
>>>>
>>>>  Wojciech.Domski.pl
>>>
>>>
>>>
>>>  Hi Wojciech
>>>
>>>  I did some changes to the patch that you sent and pushed it to my Xenomai 3 tree
>>>  (branch sensoray) as work in progress; however we have no means to test or
>>>  validate any of the changes.
>>>  http://git.xenomai.org/xenomai-jro.git/log/?h=sensoray
>>>
>>>  is this something that you can do? ie, do you have access to the sensoray device?
>>>
>>>  In any case after reviewing the Comedi implementation in 3.12 staging I think it
>>>  would make sense to base off that newer release instead.
>>>
>>>  jro
>>>
>>>
>>
>>  Thank you for committing the driver.
>>  I have access to the Sensoray 626 board and I will test the remarks you have
>>  proposed. It will take me sometime, however. First of all I would like to test my
>>  driver with two Sensoray boards. For now, I see that it won't work with more than
>>  one card. It requires some changes to the attach and probe function. After I
>>  implement this functionality I will take a look into the interrupt handling service.
>>
>>  Seizing the opportunity, I would like to ask you a question about handling PCI
>>  device. When I'm calling pci_register_driver() and I have two exactly the same PCI
>>  devices will this function call appropriate probe() function two times? If yes,
>>  then is the probe() function an appropriate place to make list of available devices?
>>
>>  Wojciech Domski
>>
>>  Domski.pl
>>
>>  Wojciech.Domski.pl
>>
>
>  invoking pci_register_driver in dev_s626_attach causes the probe interface in the
>  pci driver to be executed for all the devices of the kind described in the pci id
>  table; this is probably the reason why you can only register one.
>

of course, in case it was not clear, you can only register the pci driver once

>  It might be easier to follow the approach in analogy/national_instruments/mite.c
>
>  mite_init registers the driver which ends up calling mite_probe which will create a
>  mite_struct and add it to the list of mite_devices.
>  Incidentally if you were wondering, this is the reason why if the
>  pci_register_driver call succeeded the driver can display all the devices in the
>  system.
>
>  the same would need to be done for the s626
>
>  on a different note, we are adding a new interface to rtdm to support the busy loops.
>  rtdm_busywait_safe(__condition, __busy_delay, __busy_wait)
>
>  this should allow you to do things like this
>
>  -       while (!MC_TEST(P_MC2, MC2_UPLD_DEBI))
>  -               rtdm_task_sleep(2000);
>  +       ret = rtdm_busywait_safe(!MC_TEST(P_MC2, MC2_UPLD_DEBI), BUSY_DELAY,
>  BUSY_SLEEP);
>  +       if (ret)
>  +               __a4l_err( "error waiting");
>
> >
> >
> >
> >
> >
>

-- 
jro

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Jorge Ramirez Ortiz]

>>>  Thank you for committing the driver.
>>>  I have access to the Sensoray 626 board and I will test the remarks you have
>>>  proposed. It will take me sometime, however. First of all I would like to test my
>>>  driver with two Sensoray boards. For now, I see that it won't work with more than
>>>  one card. It requires some changes to the attach and probe function. After I
>>>  implement this functionality I will take a look into the interrupt handling 
>>> service.
>>>
>>>  Seizing the opportunity, I would like to ask you a question about handling PCI
>>>  device. When I'm calling pci_register_driver() and I have two exactly the same PCI
>>>  devices will this function call appropriate probe() function two times? If yes,
>>>  then is the probe() function an appropriate place to make list of available 
>>> devices?
>>>
>>>  Wojciech Domski
>>>
>>>  Domski.pl
>>>
>>>  Wojciech.Domski.pl
>>>
>>
>>  invoking pci_register_driver in dev_s626_attach causes the probe interface in the
>>  pci driver to be executed for all the devices of the kind described in the pci id
>>  table; this is probably the reason why you can only register one.
>>
>
> of course, in case it was not clear, you can only register the pci driver once
>
>>  It might be easier to follow the approach in analogy/national_instruments/mite.c


please have a look to the changes I pushed (untested). let me know if it helps with 
your issues.
http://git.xenomai.org/xenomai-jro.git/log/?h=sensoray

[note that this driver is still very much work in progress but I thought you'll need 
it sooner rather than later]

>>
>>  mite_init registers the driver which ends up calling mite_probe which will create a
>>  mite_struct and add it to the list of mite_devices.
>>  Incidentally if you were wondering, this is the reason why if the
>>  pci_register_driver call succeeded the driver can display all the devices in the
>>  system.
>>
>>  the same would need to be done for the s626
>>
>>  on a different note, we are adding a new interface to rtdm to support the busy 
>> loops.
>>  rtdm_busywait_safe(__condition, __busy_delay, __busy_wait)
>>
>>  this should allow you to do things like this
>>
>>  -       while (!MC_TEST(P_MC2, MC2_UPLD_DEBI))
>>  -               rtdm_task_sleep(2000);
>>  +       ret = rtdm_busywait_safe(!MC_TEST(P_MC2, MC2_UPLD_DEBI), BUSY_DELAY,
>>  BUSY_SLEEP);
>>  +       if (ret)
>>  +               __a4l_err( "error waiting");
>>
>>
>

-- 
jro

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Wojciech Domski]

W dniu 2014-07-16 21:03, Jorge Ramirez Ortiz pisze:
>
>>>>  Thank you for committing the driver.
>>>>  I have access to the Sensoray 626 board and I will test the 
>>>> remarks you have
>>>>  proposed. It will take me sometime, however. First of all I would 
>>>> like to test my
>>>>  driver with two Sensoray boards. For now, I see that it won't work 
>>>> with more than
>>>>  one card. It requires some changes to the attach and probe 
>>>> function. After I
>>>>  implement this functionality I will take a look into the interrupt 
>>>> handling service.
>>>>
>>>>  Seizing the opportunity, I would like to ask you a question about 
>>>> handling PCI
>>>>  device. When I'm calling pci_register_driver() and I have two 
>>>> exactly the same PCI
>>>>  devices will this function call appropriate probe() function two 
>>>> times? If yes,
>>>>  then is the probe() function an appropriate place to make list of 
>>>> available devices?
>>>>
>>>>  Wojciech Domski
>>>>
>>>>  Domski.pl
>>>>
>>>>  Wojciech.Domski.pl
>>>>
>>>
>>>  invoking pci_register_driver in dev_s626_attach causes the probe 
>>> interface in the
>>>  pci driver to be executed for all the devices of the kind described 
>>> in the pci id
>>>  table; this is probably the reason why you can only register one.
>>>
>>
>> of course, in case it was not clear, you can only register the pci 
>> driver once
>>
>>>  It might be easier to follow the approach in 
>>> analogy/national_instruments/mite.c
>
>
> please have a look to the changes I pushed (untested). let me know if 
> it helps with your issues.
> http://git.xenomai.org/xenomai-jro.git/log/?h=sensoray
>
> [note that this driver is still very much work in progress but I 
> thought you'll need it sooner rather than later]
>
>>>
>>>  mite_init registers the driver which ends up calling mite_probe 
>>> which will create a
>>>  mite_struct and add it to the list of mite_devices.
>>>  Incidentally if you were wondering, this is the reason why if the
>>>  pci_register_driver call succeeded the driver can display all the 
>>> devices in the
>>>  system.
>>>
>>>  the same would need to be done for the s626
>>>
>>>  on a different note, we are adding a new interface to rtdm to 
>>> support the busy loops.
>>>  rtdm_busywait_safe(__condition, __busy_delay, __busy_wait)
>>>
>>>  this should allow you to do things like this
>>>
>>>  -       while (!MC_TEST(P_MC2, MC2_UPLD_DEBI))
>>>  -               rtdm_task_sleep(2000);
>>>  +       ret = rtdm_busywait_safe(!MC_TEST(P_MC2, MC2_UPLD_DEBI), 
>>> BUSY_DELAY,
>>>  BUSY_SLEEP);
>>>  +       if (ret)
>>>  +               __a4l_err( "error waiting");
>>>
>>>
>>
>
Thank you for the patch. I will give it a try first thing tomorrow.

Wojciech Domski

Domski.pl

Wojciech.Domski.pl

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Wojciech Domski]

W dniu 2014-07-16 21:03, Jorge Ramirez Ortiz pisze:
>
>>>>  Thank you for committing the driver.
>>>>  I have access to the Sensoray 626 board and I will test the 
>>>> remarks you have
>>>>  proposed. It will take me sometime, however. First of all I would 
>>>> like to test my
>>>>  driver with two Sensoray boards. For now, I see that it won't work 
>>>> with more than
>>>>  one card. It requires some changes to the attach and probe 
>>>> function. After I
>>>>  implement this functionality I will take a look into the interrupt 
>>>> handling service.
>>>>
>>>>  Seizing the opportunity, I would like to ask you a question about 
>>>> handling PCI
>>>>  device. When I'm calling pci_register_driver() and I have two 
>>>> exactly the same PCI
>>>>  devices will this function call appropriate probe() function two 
>>>> times? If yes,
>>>>  then is the probe() function an appropriate place to make list of 
>>>> available devices?
>>>>
>>>>  Wojciech Domski
>>>>
>>>>  Domski.pl
>>>>
>>>>  Wojciech.Domski.pl
>>>>
>>>
>>>  invoking pci_register_driver in dev_s626_attach causes the probe 
>>> interface in the
>>>  pci driver to be executed for all the devices of the kind described 
>>> in the pci id
>>>  table; this is probably the reason why you can only register one.
>>>
>>
>> of course, in case it was not clear, you can only register the pci 
>> driver once
>>
>>>  It might be easier to follow the approach in 
>>> analogy/national_instruments/mite.c
>
>
> please have a look to the changes I pushed (untested). let me know if 
> it helps with your issues.
> http://git.xenomai.org/xenomai-jro.git/log/?h=sensoray
>
> [note that this driver is still very much work in progress but I 
> thought you'll need it sooner rather than later]
>
>>>
>>>  mite_init registers the driver which ends up calling mite_probe 
>>> which will create a
>>>  mite_struct and add it to the list of mite_devices.
>>>  Incidentally if you were wondering, this is the reason why if the
>>>  pci_register_driver call succeeded the driver can display all the 
>>> devices in the
>>>  system.
>>>
>>>  the same would need to be done for the s626
>>>
>>>  on a different note, we are adding a new interface to rtdm to 
>>> support the busy loops.
>>>  rtdm_busywait_safe(__condition, __busy_delay, __busy_wait)
>>>
>>>  this should allow you to do things like this
>>>
>>>  -       while (!MC_TEST(P_MC2, MC2_UPLD_DEBI))
>>>  -               rtdm_task_sleep(2000);
>>>  +       ret = rtdm_busywait_safe(!MC_TEST(P_MC2, MC2_UPLD_DEBI), 
>>> BUSY_DELAY,
>>>  BUSY_SLEEP);
>>>  +       if (ret)
>>>  +               __a4l_err( "error waiting");
>>>
>>>
>>
>
Today I have tested the driver against working with multiple Sensoray 
626 cards.
However, there are still some issues with I have to deal with.

The patch which you have Jorge delivered was of much help to me. 
However, there were some issues which I had to fix. Really minor stuff.

As for the irq service I didn't have time to check it because I'm 
running Xenomai 2.6.3.

Wojciech Domski

Domski.pl

Wojciech.Domski.pl

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Jorge Ramirez Ortiz]

On 07/17/2014 02:59 PM, Wojciech Domski wrote:
> W dniu 2014-07-16 21:03, Jorge Ramirez Ortiz pisze:
>>
>>>>>  Thank you for committing the driver.
>>>>>  I have access to the Sensoray 626 board and I will test the remarks you have
>>>>>  proposed. It will take me sometime, however. First of all I would like to test my
>>>>>  driver with two Sensoray boards. For now, I see that it won't work with more than
>>>>>  one card. It requires some changes to the attach and probe function. After I
>>>>>  implement this functionality I will take a look into the interrupt handling 
>>>>> service.
>>>>>
>>>>>  Seizing the opportunity, I would like to ask you a question about handling PCI
>>>>>  device. When I'm calling pci_register_driver() and I have two exactly the same 
>>>>> PCI
>>>>>  devices will this function call appropriate probe() function two times? If yes,
>>>>>  then is the probe() function an appropriate place to make list of available 
>>>>> devices?
>>>>>
>>>>>  Wojciech Domski
>>>>>
>>>>>  Domski.pl
>>>>>
>>>>>  Wojciech.Domski.pl
>>>>>
>>>>
>>>>  invoking pci_register_driver in dev_s626_attach causes the probe interface in the
>>>>  pci driver to be executed for all the devices of the kind described in the pci id
>>>>  table; this is probably the reason why you can only register one.
>>>>
>>>
>>> of course, in case it was not clear, you can only register the pci driver once
>>>
>>>>  It might be easier to follow the approach in analogy/national_instruments/mite.c
>>
>>
>> please have a look to the changes I pushed (untested). let me know if it helps 
>> with your issues.
>> http://git.xenomai.org/xenomai-jro.git/log/?h=sensoray
>>
>> [note that this driver is still very much work in progress but I thought you'll 
>> need it sooner rather than later]
>>
>>>>
>>>>  mite_init registers the driver which ends up calling mite_probe which will 
>>>> create a
>>>>  mite_struct and add it to the list of mite_devices.
>>>>  Incidentally if you were wondering, this is the reason why if the
>>>>  pci_register_driver call succeeded the driver can display all the devices in the
>>>>  system.
>>>>
>>>>  the same would need to be done for the s626
>>>>
>>>>  on a different note, we are adding a new interface to rtdm to support the busy 
>>>> loops.
>>>>  rtdm_busywait_safe(__condition, __busy_delay, __busy_wait)
>>>>
>>>>  this should allow you to do things like this
>>>>
>>>>  -       while (!MC_TEST(P_MC2, MC2_UPLD_DEBI))
>>>>  -               rtdm_task_sleep(2000);
>>>>  +       ret = rtdm_busywait_safe(!MC_TEST(P_MC2, MC2_UPLD_DEBI), BUSY_DELAY,
>>>>  BUSY_SLEEP);
>>>>  +       if (ret)
>>>>  +               __a4l_err( "error waiting");
>>>>
>>>>
>>>
>>
> Today I have tested the driver against working with multiple Sensoray 626 cards.
> However, there are still some issues with I have to deal with.
>
> The patch which you have Jorge delivered was of much help to me. However, there 
> were some issues which I had to fix. Really minor stuff.

sounds good. please don't forget to share with us your updates so we can push them to 
the tree.

>
> As for the irq service I didn't have time to check it because I'm running Xenomai 
> 2.6.3.
>
> Wojciech Domski
>
> Domski.pl
>
> Wojciech.Domski.pl
>
>


-- 
jro

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Wojciech Domski]

I prepared the driver to work well with multiple Sensoray 626 and I tested
it with two of those. I have a problem, however.
I suspect that the analogy interface doesn't play along with the driver but
I'm not certain about that. Here what's happening.
I have two s626 cards: s0 and s1. For the sake of conversation let's assume
that analogy device analogy0 is a0 and so on.
When I link s0 to a0, unlink, link s1 to a1, unlink everything works fine,
however. Once more when I link s0 but this time to a1 something goes wrong.
I get -16 error from a4l_sys_attach() which is

No such device

What is the reason of this happening? I do clean everything every time when
I release s626.
Here is what I do when I want to open my device:

a4l_sys_open();
a4l_sys_attach();
a4l_open();
rt_dev_open();
a4l_fill_desc();

When I close the s626 I do:

rt_dev_close();
a4l_close();
a4l_sys_detach();
a4l_sys_close();

Best regards,
Wojciech Domski

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Jorge Ramirez Ortiz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/31/2014 05:22 AM, Wojciech Domski wrote:
 I prepared the driver to work well with multiple Sensoray 626 and I tested
 it with two of those. I have a problem, however.
 I suspect that the analogy interface doesn't play along with the driver but
 I'm not certain about that. Here what's happening.
 I have two s626 cards: s0 and s1. For the sake of conversation let's assume
 that analogy device analogy0 is a0 and so on.
 When I link s0 to a0, unlink, link s1 to a1, unlink everything works fine,
 however. Once more when I link s0 but this time to a1 something goes wrong.
 I get -16 error from a4l_sys_attach() which is

 No such device

 What is the reason of this happening? I do clean everything every time when
 I release s626.
 Here is what I do when I want to open my device:

 a4l_sys_open();
 a4l_sys_attach();
 a4l_open();
 rt_dev_open();
 a4l_fill_desc();

 When I close the s626 I do:

 rt_dev_close();
 a4l_close();
 a4l_sys_detach();
 a4l_sys_close();

 Best regards,
 Wojciech Domski

- ------------------

please could you send the driver and the kernel traces for the experiment?


- -- 
jro

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT2qOQAAoJECDcy2IJkagRnH0H/3j3VgCu8KSUfOBYzC7McFxg
my+hW6i+FFNn3kpJJ2/EQtmg/pFGdenIwd/Uu8XJhwaLfT0mtP67b8GDuD/BsPGp
lVyuFeznew6gN+usGnQe48sEUCnpadlwI/ZIjcZhJqmcVzwUw991RvA32l6Z9x3/
biYv9N0QiaEpp3c0rWAApnHetsun7rFxGuzgAq2pB+adeWCOSTtOpYEado7qOrEx
FyBj8Gh1sc7kMLnyml/UXgLBvxsaSUXq81t1QwaOOZS4TQLtg/HstHMlTvqrS6k2
WsbhmS5qqmKBIKeEjWUl6d5S3TKfW+XjaY3JVFlN8p6EPS3LUl5SkxqzH/Zavfw=
=+hI6
-----END PGP SIGNATURE-----

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Wojciech Domski]

Dear Jorge,

In attachment you can find the dump file. I created it with strace. I hope
this is what you meant.

Also I forgot to tell one more thing. When I try to relink s1 to a0 I get
this message from the driver:
S626 0000:02:05.0: BAR 0: can't reserve [mem 0xf7b00000-0xf7b001ff]
This is the result of pci_request_regions() function in attach.

Here is also the sample application which I have written to test it.

ts626 * s626;
  ts626 * s626_2;

  printf("Opening a0 with s0\n");
  s626 = s626_init("S626", "analogy0");
    s626_set_options(s626);
     s626_set_bus(s626, 2);
     s626_set_slot(s626, 4);
     s626_open(s626);

     printf("Opening a1 with s1\n");
  s626_2 = s626_init("S626", "analogy1");
    s626_set_options(s626_2);
     s626_set_bus(s626_2, 2);
     s626_set_slot(s626_2, 5);
     s626_open(s626_2);

     printf("Closing a0 with s0\n");
    s626_close( s626);
    s626_deinit( s626);
    s626 = NULL;

    printf("Closing a1 with s1\n");
    s626_close( s626_2);
    s626_deinit( s626_2);
    s626_2 = NULL;

  printf("Opening a0 with s1\n");
  s626 = s626_init("S626", "analogy0");
    s626_set_options(s626);
     s626_set_bus(s626, 2);
     s626_set_slot(s626, 5);
     s626_open(s626);

    printf("Closing a0 with s1\n");
    s626_close( s626);
    s626_deinit( s626);
    s626 = NULL;

Best regards,
Wojciech Domski


2014-07-31 22:14 GMT+02:00 Jorge Ramirez Ortiz <jro@xenomai.org>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/31/2014 05:22 AM, Wojciech Domski wrote:
>  I prepared the driver to work well with multiple Sensoray 626 and I tested
>  it with two of those. I have a problem, however.
>  I suspect that the analogy interface doesn't play along with the driver
> but
>  I'm not certain about that. Here what's happening.
>  I have two s626 cards: s0 and s1. For the sake of conversation let's
> assume
>  that analogy device analogy0 is a0 and so on.
>  When I link s0 to a0, unlink, link s1 to a1, unlink everything works fine,
>  however. Once more when I link s0 but this time to a1 something goes
> wrong.
>  I get -16 error from a4l_sys_attach() which is
>
>  No such device
>
>  What is the reason of this happening? I do clean everything every time
> when
>  I release s626.
>  Here is what I do when I want to open my device:
>
>  a4l_sys_open();
>  a4l_sys_attach();
>  a4l_open();
>  rt_dev_open();
>  a4l_fill_desc();
>
>  When I close the s626 I do:
>
>  rt_dev_close();
>  a4l_close();
>  a4l_sys_detach();
>  a4l_sys_close();
>
>  Best regards,
>  Wojciech Domski
>
> - ------------------
>
> please could you send the driver and the kernel traces for the experiment?
>
>
> - --
> jro
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJT2qOQAAoJECDcy2IJkagRnH0H/3j3VgCu8KSUfOBYzC7McFxg
> my+hW6i+FFNn3kpJJ2/EQtmg/pFGdenIwd/Uu8XJhwaLfT0mtP67b8GDuD/BsPGp
> lVyuFeznew6gN+usGnQe48sEUCnpadlwI/ZIjcZhJqmcVzwUw991RvA32l6Z9x3/
> biYv9N0QiaEpp3c0rWAApnHetsun7rFxGuzgAq2pB+adeWCOSTtOpYEado7qOrEx
> FyBj8Gh1sc7kMLnyml/UXgLBvxsaSUXq81t1QwaOOZS4TQLtg/HstHMlTvqrS6k2
> WsbhmS5qqmKBIKeEjWUl6d5S3TKfW+XjaY3JVFlN8p6EPS3LUl5SkxqzH/Zavfw=
> =+hI6
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump
Type: application/octet-stream
Size: 178 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140801/c7477de8/attachment.obj>

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Jorge Ramirez Ortiz]

On 08/01/2014 07:33 AM, Wojciech Domski wrote:
> Dear Jorge,
>
> In attachment you can find the dump file. I created it with strace. I hope
> this is what you meant.

I actually meant the kernel traces.
Please when compiling the analogy drivers if you could set the analogy driver and 
core debug level thresolds to 10 that would be all.
Then attach the output of $dmesg to your email.


>
> Also I forgot to tell one more thing. When I try to relink s1 to a0 I get
> this message from the driver:
> S626 0000:02:05.0: BAR 0: can't reserve [mem 0xf7b00000-0xf7b001ff]

maybe you didnt release the device properly. Please could you send the code as well?


> This is the result of pci_request_regions() function in attach.
>
> Here is also the sample application which I have written to test it.
>
> ts626 * s626;
>    ts626 * s626_2;
>
>    printf("Opening a0 with s0\n");
>    s626 = s626_init("S626", "analogy0");
>      s626_set_options(s626);
>       s626_set_bus(s626, 2);
>       s626_set_slot(s626, 4);
>       s626_open(s626);
>
>       printf("Opening a1 with s1\n");
>    s626_2 = s626_init("S626", "analogy1");
>      s626_set_options(s626_2);
>       s626_set_bus(s626_2, 2);
>       s626_set_slot(s626_2, 5);
>       s626_open(s626_2);
>
>       printf("Closing a0 with s0\n");
>      s626_close( s626);
>      s626_deinit( s626);
>      s626 = NULL;
>
>      printf("Closing a1 with s1\n");
>      s626_close( s626_2);
>      s626_deinit( s626_2);
>      s626_2 = NULL;
>
>    printf("Opening a0 with s1\n");
>    s626 = s626_init("S626", "analogy0");
>      s626_set_options(s626);
>       s626_set_bus(s626, 2);
>       s626_set_slot(s626, 5);
>       s626_open(s626);
>
>      printf("Closing a0 with s1\n");
>      s626_close( s626);
>      s626_deinit( s626);
>      s626 = NULL;
>
> Best regards,
> Wojciech Domski
>
>
> 2014-07-31 22:14 GMT+02:00 Jorge Ramirez Ortiz <jro@xenomai.org>:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 07/31/2014 05:22 AM, Wojciech Domski wrote:
>>   I prepared the driver to work well with multiple Sensoray 626 and I tested
>>   it with two of those. I have a problem, however.
>>   I suspect that the analogy interface doesn't play along with the driver
>> but
>>   I'm not certain about that. Here what's happening.
>>   I have two s626 cards: s0 and s1. For the sake of conversation let's
>> assume
>>   that analogy device analogy0 is a0 and so on.
>>   When I link s0 to a0, unlink, link s1 to a1, unlink everything works fine,
>>   however. Once more when I link s0 but this time to a1 something goes
>> wrong.
>>   I get -16 error from a4l_sys_attach() which is
>>
>>   No such device
>>
>>   What is the reason of this happening? I do clean everything every time
>> when
>>   I release s626.
>>   Here is what I do when I want to open my device:
>>
>>   a4l_sys_open();
>>   a4l_sys_attach();
>>   a4l_open();
>>   rt_dev_open();
>>   a4l_fill_desc();
>>
>>   When I close the s626 I do:
>>
>>   rt_dev_close();
>>   a4l_close();
>>   a4l_sys_detach();
>>   a4l_sys_close();
>>
>>   Best regards,
>>   Wojciech Domski
>>
>> - ------------------
>>
>> please could you send the driver and the kernel traces for the experiment?
>>
>>
>> - --
>> jro
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJT2qOQAAoJECDcy2IJkagRnH0H/3j3VgCu8KSUfOBYzC7McFxg
>> my+hW6i+FFNn3kpJJ2/EQtmg/pFGdenIwd/Uu8XJhwaLfT0mtP67b8GDuD/BsPGp
>> lVyuFeznew6gN+usGnQe48sEUCnpadlwI/ZIjcZhJqmcVzwUw991RvA32l6Z9x3/
>> biYv9N0QiaEpp3c0rWAApnHetsun7rFxGuzgAq2pB+adeWCOSTtOpYEado7qOrEx
>> FyBj8Gh1sc7kMLnyml/UXgLBvxsaSUXq81t1QwaOOZS4TQLtg/HstHMlTvqrS6k2
>> WsbhmS5qqmKBIKeEjWUl6d5S3TKfW+XjaY3JVFlN8p6EPS3LUl5SkxqzH/Zavfw=
>> =+hI6
>> -----END PGP SIGNATURE-----
>>
>

-- 
jro

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Wojciech Domski]

I did recompile xeno_analogy kernel module with thresholds both set to 10
so now everything should be ok.
Here is the dmesg output:

[  110.899150] Analogy: a4l_add_drv: name=S626
[  110.899154] Analogy: a4l_lct_drv: name=S626
[  110.899168] Analogy: Probing for s626
[  110.899185] Analogy: Probing for s626
[  119.703343] Analogy: a4l_lct_drv: name=S626
[  119.703347] Analogy: S626: Attaching s626
[  119.703349] Analogy: S626: Desired Bus: 2, Slot: 4
[  119.703351] Analogy: S626: Has Bus: 2, Slot: 4
[  119.703353] Analogy: S626: PCI dev = ffff880211c72000
[  119.703354] Analogy: S626: PCI set master
[  119.703361] Analogy: S626: PCI region request
[  119.703366] Analogy: S626: PCI ioremap
[  119.703398] Analogy: S626: disable master interrupt
[  119.703400] Analogy: S626: DMA
[  119.703405] Analogy: S626: RTDM irq
[  119.703417] Analogy: S626: RTDM irq request
[  119.703428] Analogy: S626: subdevices allocation
[  119.703432] Analogy: S626: card initialization
[  119.718902] Analogy: S626: Driver ready
[  119.718905] Analogy: a4l_setup_transfer: nb_subd=6
[  119.719039] Analogy: a4l_lct_drv: name=S626
[  119.719041] Analogy: S626: Attaching s626
[  119.719042] Analogy: S626: Desired Bus: 2, Slot: 5
[  119.719044] Analogy: S626: Has Bus: 2, Slot: 5
[  119.719045] Analogy: S626: PCI dev = ffff880211c73000
[  119.719046] Analogy: S626: PCI set master
[  119.719053] Analogy: S626: PCI region request
[  119.719055] Analogy: S626: PCI ioremap
[  119.719067] Analogy: S626: disable master interrupt
[  119.719068] Analogy: S626: DMA
[  119.719071] Analogy: S626: RTDM irq
[  119.719080] Analogy: S626: RTDM irq request
[  119.719087] Analogy: S626: subdevices allocation
[  119.719090] Analogy: S626: card initialization
[  119.734596] Analogy: S626: Driver ready
[  119.734598] Analogy: a4l_setup_transfer: nb_subd=6
[  119.734735] Analogy: a4l_precleanup_transfer: subd[0]->status=0x00000000
[  119.734736] Analogy: a4l_precleanup_transfer: subd[1]->status=0x00000000
[  119.734738] Analogy: a4l_precleanup_transfer: subd[2]->status=0x00000000
[  119.734739] Analogy: a4l_precleanup_transfer: subd[3]->status=0x00000000
[  119.734740] Analogy: a4l_precleanup_transfer: subd[4]->status=0x00000000
[  119.734742] Analogy: a4l_precleanup_transfer: subd[5]->status=0x00000000
[  119.734745] Analogy: S626: Detaching s626
[  119.734747] Analogy: S626: Cleaning private
[  119.734767] Analogy: S626: Handling irq
[  119.938140] Analogy: S626: Releasing PCI regions
[  119.938147] Analogy: S626: Removing private
[  119.938149] Analogy: S626: Detaching completed
[  119.938276] Analogy: a4l_lct_drv: name=S626
[  119.938278] Analogy: S626: Attaching s626
[  119.938280] Analogy: S626: Desired Bus: 2, Slot: 5
[  119.938282] Analogy: S626: Has Bus: 2, Slot: 5
[  119.938283] Analogy: S626: PCI dev = ffff880211c73000
[  119.938285] Analogy: S626: PCI set master
[  119.938292] Analogy: S626: PCI region request
[  119.938298] S626 0000:02:05.0: BAR 0: can't reserve [mem
0xf7b00000-0xf7b001ff]
[  119.938299] Analogy: Can't request regions
[  119.938301] Analogy: a4l_assign_driver: call(drv->attach) failed
(ret=-12)
[  120.142476] Xenomai: RTDM: closing file descriptor 3.

Also in the attachment is the patch for the xenomai 2.6.3 for support of
multiple s626 cards. Also I have attached the simple testing program
(app.c) and API which I've written to make the interaction with s626 easier.

Please let me know if you come up with something.


2014-08-01 16:48 GMT+02:00 Jorge Ramirez Ortiz <jro@xenomai.org>:

> On 08/01/2014 07:33 AM, Wojciech Domski wrote:
>
>> Dear Jorge,
>>
>> In attachment you can find the dump file. I created it with strace. I hope
>> this is what you meant.
>>
>
> I actually meant the kernel traces.
> Please when compiling the analogy drivers if you could set the analogy
> driver and core debug level thresolds to 10 that would be all.
> Then attach the output of $dmesg to your email.
>
>
>
>
>> Also I forgot to tell one more thing. When I try to relink s1 to a0 I get
>> this message from the driver:
>> S626 0000:02:05.0: BAR 0: can't reserve [mem 0xf7b00000-0xf7b001ff]
>>
>
> maybe you didnt release the device properly. Please could you send the
> code as well?
>
>
>
>  This is the result of pci_request_regions() function in attach.
>>
>> Here is also the sample application which I have written to test it.
>>
>> ts626 * s626;
>>    ts626 * s626_2;
>>
>>    printf("Opening a0 with s0\n");
>>    s626 = s626_init("S626", "analogy0");
>>      s626_set_options(s626);
>>       s626_set_bus(s626, 2);
>>       s626_set_slot(s626, 4);
>>       s626_open(s626);
>>
>>       printf("Opening a1 with s1\n");
>>    s626_2 = s626_init("S626", "analogy1");
>>      s626_set_options(s626_2);
>>       s626_set_bus(s626_2, 2);
>>       s626_set_slot(s626_2, 5);
>>       s626_open(s626_2);
>>
>>       printf("Closing a0 with s0\n");
>>      s626_close( s626);
>>      s626_deinit( s626);
>>      s626 = NULL;
>>
>>      printf("Closing a1 with s1\n");
>>      s626_close( s626_2);
>>      s626_deinit( s626_2);
>>      s626_2 = NULL;
>>
>>    printf("Opening a0 with s1\n");
>>    s626 = s626_init("S626", "analogy0");
>>      s626_set_options(s626);
>>       s626_set_bus(s626, 2);
>>       s626_set_slot(s626, 5);
>>       s626_open(s626);
>>
>>      printf("Closing a0 with s1\n");
>>      s626_close( s626);
>>      s626_deinit( s626);
>>      s626 = NULL;
>>
>> Best regards,
>> Wojciech Domski
>>
>>
>> 2014-07-31 22:14 GMT+02:00 Jorge Ramirez Ortiz <jro@xenomai.org>:
>>
>>  -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 07/31/2014 05:22 AM, Wojciech Domski wrote:
>>>   I prepared the driver to work well with multiple Sensoray 626 and I
>>> tested
>>>   it with two of those. I have a problem, however.
>>>   I suspect that the analogy interface doesn't play along with the driver
>>> but
>>>   I'm not certain about that. Here what's happening.
>>>   I have two s626 cards: s0 and s1. For the sake of conversation let's
>>> assume
>>>   that analogy device analogy0 is a0 and so on.
>>>   When I link s0 to a0, unlink, link s1 to a1, unlink everything works
>>> fine,
>>>   however. Once more when I link s0 but this time to a1 something goes
>>> wrong.
>>>   I get -16 error from a4l_sys_attach() which is
>>>
>>>   No such device
>>>
>>>   What is the reason of this happening? I do clean everything every time
>>> when
>>>   I release s626.
>>>   Here is what I do when I want to open my device:
>>>
>>>   a4l_sys_open();
>>>   a4l_sys_attach();
>>>   a4l_open();
>>>   rt_dev_open();
>>>   a4l_fill_desc();
>>>
>>>   When I close the s626 I do:
>>>
>>>   rt_dev_close();
>>>   a4l_close();
>>>   a4l_sys_detach();
>>>   a4l_sys_close();
>>>
>>>   Best regards,
>>>   Wojciech Domski
>>>
>>> - ------------------
>>>
>>> please could you send the driver and the kernel traces for the
>>> experiment?
>>>
>>>
>>> - --
>>> jro
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>
>>> iQEcBAEBAgAGBQJT2qOQAAoJECDcy2IJkagRnH0H/3j3VgCu8KSUfOBYzC7McFxg
>>> my+hW6i+FFNn3kpJJ2/EQtmg/pFGdenIwd/Uu8XJhwaLfT0mtP67b8GDuD/BsPGp
>>> lVyuFeznew6gN+usGnQe48sEUCnpadlwI/ZIjcZhJqmcVzwUw991RvA32l6Z9x3/
>>> biYv9N0QiaEpp3c0rWAApnHetsun7rFxGuzgAq2pB+adeWCOSTtOpYEado7qOrEx
>>> FyBj8Gh1sc7kMLnyml/UXgLBvxsaSUXq81t1QwaOOZS4TQLtg/HstHMlTvqrS6k2
>>> WsbhmS5qqmKBIKeEjWUl6d5S3TKfW+XjaY3JVFlN8p6EPS3LUl5SkxqzH/Zavfw=
>>> =+hI6
>>> -----END PGP SIGNATURE-----
>>>
>>>
>>
> --
> jro
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s626n.patch
Type: text/x-patch
Size: 144321 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140805/3cdffafe/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: app.c
Type: text/x-csrc
Size: 2503 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140805/3cdffafe/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S626API.c
Type: text/x-csrc
Size: 8851 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140805/3cdffafe/attachment-0001.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S626API.h
Type: text/x-chdr
Size: 3147 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140805/3cdffafe/attachment.h>

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Wojciech Domski]

Ok, there was a problem with closing the descriptor on the side of API (new
file in attachment). I have resolved it but now I have problem with IRQ.
Here is what dmesg says:

[  103.942431] Analogy: a4l_add_drv: name=S626
[  103.942434] Analogy: a4l_lct_drv: name=S626
[  103.942450] Analogy: Probing for s626
[  103.942469] Analogy: Probing for s626
[  115.764941] Analogy: a4l_lct_drv: name=S626
[  115.764945] Analogy: S626: Attaching s626
[  115.764947] Analogy: S626: Desired Bus: 2, Slot: 4
[  115.764949] Analogy: S626: Has Bus: 2, Slot: 4
[  115.764951] Analogy: S626: PCI dev = ffff880211c72000
[  115.764952] Analogy: S626: PCI set master
[  115.764960] Analogy: S626: PCI region request
[  115.764964] Analogy: S626: PCI ioremap
[  115.764997] Analogy: S626: disable master interrupt
[  115.764998] Analogy: S626: DMA
[  115.765004] Analogy: S626: RTDM irq
[  115.765016] Analogy: S626: RTDM irq request
[  115.765027] Analogy: S626: subdevices allocation
[  115.765031] Analogy: S626: card initialization
[  115.780513] Analogy: S626: Driver ready
[  115.780516] Analogy: a4l_setup_transfer: nb_subd=6
[  119.620570] Analogy: a4l_lct_drv: name=S626
[  119.620575] Analogy: S626: Attaching s626
[  119.620579] Analogy: S626: Desired Bus: 2, Slot: 5
[  119.620581] Analogy: S626: Has Bus: 2, Slot: 5
[  119.620583] Analogy: S626: PCI dev = ffff880211c73000
[  119.620584] Analogy: S626: PCI set master
[  119.620592] Analogy: S626: PCI region request
[  119.620596] Analogy: S626: PCI ioremap
[  119.620630] Analogy: S626: disable master interrupt
[  119.620632] Analogy: S626: DMA
[  119.620635] Analogy: S626: RTDM irq
[  119.620644] Analogy: S626: RTDM irq request
[  119.620655] Analogy: S626: subdevices allocation
[  119.620659] Analogy: S626: card initialization
[  119.636135] Analogy: S626: Driver ready
[  119.636139] Analogy: a4l_setup_transfer: nb_subd=6
[  121.908284] Analogy: a4l_precleanup_transfer: subd[0]->status=0x00000000
[  121.908287] Analogy: a4l_precleanup_transfer: subd[1]->status=0x00000000
[  121.908289] Analogy: a4l_precleanup_transfer: subd[2]->status=0x00000000
[  121.908290] Analogy: a4l_precleanup_transfer: subd[3]->status=0x00000000
[  121.908291] Analogy: a4l_precleanup_transfer: subd[4]->status=0x00000000
[  121.908293] Analogy: a4l_precleanup_transfer: subd[5]->status=0x00000000
[  121.908298] Analogy: S626: Detaching s626
[  121.908300] Analogy: S626: Cleaning private
[  121.908322] Analogy: S626: Handling irq
[  122.111663] Analogy: S626: Releasing PCI regions
[  122.111670] Analogy: S626: Removing private
[  122.111671] Analogy: S626: Detaching completed
[  124.081687] Analogy: a4l_precleanup_transfer: subd[0]->status=0x00000000
[  124.081691] Analogy: a4l_precleanup_transfer: subd[1]->status=0x00000000
[  124.081692] Analogy: a4l_precleanup_transfer: subd[2]->status=0x00000000
[  124.081694] Analogy: a4l_precleanup_transfer: subd[3]->status=0x00000000
[  124.081695] Analogy: a4l_precleanup_transfer: subd[4]->status=0x00000000
[  124.081696] Analogy: a4l_precleanup_transfer: subd[5]->status=0x00000000
[  124.081702] Analogy: S626: Detaching s626
[  124.081704] Analogy: S626: Cleaning private
[  124.081726] Analogy: S626: Handling irq
[  124.283848] Analogy: S626: Releasing PCI regions
[  124.283855] Analogy: S626: Removing private
[  124.283856] Analogy: S626: Detaching completed
[  127.376882] Analogy: a4l_lct_drv: name=S626
[  127.376887] Analogy: S626: Attaching s626
[  127.376888] Analogy: S626: Desired Bus: 2, Slot: 5
[  127.376890] Analogy: S626: Has Bus: 2, Slot: 5
[  127.376893] Analogy: S626: PCI dev = ffff880211c73000
[  127.376894] Analogy: S626: PCI set master
[  127.376901] Analogy: S626: PCI region request
[  127.376905] Analogy: S626: PCI ioremap
[  127.376961] Analogy: S626: disable master interrupt
[  127.376962] Analogy: S626: DMA
[  127.376968] Analogy: S626: RTDM irq
[  127.376983] Analogy: S626: RTDM irq request
[  127.376992] Analogy: a4l_assign_driver: call(drv->attach) failed
(ret=-16)
[  127.376994] Analogy: a4l_request_irq: IRQ registration failed



2014-08-05 11:20 GMT+02:00 Wojciech Domski <wojciech.domski@gmail.com>:

> I did recompile xeno_analogy kernel module with thresholds both set to 10
> so now everything should be ok.
> Here is the dmesg output:
>
> [  110.899150] Analogy: a4l_add_drv: name=S626
> [  110.899154] Analogy: a4l_lct_drv: name=S626
> [  110.899168] Analogy: Probing for s626
> [  110.899185] Analogy: Probing for s626
> [  119.703343] Analogy: a4l_lct_drv: name=S626
> [  119.703347] Analogy: S626: Attaching s626
> [  119.703349] Analogy: S626: Desired Bus: 2, Slot: 4
> [  119.703351] Analogy: S626: Has Bus: 2, Slot: 4
> [  119.703353] Analogy: S626: PCI dev = ffff880211c72000
> [  119.703354] Analogy: S626: PCI set master
> [  119.703361] Analogy: S626: PCI region request
> [  119.703366] Analogy: S626: PCI ioremap
> [  119.703398] Analogy: S626: disable master interrupt
> [  119.703400] Analogy: S626: DMA
> [  119.703405] Analogy: S626: RTDM irq
> [  119.703417] Analogy: S626: RTDM irq request
> [  119.703428] Analogy: S626: subdevices allocation
> [  119.703432] Analogy: S626: card initialization
> [  119.718902] Analogy: S626: Driver ready
> [  119.718905] Analogy: a4l_setup_transfer: nb_subd=6
> [  119.719039] Analogy: a4l_lct_drv: name=S626
> [  119.719041] Analogy: S626: Attaching s626
> [  119.719042] Analogy: S626: Desired Bus: 2, Slot: 5
> [  119.719044] Analogy: S626: Has Bus: 2, Slot: 5
> [  119.719045] Analogy: S626: PCI dev = ffff880211c73000
> [  119.719046] Analogy: S626: PCI set master
> [  119.719053] Analogy: S626: PCI region request
> [  119.719055] Analogy: S626: PCI ioremap
> [  119.719067] Analogy: S626: disable master interrupt
> [  119.719068] Analogy: S626: DMA
> [  119.719071] Analogy: S626: RTDM irq
> [  119.719080] Analogy: S626: RTDM irq request
> [  119.719087] Analogy: S626: subdevices allocation
> [  119.719090] Analogy: S626: card initialization
> [  119.734596] Analogy: S626: Driver ready
> [  119.734598] Analogy: a4l_setup_transfer: nb_subd=6
> [  119.734735] Analogy: a4l_precleanup_transfer: subd[0]->status=0x00000000
> [  119.734736] Analogy: a4l_precleanup_transfer: subd[1]->status=0x00000000
> [  119.734738] Analogy: a4l_precleanup_transfer: subd[2]->status=0x00000000
> [  119.734739] Analogy: a4l_precleanup_transfer: subd[3]->status=0x00000000
> [  119.734740] Analogy: a4l_precleanup_transfer: subd[4]->status=0x00000000
> [  119.734742] Analogy: a4l_precleanup_transfer: subd[5]->status=0x00000000
> [  119.734745] Analogy: S626: Detaching s626
> [  119.734747] Analogy: S626: Cleaning private
> [  119.734767] Analogy: S626: Handling irq
> [  119.938140] Analogy: S626: Releasing PCI regions
> [  119.938147] Analogy: S626: Removing private
> [  119.938149] Analogy: S626: Detaching completed
> [  119.938276] Analogy: a4l_lct_drv: name=S626
> [  119.938278] Analogy: S626: Attaching s626
> [  119.938280] Analogy: S626: Desired Bus: 2, Slot: 5
> [  119.938282] Analogy: S626: Has Bus: 2, Slot: 5
> [  119.938283] Analogy: S626: PCI dev = ffff880211c73000
> [  119.938285] Analogy: S626: PCI set master
> [  119.938292] Analogy: S626: PCI region request
> [  119.938298] S626 0000:02:05.0: BAR 0: can't reserve [mem
> 0xf7b00000-0xf7b001ff]
> [  119.938299] Analogy: Can't request regions
> [  119.938301] Analogy: a4l_assign_driver: call(drv->attach) failed
> (ret=-12)
> [  120.142476] Xenomai: RTDM: closing file descriptor 3.
>
> Also in the attachment is the patch for the xenomai 2.6.3 for support of
> multiple s626 cards. Also I have attached the simple testing program
> (app.c) and API which I've written to make the interaction with s626 easier.
>
> Please let me know if you come up with something.
>
>
> 2014-08-01 16:48 GMT+02:00 Jorge Ramirez Ortiz <jro@xenomai.org>:
>
> On 08/01/2014 07:33 AM, Wojciech Domski wrote:
>>
>>> Dear Jorge,
>>>
>>> In attachment you can find the dump file. I created it with strace. I
>>> hope
>>> this is what you meant.
>>>
>>
>> I actually meant the kernel traces.
>> Please when compiling the analogy drivers if you could set the analogy
>> driver and core debug level thresolds to 10 that would be all.
>> Then attach the output of $dmesg to your email.
>>
>>
>>
>>
>>> Also I forgot to tell one more thing. When I try to relink s1 to a0 I get
>>> this message from the driver:
>>> S626 0000:02:05.0: BAR 0: can't reserve [mem 0xf7b00000-0xf7b001ff]
>>>
>>
>> maybe you didnt release the device properly. Please could you send the
>> code as well?
>>
>>
>>
>>  This is the result of pci_request_regions() function in attach.
>>>
>>> Here is also the sample application which I have written to test it.
>>>
>>> ts626 * s626;
>>>    ts626 * s626_2;
>>>
>>>    printf("Opening a0 with s0\n");
>>>    s626 = s626_init("S626", "analogy0");
>>>      s626_set_options(s626);
>>>       s626_set_bus(s626, 2);
>>>       s626_set_slot(s626, 4);
>>>       s626_open(s626);
>>>
>>>       printf("Opening a1 with s1\n");
>>>    s626_2 = s626_init("S626", "analogy1");
>>>      s626_set_options(s626_2);
>>>       s626_set_bus(s626_2, 2);
>>>       s626_set_slot(s626_2, 5);
>>>       s626_open(s626_2);
>>>
>>>       printf("Closing a0 with s0\n");
>>>      s626_close( s626);
>>>      s626_deinit( s626);
>>>      s626 = NULL;
>>>
>>>      printf("Closing a1 with s1\n");
>>>      s626_close( s626_2);
>>>      s626_deinit( s626_2);
>>>      s626_2 = NULL;
>>>
>>>    printf("Opening a0 with s1\n");
>>>    s626 = s626_init("S626", "analogy0");
>>>      s626_set_options(s626);
>>>       s626_set_bus(s626, 2);
>>>       s626_set_slot(s626, 5);
>>>       s626_open(s626);
>>>
>>>      printf("Closing a0 with s1\n");
>>>      s626_close( s626);
>>>      s626_deinit( s626);
>>>      s626 = NULL;
>>>
>>> Best regards,
>>> Wojciech Domski
>>>
>>>
>>> 2014-07-31 22:14 GMT+02:00 Jorge Ramirez Ortiz <jro@xenomai.org>:
>>>
>>>  -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 07/31/2014 05:22 AM, Wojciech Domski wrote:
>>>>   I prepared the driver to work well with multiple Sensoray 626 and I
>>>> tested
>>>>   it with two of those. I have a problem, however.
>>>>   I suspect that the analogy interface doesn't play along with the
>>>> driver
>>>> but
>>>>   I'm not certain about that. Here what's happening.
>>>>   I have two s626 cards: s0 and s1. For the sake of conversation let's
>>>> assume
>>>>   that analogy device analogy0 is a0 and so on.
>>>>   When I link s0 to a0, unlink, link s1 to a1, unlink everything works
>>>> fine,
>>>>   however. Once more when I link s0 but this time to a1 something goes
>>>> wrong.
>>>>   I get -16 error from a4l_sys_attach() which is
>>>>
>>>>   No such device
>>>>
>>>>   What is the reason of this happening? I do clean everything every time
>>>> when
>>>>   I release s626.
>>>>   Here is what I do when I want to open my device:
>>>>
>>>>   a4l_sys_open();
>>>>   a4l_sys_attach();
>>>>   a4l_open();
>>>>   rt_dev_open();
>>>>   a4l_fill_desc();
>>>>
>>>>   When I close the s626 I do:
>>>>
>>>>   rt_dev_close();
>>>>   a4l_close();
>>>>   a4l_sys_detach();
>>>>   a4l_sys_close();
>>>>
>>>>   Best regards,
>>>>   Wojciech Domski
>>>>
>>>> - ------------------
>>>>
>>>> please could you send the driver and the kernel traces for the
>>>> experiment?
>>>>
>>>>
>>>> - --
>>>> jro
>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>>
>>>> iQEcBAEBAgAGBQJT2qOQAAoJECDcy2IJkagRnH0H/3j3VgCu8KSUfOBYzC7McFxg
>>>> my+hW6i+FFNn3kpJJ2/EQtmg/pFGdenIwd/Uu8XJhwaLfT0mtP67b8GDuD/BsPGp
>>>> lVyuFeznew6gN+usGnQe48sEUCnpadlwI/ZIjcZhJqmcVzwUw991RvA32l6Z9x3/
>>>> biYv9N0QiaEpp3c0rWAApnHetsun7rFxGuzgAq2pB+adeWCOSTtOpYEado7qOrEx
>>>> FyBj8Gh1sc7kMLnyml/UXgLBvxsaSUXq81t1QwaOOZS4TQLtg/HstHMlTvqrS6k2
>>>> WsbhmS5qqmKBIKeEjWUl6d5S3TKfW+XjaY3JVFlN8p6EPS3LUl5SkxqzH/Zavfw=
>>>> =+hI6
>>>> -----END PGP SIGNATURE-----
>>>>
>>>>
>>>
>> --
>> jro
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: app.c
Type: text/x-csrc
Size: 2577 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140805/ccda79ec/attachment.c>

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Jorge Ramirez Ortiz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/05/2014 06:01 AM, Wojciech Domski wrote:
> Ok, there was a problem with closing the descriptor on the side of API (new
> file in attachment). I have resolved it but now I have problem with IRQ.
> Here is what dmesg says:
> 
> [  103.942431] Analogy: a4l_add_drv: name=S626
> [  103.942434] Analogy: a4l_lct_drv: name=S626
> [  103.942450] Analogy: Probing for s626
> [  103.942469] Analogy: Probing for s626
> [  115.764941] Analogy: a4l_lct_drv: name=S626
> [  115.764945] Analogy: S626: Attaching s626
> [  115.764947] Analogy: S626: Desired Bus: 2, Slot: 4
> [  115.764949] Analogy: S626: Has Bus: 2, Slot: 4
> [  115.764951] Analogy: S626: PCI dev = ffff880211c72000
> [  115.764952] Analogy: S626: PCI set master
> [  115.764960] Analogy: S626: PCI region request
> [  115.764964] Analogy: S626: PCI ioremap
> [  115.764997] Analogy: S626: disable master interrupt
> [  115.764998] Analogy: S626: DMA
> [  115.765004] Analogy: S626: RTDM irq
> [  115.765016] Analogy: S626: RTDM irq request
> [  115.765027] Analogy: S626: subdevices allocation
> [  115.765031] Analogy: S626: card initialization
> [  115.780513] Analogy: S626: Driver ready
> [  115.780516] Analogy: a4l_setup_transfer: nb_subd=6
> [  119.620570] Analogy: a4l_lct_drv: name=S626
> [  119.620575] Analogy: S626: Attaching s626
> [  119.620579] Analogy: S626: Desired Bus: 2, Slot: 5
> [  119.620581] Analogy: S626: Has Bus: 2, Slot: 5
> [  119.620583] Analogy: S626: PCI dev = ffff880211c73000
> [  119.620584] Analogy: S626: PCI set master
> [  119.620592] Analogy: S626: PCI region request
> [  119.620596] Analogy: S626: PCI ioremap
> [  119.620630] Analogy: S626: disable master interrupt
> [  119.620632] Analogy: S626: DMA
> [  119.620635] Analogy: S626: RTDM irq
> [  119.620644] Analogy: S626: RTDM irq request
> [  119.620655] Analogy: S626: subdevices allocation
> [  119.620659] Analogy: S626: card initialization
> [  119.636135] Analogy: S626: Driver ready
> [  119.636139] Analogy: a4l_setup_transfer: nb_subd=6
> [  121.908284] Analogy: a4l_precleanup_transfer: subd[0]->status=0x00000000
> [  121.908287] Analogy: a4l_precleanup_transfer: subd[1]->status=0x00000000
> [  121.908289] Analogy: a4l_precleanup_transfer: subd[2]->status=0x00000000
> [  121.908290] Analogy: a4l_precleanup_transfer: subd[3]->status=0x00000000
> [  121.908291] Analogy: a4l_precleanup_transfer: subd[4]->status=0x00000000
> [  121.908293] Analogy: a4l_precleanup_transfer: subd[5]->status=0x00000000
> [  121.908298] Analogy: S626: Detaching s626
> [  121.908300] Analogy: S626: Cleaning private
> [  121.908322] Analogy: S626: Handling irq
> [  122.111663] Analogy: S626: Releasing PCI regions
> [  122.111670] Analogy: S626: Removing private
> [  122.111671] Analogy: S626: Detaching completed
> [  124.081687] Analogy: a4l_precleanup_transfer: subd[0]->status=0x00000000
> [  124.081691] Analogy: a4l_precleanup_transfer: subd[1]->status=0x00000000
> [  124.081692] Analogy: a4l_precleanup_transfer: subd[2]->status=0x00000000
> [  124.081694] Analogy: a4l_precleanup_transfer: subd[3]->status=0x00000000
> [  124.081695] Analogy: a4l_precleanup_transfer: subd[4]->status=0x00000000
> [  124.081696] Analogy: a4l_precleanup_transfer: subd[5]->status=0x00000000
> [  124.081702] Analogy: S626: Detaching s626
> [  124.081704] Analogy: S626: Cleaning private
> [  124.081726] Analogy: S626: Handling irq
> [  124.283848] Analogy: S626: Releasing PCI regions
> [  124.283855] Analogy: S626: Removing private
> [  124.283856] Analogy: S626: Detaching completed
> [  127.376882] Analogy: a4l_lct_drv: name=S626
> [  127.376887] Analogy: S626: Attaching s626
> [  127.376888] Analogy: S626: Desired Bus: 2, Slot: 5
> [  127.376890] Analogy: S626: Has Bus: 2, Slot: 5
> [  127.376893] Analogy: S626: PCI dev = ffff880211c73000
> [  127.376894] Analogy: S626: PCI set master
> [  127.376901] Analogy: S626: PCI region request
> [  127.376905] Analogy: S626: PCI ioremap
> [  127.376961] Analogy: S626: disable master interrupt
> [  127.376962] Analogy: S626: DMA
> [  127.376968] Analogy: S626: RTDM irq
> [  127.376983] Analogy: S626: RTDM irq request
> [  127.376992] Analogy: a4l_assign_driver: call(drv->attach) failed


the IRQ line is already in use as per the return code (EBUSY).
it could be that the previous call to rtdm_irq_free failed.

could you try again after applying this patch please ?

http://git.xenomai.org/xenomai-jro.git/commit/?h=for-forge&id=44e4db095fb690705e311aaee378d66e84a381db






> (ret=-16)
> [  127.376994] Analogy: a4l_request_irq: IRQ registration failed
> 
> 
> 
> 2014-08-05 11:20 GMT+02:00 Wojciech Domski <wojciech.domski@gmail.com>:
> 
>> I did recompile xeno_analogy kernel module with thresholds both set to 10
>> so now everything should be ok.
>> Here is the dmesg output:
>>
>> [  110.899150] Analogy: a4l_add_drv: name=S626
>> [  110.899154] Analogy: a4l_lct_drv: name=S626
>> [  110.899168] Analogy: Probing for s626
>> [  110.899185] Analogy: Probing for s626
>> [  119.703343] Analogy: a4l_lct_drv: name=S626
>> [  119.703347] Analogy: S626: Attaching s626
>> [  119.703349] Analogy: S626: Desired Bus: 2, Slot: 4
>> [  119.703351] Analogy: S626: Has Bus: 2, Slot: 4
>> [  119.703353] Analogy: S626: PCI dev = ffff880211c72000
>> [  119.703354] Analogy: S626: PCI set master
>> [  119.703361] Analogy: S626: PCI region request
>> [  119.703366] Analogy: S626: PCI ioremap
>> [  119.703398] Analogy: S626: disable master interrupt
>> [  119.703400] Analogy: S626: DMA
>> [  119.703405] Analogy: S626: RTDM irq
>> [  119.703417] Analogy: S626: RTDM irq request
>> [  119.703428] Analogy: S626: subdevices allocation
>> [  119.703432] Analogy: S626: card initialization
>> [  119.718902] Analogy: S626: Driver ready
>> [  119.718905] Analogy: a4l_setup_transfer: nb_subd=6
>> [  119.719039] Analogy: a4l_lct_drv: name=S626
>> [  119.719041] Analogy: S626: Attaching s626
>> [  119.719042] Analogy: S626: Desired Bus: 2, Slot: 5
>> [  119.719044] Analogy: S626: Has Bus: 2, Slot: 5
>> [  119.719045] Analogy: S626: PCI dev = ffff880211c73000
>> [  119.719046] Analogy: S626: PCI set master
>> [  119.719053] Analogy: S626: PCI region request
>> [  119.719055] Analogy: S626: PCI ioremap
>> [  119.719067] Analogy: S626: disable master interrupt
>> [  119.719068] Analogy: S626: DMA
>> [  119.719071] Analogy: S626: RTDM irq
>> [  119.719080] Analogy: S626: RTDM irq request
>> [  119.719087] Analogy: S626: subdevices allocation
>> [  119.719090] Analogy: S626: card initialization
>> [  119.734596] Analogy: S626: Driver ready
>> [  119.734598] Analogy: a4l_setup_transfer: nb_subd=6
>> [  119.734735] Analogy: a4l_precleanup_transfer: subd[0]->status=0x00000000
>> [  119.734736] Analogy: a4l_precleanup_transfer: subd[1]->status=0x00000000
>> [  119.734738] Analogy: a4l_precleanup_transfer: subd[2]->status=0x00000000
>> [  119.734739] Analogy: a4l_precleanup_transfer: subd[3]->status=0x00000000
>> [  119.734740] Analogy: a4l_precleanup_transfer: subd[4]->status=0x00000000
>> [  119.734742] Analogy: a4l_precleanup_transfer: subd[5]->status=0x00000000
>> [  119.734745] Analogy: S626: Detaching s626
>> [  119.734747] Analogy: S626: Cleaning private
>> [  119.734767] Analogy: S626: Handling irq
>> [  119.938140] Analogy: S626: Releasing PCI regions
>> [  119.938147] Analogy: S626: Removing private
>> [  119.938149] Analogy: S626: Detaching completed
>> [  119.938276] Analogy: a4l_lct_drv: name=S626
>> [  119.938278] Analogy: S626: Attaching s626
>> [  119.938280] Analogy: S626: Desired Bus: 2, Slot: 5
>> [  119.938282] Analogy: S626: Has Bus: 2, Slot: 5
>> [  119.938283] Analogy: S626: PCI dev = ffff880211c73000
>> [  119.938285] Analogy: S626: PCI set master
>> [  119.938292] Analogy: S626: PCI region request
>> [  119.938298] S626 0000:02:05.0: BAR 0: can't reserve [mem
>> 0xf7b00000-0xf7b001ff]
>> [  119.938299] Analogy: Can't request regions
>> [  119.938301] Analogy: a4l_assign_driver: call(drv->attach) failed
>> (ret=-12)
>> [  120.142476] Xenomai: RTDM: closing file descriptor 3.
>>
>> Also in the attachment is the patch for the xenomai 2.6.3 for support of
>> multiple s626 cards. Also I have attached the simple testing program
>> (app.c) and API which I've written to make the interaction with s626 easier.
>>
>> Please let me know if you come up with something.
>>
>>
>> 2014-08-01 16:48 GMT+02:00 Jorge Ramirez Ortiz <jro@xenomai.org>:
>>
>> On 08/01/2014 07:33 AM, Wojciech Domski wrote:
>>>
>>>> Dear Jorge,
>>>>
>>>> In attachment you can find the dump file. I created it with strace. I
>>>> hope
>>>> this is what you meant.
>>>>
>>>
>>> I actually meant the kernel traces.
>>> Please when compiling the analogy drivers if you could set the analogy
>>> driver and core debug level thresolds to 10 that would be all.
>>> Then attach the output of $dmesg to your email.
>>>
>>>
>>>
>>>
>>>> Also I forgot to tell one more thing. When I try to relink s1 to a0 I get
>>>> this message from the driver:
>>>> S626 0000:02:05.0: BAR 0: can't reserve [mem 0xf7b00000-0xf7b001ff]
>>>>
>>>
>>> maybe you didnt release the device properly. Please could you send the
>>> code as well?
>>>
>>>
>>>
>>>  This is the result of pci_request_regions() function in attach.
>>>>
>>>> Here is also the sample application which I have written to test it.
>>>>
>>>> ts626 * s626;
>>>>    ts626 * s626_2;
>>>>
>>>>    printf("Opening a0 with s0\n");
>>>>    s626 = s626_init("S626", "analogy0");
>>>>      s626_set_options(s626);
>>>>       s626_set_bus(s626, 2);
>>>>       s626_set_slot(s626, 4);
>>>>       s626_open(s626);
>>>>
>>>>       printf("Opening a1 with s1\n");
>>>>    s626_2 = s626_init("S626", "analogy1");
>>>>      s626_set_options(s626_2);
>>>>       s626_set_bus(s626_2, 2);
>>>>       s626_set_slot(s626_2, 5);
>>>>       s626_open(s626_2);
>>>>
>>>>       printf("Closing a0 with s0\n");
>>>>      s626_close( s626);
>>>>      s626_deinit( s626);
>>>>      s626 = NULL;
>>>>
>>>>      printf("Closing a1 with s1\n");
>>>>      s626_close( s626_2);
>>>>      s626_deinit( s626_2);
>>>>      s626_2 = NULL;
>>>>
>>>>    printf("Opening a0 with s1\n");
>>>>    s626 = s626_init("S626", "analogy0");
>>>>      s626_set_options(s626);
>>>>       s626_set_bus(s626, 2);
>>>>       s626_set_slot(s626, 5);
>>>>       s626_open(s626);
>>>>
>>>>      printf("Closing a0 with s1\n");
>>>>      s626_close( s626);
>>>>      s626_deinit( s626);
>>>>      s626 = NULL;
>>>>
>>>> Best regards,
>>>> Wojciech Domski
>>>>
>>>>
>>>> 2014-07-31 22:14 GMT+02:00 Jorge Ramirez Ortiz <jro@xenomai.org>:
>>>>
>>>>  -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> On 07/31/2014 05:22 AM, Wojciech Domski wrote:
>>>>>   I prepared the driver to work well with multiple Sensoray 626 and I
>>>>> tested
>>>>>   it with two of those. I have a problem, however.
>>>>>   I suspect that the analogy interface doesn't play along with the
>>>>> driver
>>>>> but
>>>>>   I'm not certain about that. Here what's happening.
>>>>>   I have two s626 cards: s0 and s1. For the sake of conversation let's
>>>>> assume
>>>>>   that analogy device analogy0 is a0 and so on.
>>>>>   When I link s0 to a0, unlink, link s1 to a1, unlink everything works
>>>>> fine,
>>>>>   however. Once more when I link s0 but this time to a1 something goes
>>>>> wrong.
>>>>>   I get -16 error from a4l_sys_attach() which is
>>>>>
>>>>>   No such device
>>>>>
>>>>>   What is the reason of this happening? I do clean everything every time
>>>>> when
>>>>>   I release s626.
>>>>>   Here is what I do when I want to open my device:
>>>>>
>>>>>   a4l_sys_open();
>>>>>   a4l_sys_attach();
>>>>>   a4l_open();
>>>>>   rt_dev_open();
>>>>>   a4l_fill_desc();
>>>>>
>>>>>   When I close the s626 I do:
>>>>>
>>>>>   rt_dev_close();
>>>>>   a4l_close();
>>>>>   a4l_sys_detach();
>>>>>   a4l_sys_close();
>>>>>
>>>>>   Best regards,
>>>>>   Wojciech Domski
>>>>>
>>>>> - ------------------
>>>>>
>>>>> please could you send the driver and the kernel traces for the
>>>>> experiment?
>>>>>
>>>>>
>>>>> - --
>>>>> jro
>>>>>
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>>>
>>>>> iQEcBAEBAgAGBQJT2qOQAAoJECDcy2IJkagRnH0H/3j3VgCu8KSUfOBYzC7McFxg
>>>>> my+hW6i+FFNn3kpJJ2/EQtmg/pFGdenIwd/Uu8XJhwaLfT0mtP67b8GDuD/BsPGp
>>>>> lVyuFeznew6gN+usGnQe48sEUCnpadlwI/ZIjcZhJqmcVzwUw991RvA32l6Z9x3/
>>>>> biYv9N0QiaEpp3c0rWAApnHetsun7rFxGuzgAq2pB+adeWCOSTtOpYEado7qOrEx
>>>>> FyBj8Gh1sc7kMLnyml/UXgLBvxsaSUXq81t1QwaOOZS4TQLtg/HstHMlTvqrS6k2
>>>>> WsbhmS5qqmKBIKeEjWUl6d5S3TKfW+XjaY3JVFlN8p6EPS3LUl5SkxqzH/Zavfw=
>>>>> =+hI6
>>>>> -----END PGP SIGNATURE-----
>>>>>
>>>>>
>>>>
>>> --
>>> jro
>>>
>>
>>
> 

- -- 
jro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJT6W0OAAoJECDcy2IJkagRB4cIAI/LPyA+87ximC4HXoNvr23N
3bUXuTPKP6rPnprNLqzWQnZHaXVZLavXb7QX81DT/biUVw6ObH8/AJ3bRcoYJoa0
4x4FCwh77mLlwgPSi6vipgduEoZ4Sq+f7bidYbw7UWZjicKdtFc+6nPqJJE2+5iE
1VR8yPvZKOg9cQduF0UTHuoAdXrHRCP25vSw1o8HrN37nnyVN2BUVwR2YI78s2Ga
09b+5O8tzEIiXQOuK1jVBhSiHWnnvBaaYseDPihcrec3OJlsAG+pirSXsv+TqW6d
B+N+ehU/ropvWUAwxnOXYKpRsPj32XjwEYRn4sJh79sFYzejD4OED6ZovP0pckA=
=XU3a
-----END PGP SIGNATURE-----

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Jorge Ramirez Ortiz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/11/2014 09:25 PM, Jorge Ramirez Ortiz wrote:
> On 08/05/2014 06:01 AM, Wojciech Domski wrote:
>> Ok, there was a problem with closing the descriptor on the side of API (new
>> file in attachment). I have resolved it but now I have problem with IRQ.
>> Here is what dmesg says:
> 
>> [  103.942431] Analogy: a4l_add_drv: name=S626
>> [  103.942434] Analogy: a4l_lct_drv: name=S626
>> [  103.942450] Analogy: Probing for s626
>> [  103.942469] Analogy: Probing for s626
>> [  115.764941] Analogy: a4l_lct_drv: name=S626
>> [  115.764945] Analogy: S626: Attaching s626
>> [  115.764947] Analogy: S626: Desired Bus: 2, Slot: 4
>> [  115.764949] Analogy: S626: Has Bus: 2, Slot: 4
>> [  115.764951] Analogy: S626: PCI dev = ffff880211c72000
>> [  115.764952] Analogy: S626: PCI set master
>> [  115.764960] Analogy: S626: PCI region request
>> [  115.764964] Analogy: S626: PCI ioremap
>> [  115.764997] Analogy: S626: disable master interrupt
>> [  115.764998] Analogy: S626: DMA
>> [  115.765004] Analogy: S626: RTDM irq
>> [  115.765016] Analogy: S626: RTDM irq request
>> [  115.765027] Analogy: S626: subdevices allocation
>> [  115.765031] Analogy: S626: card initialization
>> [  115.780513] Analogy: S626: Driver ready
>> [  115.780516] Analogy: a4l_setup_transfer: nb_subd=6
>> [  119.620570] Analogy: a4l_lct_drv: name=S626
>> [  119.620575] Analogy: S626: Attaching s626
>> [  119.620579] Analogy: S626: Desired Bus: 2, Slot: 5
>> [  119.620581] Analogy: S626: Has Bus: 2, Slot: 5
>> [  119.620583] Analogy: S626: PCI dev = ffff880211c73000
>> [  119.620584] Analogy: S626: PCI set master
>> [  119.620592] Analogy: S626: PCI region request
>> [  119.620596] Analogy: S626: PCI ioremap
>> [  119.620630] Analogy: S626: disable master interrupt
>> [  119.620632] Analogy: S626: DMA
>> [  119.620635] Analogy: S626: RTDM irq
>> [  119.620644] Analogy: S626: RTDM irq request
>> [  119.620655] Analogy: S626: subdevices allocation
>> [  119.620659] Analogy: S626: card initialization
>> [  119.636135] Analogy: S626: Driver ready
>> [  119.636139] Analogy: a4l_setup_transfer: nb_subd=6
>> [  121.908284] Analogy: a4l_precleanup_transfer: subd[0]->status=0x00000000
>> [  121.908287] Analogy: a4l_precleanup_transfer: subd[1]->status=0x00000000
>> [  121.908289] Analogy: a4l_precleanup_transfer: subd[2]->status=0x00000000
>> [  121.908290] Analogy: a4l_precleanup_transfer: subd[3]->status=0x00000000
>> [  121.908291] Analogy: a4l_precleanup_transfer: subd[4]->status=0x00000000
>> [  121.908293] Analogy: a4l_precleanup_transfer: subd[5]->status=0x00000000
>> [  121.908298] Analogy: S626: Detaching s626
>> [  121.908300] Analogy: S626: Cleaning private
>> [  121.908322] Analogy: S626: Handling irq
>> [  122.111663] Analogy: S626: Releasing PCI regions
>> [  122.111670] Analogy: S626: Removing private
>> [  122.111671] Analogy: S626: Detaching completed
>> [  124.081687] Analogy: a4l_precleanup_transfer: subd[0]->status=0x00000000
>> [  124.081691] Analogy: a4l_precleanup_transfer: subd[1]->status=0x00000000
>> [  124.081692] Analogy: a4l_precleanup_transfer: subd[2]->status=0x00000000
>> [  124.081694] Analogy: a4l_precleanup_transfer: subd[3]->status=0x00000000
>> [  124.081695] Analogy: a4l_precleanup_transfer: subd[4]->status=0x00000000
>> [  124.081696] Analogy: a4l_precleanup_transfer: subd[5]->status=0x00000000
>> [  124.081702] Analogy: S626: Detaching s626
>> [  124.081704] Analogy: S626: Cleaning private
>> [  124.081726] Analogy: S626: Handling irq
>> [  124.283848] Analogy: S626: Releasing PCI regions
>> [  124.283855] Analogy: S626: Removing private
>> [  124.283856] Analogy: S626: Detaching completed
>> [  127.376882] Analogy: a4l_lct_drv: name=S626
>> [  127.376887] Analogy: S626: Attaching s626
>> [  127.376888] Analogy: S626: Desired Bus: 2, Slot: 5
>> [  127.376890] Analogy: S626: Has Bus: 2, Slot: 5
>> [  127.376893] Analogy: S626: PCI dev = ffff880211c73000
>> [  127.376894] Analogy: S626: PCI set master
>> [  127.376901] Analogy: S626: PCI region request
>> [  127.376905] Analogy: S626: PCI ioremap
>> [  127.376961] Analogy: S626: disable master interrupt
>> [  127.376962] Analogy: S626: DMA
>> [  127.376968] Analogy: S626: RTDM irq
>> [  127.376983] Analogy: S626: RTDM irq request
>> [  127.376992] Analogy: a4l_assign_driver: call(drv->attach) failed
> 
> 
> the IRQ line is already in use as per the return code (EBUSY).
> it could be that the previous call to rtdm_irq_free failed.
> 
> could you try again after applying this patch please ?
> 
> http://git.xenomai.org/xenomai-jro.git/commit/?h=for-forge&id=44e4db095fb690705e311aaee378d66e84a381db
> 
> 

this is the fix that you probably need:
http://git.xenomai.org/xenomai-jro.git/commit/?h=for-forge&id=99ec0e1122f27c0a4b6b0a3d1f3d8aff6498a877

please let me know if it addresses your problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJT7m4HAAoJECDcy2IJkagRCA0IAIfvRvrfaLFjbExAHZGY+1LO
B7hpOzzlzsUPD21Rz8xyuVAsMLfP6I3+ogOQgAje1ALy04DbVFluL7GTyYHVItRn
wzjccqPHmOeRQJR1L5p+dGXzrJvm3WxTeZwX7klaf//6ygWpj/Dd0RTXl2TiYAXm
S9qkEL0FKXF+PN0L5ScnSPA1oecsHoDx1JXtwcQW6T6RkiF8EwuLIRj2Tdi5A13i
evtfncYoBXn47gNQ9RYPMVfR5GhVd8xyNXPJGIDtSNdnYGXSnu1FChTCd+4zkf+r
9y2MwgCP3BJhWuOpA/NgNlS9reYD5A8JRNsXONvPLMHJvwFCniR4n1HbL2Ex+Dw=
=8NM+
-----END PGP SIGNATURE-----

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Wojciech Domski]

Dear Jorge,

Yes, this fix solved the problem. Now, everything works just fine. Please
find attached a Sensoray 626 driver. It is cleaned and tested to work with
two cards. There shouldn't be any problem with more cards support.
However, I would like to ask you for a favour. Is it possible for you to
put this patch to Xenomai 2 tree ?

Also as you could notice before I've written a piece of API for using the
Sensoray 626 card. Is is possible to add this also to Xenomai but to
example section or something similar, of course?

Best regards,
Wojciech Domski

2014-08-15 22:31 GMT+02:00 Jorge Ramirez Ortiz <jro@xenomai.org>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/11/2014 09:25 PM, Jorge Ramirez Ortiz wrote:
> > On 08/05/2014 06:01 AM, Wojciech Domski wrote:
> >> Ok, there was a problem with closing the descriptor on the side of API
> (new
> >> file in attachment). I have resolved it but now I have problem with IRQ.
> >> Here is what dmesg says:
> >
> >> [  103.942431] Analogy: a4l_add_drv: name=S626
> >> [  103.942434] Analogy: a4l_lct_drv: name=S626
> >> [  103.942450] Analogy: Probing for s626
> >> [  103.942469] Analogy: Probing for s626
> >> [  115.764941] Analogy: a4l_lct_drv: name=S626
> >> [  115.764945] Analogy: S626: Attaching s626
> >> [  115.764947] Analogy: S626: Desired Bus: 2, Slot: 4
> >> [  115.764949] Analogy: S626: Has Bus: 2, Slot: 4
> >> [  115.764951] Analogy: S626: PCI dev = ffff880211c72000
> >> [  115.764952] Analogy: S626: PCI set master
> >> [  115.764960] Analogy: S626: PCI region request
> >> [  115.764964] Analogy: S626: PCI ioremap
> >> [  115.764997] Analogy: S626: disable master interrupt
> >> [  115.764998] Analogy: S626: DMA
> >> [  115.765004] Analogy: S626: RTDM irq
> >> [  115.765016] Analogy: S626: RTDM irq request
> >> [  115.765027] Analogy: S626: subdevices allocation
> >> [  115.765031] Analogy: S626: card initialization
> >> [  115.780513] Analogy: S626: Driver ready
> >> [  115.780516] Analogy: a4l_setup_transfer: nb_subd=6
> >> [  119.620570] Analogy: a4l_lct_drv: name=S626
> >> [  119.620575] Analogy: S626: Attaching s626
> >> [  119.620579] Analogy: S626: Desired Bus: 2, Slot: 5
> >> [  119.620581] Analogy: S626: Has Bus: 2, Slot: 5
> >> [  119.620583] Analogy: S626: PCI dev = ffff880211c73000
> >> [  119.620584] Analogy: S626: PCI set master
> >> [  119.620592] Analogy: S626: PCI region request
> >> [  119.620596] Analogy: S626: PCI ioremap
> >> [  119.620630] Analogy: S626: disable master interrupt
> >> [  119.620632] Analogy: S626: DMA
> >> [  119.620635] Analogy: S626: RTDM irq
> >> [  119.620644] Analogy: S626: RTDM irq request
> >> [  119.620655] Analogy: S626: subdevices allocation
> >> [  119.620659] Analogy: S626: card initialization
> >> [  119.636135] Analogy: S626: Driver ready
> >> [  119.636139] Analogy: a4l_setup_transfer: nb_subd=6
> >> [  121.908284] Analogy: a4l_precleanup_transfer:
> subd[0]->status=0x00000000
> >> [  121.908287] Analogy: a4l_precleanup_transfer:
> subd[1]->status=0x00000000
> >> [  121.908289] Analogy: a4l_precleanup_transfer:
> subd[2]->status=0x00000000
> >> [  121.908290] Analogy: a4l_precleanup_transfer:
> subd[3]->status=0x00000000
> >> [  121.908291] Analogy: a4l_precleanup_transfer:
> subd[4]->status=0x00000000
> >> [  121.908293] Analogy: a4l_precleanup_transfer:
> subd[5]->status=0x00000000
> >> [  121.908298] Analogy: S626: Detaching s626
> >> [  121.908300] Analogy: S626: Cleaning private
> >> [  121.908322] Analogy: S626: Handling irq
> >> [  122.111663] Analogy: S626: Releasing PCI regions
> >> [  122.111670] Analogy: S626: Removing private
> >> [  122.111671] Analogy: S626: Detaching completed
> >> [  124.081687] Analogy: a4l_precleanup_transfer:
> subd[0]->status=0x00000000
> >> [  124.081691] Analogy: a4l_precleanup_transfer:
> subd[1]->status=0x00000000
> >> [  124.081692] Analogy: a4l_precleanup_transfer:
> subd[2]->status=0x00000000
> >> [  124.081694] Analogy: a4l_precleanup_transfer:
> subd[3]->status=0x00000000
> >> [  124.081695] Analogy: a4l_precleanup_transfer:
> subd[4]->status=0x00000000
> >> [  124.081696] Analogy: a4l_precleanup_transfer:
> subd[5]->status=0x00000000
> >> [  124.081702] Analogy: S626: Detaching s626
> >> [  124.081704] Analogy: S626: Cleaning private
> >> [  124.081726] Analogy: S626: Handling irq
> >> [  124.283848] Analogy: S626: Releasing PCI regions
> >> [  124.283855] Analogy: S626: Removing private
> >> [  124.283856] Analogy: S626: Detaching completed
> >> [  127.376882] Analogy: a4l_lct_drv: name=S626
> >> [  127.376887] Analogy: S626: Attaching s626
> >> [  127.376888] Analogy: S626: Desired Bus: 2, Slot: 5
> >> [  127.376890] Analogy: S626: Has Bus: 2, Slot: 5
> >> [  127.376893] Analogy: S626: PCI dev = ffff880211c73000
> >> [  127.376894] Analogy: S626: PCI set master
> >> [  127.376901] Analogy: S626: PCI region request
> >> [  127.376905] Analogy: S626: PCI ioremap
> >> [  127.376961] Analogy: S626: disable master interrupt
> >> [  127.376962] Analogy: S626: DMA
> >> [  127.376968] Analogy: S626: RTDM irq
> >> [  127.376983] Analogy: S626: RTDM irq request
> >> [  127.376992] Analogy: a4l_assign_driver: call(drv->attach) failed
> >
> >
> > the IRQ line is already in use as per the return code (EBUSY).
> > it could be that the previous call to rtdm_irq_free failed.
> >
> > could you try again after applying this patch please ?
> >
> >
> http://git.xenomai.org/xenomai-jro.git/commit/?h=for-forge&id=44e4db095fb690705e311aaee378d66e84a381db
> >
> >
>
> this is the fix that you probably need:
>
> http://git.xenomai.org/xenomai-jro.git/commit/?h=for-forge&id=99ec0e1122f27c0a4b6b0a3d1f3d8aff6498a877
>
> please let me know if it addresses your problem.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBAgAGBQJT7m4HAAoJECDcy2IJkagRCA0IAIfvRvrfaLFjbExAHZGY+1LO
> B7hpOzzlzsUPD21Rz8xyuVAsMLfP6I3+ogOQgAje1ALy04DbVFluL7GTyYHVItRn
> wzjccqPHmOeRQJR1L5p+dGXzrJvm3WxTeZwX7klaf//6ygWpj/Dd0RTXl2TiYAXm
> S9qkEL0FKXF+PN0L5ScnSPA1oecsHoDx1JXtwcQW6T6RkiF8EwuLIRj2Tdi5A13i
> evtfncYoBXn47gNQ9RYPMVfR5GhVd8xyNXPJGIDtSNdnYGXSnu1FChTCd+4zkf+r
> 9y2MwgCP3BJhWuOpA/NgNlS9reYD5A8JRNsXONvPLMHJvwFCniR4n1HbL2Ex+Dw=
> =8NM+
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s626_cleaned.patch
Type: text/x-patch
Size: 144553 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140909/bdfda94c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S626API.c
Type: text/x-csrc
Size: 8821 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140909/bdfda94c/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S626API.h
Type: text/x-chdr
Size: 3147 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140909/bdfda94c/attachment.h>

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Jorge Ramirez Ortiz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/09/2014 05:31 AM, Wojciech Domski wrote:
> Dear Jorge,
> 
> Yes, this fix solved the problem. Now, everything works just fine. Please
> find attached a Sensoray 626 driver. It is cleaned and tested to work with
> two cards. There shouldn't be any problem with more cards support.
> However, I would like to ask you for a favour. Is it possible for you to
> put this patch to Xenomai 2 tree ?


Sure, let me review it and will push it.I will be at Linaro Connect next week so it
might take me a couple of weeks to do this. But will certainly do.
I am in the process of the delivering a software calibration utility for the NI-M
family of cards.

Would you happen to have a software calibration algorithm that I could implement for
the Sensoray ones?

> 
> Also as you could notice before I've written a piece of API for using the
> Sensoray 626 card. Is is possible to add this also to Xenomai but to
> example section or something similar, of course?

let me think about this. Maybe it would make sense to have some higher level API
providing functional encapsulation as you propose.


> 
> Best regards,
> Wojciech Domski
> 
> 2014-08-15 22:31 GMT+02:00 Jorge Ramirez Ortiz <jro@xenomai.org>:
> 
> On 08/11/2014 09:25 PM, Jorge Ramirez Ortiz wrote:
>>>> On 08/05/2014 06:01 AM, Wojciech Domski wrote:
>>>>> Ok, there was a problem with closing the descriptor on the side of API
> (new
>>>>> file in attachment). I have resolved it but now I have problem with IRQ.
>>>>> Here is what dmesg says:
>>>>
>>>>> [  103.942431] Analogy: a4l_add_drv: name=S626
>>>>> [  103.942434] Analogy: a4l_lct_drv: name=S626
>>>>> [  103.942450] Analogy: Probing for s626
>>>>> [  103.942469] Analogy: Probing for s626
>>>>> [  115.764941] Analogy: a4l_lct_drv: name=S626
>>>>> [  115.764945] Analogy: S626: Attaching s626
>>>>> [  115.764947] Analogy: S626: Desired Bus: 2, Slot: 4
>>>>> [  115.764949] Analogy: S626: Has Bus: 2, Slot: 4
>>>>> [  115.764951] Analogy: S626: PCI dev = ffff880211c72000
>>>>> [  115.764952] Analogy: S626: PCI set master
>>>>> [  115.764960] Analogy: S626: PCI region request
>>>>> [  115.764964] Analogy: S626: PCI ioremap
>>>>> [  115.764997] Analogy: S626: disable master interrupt
>>>>> [  115.764998] Analogy: S626: DMA
>>>>> [  115.765004] Analogy: S626: RTDM irq
>>>>> [  115.765016] Analogy: S626: RTDM irq request
>>>>> [  115.765027] Analogy: S626: subdevices allocation
>>>>> [  115.765031] Analogy: S626: card initialization
>>>>> [  115.780513] Analogy: S626: Driver ready
>>>>> [  115.780516] Analogy: a4l_setup_transfer: nb_subd=6
>>>>> [  119.620570] Analogy: a4l_lct_drv: name=S626
>>>>> [  119.620575] Analogy: S626: Attaching s626
>>>>> [  119.620579] Analogy: S626: Desired Bus: 2, Slot: 5
>>>>> [  119.620581] Analogy: S626: Has Bus: 2, Slot: 5
>>>>> [  119.620583] Analogy: S626: PCI dev = ffff880211c73000
>>>>> [  119.620584] Analogy: S626: PCI set master
>>>>> [  119.620592] Analogy: S626: PCI region request
>>>>> [  119.620596] Analogy: S626: PCI ioremap
>>>>> [  119.620630] Analogy: S626: disable master interrupt
>>>>> [  119.620632] Analogy: S626: DMA
>>>>> [  119.620635] Analogy: S626: RTDM irq
>>>>> [  119.620644] Analogy: S626: RTDM irq request
>>>>> [  119.620655] Analogy: S626: subdevices allocation
>>>>> [  119.620659] Analogy: S626: card initialization
>>>>> [  119.636135] Analogy: S626: Driver ready
>>>>> [  119.636139] Analogy: a4l_setup_transfer: nb_subd=6
>>>>> [  121.908284] Analogy: a4l_precleanup_transfer:
> subd[0]->status=0x00000000
>>>>> [  121.908287] Analogy: a4l_precleanup_transfer:
> subd[1]->status=0x00000000
>>>>> [  121.908289] Analogy: a4l_precleanup_transfer:
> subd[2]->status=0x00000000
>>>>> [  121.908290] Analogy: a4l_precleanup_transfer:
> subd[3]->status=0x00000000
>>>>> [  121.908291] Analogy: a4l_precleanup_transfer:
> subd[4]->status=0x00000000
>>>>> [  121.908293] Analogy: a4l_precleanup_transfer:
> subd[5]->status=0x00000000
>>>>> [  121.908298] Analogy: S626: Detaching s626
>>>>> [  121.908300] Analogy: S626: Cleaning private
>>>>> [  121.908322] Analogy: S626: Handling irq
>>>>> [  122.111663] Analogy: S626: Releasing PCI regions
>>>>> [  122.111670] Analogy: S626: Removing private
>>>>> [  122.111671] Analogy: S626: Detaching completed
>>>>> [  124.081687] Analogy: a4l_precleanup_transfer:
> subd[0]->status=0x00000000
>>>>> [  124.081691] Analogy: a4l_precleanup_transfer:
> subd[1]->status=0x00000000
>>>>> [  124.081692] Analogy: a4l_precleanup_transfer:
> subd[2]->status=0x00000000
>>>>> [  124.081694] Analogy: a4l_precleanup_transfer:
> subd[3]->status=0x00000000
>>>>> [  124.081695] Analogy: a4l_precleanup_transfer:
> subd[4]->status=0x00000000
>>>>> [  124.081696] Analogy: a4l_precleanup_transfer:
> subd[5]->status=0x00000000
>>>>> [  124.081702] Analogy: S626: Detaching s626
>>>>> [  124.081704] Analogy: S626: Cleaning private
>>>>> [  124.081726] Analogy: S626: Handling irq
>>>>> [  124.283848] Analogy: S626: Releasing PCI regions
>>>>> [  124.283855] Analogy: S626: Removing private
>>>>> [  124.283856] Analogy: S626: Detaching completed
>>>>> [  127.376882] Analogy: a4l_lct_drv: name=S626
>>>>> [  127.376887] Analogy: S626: Attaching s626
>>>>> [  127.376888] Analogy: S626: Desired Bus: 2, Slot: 5
>>>>> [  127.376890] Analogy: S626: Has Bus: 2, Slot: 5
>>>>> [  127.376893] Analogy: S626: PCI dev = ffff880211c73000
>>>>> [  127.376894] Analogy: S626: PCI set master
>>>>> [  127.376901] Analogy: S626: PCI region request
>>>>> [  127.376905] Analogy: S626: PCI ioremap
>>>>> [  127.376961] Analogy: S626: disable master interrupt
>>>>> [  127.376962] Analogy: S626: DMA
>>>>> [  127.376968] Analogy: S626: RTDM irq
>>>>> [  127.376983] Analogy: S626: RTDM irq request
>>>>> [  127.376992] Analogy: a4l_assign_driver: call(drv->attach) failed
>>>>
>>>>
>>>> the IRQ line is already in use as per the return code (EBUSY).
>>>> it could be that the previous call to rtdm_irq_free failed.
>>>>
>>>> could you try again after applying this patch please ?
>>>>
>>>>
> http://git.xenomai.org/xenomai-jro.git/commit/?h=for-forge&id=44e4db095fb690705e311aaee378d66e84a381db
>>>>
>>>>
> 
> this is the fix that you probably need:
> 
> http://git.xenomai.org/xenomai-jro.git/commit/?h=for-forge&id=99ec0e1122f27c0a4b6b0a3d1f3d8aff6498a877
> 
> please let me know if it addresses your problem.
>>
> 

- -- 
jro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJUD5jjAAoJECDcy2IJkagR8pUIAK6wW7mcJFZVEMDNsPNhjkcK
Y+AbIVb+rxz127IMnEURWaLUoXiXjhxuu1TKwawddCmL+Xf4QrMdBsmSJgm3Z5uZ
epKZO6NTSTFub6f2i8xLf3R/9c5AHejLK2of61Lc4gmf4rIthjhV5S2x1pXc3rvL
3sRpiqfBNUNRghIas7VaVJjryLEmO5bT7YhoTOTtj/7aAMroLa6TZntIOxfp2gzP
Zp3mcKCKwk+FEEkITI791raMdzqza/2t5VwaF6pENeiSf5KFS4oDWM2rnuTJAc/T
rv8neAfKGsAOVdyq5/iLFTmDZeW+owb5c7hrk6rDOhKH9byVqRzJAX3s16SAnxM=
=WdJd
-----END PGP SIGNATURE-----

Re: [Xenomai] sensoray 626 patch [Re: Xenomai Digest, Vol 27, Issue 12]

[Jorge Ramirez Ortiz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/09/2014 05:31 AM, Wojciech Domski wrote:
> Dear Jorge,
> 
> Yes, this fix solved the problem. Now, everything works just fine. Please
> find attached a Sensoray 626 driver. It is cleaned and tested to work with
> two cards. There shouldn't be any problem with more cards support.
> However, I would like to ask you for a favour. Is it possible for you to
> put this patch to Xenomai 2 tree ?

looking into this now.

> 
> Also as you could notice before I've written a piece of API for using the
> Sensoray 626 card. Is is possible to add this also to Xenomai but to
> example section or something similar, of course?
> 
> Best regards,
> Wojciech Domski
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJUIyImAAoJECDcy2IJkagRGVMH/RnY/4dsH4wt2zQ4pfXvCOB2
b4IWIhaBksfjzziHP7PPuL+mjRiitowhq6NWnxzJMm8+04hckOOJtooNV4KZyG95
OGdE0E+NzcXiuB8SCGlTQc3rNUHynlOBB1s8z+8qN69CN6y3FrqvXjKID/Z03lJI
vf7RNHFx+svVH0PG7EC3jHW3hH4VKSzgNkhpTSmHfnMeEG0YYJea0rR/QUuh0EKN
wvz6NaFlovn/YPo8/kqYbn5IirhBVkKrgb1ZyCnlmFEkzPlVoFZBnmIU9npWs++5
pOMCVhenp7kXoAdaScH0/Wkx3XVki38otWOwoK4VOFGBM29mEouF3q+a6MckYTU=
=p3Qe
-----END PGP SIGNATURE-----