Re: [RTnet-developers] Only slave mode works on new port to ns9xxx

[Jan K. <jan...@si...>]

CCs... :)

James Kilts wrote:
>> (Better include the parsed frames as wireshark displays them - easier to
>> read unless one knows all protocol bits by heart.)
> 
> Attached are the full Wireshark captures showing the device failing to populate all of the fields of the TDMA synch broadcast when running in master mode.

It shows that the driver obviously fails to populate the xmit-stamp field:

> TDMA RTmac Discipline, Synchronisation
>     Version: 0x0201
>     Message ID: Synchronisation (0x0000)
>     Cycle Number: 10376
>     Transmission Time Stamp: 0 (-80052902983)
>     Scheduled Transmission Time: 80052902983

and

> TDMA RTmac Discipline, Synchronisation
>     Version: 0x0201
>     Message ID: Synchronisation (0x0000)
>     Cycle Number: 89575
>     Transmission Time Stamp: 0 (-466667678324)
>     Scheduled Transmission Time: 466667678324

It's zero in both cases, but it should be close to the scheduled time.

> 
> 
>> Is your driver trying to time-stamp outgoing frame already? If yes,
>> maybe the is a problem with the required late update of the frame.
> 
> I'm not entirely sure I understand.  The driver time-stamps the outgoing frame in hard_start_xmit(), the same as many of the other drivers.  I've tried doing the time-stamp earlier and later in the process, but the result is basically the same.  In what part of the code does/should the "late update of the frame" occur?

It should happen atomically together with giving the transmission signal
to the hardware. If special measures are required to prepare the payload
transfer (like some cache flush e.g.), the frame patching must happen
before that or the measures need to be repeated for the modified payload
range.

Maybe you want to share your current work already, that would make the
discussion a bit more concrete.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux