From: "Albrecht Dreß" <albrecht.dress@arcor.de>
To: linuxppc-dev@ozlabs.org
Subject: [Q/RFC] mpc52xx gpt api
Date: Sun, 15 Nov 2009 18:17:33 +0100 (CET) [thread overview]
Message-ID: <283847.1258305453891.JavaMail.ngmail@webmail10.arcor-online.net> (raw)
Hi all,
I tried to use a '5200B internal timer for a very simple task - as pwm to m=
ake a led blink, but apparently the current gpt implementation from Grant's=
tree does only support internal (cpu timer) modes which do not use the tim=
er io pin.
The first hurdle was to actually get the timer itself - mpc52xx_gpt_from_ir=
q() never returned something when I passed the timers (v)irq to it. What i=
s the intended use of this function? BTW, I do not need timer irq's, so I =
believe there should be an other way to grab a timer!
I made several changes to finally get the pwm timer running for me with the=
current implementation, but IMO it might be interesting to have a more gen=
eric api. Before digging into it, I would be interested in any comment abo=
ut the following approach, which could cover all possible gpt operating mod=
es:
* struct mpc52xx_gpt_priv *mpc52xx_gpt_grab(const char * name, mode)
name: timer name, e.g. "f0000630.timer", or NULL for the next free cpu ti=
mer
mode: CPU, PWM, IC or OC. The latter three are only possible if the requ=
ested timer shall not be used as gpio (i.e. the device tree does not regist=
er it as such)
The function shall mark the timer as being in use, to avoid access confli=
cts.
It might also make sense to pass an irq callback function here. The gpt =
module would catch the hw irq, clear the status flags, and then call this f=
unction.
* int mpc52xx_gpt_setup
Configure period, continuous (cpu only), pwm width and polarity (pwm only=
). Didn't look into the special IC/OC requirements yet. Probably it makes=
sense to provide different functions for the four different modes (mpc52xx=
_gpt_setup_internal, mpc52xx_gpt_setup_pwm, etc.). We might then omit the =
mode parameter of the "grab" function, and shift the gpio vs. timer pin con=
flict check here.
The function shall always change the timer registers, even if the timer i=
s already running, which is convenient if e.g. the pwm output waveform shal=
l be changed on the fly.
* int mpc52xx_gpt_runstate(struct mpc52xx_gpt_priv *, int running)
Start/stop the timer
* int mpc52xx_gpt_release(struct mpc52xx_gpt_priv *)
Release timer, so an other mpc52xx_gpt_grab() will succeed.
Opinions?
Cheers, Albrecht.
Jetzt NEU: Do it youself E-Cards bei Arcor.de!
Stellen Sie Ihr eigenes Unikat zusammen und machen Sie dem Empf=E4nger eine=
ganz pers=F6nliche Freude!
E-Card Marke Eigenbau: HIER KLICKEN: http://www.arcor.de/rd/footer.ecard
next reply other threads:[~2009-11-15 17:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-15 17:17 Albrecht Dreß [this message]
2009-11-20 22:04 ` [Q/RFC] mpc52xx gpt api Grant Likely
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=283847.1258305453891.JavaMail.ngmail@webmail10.arcor-online.net \
--to=albrecht.dress@arcor.de \
--cc=linuxppc-dev@ozlabs.org \
/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;
as well as URLs for NNTP newsgroup(s).