Syslink

Hi Igor,

What makes you say that?  I just checked various Linux source code versions and all had the L_PTE_MT_* symbols as bitmap macros (#defines).

Regards,

- Rob

Hi Rob,

Just look at the values at arch/arm/include/asm/pgtable.h:

#define L_PTE_MT_BUFFERABLE     (0x01 << 2)     /* 0001 */
#define L_PTE_MT_WRITETHROUGH   (0x02 << 2)     /* 0010 */
#define L_PTE_MT_WRITEBACK      (0x03 << 2)     /* 0011 */

Following your logic, we have: L_PTE_MT_BUFFERABLE  + L_PTE_MT_BUFFERABLE  = L_PTE_MT_WRITEBACK :-)

Check ARM 7+ memory types at  arch/arm/mm/proc-v7.S and page table entry format at

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0198e/I16780.html

Thanks,

Igor

Igor Serikov said:

Just look at the values at arch/arm/include/asm/pgtable.h:

#define L_PTE_MT_BUFFERABLE     (0x01 << 2)     /* 0001 */
#define L_PTE_MT_WRITETHROUGH   (0x02 << 2)     /* 0010 */
#define L_PTE_MT_WRITEBACK      (0x03 << 2)     /* 0011 */

Hi Igor,

I believe that the L_PTE_MT_WRITEBACK symbol is just a high-level name for the combination of L_PTE_MT_BUFFERABLE | L_PTE_MT_WRITETHROUGH.  According to the doc page that you linked, bit 2 is "B" and bit 3 is "C", so they are indeed separate bits in a bitmask.

Perhaps SysLink could use L_PTE_MT_WRITEBACK in place of L_PTE_MT_BUFFERABLE | L_PTE_MT_WRITEBACK, but it doesn't seem wrong as it is.

Regards,

- Rob

Hi Rob,

ARM supports a set of distinct cache policies, see the link:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0246c/Cjabgaff.html

Thanks,

Igor

Hi Igor,

That's an interesting page to which you linked, thankyou for that.

Do you still have some concern about SysLink existing behaviour?

Is there some enhancement request you'd like to make for SysLink?

I get the impression that you'd like some other "cache" attributes available for this SysLink functionality, but I don't see a problem with what it's currently doing, at least as it relates to your original question.

Regards,

- Rob

Hi Rob,

I would like to have more control over caching policies. Technically, the code branch we were discussing is for "not normal" memory. The other one, for the "normal"" memory has to sub-branches: cached and un-cached. The policies used are: "write back" and "bufferable". I would like to have "write through"  in the first case. The advantage is obvious: I just need insert data synchronization buffer which would stall the execution until the write buffers is drained. When it is drained, it is guaranteed that the data is in the memory, if the policy is "write through". I do not need to flush the cache. Of course, there could be other scenarios, so it is better to have a choice. By the way, does DSP-side software (syslink/ipc) examines "cacheEnable"? DSP and host side caching should be set separately. Yet, setting MAR manually does not look good too.

Another questions is DSP clock setup. I have OMAP 3621. Syslink just resets the registers and the default clock divider gives a very low frequency. Where/when do I need to set it up?  Are there any dependencies  between ARM, bus and DSP frequencies?

Thanks,

Igor

Igor Serikov said:

I would like to have "write through"  in the first case. ...  When it is drained, it is guaranteed that the data is in the memory, if the policy is "write through

This use case seems to be application-specific, so unless a strong general case can be offered to support this request I don't expect that such a feature would make the grade for a SysLink release.

You're free to change your SysLink source code and rebuild it, so I would suggest that route for now.

Igor Serikov said:

By the way, does DSP-side software (syslink/ipc) examines "cacheEnable"? DSP and host side caching should be set separately. Yet, setting MAR manually does not look good too.

DSP-side caching is controlled separately from the ARM-side caching.  DSP cacheability is controlled by the MAR registers and L1/L2 cache configuration, as you probably already know.  The DSP executable is built with a .cfg config file which specifies the MAR settings and L1/L2 cache size.  SYS/BIOS/Ipc does *not* set any MAR or L1/L2 cache setting based on seeing the "cacheEnable" bit of a SharedRegion, so it is the user's responsibility to ensure they "match up".

Only the DSP's runtime behaviour with respect to the cache is controlled by the SharedRegion's cache attribute - if a SharedRegion is configured (in the DSP .cfg file) as cacheable then the DSP-side then SysLink & Ipc software will perform cache maintenance operations when appropriate (writeback, invalidate, or writeback-invalidate).

For SharedRegions, ARM-side caching is controlled by a special SharedRegion property (see SysLink_params description at http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/syslink/latest/docs/html/_sys_link_8h.html), and this property controls both the HW setting and SysLink runtime behaviour.  For non-SharedRegions, the application controls the cacheability through a parameter to the memory mapping API, and the application manually maintains the cache at appropriate points.

Igor Serikov said:

Another questions is DSP clock setup. I have OMAP 3621. Syslink just resets the registers and the default clock divider gives a very low frequency. Where/when do I need to set it up?  Are there any dependencies  between ARM, bus and DSP frequencies?

I'm pretty sure that SysLink does not set the DSP operating clock frequency, although I'm not positive about the OMAP3 in particular.  Either u-boot or the Linux kernel would be responsible for that.  SYS/BIOS needs to be "told" of the DSP's frequency so it can properly calculate or calibrate certain timing relationships, but it does nothing to set the frequency.

Regards,

- Rob

Hi Rob,

Thank you for the information.

What I found is that omap3530_hal_reset.c resets IVA2 thus setting the clock dividers and sources to defaults.

1. Is it OK to change an IVA2 clock divider in the DSP-side program?

2. Are there any dependencies between DSP, ARM and bus clocks?

3. What is the way to bring the DSP into a low power mode without decreasing the frequency? Any idle state? (I do it when there are no DSP requests).

Regards!

Igor

Igor Serikov said:

1. Is it OK to change an IVA2 clock divider in the DSP-side program?

I had to ask around, but got the response "Yes, I think the DSP can change the dividers.".

Igor Serikov said:

2. Are there any dependencies between DSP, ARM and bus clocks?

Again from asking around "I think the clocks are mostly de-coupled and can be changed independently.  But I think there are some ratio requirements that need to be maintained, e.g., the CPU clock must be a factor of N in relation to the XYZ bus clock rate."

Also, SYS/BIOS needs to be informed of the correct DSP clock speed so it can relate real-time with CPU cycles.

Igor Serikov said:

3. What is the way to bring the DSP into a low power mode without decreasing the frequency? Any idle state? (I do it when there are no DSP requests).

The “IDLE” instruction can be invoked by the DSP to have it execute NOP instructions continuously, with no external program fetches.  Any enabled interrupt will pull the CPU out of the IDLE instruction to run the ISR.  SYS/BIOS supports entering this IDLE state during it's "Task_idle()" loop, with the proper configuration.

I was also going to suggest that you could use the SYS/BIOS Power module to "hibernate" the DSP, but I have been informed that this module is not available for the OMAP3530 (and OMAP3621 by extension), nor will it be in the future.

Regards,

- Rob