On Mon, 11 Dec 2017 09:18:55 +0100
Quentin Schulz [off-list ref] wrote:

Hi Jonathan,

On 10/12/2017 17:36, Jonathan Cameron wrote:

quoted

On Mon,  4 Dec 2017 15:12:48 +0100
Quentin Schulz [off-list ref] wrote:
  

quoted

The X-Powers AXP813 PMIC is really close to what is already done for
AXP20X/AXP22X.

There are two pairs of bits to set the rate (one for Voltage and Current
measurements and one for TS/GPIO0 voltage measurements) instead of one.  

This would normally imply we need to split the device into two logical
IIO devices.  However, that only becomes relevant if we are using
buffered output which this driver doesn't support.  

quoted

It'll be nasty to deal with this if we add that support down the line  

though.  Up to you though as it's more likely to be your problem than
anyone else's :)
  

I have no plans for supporting buffered output for the AXPs at the
moment. But that's an interesting (and important) limitation to raise.
Wouldn't be more of a hack to have two IIO devices representing the
actual same IP?

We have thought about allowing multiple buffers from a single IIO device
but that makes for some horrible changes to the ABI - so as things stand
the only option is two devices for one IP.  Ultimately they aren't really
two devices - in the same way we have triggers separating registered on
the IIO bus (often many of them).  Just two different elements of the same IP.

quoted

For now you could elect to support the different sampling frequencies
if you wanted to but just providing controls for each channel.
  

I guess that you're offering to use IIO_CHAN_INFO_SAMP_FREQ in
info_mask_separate for each channel?

Yes

quoted

Given the driver doesn't currently expose these at all (I think)
this is all rather immaterial ;)  

I'm not giving the user the option to chose the sampling frequency for
now. I have no plans to do it either, but I think it would be rather
simple to later add support for setting frequency sampling since we only
need to add a sysfs entry (with IIO_CHAN_INFO_SAMP_FREQ) that does not
exist yet. Don't you think? Am I missing something?

No should be straight forward as long as we keep clear of the buffered
interfaces with their limitations.

Thanks,
Quentin