parallel I/O ports & opend darin pins on MPC8xx

parallel I/O ports & opend darin pins on MPC8xx

[Stephan Linke]

Hi,

on one of our boards we are using one of the I/O pins in open drain mode. This leads to some problems in combination with other
drivers that write to the ports data register. Since they can not detect the current output value of the open drain pin. They only
see the status of the I/O pin no matter who forces the value the CPM or another device connected to the open drain pin. After
writing back the value read from the I/O data register this value is forced by CPM which is normaly wrong.

Did anyone run into that problem in the past? What was your solution? Any thing else but NOT using open drain pins?

Thanks, Stephan


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

Re: parallel I/O ports & opend darin pins on MPC8xx

[Craig Hollabaugh]

On Tue, 2003-07-08 at 09:31, Stephan Linke wrote:
> on one of our boards we are using one of the I/O pins in open drain mode. This leads to some problems in combination with other
> drivers that write to the ports data register. Since they can not detect the current output value of the open drain pin. They only
> see the status of the I/O pin no matter who forces the value the CPM or another device connected to the open drain pin. After
> writing back the value read from the I/O data register this value is forced by CPM which is normaly wrong.

Stephan,

What you are explaining, I beleive, is the reason why developers use
open drain in the first place. Multiple devices connected to control a
single signal giving bidirectional data flow.

>
> Did anyone run into that problem in the past? What was your solution? Any thing else but NOT using open drain pins?

Have you grepped the kernel source to find the other drivers affecting
that specific port control register? What did you look for and what did
you find?

Craig



>
--
------------------------------------------------------------
Dr. Craig Hollabaugh, craig@hollabaugh.com
Author of Embedded Linux: Hardware, Software and Interfacing
www.embeddedlinuxinterfacing.com


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

Re: parallel I/O ports & opend darin pins on MPC8xx

[Wolfgang Denk]

Dear Stephan,

in message <FCEAKDJJAPHPLJFINDAJOEFEDEAA.Stephan.Linke@epygi.de> you wrote:
>
> on one of our boards we are using one of the I/O pins in open drain mode. This leads to some problems in combination with other

Please don't use such long lines, they are hard to read.

> drivers that write to the ports data register. Since they can not detect the current output value of the open drain pin. They only
> see the status of the I/O pin no matter who forces the value the CPM or another device connected to the open drain pin. After
> writing back the value read from the I/O data register this value is forced by CPM which is normaly wrong.

This is a feature. It allows you to detect the the state of  the  pin
which can be pretty useful.

> Did anyone run into that problem in the past? What was your solution? Any thing else but NOT using open drain pins?

It is _not_ a problem, it is a feature, and a useful one.

Solution? What is so difficult about latching your output value in  a
variable?


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
It is practically impossible to teach good programming style to  stu-
dents that have had prior exposure to BASIC: as potential programmers
they are mentally mutilated beyond hope of regeneration.   - Dijkstra

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

Re: parallel I/O ports & opend darin pins on MPC8xx

[None Atall]

 I hope it is not a Hardware problem. Do you
need an external pullup? If you do not have one,
then the problem arises (had the same problem once).
Except if one of your peripherals actively drives
your input....

                       Cheers
                            Dimitris.

--- Stephan Linke <Stephan.Linke@epygi.de> wrote:
>
> Hi,
>
> on one of our boards we are using one of the I/O
> pins in open drain mode. This leads to some problems
> in combination with other
> drivers that write to the ports data register. Since
> they can not detect the current output value of the
> open drain pin. They only
> see the status of the I/O pin no matter who forces
> the value the CPM or another device connected to the
> open drain pin. After
> writing back the value read from the I/O data
> register this value is forced by CPM which is
> normaly wrong.
>
> Did anyone run into that problem in the past? What
> was your solution? Any thing else but NOT using open
> drain pins?
>
> Thanks, Stephan
>
>
>


=====
------------------------------------------------------------
-Dhmhtrios Meidanis
-Degree in Mathematics, University of the Aegean.
-Master in Computer Architecture and Digital
 Systems, University of Crete.
 Greece.
------------------------------------------------------------


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

Re: parallel I/O ports & opend darin pins on MPC8xx

[Wolfgang Denk]

Dear Stephan,

in message <FCEAKDJJAPHPLJFINDAJCEGCDEAA.Stephan.Linke@epygi.de> you wrote:
>
> There are two drivers, both are manualy manipulating bits at the same I/O port.
> Both drivers use the following mechanism to change the value of their pin: they
> read the value from the data register changeing the value and writing the result
> back to the data register (hopefully an atomic access). This works fine since
> for normal output pins you can read the output value and for input pins it's a
> don't care. As soon as one of the drivers use open drain pins something changes.

You must define for your driver(s) what they shall do, and  implement
it that way.

> You can't read the output value any more sou you are starting to drive the
> output pin of the other driver with the input value. Which can be a verry bad
> idea.

Wrong.

Correct is:  You  cannot  read  the  output  value  from  the  _data_
register,  because external logic might drive a the level low even if
your output bit says "high".

Note 1: There is nothing  that  prevents  you  from  using  a  simple
        integer  variable  to latch the value you write to the output
        port. This is so simple that I'm really surprised you did not
        come up with this solution yourself. And  of  course  such  a
        "buffer" can be shared between several drivers, too.

Note 2: Actually I don't think _anything_  changes  between  actively
        driven output and open drain. I think the value you read from
        the  inputs will ALWAYS reflect the actual value at the pins.
        You may want to test what happens when you configure  a  port
        as  actively  driven  output, write a 1 bit to it, ground the
        output pin, and then read back the data  register.  I  bet  a
        case of beer that you will read a 0 bit.

	And no, I will not pay for the CPU you just fried.


> That's why I aggree open drain I/O's are a good feature but in detail they are
> difficult to deal with. The only solution I came up with was a non atomic access
> to data and open drain register and I don't what to block IRQ changing a single
> pin in let's say the I2C driver. So our current solution is to make the
> suspicious pin an input (preventing 10BT from being switched from half to full
> duplex).

??? I must be missing something. I wouldn't  think  such  complicated
stuff is necessary here at all.


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
A mouse is an elephant built by the Japanese.

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

Re: parallel I/O ports & opend darin pins on MPC8xx

[Wolfgang Denk]

Dear Stephan,

in message <FCEAKDJJAPHPLJFINDAJEEGGDEAA.Stephan.Linke@epygi.de> you wrote:
>
> So a verry simple question remains:
>
> If it's so easy, why isn't all that already done in the existing
> drivers that are manipulating single I/O pins like 8xx_io/enet.c drivers/i2c/i2c-algo-8xx_soft.c? Since they are the candidates

I think the answer is simply that nobody needed it yet  so  it  never
caused problems?

Open drain outputs are very ralrey used after all. On all the  boards
we had in the lab there was only one which happened to use OD outputs
- and this just to drive a LED display, where actively driven outputs
worked as well.

[And actually in this case the OD outputs did  cause  problems,  too:
the  customer  implemented some code which would set a state and read
it back immediately, which did not work. It turned out  the  the  CPU
was faster than the raising time of the signal.]

> for such trouble if someone uses these drivers and has an additional
> open drain pin on one of his ports...
>
> And I thought we should be talking about a general solution, not only
> about how I can fix my little problem.

I'm afraid I'm not in the position to change anything.

There are several  isssues  with  using  port  pins,  like  the  chip
internal  race condition when using PWM outputs. I don't think that a
good general  solution  for  all  these  issues  is  available.  Your
configuration  is  pretty  rare,  so it is probably handled best as a
special case, outside the general code. -- YMMV.



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
"Everything should be made as simple as possible, but not simpler."
                                                    - Albert Einstein

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

Re: parallel I/O ports & opend darin pins on MPC8xx

[Wolfgang Denk]

In message <3F0C6C0C.8040306@earthlink.net> you wrote:
>
> >Solution? What is so difficult about latching your output value in  a
> >variable?
> >
> What he's saying is that OTHER drivers read the input and then write
> that value to the output.

I did understand this.

> In his driver, he can latch the output through a variable, but that
> won't affect what other

Obviously all drivers that may modify bits in this I/O port will have
to share the variable used to latch the value.

Yes, this may include modifying existing code in the UART or Ethernet
or other drivers.

> Unless there is kernel support to alias the data in a memory variable
> (and it doesn't sound like
> there is), then this is going to continue to be a problem.  Might I

Don't make it unnecessary complicated. You don't need "kernel support
to alias the data in a  memory  variable".  This  is  really  not  so
difficult to implement yourself when you need it.


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
The so-called "desktop metaphor" of today's workstations  is  instead
an  "airplane-seat"  metaphor.  Anyone who has shuffled a lap full of
papers while seated between two portly passengers will recognize  the
difference -- one can see only a very few things at once.
                                                   - Fred Brooks, Jr.

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

Re: parallel I/O ports & opend darin pins on MPC8xx

[Wolfgang Denk]

In message <3F0C7782.3060704@earthlink.net> you wrote:
>
> But I still don't see how you could avoid having other drivers clobber
> your output but.  I think he has to take one of the two options I

By modifying _all_ drivers that will modify the port in question in a
way that is based on previously read data.

> suggested.  Adding his own variable can't help in any way I can
> imagine.  Could you give an example?

Find out which port pin(s) is/are  configured  as  OD  output.  Check
which  other port pins on this port are in use, and which drivers are
using these port pins. Make all these drivers  use  a  common  buffer
variable. Voila...


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
If a packet hits a pocket on a socket on a port,
And the bus is interrupted as a very last resort,
And the address of the memory makes your floppy disk abort,
Then the socket packet pocket has an error to report! - Ken Burchill?

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

Re: parallel I/O ports & opend darin pins on MPC8xx

[Dean Matsen]

Dean Matsen wrote:

>
> Wolfgang Denk wrote:
>
>> In message <3F0C6C0C.8040306@earthlink.net> you wrote:
>>
>>
>>>> Solution? What is so difficult about latching your output value in a
>>>> variable?
>>>>
>>>>
>>>>
>>> What he's saying is that OTHER drivers read the input and then write
>>> that value to the output.
>>>
>>>
>>
>> I did understand this.
>>
>>
>>
>>> In his driver, he can latch the output through a variable, but that
>>> won't affect what other
>>>
>>>
>>
>> Obviously all drivers that may modify bits in this I/O port will have
>> to share the variable used to latch the value.
>>
>> Yes, this may include modifying existing code in the UART or Ethernet
>> or other drivers.
>>
>>
>>
>>> Unless there is kernel support to alias the data in a memory variable
>>> (and it doesn't sound like
>>> there is), then this is going to continue to be a problem. Might I
>>>
>>>
>>
>> Don't make it unnecessary complicated. You don't need "kernel support
>> to alias the data in a memory variable". This is really not so
>> difficult to implement yourself when you need it.
>>
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
>>
>>
> No no, I wasn't suggesting that it be added, I was (subtly) pointing out
> that it is not likely to be added because you'd have to review every
> other driver in the PPC system. Not gonna happen.
>
> But I still don't see how you could avoid having other drivers clobber
> your output but. I think he has to take one of the two options I
> suggested. Adding his own variable can't help in any way I can
> imagine. Could you give an example?
>
> Dean
>
>
>
>
Ooops, NM on the example -- I didn't read carefully enough. Yes,
updating the
other drivers would work too, but then he's got to maintain a ton of patches
for his version of the kernel.

Dean


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