Re: [PATCH v2] DSPBRIDGE: use dm timer framework for gpt timers

[Benoit Cousson <b-cousson@ti.com>]

On 4/28/2010 10:50 PM, Kevin Hilman wrote:
> Nishanth Menon<nm@ti.com>  writes:
>
>> Kevin Hilman had written, on 04/28/2010 12:59 PM, the following:
>>> Omar Ramirez Luna<omar.ramirez@ti.com>  writes:
>>>
>>>> On 4/28/2010 11:36 AM, Menon, Nishanth wrote:
>>>>> Kevin Hilman had written, on 04/28/2010 11:29 AM, the following:
>>>>>> Omar Ramirez Luna<omar.ramirez@ti.com>   writes:
>>>>>>
>>>>>>> On 4/28/2010 2:46 AM, Felipe Contreras wrote:
>>>>>>>> On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez Luna<omar.ramirez@ti.com>    wrote:
>>>>>>>>> This patch switches to use DM timer framework instead of
>>>>>>>>> a custom one for GPT timers, currently dsp can make use of
>>>>>>>>> gpt 5, 6, 7 or 8.
>>>>>>>> I heard someone that was using gpt 8 for something else. Is it
>>>>>>>> possible to configure dsp-bridge to not use it?
>>>>>>>>
>>>>>>> There are two scenarios:
>>>>>>>
>>>>>>> 1. The request comes from the DSP side (afaik for video use case), the
>>>>>>> change should be in the DSP side binaries to request some other gpt
>>>>>>> instead. I don't know how possible is to get this changed.
>>>>>>>
>>>>>>> 2. bridge driver also requests gpt8 whenever a mmu fault is triggered,
>>>>>>> this to set a timer to interrupt the dsp after the mmu fault dump has
>>>>>>> been finished, I think this can be easily replaced in bridge to use
>>>>>>> some other gpt, but "1" is still there. (besides a new patch is needed
>>>>>>> to remove direct access to dm timer inside ue_deh and make it to go
>>>>>>> through dsp-clock)
>>>>>> Why does Bridge care at all which specific timers it requests?  They
>>>>>> are all the same, with the exception of GPT1 which is in the WKUP
>>>>>> powerdomain and already used as the kernel clocksource.
>>>>>>
>>>>>> Bridge should just use the generic _request() instead of
>>>>>> _request_specific()
>>>>>>
>>>>> trouble I believe is that DSP BIOS uses a specific timer.
>>>>>
>>>> yes, dsp side wants:
>>>> bios -->  GPT5 (only used during boot up ->  baseimage load)
>>>> load monitoring -->  GPT 6 (used while the dsp is awake)
>>>> AV Sync -->  GPT 8 (based on use case)
>>>>
>>>> to generate the interrupt for mmu fault case it needs one connected to
>>>> the dsp interrupt line and only 5, 6, 7 or 8 apply.
>>>
>>> Then DSP bios is broken by hard-coding *general purpose* timers.
>>   /me just eats my own words.
>> Not really.. I just got educated internally that DSP does not get
>> interrupts from all GPTs.
>> Ref: http://focus.ti.com/pdfs/wtbu/SWPU114Q_PrelimFinal_EPDF_03_05_2009.pdf
>> page 1753 ->  only mentioned these timers can generate interrupts for
>> DSP, and hence for BIOS's usage.
>
> OK, now that part makes sense.

This issue will be even worse on OMAP4 with the CortexM3 (aka Ducati), 
because several IPs like GPIO or GPTIMER will have different IRQ / 
functionality / power partitioning depending of the instance.
One of the proposed solution we considered, at least for the GPTIMERs, 
was to add an extra API that can allow to request a timer based on the 
needed capabilities and not based on index.

We can easily encode in each GPTIMER HWMOD the specificity of an 
instance like (HAS_DSP_IRQ, HAS_IPU_IRQ, HAS_PWM, IN_WKUP_DOMAIN, 
IN_AUDIO_DOMAIN...).
Driver can then use a request_timer_per_functionalies(HAS_DSP_IRQ | 
HAS_IPU_IRQ...).
It will allow driver to be much more independent of the current IP 
implementation for an OMAP version.

Any thoughts?

Regards,
Benoit