Wolfgang Grandegger wrote: > Hello, > > Siniša Denić wrote: >> Hello Jan, we met each other on Real Time Conference in Linz, a few days >> ago. >> We talked about, rt_8139too driver and also I told you about my idea to >> wrote some kind of rt_mpc52xx_fec for 2.6 kernel. >> For now I have two questions: >> 1. does the MPC5200 Bestcomm DMA engine must be handled as rtdm device >> in order to serve data transfer between rt_mpc52xx_fec driver and >> memory, or I can use Bestcomm API as is? > > I believe you can use it as-is. Spin_lock/spin_unlock functions are used > for SDMA task creation, but they get called at initialization time in > secondary mode. I need to check more carefully, though.
CONFIG_IPIPE_DEBUG_CONTEXT can help to find remaining incompatible spinlock usages during runtime. > >> 2. what I have to do to put built-in fec driver "out of the kernel" and >> get it as module.I think that problem is because BestcommDMA is system >> device and must be built-in, hence(I suppose) fec is also work only as >> built-in. > > You need to port the FEC driver of a recent version of 2.6 to RTnet > using arch/powerpc. > >> This is already done for 2.4 kernel with kernel-patch which alows >> rt_mpc52xx_fec as module, but I think for 2.6 there is difference in >> patch and I don't know how to get it? > > The RTnet driver for the FEC om MPC5200 currently available for 2.4 is > not usable for 2.6 and it makes little sense to port it. > >> I hope you understand me.If these questions are rather for Wolfgang I'll >> be pleased to meet him here. > > You want to use RTnet on the MPC5200 with Linux 2.6, right? > Unfortunately, that FEC driver is still missing in Linux 2.6.23. There > are patches around and hopefully they will get included already in > 2.6.24. The corresponding RTnet driver should then be derived from that > Linux driver. One further question we discussed in Linz was if a directly attached FEC device might provide faster roundtrip times than a PCI-attached NIC with that controller. Wolfgang, what would you say? In any case, the so far used rt_8139 is not an optimal choice even if ignoring the PCI path for a while. The reason I just realised again: This hardware requires incoming and outgoing packets to be _copied_ between the stack data structures and special DMA regions of this card. So, maybe switching to another PCI adapter would already provide better numbers! Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-users
