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

[Felipe Contreras]

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).

> As for this patch, dm timer framework should support request on soft
> or hard irq[1], but it can't because the underlying functions to use
> clk_get->clk_get_sys which holds a mutex.
>
> I believe your error was seen because of patches not in mainline, but
> the concept between the patches is similar indeed, however mine:

Yes, it's basically the same, the only difference is that I'm
initializing only the clocks that are supposed to be needed by the
baseimage.

> - 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...

> - 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/

> - 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 :)

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

Cheers.

-- 
Felipe Contreras