OMAPL-138: Service PRD_Tick() externally

Arya Ba

Hi All,

Note: Using BIOS 5.33.05 / DSPLink 1.65.00.03 on the OMAP-L138 with Linux on the ARM Core.

We are currently using a 1 msec HWI timer in our system for the BIOS PRD_Tick() and some timekeeping functions. Ideally, we would like to relocate the HWI into a PRU to save some horsepower on the DSP. Any ideas on how we could call the PRD_Tick() externally with a PRU ? Or reconfigure our system to not use the PRD_Tick() and still save the 1 msec HWI overhead ?

Thank you,

Arya B.

over 11 years ago

0 Alan DeMars over 11 years ago

TI__Mastermind 30830 points

Arya,

I don't see how you could invoke PRD_tick() from another processor other than the processor running DSP/BIOS. The other "timekeeping functions" you refer to may be be able to be ported to another processor but the PRD_tick() function interacts with the kernel's internal data objects which are carefully managed and protected using single-processor critical section protection mechanisms.

Alan

0 Arya Ba over 11 years ago in reply to Alan DeMars

Intellectual 690 points

Hi Alan,

Thank you very much for the prompt response. That makes complete sense, so there is no way to save the overhead of the 1 msec ISR in DSP/BIOS ?

Thanks,

Arya B.

0 Alan DeMars over 11 years ago in reply to Arya Ba

TI__Mastermind 30830 points

If you already have another periodic interrupt that you can use to call PRD_tick() from you can save the ISR overhead.

You could also reduce the effective ISR overhead by increasing the period of the CLK interrupt: For instance, the code below would set the period to 10ms rather than 1ms:

CLK.MICROSECONDS = 10000; /* this would result in 1/10 the ISR overhead */

But remember that the timeout values sent to Task_sleep() are in CLK.MICROSECONDS units.

Alan

0 Arya Ba over 11 years ago in reply to Alan DeMars

Intellectual 690 points

Excellent, we do have another ISR that can used for the PRD_tick() and can off load our own timekeeping into the PRU. What are the repercussions of increasing CLK.MICROSECONDS ? You mentioned Task_sleep(), are there any other DSP/BIOS timing components that rely on the PRD_tick() ?

Thank you very much for the prompt responses and help,

Arya B.

0 Alan DeMars over 11 years ago in reply to Arya Ba

TI__Mastermind 30830 points

All timeouts will be in these units. SEM_pend(), MBX_pend/post(). Apart from that, I don't know of any other side effects.

Alan

0 Arya Ba over 11 years ago in reply to Alan DeMars

Intellectual 690 points

Interesting, hypothetically if we change the CLK.MICROSECONDS to 5 msec, would that mean when we SEM_post() the corresponding SEM_pend() can take upto 4msec to release the task ?

Thanks,

Arya B.

0 Alan DeMars over 11 years ago in reply to Arya Ba

TI__Mastermind 30830 points

No. SEM_post() will immediately unblock the TSK which will then run if it has become the highest priority task ready to run.

Alan

0 Arya Ba over 11 years ago in reply to Alan DeMars

Intellectual 690 points

Great, so I guess the only time it would be affected is if we specify a timeout in the SEM_pend() ?

Thanks,

Arya B.

0 Alan DeMars over 11 years ago in reply to Arya Ba

TI__Mastermind 30830 points

Yes.

If your SEM_pend() uses SYS_FOREVER, then the change in MICROSECONDS has no effect on SEM_pend()/SEM_post() behavior.

Alan

0 Arya Ba over 11 years ago in reply to Alan DeMars

Intellectual 690 points

Hi Alan,

Excellent, Thank you very much for all your help.

Thanks,

Arya B.

Processors

Processors forum

OMAPL-138: Service PRD_Tick() externally