z8530book.tmpl

嵌入式系统设计与实例开发实验教材二源码 多线程应用程序设计 串行端口程序设计 AD接口实验 CAN总线通信实验 GPS通信实验 Linux内核移植与编译实验 IC卡读写实验 SD驱动使

  <para>
	The way most drivers approach this particular problem is to
	create a structure holding the Z8530 device definition and
	put that and the syncppp pointer into the private field of
	the network device. The network device fields of the channels
	then point back to the network devices. The ppp_device can also
	be put in the private structure conveniently.
  </para>
  <para>
	If you wish to use the synchronous ppp then you need to attach
	the syncppp layer to the network device. You should do this before
	you register the network device. The
	<function>sppp_attach</function> requires that the first void *
	pointer in your private data is pointing to an empty struct
	ppp_device. The function fills in the initial data for the
	ppp/hdlc layer.
  </para>
  <para>
	Before you register your network device you will also need to
	provide suitable handlers for most of the network device callbacks. 
	See the network device documentation for more details on this.
  </para>
  </chapter>

  <chapter>
 	<title>Configuring And Activating The Port</title>
  <para>
	The Z85230 driver provides helper functions and tables to load the
	port registers on the Z8530 chips. When programming the register
	settings for a channel be aware that the documentation recommends
	initialisation orders. Strange things happen when these are not
	followed. 
  </para>
  <para>
	<function>z8530_channel_load</function> takes an array of
	pairs of initialisation values in an array of u8 type. The first
	value is the Z8530 register number. Add 16 to indicate the alternate
	register bank on the later chips. The array is terminated by a 255.
  </para>
  <para>
	The driver provides a pair of public tables. The
	z8530_hdlc_kilostream table is for the UK 'Kilostream' service and
	also happens to cover most other end host configurations. The
	z8530_hdlc_kilostream_85230 table is the same configuration using
	the enhancements of the 85230 chip. The configuration loaded is
	standard NRZ encoded synchronous data with HDLC bitstuffing. All
	of the timing is taken from the other end of the link.
  </para>
  <para>
	When writing your own tables be aware that the driver internally
	tracks register values. It may need to reload values. You should
	therefore be sure to set registers 1-7, 9-11, 14 and 15 in all
	configurations. Where the register settings depend on DMA selection
	the driver will update the bits itself when you open or close.
	Loading a new table with the interface open is not recommended.
  </para>
  <para>
	There are three standard configurations supported by the core
	code. In PIO mode the interface is programmed up to use
	interrupt driven PIO. This places high demands on the host processor
	to avoid latency. The driver is written to take account of latency
	issues but it cannot avoid latencies caused by other drivers,
	notably IDE in PIO mode. Because the drivers allocate buffers you
	must also prevent MTU changes while the port is open.
  </para>
  <para>
	Once the port is open it will call the rx_function of each channel
	whenever a completed packet arrived. This is invoked from
	interrupt context and passes you the channel and a network	
	buffer (struct sk_buff) holding the data. The data includes
	the CRC bytes so most users will want to trim the last two
	bytes before processing the data. This function is very timing
	critical. When you wish to simply discard data the support
	code provides the function <function>z8530_null_rx</function>
	to discard the data.
  </para>
  <para>
	To active PIO mode sending and receiving the <function>
	z8530_sync_open</function> is called. This expects to be passed
	the network device and the channel. Typically this is called from
	your network device open callback. On a failure a non zero error
	status is returned. The <function>z8530_sync_close</function> 
	function shuts down a PIO channel. This must be done before the 
	channel is opened again	and before the driver shuts down 
	and unloads.
  </para>
  <para>
	The ideal mode of operation is dual channel DMA mode. Here the
	kernel driver will configure the board for DMA in both directions.
	The driver also handles ISA DMA issues such as controller
	programming and the memory range limit for you. This mode is
	activated by calling the <function>z8530_sync_dma_open</function>
	function. On failure a non zero error value is returned.
	Once this mode is activated it can be shut down by calling the
	<function>z8530_sync_dma_close</function>. You must call the close
	function matching the open mode you used.
  </para>
  <para>
	The final supported mode uses a single DMA channel to drive the
	transmit side. As the Z85C30 has a larger FIFO on the receive
	channel	this tends to increase the maximum speed a little. 
	This is activated by calling the <function>z8530_sync_txdma_open
	</function>. This returns a non zero error code on failure. The
	<function>z8530_sync_txdma_close</function> function closes down
	the Z8530 interface from this mode.
  </para>
  </chapter>

  <chapter>
 	<title>Network Layer Functions</title>
  <para>
	The Z8530 layer provides functions to queue packets for
	transmission. The driver internally buffers the frame currently
	being transmitted and one further frame (in order to keep back
	to back transmission running). Any further buffering is up to
	the caller.
  </para>
  <para>
	The function <function>z8530_queue_xmit</function> takes a network
	buffer in sk_buff format and queues it for transmission. The
	caller must provide the entire packet with the exception of the
	bitstuffing and CRC. This is normally done by the caller via
	the syncppp interface layer. It returns 0 if the buffer has been 
        queued and non zero values  for queue full. If the function accepts 
	the buffer it becomes property of the Z8530 layer and the caller 
	should not free it. 
  </para>
  <para>
	The function <function>z8530_get_stats</function> returns a pointer
	to an internally maintained per interface statistics block. This
	provides most of the interface code needed to implement the network
	layer get_stats callback.
  </para>
  </chapter>

  <chapter>
     <title>Porting The Z8530 Driver</title>
  <para>
	The Z8530 driver is written to be portable. In DMA mode it makes
	assumptions about the use of ISA DMA. These are probably warranted
	in most cases as the Z85230 in particular was designed to glue to PC
	type machines. The PIO mode makes no real assumptions.
  </para>
  <para>
	Should you need to retarget the Z8530 driver to another architecture
	the only code that should need changing are the port I/O functions.
	At the moment these assume PC I/O port accesses. This may not be
	appropriate for all platforms. Replacing 
	<function>z8530_read_port</function> and <function>z8530_write_port
	</function> is intended to be all that is required to port this
	driver layer.
  </para>
  </chapter>

  <chapter id="bugs">
     <title>Known Bugs And Assumptions</title>
  <para>
  <variablelist>
    <varlistentry><term>Interrupt Locking</term>
    <listitem>
    <para>
	The locking in the driver is done via the global cli/sti lock. This
	makes for relatively poor SMP performance. Switching this to use a
	per device spin lock would probably materially improve performance.
    </para>
    </listitem></varlistentry>

    <varlistentry><term>Occasional Failures</term>
    <listitem>
    <para>
	We have reports of occasional failures when run for very long
	periods of time and the driver starts to receive junk frames. At
	the moment the cause of this is not clear.
    </para>
    </listitem></varlistentry>
  </variablelist>
	
  </para>
  </chapter>

  <chapter id="pubfunctions">
     <title>Public Functions Provided</title>
!Edrivers/net/wan/z85230.c
  </chapter>

  <chapter id="intfunctions">
     <title>Internal Functions</title>
!Idrivers/net/wan/z85230.c
  </chapter>

</book>