thesofproject
[DNM] Tools: Topology2: Use for LNL own platform configuration lnl.conf
The new lnl.conf is copy of mtl.conf but DMIC_DRIVER_VERSION needs to be increased by one for a small registers change.
what register change @singalsu ? I thought MTL and LNL could use exactly the same blobs?
what register change @singalsu ? I thought MTL and LNL could use exactly the same blobs?
I also thought so, but I realized there's one bitfield in OUTCONTROL removed and marked as reserved. We should not set those bits due to risk of them becoming reused for something else later. Though there should be no harm from doing it now.
what register change @singalsu ? I thought MTL and LNL could use exactly the same blobs?
I also thought so, but I realized there's one bitfield in OUTCONTROL removed and marked as reserved. We should not set those bits due to risk of them becoming reused for something else later. Though there should be no harm from doing it now.
Do we need to program this OUTCONTROL bitfield, how important is it? I mean, if we can keep the same blobs for MTL and LNL it's best to do so and not use an obscure feature of the hardware we never knew we didn't need.
Do we need to program this OUTCONTROL bitfield, how important is it? I mean, if we can keep the same blobs for MTL and LNL it's best to do so and not use an obscure feature of the hardware we never knew we didn't need.
It's the DMA burst size in MTL and it needs to be set. I haven't tried to not set it with MTL but in earlier platforms having non-matching configuration in DMIC IP and in DMA resulted in not working capture. In LNL and after we should not write to registers non-existing control bits.
We identify in topology DMIC driver versions 1-4, with 5 coming, so we already handle a number of different hardware versions in ChromeOS topology builds. We don't have release with v2 (was Sue Creek). But three versions are in use with v1 APL to TGL, v3 MTL, v4 LNL.
@singalsu it's pretty obvious why the change happened: the DMA burst is irrelevant for LNL+ since it uses a different DMA. That's not really a DMIC IP change, more its interface. I have no objection if we avoid setting something that is not used, but we should not expect any behavioral change with this PR. Reserved bits are ignored....
@singalsu it's pretty obvious why the change happened: the DMA burst is irrelevant for LNL+ since it uses a different DMA. That's not really a DMIC IP change, more its interface. I have no objection if we avoid setting something that is not used, but we should not expect any behavioral change with this PR. Reserved bits are ignored....
Yes, that is true. There is no change in operation from not setting those bits or leaving them set. But it would be good to add to LNL driver a warning of trying to set these bits in the blob similarly as there is for other reserved fields. We used to error about those but due to delays in maintaining the blobs it was too restricting.
Also those bits have been removed in the internal specification for the ACE2.x DMIC IP.
@singalsu still DNM ?
It's now safe to merge. Alsa-utils patch 19a75d0ebcc9602b7be0043d58740c51fed2ca2c "topology: nhlt: Intel: Clear DMIC BFTH bits for version" is now included.