Benoit Cousson <b-cousson@xxxxxx> writes: > 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? Yes, this sounds much better. It makes a lot more sense than hard-coding specific GPT numbers. 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
