DM6446 EMAC Silicon 2.1 and Driver Questions

Which LSP version are you using?  Let me know so I can point someone from our driver team to this thread.

PG 2.1 was to fix bugs in the device.  Looking in the errata I see the following bugs were fixed in PG 2.1:

Advisory 1.3.1 VPBE: Limited OSD Window Addressing Range
Advisory 1.3.2 EMU: Loss of DSP/ARM/ARM ETM Cross Triggering Capability Halts Emulation
Advisory 1.3.6 DSP Shutdown: DSP Clock Stop Sequence Does Not Work
Advisory 1.3.7 VLYNQ: VLYNQ Clock Buffer has Limited Drive Strength
Advisory 1.3.8 VPBE: OSD Field Signal is Inverted for All but Video Window 0
Advisory 1.3.9 VPBE: Video Window 0 is Shifted When Overlaid by Video Window 1
Advisory 1.3.10 VPBE: RGB888 Video Windows Corrupted When Overlaid by OSD Windows
Advisory 1.3.14 Device Configuration: MSTPRI0 Register Does Not Work. MSTPRI1 Register Affects All Fixed-Priority
Masters
Advisory 1.3.15 Clock Domain: Peripherals in the Fixed-Clock Domain (MXI) may Lose Register Contents if Clock is
Turned Off
Advisory 1.3.16 L1D Cache: C64x+ L1D Cache May Lose Data or Hang DMA Operations Under Certain Conditions
Advisory 1.3.17 DSP Subsystem: C64x+ CPU STORE Instruction to Any MMRs or EMIFA While IDMA Channel 0
Transfer is in Progress Can Hang C64x+ CPU
Advisory 1.3.22 PSC: PTSTAT Register Does Not Clear After Warm/Maximum Reset
Advisory 1.3.23 EMU: Poor Quality of the RTCK and TDO Emulation Signals May Cause Loss of Synchronization
Advisory 1.3.24 ARM: Concurrent Access to ARM Internal Memory May Fail
Advisory 1.3.25 VPBE: AC Timings Differ From Data Manual Specifications
Advisory 1.3.26 USB: Electrostatic Discharge (ESD) Sensitivity Classification
Advisory 1.3.35 VPBE: Video Corruption on VIDWIN1 Caused by Synchronization Issue
Advisory 1.3.38 EMIFA: AC Timings Differ From Data Manual Specifications

I wouldn't expect any of these to have any impact on EMAC operation.  I'll do a bit more asking to make sure, but all/most changes should be captured above.

Brad,

I believe it is LSP 1.2

The latest version in the davinci_emac.c header is:

4.0 Kevin Hilman, Anant Gole - Linuxification of the driver

and

 *  14Feb2006    Anant Gole                 Re-written for linux

for davinci_emac_phy.c

Do you know which Montavista patch level you're at?  So you are still on 2.6.10 kernel?  I had it in my head that you guys updated to DVSDK 2.0 and the LSP 2.0 (i.e. 2.6.18 kernel).  Maybe that was a different project though.

So what exactly is the problem you're seeing?

Brad,

Were at 2.6.10.4.  Were planning on upgrading, but haven't done it yet.

The problem we are seeing is more at the application level, when video data is transmitted via an rtsp stream (udp data), in some cases the far end video is corrupted.  However, the analog output is fine, and other formats with a custom protocol with retires are fine, so the mpeg encoder is fine.  Therefore the problem is in the path from the rtsp encoder to the phy chain somewhere.

This problem seems to have shown up in the latest version of the silicon without any other changes on the board, but we are also investigating the phy side of things, which in our case is a broadband over powerline device.  Anyhow, I'm trying to figure out exactly what is going on with this driver for now and understanding what happens to those constants is somewhat key.

Mike,

Sorry for the delay -- I'm trying to find one of our Ethernet experts to have a look at your question on the #defines.

Anything new on your end?

Brad

Brad,

I've done some further testing and it does seem to point back to the latest version of the Davinci.  Were getting a board re-worked with an older version as a further confirmation, so I should have that early next week.

I measured out the MDIO clock and it was faster than we wanted, so I changed the define statements to our PLL1/6 frequency and set the MDIO interface to run at 1MHz.  I verified this change with the scope, it’s actually running at 978 kHz, but it is close enough and within spec of the external chip.  The problem did not go away after making this modification.

I then wired in an ethernet phy in place of the powerline phy on a board that was exhibiting this problem and found the video breakup problem remained.  This leads me to thinking that the external phy does not seem to be the problematic element in the data path.

We have been playing around with the data path and found an interesting scenario.  In the case where this failure is seen most often, the input data buffer is passed to the resizer and the output/display buffer is wiped with a memeset.  The output of the resize block is set on the display buffer.  If we remove this memset function to wipe the buffer and leave the buffer with the video data from the input, the break up does not seem to occur.

However, this memset on the initial buffer has been there for years and only seems to be causing an issue on the new version of the Davinici.  So were looking at clearing out the rest of the display around the resized image using another method that may give us a workaround, but we had been doing this for years without problem until the new version of the chip.  I’m planning on working on this workaround a bit more first, then probably parsing more closely through the errata and seeing if we may somehow be hitting something I missed before.

Let me know if you think you might be able to point me in any particular direction.

Mike

I recommend that you look at Advisory 1.3.8 in particular.  There has been a software workaround for this issue in the drivers for years.  However, now that the issue is fixed, the software workaround will actually cause things to break!  You need to be sure your kernel is sufficiently up to date.  The newer drivers will detect the silicon revision and apply the workaround only if the silicon revision contains the bug.  You need to have Patch Level 14 for LSP 1.20 in order to have this code.  The LSP 1.20 Patch Level 14 release can be downloaded here if you're not sure whether or not you have it.

Brad,

I did see that one when I was parsing through, but after talking with the software guys, we don't use the OSD engine, but instead to the overlays via the ARM directly so that Errata shouldn't be in play.

I'll look into updating the driver with the current patch level.

Mike

Brad,

I guess I should clarify a little.  We don't use the OSD engine for the digital output stream.  The encoded MPEG4 stream comes out the DSP and is sent to the OSD as well as an RTSP library.  Since we are seeing the problem with the digital stream and not on the analog stream, I don't believe that particular problem is the issue.

We've been looking into the removal of the memset a little further and I'm wondering if the note 2.1.2 Bus Priority Inversion might be effecting our stream.  I've got to check if our time limit is set to the default or something smaller, but I could see a problem with that and an operation like memset.

Also, after looking further, it appears our base revision is actually 1.1.0.0.30, not 1.2.  We have applied many patches since then and pulled in some stuff from 1.2 like the resizer, but as we were discussing earlier, we really need to get upgraded.

It looks like this workaround removing the memset operation might work for the moment, then we can upgrade and see if we are still having problems.

Mike,

Is there more info you need from TI related to this issue?  Any further updates from your end?

Best regards,
Brad

Brad,

We got the boards back where we replaced the TMS320DM6446AZWT with TMS320DM6446ZWT and the problem we were experiencing went away.

So.... Other than the 2.1.42/1.3.8 OSD Field Signal Inverted driver fix, are there any other 2.1 silicon specific driver changes?

Thanks

Brad,

Also, I did try the fix removing the workaround for 1.3.8 since this is specific to 2.1 and it did not solve the problem.  I'm hoping you might be able to point to another driver fix specific to silicon 2.1.

Here is a diff file with the changes made per the errata sheet:

@@ -730,7 +730,7 @@
     DBGENTER;
     if (is_win(id, VID0))
         /* Turning off VID0 use due to field inversion issue */
-        dispc_reg_merge(OSD_VIDWINMD, 0, OSD_VIDWINMD_ACT0);
+        dispc_reg_merge(OSD_VIDWINMD, 1, OSD_VIDWINMD_ACT0);
     else if (is_win(id, VID1))
         dispc_reg_merge(OSD_VIDWINMD, on, OSD_VIDWINMD_ACT1);
     else if (is_win(id, OSD0))
@@ -1645,7 +1645,7 @@
     set_bg_color(0, 162);
 
     /* Field Inversion Workaround */
-    dispc_reg_out(OSD_MODE, 0x200);
+    //dispc_reg_out(OSD_MODE, 0x200);
 
     /* Setup VID0 framebuffer */
     if (!(dmparams.windows & (1 << VID0))) {

Brad,

That was the problem.  When I re-wrote the MSTPRI0 with the MSTPRI1 values, the issue we were dealing with went away.  I then tried only modifying the EMAC priority in MSTPRI0 to share the same priority as the ARM and the problem still was not there.

This leads me to believe that the EMAC must have been getting starved out during operations where the ARM was holding the bus too long, in our case a memset operation on the whole video buffer each video frame.

This leads to a couple of follow up questions.  First, there isn't really detailed documentation on the switched central resource, but based on my observations, it appears that when multiple resources with the same priority want access to the bus there is a round-robin type action for arbitration and I'm guessing that the round robin action takes place after PBBPR clock cycles in the case of the DDR?

Also, is there any way of monitoring this behavior from our applications point of view, is there any flag that we could have monitored that would have let us know the EMAC was getting starved?

It looks like in our application, the best course of action would just be to set the priorities in MSTPRI0 back to the values that were used prior to silicon 2.1 (were just using the defaults, so the value would be 0x444444), which would give the same priority to the ARM DMA, ARM Config, DSP Config, EMAC, USB, ATA, and VLYNQ.  Can you think of any adverse effects this may have if the ARM doesn't have a higher priority on the bus than the EMAC for example?

Last, is there a more detailed document on the switched central resource?  I wasn't able to find anything that even really described the type of transactions were handled over the ARM DMA bus vs the ARM CFG bus or the C64x Config bus, let alone a detailed description of operation.

Thanks again for all of your help,

Mike

Brad,

Sorry, one more thing, do you have any idea where the MSTPRI registers might be getting set in the EVM code?  I've searched through for the name and haven't found them yet, but they must be getting setup in the application because I tried changing it in the bootloader, but it gets overwritten each startup by the application.  I'll keep looking, but I figured you might know off the top of your head.

Thanks,

Mike

MikeP said:

When I re-wrote the MSTPRI0 with the MSTPRI1 values, the issue we were dealing with went away.  I then tried only modifying the EMAC priority in MSTPRI0 to share the same priority as the ARM and the problem still was not there.

YES!!!  Glad to hear it's fixed!  :)

MikeP said:

First, there isn't really detailed documentation on the switched central resource, but based on my observations, it appears that when multiple resources with the same priority want access to the bus there is a round-robin type action for arbitration and I'm guessing that the round robin action takes place after PBBPR clock cycles in the case of the DDR?

Close.  When there are multiple requestors of the same priority then you are correct that there is round-robin type arbitration.  However, the PBBPR arbitration occurs later.  The PBBPR register is part of the DDR2 controller.  There are some queues local to the DDR2 controller and once data has gone through the SCR to the DDR2 controller that's when this PBBPR capability comes into play.

MikeP said:

Also, is there any way of monitoring this behavior from our applications point of view, is there any flag that we could have monitored that would have let us know the EMAC was getting starved?

Not that I know of, besides the fact that your system stopped working properly!

MikeP said:

It looks like in our application, the best course of action would just be to set the priorities in MSTPRI0 back to the values that were used prior to silicon 2.1 (were just using the defaults, so the value would be 0x444444), which would give the same priority to the ARM DMA, ARM Config, DSP Config, EMAC, USB, ATA, and VLYNQ.  Can you think of any adverse effects this may have if the ARM doesn't have a higher priority on the bus than the EMAC for example?

This all comes down to tuning for an individual system.  Ultimately you want settings where everything works, so if you've already achieved it then I would just leave it.  If you want to be really thorough you might look at things like the ARM CPU load, video output, etc and see what effect the various settings have.  You might be able to "tune" a little more.  The overall effect of a change can be hard to predict.

MikeP said:

Last, is there a more detailed document on the switched central resource? 

Wow, you're right!  All I could find is this:

• Ch 4 "System Interconnect" of datasheet.
• Ch 10.8.1 "Bus Master DMA Priority Control" of ARM Subsystem Reference Guide.

If you have further questions specific to the SCR then I recommend starting a "fresh" thread.

Sorry, don't know that off the top of my head and I'm actually traveling right now with no easy way to look.