Jay Cheng [Thu, 19 Aug 2010 11:09:49 +0000 (07:09 -0400)]
serial: tegra_hsuart: fix receive DMA, RTS, timeout, and tx trigger
initialize baud rate and configuration settings to safe default values
when receive DMA is in use, so that the DMA request may be enqueued at
initialization time
re-enqueue the receive DMA buffer immediately it is dequeued by the
DMA threshold callback and the receive ISR, rather than waiting for the
DMA complete callback
originally fixed by Gary King <gking@nvidia.com>
Fixing tx trigger level setting:
On tegra uart, the FCR setting for different tx trigger level
is not same as the 16550 tx trigger level setting. The tegra
uart have the setting in reverse direction on tx fifo attention
level:
b00 for 16 bytes attention level.
b01 for 8 byte attention level.
b10 for 4 byte attention level
b11 for 1 byte attention level.
The rx trigger attention level match with the standard uart
FCR register setttings.
Also fixing the typo in code when setting DTR.
originally fixed by Laxman Dewangan (ldewangan@nvidia.com)
Change-Id: Iea00478f143e61c604828035c6c92d614fa7cccb Signed-off-by: Jay Cheng <jacheng@nvidia.com>
Colin Cross [Fri, 4 Jun 2010 17:56:50 +0000 (10:56 -0700)]
serial: tegra_hsuart: Cleanups and bug fixes
tegra_start_tx was called directly by the serial core, as
well as from dma and serial interrupts to queue the next
block of data. Separate out the "queue next data"
functionality into tegra_start_next_tx.
Also fixes TX PIO by adjusting FIFO sizes and prevents
last characters from getting lost by spinning on TEMT
before disabling clocks.
Change-Id: If8ce15490f77dcbde48f1e64959d5c3f0ec35120 Signed-off-by: Colin Cross <ccross@android.com>
Erik Gilling [Tue, 24 Aug 2010 04:58:20 +0000 (21:58 -0700)]
video: tegra: add skeleton host bus support
The host (or host1x) bus sits between the cpu core and the 3d, 2d, camera,
display, and mpeg encoder functions. It contains provides DMA channels,
hardware mutexes, and synchronization points.
Iliyan Malchev [Fri, 20 Aug 2010 22:11:48 +0000 (15:11 -0700)]
[ARM] tegra: tegra_i2s_audio: allow preloading of the tx fifo with data
Add an ioctl to allow the TX fifo to be loaded with data before playback
starts. Playback can then be started by calling write() on the FIFO, even
with a length of 0. This will cause the pending data to be played out.
Iliyan Malchev [Wed, 18 Aug 2010 01:36:41 +0000 (18:36 -0700)]
[ARM] tegra: tegra_i2s_audio: clean up handling of state
-- Use consistently the various state flags:
-- active is set only when there is a read or write in flight
-- recording_canncelled is set only when recording is stopped via the ioctl()
-- dma_has_it is used to determine whether DMA is already in flight; do not
use the state of the fifos for this (e.g., if the TX fifo is empty, do not
assume that playback is stopped)
-- added a stop_completion (implemented for readers only) so that readers
closing a stream can wait until DMA or PIO transactions are stopped
-- Split /dev/audio0_{in,out} into /dev/audio0_{in,in_ctl,out,out_ctl} where the
_ctl versions have the ioctl()s
-- Introduced an error count per audio_stream; error count is reset on open, can
be read back & reset through an ioctl
Iliyan Malchev [Tue, 17 Aug 2010 18:34:39 +0000 (11:34 -0700)]
[ARM] tegra: tegra_i2s_audio: configure in/out buffer sizes from user space
-- Add ioctls for configuring buffer, threshold, and DMA-transaction sizes from
user space.
-- Buffer sizes are provided in orders of magnitude.
-- Allocate max-sized buffers during probe, and allow the user to resize them
only within the original allocation, to avoid the risk from kmalloc failing
due to kernel-heap fragmentation, and also to avoid race conditions on DMA
shut-down.
-- In tegra_audio_write(), moved the call to start_playback_if_necessary()
immediately after writing to the fifo. Otherwise, when the fifo size is
smaller than what the user is trying to write, the user will block before
playback is started.
-- Silenced printk spew on spinning on i2s registers after transactions are
completed.
-- Cleaned up a 80-col style violation in downsample()
Iliyan Malchev [Thu, 12 Aug 2010 01:19:47 +0000 (18:19 -0700)]
[ARM] tegra_i2s_audio: add software downsampling for recorded data + fixes
downsampling:
-- add ioctl()s to downsample recorded data
-- supported frequencies are 8kHz, 11.025kHz, 22.05kHz, and 44.1kHz
-- downsamping to stereo and mono
-- default is 11.025kHz mono
fixes:
-- fix crashes from dequeuing DMA requests twice
Iliyan Malchev [Fri, 6 Aug 2010 22:41:26 +0000 (15:41 -0700)]
[ARM] tegra: audio_i2s_audio: clean up & support for recording audio
-- add audio_in_stream (identical to audio_out_stream, may merge them later)
-- add support for DMA and PIO recording
-- add ioctls for /dev/audio<n>_in to start and stop recording
Erik Gilling [Mon, 12 Jul 2010 00:06:28 +0000 (17:06 -0700)]
video: tegra: add tegra display controller driver
Notable ommisions:
* support for anything but lvds panels
* inegration with nvhost driver to sync updates with 3D
* FB physical geometry is not set
* lacks interface to set overlay/window x,y offset
v2 changes:
* suspend/resume support
* move code into drivers/video/tegra/dc
* modularize output support
* clean register dumping, add debugfs register file
* code review feedback
* make the display controller register the framebuffer devices
[ARM] tegra: generic driver for i2s audio (initial implementation)
-- i2s settings are passed through the board file
-- supports playback (no recording yet)
-- works in DMA and PIO (non-DMA) modes (toggle through debugfs)
-- does NOT perform volume and audio-path control
-- exports /dev/audio<n>_{in, out}, where <n> is the i2s interface
-- assumes that i2s is used such that fifo1 is TX and fifo2 is RX
The Tegra IOVMM is an interface to allow device drivers and subsystems in
the kernel to manage the virtual memory spaces visible to I/O devices.
The interface has been designed to be scalable to allow for I/O virtual
memory hardware which exists in one or more limited apertures of the address
space (e.g., a small aperture in physical address space which can perform
MMU-like remapping) up to complete virtual addressing with multiple
address spaces and memory protection.
The interface has been designed to be similar to the Linux virtual memory
system; however, operations which would be difficult to implement or
nonsensical for DMA devices (e.g., copy-on-write) are not present, and
APIs have been added to allow for management of multiple simultaneous
active address spaces.
The API is broken into four principal objects: areas, clients, domains and
devices.
Areas
=====
An area is a contiguous region of the virtual address space which can be
filled with virtual-to-physical translations (and, optionally, protection
attributes). The virtual address of the area can be queried and used for
DMA operations by the client which created it.
As with the Linux vm_area structures, it is the responsibility of whichever
code creates an area to ensure that it is populated with appropriate
translations.
Domains
=======
A domain in the IOVMM system is similar to a process in a standard CPU
virtual memory system; it represents the entire range of virtual addresses
which may be allocated and used for translation. Depending on hardware
capabilities, one or more domains may be resident and available for
translation. IOVMM areas are allocated from IOVMM domains.
Whenever a DMA operation is performed to or from an IOVMM area, its parent
domain must be made resident prior to commencing the operation.
Clients
=======
I/O VMM clients represent any entity which needs to be able to allocate
and map system memory into I/O virtual space. Clients are created by name
and may be created as part of a "share group," where all clients created
in the same share group will observe the same I/O virtual space (i.e., all
will use the same IOVMM domain). This is similar to threads inside a process
in the CPU virtual memory manager.
The callers of the I/O VMM system are responsible for deciding on the
granularity of client creation and share group definition; depending on the
specific usage model expected by the caller, it may be appropriate to create
an IOVMM client per task (if the caller represents an ioctl'able interface
to user land), an IOVMM client per driver instance, a common IOVMM client
for an entire bus, or a global IOVMM client for an OS subsystem (e.g., the DMA
mapping interface).
Each client is responsible for ensuring that its IOVMM client's translation is
resident on the system prior to performing DMA operations using the IOVMM
addresses. This is accomplished by preceding all DMA operations for the client
with a call to tegra_iovmm_client_lock (or tegra_iovmm_client_trylock),
and following all operations (once complete) with a call to
tegra_iovmm_client_unlock. In this regard, clients are cooperatively context-
switched, and are expected to behave appropriately.
Devices
=======
I/O VMM devices are the physical hardware which is responsible for performing
the I/O virtual-to-physical translation.
Devices are responsible for domain management: the mapping and unmapping
operations needed to make translations resident in the domain (including
any TLB shootdown or cache invalidation needed to ensure coherency), locking
and unlocking domains as they are made resident by clients into the devices'
address space(s), and allocating and deallocating the domain objects.
Devices are responsible for the allocation and deallocation of domains to
allow coalescing of multiple client share groups into a single domain. For
example, if the device's hardware only allows a single address space to
be translated system-wide, performing full flushes and invalidates of the
translation at every client switch may be prohibitively expensive. In these
circumstances, a legal implementation of the IOVMM interface includes
returning the same domain for all clients on the system (regardless of
the originally-specified share group).
In this respect, a client can be assured that it will share an address space
with all of the other clients in its share group; however, it may also share
this address space with other clients, too.
Multiple devices may be present in a system; a device should return a NULL
domain if it is incapable of servicing the client when it is asked to
allocate a domain.
tegra_iovmm_alloc_client - Called to create a new IOVMM client object; the
implementation may create a new domain or return an existing one depending on
both the device and the share group.
tegra_iovmm_free_client - Frees a client.
tegra_iovmm_client_lock - Makes a client's translations resident in the IOVMM
device for subsequent DMA operations. May block if the device is incapable
of context-switching the client when it is called. Returns -EINTR if the
waiting thread is interrupted before the client is locked.
tegra_iovmm_client_trylock - Non-blocking version of tegra_iovmm_client_lock
tegra_iovmm_client_unlock - Called by clients after DMA operations on IOVMM-
translated addresses is complete; allows IOVMM system to context-switch the
current client out of the device if needed.
tegra_iovmm_create_vm - Called to allocate an IOVMM area. If
lazy / demand-loading of pages is desired, clients should supply a pointer
to a tegra_iovmm_area_ops structure providing callback functions to load, pin
and unpin the physical pages which will be mapped into this IOVMM region.
tegra_iovmm_get_vm_size - Called to query the total size of an IOVMM client
tegra_iovmm_free_vm - Called to free a IOVMM area, releasing any pinned
physical pages mapped by it and to decommit any resources (memory for
PTEs / PDEs) required by the VM area.
tegra_iovmm_vm_insert_pfn - Called to insert an exact pfn (system memory
physical page) into the area at a specific virtual address. Illegal to call
if the IOVMM area was originally created with lazy / demand-loading.
tegra_iovmm_zap_vm - Called to mark all mappings in the IOVMM area as
invalid / no-access, but continues to consume the I/O virtual address space.
For lazy / demand-loaded IOVMM areas, a zapped region will not be reloaded
until it has been unzapped; DMA operations using the affected translations
may fault (if supported by the device).
tegra_iovmm_unzap_vm - Called to re-enable lazy / demand-loading of pages
for a previously-zapped IOVMM area.
tegra_iovmm_find_area_get - Called to find the IOVMM area object
corresponding to the specified I/O virtual address, or NULL if the address
is not allocated in the client's address space. Increases the reference count
on the IOVMM area object
tegra_iovmm_area_get - Called to increase the reference count on the IOVMM
area object
tegra_iovmm_area_put - Called to decrease the reference count on the IOVMM
area object
IOVMM Device API
================
tegra_iovmm_register - Called to register a new IOVMM device with the IOVMM
manager
tegra_iovmm_unregister - Called to remove an IOVMM device from the IOVMM
manager (unspecified behavior if called while a translation is active and / or
in-use)
tegra_iovmm_domain_init - Called to initialize all of the IOVMM manager's
data structures (block trees, etc.) after allocating a new domain
IOVMM Device HAL
================
map - Called to inform the device about a new lazy-mapped IOVMM area. Devices
may load the entire VM area when this is called, or at any time prior to
the completion of the first read or write operation using the translation.
unmap - Called to zap or to decommit translations
map_pfn - Called to insert a specific virtual-to-physical translation in the
IOVMM area
lock_domain - Called to make a domain resident; should return 0 if the
domain was successfully context-switched, non-zero if the operation can
not be completed (e.g., all available simultaneous hardware translations are
locked). If the device can guarantee that every domain it allocates is
always usable, this function may be NULL.
unlock_domain - Releases a domain from residency, allows the hardware
translation to be used by other domains.
alloc_domain - Called to allocate a new domain; allowed to return an
existing domain
free_domain - Called to free a domain.
Change-Id: Ic65788777b7aba50ee323fe16fd553ce66c4b87c Signed-off-by: Gary King <gking@nvidia.com>
Gary King [Mon, 28 Jun 2010 22:00:10 +0000 (15:00 -0700)]
mtd/tegra_nand: don't ignore return value for add_mtd_partitions
when the mtd partition command line format is used, ignoring the
return value left err set to the number of partitions, which was
later interpreted as an error return code for tegra_nand_probe,
which caused the MTD master to be unregistered (ultimately causing
NULL pointer derefs when mounting the root partition).
Change-Id: Icebfb295810554617c56deeafc91bc22cc43bb35 Signed-off-by: Gary King <gking@nvidia.com>
Gary King [Wed, 14 Jul 2010 01:56:40 +0000 (18:56 -0700)]
i2c-tegra: add support for virtual busses with dynamic pinmuxing
this adds support for dynamically reprogramming the I2C controller's
pin mux on transaction boundaries to enable one controller to be
registered as multiple I2C bus adapters with the kernel. this allows
platform designers an additional tool to resolve clock rate, I/O
voltage and electrical loading restrictions between the platform's
peripherals.
the i2c-tegra platform data is extended to support this; platforms
which use this feature should pass in the number of busses which
should be created for each controller, the starting adapter number
to use and the clock rate and pin mux for each virtual bus.
Change-Id: I57a96deb7b7b793222ec3f8cc3a941917a023609 Signed-off-by: Gary King <gking@nvidia.com>
Colin Cross [Sun, 3 Apr 2011 07:57:28 +0000 (00:57 -0700)]
ARM: tegra: add hotplug support
Hotplug uses the same CPU wfi code as cpuidle to put either cpu
into a slightly lower power mode (clock gated, but still powered).
If the remaining cpu enters LP2, the hotplugged cpu will be power
gated until the remaining cpu is active.
Change-Id: Ib7428709043415dc759136cf91668f6f63fe5a5c Signed-off-by: Colin Cross <ccross@android.com>
Colin Cross [Mon, 29 Nov 2010 07:59:30 +0000 (23:59 -0800)]
ARM: tegra: add cpuidle driver
Supports clock-gated (LP3) SMP idle mode, and power-gated (LP2) idle.
Latency for LP2 idle state is calculated as a 2-sample weighted moving
average, to allow for variations due to CPU frequency scaling.
LP3 idle gates a single CPU core, but LP2 requires power gating both
CPU cores. When the first CPU requests to enter LP2, it saves its
own state and then enters WFI. When the second CPU requests LP2,
it attempts to put the first CPU into reset to prevent it from waking
up, with some synchronization in case it was already awake, and then
powers down both CPUs together.
Change-Id: I1dc2a7fb9b3bff524952d0cbf3c322a7b9a38be9 Signed-off-by: Colin Cross <ccross@android.com>
Colin Cross [Mon, 29 Nov 2010 06:36:08 +0000 (22:36 -0800)]
ARM: tegra: Add suspend support
Tegra supports three low power modes that involve powering down the CPU.
LP2 powers down both CPU cores and the GICs, but leaves the core
peripherals, including the memory controller and the legacy
interrupt controller, enabled. The legacy interrupt controller
is used as the wakeup source, and any interrupt can wake the device.
LP2 can be used in idle.
LP1 is the same as LP2, but in addition turns off the memory
controller and puts the DDR memory in self-refresh. Any interrupt
can wake the device. LP1 could be used in idle if no peripherals
are doing DMA.
LP0 turns off everything in the SoC except the RTC and a power
management controller, both of which run off a 32 kHz clock.
The power management controller has 32 wake sources, all other
interrupts can not be used to wake from LP0.
These low power modes power-gate the main CPU complex, requiring a
full processor state save and restore from a reset vector.
Platform-specific data (power good times, PMU capabilities, etc.) must be
specified when registering the suspend operations to ensure that platform
power sequencing restrictions are maintained.
In both LP0 and LP1, SDRAM is placed into self-refresh. in order to safely
perform this transition, the final shutdown procedure responsible for
* turning off the MMU and L1 data cache
* putting memory into self-refresh
* setting the DDR pads to the lowest power state
* and turning off PLLs
is copied into IRAM (at the address TEGRA_IRAM_BASE + SZ_4K) at the
start of the suspend process.
In LP1 mode (like LP2), the CPU is reset and executes the code specified
at the EVP reset vector. Since SDRAM is in self-refresh, this code must
also be located in IRAM, and it must re-enable DRAM before restoring the
full context. In this implementation, it enables the CPU on PLLP, enables
PLLC and PLLM, restores the SCLK burst policy, and jumps to the LP2 reset
vector to restore the rest of the system (MMU, PLLX, coresite, etc.). The
LP2 reset vector is expected to be found in PMC_SCRATCH1, and is
initialized during system-bootup.
In LP0 mode, the core voltage domain is also shutoff. As a result, all
of the volatile state in the core voltage domain (e.g., pinmux registers,
clock registers, etc.) must be saved to memory so that it can be restored
after the system resumes. A limited set of wakeups are available from LP0,
and the correct levels for the wakeups must be programmed into the PMC
wakepad configuration register prior to system shutdown. On resume, the
system resets into the boot ROM, and the boot ROM restores SDRAM and other
system state using values saved during kernel initialization in the PMC
scratch registers.
Resuming from LP0 requires the boot ROM to supply a signed recovery codeblob
to the kernel; the kernel expects that the length and address of this blob
is supplied with the lp0_vec= command line argument; if not present, suspend-
to-LP0 will be disabled
For simplicity, the outer cache is shutdown for both LP0 and LP1; it
is possible to optimize the LP1 routine to bypass outer cache shutdown
and restart.
Includes fixes from:
Scott Williams <scwilliams@nvidia.com>
Aleksandr Frid <afrid@nvidia.com>
Vik Kasivajhula <tkasivajhula@nvidia.com>
Bharat Nihalani <Kbnihalani@nvidia.com>
James Wylder <james.wylder@motorola.com>
Allen Martin <amartin@nvidia.com>
Change-Id: I9e4e61c2fbb8c7bb5a29b1832ea38e7ea0524c52
Original-author: Gary King <gking@nvidia.com> Signed-off-by: Gary King <gking@nvidia.com> Signed-off-by: Colin Cross <ccross@android.com>