public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: Vladimir Pantelic <pan@nt.tu-darmstadt.de>
Cc: Kevin Hilman <khilman@deeprootsystems.com>,
	"Ramirez Luna, Omar" <omar.ramirez@ti.com>,
	Felipe Contreras <felipe.contreras@gmail.com>,
	linux-omap <linux-omap@vger.kernel.org>,
	Ameya Palande <ameya.palande@nokia.com>,
	Hiroshi Doyu <Hiroshi.DOYU@nokia.com>,
	Felipe Contreras <felipe.contreras@nokia.com>,
	Omar Ramirez Luna <omar.ramirez@hotmail.com>
Subject: Re: [PATCH v2] DSPBRIDGE: use dm timer framework for gpt timers
Date: Wed, 28 Apr 2010 14:57:17 -0500	[thread overview]
Message-ID: <4BD8931D.7080307@ti.com> (raw)
In-Reply-To: <4BD891F8.7000609@nt.tu-darmstadt.de>

Vladimir Pantelic had written, on 04/28/2010 02:52 PM, the following:
> Nishanth Menon wrote:
[...]

>>>>> 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?

Seriously, is this debate going to close even then?
case a) some other guy is gonna use GPT7 then we are all screwed again
case b) the DSPBIOS guys need more GPT to do something else later on (I 
dont know what.. but just guessing), again screwed?
case c) *what if* some bloke is already using GPT7 for some reason of 
his own and he already has a board working, is'nt he screwed if we 
switch to GPT7 now?

-- 
Regards,
Nishanth Menon

  reply	other threads:[~2010-04-28 19:57 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-28  1:29 [PATCH v2] generic clk module removal Omar Ramirez Luna
2010-04-28  1:29 ` [PATCH v2] DSPBRIDGE: remove clk_handle from drv interface Omar Ramirez Luna
2010-04-28  1:29   ` [PATCH v2] DSPBRIDGE: fail if clk handle is NULL Omar Ramirez Luna
2010-04-28  1:29     ` [PATCH v2] DSPBRIDGE: Now actually fail if a clk handle is wrong Omar Ramirez Luna
2010-04-28  1:29       ` [PATCH v2] DSPBRIDGE: Rename services_clk_* to dsp_clk_* Omar Ramirez Luna
2010-04-28  1:29         ` [PATCH v2] DSPBRIDGE: remove unused clock sys_ck Omar Ramirez Luna
2010-04-28  1:29           ` [PATCH v2] DSPBRIDGE: remove function clk_set32k_hz Omar Ramirez Luna
2010-04-28  1:29             ` [PATCH v2] DSPBRIDGE: remove clk_get_use_cnt Omar Ramirez Luna
2010-04-28  1:29               ` [PATCH v2] DSPBRIDGE: trivial clock cleanup for unused code Omar Ramirez Luna
2010-04-28  1:29                 ` [PATCH v2] DSPBRIDGE: function to get the type of clock requested by dsp Omar Ramirez Luna
2010-04-28  1:29                   ` [PATCH v2] DSPBRIDGE: iva2 clock handling Omar Ramirez Luna
2010-04-28  1:29                     ` [PATCH v2] DSPBRIDGE: use dm timer framework for gpt timers Omar Ramirez Luna
2010-04-28  1:29                       ` [PATCH v2] DSPBRIDGE: use omap mcbsp to enable mcbsp clocks Omar Ramirez Luna
2010-04-28  1:29                         ` [PATCH v2] DSPBRIDGE: remove wdt3 from dsp control Omar Ramirez Luna
2010-04-28  1:29                           ` [PATCH v2] DSPBRIDGE: dsp interface to enable ssi clocks Omar Ramirez Luna
2010-04-28  1:29                             ` [PATCH v2] DSPBRIDGE: use one call for both ick and fck clocks Omar Ramirez Luna
2010-04-28  1:29                               ` [PATCH v2] DSPBRIDGE: Move MCBSP_CLOCKS code to a common place Omar Ramirez Luna
2010-04-28  1:29                                 ` [PATCH v2] DSPBRIDGE: Balance the number of enable/disable Omar Ramirez Luna
2010-04-28  1:29                                   ` [PATCH v2] DSPBRIDGE: move clk to dsp-clock Omar Ramirez Luna
2010-04-28  1:29                                     ` [PATCH v2] DSPBRIDGE: reorganize the code to handle peripheral clocks Omar Ramirez Luna
2010-04-28  7:46                       ` [PATCH v2] DSPBRIDGE: use dm timer framework for gpt timers Felipe Contreras
2010-04-28 14:15                         ` Omar Ramirez Luna
2010-04-28 16:29                           ` Kevin Hilman
2010-04-28 16:36                             ` Nishanth Menon
2010-04-28 17:00                               ` Omar Ramirez Luna
2010-04-28 17:11                                 ` Vladimir Pantelic
2010-04-28 17:22                                   ` Nishanth Menon
2010-04-28 17:59                                 ` Kevin Hilman
2010-04-28 18:56                                   ` Nishanth Menon
2010-04-28 19:52                                     ` Vladimir Pantelic
2010-04-28 19:57                                       ` Nishanth Menon [this message]
2010-04-28 20:50                                     ` Kevin Hilman
2010-04-29 13:40                                       ` Benoit Cousson
2010-04-29 14:12                                         ` Kevin Hilman
2010-04-28 17:02                               ` Uribe de Leon, Armando
2010-04-28 17:04                               ` Felipe Contreras
2010-04-28  1:34 ` [PATCH v2] generic clk module removal Nishanth Menon
2010-04-28 13:55   ` Omar Ramirez Luna

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BD8931D.7080307@ti.com \
    --to=nm@ti.com \
    --cc=Hiroshi.DOYU@nokia.com \
    --cc=ameya.palande@nokia.com \
    --cc=felipe.contreras@gmail.com \
    --cc=felipe.contreras@nokia.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=omar.ramirez@hotmail.com \
    --cc=omar.ramirez@ti.com \
    --cc=pan@nt.tu-darmstadt.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox