Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp503328pxk; Wed, 9 Sep 2020 10:51:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz9tJeB8/30/KWvSB1h+z+cRzr6KFHrMKbLnx68jeWsWQ866ElLNop8ogvO4TL3I9Li8D8V X-Received: by 2002:a17:906:3957:: with SMTP id g23mr5140850eje.24.1599673900556; Wed, 09 Sep 2020 10:51:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599673900; cv=none; d=google.com; s=arc-20160816; b=A51Rise4ofknrI1hTpOPrDU/tn2bMkpTgLmU1rN2ieseYrf0RyMbD6J+EqTSIjgmDh UT4Yp3LcewJcZN7pmLBxVf+tcf1QNFGJ6zJztYzrJALxcjaj2KvnBvJeFNG665o9cR6Q l1ZksnCYsp3lmu8oOm62tEz98MP8Os6o1Sfr8WruMSW9ofqSu3KlXYizbVCbHwZ0IwRu pRkgeCUi1X1NEReY2HkTJw5aXth3x+5OLlTsRdwefgIlg6G9Iln3CDJJc4/Evulk19uH 0rF8LNnIi8G8Rs+rA6b6VJjJNcbxia3PgUu4fKsSCk+wEZc2Lcc6pnXkoQE+nyoE6RYY pQaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RWPvIloFp9d57MQOw6+EFOTTqdOEgTv7v9mFR+ZJ29w=; b=j/5Jh8Ikiqg4cTnDYLJChR/bzpxYqqNMpF52gPavkpRy08NQh9q9Gr7ShFtk6S4gKd njG3abxcCTb5/GuDidMaEGF6Vw0gIZE+XIVTtI+kDn4s+EzpjgP4gQcy/SRBliwghZOx LQmKP2PLFiKR8PYu0vbyfQ4geOyDPOcXze7hrXpN9eg6164Z9szdeo7hsg5/3u0V58m4 q6YwevJrv+CVPL6+lM7O+r6PC0lU2llKsf9EXTq9QdgUgVeBDZvnr3O1Nic4Tzqyq1sV NubfQ2majWV5k0GRn6oGe3LdR/VeVv5s4OGtFk3e+2TFVl4iRY0HVIL9CwEtcnJHWUem uzZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=fols9K8K; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m10si2068272edf.246.2020.09.09.10.51.17; Wed, 09 Sep 2020 10:51:40 -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; dkim=pass header.i=@kernel.org header.s=default header.b=fols9K8K; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728347AbgIIRto (ORCPT + 99 others); Wed, 9 Sep 2020 13:49:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:54436 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726642AbgIIRtk (ORCPT ); Wed, 9 Sep 2020 13:49:40 -0400 Received: from mail-oo1-f52.google.com (mail-oo1-f52.google.com [209.85.161.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9C2D621D7D; Wed, 9 Sep 2020 17:49:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599673775; bh=je19kXLLPeXGnvJ2cpDOUeTXsKizvTv7mb1EaLQTtgE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=fols9K8K9dpRLbuLhLcJb9qUeeCiTKsuENoJrq+YBNeC0RK/ZlH1kHvO5EDKRABAp yD13dwjts1JX3l9VaH8AGbnOCA9svC0V2YMwvgnpGgF1YnZm7nx35PURL8jrcDh9te 2JVdXPmWRdf9FlSYzobSMWPUf5iv+c6DEZcTsdQ4= Received: by mail-oo1-f52.google.com with SMTP id k13so783867oor.2; Wed, 09 Sep 2020 10:49:35 -0700 (PDT) X-Gm-Message-State: AOAM532Rw7UfJeDCqHp0Fen9WfMgO7k81ipJNMNR1pwLlhI2PZdT38Zc E3MYFDjkhpjuRW9mWbIfJLHSq2AoGozmiVHNmQ== X-Received: by 2002:a4a:d38c:: with SMTP id i12mr1548249oos.81.1599673774912; Wed, 09 Sep 2020 10:49:34 -0700 (PDT) MIME-Version: 1.0 References: <20200907100039.1731457-1-cychiang@chromium.org> <20200907100039.1731457-3-cychiang@chromium.org> <20200908203357.GA861143@bogus> In-Reply-To: From: Rob Herring Date: Wed, 9 Sep 2020 11:49:22 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 2/3] ASoC: qcom: dt-bindings: Add sc7180 machine bindings To: Cheng-yi Chiang Cc: linux-kernel , Mark Brown , Taniya Das , Rohit kumar , Banajit Goswami , Patrick Lai , Andy Gross , Bjorn Andersson , Liam Girdwood , Jaroslav Kysela , Takashi Iwai , Srini Kandagatla , Stephan Gerhold , Matthias Brugger , Heiko Stuebner , Doug Anderson , Dylan Reid , Tzung-Bi Shih , Linux ARM , linux-arm-msm , "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..." Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 9, 2020 at 3:24 AM Cheng-yi Chiang wrote: > > On Wed, Sep 9, 2020 at 4:34 AM Rob Herring wrote: > > > > On Mon, Sep 07, 2020 at 06:00:38PM +0800, Cheng-Yi Chiang wrote: > > > Add devicetree bindings documentation file for sc7180 sound card. > > > > > > Signed-off-by: Cheng-Yi Chiang > > > --- > > > .../bindings/sound/qcom,sc7180.yaml | 143 ++++++++++++++++++ > > > 1 file changed, 143 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/sound/qcom,sc7180.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/sound/qcom,sc7180.yaml b/Documentation/devicetree/bindings/sound/qcom,sc7180.yaml > > > new file mode 100644 > > > index 000000000000..ae809346ca80 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/sound/qcom,sc7180.yaml > > > @@ -0,0 +1,143 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/sound/qcom,sc7180.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Qualcomm Technologies Inc. SC7180 ASoC sound card driver > > > + > > > +maintainers: > > > + - Rohit kumar > > > + - Cheng-Yi Chiang > > > + > > > +description: > > > + This binding describes the SC7180 sound card which uses LPASS for audio. > > > + > > > +properties: > > > + compatible: > > > + const: qcom,sc7180-sndcard > > > + > > > + audio-routing: > > > + $ref: /schemas/types.yaml#/definitions/non-unique-string-array > > > + description: > > > + A list of the connections between audio components. Each entry is a > > > + pair of strings, the first being the connection's sink, the second > > > + being the connection's source. > > > + > > > + model: > > > + $ref: /schemas/types.yaml#/definitions/string > > > + description: User specified audio sound card name > > > + > > > + headset-jack: > > > + $ref: /schemas/types.yaml#/definitions/phandle > > > + description: phandle of the codec for headset detection > > > + > > > + hdmi-jack: > > > + $ref: /schemas/types.yaml#/definitions/phandle > > > + description: phandle of the codec for hdmi jack detection > > > > You already have links to these devices. Why duplicate it here? > > > > What if you had 2 headsets? This doesn't scale. > > > Hi Rob, thanks for reviewing. > There was some discussion in > https://patchwork.kernel.org/patch/11737905/#23571643 about how to > specify the dailink that has a headset jack. > I would like to pass the information of headset jack and hdmi jack to > the machine driver so the machine driver can call > snd_soc_component_set_jack to set jack when init the corresponding link. > Headset jack and hdmi jack will be treated differently for button and > event type. > Because of this, we can not just set a property "jack" in the link. Don't design your binding around some driver architecture. Limitations of ASoC are not reasons for your binding. For DP and HDMI, we assume HPD is supported generally as that's a standard function for HDMI/DP controllers. There's a 'no-hpd' property for cases of broken HPD. That hardware description is part of the device HPD is connected to which is the HDMI/DP controller/bridge or the connector node in the case of a GPIO line. That doesn't belong in the virtual sound card. I would assume a codec to be similar. The codec node (the alc5682 node) should have any jack related properties (or possibly implicitly support it by default). > As for the 2 headsets case (I guess you mean hp jack and mic jack), on > this board we will not have this use case. > If someone really wants to build hp jack and mic jack on the board > based on this machine driver, we can add two more property hp-jack and > mic-jack to specify that, > as the machine driver will need to know the different jack types > anyway. What do you think ? I was thinking more of a case of having 2 of the same thing. Perhaps 2 HDMI outputs. Or if you have DP instead of HDMI? Just going to add 'dp-jack'? Rob