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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <316ce0d5-318d-0533-ef06-bd7e8672f893@nvidia.com>
Date:   Fri, 21 Feb 2020 14:31:05 +0000
From:   Jon Hunter <jonathanh@...dia.com>
To:     Mark Brown <broonie@...nel.org>, Sameer Pujar <spujar@...dia.com>
CC:     <perex@...ex.cz>, <tiwai@...e.com>, <robh+dt@...nel.org>,
        <lgirdwood@...il.com>, <thierry.reding@...il.com>,
        <digetx@...il.com>, <alsa-devel@...a-project.org>,
        <devicetree@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <sharadg@...dia.com>,
        <mkumard@...dia.com>, <viswanathl@...dia.com>,
        <rlokhande@...dia.com>, <dramesh@...dia.com>,
        <atalambedu@...dia.com>
Subject: Re: [PATCH v3 03/10] ASoC: tegra: add Tegra210 based DMIC driver


On 21/02/2020 13:00, Mark Brown wrote:
> On Thu, Feb 20, 2020 at 12:04:45PM +0530, Sameer Pujar wrote:
> 
>> +++ b/sound/soc/tegra/tegra210_dmic.c
>> @@ -0,0 +1,515 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * tegra210_dmic.c - Tegra210 DMIC driver
>> + *
>> + * Copyright (c) 2020 NVIDIA CORPORATION.  All rights reserved.
> 
> Please make the entire comment a C++ one so things look more
> intentional.
> 
>> +	/* Below enables all filters - DCR, LP and SC */
>> +	{ TEGRA210_DMIC_DBG_CTRL, 0xe },
> 
> So this isn't the hardware default?
> 
>> +	srate = params_rate(params);
>> +	if (dmic->srate_override)
>> +		srate = dmic->srate_override;
> 
> How does this work for userspace?  If we just ignore the sample rate we
> were asked for I'd expect that the application would get upset.

Tegra has a hardware sample rate converter (though driver not yet
upstream or part of this initial series) and if using the sample-rate
converter, then the actual rate captured by the DMIC interface could be
different from the resulting sample-rate.

So we want a way to indicate to the DMIC it is capturing at rate X,
while the resulting sample-rate is Y.

I am not sure if there is a better way to do this? Ideally, the DMIC
would query the rate from the upstream MUX it is connected to, but I am
not sure if there is a way to do that. So right now it is a manual
process and the user has to configure these which are not ideal.

Cheers
Jon

-- 
nvpublic

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ