On 16/08/2022 16:56, Mark Brown wrote:
On Tue, Aug 16, 2022 at 02:44:47PM +0100, Srinivas Kandagatla wrote:
On 16/08/2022 14:11, Mark Brown wrote:
On Mon, Aug 15, 2022 at 10:22:37AM +0100, Srinivas Kandagatla wrote:
The issue is that it's not clear if the platform_max value should be a
value for the register or a value for the control. For some reason
(which frankly is the source of a lot of the problems here) the controls
adjust the user visible range to be zero based even though the ABI would
be totally fine with any range. There were out of tree patches that
changed things for some of the control types too.
Only Instances where platform_max is set are via kcontrol builder macros,
which then always sets this to xmax.
Those macros just shouldn't be setting platform_max at all, the whole > goal with platform_max is that it overrides what the driver is doing for
platform specific reasons. This is supposed to be overridable by the
Ah,
Do you think we should remove setting platform_max from these macros.
Am hoping that this should also fix the issues that am seeing.
--srini
machine integration, but looking now it looks like it's got lost in the
shuffle, I can't see any mechanism to configure it via DT or machine
drivers right now though I think there might be some out of tree drivers
that do it or perhaps I'm doing the wrong greps.
And none of these macros have provision to pass platform_max these are
always assumed to be xmax. Which am not sure is always correct.
That's entirely correct in that if it's not been overridden by the
platform then we should just use whatever the driver provided.
- max = uinfo->value.integer.max = mc->max - mc->min;
+ max = uinfo->value.integer.max = mc->max;
Don't do double assignments like this, they're confusing.
