> Am 14.01.2020 um 19:29 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>:
>
>
>> 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.
I have checked our tree and it is already built into a separate module with
sound/soc/ti/aess/omap-aess-core.c: { .compatible = "ti,omap4-aess", },
So
> target-module@f1000 { /* 0x401f1000, ap 32 20.0 */
> ...
> aess: aess {
> compatible = "ti,omap4-aess";
> status = "disabled";
> };
> };
would be what we will need.
BR,
Nikolaus
