On Wed, Apr 10, 2019 at 07:22:31AM +0000, S.j. Wang wrote:
The table was copied directly from the Reference Manual. We also have listed all supported input and output sample rates just right behind that table. If there're missing rates, we probably should update those two lists also? Otherwise, how could we have a driver limiting both I/O sample rates while we still see something not in the table?
Yes, I plan to send another patch to update the in/out rate list. Do I need To merge that to this commit? Actually we want to support 12k and 24KHz
Please send separate patches but in one series. And a question:
Is it possible to update the table? It'd be way quicker to use lookup table than real-time calculation all the time. I believe you can simply calculate all the values out for 12KHz and 24KHz since you have the function. If there are certain combinations of these two not being supported, then we could mark it with a special value and add an if-check to error out.
+static int proc_autosel(int Fsin, int Fsout, int *pre_proc, int +*post_proc)
Please add some comments to this function to explain what it does, and how it works. And better to rename it to something like "fsl_asrc_sel_proc".
Yes, some comments should be added, but not so detail, because this function
As much comments as possible.
Is get from the design team, but the owner has left.
OK...that's sad...
Another thing confuses me: so we could have supported sample rates in the list but the hardware might not support some of them because we couldn't calculate their processing options?
No, just want to support 12k, 24KHz, or others as customer like.
I was confused because the I/O rate lists not getting updated. It makes sense now if you are abort to update them.