On 4/28/2010 10:50 PM, Kevin Hilman wrote:
Nishanth Menon<nm@xxxxxx> writes:
Kevin Hilman had written, on 04/28/2010 12:59 PM, the following:
Omar Ramirez Luna<omar.ramirez@xxxxxx> 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@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.
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
--
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
