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