On Thu, May 07, 2015 at 02:52:22PM +0100, Charles Keepax wrote:
This is the only place where we have _check_path_cache() calls so n is always 2 here and it is unclear where that number comes from or what it means without going and peering at the implementation and the commit log. It seems it would be better to hide that number inside the function.
I was sort of thinking along the lines of if anyone wanted to add CODEC specific levels of searching the cache or some such. But I have no problem moving this into the function, probably was a bit premature generalisation there.
I think there's probably a long way to go with making the generic cache more performant before we need to start adding CODEC specific code.
:-) The original version I did put the pointers in the DAPM context, but I somehow managed to talk myself out of it as I was nervous of bloating the DAPM context and it felt like this only applied to adding routes. Adding it to the card feels kinda reasonable as that is where the lists we are caching reside.
If it's just one or two pointers it's not that big a deal in the DAPM context, we don't have that many of those per card or per system - if it was going into the widgets that'd hurt a lot more.