← Back to branch summary

~ubuntu-branches/ubuntu/precise/linux-ti-omap4/precise

« back to all changes in this revision

Viewing changes to drivers/tty/serial/pmac_zilog.c

  • Committer: Bazaar Package Importer
  • Author(s): Paolo Pisati
  • Date: 2011-06-29 15:23:51 UTC
  • mfrom: (26.1.1 natty-proposed)
  • Revision ID: james.westby@ubuntu.com-20110629152351-xs96tm303d95rpbk
Tags: 3.0.0-1200.2
* Rebased against 3.0.0-6.7
* BSP from TI based on 3.0.0

Show diffs side-by-side

added added

removed removed

Lines of Context:
drivers/tty/serial/pmac_zilog.c
1
1
/*
2
 
 * linux/drivers/serial/pmac_zilog.c
3
 
 * 
4
2
 * Driver for PowerMac Z85c30 based ESCC cell found in the
5
3
 * "macio" ASICs of various PowerMac models
6
4
 * 
330
328
                 * When that happens, I disable the receive side of the driver.
331
329
                 * Note that what I've been experiencing is a real irq loop where
332
330
                 * I'm getting flooded regardless of the actual port speed.
333
 
                 * Something stange is going on with the HW
 
331
                 * Something strange is going on with the HW
334
332
                 */
335
333
                if ((++loops) > 1000)
336
334
                        goto flood;
396
394
                 * be nice to transmit console writes just like we normally would for
397
395
                 * a TTY line. (ie. buffered and TX interrupt driven).  That is not
398
396
                 * easy because console writes cannot sleep.  One solution might be
399
 
                 * to poll on enough port->xmit space becomming free.  -DaveM
 
397
                 * to poll on enough port->xmit space becoming free.  -DaveM
400
398
                 */
401
399
                if (!(status & Tx_BUF_EMP))
402
400
                        return;
809
807
#endif /* !CONFIG_PPC_PMAC */
810
808
 
811
809
/*
812
 
 * FixZeroBug....Works around a bug in the SCC receving channel.
 
810
 * FixZeroBug....Works around a bug in the SCC receiving channel.
813
811
 * Inspired from Darwin code, 15 Sept. 2000  -DanM
814
812
 *
815
813
 * The following sequence prevents a problem that is seen with O'Hare ASICs