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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 E7134C33C9E for ; Tue, 14 Jan 2020 17:16:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B90CA2465A for ; Tue, 14 Jan 2020 17:16:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726270AbgANRQj (ORCPT ); Tue, 14 Jan 2020 12:16:39 -0500 Received: from muru.com ([72.249.23.125]:50950 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726195AbgANRQj (ORCPT ); Tue, 14 Jan 2020 12:16:39 -0500 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id A61F9816C; Tue, 14 Jan 2020 17:17:19 +0000 (UTC) Date: Tue, 14 Jan 2020 09:16:34 -0800 From: Tony Lindgren To: "H. Nikolaus Schaller" Cc: linux-omap@vger.kernel.org, =?utf-8?Q?Beno=C3=AEt?= Cousson , devicetree@vger.kernel.org, Matthijs van Duin , Peter Ujfalusi , Tero Kristo Subject: Re: [PATCH] ARM: dts: Configure omap5 AESS Message-ID: <20200114171634.GS5885@atomide.com> References: <20200114150937.18304-1-tony@atomide.com> <52905C15-A2D1-4372-9781-D602D0B274B6@goldelico.com> <20200114164613.GR5885@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org * H. Nikolaus Schaller [200114 17:05]: > > Am 14.01.2020 um 17:46 schrieb Tony Lindgren : > > Care to clarify what you have in mind? The module is generic, aess > > device will be the child node. > > The existing driver is hooked into the sound root-node and looks for a > ti,aess = <&aess>; link: > > / { > sound: sound { > compatible = "ti,abe-twl6040"; > ti,model = "omap5-uevm"; > > ti,jack-detection; > ti,mclk-freq = <19200000>; > > ti,mcpdm = <&mcpdm>; > ti,mcbsp1 = <&mcbsp1>; > ti,mcbsp2 = <&mcbsp2>; > ti,mcbsp3 = <&mcbsp3>; > > ti,twl6040 = <&twl6040>; > ti,aess = <&aess>; > > ... > }; > }; > > Well, this could be simply wrong... I.e. the aess node should request > all the phandles to mcpdm and mcbsps because it is connected to. The aess label above should be in the child aess node, not in the target-module. > Or it is right to use the sound node to "connect" all subsystems. Sounds like that's all taken care of nowadays with the generic graph binding: Documentation/devicetree/bindings/graph.txt See also snd-soc-audio-graph-card and various users for it: Documentation/devicetree/bindings/sound/audio-graph-card.txt > Then the "aess" core could also become the child node of the target-module: > > target-module@f1000 { /* 0x401f1000, ap 32 20.0 */ > ... > aess: aess { > compatible = "ti,aess"; > status = "disabled"; > }; > }; Yeah this is how it should be :) > Although it looks better this way, it may make it even one step > more difficult to resurrect the old code... Well the old phandles and properties should work the same, just put them into the child aess node. No need to stuff anything else there at the target-module level AFAIK. > And DT maintainers are not happy with otherwise undefined compatible > definitions. > > So maybe: > > target-module@f1000 { /* 0x401f1000, ap 32 20.0 */ > ... > > aess: aess { > /* revisit > compatible = "ti,aess"; > status = "disabled"; > */ > }; > }; But we have no binding and no driver for the aess at this point.. If and when the aess driver work the child node can be just added :) Regards, Tony From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH] ARM: dts: Configure omap5 AESS Date: Tue, 14 Jan 2020 09:16:34 -0800 Message-ID: <20200114171634.GS5885@atomide.com> References: <20200114150937.18304-1-tony@atomide.com> <52905C15-A2D1-4372-9781-D602D0B274B6@goldelico.com> <20200114164613.GR5885@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "H. Nikolaus Schaller" Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, =?utf-8?Q?Beno=C3=AEt?= Cousson , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Matthijs van Duin , Peter Ujfalusi , Tero Kristo List-Id: linux-omap@vger.kernel.org * H. Nikolaus Schaller [200114 17:05]: > > Am 14.01.2020 um 17:46 schrieb Tony Lindgren : > > Care to clarify what you have in mind? The module is generic, aess > > device will be the child node. > > The existing driver is hooked into the sound root-node and looks for a > ti,aess = <&aess>; link: > > / { > sound: sound { > compatible = "ti,abe-twl6040"; > ti,model = "omap5-uevm"; > > ti,jack-detection; > ti,mclk-freq = <19200000>; > > ti,mcpdm = <&mcpdm>; > ti,mcbsp1 = <&mcbsp1>; > ti,mcbsp2 = <&mcbsp2>; > ti,mcbsp3 = <&mcbsp3>; > > ti,twl6040 = <&twl6040>; > ti,aess = <&aess>; > > ... > }; > }; > > Well, this could be simply wrong... I.e. the aess node should request > all the phandles to mcpdm and mcbsps because it is connected to. The aess label above should be in the child aess node, not in the target-module. > Or it is right to use the sound node to "connect" all subsystems. Sounds like that's all taken care of nowadays with the generic graph binding: Documentation/devicetree/bindings/graph.txt See also snd-soc-audio-graph-card and various users for it: Documentation/devicetree/bindings/sound/audio-graph-card.txt > Then the "aess" core could also become the child node of the target-module: > > target-module@f1000 { /* 0x401f1000, ap 32 20.0 */ > ... > aess: aess { > compatible = "ti,aess"; > status = "disabled"; > }; > }; Yeah this is how it should be :) > Although it looks better this way, it may make it even one step > more difficult to resurrect the old code... Well the old phandles and properties should work the same, just put them into the child aess node. No need to stuff anything else there at the target-module level AFAIK. > And DT maintainers are not happy with otherwise undefined compatible > definitions. > > So maybe: > > target-module@f1000 { /* 0x401f1000, ap 32 20.0 */ > ... > > aess: aess { > /* revisit > compatible = "ti,aess"; > status = "disabled"; > */ > }; > }; But we have no binding and no driver for the aess at this point.. If and when the aess driver work the child node can be just added :) Regards, Tony