[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <15ee98bd-b92b-8a34-e3f9-a1537edf2da9@gmail.com>
Date: Sun, 23 Jul 2023 14:15:10 +0200
From: Andrea Collamati <andrea.collamati@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Lars-Peter Clausen <lars@...afoo.de>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, linux-iio@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] iio: add MCP4728 I2C DAC driver
On 7/23/23 13:41, Jonathan Cameron wrote:
>>>> +
>>>> + if (mode == MCP4728_VREF_EXTERNAL_VDD &&
>>>> + data->channel_data[chan->channel].g_mode == MCP4728_GAIN_X2) {
>>>> + dev_warn(&data->client->dev,
>>>> + "CH%d: Gain x2 not effective when vref is vdd, force to x1",
>>>> + chan->channel);
>>> Even better if you don't present the option at all and wrap it up in the
>>> standard ABI of _scale
>>>
>> I think that the solution could be:
>>
>> - Removing custom ABI (vref/gain)
>>
>> - Initialize them at device tree level using two 4-elements arrays.
> If doing with device tree, they should reflect something that is a characteristic
> of how the chips is wired up. So you would need to explain why that is the case here.
>
> However, I'm still not understanding why _SCALE is not appropriate here. We have
> a small set of options with well defined scales.
SCALE is appropriate. I didn't know that scale_available was a standard ABI.
I will follow the implementation done n https://github.com/torvalds/linux/blob/c2782531397f5cb19ca3f8f9c17727f1cdf5bee8/drivers/iio/dac/ad5592r-base.c#L487
Powered by blists - more mailing lists