Yeoh Chun Yeow wrote: > Dear Jan, > > Please provide me the details on how to do testing.
Just merged your driver with some modifications - hopefully good ones. My problem is that I don't know the locking requirements of the hardware, and that the original Linux driver is no real help here as it was built on wrong assumptions about locking. I picked a careful approach first and kept what I found, rather extended it. Maybe it would be possible to decouple all the PHY handling completely from the real-time domain, but that would need deeper analysis of hardware and driver. What I furthermore did is to default-disable the link state polling timer. That one is only needed if there is not PHY IRQ and you reconfigure your RT network after rtifconfig up. You can re-enable it via the module parameter "use_phy_timer". Another thing I came across is the extremely short TX queue of the rt_at91_ether (one slot!). This can be problematic if the TX completion interrupt takes longer than a succeeding TX request by the RTnet stack (e.g. joint TDMA slots or the Sync frame immediately followed by the master's payload slot). Did you already test such scenarios, and did it work? Looking forward to your test results! Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
