linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Dan Malek <dan@netx4.com>
To: john zhan <r3587@sina.com>
Cc: hugh.mcdonald@nokia.com, linuxppc-embedded@lists.linuxppc.org
Subject: Re: SCC used for WAN connection
Date: Sat, 17 Jun 2000 13:14:49 -0400	[thread overview]
Message-ID: <394BB209.E711286D@embeddededge.com> (raw)
In-Reply-To: 023901bfd7f1$96254ba0$d0c809c0@p2kasvr


john zhan wrote:

> me too.  in fact,   also, I need generic x.25 running on it.

So, write it.


>
> >    What is needed is a new version of 8xx_io/uart.c that sets up and drives

No, what you want is an SCC synchronous driver. Period.  Don't put
stuff like this in the uart driver, it is a big enough mess the
way it is.  I am close to having a really configurable uart driver,
so you can select what SCC/SMCs you want.  The uart driver is a uart
driver, not an SCC driver.

We will probably have to create some other functions for managing the
baud rate generators, but for synchronous I/O that clock should be
provided externally.

> > other possible solutions....
> I think we can  work together .
> If you like,let's discuss it later , privately.

I would strongly suggest not going off and making a big mess, then
sending me a patch and hope it gets applied to the kernel sources.

I have done lots of synchronous SCC, HDLC, and other things as custom
proprietary drivers for many customers.  Typically, the driver does
very little, just buffers the data for mmap()'ed applications that
do the real work.  I will see if I can provide some framework from
past work I have done, but some of these folks are quite protective
of this.

These drivers are not hard to write, and you can use examples from
Motorola's NetComm site to get started.  You may need to do some
uncached memory buffering tricks in Linux or just use cache management
functions to ensure cache coherency.

Don't use old silicon, like before Rev. C 860.  Most of these functions
don't work as advertised on SCC3 and SCC4, only on SCC1 and SCC2.  Make
sure you pay close attention to the external hardware, as clock and
data transition edges are criticaly to this working correctly.


	-- Dan

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

  reply	other threads:[~2000-06-17 17:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-15 23:21 SCC used for WAN connection hugh.mcdonald
2000-06-14  3:24 ` john zhan
2000-06-17  0:16 ` john zhan
2000-06-17 17:14   ` Dan Malek [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-06-19  7:59 hugh.mcdonald
2000-05-29 15:51 Ruedi.Hofer

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=394BB209.E711286D@embeddededge.com \
    --to=dan@netx4.com \
    --cc=hugh.mcdonald@nokia.com \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    --cc=r3587@sina.com \
    /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).