On Mon, 2023-07-03 at 14:27 +0200, AngeloGioacchino Del Regno wrote:
Il 30/06/23 13:00, Mark Brown ha scritto:
On Fri, Jun 30, 2023 at 05:29:23AM +0000, Trevor Wu (吳文良) wrote:
On Thu, 2023-06-29 at 16:06 +0100, Mark Brown wrote:
This commit message isn't entirely clear. The effect of the
commit
is to restrict the configurations supported when using a nau8825 but it's not clear what a nau8825 has to do with this or why we're doing
this
in general. What exactly do you mean when saying that "only a
limited
number of parameters are necessary" and what makes this the case?
For instance, some userspace frameworks only support specific
sampling
rates such as 48kHz on Chromebook, making other parameters
unnecessary.
By restricting the configuration, unexpected usage can be
prevented and
the alsa_conformance_test process which checks all parameters
provided
by an ALSA driver can be sped up.
That's a userspace policy decision, we shouldn't be enforcing this
in
the kernel - even for Chromebooks people can install other OSs on
them
which may make different decisions, and it's always possible that
the
ChromeOS people might change their mind later. If they're only interested in testing 48kHz and it's slowing things down
unreasonably
to test more then they should just only test 48kHz rather than
changing
the driver to work around it.
Would it be more beneficial to establish the criteria as a general
rule
for this machine driver, while limiting the use of the machine
driver
solely to the Chromebook project? Or do you just suggest that I
add
more details in the commit messages?
I think we just shouldn't do this, it's policy for ChromeOS rather
than
something that's actually needed. If we were doing this it would
need a
much clearer commit message and we should be restricting things to Chromebooks only.
I agree with Mark. Except for me it's not a *should not* but a *shall not*.
Such other configurations are supported by the hardware and it is the driver's duty to support all of them - otherwise I deem the driver to be *incomplete*. It's then the userspace's duty to properly use the sound APIs and request the right sampling rate for specific usecases.
Chromebooks aren't special at all in this regard.
Thanks for your suggestion. After the internal discussion, we decided to drop the patch. On the other hand, I will send another patch using dpcm_merged_xxx to report the actual capability of hardware.
Thanks, Trevor