terasic_mtl(4) [freebsd man page]

TERASIC_MTL(4)						   BSD Kernel Interfaces Manual 					    TERASIC_MTL(4)

NAME

     terasic_mtl -- driver for the Terasic/Cambridge Multi-Touch LCD device

SYNOPSIS

     device terasic_mtl

     In /boot/device.hints:
     hint.terasic_mtl.0.at="nexus0"
     hint.terasic_mtl.0.reg_maddr=0x70400000
     hint.terasic_mtl.0.reg_msize=0x1000
     hint.terasic_mtl.0.pixel_maddr=0x70000000
     hint.terasic_mtl.0.pixel_msize=0x177000
     hint.terasic_mtl.0.text_maddr=0x70177000
     hint.terasic_mtl.0.text_msize=0x2000

DESCRIPTION

     The terasic_mtl device driver provides support for the Terasic Multi-Touch LCD combined as controlled by a University of Cambridge's IP Core.
     Three device nodes are instantiated, representing various services supported by the device:

     terasic_regX    Memory-mapped register interface, including touch screen input.

     terasic_pixelX  Memory-mapped pixel-oriented frame buffer.

     terasic_textX   Memory-mapped text-oriented frame buffer.

     terasic_mtl devices are also attached to the syscons(4) framework, which implements a VT-compatible terminal connected to the tty(4) frame-
     work.  ttyvX device nodes may be added to ttys(5) in order to launch login(1) sessions at boot.

     Register, text, and pixel devices may be accessed using read(2) and write(2) system calls, and also memory mapped using mmap(2).

SEE ALSO

     login(1), ioctl(2), mmap(2), poll(2), read(2), write(2), syscons(4), tty(4), ttys(5)

HISTORY

     The terasic_mtl device driver first appeared in FreeBSD 10.0.

AUTHORS

     The terasic_mtl device driver and this manual page were developed by SRI International and the University of Cambridge Computer Laboratory
     under DARPA/AFRL contract (FA8750-10-C-0237) (``CTSRD''), as part of the DARPA CRASH research programme.  This device driver was written by
     Robert N. M. Watson.

BUGS

     The syscons(4) attachment does not support the hardware cursor feature.

     A more structured interface to control registers using the ioctl(2) system call, would sometimes be preferable to memory mapping.	For touch
     screen input, it would be highly desirable to offer a streaming interface whose events can be managed using poll(2) and related system calls,
     with the kernel performing polling rather than the userspace application.

     terasic_mtl supports only a nexus bus attachment, which is appropriate for system-on-chip busses such as Altera's Avalon bus.  If the IP core
     is configured off of another bus type, then additional bus attachments will be required.

BSD
								  August 18, 2012							       BSD

GPIO(4) 						   BSD Kernel Interfaces Manual 						   GPIO(4)

NAME

     gpiobus -- GPIO bus system

SYNOPSIS

     To compile these devices into your kernel and use the device hints, place the following lines in your kernel configuration file:

	   device gpio
	   device gpioc
	   device gpioiic
	   device gpioled

     Additional device entries for the ARM architecture include:

	   device a10_gpio
	   device bcm_gpio
	   device imx51_gpio
	   device lpcgpio
	   device mv_gpio
	   device ti_gpio
	   device gpio_avila
	   device gpio_cambria
	   device zy7_gpio
	   device pxagpio

     Additional device entries for the MIPS architecture include:

	   device ar71xxx_gpio
	   device octeon_gpio
	   device rt305_gpio

     Additional device entries for the POWERPC architecture include:

	   device wiigpio
	   device macgpio

DESCRIPTION

     The gpiobus system provides a simple interface to the GPIO pins that are usually available on embedded architectures and can provide bit
     banging style devices to the system.

     The acronym GPIO means ``General-Purpose Input/Output.''

     The BUS physically consists of multiple pins that can be configured for input/output, IRQ delivery, SDA/SCL iicbus use, etc.

     On some embedded architectures (like MIPS), discovery of the bus and configuration of the pins is done via device.hints(5) in the platform's
     kernel config(5) file.

     On some others (like ARM), where FDT(4) is used to describe the device tree, the bus discovery is done via the DTS passed to the kernel,
     being either statically compiled in, or by a variety of ways where the boot loader (or Open Firmware enabled system) passes the DTS blob to
     the kernel at boot.

     The following device.hints(5) are only provided by the ar71xx_gpio driver:

     hint.gpio.%d.pinmask   This is a bitmask of pins on the GPIO board that we would like to expose for use to the host operating system.  To
			    expose pin 0, 4 and 7, use the bitmask of 10010001 converted to the hexadecimal value 0x0091.

     hint.gpio.%d.pinon     This is a bitmask of pins on the GPIO board that will be set to ON at host start.  To set pin 2, 5 and 13 to be set ON
			    at boot, use the bitmask of 10000000010010 converted to the hexadecimal value 0x2012.

     hint.gpio.function_set

     hint.gpio.function_clear
			    These are bitmasks of pins that will remap a pin to handle a specific function (USB, UART TX/RX, etc) in the Atheros
			    function registers.  This is mainly used to set/clear functions that we need when they are set up or not set up by
			    uBoot.

     Simply put, each pin of the GPIO interface is connected to an input/output of some device in a system.

SEE ALSO

     gpioiic(4), gpioled(4), iicbus(4), gpioctl(8)

HISTORY

     The gpiobus manual page first appeared in FreeBSD 10.0.

AUTHORS

     This manual page was written by Sean Bruno <sbruno@FreeBSD.org>.

BSD
								 November 5, 2013							       BSD