Just found out in my system, the register Peripheral Bus Burst Priority Register(PBBPR address 0x2000 0020) was already set to 0x20, and the packet dropping is still happening; then I change to other values(0x10,0x05,0x30,0xff etc.), does not help neither. At this point, it seems the DDR2 bandwidth control may not be the issue, the most doubting point may still be the compat flash driver(or IDE driver?), I may need to dig into emac driver to find out where is the packets get dropped. Thanks, Bin
On Mon, Mar 9, 2009 at 11:13 AM, Bin Liu <[email protected]> wrote: > Sorry, I think I should send to the list. > > Bin > > > ---------- Forwarded message ---------- > From: Bin Liu <[email protected]> > Date: Mon, Mar 9, 2009 at 11:11 AM > Subject: Re: reading compat flash causing emac network drop packets? > To: Arie de Muijnck <[email protected]> > > > Thank you for the reply, I will try that out and let you know the outcome. > One question in my mind is if that is the case, why nfs reading can still > go through. > > Bin > > > On Fri, Mar 6, 2009 at 2:55 AM, Arie de Muijnck <[email protected]> wrote: > >> From: Bin Liu >> >> Hi, I am trying to read transport stream file from compat flash and stream >> out to the ethernet port, >> and I am using customer DM6446 board, running 2.6.10 Linux. >> When bitrate is low, less than 10 Mbps, there is no problem, but if >> bitrate goes up to anything higher >> than 15 Mbps, I am seeing the packet drops. >> So far I have made sure there is no packet drop before packet is handed >> over to ethernet emac driver, >> and the cpu usage is not very high(around 30%) when dropping packet, if I >> read the file from nfs server seem to be fine, so I doubt the cf driver is >> causing the packet drop, anybody can shad some light >> >> This is I think a known 'feature'. >> The maximum length of a DDRAM access burst is default set to 'infinite', >> meaning a low-priority access may block a high-priority DMA transfer such as >> used for the EMAC TX. See the errata sheet for the fix, the memory burst >> control register is mentioned there, the default is the special value 0xFF >> meaning infinite and should be set to 0x20 meaning 32. >> >> Regards, >> Arie de Muijnck >> > > >
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
