Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp518812pxk; Sun, 30 Aug 2020 12:18:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw1fZQzJghP449b03eHnfBu+nT1UX3EFOAi/Jmlqexk2aMu2FSZSRKj/S3DUGD/p/y59hEo X-Received: by 2002:a17:906:7b83:: with SMTP id s3mr8817843ejo.2.1598815083543; Sun, 30 Aug 2020 12:18:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598815083; cv=none; d=google.com; s=arc-20160816; b=rt2p/uc0Y9kACcPAgwFDV6eDfrfnQG3Bs+YhU+21W6N9DoS/i08EEOIxK3ld+b542s xrKp0omWKWDcoxMRNRR7OOK5UsDFqubaCn0Xi9a1v7XJFRt15jUUwfSRbizIBRL2kZx1 bUzoe94169D4/taVDk2+eGcky1bPXuc9jaJVLo+MKj7L9XZu8mkpSvR4beei/IRreauk UsLCUZKc0rz8v5Yc85lwnAt57i50/gClINaWrsunFKo0P8yiIxB6w1hx2247wpPU65JY iWH6Np3POI6yDoaW/k7dRGdrhY30blD2eQ1JHOIhUO7mhnkX9+yMw9LvoW8uD9YVKqVu 22Pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=HIscXfqwphHtgOHyD4lmg5cnd+LVllqlIPQCEgpQMXw=; b=snH2tdJTstKtA1IZ9/SDYeeupKiHjCmTZZEE+mIZ2TWl9ujYjZ5fpZLMXYXaLPQFcs jc5uWdPE1o2YcYcG0Axi8xGp/lGcZcYPrALgolHmZUQXLPGXsTJ3qNghPbg5MyRvUXHi sRLsrm1xo89QcI27NTfjMHodQVbeq7YK9AnSEDAikDHpWDEj6wkyQ3T2zeJMzM4KwKu4 PpxJ4pMQ5RsffFnWMfqF98QHTxDLh1YYLhskdcxLgbi0Jp+pUEHy92zVQucszb/ruCy9 LBvDMkFWixtKNVgPMtc0VlPWmoHppctRRlcxvWitwfYkzL2pHp1gvqV+0gELwZtM+T4z esNw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u1si3780545edv.460.2020.08.30.12.17.40; Sun, 30 Aug 2020 12:18:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727818AbgH3TRE (ORCPT + 99 others); Sun, 30 Aug 2020 15:17:04 -0400 Received: from gloria.sntech.de ([185.11.138.130]:47812 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727078AbgH3TQt (ORCPT ); Sun, 30 Aug 2020 15:16:49 -0400 Received: from p508fca7b.dip0.t-ipconnect.de ([80.143.202.123] helo=phil.localnet) by gloria.sntech.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kCSop-00028U-Vw; Sun, 30 Aug 2020 21:16:48 +0200 From: Heiko Stuebner To: Katsuhiro Suzuki Cc: linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Katsuhiro Suzuki Subject: Re: [PATCH v2] arm64: dts: rockchip: enable HDMI sound nodes for rk3328-rock64 Date: Sun, 30 Aug 2020 21:16:47 +0200 Message-ID: <7880329.2VsnZ9RgxX@phil> In-Reply-To: <20200802154231.2639186-1-katsuhiro@katsuster.net> References: <20200802154231.2639186-1-katsuhiro@katsuster.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Am Sonntag, 2. August 2020, 17:42:31 CEST schrieb Katsuhiro Suzuki: > This patch enables HDMI sound (I2S0) and Analog sound (I2S1) which > are defined in rk3328.dtsi, and replace SPDIF nodes. > > We can use SPDIF pass-through with suitable ALSA settings and on > mpv or other media players. > - Settings: https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Rockchip/filesystem/usr/share/alsa/cards/SPDIF.conf > - Ex.: mpv foo.ac3 --audio-spdif=ac3 --audio-device='alsa/SPDIF.pcm.iec958.0:SPDIF' > > [Why use simple-audio-card for SPDIF?] > > For newly adding nodes, ASoC guys recommend to use audio-graph-card. > But all other sound nodes for rk3328 have already been defined by > simple-audio-card. In this time, I chose for consistent sound nodes. > > [DMA allocation problem] > > After this patch is applied, UART2 will fail to allocate DMA resources > but UART driver can work fine without DMA. > > This error is related to the DMAC of rk3328 (pl330 or compatible). > DMAC connected to 16 DMA sources. Each sources have ID number that is > called 'Req number' in rk3328 TRM. After this patch is applied total 7 > of DMA sources will be activated as follows: > > | Req number | Source | Required | > | | | channels | > |------------+--------+-----------| > | 8, 9 | SPI0 | 2ch | > | 11, 12 | I2S0 | 2ch | > | 14, 15 | I2S1 | 2ch | > | 10 | SPDIF | 1ch | > |------------+--------+-----------| > | | Total | 7ch | > |------------+--------+-----------| > | 6, 7 | UART2 | 2ch | -> cannot get DMA channels > > Due to rk3328 DMAC specification we can use max 8 channels at same > time. If SPI0/I2S0/I2S1/SPDIF will be activated by this patch, > required DMAC channels reach to 7. So the last two channels (for > UART2) cannot get DMA resources. Wouldn't the dma allocation depend on the probe ordering? Or is this predetermined, so that always uart2 looses its dmas? Heiko