[PATCH v2] staging: tidspbridge: request dmtimer clocks on init

[Ramirez Luna, Omar]

On Thu, Dec 8, 2011 at 1:50 PM, Felipe Contreras
<felipe.contreras at gmail.com> wrote:
> On Thu, Dec 8, 2011 at 9:10 PM, Ramirez Luna, Omar <omar.ramirez at ti.com> wrote:
>> On Wed, Dec 7, 2011 at 4:11 PM, Felipe Contreras
>> <felipe.contreras at gmail.com> wrote:
>>> On Sat, Nov 19, 2011 at 12:18 AM, Omar Ramirez Luna <omar.ramirez at ti.com> wrote:
>>>> Given that dm timer framework doesn't support request of clocks
>>>> by soft | hard irqs because some recent changes, tidspbridge needs
>>>> to request its clocks on init and enable/disable them on demand.
>>>>
>>>> This was first seen on 3.2-rc1.
>>>>
>>>> Signed-off-by: Omar Ramirez Luna <omar.ramirez at ti.com>
>>>
>>> This looks similar similar to this one:
>>> http://article.gmane.org/gmane.linux.ports.arm.omap/61816
>>>
>>> Are you sure this is what we want instead of that one?
>>
>> I believe your patch only takes care of gpt5 and gpt6, but not of the
>> other 2 that could be requested by the dsp, let's say gpt8 for avsync.
>
> I'm not really sure about that... Judging from the code, the only
> timers needed used to be initialized on bridge_brd_start based on the
> symbols of the baseimage. If you say that's not enough, then I guess
> that's fine (not really surprising that the old code missed that).

I meant the dsp by itself can generate that request. That is why it is
not explicitly seen in the code.

>> - Handles the other gpt that can be requested by the dsp.
>
> And I guess which clocks are going to be used is not discoverable somehow...

It is basically the pool of clocks of the dsp is formed by mcbsp, gpt,
wdt, ssi. The dsp can request any gpt from 5 to 8 according to the
binary you are running on the dsp side. That's the reason it is
somewhat hidden what clock the dsp needs.

>> - Uses start/stop according to future plans of making enable/disable static.
>
> Yeah, but that's easy to change s/enable/start/ s/disable/stop/

Agree

>> - Might be temporal if *dm_timer_request* functions are fixed and
>> there is an overall feeling that we can revert to use
>> request+start/stop+free on request.
>
> At which point we would end up with something similar to my patch :)

Yes, plus handling the other clocks that can be available to the dsp.

> Anyway, I guess there's not much problem in requesting extra clocks
> that we would not use.

AV playback does use gpt8, but for systems that doesn't use gpt8 it is
best to use the old approach of just request/free prior to dm timer
changes.

Regards,

Omar