linux-kernel - Re: [alsa-devel] [PATCH 15/27] ALSA: hda - Use timecounter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d3e83230-dc06-fc2b-b507-723d4863fb4e@intel.com>
Date:   Fri, 5 Jan 2018 15:36:56 +0530
From:   Sagar Arun Kamble <sagar.a.kamble@...el.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Richard Cochran <richardcochran@...il.com>
Cc:     alsa-devel@...a-project.org, Takashi Iwai <tiwai@...e.de>,
        linux-kernel@...r.kernel.org, Vinod Koul <vinod.koul@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [alsa-devel] [PATCH 15/27] ALSA: hda - Use timecounter_initialize
 interface



On 1/3/2018 1:23 AM, Pierre-Louis Bossart wrote:
> On 1/2/18 12:21 PM, Richard Cochran wrote:
>> On Tue, Jan 02, 2018 at 11:15:45AM -0600, Pierre-Louis Bossart wrote:
>>> 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
>>
>> Would using clocks_calc_mult_shift() work for you?
>
> In theory yes, but I'd need to re-check what the results would be.
> I remember applying the 1/3 factor separately to avoid wrap-around 
> after 4 hours [1], but I can't remember the details on the analysis. I 
> can't figure out what the 'maxsec' argument should be either.
>
I am not sure if I understood the wrap-around correctly. Is 
AZX_REG_WALL_CLK 64bit or 32bit and in the comments which 20 bits are 
being referred.

Keeping maxsec at lower value will ensure good precision but the mult 
factor derived then might lead to overflow if the interval of counter 
read is big.
Keeping maxsec high will reduce the mult factor and will marginally 
impact the precision (of the order of 6 decimal places of fraction nano 
second).

For 24mhz clock I am getting following scale factors at different maxsec 
values. I think these are as good as 125/3
125/3 gives scale factor of 41.666666666666666666666666666667

maxsec, mult, shift, scale factor (mult/(2^shift))
0, 2796202667, 26,     41.66666667163372039794921875
3600, 87381333, 21,   41.666666507720947265625
14400, 21845333, 19, 41.6666660308837890625

I see sound driver uses only timecounter_read so conversions should be fine.
If there are usages of timecounter_cyc2time then we will have to take 
care of updating the timecounter often as
timecounter API internally counts time backwards if counter is spaced 
more than 1/2 the range.

Thanks
Sagar
> [1] 
> http://elixir.free-electrons.com/linux/latest/source/sound/hda/hdac_stream.c#L486 
>