Received: by 10.213.65.68 with SMTP id h4csp3653847imn; Tue, 3 Apr 2018 08:34:30 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+Yb7vgz2EOuO1NFONvhFWt13nVuYgSdMzdtG27JJxjeDZibmonJIpIv32ltUBOKx0slDeE X-Received: by 10.101.72.13 with SMTP id h13mr9375353pgs.420.1522769670402; Tue, 03 Apr 2018 08:34:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522769670; cv=none; d=google.com; s=arc-20160816; b=aUaZMv/Qp1B4xc/DaoHWVEyjvWjv2W82/Z4E1mlQw7Sth/0/QfWjFXOm2+eabiT2fi pbUOq0pTrCLy71pnMcFP38lLdB0emz+hUQrSRwpFUoC10PaGaK2dIVTXCxjBeOMLRkwr vIN67ZJA45xJJAEbNr53Znbw6u9W4CYiG00MAoYzYDcL+sooBz0N1VborsDeaA6rF/92 wSkDsvu9B53mnHOJoP44s3xceVnjxJNwGzpfe9JNIw9lRW4tMcA3Xo6Gsx2OXZLvV7Dy usYk3etZP23Bh/8Fwdvu/4Y2a1wJshLS609DS5kR+Xc+ozxYdK6GvRCmYv2ioIUyr8SY p0kw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from :arc-authentication-results; bh=8DPtJwtRF3BsN4AbIn3fJxtTo1XT0lUiXeauOTlMPpY=; b=XCoP5xi+panjzH2+wkRvbB9Jx+y19rfJVcoQrT6bcFSlrHX0sDjZ86j/A7b5H0l7Ja dO9mDtBqUpoIInlMTchMfAG/vRU74+l1rBg3uqOsouBplD5/k3Bx3vhmbTOYF1im+Slq HofZ0grk7IyHPZzgbz+RyM+WzaPsoGmxaWt004+5FJYnc4+wM7jJkRiisb92bXx5iJok vNgTNQh2wBt/K6P9+BDC+rl0KM9p5HdNhz7U+HBqxwEZpaWuefgfYMbqk4Gc1yIqRN6e EkVUEfJqz9rMSejq0EBK7r2SCbZ9edxkHP6FZOScFQa85A+24GvprmvWD9iOu5mhqgSC 2c+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b3si2063213pgn.665.2018.04.03.08.34.16; Tue, 03 Apr 2018 08:34:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752258AbeDCPdC (ORCPT + 99 others); Tue, 3 Apr 2018 11:33:02 -0400 Received: from smtp03.smtpout.orange.fr ([80.12.242.125]:38023 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751434AbeDCPdB (ORCPT ); Tue, 3 Apr 2018 11:33:01 -0400 Received: from belgarion ([86.201.130.131]) by mwinf5d38 with ME id VrYz1x0042qEl8e03rYzEC; Tue, 03 Apr 2018 17:33:00 +0200 X-ME-Helo: belgarion X-ME-Auth: amFyem1pay5yb2JlcnRAb3JhbmdlLmZy X-ME-Date: Tue, 03 Apr 2018 17:33:00 +0200 X-ME-IP: 86.201.130.131 From: Robert Jarzmik To: Arnd Bergmann Cc: Daniel Mack , Haojian Zhuang , Vinod Koul , Jaroslav Kysela , Takashi Iwai , Liam Girdwood , Mark Brown , Linux ARM , Linux Kernel Mailing List , alsa-devel@alsa-project.org Subject: Re: [PATCH 14/15] ARM: pxa: change SSP devices allocation References: <20180402142656.26815-1-robert.jarzmik@free.fr> <20180402142656.26815-15-robert.jarzmik@free.fr> X-URL: http://belgarath.falguerolles.org/ Date: Tue, 03 Apr 2018 17:32:58 +0200 In-Reply-To: (Arnd Bergmann's message of "Tue, 3 Apr 2018 09:06:46 +0200") Message-ID: <87lge4485x.fsf@belgarion.home> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Arnd Bergmann writes: chop chop ... removed several mail recipients to leave only the ASoC / PXA subset ... > On Mon, Apr 2, 2018 at 4:26 PM, Robert Jarzmik wrote: > >> >> +static struct pxa_ssp_info pxa_ssp_infos[] = { >> + { .dma_chan_rx_name = "ssp1_rx", .dma_chan_tx_name = "ssp1_tx", }, >> + { .dma_chan_rx_name = "ssp1_rx", .dma_chan_tx_name = "ssp1_tx", }, >> + { .dma_chan_rx_name = "ssp2_rx", .dma_chan_tx_name = "ssp2_tx", }, >> + { .dma_chan_rx_name = "ssp2_rx", .dma_chan_tx_name = "ssp2_tx", }, >> + { .dma_chan_rx_name = "ssp3_rx", .dma_chan_tx_name = "ssp3_tx", }, >> + { .dma_chan_rx_name = "ssp3_rx", .dma_chan_tx_name = "ssp3_tx", }, >> + { .dma_chan_rx_name = "ssp4_rx", .dma_chan_tx_name = "ssp4_tx", }, >> + { .dma_chan_rx_name = "ssp4_rx", .dma_chan_tx_name = "ssp4_tx", }, >> +}; > > This part looks odd to me, you're adding an extra level of indirection to > do two stages of lookups in some form of platform data. That's unfortunately right. > Why can't you just always use "rx" and "tx" as the names here? Well I couldn't. I'll explain you why, and maybe you'll find a better solution. That all is related to how ASoC and SSP interact. If I remember correctly, here is how it works : - the DMA channel is requested in sound/arm/pxa2xx-pcm-lib.c:128 return snd_dmaengine_pcm_open( substream, dma_request_slave_channel(rtd->platform->dev, The trick is that the device here is _not_ the SSP one, it's if memory serves me well the pxa-pcm-audio one. As a consequence, the device cannot be used to differenciate which SSP exactly is providing the sound samples stream. This information is nevertheless required to choose the correct requestor line, which is a 1-to-1 match to the SSP port. The indirection in the channel name is used to choose the correct requestor line for a given SSP port providing the samples. It also must be underlined that this dma request serves both AC97 and SSP as sample providers. > (also, I don't see why each line is duplicated, but I'm sure there's > an easy answer for that). Ahh that is an unfortunate rebase most probably :) Cheers. -- Robert