All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
To: "H. Nikolaus Schaller" <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Benoît Cousson"
	<bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Matthijs van Duin"
	<matthijsvanduin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Peter Ujfalusi" <peter.ujfalusi-l0cyMroinI0@public.gmane.org>,
	"Tero Kristo" <t-kristo-l0cyMroinI0@public.gmane.org>
Subject: Re: [PATCH] ARM: dts: Configure omap5 AESS
Date: Tue, 14 Jan 2020 09:16:34 -0800	[thread overview]
Message-ID: <20200114171634.GS5885@atomide.com> (raw)
In-Reply-To: <D51230C4-2642-4388-959F-313A3382AB99-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>

* H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> [200114 17:05]:
> > Am 14.01.2020 um 17:46 schrieb Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
> > 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

WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: linux-omap@vger.kernel.org,
	"Benoît Cousson" <bcousson@baylibre.com>,
	devicetree@vger.kernel.org,
	"Matthijs van Duin" <matthijsvanduin@gmail.com>,
	"Peter Ujfalusi" <peter.ujfalusi@ti.com>,
	"Tero Kristo" <t-kristo@ti.com>
Subject: Re: [PATCH] ARM: dts: Configure omap5 AESS
Date: Tue, 14 Jan 2020 09:16:34 -0800	[thread overview]
Message-ID: <20200114171634.GS5885@atomide.com> (raw)
In-Reply-To: <D51230C4-2642-4388-959F-313A3382AB99@goldelico.com>

* H. Nikolaus Schaller <hns@goldelico.com> [200114 17:05]:
> > Am 14.01.2020 um 17:46 schrieb Tony Lindgren <tony@atomide.com>:
> > 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

  parent reply	other threads:[~2020-01-14 17:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14 15:09 [PATCH] ARM: dts: Configure omap5 AESS Tony Lindgren
2020-01-14 16:37 ` H. Nikolaus Schaller
     [not found]   ` <52905C15-A2D1-4372-9781-D602D0B274B6-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
2020-01-14 16:46     ` Tony Lindgren
2020-01-14 16:46       ` Tony Lindgren
2020-01-14 17:04       ` H. Nikolaus Schaller
     [not found]         ` <D51230C4-2642-4388-959F-313A3382AB99-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
2020-01-14 17:16           ` Tony Lindgren [this message]
2020-01-14 17:16             ` Tony Lindgren
     [not found]             ` <20200114171634.GS5885-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2020-01-14 18:29               ` H. Nikolaus Schaller
2020-01-14 18:29                 ` H. Nikolaus Schaller
     [not found]                 ` <632E66D6-47EF-44CF-BF02-B0F5A215D904-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
2020-01-14 18:39                   ` H. Nikolaus Schaller
2020-01-14 18:39                     ` H. Nikolaus Schaller
     [not found]                     ` <ACB71118-B121-4CF7-934D-A88654366E8F-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
2020-01-14 21:00                       ` Tony Lindgren
2020-01-14 21:00                         ` Tony Lindgren
2020-01-15 12:49                         ` H. Nikolaus Schaller
     [not found]                           ` <5E0BF30D-2723-4724-89E1-449230758EE2-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
2020-01-16 18:52                             ` Tony Lindgren
2020-01-16 18:52                               ` Tony Lindgren
     [not found] ` <20200114150937.18304-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2020-01-16 15:53   ` kbuild test robot
2020-01-16 15:53     ` kbuild test robot
2020-01-16 15:53     ` kbuild test robot
     [not found]     ` <202001162346.4yVlrA8l%lkp-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2020-01-16 18:52       ` Tony Lindgren
2020-01-16 18:52         ` Tony Lindgren
2020-01-16 18:52         ` Tony Lindgren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200114171634.GS5885@atomide.com \
    --to=tony-4v6ys6ai5vpbdgjk7y7tuq@public.gmane.org \
    --cc=bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org \
    --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=matthijsvanduin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=peter.ujfalusi-l0cyMroinI0@public.gmane.org \
    --cc=t-kristo-l0cyMroinI0@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.