Nishanth Menon wrote: > Kevin Hilman had written, on 04/28/2010 12:59 PM, the following: >> Omar Ramirez Luna <omar.rami...@ti.com> 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.rami...@ti.com> writes: >>>>> >>>>>> On 4/28/2010 2:46 AM, Felipe Contreras wrote: >>>>>>> On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez >>>>>>> Luna<omar.rami...@ti.com> 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. Added to this, the fact that GPT PWM is > usable on 9,10,11 as well, makes me believe this is something to > consider as part of board design based on which peripherals one uses and > their constraints. BIOS is not at fault here to use the resources it > requires, but is part of system design to look at options, constraints > and select the ones appropriately.. > > A similar example is mux pins, you have options to plug to one of many > options, but if you plug in both a interrupt and a data line to the same > pin which could run in two different modes, there is a problem there > right? Alright, that is too obvious i suppose....
Yes, just that pin mux issues are pretty obvious reading the TRM and DM, but the fact that bridge blocks GPT5,6 and 8 is not. You are telling me that using all 4 GPTs for PWM or input event capture is not possible when using dspbridge? As I understand, bridge mostly uses 2 of the GPTs (6 for load monitoring, 8 for sync/mmu fault), so I think moving GPT8 to 7 should make both sides happy, no? Regards, Vladimir -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
