From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B002C4363D for ; Tue, 20 Oct 2020 14:55:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 37F222222C for ; Tue, 20 Oct 2020 14:55:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="cK9G7+OH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392672AbgJTOzv (ORCPT ); Tue, 20 Oct 2020 10:55:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728489AbgJTOzv (ORCPT ); Tue, 20 Oct 2020 10:55:51 -0400 Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 20FFDC0613CE for ; Tue, 20 Oct 2020 07:55:49 -0700 (PDT) Received: by mail-wm1-x341.google.com with SMTP id 13so2117033wmf.0 for ; Tue, 20 Oct 2020 07:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uf/L+N0SXiT5GxWzSMpW76s8MjBMaRe3gnVIlCSIR5M=; b=cK9G7+OH/TUQCyR8rfJv0QoQ3SjEQsnF9XCjVN6xqr/O8yU3IlDfbvmsbTfkhxQ06f q4IpVZ8VlQ3fVXlWWHGSfLpylD2IH5P4NE25315km3BTplz4wROeM/cLeRnrZhnHb/v5 PyAaPitLsRWmdVTipbLqX4Out+F21VmQJ/X09y763klLznhk8Wjph5Dm6ltToTwu1GKi 6cF9SRXzSOe+CnDRgo2LkN4n5tkvfZ7EpQsA7EkHbGt3NkoE1mD/PmAfdxkXt8UbFE9X RN1mqjge119zJMoJpTqXMa+rN2apg4iQxVK+dpL4RLHKRIlCnNkTt3EAvl5wmXLl4Uz1 eT1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uf/L+N0SXiT5GxWzSMpW76s8MjBMaRe3gnVIlCSIR5M=; b=n0SqJL5IH10XRhbpoZighN6e/YWbRTKeNRlRAFyRm8i7OJjd59bhfrz1nmdOYkaIwP SBJL7UN/8XK9yxYFR3uEdXxpPKHCinktrY0XweXdVcF/h3cPwTZ5xoH+o4y1EEF72tAP 7dPZ26EX8uxk7j4h7z8cSG4to3Zq1P1LpPYehHBKz7dGZ6I/8k1Ac2rY1psV1+DKEwbu rdFbsObSil9iH72GSW0gH6arFm/gdJNj11OdIcu5kD+LWHBDH+Fq9uH+xQIqLXHSNzUg 2I8EfGSeRCQpEB5vKpV+o4PfuoyaBAYXTjHigJMEJ0faoyENPZRhsIqyVCiM+TI4Eg70 VNfQ== X-Gm-Message-State: AOAM5312QZ8fZMkGmvYk0896ocJyW/9zFH14/FYj51A4WZt9e9kMS2Uu Lkh8ha3HcYvuZQd4gEjAw68QSw== X-Google-Smtp-Source: ABdhPJwZTIfXIjPLWWjL97y1NfJTXN0Y2s/to/X10G0kOS41vqvGeaVeSXPhf5OZA0t9DHJLkiPgNg== X-Received: by 2002:a7b:ce8f:: with SMTP id q15mr3351776wmj.88.1603205747699; Tue, 20 Oct 2020 07:55:47 -0700 (PDT) Received: from [192.168.86.34] (cpc86377-aztw32-2-0-cust226.18-1.cable.virginm.net. [92.233.226.227]) by smtp.googlemail.com with ESMTPSA id 1sm3868599wre.61.2020.10.20.07.55.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2020 07:55:46 -0700 (PDT) Subject: Re: [PATCH v11 2/3] ASoC: qcom: dt-bindings: Add sc7180 machine bindings To: Mark Brown , Cheng-yi Chiang Cc: linux-kernel , Taniya Das , Rohit kumar , Banajit Goswami , Patrick Lai , Andy Gross , Bjorn Andersson , Liam Girdwood , Rob Herring , Jaroslav Kysela , Takashi Iwai , Stephan Gerhold , Matthias Brugger , Heiko Stuebner , Srinivasa Rao , Doug Anderson , Dylan Reid , Tzung-Bi Shih , Linux ARM , linux-arm-msm , Kuninori Morimoto , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." , "moderated list:ARM/Mediatek SoC support" , "open list:ARM/Rockchip SoC..." , Ajye Huang References: <20200914080619.4178587-1-cychiang@chromium.org> <20200914080619.4178587-3-cychiang@chromium.org> <7bdc0d63-27b1-f99e-c5f8-65f880733d16@linaro.org> <20201015161251.GF4390@sirena.org.uk> <20201020143711.GC9448@sirena.org.uk> From: Srinivas Kandagatla Message-ID: <63f1a29c-0758-97b8-ce80-fe43d91630fa@linaro.org> Date: Tue, 20 Oct 2020 15:55:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20201020143711.GC9448@sirena.org.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 20/10/2020 15:37, Mark Brown wrote: > I don't understand what "logic scattered in various dtsi files" means, > sorry. > >> Yes, that should work to describe the dailink we are using. >> But a more tricky issue is how to do calls like setting PLL in dai startup ops. > ... > >> I think that asking a generic machine driver to do configuration like >> this with only a limited interface of device property >> might be too much of an ask for the machine driver. > Richard was looking at some basic configuration for PLLs. > >> Would you mind if I simplify the compatible string like Srinivas >> suggested, and send a v12? >> As for other two kinds of variations that I am aware of: >> 1. front mic / rear mic >> 2. replace alc5682 with adau7002 > The CODEC change is going to be described in the DT no matter what - > you'll have a reference to the CODEC node but it may make sense if > there's enough custom code around it. For front vs rear mic the > simplest thing would just be to not mention which if this is a hardware > fixed thing, otherwise a control. > >> We can set different board names and different compatible strings to >> achieve such variation. >> So that it would make sense to describe configuration in compatible >> strings like you suggested, and also provides UCM a way to distinguish >> different boards. > I don't recall having suggested distinguishing these things with a > compatible string, especially not the microphones. UCM can already use > the display names for the boards to distinguish things. Not with the compatible string! Currently card name, and long name are exactly same in all Qualcomm soundcards, which makes it very difficult to identify how those boards re wired up at UCM2 level. So the plan is to properly populate card long name with "model" property which can include details on how things are wiredup on that board. --srini