From patchwork Sat Mar 5 02:50:40 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Pierre-Louis Bossart X-Patchwork-Id: 8509111 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id F282BC0553 for ; Sat, 5 Mar 2016 02:54:21 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 93F9A20260 for ; Sat, 5 Mar 2016 02:54:20 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 2C1AE2024D for ; Sat, 5 Mar 2016 02:54:19 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7644D6E1E0; Sat, 5 Mar 2016 02:54:18 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTP id C74C86E1DE for ; Sat, 5 Mar 2016 02:54:14 +0000 (UTC) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP; 04 Mar 2016 18:54:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,538,1449561600"; d="scan'208";a="930040805" Received: from jmatilax-mobl2.amr.corp.intel.com (HELO pbossart-mobl2.amr.corp.intel.com) ([10.255.36.148]) by fmsmga002.fm.intel.com with ESMTP; 04 Mar 2016 18:54:13 -0800 From: Pierre-Louis Bossart To: intel-gfx@lists.freedesktop.org Date: Fri, 4 Mar 2016 20:50:40 -0600 Message-Id: <1457146252-4577-4-git-send-email-pierre-louis.bossart@linux.intel.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1457146252-4577-1-git-send-email-pierre-louis.bossart@linux.intel.com> References: <1457146252-4577-1-git-send-email-pierre-louis.bossart@linux.intel.com> MIME-Version: 1.0 Cc: mengdong.lin@linux.intel.com, tiwai@suse.de, liam.r.girdwood@linux.intel.com, vinod.koul@intel.com, broonie@kernel.org, rakesh.a.ughreja@intel.com Subject: [Intel-gfx] [RFC 03/15] Doc: sound: add description of Atom HDMI audio interface X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Used when HDaudio is not enabled Signed-off-by: Pierre-Louis Bossart --- Documentation/sound/alsa/Atom-hdmi-audio.txt | 241 +++++++++++++++++++++++++++ 1 file changed, 241 insertions(+) create mode 100644 Documentation/sound/alsa/Atom-hdmi-audio.txt diff --git a/Documentation/sound/alsa/Atom-hdmi-audio.txt b/Documentation/sound/alsa/Atom-hdmi-audio.txt new file mode 100644 index 0000000..bcc485c --- /dev/null +++ b/Documentation/sound/alsa/Atom-hdmi-audio.txt @@ -0,0 +1,241 @@ +This short blurb describes the support for HDMI audio on Atom +platforms with the DMA/register-based interface (non HDAudio). + +1.Overview + +The HDMI transmitter operates in an image-oriented fashion. The major +part of each frame is used by pixel data; non-pixel data is inserted +in the data islands in the vertical and horizontal blanking +spaces. Null packets are transmitted to fill the gaps when no data is +available. + +Non-pixel data is abstracted though the concept of ‘Data Island’ which +includes packet types such as + +- Audio Clock Regeneration. This packet conveys the information needed +for the receiver to reconstruct a valid audio clock; it is sent every +other frame. + +- Audio data (Audio Sample Packet, One Bit Audio Sample Packet, DST +Audio Packet, HBR Audio packet) + +- Audio InfoFrame. This packets conveys configuration information on +formats, sample rate, channel allocation, etc. + +2 Hardware description + +Although the HDMI block reuses many elements from the ‘normal’ +HDAudio-based design, the insertion of audio and configuration data +into the HDMI frame is done differently, spefically the data is +provided to the display controller with a DMA (instead of a serial +link) and the control interface is done through register access +(instead of HDAudio verbs). The interaction between audio and display +driver remains similar, e.g. to handle hot-plug or EDID information. + +2.1 Data flow + +The audio rate is derived from the video frame rate and software must +program the values of N/CTS registers. In some cases the audio clock is +approximated with an offset that remains within the acceptable bounds +of the standard. Based on N and CTS values and the actual video clock, +the transmitter determines how many audio sample packets need to be +inserted per frame. These packets are read from memory using a DMA +interface and inserted in the data island. In case the display format +or resolution changes the values for N and CTS need to be adjusted. + +2.2 Data formats + +The supported audio frequencies are 32, 44.1, 48, 88.2, 96, 176.4 and +192 kHz. 64 kHz is not supported in the HDMI standard. + +Two to eight channels can be transmitted. Odd number of channels will +required the insertion of an additional dummy channel. This insertion +is handled by software. + +Each transmitted PCM word is represented on 28 bits as described in +the IEC60958 standard. Each sample conveys 24 bits of audio data, +along with 4 configuration bits. + +Unsupported features: +One bit audio sample packet +DST audio packet +High Bit Rate packets + +2.3 DMA operation + +The HDMI audio DMA controller handles a single context. It supports a +four-entry descriptor register for source buffers and handles a single +destination. The address and size of the source buffers can be +programmed in the descriptors. + +The DMA controller transfers bursts of 16 32-bit words from memory (64 +bytes). These bursts are initiated when its FIFO level falls below a +programmable watermark threshold. It is required that the buffers are +aligned on a 64-byte boundary and are allocated from contiguous +physical memory. They also need to be multiples of 64 bytes. + +The DMA controller enables the addition of buffers in descriptor +registers during playback and issues an interrupt when a Transfer +Complete is reached. When it has finished playing a buffer, it will +move to the next descriptor. If no valid descriptors are found after a +complete loop on the 4 descriptors, the hardware will go to a wait +mode and report an under-run condition. As soon as the driver enables +a new transfer the hardware will wake up. Note: it is not possible to +program the DMA to fetch data completely autonomously without +interrupts, after the 4 descriptors are used they need to be +re-enabled by software. + +Should an underflow occur, the hardware can raise an underflow +interrupt, will not transmit any audio packets and will insert null +packets instead. On the software side, the audio device should be +closed and the application restarted from a known position. + +2.4 Data representation in RAM + +Linear or compressed data are represented in the 24 least significant +bits of a 32-bit word. No overlap between words is allowed. The +hardware assumes that the 32-bits are written in little-endian +format. Software needs to take care of format conversions when playing +16-bit PCM (shift-left by eight bits) + +Layout 0 is used for stereo data, with left and right channels +interleaved in memory. This layout is also used when transmitting +compressed data over HDMI in IEC format + +For multichannel, Layout 1 is used. The order of each channel is +defined as per CEA-861D. Since this order does not correspond to the +native order of any known decoder, the hardware provides a 3-bit +register for each channel. The channel position is modulo-added to the +register. This provides a direct means to change the channel +order. Note that the channel swap configuration needs to be aligned +with the CA code transmitted to the receiver. Alternatively the +channel swaps can be done in software. + +Only even number of channels will be transmitted. The software will +interleave a dummy channel if needed; the CA codec transmitted in +InfoFrames will only correspond to even number of channels. + +PCM Multichannel files will be stored in memory using the interleaved +mode (L0, R0, C0, LFE0, L1, R1, C1, LFE1). In Layout 1, the software +will need to generate 2, 4, 6 or 8 channels. By the same token, stereo +files will always provide a multiple of 4 samples to allow for the +same simplification for Layout 0. + +3. Configuration bits + +The U bit is not handled, as there is no real way to align the user +bits with the audio data. + +Only the first 40 bits of the channel status are meaningful. The HDMI +interface provides a two-word register which will be written with the +relevant values by software. For each block, the first 40 bits are +inserted one at a time in each frame, the remaining 152 bits are +zeroed. + +Note that the same C bit value is transmitted for each subframe of +each sub-packet. In theory, each channel could have independent C bits +and some of the information transmitted to the receiver may be +incorrect (channel number). To avoid any ambiguity for the receiver, +the source number and channel number will be set by the software to +zero, which is specified as ‘Do not take into account’ in IEC60958-3 + +For multichannel PCM transmitted using Layout1, the same C bit is +inserted in all valid subpackets. The same simplification is made by +zero-ing out source number and channel number by software. The V bit +is defined by a register as well. By default all samples are marked as +valid. The option of transmitting invalid samples is only meaningful +is there is a change in the type of data transmitted, or a change of +sampling rate. This is unlikely to occur as the audio transfers would +be stopped and restarted by the HDMI audio device driver. + +The parity bit is inserted by the hardware on-the-fly. The software is +not involved at all. + +4. Preambles + +Note that HDMI does not encode the 4-bit preamble, which instead is +replaced with a “B” bit (start-of-block) in each Audio Sample +packet. This preamble is added on-the-fly by the hardware. The +start-of-block bit is set for the first subpacket transmitted after +AUD_ENABLE is set. This B bit should always coincide with the start of +a DMA transfer. + +5. Programming model + +HDMI audio open: +A. reset the audio function in AUD_HDMI_STATUS register +B. Get the audio and video latencies, compute the relevant delay from +EDID information +C. write AUD_CONFIG register, except AudioEnable (sets User, Validity, +sample flat, block begin, number of channels, format, layout) +D. program ChannelStatus bits +E. unmask the relevant interrupts in PIPEBSTAT register +F. get frame rate from video driver +G. program N, CTS +H. program the FIFO threshold in AUD_BUF_CONFIG register +I. program the delay for lip-sync in AUD_BUF_CONFIG register +J. program channel swaps if need be +K. write Audio Infoframe in local memory (all the 28 bytes need to be +written, zero-out reserved bits/bytes) +L. signal location of Infoframe in AUD_CNTL_ST (how is frequency +transmitted) + +HDMI audio start: + +A. Inset a set of buffers in the circular list and mark them as +valid. Set interrupt flag on all or some buffers, choice left to the +user. +B. Enable the audio, which starts the DMA requests to fill the audio +FIFO immediately. The audio packets will actually be inserted in the +next video frame. There is no transmission before the next video +frame. + +HDMI audio pause: audio disable (continues transmitting packets until +the current video frame is complete) + +HDMI audio resume: audio enable (resumes at the next frame, pointers +kept, nothing lost) + +HDMI audio stop: +A. disable audio +B. reset audio module (Function Reset bit in HDMI audio status) + +The HDMI audio driver will need to communicate with the display +driver, so that the latter provides the following information: +- Display frame rate +- EDID +- HDCP failure + +The audio driver can keep track of playback progress by setting the +interrupt flag for each of the 4 buffers. Alternatively, for a finer +control and lower latency, the driver can read the buffer +AUD_BUF_X_LENGTH register, which is initialized by software with the +number of bytes to be transmitted and updated by hardware during DMA +reads. + +6. Known issues: + +HDMI receivers tend to ignore control (‘C’) bits and detect the +content type by parsing incoming data. As a result, receivers with +support for DolbyDigital, DTS, etc, tend to take around one or two +seconds to reliably lock on a set of sync words and avoid false +detections. When content is played on such receivers, the first +seconds of audio will not be heard. + +The only solution consists in playing dummy silent data as soon as the +HDMI cable is connected. This solution assumes that the system mixer +always uses the same configuration and does not change +sample-rates. In Baytrail and Cherrytrail the HDMI controller can keep +the audio link active by pushing zeroes as soon as DMA transfers are +complete. + +The hardware also provides a ‘stop’ bit to avoid waiting for the end +of a period elapsed to stop a playback. + +6. Differences with digital ouputs with HDaudio + +The channel status bits are programmed separately through a separate +register. Only 40 bits out of the 192 can be programmed +the parity is computed in hardware +the validity bit is inserted by hardware. +The ‘hdmi’ alsa-lib plugin cannot be used with this interface.