On 4/11/19 1:09 AM, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote:
On Wed, Apr 10, 2019 at 09:24:29PM -0700, Nicolin Chen wrote:
On Wed, Apr 10, 2019 at 05:55:19PM -0700, Guenter Roeck wrote:
+static ssize_t samples_for_avg_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct i2c_client *client = to_i2c_client(dev->parent);
+ int ret;
+
+ ret = pmbus_read_byte_data(client, 0, LM25066_SAMPLES_FOR_AVG);
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "%d\n", 1 << ret);
+}
+
+static ssize_t samples_for_avg_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct i2c_client *client = to_i2c_client(dev->parent);
+ int ret, val;
+
+ ret = kstrtoint(buf, 0, &val);
+ if (ret < 0)
+ return ret;
+
+ ret = pmbus_write_byte_data(client, 0, LM25066_SAMPLES_FOR_AVG,
+ ilog2(val));
+ if (ret < 0)
+ return ret;
+
+ return count;
+}
+
+static DEVICE_ATTR_RW(samples_for_avg);
+
+static struct attribute *lm25056_attrs[] = {
+ &dev_attr_samples_for_avg.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(lm25056); // should we set a name of this group to put all
+ // those attributes in subdirectory? Like "custom" ?
+
We don't add subdirectories for other chips, and we won't start it here.
I don't mind the attribute itself, but I do mind its name. We'll have
to find something more generic, such as 'num_samples' or just 'samples'.
I am open to suggestions. We'll also have to decide if the attribute(s)
should be limited to one per chip, or if there can be multiple attributes.
For example, MAX34462 has separate values for iout_samples and adc_average.
Do we want samples, {curr,in,power,...}_samples, or both ? Or even
currX_samples ?
For my use case -- TI's INA chips, there is only one "samples"
configuration being used for all currX_inputs and inX_inputs.
So having a "samples" node would certainly fit better than an
in0_samples. So I vote for having both.
The name is family specific. The data sheet calls this register exactly
like that so I used this name. But I agree that we could standardise on
Well, yes, but the whole point of an ABI is to make it chip independent.
some common name, even if the actual implementation will be
device-specific.
The LM5064 has one value for all readings, ADM1293 would have one
setting for PIN and separate one for VIN/VAUX/IOUT.
So maybe it makes sense to allow for some device specific naming (with
prefixes) where it makes sense but default to "samples" in simple case
of shared value? In this case, if there is specific value like
"curr_samples", user knows exactly which readings are influenced but
when using "samples" it needs to have device specific knowledge to
understand this.
Let's go for "samples" and {in,curr,power,temp,...}_samples. "samples"
should be used if the attribute applies to all sensors.
I'm just not sure what would be the best way to express situation for
adm1293 for example - the PIN case is simple but what to do with
"shared" settings - expose both curr_samples/in_samples and writing to
one would change the other as well? Or just default to "samples" for
this case and have separate "power_samples" just for PIN?
Both "samples" and "power_samples" at the same time would be confusing.
Common implementation in situations like this is to have both curr_samples
and in_samples, and changing one would also change the other (or only one
would be writable, but that is just an implementation detail).
So what we need is virtual registers (PMBUS_VIRT_SAMPLES, PMBUS_VIRT_IN_SAMPLES,
and so on), plus the necessary code in pmbus_core.c and the implementation
in the chip driver. We'll also need to document new ABI attributes (samples,
in_samples, temp_samples, ...).
Any takers ?
Nicolin, I think with that you can move forward with the TI INA chip
implementation. I agree that 'samples' would be most appropriate for
this chip.
Thanks,
Guenter
