From: Dan Murphy <dmurphy@ti.com>
To: Mark Brown <broonie@kernel.org>
Cc: <lgirdwood@gmail.com>, <perex@perex.cz>, <tiwai@suse.com>,
<alsa-devel@alsa-project.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ASoC: tas2562: Add support for digital volume control
Date: Thu, 20 Feb 2020 13:22:34 -0600 [thread overview]
Message-ID: <6f3ff810-5e75-cb33-10d6-198a7c5cd202@ti.com> (raw)
In-Reply-To: <20200220191803.GH3926@sirena.org.uk>
Mark
On 2/20/20 1:18 PM, Mark Brown wrote:
> On Thu, Feb 20, 2020 at 12:46:57PM -0600, Dan Murphy wrote:
>> On 2/20/20 12:45 PM, Mark Brown wrote:
>>> Is there a reason not to use the chip default here? Otherwise this
>>> looks good.
>> Chip default is set to 0dB full blast+ 0x40400000. This sets the volume to
>> -110dB.
> OK... that's a policy decision the same as all other volume changes and
> so shouldn't be done by the driver - as ever we don't know how the
> system is set up and what values make sense and keeping things out of
> the driver means we don't end up with competing system integration
> decisions causing changes in the driver. The system may have an
> external amplifier they prefer to use for hardware volume control, may
> prefer to do entirely soft volume control in their sound server or
> something like that.
But this is an amplifier. Not sure why the system designer would design
cascading amplifiers.
And if that was the case wouldn't you want the output to be low so you
don't overdrive the ext amplifier front end?
I mean I have no qualms with removing the init from the driver. I will
send v3 tomorrow after a 24 hour review cycle.
I was considering safety in that the device is on at full blast (not
sure why the HW is defaulted that way but it is).
But if volume is adjusted prior to playback then this is not an issue.
But if volume is not adjusted then it plays full blast.
Dan
next prev parent reply other threads:[~2020-02-20 19:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-20 17:27 Dan Murphy
2020-02-20 18:45 ` Mark Brown
2020-02-20 18:46 ` Dan Murphy
2020-02-20 19:18 ` Mark Brown
2020-02-20 19:22 ` Dan Murphy [this message]
2020-02-20 19:40 ` Mark Brown
2020-02-20 19:52 ` Dan Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6f3ff810-5e75-cb33-10d6-198a7c5cd202@ti.com \
--to=dmurphy@ti.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®