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@xxxxxx> 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@xxxxxx> 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.
Regards,
Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
