linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: joakim.tjernlund@lumentis.se
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: PWM on the MPC850
Date: Wed, 11 Dec 2002 15:50:54 +0100	[thread overview]
Message-ID: <20021211145059.27DECC613A@atlas.denx.de> (raw)
In-Reply-To: Your message of "Wed, 11 Dec 2002 14:55:42 +0100." <IGEFJKJNHJDCBKALBJLLAELKFIAA.joakim.tjernlund@lumentis.se>


In message <IGEFJKJNHJDCBKALBJLLAELKFIAA.joakim.tjernlund@lumentis.se> you wrote:
>
> > But be warned: do NOT use any of the port B pins for I/O  in  such  a
> > setup. There is a race condition within all MPC8xx CPUs.
>
> hmm, we access a few port B I/O pins from user space. What/where is the
> race in kernel?

It's not in the kernel, it's in the MPC8xxL.

The RISC timers are implemented in softtware (microcode)  running  on
the  CPM.  To  toggle  a PWM output pin, the CPM will read the port B
data register, modify the bit, and rewrite the port B data  register,
This  access is NOT synchronized against any accesses by the CPU. You
can test this by toggeling a port B pin with software running on  the
CPU:  after  each write to the port B data register read the register
back for a couple of times. You will find that,  as  soon  as  a  PWM
timer is running, the value you write will not "stick".

It's a classical race condition: the CPM reads PBDAT to modify a  PWM
pin, then the CPU writes a new value (modifying a different bit), the
the  CPM writes his copy back - and the value written by the CPU gets
lost. You can see this on an oscilloscope: the data  written  by  the
CPU will be actually there onthe outputs for some 15...25 ns (nano!),
and then drop back to the old state.

Moto never officially confirmed the problem, but the  MPC823E  UM  (I
didn't find this anywhere else) contains the traitorous words:

    [16.2.6.4.4 PWM Mode] ... Because the CPM has to read the
    data register, modify it and then write it back, you cannot
    use open drain output with the PWMs if the output can be
    forced to 0 by external devices.

This is IMHO related to the same problem.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Writing a book is like washing an elephant: there's no good place  to
begin  or  end,  and  it's  hard to keep track of what you've already
covered.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

       reply	other threads:[~2002-12-11 14:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <IGEFJKJNHJDCBKALBJLLAELKFIAA.joakim.tjernlund@lumentis.se>
2002-12-11 14:50 ` Wolfgang Denk [this message]
2002-12-11 14:54 ` PWM on the MPC850 Wolfgang Denk
2002-12-11 13:31 Donald MacArthur
2002-12-11 13:43 ` Wolfgang Denk

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=20021211145059.27DECC613A@atlas.denx.de \
    --to=wd@denx.de \
    --cc=joakim.tjernlund@lumentis.se \
    --cc=linuxppc-embedded@lists.linuxppc.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).