EDMA3 channel controller config register for different devices

Vladimir,

Could you be specific, please, about a discrepancy that you find between two devices? You mention the C6424, but all other device numbers in your post have an x in them, meaning there are several devices which can vary in design and implementation.

TI provides CSL libraries with header files that include resource implementations for most devices. Or these may be implemented as part of the EDMA3 LLD for a device. Different members of the C6000 family may be targeted for different applications, and for that reason TI may offer different methods for getting the software and hardware configured such that these applications are implemented efficiently.

If you would like to explain the algorithm and rules that you are pulling from our documentation, we may be able to comment. The intention of these registers was to document features, and if we have done that incorrectly we would like you to point that out.

Regards,
RandyP

Randy,

I have prepared a simple table to view all C6000 devices at glance:

8484.c6x-edma3.pdf

I inferred some formulas (please see the document in pdf). Initially I used a few devices to check some cases. Then I wondered whether these formulas apply to all the family. And got into trouble with all 674x devices. That's why I used an x. However, today, when I was working on this table and had to download all EDMA documentation once again I saw that reference manuals for 6743, 6745 and 6747 have been updated to revision B in march 2013. And now they have fixed CCCFG values. Reference manual for 6748 has revision A for now and there is a error in CCCFG description. When I strarted a topic I looked at revision A for all C674x devices which were downloaded couple on months ago. So, my conclusion is that this was a documentation error in revision A, and all devices actually have CCCFG encoded using the same rules.

I want to point out that there are still some errors in CCCFG description for C6474 and TCI6487/88. You can see all the differencies highlighed with red bold text.

Another question is about Transfer Controller PID register. Some devices have values of 0x4000???? pattern, that looks similar to PID of channel controller, e.g. 0x40015300. However, some devices have TC PID that is exacly the same as CC CCCFG register, e.g. 0x03334425, nothing common with 0x4000????. Is that a error?

Another issue applies to C6678. CC PID does not have a documented lower half word in CC PID. I couldn't find the value of y neither in datasheet, nor in EDMA user guide.

Best regards, Vladimir

Vladimir,

You have done a lot of work trying to implement something that you may find very useful.

Can you please be clear and detailed about any documentation errors that you believe exist? "Some devices" is not something we can dig into very easily, and the specific documentation error for some C674x device would be easier for us to follow-up with.

Regards,
RandyP

Randy,

I think was clear enough providing you with detailed table in my previous post. You can see there several numbers shown using bold red text. The most right column of the table specifies the socument which was a source of data. You can check my table for these few cases: TCI6487/88, C6474, C6748.

1. TCI6487/6488, C6474. EDMA CCCFG values do not match with formal EDMA features description. There are 8 QDMA channels, not 4. There are 6 transfer controlers, not 4. I also highlighted C6457 descriprion in bold since it is the only one device for now which has correct CCCFG values for 6 TCs. Also, I suspect that C6472 has the same EDMA with TCI64782/86, and C6474 has same EDMA with TCI6487/88. But now they are documented such that C6472 abd all TCI chips are described in SPRU727E, and only C6474 is described in SPRUG711. So, the documents should be fixed I think.
2. C6748 has wrong values in CCCFG descriprion. This is a error of revision A. Previously, the same errors were for C6743/5/7 devices but they were fixed in revision B of reference manual. I suppose that C6748 also needs update to revision B.

My goal is to implement more intelligent EDMA support in linux. Original driver provided with c6x-linux project required all the EDMA parameters to be passed through the platform_data attached to platdorm_device. Now the driver needs only i/o address space resource definition, all other things are acquired during driver probe method by reading CCCFG. Thus, driver code is simple, most of #ifded/endif code was removed. Also, other modules can now dynamycally link to EDMA driver. For example, AEMIF NAND driver can use EDMA accelerator if EDMA driver is loaded or can use older CPU-based data copy if EDMA is not loaded. But in both cases driver nand will work.

Vladimir,

Vladimir Dashevsky said:

TCI6487/6488, C6474. EDMA CCCFG values do not match with formal EDMA features description. There are 8 QDMA channels, not 4. There are 6 transfer controlers, not 4.

Thank you. This information is the detail I was looking for. Knowing exactly what you have found to be incorrect allows me to find that reference.

In the C6474 EDMA3 User's Guide, CCCFG.NUM_QDMACH is shown differently in Figure 4-2 and Table 4-3. The Figure shows a default value of 2 while the Table shows a single available value of 4. The Table says that the value of 4 represents the correct value of 8 QDMA channels.

I will pass this item on to the team supporting the documentation for the C6474. It is possible for the documentation to be updated, but I cannot offer any true insight into that. If there is a discrepancy between the silicon value in the register and the documentation, the consideration would be to update the documentation to match the silicon and not the formula.

Thank you for your continued patience and support on this.

Regards,
RandyP