On Mon, 1 Oct 2018 11:58:14 +0800 Song Qiang <songqiang1304521@xxxxxxxxx> wrote: > On Fri, Sep 28, 2018 at 06:52:13PM -0500, Rob Herring wrote: > > On Fri, Sep 28, 2018 at 4:36 AM Song Qiang <songqiang1304521@xxxxxxxxx> wrote: > > > > > > On Wed, Sep 26, 2018 at 05:46:18PM -0500, Rob Herring wrote: > > > > On Sat, Sep 22, 2018 at 04:05:23PM +0100, Jonathan Cameron wrote: > > > > > On Tue, 18 Sep 2018 16:24:22 +0800 > > > > > Song Qiang <songqiang1304521@xxxxxxxxx> wrote: > > > > > > > > > > > The first version of this driver issues a measuring request and polling > > > > > > for a status register in the device for measuring completes. > > > > > > vl53l0x support configuring GPIO1 on it to generate interrupt to > > > > > > indicate that new measurement is ready. This patch adds support for > > > > > > using this mechanisim to reduce cpu cost. > > > > > > > > > > > > Signed-off-by: Song Qiang <songqiang1304521@xxxxxxxxx> > > > > > Hi Song. > > > > > > > > > > Looks correct in principal but a few things to tidy up before > > > > > this is ready to apply. > > > > > > > > > > Also we have an unrelated change in here to check the devices ID. > > > > > That should be in it's own patch. > > > > > > > > > > Thanks, > > > > > > > > > > Jonathan > > > > > > --- > > > > > > .../bindings/iio/proximity/vl53l0x.txt | 14 +- > > > > > > > > This should have been split with the complete binding in one patch > > > > rather than piecemeal driver feature by feature. > > > > > > > > > > Hi Rob, > > > > > > A few days ago when I was submitting this driver, I didn't do it very > > > well, the function of this driver is limited. I added interrupt support > > > the next day after you acked my first patch. I thought it's not polite > > > to add something after someone acked that patch, so I send the interrupt > > > support as a second patch. The first patch is merged to togreg now, but > > > this doesn't. I don't know when can I add new functions to the code that > > > just merged to togreg branch, could you offer some suggestions? > > > > You just needed to state why you didn't add a ack. But really, just > > don't send things except as RFC until they are "done". > > > > What to do next depends on Jonathan and whether he wants a follow-up > > patch or he will drop the first one. > > > > > > > > drivers/iio/proximity/vl53l0x-i2c.c | 135 +++++++++++++++--- > > > > > > 2 files changed, 129 insertions(+), 20 deletions(-) > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt b/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt > > > > > > index ab9a9539fec4..40290f8dd70f 100644 > > > > > > --- a/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt > > > > > > +++ b/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt > > > > > > @@ -4,9 +4,21 @@ Required properties: > > > > > > - compatible: must be "st,vl53l0x-i2c" > > > > > > > > Is there more than one interface on this device, such as SPI? If not, > > > > then '-i2c' should be dropped. > > > > > > > > > > Yes, there is a CCI(Camera Control Interface) for communication. > > > > Isn't CCI just a subset of I2C? I should clarify my question is > > whether there's more than 1 mutually exclusive control interface (as > > many devices have control and data interfaces) where you could have 2 > > different drivers. A common example are devices with I2C and SPI > > interfaces. > > > > Rob > > Hi Rob, Jonathan, > > I don't know things about CCI very well, and google also tells me little > about it. Actually, I found it difficult to find a standard definition > about it. Then I dug into vl53l0x's API source code, and what I can > tell is when we use these two interfaces, the whole programming > framework is different, even though the pysical bus of them are likely > to be the same. > Source code of CCI uses a 'msm_camera_i2c_fn_t' struct and a > 'v4l2_file_operations' as hardware interfaces for controlling device, > while the i2c one just uses generic i2c bus interfaces. > > This explanation is for why the file name still contains '-i2c'. > File names are easy to change in future compared to device tree bindings (which may be fixed for ever in an embedded platform). So this isn't a problem at all. Thanks, Jonathan > yours, > Song Qiang
