On 1/2/18 12:03 AM, Sagar Arun Kamble wrote:
On 12/28/2017 10:19 PM, Richard Cochran wrote:
On Tue, Dec 26, 2017 at 01:07:35PM +0530, Sagar Arun Kamble wrote:
Or can we provide simpler versions for covering some defaults? At least reducing the number of arguments would make things easier.
Thought about specifying 1. cyclecounter read func 2. frequency 3. width of counter as parameters here which can get rid of mult, shift params. But this is not easy as most of the drivers do not specify cyclecounter frequency and instead hard-code the mult/shift factors.
You are talking about using clocks_calc_mult_shift() here, right? (See the usage example in drivers/net/ethernet/ti/cpts.c).
Yes
This is a good idea, and it is worth getting the driver authors' input to figure out the correct parameters.
I wrote the code for HDaudio and I remember wasting time trying to figure out the gory details of the cycle counter stuff when all I wanted was a conversion from a 24MHz counter to ns values using a 125/3 operation in the right order - as explained in the comments
If there was a helper to set those mult/shift values it'd make the HDaudio code clearer (and also help support newer modes of operation with a 12 and 6 MHz MCLK).
The initial proposal with hard-coded values in arguments instead of structure members didn't really make the code clearer.
I bet we can use that almost everywhere. If there are any drivers that cannot be converted, then we can leave some sort of low level legacy initialization method.
Agree
Thanks, Richard
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel