Re: [PATCH] ARM: dts: Configure omap5 AESS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Ok. Will become a major rework of the driver...
On the other hand the audio graph library could simplify a lot of things.

> 
>> 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.

What it might need is to make the aess driver a completely separate module
loaded identified through the compatible record.

> 
>> 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..

That is why I propose a comment around it...
But I am not sure if empty nodes are even allowed.

> If and when the aess driver work the child node can be just added :)

Yes, surely. So it is up to you to decide.

Best regards,
Nikolaus





[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux