Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp5688231pxv; Wed, 21 Jul 2021 11:21:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxAhv9Rw83Wpoo/3Kfqy7vCHRXQTmmUr++VSZkFvIxJ4EJTonPJ8/+ZkkoLXdTzp9oy02zS X-Received: by 2002:a17:906:57d0:: with SMTP id u16mr40772490ejr.468.1626891684323; Wed, 21 Jul 2021 11:21:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626891684; cv=none; d=google.com; s=arc-20160816; b=EXymL3uJ7e+yoEuyA6ijrzxQ1ozdc/UEcwQv1JOCUcmJRXR2+nsRVN+rGag9uDie5q bknmy5U9C5EKQtMpvnJwEXzbXa4cczouKuNwvVq6wXeY+G1eFDKsWsDBlad+YTLHlLxw hmonb8/0rf8Uk7qWeNKhvEwN2eOkVhiHamEPwZ2BEL7b4T2BigFT3mRCpYSGCZiEtFR6 qJjtse3YS5vSCWsprDJKY9WNgXU1Ttr5dMyiNw123usgidquR60XDn5XILEC3Gy21qcf /7Kwv1bCM/GXV3VWQadzQkO5LC5RufO3jA8a6ihropSIyKws06AOZCIgnWS312S3Tece EiPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=ZFyJ5UYZo85XZjVaMgv/JyZVh2h1UvIv58TZmRPI7UY=; b=HV4jVA+P4kuiIGDtCyCWF1qEM/CdHe74hbEs/PJ5o8pREosCxzqv4U2HfYqu7N4MZU ePeqwj5Y3Wssz1nzw2uxMPs3pQnhNm2YCS5R3RSYxyD8jDgzkmsDEHQX3sMnzlSaf3lt 8BJGMVlqkAkV+z8mfUbJKB4IWCN46QCU1hTuH2aSWwRA54dfDESbVIaAh04yP+RgVfWb nFnJjc4fOOJLO6pTlGS5LRr/wdRacvFNGqJPLx10P7fvA0/Y0U6ljpWAL8ls5apMZCnx +MWdjrvY/x7bBq2D7mt2mN/JnbV33tpqy/rCb6NuKwXqMt5O8M/p5lLFqOmZw/5QQZ8L pxzg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y1si27652794eds.296.2021.07.21.11.20.58; Wed, 21 Jul 2021 11:21:24 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237942AbhGUMrq (ORCPT + 99 others); Wed, 21 Jul 2021 08:47:46 -0400 Received: from mga09.intel.com ([134.134.136.24]:59252 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232672AbhGUMrp (ORCPT ); Wed, 21 Jul 2021 08:47:45 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10051"; a="211432735" X-IronPort-AV: E=Sophos;i="5.84,258,1620716400"; d="scan'208";a="211432735" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jul 2021 06:28:21 -0700 X-IronPort-AV: E=Sophos;i="5.84,258,1620716400"; d="scan'208";a="662114672" Received: from tamoore1-mobl3.amr.corp.intel.com (HELO [10.209.131.176]) ([10.209.131.176]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jul 2021 06:28:20 -0700 Subject: Re: [PATCH 1/3] ASoC: SOF: Parse fw/tplg filename from DT To: Mark Brown Cc: Devicetree List , Daniel Baluta , Kai Vehmanen , Liam Girdwood , Daniel Baluta , Linux-ALSA , Linux Kernel Mailing List , Rob Herring , Ranjani Sridharan , Takashi Iwai , Daniel Baluta References: <20210715141802.880911-1-daniel.baluta@oss.nxp.com> <20210715141802.880911-2-daniel.baluta@oss.nxp.com> <20210715143906.GD4590@sirena.org.uk> <20210721125912.GE4259@sirena.org.uk> From: Pierre-Louis Bossart Message-ID: Date: Wed, 21 Jul 2021 08:28:17 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210721125912.GE4259@sirena.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Please fix your mail client to word wrap within paragraphs at something > substantially less than 80 columns. Doing this makes your messages much > easier to read and reply to. Oops. >> - we currently don't support 'shipping the topology and firmware >> bundled up in a single image to avoid them getting out of sync'. No >> idea how that might work. > > Seems like it'd be trivial to arrange in the kernel, or with userspace > firmware loading the loader could do the unpacking. I think we can bundle the firmware inside of the kernel image itself, but we've never tried so it doesn't work by default. I don't know what userspace loading means, we rely on request_firmware and don't assume any specific support from userspace. >> - if the machine driver is specified in DeviceTree, then the topology >> used is *required* to be aligned with the machine driver. The rules >> are that a topology may not make references to a BE dailink exposed in >> the machine driver, but conversely if the topology makes a reference >> to a BE dailink that is not exposed in the machine driver the topology >> parsing will fail. It's one of the current weaknesses of >> topology-based solutions, we have non-configurable hardware-related >> things that are described in topology but should really be described >> in platform firmware, be it ACPI or DT, and provided to the topology. > > That seems like an orthogonal issue here? The requirement for a > firmware that's joined up with the hardware (and system description) > that it's being used with exists regardless of how we rename things. It's not completely orthogonal. The topology currently defines e.g. the I2S interface index, Mclk, bclk, fsync, etc, and my point is that these bits of information are completely related to the hardware and should probably come from platform firmware/ACPI. The topology framework currently provides too much freedom to developers, it's fine to add new pipelines, PCM devices and new processing, but when it comes to the hardware interfaces the topology is completely constrained. I've been arguing for a while now that the dailink descriptions and configurations should be treated as an input to the topology, not something that the topology can configure. I don't know how many issues we had to deal with because the topology settings were not supported by the hardware, or mismatches between topology and machine drivers (missing dailinks, bad dailink index, etc).